From viridia at gmail.com  Thu Jan  1 03:21:21 2009
From: viridia at gmail.com (Talin)
Date: Thu, 01 Jan 2009 01:21:21 -0800
Subject: [LLVMdev] Unit test patch, updated
In-Reply-To: <f88b89a50812311827s4dc2b610gd0982675ba654691@mail.gmail.com>
References: <d1b71f830812301307w7dd9377fv1c19d927c02d1f40@mail.gmail.com>	<f88b89a50812301432i128d08efud4bdbbc4fcf7a390@mail.gmail.com>	<f88b89a50812301440o68c0b8afw9db6ad8642160449@mail.gmail.com>	<d1b71f830812301454h73f8f4few2e96f1be35a18677@mail.gmail.com>	<EC3652F4-03DB-48E0-B96C-7BBBFBF2703A@apple.com>
	<f88b89a50812311827s4dc2b610gd0982675ba654691@mail.gmail.com>
Message-ID: <495C8B11.7020409@gmail.com>

Hooray!

I'm thinking that getting unit tests for the classes in ADT should be an 
early goal.

I also wanted to mention a point about the general philosophy of unit 
testing, which is that the presence of such tests alters the calculation 
of risk when making changes to a code base. Programmers have various 
rules of thumb for estimating risk - for example, a change which affects 
a large number of lines of code is generally perceived to be riskier 
than a change which affects a small number of lines. But at the same 
time, some very large changes can carry almost no risk - such as 
changing the name of a symbol which occurs in thousands of places in the 
code - because the compiler will tell you if you made a mistake 
anywhere. What unit tests do is allow that same kind of assurance at the 
semantic level that the compiler's syntax checking gives you at the 
syntactical level. And since reduction of risk in one area allows taking 
greater risks elsewhere, it can act as an enabler for global 
refactorings and other radical improvements that would have been 
perceived as too risky otherwise.

This ability of unit tests to reduce perceived risk works best if the 
tests are comprehensive, testing even trivial aspects of the target 
class (such as brand new container correctly reporting empty()).

-- Talin

Misha Brukman wrote:
> 2008/12/31 Chris Lattner <clattner at apple.com>
>
>   
>> On Dec 30, 2008, at 2:54 PM, Talin wrote:
>>
>> OK changes made and new patch attached.
>>
>> +++ utils/unittest/Makefile (revision 0)
>>
>> ...
>> +# This has to come after Makefile.common, since it doesn't allow us to
>> +# override the VPATH value unless we set PROJECT_NAME, which we don't want
>> +# to do.
>> +VPATH = $(LLVM_SRC_ROOT)/utils/unittest/googletest/src/
>>
>>
>> Why play with VPATH here?  What is this doing?  Can this be handled a
>> different way?  Similarly in makefile.unittest.
>>
>>     
>
> Removed VPATH in this file by moving GTest up one directory, and added
> VPATH-less Makefiles:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=61539
> http://llvm.org/viewvc/llvm-project?view=rev&revision=61540 (minor revision)
>
> Also removed VPATH from Makefile.unittest (see link below).
>
> +++ unittests/ADT/DenseMapTest.cpp (revision 0)
>   
>> +namespace {
>> +
>> +using namespace llvm;
>>
>>
>> Please put the 'using' right after the #includes.
>>
>>     
>
> Done.
>
>
>   
>> Otherwise, the patch looks good to me.  Please verify that it works with
>> both a SRCDIR=OBJDIR and SRCDIR!=OBJDIR build.
>>
>>     
>
> Done for both; passes both with flying colors.
> Submitted: http://llvm.org/viewvc/llvm-project?view=rev&revision=61541
>
> Thanks to Talin for the original patch.
>
> Now everyone can go write some unittests!
>
> Misha
>
> P.S.  Why are you still reading?  Go!  Write!  Test!
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From isanbard at gmail.com  Thu Jan  1 06:08:05 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Thu, 1 Jan 2009 04:08:05 -0800
Subject: [LLVMdev] Unit test patch, updated
In-Reply-To: <495C8B11.7020409@gmail.com>
References: <d1b71f830812301307w7dd9377fv1c19d927c02d1f40@mail.gmail.com>	<f88b89a50812301432i128d08efud4bdbbc4fcf7a390@mail.gmail.com>	<f88b89a50812301440o68c0b8afw9db6ad8642160449@mail.gmail.com>	<d1b71f830812301454h73f8f4few2e96f1be35a18677@mail.gmail.com>	<EC3652F4-03DB-48E0-B96C-7BBBFBF2703A@apple.com>
	<f88b89a50812311827s4dc2b610gd0982675ba654691@mail.gmail.com>
	<495C8B11.7020409@gmail.com>
Message-ID: <FD19936C-DA2B-4911-A73C-5A3603D8E6CB@gmail.com>

On Jan 1, 2009, at 1:21 AM, Talin wrote:

> Hooray!
>
> I'm thinking that getting unit tests for the classes in ADT should  
> be an
> early goal.
>
Definitely! This is an area of "low hanging fruit".

> I also wanted to mention a point about the general philosophy of unit
> testing, which is that the presence of such tests alters the  
> calculation
> of risk when making changes to a code base. Programmers have various
> rules of thumb for estimating risk - for example, a change which  
> affects
> a large number of lines of code is generally perceived to be riskier
> than a change which affects a small number of lines. But at the same
> time, some very large changes can carry almost no risk - such as
> changing the name of a symbol which occurs in thousands of places in  
> the
> code - because the compiler will tell you if you made a mistake
> anywhere. What unit tests do is allow that same kind of assurance at  
> the
> semantic level that the compiler's syntax checking gives you at the
> syntactical level. And since reduction of risk in one area allows  
> taking
> greater risks elsewhere, it can act as an enabler for global
> refactorings and other radical improvements that would have been
> perceived as too risky otherwise.
>
> This ability of unit tests to reduce perceived risk works best if the
> tests are comprehensive, testing even trivial aspects of the target
> class (such as brand new container correctly reporting empty()).
>
I completely agree with all you said here. LLVM has been lacking in  
"quality assurance" for a long time. Only recently have we've set up  
buildbot systems to make sure that incremental changes won't break  
obvious things. The unit testing will make sure that invariant  
assumptions about the code will remain after each change. Those people  
who maintain buildbot systems should add the unit tests as part of the  
testing process.

Thanks for spearheading this, Talin!

-bw


From jon at ffconsultancy.com  Thu Jan  1 08:13:51 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Thu, 1 Jan 2009 14:13:51 +0000
Subject: [LLVMdev] sret
Message-ID: <200901011413.51486.jon@ffconsultancy.com>


I'm returning structs from functions by passing a pointer to the pre-existing 
struct as the first argument. However, I am not setting "sret" because there 
are not yet any OCaml bindings for it. What am I missing out on?

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From jon at ffconsultancy.com  Thu Jan  1 08:25:43 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Thu, 1 Jan 2009 14:25:43 +0000
Subject: [LLVMdev] Suggestion: Support union types in IR
In-Reply-To: <495C150E.5000200@gmail.com>
References: <d1b71f830812301241w4d1b49b9ke2a9d1d7cbb1fab3@mail.gmail.com>
	<7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com>
	<495C150E.5000200@gmail.com>
Message-ID: <200901011425.43875.jon@ffconsultancy.com>

On Thursday 01 January 2009 00:57:50 Talin wrote:
> Jon Harrop wrote:
> > I think very few people are still using C-style unions so there is
> > probably little desire to put them into LLVM itself. Class hierarchies
> > and algebraic datatypes are much more common and use a different
> > representation (that LLVM can already handle with bitcasts).
> > Specifically, as a pointer to one of several struct types that can vary
> > in size.
> >
> > I am considering a design along the following lines. All algebraic
> > datatypes are stored as a pointer to an int tag:
> >
> >   i32 *
>
> Exactly. I'm not especially interested in C-style unions, I'm interested
> in discriminated unions. But the actual discriminator field is easily
> represented in LLVM IR already, so there's no need to extend the IR to
> support them. That's why I am only asking for C-style union support -
> it's a lower-level primitive that you can use to build discriminated
> unions on top of.

I don't think you would want to build discriminated unions on top of C-style 
unions though.

> The problem with varying-size structs is that it would be nice to be
> able to pass them as function parameters and function return values
> using LLVM's support of structs as first-class data types.

As I understand it, LLVM does not provide first-class structs and attempting 
to return arbitrary structs from functions will randomly break. I believe you 
need to implement that yourself in whatever way your target language 
requires.

> That requires that the code that handles argument marshalling know the size
> of the largest possible type that can be passed.

Pass a pointer and that size will always be 1 word. You can still stack 
allocate the space if you must and LLVM's optimization passes will do their 
best to completely remove that overhead when possible.

> > The tag conveys the true type of the value and, indeed, it may even be a
> > pointer to comprehensive run-time type information. So you load the tag
> > and examine it in order to determine what type to cast to. Then you
> > bitcast to another type if you need to load any arguments (that appear
> > after the tag). For example, an int option type might cast as follows:
> >
> >   None   (tag=0) -> {i32} *
> >   Some n (tag=1) -> {i32, i32} *
>
> Since the language I am working on is statically typed, I was going to
> select a type discrimination strategy based on the actual types
> involved. For example, in the case of a union of reference types,
> there's no need for a discriminator field,

Only if they are all different reference types. Otherwise you might have the 
situation:

  type t = Negate of t | Factorial of t

Where both constructors carry an argument of the same type (t) and you do 
still need a tag to distinguish between the cases (Negate and Factorial) in 
the union.

> since reference types already 
> carry around their own type information. On the other hand, if you have
> a union of two enum types of limited range, the high bits of the enum
> would be available. In cases such as int or float where all the bits
> were used, then a separate discriminator field would be needed.

There is certainly some scope here and I have been thinking about similar 
things. I would like both run-time type information and efficient pattern 
matching over algebraic datatypes.

The run-time type information can be a field from every reference type that 
points to its run-time type. When pattern matching, you usually want to 
bisect the number of cases covered in the union to perform a balanced search 
and achieve the best performance. That usually assumes the presence of 
consecutive integers as tags so the use of effectively-random pointers would 
throw that off a bit, especially if the run-time type information is 
subjected to a moving garbage collector. Alternatively, I could put a 
redundant tag in each value on the heap...

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From baldrick at free.fr  Thu Jan  1 09:06:34 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 1 Jan 2009 16:06:34 +0100
Subject: [LLVMdev] sret
In-Reply-To: <200901011413.51486.jon@ffconsultancy.com>
References: <200901011413.51486.jon@ffconsultancy.com>
Message-ID: <200901011606.34534.baldrick@free.fr>

Hi,

> I'm returning structs from functions by passing a pointer to the pre-existing 
> struct as the first argument. However, I am not setting "sret" because there 
> are not yet any OCaml bindings for it. What am I missing out on?

sret exists to achieve ABI compliance, i.e. to achieve interoperability with
code compiled with other compilers.  If you don't care about that, there's
not much point in setting sret attribute.

Ciao,

Duncan.

From vitaly.chipounov at epfl.ch  Thu Jan  1 10:50:32 2009
From: vitaly.chipounov at epfl.ch (Vitaly C.)
Date: Thu, 1 Jan 2009 08:50:32 -0800 (PST)
Subject: [LLVMdev] Re ducing LLVM's memory usage
In-Reply-To: <21174014.post@talk.nabble.com>
References: <21174014.post@talk.nabble.com>
Message-ID: <21242672.post@talk.nabble.com>


Hi


Vitaly C. wrote:
> 
> Is there are simple way of cleaning the used memory without destroying
> everything (unloading the ExecutionEngine, freeing the module, calling
> llvm_shutdown) ? Ideally I would like something which brings everything to
> the state just after I created the JIT engine for the first time.
> 

I've tried to run the Fibonacci example with Valgrind after having added
delete EE and llvm_shutdown in the main of fibonacci.cpp. Unfortunately, it
gives me a lot of definitely lost blocks.
I also have similar problems with my own code: there is a lot of lost
ConstantInts. From what I saw in the LLVM code, constants are put in a
statically managed structure which is supposed to be cleaned at shutdown.

Vitaly C.

-- 
View this message in context: http://www.nabble.com/Reducing-LLVM%27s-memory-usage-tp21174014p21242672.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From zackr at vmware.com  Thu Jan  1 13:14:13 2009
From: zackr at vmware.com (Zack Rusin)
Date: Thu, 1 Jan 2009 14:14:13 -0500
Subject: [LLVMdev] [Mesa3d-dev]  Folding vector instructions
In-Reply-To: <4d77c5f20812310615o522fe2cej966dc439c8d296f2@mail.gmail.com>
References: <a63d088d0812291829g2d933cdxfc14cdb00b42156b@mail.gmail.com>
	<495AE109.7010806@gmail.com>
	<4d77c5f20812310615o522fe2cej966dc439c8d296f2@mail.gmail.com>
Message-ID: <200901011414.14172.zackr@vmware.com>

On Wednesday 31 December 2008 09:15:09 Alex wrote:
> Zack Rusin wrote:
> > I think Alex was referring here to a AOS layout which is completely not
> > ready.
> > Actually currently the plan is to have essentially a "two pass" LLVM IR.
> > I wanted the first one to never lower any of the GPU instructions so we'd
> > have intrinsics or maybe even just function calls like gallium.lit,
> > gallium.dot, gallium.noise and such. Then gallium should query the driver
> > to figure out which instructions the GPU supports and runs our custom
> > llvm lowering pass that decomposes those into things the GPU supports.
>
> If I understand correct, that is to say, the gallium will dynamically build
> a lowering pass by querying the capability (instructions supported by the
> GPU)? Instead, isn't it a better approach to have a lowering pass for each
> GPU and gallium simply uses it?

The whole point of Gallium is to make driver development as simple as 
possible. So while it's certainly harder to write this code in a way that 
could be generic it's essentially what Gallium is all about and it's at least 
worth a try. 

> What do you plan to do with SOA and AOS paths in the gallium?

For now we need to figure out whether we need all the layouts or whether one  
is enough for all the backends.

> (1) Will they eventually be developed independently? So that for a
> scalar/SIMD GPU, the SOA will be used to generate LLVM IR, and for a vector
> GPU, AOS is used?

Well, they're all connected, so developing them independently would be hard. 
As mentioned above, depending on what's going to happen either we'll let the 
drivers ask for the layout that they want to work with or decide to use one 
layout everywhere.

> (2) At present the difference between SOA and AOS path is not only the
> layout of the input data. The AOS seems to be more complete for me, though
> Rusin has said that it's completely not ready and not used in the gallium.
> Is there a plan to merge/add the support of function/branch and LLVM IR
> extract/insert/shuffle to the SOA code?

I wrote both so I can tell you they're both far from usable. It looks like 
Stephane and Corbin are rocking right now but the infrastructure code in 
Gallium needs a lot of love. We have a lot of choices to make over the next 
few months and obviously all the paths (assuming those will be "paths" and not 
a "path") will require feature parity.

> By the way, is there any open source frontend which converts GLSL to LLVM
> IR?

Yes, there is at:
http://cgit.freedesktop.org/~zack/mesa.git.old/log/?h=llvm
but it's also not complete.

z

From nunoplopes at sapo.pt  Thu Jan  1 13:35:50 2009
From: nunoplopes at sapo.pt (Nuno Lopes)
Date: Thu, 1 Jan 2009 19:35:50 -0000
Subject: [LLVMdev] Re ducing LLVM's memory usage
In-Reply-To: <21242672.post@talk.nabble.com>
References: <21174014.post@talk.nabble.com> <21242672.post@talk.nabble.com>
Message-ID: <F170A439A623463BAC84E6545DBA1253@pc07654>

>> Is there are simple way of cleaning the used memory without destroying
>> everything (unloading the ExecutionEngine, freeing the module, calling
>> llvm_shutdown) ? Ideally I would like something which brings everything 
>> to
>> the state just after I created the JIT engine for the first time.
>>
>
> I've tried to run the Fibonacci example with Valgrind after having added
> delete EE and llvm_shutdown in the main of fibonacci.cpp. Unfortunately, 
> it
> gives me a lot of definitely lost blocks.
> I also have similar problems with my own code: there is a lot of lost
> ConstantInts. From what I saw in the LLVM code, constants are put in a
> statically managed structure which is supposed to be cleaned at shutdown.

The leakage of Constant* is a known issue.
In attach I send a fairly complete suppression file for valgrind (use 
with --suppressions=valgrind.supp) that will suppress the known problems 
from the report.

Nuno 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind.supp
Type: application/octet-stream
Size: 1943 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090101/006c5976/attachment.obj 

From clattner at apple.com  Thu Jan  1 14:16:48 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 1 Jan 2009 12:16:48 -0800
Subject: [LLVMdev] Unit test patch, updated
In-Reply-To: <495C8B11.7020409@gmail.com>
References: <d1b71f830812301307w7dd9377fv1c19d927c02d1f40@mail.gmail.com>
	<f88b89a50812301432i128d08efud4bdbbc4fcf7a390@mail.gmail.com>
	<f88b89a50812301440o68c0b8afw9db6ad8642160449@mail.gmail.com>
	<d1b71f830812301454h73f8f4few2e96f1be35a18677@mail.gmail.com>
	<EC3652F4-03DB-48E0-B96C-7BBBFBF2703A@apple.com>
	<f88b89a50812311827s4dc2b610gd0982675ba654691@mail.gmail.com>
	<495C8B11.7020409@gmail.com>
Message-ID: <65DD53BE-BF0C-4C0C-9A59-86C0757B115B@apple.com>


On Jan 1, 2009, at 1:21 AM, Talin wrote:

> Hooray!
>
> I'm thinking that getting unit tests for the classes in ADT should  
> be an
> early goal.

Can I suggest the AP[S]Int class?  If you look in llvm/test/Integer  
you'll see a whole bunch of tests that really want to be unit tests  
but that aren't.  :(

-Chris

From alex.lavoro.propio at gmail.com  Thu Jan  1 14:23:19 2009
From: alex.lavoro.propio at gmail.com (Alex)
Date: Thu, 1 Jan 2009 12:23:19 -0800 (PST)
Subject: [LLVMdev] Vector swizzling and write masks code generation
In-Reply-To: <Pine.LNX.4.62.0709271028430.5978@nondot.org>
References: <200709270954.10980.zack@tungstengraphics.com>
	<Pine.LNX.4.62.0709271028430.5978@nondot.org>
Message-ID: <21244478.post@talk.nabble.com>


Chris Lattner wrote:
> > So I think my options come down to:
> >
> > 1) figure out a way of having code generator be actually able to combine
> all
> > those IR instructions back into
> > OP dst.writemask src1.swizzle1 src2.swizzle2
> 
> Yep.  If you're using the LLVM code generator, it makes it reasonably easy 
> to pattern match on this sort of thing and/or introduce machine specific 
> abstractions to describe them.

I'd like to know if this is already implemented in some backend? so that I
can take it as an example.
-- 
View this message in context: http://www.nabble.com/Vector-swizzling-and-write-masks-code-generation-tp12921797p21244478.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From lrn1986 at gmail.com  Thu Jan  1 23:19:50 2009
From: lrn1986 at gmail.com (LRN)
Date: Fri, 02 Jan 2009 08:19:50 +0300
Subject: [LLVMdev] TableGen crash
Message-ID: <495DA3F6.8070109@gmail.com>

TableGen crashes while building llvm when it tries to generate
/llvm/tools/llvmc/plugins/Base/AutoGenerated.inc from
/llvm/tools/llvmc/plugins/Base/Base.td
As a result AutoGenerated.inc is full of garbage and it's not possible
to proceed any further.

I've debugged TableGen and found out that it dies somewhere in
EmitForwardOptionPropertyHandlingCode().

I've modified LLVMCConfigurationEmitter.cpp to be like this:

/// EmitForwardOptionPropertyHandlingCode - Helper function used to
/// implement EmitActionHandler. Emits code for
/// handling the (forward) and (forward_as) option properties.
void EmitForwardOptionPropertyHandlingCode (const OptionDescription& D,
                                            const char* Indent,
                                            const std::string& NewName,
                                            std::ostream& O) {
  const std::string& Name = NewName.empty()
    ? ("-" + D.Name)
    : NewName;

  switch (D.Type) {
  case OptionType::Switch:
    O << Indent << "vec.push_back(\"" << Name << "\");\n";
    break;
  case OptionType::Parameter:
    O << Indent << "vec.push_back(\"" << Name << "\");\n";
    O << Indent << "vec.push_back(" << D.GenVariableName() << ");\n";
    break;
  case OptionType::Prefix:
    O << Indent << "vec.push_back(\"" << Name << "\" + "
      << D.GenVariableName() << ");\n";
    break;
  case OptionType::PrefixList:
    O << Indent << "for (" << D.GenTypeDeclaration()
      << "::iterator B = " << D.GenVariableName() << ".begin(),\n"
      << Indent << "E = " << D.GenVariableName() << ".end(); B != E; ++B)\n"
      << Indent << Indent1 << "vec.push_back(\"" << Name << "\" + "
      << "*B);\n";
    break;
  case OptionType::ParameterList:
    O << Indent;
    O << "for (";
    O << D.GenTypeDeclaration();
    O << "::iterator B = ";
    O << D.GenVariableName();
    O << ".begin(),\n";
    O << Indent;
    O << "E = ";
    O << D.GenVariableName();
    O << ".end() ; B != E; ++B) {\n";
    O << Indent;
    O << Indent1;
    O << "vec.push_back(\"";
    O << Name;
    O << "\");\n";
    O << Indent;
    O << Indent1;
    O << "vec.push_back(*B);\n";
    O << Indent;
    O << "}\n";
    break;
  case OptionType::Alias:
  default:
    throw std::string("Aliases are not allowed in tool option
descriptions!");
  }
}

and re-built TableGen.

then from /d/projects/llvm/utils/TableGen i did:

$ gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) file d:\\projects\\llvm\\Debug\\bin\\tblgen.exe
Reading symbols from d:\projects\llvm\Debug\bin\tblgen.exe...done.
(gdb) set args -I d:/projects/llvm/tools/llvmc/plugins/Base -I
d:/projects/llvm/include -I d:/projects/llvm/lib/Target -gen-llvmc -o
d:/projects/llvm/tools/llvmc/plugins/Base/Debug/AutoGenerated.inc.tmp
d:/projects/llvm/tools/llvmc/plugins/Base/Base.td
(gdb) start
Breakpoint 1 at 0x481330: file TableGen.cpp, line 129.
Starting program: d:\projects\llvm\Debug\bin\tblgen.exe -I
d:/projects/llvm/tools/llvmc/plugins/Base -I d:/projects/llvm/include -I
d:/projects/llvm/lib/Target -gen-llvmc -o
d:/projects/llvm/tools/llvmc/plugins/Base/Debug/Aut
oGenerated.inc.tmp d:/projects/llvm/tools/llvmc/plugins/Base/Base.td
[New thread 3744.0x1a10]
Error: dll starting at 0x77d40000 not found.
Error while mapping shared library sections:
NOT_AN_IMAGE: No such file or directory.
Error while mapping shared library sections:
C:\WINXP64\SysWOW64\ntdll32.dll: No such file or directory.
Error: dll starting at 0x77d40000 not found.
Error: dll starting at 0x77c20000 not found.
main (argc=2293680, argv=0x4010b6) at TableGen.cpp:129
129     int main(int argc, char **argv) {
(gdb) break 196
Breakpoint 2 at 0x481b7c: file TableGen.cpp, line 196.
(gdb) c
Continuing.

Breakpoint 2, main (argc=2293680, argv=0x4010b6) at TableGen.cpp:196
196           LLVMCConfigurationEmitter(Records).run(*Out);
(gdb) s
llvm::LLVMCConfigurationEmitter::run (this=0x22ff40, O=0xd0d190) at
LLVMCConfigurationEmitter.cpp:1882
1882      PluginData Data;
(gdb) break 1147
Breakpoint 3 at 0x45a651: file LLVMCConfigurationEmitter.cpp, line 1147.
(gdb) c
Continuing.

Breakpoint 3, (anonymous
namespace)::EmitForwardOptionPropertyHandlingCode (D=0xd0d81c,
Indent=0xd0de4c ' ' <repeats 12 times>, NewName=0x22f860, O=0xd0d190) at
LLVMCConfigurationEmitter.cpp:1149
1149        : NewName;
(gdb) n
1151      switch (D.Type) {
(gdb) n
1171        O << Indent;
(gdb) n
1172        O << "for (";
(gdb) n
1173        O << D.GenTypeDeclaration();
(gdb) n
1174        O << "::iterator B = ";
(gdb) n
1175        O << D.GenVariableName();
(gdb) n
1176        O << ".begin(),\n";
(gdb) n
1177        O << Indent;
(gdb) n
1178        O << "E = ";
(gdb) n
1179        O << D.GenVariableName();
(gdb) n
1180        O << ".end() ; B != E; ++B) {\n";
(gdb) n
1181        O << Indent;
(gdb) n
1182        O << Indent1;
(gdb) n
1183        O << "vec.push_back(\"";
(gdb) n
1184        O << Name;
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x77bc10f5 in wsopen () from C:\WINXP64\syswow64\msvcrt.dll
(gdb) bt
#0  0x77bc10f5 in wsopen () from C:\WINXP64\syswow64\msvcrt.dll
#1  0x0000006c in ?? ()
#2  0x00000003 in ?? ()
#3  0x77bf4a00 in ?? ()
#4  0x00000400 in ?? ()
#5  0x00d0da7c in ?? ()
#6  0x00000000 in ?? ()

I think there's something wrong with NewName. I don't know how to debug
std::string's in gdb, so i can't check what's happening with it, but an
attempt to step into "const std::string& Name = NewName.empty() ? ("-" +
D.Name) : NewName;" results in a segfault.
"(gdb) print NewName.c_str()" causes a segfault too.

This is reproduceable for both SVN and 2.4, but not in 2.3 (2.3 builds
without errors).

P.S. /llvm/utils/unittest/googletest/include/gtest/gtest-port.h:175 is
VERY true. Tell kenton that gtest-filepath.cc:267 should be updated
accordingly.

From clattner at apple.com  Fri Jan  2 01:12:40 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 1 Jan 2009 23:12:40 -0800
Subject: [LLVMdev] New .ll parser
Message-ID: <B100F27B-3609-49D4-8CEC-A9FCA684A57C@apple.com>

I just checked in a new parser for .ll files, deleting the old bison  
parser.  This means that the last of the ".cvs" files are gone from  
the tree, which will hopefully make the world a happier place for  
windows users in particular.  I tested it thoroughly but expect minor  
fallout, if you notice any problems, please let me know.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081229/071618.html

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090101/61785b6e/attachment-0001.html 

From listiges at arcor.de  Fri Jan  2 13:17:33 2009
From: listiges at arcor.de (Nico)
Date: Fri, 2 Jan 2009 20:17:33 +0100
Subject: [LLVMdev] link problem with llvm-pass
Message-ID: <B2E52147-1E2B-4B11-8846-84EBFC8142DA@arcor.de>

Hi,

I tried to implement an 'llc'-like tool in my project to manage  
different passes and a target machine.

I use given llvm project structure to avoid problems but I have a link  
problem and don't know how to solve it:
The target machine uses 'FindUsedTypes' pass and when I try to use my  
target machine in the tool I got "Undefined symbols:  
"llvm::FindUsedTypes ... ld: symbol(s) not found"

I tried following link options:
LLVMLIBS = LLVMAnalysis.a
LINK_COMPONENTS = analysis
LINK_COMPONENTS = all
But nothing solved my problem (in fact the last made some other  
problems with code I never touched).

I would be very appreciated for any idea.

Thanks a lot
Nico

PS: output from "make VERBOSE=1"

llvm[2]: Linking Release executable llx (without symbols)
/Users/me/Work/code/llvm-2.4/mklib --tag=CXX --tag=disable-shared -- 
mode=link g++ -I/Users/me/Work/code/llvm-2.4/include -I/Users/me/Work/ 
code/synphony/llvmllila/build/include -I/Users/me/Work/code/synphony/ 
llvmllila/build/tools/llx -I/Users/me/Work/code/synphony/llvmllila/ 
include -I/Users/me/Work/code/synphony/llvmllila/tools/llx  -D_DEBUG  - 
D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O3  -fno-exceptions  -Woverloaded- 
virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused - 
Wno-unused-parameter  -fstrict-aliasing -Wstrict-aliasing -O3  -rpath / 
Users/me/Work/code/synphony/llvmllila/build/Release//bin -export- 
dynamic -L/Users/me/Work/code/synphony/llvmllila/build/Release//lib -L/ 
Users/me/Work/code/llvm-2.4/Release//lib   -o /Users/me/Work/code/ 
synphony/llvmllila/build/Release//bin/llx  /Users/me/Work/code/ 
synphony/llvmllila/build/tools/llx/Release/main.o -lLMABE -lPartition - 
lLLVMBitReader -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport - 
lLLVMSystem \
	   -lpthread -lm
g++ -I/Users/me/Work/code/llvm-2.4/include -I/Users/me/Work/code/ 
synphony/llvmllila/build/include -I/Users/me/Work/code/synphony/ 
llvmllila/build/tools/llx -I/Users/me/Work/code/synphony/llvmllila/ 
include -I/Users/me/Work/code/synphony/llvmllila/tools/llx -D_DEBUG - 
D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O3 -fno-exceptions -Woverloaded- 
virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused - 
Wno-unused-parameter -fstrict-aliasing -Wstrict-aliasing -O3 -o /Users/ 
me/Work/code/synphony/llvmllila/build/Release//bin/llx /Users/me/Work/ 
code/synphony/llvmllila/build/tools/llx/Release/main.o  -L/Users/me/ 
Work/code/synphony/llvmllila/build/Release//lib -L/Users/me/Work/code/ 
llvm-2.4/Release//lib -lLMABE -lPartition -lLLVMBitReader - 
lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMSystem - 
lpthread -lm
Undefined symbols:
   "llvm::FindUsedTypes::ID", referenced from:
       __ZN4llvm13FindUsedTypes2IDE$non_lazy_ptr in  
libLMABE.a(LMAWriter.o)
   "typeinfo for llvm::FindUsedTypes", referenced from:
       __ZTIN4llvm13FindUsedTypesE$non_lazy_ptr in  
libLMABE.a(LMAWriter.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [/Users/me/Work/code/synphony/llvmllila/build/Release// 
bin/llx] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1

From scooter.phd at gmail.com  Fri Jan  2 14:13:42 2009
From: scooter.phd at gmail.com (Scott Michel)
Date: Fri, 2 Jan 2009 12:13:42 -0800
Subject: [LLVMdev] New .ll parser
In-Reply-To: <B100F27B-3609-49D4-8CEC-A9FCA684A57C@apple.com>
References: <B100F27B-3609-49D4-8CEC-A9FCA684A57C@apple.com>
Message-ID: <258cd3200901021213v551a2dfdp36779d2cf499abb1@mail.gmail.com>

Checking in ParserInternals.h would probably be a good thing about now...
because if you take this update, it doesn't compile.


-scooter

On Thu, Jan 1, 2009 at 11:12 PM, Chris Lattner <clattner at apple.com> wrote:

> I just checked in a new parser for .ll files, deleting the old bison
> parser.  This means that the last of the ".cvs" files are gone from the
> tree, which will hopefully make the world a happier place for windows users
> in particular.  I tested it thoroughly but expect minor fallout, if you
> notice any problems, please let me know.
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081229/071618.html
>
> -Chris
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090102/7bd4494a/attachment.html 

From scooter.phd at gmail.com  Fri Jan  2 14:17:26 2009
From: scooter.phd at gmail.com (Scott Michel)
Date: Fri, 2 Jan 2009 12:17:26 -0800
Subject: [LLVMdev] New .ll parser
In-Reply-To: <258cd3200901021213v551a2dfdp36779d2cf499abb1@mail.gmail.com>
References: <B100F27B-3609-49D4-8CEC-A9FCA684A57C@apple.com>
	<258cd3200901021213v551a2dfdp36779d2cf499abb1@mail.gmail.com>
Message-ID: <258cd3200901021217i77ec58dagb17322cb93fcf79a@mail.gmail.com>

Maybe not. Maybe we just need to ensure that lib/AsmParser/llvmAsmParser.cpp
is actually deleted.

-scooter

On Fri, Jan 2, 2009 at 12:13 PM, Scott Michel <scooter.phd at gmail.com> wrote:

> Checking in ParserInternals.h would probably be a good thing about now...
> because if you take this update, it doesn't compile.
>
>
> -scooter
>
> On Thu, Jan 1, 2009 at 11:12 PM, Chris Lattner <clattner at apple.com> wrote:
>
>> I just checked in a new parser for .ll files, deleting the old bison
>> parser.  This means that the last of the ".cvs" files are gone from the
>> tree, which will hopefully make the world a happier place for windows users
>> in particular.  I tested it thoroughly but expect minor fallout, if you
>> notice any problems, please let me know.
>>
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081229/071618.html
>>
>> -Chris
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090102/cce8ed15/attachment.html 

From brukman at gmail.com  Fri Jan  2 14:21:27 2009
From: brukman at gmail.com (Misha Brukman)
Date: Fri, 2 Jan 2009 15:21:27 -0500
Subject: [LLVMdev] Private headers and testing
Message-ID: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>

Hi all,

Reading this doc:
http://llvm.org/docs/CodingStandards.html#hl_privateheaders, it suggests
putting private implementation details outside of llvm/include/* to avoid
polluting the public header space.  This makes sense, and it works fine,
because make enters every directory and hence doesn't need a -I path to
include them.

However, unittests need to also #include these headers to be able to test
the internal implementations, so here are potential ways to do this:
1) Leave headers where they are now; pass in -I$(LLVM_SRC_ROOT) and #include
"lib/Transform/..." for the unittests
2) Same as above, except with -I$(LLVM_SRC_ROOT)/lib and #include
"Transform/..."
3) Create a new header directory for internal headers, e.g.
llvm/include/llvm/internal/ and put private headers there; no one needs any
new -I switches, implementation libraries and unittests all say #include
"llvm/internal/*" and all is well.  If there's a concern that we are
distributing/installing private headers, we can amend the install script to
"rm -rf llvm/include/internal" to avoid the issue.

Thoughts/comments?

Misha
(I'm voting #3)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090102/1f334826/attachment.html 

From baldrick at free.fr  Fri Jan  2 14:42:11 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 2 Jan 2009 21:42:11 +0100
Subject: [LLVMdev] New .ll parser
In-Reply-To: <258cd3200901021213v551a2dfdp36779d2cf499abb1@mail.gmail.com>
References: <B100F27B-3609-49D4-8CEC-A9FCA684A57C@apple.com>
	<258cd3200901021213v551a2dfdp36779d2cf499abb1@mail.gmail.com>
Message-ID: <200901022142.11737.baldrick@free.fr>

> Checking in ParserInternals.h would probably be a good thing about now...

Hi Scott, actually the problem is left over files in lib/AsmParser.  If
you delete that directory then "svn update" to check it out again things
should be ok.

Ciao,

Duncan.

From clattner at apple.com  Fri Jan  2 14:05:18 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 2 Jan 2009 12:05:18 -0800
Subject: [LLVMdev] Suggestion: Support union types in IR
In-Reply-To: <200901011425.43875.jon@ffconsultancy.com>
References: <d1b71f830812301241w4d1b49b9ke2a9d1d7cbb1fab3@mail.gmail.com>
	<7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com>
	<495C150E.5000200@gmail.com>
	<200901011425.43875.jon@ffconsultancy.com>
Message-ID: <3618EE78-E115-4EF3-AC9B-05BDF5403F5B@apple.com>

On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote:
>> Exactly. I'm not especially interested in C-style unions, I'm  
>> interested
>> in discriminated unions. But the actual discriminator field is easily
>> represented in LLVM IR already, so there's no need to extend the IR  
>> to
>> support them. That's why I am only asking for C-style union support -
>> it's a lower-level primitive that you can use to build discriminated
>> unions on top of.
>
> I don't think you would want to build discriminated unions on top of  
> C-style
> unions though.

Why?

>> The problem with varying-size structs is that it would be nice to be
>> able to pass them as function parameters and function return values
>> using LLVM's support of structs as first-class data types.
>
> As I understand it, LLVM does not provide first-class structs and  
> attempting
> to return arbitrary structs from functions will randomly break. I  
> believe you
> need to implement that yourself in whatever way your target language
> requires.

This is a current implementation deficiency, not a design limitation.   
We welcome patches to fix this.

-Chris

From clattner at apple.com  Fri Jan  2 14:10:41 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 2 Jan 2009 12:10:41 -0800
Subject: [LLVMdev] Suggestion: Support union types in IR
In-Reply-To: <495C150E.5000200@gmail.com>
References: <d1b71f830812301241w4d1b49b9ke2a9d1d7cbb1fab3@mail.gmail.com>
	<7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com>
	<495C150E.5000200@gmail.com>
Message-ID: <F86BFCCF-E2A6-4FF7-9F63-A4723564727D@apple.com>

On Dec 31, 2008, at 4:57 PM, Talin wrote:
> Nick Lewycky wrote:
>> It has to come down to a fixed size at some point, using target- 
>> specific
>> knowledge. Is there any reason you couldn't use 'opaque' here and
>> resolve it once you have the necessary information?
>>
> Perhaps I've never quite understood the role of bitcode files.  
> Assume I
> have a compiler that generates .bc files, and a linker which combines
> them into a runnable program. At which point is the target machine
> chosen, in the compiler or in the linker? The assumption that I have
> made up to this point is that the compiler produces .bc files which  
> are
> target-neutral, and the linker then generates a target-specific  
> program.
> (I realize that other design choices are possible.)

Well there are two answers to this.  Ideally, LLVM would work as you  
say.  Unfortunately some of the current implementation has been  
tainted by LLVM's primary development being guided by the needs of C  
compilers.  C compilers inherently need the front-end to encode target- 
specific information in the IR.

However, I really do want to serve portable languages better.   
Ideally, the first time that target-specificity comes into play is at  
the "llc" level.  I think we are very close to this, but I believe  
there are still a few problem areas.

That said, I don't think this is a reason *not to add* the 'portable  
union' feature, I just think it's a reason we *haven't already* added  
it.

> Exactly. I'm not especially interested in C-style unions, I'm  
> interested
> in discriminated unions. But the actual discriminator field is easily
> represented in LLVM IR already, so there's no need to extend the IR to
> support them. That's why I am only asking for C-style union support -
> it's a lower-level primitive that you can use to build discriminated
> unions on top of.

Yes, I completely agree with you.

-Chris

From clattner at apple.com  Fri Jan  2 14:48:25 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 2 Jan 2009 12:48:25 -0800
Subject: [LLVMdev] Suggestion: Support union types in IR
In-Reply-To: <200901011425.43875.jon@ffconsultancy.com>
References: <d1b71f830812301241w4d1b49b9ke2a9d1d7cbb1fab3@mail.gmail.com>
	<7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com>
	<495C150E.5000200@gmail.com>
	<200901011425.43875.jon@ffconsultancy.com>
Message-ID: <7CE8B76C-7C82-4F08-AFD5-E2F9ABFD3669@apple.com>

On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote:
>> Exactly. I'm not especially interested in C-style unions, I'm  
>> interested
>> in discriminated unions. But the actual discriminator field is easily
>> represented in LLVM IR already, so there's no need to extend the IR  
>> to
>> support them. That's why I am only asking for C-style union support -
>> it's a lower-level primitive that you can use to build discriminated
>> unions on top of.
>
> I don't think you would want to build discriminated unions on top of  
> C-style
> unions though.

Why?

>> The problem with varying-size structs is that it would be nice to be
>> able to pass them as function parameters and function return values
>> using LLVM's support of structs as first-class data types.
>
> As I understand it, LLVM does not provide first-class structs and  
> attempting
> to return arbitrary structs from functions will randomly break. I  
> believe you
> need to implement that yourself in whatever way your target language
> requires.

This is a current implementation deficiency, not a design limitation.   
We welcome patches to fix this.

-Chris

From clattner at apple.com  Fri Jan  2 14:54:43 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 2 Jan 2009 12:54:43 -0800
Subject: [LLVMdev] Private headers and testing
In-Reply-To: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>
References: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>
Message-ID: <86C752D4-EB94-4A38-9D4B-DE9E42AFC166@apple.com>


On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:

> Hi all,
>
> Reading this doc: http://llvm.org/docs/CodingStandards.html#hl_privateheaders 
> , it suggests putting private implementation details outside of llvm/ 
> include/* to avoid polluting the public header space.  This makes  
> sense, and it works fine, because make enters every directory and  
> hence doesn't need a -I path to include them.
>
> However, unittests need to also #include these headers to be able to  
> test the internal implementations, so here are potential ways to do  
> this:
> 1) Leave headers where they are now; pass in -I$(LLVM_SRC_ROOT) and  
> #include "lib/Transform/..." for the unittests
> 2) Same as above, except with -I$(LLVM_SRC_ROOT)/lib and #include  
> "Transform/..."
> 3) Create a new header directory for internal headers, e.g. llvm/ 
> include/llvm/internal/ and put private headers there; no one needs  
> any new -I switches, implementation libraries and unittests all say  
> #include "llvm/internal/*" and all is well.  If there's a concern  
> that we are distributing/installing private headers, we can amend  
> the install script to "rm -rf llvm/include/internal" to avoid the  
> issue.

Do you have a specific example of a unit test that would need these?   
I really think these should stay private.

-Chris 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090102/ead1622b/attachment.html 

From brukman at gmail.com  Fri Jan  2 15:48:19 2009
From: brukman at gmail.com (Misha Brukman)
Date: Fri, 2 Jan 2009 16:48:19 -0500
Subject: [LLVMdev] Private headers and testing
In-Reply-To: <86C752D4-EB94-4A38-9D4B-DE9E42AFC166@apple.com>
References: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>
	<86C752D4-EB94-4A38-9D4B-DE9E42AFC166@apple.com>
Message-ID: <f88b89a50901021348t4d3ec6fcocabbc15a8a67c177@mail.gmail.com>

2009/1/2 Chris Lattner <clattner at apple.com>

> On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:
> Do you have a specific example of a unit test that would need these?  I
> really think these should stay private.
>

Let's take lib/Transforms/Utils/CodeExtractor.cpp .  The public interface
for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the
high-level API.

If I want to test some corner-case (consider the number of code paths in
that code), I have to strain to come up with some combination of a Function
and input BasicBlocks that will fit all the conditions from the outset.  Or,
I can just feed each individual method in the class exactly the corner cases
I will want it to handle, and verify its output (or side effects) exactly,
to make sure I pin-pointed the issue.

Or, let's say I want to write some tests for the LLParser -- the only public
API is "ParseAssemblyString", I can't unittest each individual method.  The
unittest for this using the public API will be very brittle as it would have
to check the contents of the returned error message, instead of calling each
Parse*() function directly and analyzing its output.

Of course, we should still have a test for the overall public API, but
that's in addition to the small unit tests to make sure each one works as it
should.

Note that this is a parallel to having an on-disk representation of IR
(which LLVM has) to a lack of such (which some other compilers had and/or
have now).  In the former case, to test an optimization, one just writes
LLVM IR and runs the pass directly on the case at hand.  In the other case,
one has to strain to come up with a front-end input source that will trigger
something in the 'blackbox' middle or back-end code, knowing that it will
get pre-digested before it gets there, and hence it's hard to know what
you're really testing on.

Misha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090102/d46222fa/attachment.html 

From jon at ffconsultancy.com  Fri Jan  2 16:29:57 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Fri, 2 Jan 2009 22:29:57 +0000
Subject: [LLVMdev] Suggestion: Support union types in IR
In-Reply-To: <7CE8B76C-7C82-4F08-AFD5-E2F9ABFD3669@apple.com>
References: <d1b71f830812301241w4d1b49b9ke2a9d1d7cbb1fab3@mail.gmail.com>
	<200901011425.43875.jon@ffconsultancy.com>
	<7CE8B76C-7C82-4F08-AFD5-E2F9ABFD3669@apple.com>
Message-ID: <200901022229.57568.jon@ffconsultancy.com>

On Friday 02 January 2009 20:48:25 Chris Lattner wrote:
> On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote:
> >> Exactly. I'm not especially interested in C-style unions, I'm
> >> interested in discriminated unions. But the actual discriminator field is
> >> easily represented in LLVM IR already, so there's no need to extend the
> >> IR to support them. That's why I am only asking for C-style union
> >> support - it's a lower-level primitive that you can use to build
> >> discriminated unions on top of.
> >
> > I don't think you would want to build discriminated unions on top of
> > C-style unions though.
>
> Why?

Uniformity when nesting and space efficiency. Users of a language front-end 
will want to nest discriminated unions, e.g. to manipulate trees. C-style 
unions are designed to be unboxed so they are useless for that unless you 
introduce pointer indirections but if you store all unions by reference then 
the uniformity of the 1-word pointer size obviates the need to use same 
(largest) size union cases so you would drop C-style unions in favor of a 
more space-efficient alternative anyway. Otherwise, you might opt for a 
non-uniform representation where local unions are unboxed but unions stored 
within them are boxed, which is needless complexity but it might buy a little 
performance.

So I think most LLVM users will represent their discriminated unions as 
something like:

  {i32, {..} *}

or:

  {i32, {..}} *

but not as C-style unions.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From fw at deneb.enyo.de  Fri Jan  2 16:31:25 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Fri, 02 Jan 2009 23:31:25 +0100
Subject: [LLVMdev] "grep -w" irregularity
In-Reply-To: <4aca3dc20812310729k7eba1ef1l257f98cb09e1bfd2@mail.gmail.com>
	(Daniel Berlin's message of "Wed, 31 Dec 2008 10:29:36 -0500")
References: <B41F2DD2-7DE4-4802-90D4-95BA88C2B5D5@aero.org>
	<f88b89a50812301655nc697026sc9dde9bc25ffaa77@mail.gmail.com>
	<C857FA75-84C1-4694-AAD9-37F61129E352@apple.com>
	<3A921759-3A6C-4191-A2B2-33C0EC166DEC@aero.org>
	<87r63ou4hc.fsf@mid.deneb.enyo.de>
	<4aca3dc20812310729k7eba1ef1l257f98cb09e1bfd2@mail.gmail.com>
Message-ID: <87fxk1iblu.fsf@mid.deneb.enyo.de>

* Daniel Berlin:

>> There have been issues the GNU libc regular expression code.  Try
>> running with "unset LANG" (or "LC_ALL=C") and see if it improves
>> things.
>>
>> The problem is that the regexp code used to be unacceptably slow in
>> multi-byte locales such as UTF-8, and the patch Debian applied to
>> improve its speed wasn't 100% correct.
>
> Considering most regexps can be done in linear time, it seems fairly
> dumb to break them to get speed, instead of simply changing
> algorithms.

IIRC, it's not an issue of complexity classes.  With multi-byte
character set conversion, the constant factor is just too large.

From mrs at apple.com  Fri Jan  2 17:19:00 2009
From: mrs at apple.com (Mike Stump)
Date: Fri, 2 Jan 2009 15:19:00 -0800
Subject: [LLVMdev] new warnings in -r61596
Message-ID: <CE391660-BD15-4D77-ACC8-2FA803D15C2D@apple.com>

2 new warnings in llvm:

/Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member  
function 'bool llvm::LLParser::ParseGlobal(const std::string&, const  
char*, unsigned int, bool, unsigned int)':
/Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:446: warning:  
'IsConstant' may be used uninitialized in this function

Volumes/mrs5/net/llvm/llvm/lib/Analysis/ScalarEvolution.cpp: In  
function 'bool isNegative(llvm::SCEVHandle)':
/Volumes/mrs5/net/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:2911:  
warning: control reaches end of non-void function


From kapilanand2 at gmail.com  Fri Jan  2 17:47:06 2009
From: kapilanand2 at gmail.com (kapil anand)
Date: Fri, 2 Jan 2009 18:47:06 -0500
Subject: [LLVMdev] Function Type and Argument List
Message-ID: <9f741d560901021547j5a6431a0obb9610a34b6953dc@mail.gmail.com>

Hi all,

I am having some problem using the Function class. For my application,
FunctionType is not known at the time I initialize the function. So, I just
initialize the Function as return type
void with no arguments. As I work on my function, I get to know the
arguments and I insert the arguments in ArgumentList data structure of the
function. The FunctionType is defined as const and I can't change that.

When I insert a call to this function, I look at ArgumentList Data
structure, and determine the number of arguments and pass them with the
call. But, FunctionType is same as original type( with no arguments). The
insertion of Call Instruction checks the functiontype and gives me an
assertion failure that I am calling the function with wrong type.

So, is there any way I can modify the functiontype after initializing the
function?

Thanks

--Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090102/be2a1478/attachment-0001.html 

From clattner at apple.com  Fri Jan  2 18:51:40 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 2 Jan 2009 16:51:40 -0800
Subject: [LLVMdev] Function Type and Argument List
In-Reply-To: <9f741d560901021547j5a6431a0obb9610a34b6953dc@mail.gmail.com>
References: <9f741d560901021547j5a6431a0obb9610a34b6953dc@mail.gmail.com>
Message-ID: <9F4204D5-2050-4C6D-A14A-4ED9038645C4@apple.com>


On Jan 2, 2009, at 3:47 PM, kapil anand wrote:

> Hi all,
>
> I am having some problem using the Function class. For my  
> application, FunctionType is not known at the time I initialize the  
> function. So, I just initialize the Function as return type
> void with no arguments. As I work on my function, I get to know the  
> arguments and I insert the arguments in ArgumentList data structure  
> of the function. The FunctionType is defined as const and I can't  
> change that.
>
> When I insert a call to this function, I look at ArgumentList Data  
> structure, and determine the number of arguments and pass them with  
> the call. But, FunctionType is same as original type( with no  
> arguments). The insertion of Call Instruction checks the  
> functiontype and gives me an assertion failure that I am calling the  
> function with wrong type.
>
> So, is there any way I can modify the functiontype after  
> initializing the function?

Nope, all LLVM IR objects have a fixed type on construction.  To  
change the type of a function, instruction, etc you have to make a new  
one.

-Chris

From clattner at apple.com  Fri Jan  2 18:52:24 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 2 Jan 2009 16:52:24 -0800
Subject: [LLVMdev] new warnings in -r61596
In-Reply-To: <CE391660-BD15-4D77-ACC8-2FA803D15C2D@apple.com>
References: <CE391660-BD15-4D77-ACC8-2FA803D15C2D@apple.com>
Message-ID: <D3236877-808E-4EE9-B66B-941B4308DBFF@apple.com>


On Jan 2, 2009, at 3:19 PM, Mike Stump wrote:

> 2 new warnings in llvm:
>
> /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member
> function 'bool llvm::LLParser::ParseGlobal(const std::string&, const
> char*, unsigned int, bool, unsigned int)':
> /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:446: warning:
> 'IsConstant' may be used uninitialized in this function

This is a bogus warning.

-Chris

From nicholas at mxc.ca  Fri Jan  2 18:59:32 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Fri, 02 Jan 2009 16:59:32 -0800
Subject: [LLVMdev] new warnings in -r61596
In-Reply-To: <CE391660-BD15-4D77-ACC8-2FA803D15C2D@apple.com>
References: <CE391660-BD15-4D77-ACC8-2FA803D15C2D@apple.com>
Message-ID: <495EB874.50000@mxc.ca>

Mike Stump wrote:
> Volumes/mrs5/net/llvm/llvm/lib/Analysis/ScalarEvolution.cpp: In  
> function 'bool isNegative(llvm::SCEVHandle)':
> /Volumes/mrs5/net/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:2911:  
> warning: control reaches end of non-void function
>   
Oops! Thanks for the report, I'll fix that promptly.

Nick

From gohman at apple.com  Sat Jan  3 13:08:12 2009
From: gohman at apple.com (Dan Gohman)
Date: Sat, 3 Jan 2009 11:08:12 -0800
Subject: [LLVMdev] Private headers and testing
In-Reply-To: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>
References: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>
Message-ID: <748FA961-F1D5-4625-A2DA-2402188AAB1F@apple.com>

On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:

> Hi all,
>
> Reading this doc: http://llvm.org/docs/CodingStandards.html#hl_privateheaders 
> , it suggests putting private implementation details outside of llvm/ 
> include/* to avoid polluting the public header space.  This makes  
> sense, and it works fine, because make enters every directory and  
> hence doesn't need a -I path to include them.

Conceptually, this kind of test should have the same include path view
of the source tree as the source it's testing.  Would it be possible  
to create
a parallel directory structure under the unittests directory? That  
way, a test
in unittests/lib/Transform/... could
be given -I$(LLVM_SRC_ROOT)/lib/Transform/... .

>
>
> However, unittests need to also #include these headers to be able to  
> test the internal implementations, so here are potential ways to do  
> this:
> 1) Leave headers where they are now; pass in -I$(LLVM_SRC_ROOT) and  
> #include "lib/Transform/..." for the unittests
> 2) Same as above, except with -I$(LLVM_SRC_ROOT)/lib and #include  
> "Transform/..."
> 3) Create a new header directory for internal headers, e.g. llvm/ 
> include/llvm/internal/ and put private headers there; no one needs  
> any new -I switches, implementation libraries and unittests all say  
> #include "llvm/internal/*" and all is well.  If there's a concern  
> that we are distributing/installing private headers, we can amend  
> the install script to "rm -rf llvm/include/internal" to avoid the  
> issue.

Otherwise, if we're voting, I vote for #2, because it keeps the tree a  
little
tidier.  Also, LLVM is used in diverse settings with a variety of  
install scripts,
so it's preferable to keep things simple.

Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090103/09db458b/attachment.html 

From gohman at apple.com  Sat Jan  3 13:46:55 2009
From: gohman at apple.com (Dan Gohman)
Date: Sat, 3 Jan 2009 11:46:55 -0800
Subject: [LLVMdev] Using CallingConvLower in ARM target
In-Reply-To: <305d6f60812270430xdf1ebb9gf6d99f94215ab66b@mail.gmail.com>
References: <305d6f60812270430xdf1ebb9gf6d99f94215ab66b@mail.gmail.com>
Message-ID: <F347CFB9-8B14-4BE9-8B57-856601D1E786@apple.com>


On Dec 27, 2008, at 4:30 AM, Sandeep Patel wrote:

> Attached is a prototype patch that uses CCState to lower RET nodes in
> the ARM target. Lowering CALL nodes will come later.
>
> This patch does not handle f64 and i64 types. For these types, it
> would be ideal to request the conversions below:

i64 isn't Legal on ARM, so it should already be handled.

>
>
> def RetCC_ARM_APCS : CallingConv<[
>  CCIfType<[f32], CCBitConvertToType<i32>>,
>  CCIfType<[f64], CCBitConvertToType<i64>>,
>  CCIfType<[i64], CCExtractElements<2, i32>>,
>
>  CCIfType<[i32], CCAssignToReg<[R0, R1]>>
> ]>;
>
> The problem is that i64 handling requires splitting into 2 x i32
> registers. I am not sure how to build CCExtractElements as shown. The
> current organization of CCState::AnalyzeReturn does not allow for
> reissuing of the RET with an altered set of operands which is the
> solution used elsewhere. Can anyone suggest a better way to express
> this lowering?

One problem with this approach is that since i64 isn't legal, the
bitcast would require custom C++ code in the ARM target to
handle properly.  It might make sense to introduce something
like

    CCIfType<[f64], CCCustom>

where CCCustom is a new entity that tells the calling convention
code to to let the target do something not easily representable
in the tablegen minilanguage.

Dan


From mgeisse at gmx.net  Sat Jan  3 12:20:14 2009
From: mgeisse at gmx.net (Martin Geisse)
Date: Sat, 3 Jan 2009 19:20:14 +0100
Subject: [LLVMdev] Creating an LLVM Project
Message-ID: <8B6BB0A6-FD7C-4FDE-ABFB-5862983F710F@gmx.net>

Hello,

I just tried to work through the "Creating an LLVM Project" tutorial  
and have some suggestions to improve that page (http://www.llvm.org/ 
docs/Projects.html).

1. The tutorial says "remove all the directories named .svn ("Create  
a Project from the Sample Project", step 2), so here's a command to  
copy-and-paste and run from within the new project directory:

find -f . \( -name .svn -and -print -and -exec rm -rf {} \; -and - 
prune \)

2. The line

AutoRegen.sh

("Create a Project from the Sample Project", step 5) should be  
changed to

./AutoRegen.sh

so it will work if . is not in the path.

3. In "Create a Project from the Sample Project", step 6 the  
arguments are used to "tell your project where the LLVM source/object  
tree is located. The tutorial doesn't really give a good hint which  
directory is meant. For example, the source is located partly in the  
lib/ and partly in the tools/ subdirectory of the main llvm  
directory. It might also refer to the main llvm directory, but the  
simple fact that the source and object directories - which are both  
within the main llvm directory -- must be specified separately  
suggests that this is not the case. In general, it left me (and  
probably others) clueless which path to specify.

4. The same step says "run configure in the directory in which you  
want to place object code". Again this left me a bit clueless, but it  
seems that running configure from any other directory than the one it  
is located in will place generated makefiles where they don't belong.  
(These generated makefiles would try to include other makefiles that  
are always in the same directory as the configure script)

Anyway, I cannot follow the "autoconf" way any more because I'm using  
an outdated aclocal version and cannot exclude this as the reason for  
the remaining problems I'm experiencing, so I will go on writing a  
custom makefile, but these suggestions should help newcomers a bit.

Greetings,
Martin Geisse


From mgeisse at gmx.net  Sat Jan  3 14:08:35 2009
From: mgeisse at gmx.net (Martin Geisse)
Date: Sat, 3 Jan 2009 21:08:35 +0100
Subject: [LLVMdev] Creating an LLVM Project
In-Reply-To: <fa28b9250901031202j7888e4a3ta03dfac33cc773c4@mail.gmail.com>
References: <8B6BB0A6-FD7C-4FDE-ABFB-5862983F710F@gmx.net>
	<fa28b9250901031202j7888e4a3ta03dfac33cc773c4@mail.gmail.com>
Message-ID: <FB366FB3-5582-4537-8C1E-F19BF716DE15@gmx.net>


On Jan 3, 2009, at 9:02 PM, me22 wrote:

> On Sat, Jan 3, 2009 at 13:20, Martin Geisse <mgeisse at gmx.net> wrote:
>>
>> Anyway, I cannot follow the "autoconf" way any more because I'm using
>> an outdated aclocal version and cannot exclude this as the reason for
>> the remaining problems I'm experiencing, so I will go on writing a
>> custom makefile, but these suggestions should help newcomers a bit.
>>
>
> You might be interested in this: http://llvm.org/bugs/show_bug.cgi? 
> id=1220

Yes, on first sight that looks exactly like the problems I'm running  
into. Thanks a lot!

Greetings,
Martin Geisse


From danchr at gmail.com  Sat Jan  3 17:29:22 2009
From: danchr at gmail.com (Dan Villiom Podlaski Christiansen)
Date: Sun, 4 Jan 2009 00:29:22 +0100
Subject: [LLVMdev] Private headers and testing
In-Reply-To: <f88b89a50901021348t4d3ec6fcocabbc15a8a67c177@mail.gmail.com>
References: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>
	<86C752D4-EB94-4A38-9D4B-DE9E42AFC166@apple.com>
	<f88b89a50901021348t4d3ec6fcocabbc15a8a67c177@mail.gmail.com>
Message-ID: <2EBFE936-7414-425E-B9AE-DC12CE9457D5@gmail.com>

On 2 Jan 2009, at 22:48, Misha Brukman wrote:

> Let's take lib/Transforms/Utils/CodeExtractor.cpp .  The public  
> interface for it is in include/llvm/Transform/Utils/FunctionUtils.h,  
> with only the high-level API.

I believe this should be possible to handle within GNU Make. Assuming  
that the source file in question is ?TheTest.cpp?, something like  
this should do the trick:
$(ObjDir)/TheTest.o $(ObjDir)/TheTest.lo: \
	CompileCommonOpts += -I$(PROJ_SRC_ROOT)/lib/Transforms/Utils
The specific entry in the GNU Make manual is ?6.10 Target-specific  
Variable Values?. [1] (I used this when trying to decrease the amount  
of libraries in LLVM; an example can be seen at [2].)

I hope this helps :)

[1] <http://www.gnu.org/software/make/manual/make.html#Target_002dspecific 
 >
[2] <http://www.bitbucket.org/danchr/llvm/src/ab1e5398289e/lib/Target/Makefile#cl-59 
 >

--

Dan Villiom Podlaski Christiansen, stud. scient.,
danchr at cs.au.dk, danchr at gmail.com



From clattner at apple.com  Sat Jan  3 19:23:16 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 3 Jan 2009 17:23:16 -0800
Subject: [LLVMdev] Private headers and testing
In-Reply-To: <f88b89a50901021348t4d3ec6fcocabbc15a8a67c177@mail.gmail.com>
References: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>
	<86C752D4-EB94-4A38-9D4B-DE9E42AFC166@apple.com>
	<f88b89a50901021348t4d3ec6fcocabbc15a8a67c177@mail.gmail.com>
Message-ID: <A1A26236-7A0F-4F76-B844-9E3182D819E2@apple.com>


On Jan 2, 2009, at 1:48 PM, Misha Brukman wrote:

> 2009/1/2 Chris Lattner <clattner at apple.com>
> On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:
> Do you have a specific example of a unit test that would need  
> these?  I really think these should stay private.
>
> Let's take lib/Transforms/Utils/CodeExtractor.cpp .  The public  
> interface for it is in include/llvm/Transform/Utils/FunctionUtils.h,  
> with only the high-level API.
>
> If I want to test some corner-case (consider the number of code  
> paths in that code), I have to strain to come up with some  
> combination of a Function and input BasicBlocks that will fit all  
> the conditions from the outset.  Or, I can just feed each individual  
> method in the class exactly the corner cases I will want it to  
> handle, and verify its output (or side effects) exactly, to make  
> sure I pin-pointed the issue.

Sure, ok.  But that is a public API, I'm specifically interested in  
cases you need private API.

> Or, let's say I want to write some tests for the LLParser -- the  
> only public API is "ParseAssemblyString", I can't unittest each  
> individual method.  The unittest for this using the public API will  
> be very brittle as it would have to check the contents of the  
> returned error message, instead of calling each Parse*() function  
> directly and analyzing its output.

The code is structured so that it is trivially easy to construct  
testcases for anything you're concerned with.  If you give me an  
example, I'll give you a testcase (in .ll form).  I don't see the need  
for unittests for LLParser.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090103/34ab5a6f/attachment.html 

From clattner at apple.com  Sat Jan  3 19:25:05 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 3 Jan 2009 17:25:05 -0800
Subject: [LLVMdev] Suggestion: Support union types in IR
In-Reply-To: <200901022229.57568.jon@ffconsultancy.com>
References: <d1b71f830812301241w4d1b49b9ke2a9d1d7cbb1fab3@mail.gmail.com>
	<200901011425.43875.jon@ffconsultancy.com>
	<7CE8B76C-7C82-4F08-AFD5-E2F9ABFD3669@apple.com>
	<200901022229.57568.jon@ffconsultancy.com>
Message-ID: <A0A463E3-C592-4B24-873C-0F598726717D@apple.com>

On Jan 2, 2009, at 2:29 PM, Jon Harrop wrote:
>>> I don't think you would want to build discriminated unions on top of
>>> C-style unions though.
>>
>> Why?
>
> Uniformity when nesting and space efficiency. Users of a language  
> front-end
> will want to nest discriminated unions, e.g. to manipulate trees.

Okay, so you're just talking about boxed vs unboxed discriminated  
unions, or "by ref" vs "by value" discriminated unions.  Clearly the  
LLVM IR support for "c style unions" would only be useful for  
"unboxed" or "byvalue" discriminated unions.  That doesn't mean that  
*your* specific uses would need them.  If you're doing "by-ref" or  
"boxed" unions, then our current support should already be sufficient.

-Chris


From hbrenkun at yahoo.cn  Sun Jan  4 05:11:20 2009
From: hbrenkun at yahoo.cn (=?gb2312?B?yM7ApA==?=)
Date: Sun, 4 Jan 2009 19:11:20 +0800 (CST)
Subject: [LLVMdev] hi, llvm-gcc  deal with va_arg() by word alignment.
In-Reply-To: <mailman.386.1231032318.8882.llvmdev@cs.uiuc.edu>
Message-ID: <364780.96994.qm@web92402.mail.cnh.yahoo.com>

hi, 
???? I am porting llvm to our embedded cpu.
By my abi, long long type is aligned by 8 bytes.
But now llvm-gcc frontend follows x86 abi, generate 
word-alignment LLVM-IR for va_arg().

?? In some degree, llvm-gcc frontend depends on targets.
The best solution is llvm-gcc can create va_arg node, 
I can lower it at the backend.

?? Who can give a temporary solution to make frontend can 
create 8 byte alignment code for long long type?

Thanks

??? renkun.



      ___________________________________________________________ 
  ????????????????? 
http://card.mail.cn.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090104/45a0386c/attachment.html 

From isanbard at gmail.com  Sun Jan  4 05:44:35 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sun, 4 Jan 2009 03:44:35 -0800
Subject: [LLVMdev] RFA: TREE_READONLY in LLVM-GCC
Message-ID: <198A9896-6114-45AD-A75F-2CA3B9A181E8@gmail.com>

Hi LLVM-GCC hackers!

I have a global variable that I want to mark as "TREE_READONLY" so  
that it will become a "constant" in LLVM IR. This is for the new  
blocks-related stuff, but that's not necessarily important for this  
question. In particular, I want to mark the "block_holder" created in  
"build_block_literal_tmp()" as read-only.

My question to you is: Considering that LLVM-GCC uses only a small  
part of the GCC source base, what affect will marking the  
"block_holder" variable as TREE_READONLY have? Does LLVM-GCC run  
through code that looks at this flag and act differently before it  
generates the LLVM IR?

I know that this is a broad question and difficult to answer. I'm  
mostly looking for people's gut reactions to this proposal. My current  
plan is to "test it out and see if it works," but the testing might  
not be comprehensive enough to ferret out potential problems.

Thanks in advance!

-bw


From jon at ffconsultancy.com  Sun Jan  4 07:07:57 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Sun, 4 Jan 2009 13:07:57 +0000
Subject: [LLVMdev] Suggestion: Support union types in IR
In-Reply-To: <A0A463E3-C592-4B24-873C-0F598726717D@apple.com>
References: <d1b71f830812301241w4d1b49b9ke2a9d1d7cbb1fab3@mail.gmail.com>
	<200901022229.57568.jon@ffconsultancy.com>
	<A0A463E3-C592-4B24-873C-0F598726717D@apple.com>
Message-ID: <200901041307.57064.jon@ffconsultancy.com>

On Sunday 04 January 2009 01:25:05 Chris Lattner wrote:
> On Jan 2, 2009, at 2:29 PM, Jon Harrop wrote:
> >>> I don't think you would want to build discriminated unions on top of
> >>> C-style unions though.
> >>
> >> Why?
> >
> > Uniformity when nesting and space efficiency. Users of a language
> > front-end
> > will want to nest discriminated unions, e.g. to manipulate trees.
>
> Okay, so you're just talking about boxed vs unboxed discriminated
> unions, or "by ref" vs "by value" discriminated unions.  Clearly the
> LLVM IR support for "c style unions" would only be useful for
> "unboxed" or "byvalue" discriminated unions.  That doesn't mean that
> *your* specific uses would need them.

Yes. I expect relatively few people would need C-style unions.

> If you're doing "by-ref" or "boxed" unions, then our current support should
> already be sufficient. 

Yes, LLVM's existing support is fine.

Incidentally, is there any way for LLVM users to vote on a "wish list" in such 
a way that developers can see which features are most sought after?

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From jon at ffconsultancy.com  Sun Jan  4 07:36:35 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Sun, 4 Jan 2009 13:36:35 +0000
Subject: [LLVMdev] HLVM
Message-ID: <200901041336.35290.jon@ffconsultancy.com>


What happened to the HLVM project? I understand it was intended to be a 
high-level VM specifically for dynamic languages and this post indicates that 
it was integrated into the LLVM project last year:

  http://www.nabble.com/NEWS:-HLVM-merges-with-LLVM-td9627113.html

But I cannot find any code in LLVM that looks like it would have come from 
HLVM.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From hyperquantum at gmail.com  Sun Jan  4 07:49:52 2009
From: hyperquantum at gmail.com (HyperQuantum)
Date: Sun, 4 Jan 2009 14:49:52 +0100
Subject: [LLVMdev] HLVM
In-Reply-To: <200901041336.35290.jon@ffconsultancy.com>
References: <200901041336.35290.jon@ffconsultancy.com>
Message-ID: <20d882600901040549i183a6339o34d8a493ba53abe9@mail.gmail.com>

On Sun, Jan 4, 2009 at 2:36 PM, Jon Harrop <jon at ffconsultancy.com> wrote:
(...)
> But I cannot find any code in LLVM that looks like it would have come from
> HLVM.

Don't know about the status of the project, but the code seems to be here:

http://llvm.org/viewvc/llvm-project/    (in directory "hlvm")


Regards,

Kevin Andr?


From criswell at uiuc.edu  Sun Jan  4 09:07:46 2009
From: criswell at uiuc.edu (John Criswell)
Date: Sun, 04 Jan 2009 09:07:46 -0600
Subject: [LLVMdev] link problem with llvm-pass
In-Reply-To: <B2E52147-1E2B-4B11-8846-84EBFC8142DA@arcor.de>
References: <B2E52147-1E2B-4B11-8846-84EBFC8142DA@arcor.de>
Message-ID: <4960D0C2.8000809@uiuc.edu>

Dear Nico,

I believe you need to add LLVMipa to the list of libraries to link into 
your tool.  FindUsedTypes::ID is defined in lib/Analysis/IPA.

I think it would be LLVMipa.a if you added it to LLVMLIBS and ipa if you 
added it to LINK_COMPONENTS.

-- John T.

Nico wrote:
> Hi,
>
> I tried to implement an 'llc'-like tool in my project to manage  
> different passes and a target machine.
>
> I use given llvm project structure to avoid problems but I have a link  
> problem and don't know how to solve it:
> The target machine uses 'FindUsedTypes' pass and when I try to use my  
> target machine in the tool I got "Undefined symbols:  
> "llvm::FindUsedTypes ... ld: symbol(s) not found"
>
> I tried following link options:
> LLVMLIBS = LLVMAnalysis.a
> LINK_COMPONENTS = analysis
> LINK_COMPONENTS = all
> But nothing solved my problem (in fact the last made some other  
> problems with code I never touched).
>
> I would be very appreciated for any idea.
>
> Thanks a lot
> Nico
>
> PS: output from "make VERBOSE=1"
>
> llvm[2]: Linking Release executable llx (without symbols)
> /Users/me/Work/code/llvm-2.4/mklib --tag=CXX --tag=disable-shared -- 
> mode=link g++ -I/Users/me/Work/code/llvm-2.4/include -I/Users/me/Work/ 
> code/synphony/llvmllila/build/include -I/Users/me/Work/code/synphony/ 
> llvmllila/build/tools/llx -I/Users/me/Work/code/synphony/llvmllila/ 
> include -I/Users/me/Work/code/synphony/llvmllila/tools/llx  -D_DEBUG  - 
> D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O3  -fno-exceptions  -Woverloaded- 
> virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused - 
> Wno-unused-parameter  -fstrict-aliasing -Wstrict-aliasing -O3  -rpath / 
> Users/me/Work/code/synphony/llvmllila/build/Release//bin -export- 
> dynamic -L/Users/me/Work/code/synphony/llvmllila/build/Release//lib -L/ 
> Users/me/Work/code/llvm-2.4/Release//lib   -o /Users/me/Work/code/ 
> synphony/llvmllila/build/Release//bin/llx  /Users/me/Work/code/ 
> synphony/llvmllila/build/tools/llx/Release/main.o -lLMABE -lPartition - 
> lLLVMBitReader -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport - 
> lLLVMSystem \
> 	   -lpthread -lm
> g++ -I/Users/me/Work/code/llvm-2.4/include -I/Users/me/Work/code/ 
> synphony/llvmllila/build/include -I/Users/me/Work/code/synphony/ 
> llvmllila/build/tools/llx -I/Users/me/Work/code/synphony/llvmllila/ 
> include -I/Users/me/Work/code/synphony/llvmllila/tools/llx -D_DEBUG - 
> D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O3 -fno-exceptions -Woverloaded- 
> virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused - 
> Wno-unused-parameter -fstrict-aliasing -Wstrict-aliasing -O3 -o /Users/ 
> me/Work/code/synphony/llvmllila/build/Release//bin/llx /Users/me/Work/ 
> code/synphony/llvmllila/build/tools/llx/Release/main.o  -L/Users/me/ 
> Work/code/synphony/llvmllila/build/Release//lib -L/Users/me/Work/code/ 
> llvm-2.4/Release//lib -lLMABE -lPartition -lLLVMBitReader - 
> lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMSystem - 
> lpthread -lm
> Undefined symbols:
>    "llvm::FindUsedTypes::ID", referenced from:
>        __ZN4llvm13FindUsedTypes2IDE$non_lazy_ptr in  
> libLMABE.a(LMAWriter.o)
>    "typeinfo for llvm::FindUsedTypes", referenced from:
>        __ZTIN4llvm13FindUsedTypesE$non_lazy_ptr in  
> libLMABE.a(LMAWriter.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [/Users/me/Work/code/synphony/llvmllila/build/Release// 
> bin/llx] Error 1
> make[1]: *** [all] Error 1
> make: *** [all] Error 1
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From charles.ying at gmail.com  Sun Jan  4 11:29:58 2009
From: charles.ying at gmail.com (Charles Ying)
Date: Sun, 4 Jan 2009 09:29:58 -0800
Subject: [LLVMdev] Avoiding jump (branch) instructions in a LLVM JavaScript
	backend
Message-ID: <3db207a40901040929v234b15bs1d323349d1399c72@mail.gmail.com>

Hello llvm-dev,

I've been hacking on a JavaScript backend to LLVM, starting with the
CBackend as base.

Sadly, JavaScript does not support a "goto" style of jump instruction,
making it "tricky" to code generate a jump instruction.

What might you recommend for avoiding jump instructions? Is there a
transformation for something like this or any other ideas? The only solution
I see at the moment is to write a small VM execution loop in JavaScript, but
I was hoping that there might be other solutions.

Thanks!
Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090104/d9e91a3a/attachment.html 

From me22.ca at gmail.com  Sun Jan  4 13:10:19 2009
From: me22.ca at gmail.com (me22)
Date: Sun, 4 Jan 2009 14:10:19 -0500
Subject: [LLVMdev] Avoiding jump (branch) instructions in a LLVM
	JavaScript backend
In-Reply-To: <3db207a40901040929v234b15bs1d323349d1399c72@mail.gmail.com>
References: <3db207a40901040929v234b15bs1d323349d1399c72@mail.gmail.com>
Message-ID: <fa28b9250901041110i4f6e4203x47c06a71ed441f45@mail.gmail.com>

On Sun, Jan 4, 2009 at 12:29, Charles Ying <charles.ying at gmail.com> wrote:
> Sadly, JavaScript does not support a "goto" style of jump instruction,
> making it "tricky" to code generate a jump instruction.
>
> What might you recommend for avoiding jump instructions? Is there a
> transformation for something like this or any other ideas? The only solution
> I see at the moment is to write a small VM execution loop in JavaScript, but
> I was hoping that there might be other solutions.
>

What about splitting each block into a javascript function and calling
it with setTimeout( function() {...}, 0)?  Or, similarly, having a
while (1) { continuation(); } loop, where goto becomes continuation =
function() {...};.

From criswell at uiuc.edu  Sun Jan  4 13:10:46 2009
From: criswell at uiuc.edu (John Criswell)
Date: Sun, 04 Jan 2009 13:10:46 -0600
Subject: [LLVMdev] Avoiding jump (branch) instructions in a LLVM
 JavaScript backend
In-Reply-To: <3db207a40901040929v234b15bs1d323349d1399c72@mail.gmail.com>
References: <3db207a40901040929v234b15bs1d323349d1399c72@mail.gmail.com>
Message-ID: <496109B6.50402@uiuc.edu>

Charles Ying wrote:
> Hello llvm-dev,
>
> I've been hacking on a JavaScript backend to LLVM, starting with the 
> CBackend as base. 
>
> Sadly, JavaScript does not support a "goto" style of jump instruction, 
> making it "tricky" to code generate a jump instruction.
One possible solution for code that is well structured is to map the 
branching behavior back into higher level constructs.

For example, the LoopInfo pass can identify loops; you can probably 
translate those into JavaScript loops.  You might be able to write a 
similar analysis pass that finds if/then/else constructs.

Of course, this won't work in the general case (since LLVM bitcode can 
express arbitrary, unstructured branching behavior), but it might offer 
better code generation for programs that were written using structured 
programming constructs.

-- John T.

>
> What might you recommend for avoiding jump instructions? Is there a 
> transformation for something like this or any other ideas? The only 
> solution I see at the moment is to write a small VM execution loop in 
> JavaScript, but I was hoping that there might be other solutions.
>
> Thanks!
> Charles
>


From molipp at arcor.de  Sun Jan  4 13:15:35 2009
From: molipp at arcor.de (Nico)
Date: Sun, 4 Jan 2009 20:15:35 +0100
Subject: [LLVMdev] link problem with llvm-pass
In-Reply-To: <4960D0C2.8000809@uiuc.edu>
References: <B2E52147-1E2B-4B11-8846-84EBFC8142DA@arcor.de>
	<4960D0C2.8000809@uiuc.edu>
Message-ID: <B35FBC68-513F-4FC6-96C4-92B29F769B24@arcor.de>

Dear John,

thanks! I was irritated by the path of the header file/declaration.
It is not like the definition in a subdirectory. Sorry my fault.

Is there an overview where classes and link options are mapped to each  
other?

Kind regards,
Nico

On Jan 4, 2009, at 4:07 PM, John Criswell wrote:

> Dear Nico,
>
> I believe you need to add LLVMipa to the list of libraries to link  
> into
> your tool.  FindUsedTypes::ID is defined in lib/Analysis/IPA.
>
> I think it would be LLVMipa.a if you added it to LLVMLIBS and ipa if  
> you
> added it to LINK_COMPONENTS.
>
> -- John T.
>
> Nico wrote:
>> Hi,
>>
>> I tried to implement an 'llc'-like tool in my project to manage
>> different passes and a target machine.
>>
>> I use given llvm project structure to avoid problems but I have a  
>> link
>> problem and don't know how to solve it:
>> The target machine uses 'FindUsedTypes' pass and when I try to use my
>> target machine in the tool I got "Undefined symbols:
>> "llvm::FindUsedTypes ... ld: symbol(s) not found"
>>
>> I tried following link options:
>> LLVMLIBS = LLVMAnalysis.a
>> LINK_COMPONENTS = analysis
>> LINK_COMPONENTS = all
>> But nothing solved my problem (in fact the last made some other
>> problems with code I never touched).
>>
>> I would be very appreciated for any idea.
>>
>> Thanks a lot
>> Nico
>>
>> PS: output from "make VERBOSE=1"
>>
>> llvm[2]: Linking Release executable llx (without symbols)
>> /Users/me/Work/code/llvm-2.4/mklib --tag=CXX --tag=disable-shared --
>> mode=link g++ -I/Users/me/Work/code/llvm-2.4/include -I/Users/me/ 
>> Work/
>> code/synphony/llvmllila/build/include -I/Users/me/Work/code/synphony/
>> llvmllila/build/tools/llx -I/Users/me/Work/code/synphony/llvmllila/
>> include -I/Users/me/Work/code/synphony/llvmllila/tools/llx  - 
>> D_DEBUG  -
>> D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O3  -fno-exceptions  - 
>> Woverloaded-
>> virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -
>> Wno-unused-parameter  -fstrict-aliasing -Wstrict-aliasing -O3  - 
>> rpath /
>> Users/me/Work/code/synphony/llvmllila/build/Release//bin -export-
>> dynamic -L/Users/me/Work/code/synphony/llvmllila/build/Release//lib  
>> -L/
>> Users/me/Work/code/llvm-2.4/Release//lib   -o /Users/me/Work/code/
>> synphony/llvmllila/build/Release//bin/llx  /Users/me/Work/code/
>> synphony/llvmllila/build/tools/llx/Release/main.o -lLMABE - 
>> lPartition -
>> lLLVMBitReader -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport -
>> lLLVMSystem \
>> 	   -lpthread -lm
>> g++ -I/Users/me/Work/code/llvm-2.4/include -I/Users/me/Work/code/
>> synphony/llvmllila/build/include -I/Users/me/Work/code/synphony/
>> llvmllila/build/tools/llx -I/Users/me/Work/code/synphony/llvmllila/
>> include -I/Users/me/Work/code/synphony/llvmllila/tools/llx -D_DEBUG -
>> D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O3 -fno-exceptions -Woverloaded-
>> virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -
>> Wno-unused-parameter -fstrict-aliasing -Wstrict-aliasing -O3 -o / 
>> Users/
>> me/Work/code/synphony/llvmllila/build/Release//bin/llx /Users/me/ 
>> Work/
>> code/synphony/llvmllila/build/tools/llx/Release/main.o  -L/Users/me/
>> Work/code/synphony/llvmllila/build/Release//lib -L/Users/me/Work/ 
>> code/
>> llvm-2.4/Release//lib -lLMABE -lPartition -lLLVMBitReader -
>> lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMSystem -
>> lpthread -lm
>> Undefined symbols:
>>   "llvm::FindUsedTypes::ID", referenced from:
>>       __ZN4llvm13FindUsedTypes2IDE$non_lazy_ptr in
>> libLMABE.a(LMAWriter.o)
>>   "typeinfo for llvm::FindUsedTypes", referenced from:
>>       __ZTIN4llvm13FindUsedTypesE$non_lazy_ptr in
>> libLMABE.a(LMAWriter.o)
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>> make[2]: *** [/Users/me/Work/code/synphony/llvmllila/build/Release//
>> bin/llx] Error 1
>> make[1]: *** [all] Error 1
>> make: *** [all] Error 1
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From libors at gmail.com  Sun Jan  4 14:25:44 2009
From: libors at gmail.com (Libor Spacek)
Date: Sun, 04 Jan 2009 20:25:44 -0000
Subject: [LLVMdev] Phishing Attack?
Message-ID: <op.um81o6ru6yy425@ubangu>

I am compiling svn head LLVM at the moment and I keep getting requests for password, which never used to occur before, followed by: 
Connection closed by 147.32.84.4, which is some site in Amsterdam.
This occurs at this point in the make execution: make[3]: Entering directory `......./llvm/lib/Target/X86'
Is this genuine, or has someone hacked the code and inserted some phishing attack into it?
As far as I know, there should be no reason to demand password during normal make execution (I am not doing make install yet).


From libors at gmail.com  Sun Jan  4 14:53:59 2009
From: libors at gmail.com (Libor Spacek)
Date: Sun, 04 Jan 2009 20:53:59 -0000
Subject: [LLVMdev] Phishing Attack?
Message-ID: <op.um82z9yt6yy425@ubangu>

This appears to be not as bad as I first feared. 

I had been using llvm previously on a remote machine and for some inexplicable reason a fresh compilation on my local machine wanted to make a connection to the remote one, in the context of: 

 Updated Intrinsics.gen because Intrinsics.gen.tmp changed significantly.

Though why this should be necessary, or useful,  is beyond me.


From jon at ffconsultancy.com  Sun Jan  4 13:58:24 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Sun, 4 Jan 2009 19:58:24 +0000
Subject: [LLVMdev] HLVM
In-Reply-To: <20d882600901040549i183a6339o34d8a493ba53abe9@mail.gmail.com>
References: <200901041336.35290.jon@ffconsultancy.com>
	<20d882600901040549i183a6339o34d8a493ba53abe9@mail.gmail.com>
Message-ID: <200901041958.24187.jon@ffconsultancy.com>

On Sunday 04 January 2009 13:49:52 HyperQuantum wrote:
> On Sun, Jan 4, 2009 at 2:36 PM, Jon Harrop <jon at ffconsultancy.com> wrote:
> > But I cannot find any code in LLVM that looks like it would have come
> > from HLVM.
>
> Don't know about the status of the project, but the code seems to be here:
>
> http://llvm.org/viewvc/llvm-project/    (in directory "hlvm")

Thanks. Looks like HLVM has not been updated for 16 months but VMKit is alive.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From clattner at apple.com  Sun Jan  4 13:58:53 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 4 Jan 2009 11:58:53 -0800
Subject: [LLVMdev] HLVM
In-Reply-To: <200901041336.35290.jon@ffconsultancy.com>
References: <200901041336.35290.jon@ffconsultancy.com>
Message-ID: <7F7F1A81-D6B2-4FBE-B5A3-55A071CDA69B@apple.com>


On Jan 4, 2009, at 5:36 AM, Jon Harrop wrote:

>
> What happened to the HLVM project? I understand it was intended to  
> be a
> high-level VM specifically for dynamic languages and this post  
> indicates that
> it was integrated into the LLVM project last year:
>
>  http://www.nabble.com/NEWS:-HLVM-merges-with-LLVM-td9627113.html
>
> But I cannot find any code in LLVM that looks like it would have  
> come from
> HLVM.

HLVM was checked into an llvm svn module, but it died shortly after  
that.  There are a couple of reasons: 1) the main author got busy and  
lost his time to work on it, 2) the goals of hlvm are very broad and  
poorly defined (possibly unachievable?) so no one else seems to have  
picked it up.

-Chris

From clattner at apple.com  Sun Jan  4 14:01:19 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 4 Jan 2009 12:01:19 -0800
Subject: [LLVMdev] Suggestion: Support union types in IR
In-Reply-To: <200901041307.57064.jon@ffconsultancy.com>
References: <d1b71f830812301241w4d1b49b9ke2a9d1d7cbb1fab3@mail.gmail.com>
	<200901022229.57568.jon@ffconsultancy.com>
	<A0A463E3-C592-4B24-873C-0F598726717D@apple.com>
	<200901041307.57064.jon@ffconsultancy.com>
Message-ID: <E478C105-9AB5-4E34-BAF3-A779B165DD28@apple.com>

On Jan 4, 2009, at 5:07 AM, Jon Harrop wrote:
>> Okay, so you're just talking about boxed vs unboxed discriminated
>> unions, or "by ref" vs "by value" discriminated unions.  Clearly the
>> LLVM IR support for "c style unions" would only be useful for
>> "unboxed" or "byvalue" discriminated unions.  That doesn't mean that
>> *your* specific uses would need them.
>
> Yes. I expect relatively few people would need C-style unions.

We obviously don't have them yet, so there hasn't been a driving need  
to make it happen.

>> If you're doing "by-ref" or "boxed" unions, then our current  
>> support should
>> already be sufficient.
>
> Yes, LLVM's existing support is fine.
>
> Incidentally, is there any way for LLVM users to vote on a "wish  
> list" in such
> a way that developers can see which features are most sought after?

Nope, but you can add things to the open projects list if you want.

-Chris

From clattner at apple.com  Sun Jan  4 14:47:02 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 4 Jan 2009 12:47:02 -0800
Subject: [LLVMdev] RFA: TREE_READONLY in LLVM-GCC
In-Reply-To: <198A9896-6114-45AD-A75F-2CA3B9A181E8@gmail.com>
References: <198A9896-6114-45AD-A75F-2CA3B9A181E8@gmail.com>
Message-ID: <5A1F4DC3-D90F-476B-AE6F-6266CE643498@apple.com>


On Jan 4, 2009, at 3:44 AM, Bill Wendling wrote:

> Hi LLVM-GCC hackers!
>
> I have a global variable that I want to mark as "TREE_READONLY" so
> that it will become a "constant" in LLVM IR. This is for the new
> blocks-related stuff, but that's not necessarily important for this
> question. In particular, I want to mark the "block_holder" created in
> "build_block_literal_tmp()" as read-only.
>
> My question to you is: Considering that LLVM-GCC uses only a small
> part of the GCC source base, what affect will marking the
> "block_holder" variable as TREE_READONLY have? Does LLVM-GCC run
> through code that looks at this flag and act differently before it
> generates the LLVM IR?

Hi Bill,

I think this change is fine and should go into the normal apple GCC as  
well.  Setting TREE_READONLY means that it can go into the "constant"  
section of the executable, go in ROM, etc.  This is the same as the  
llvm constant bit on globals.

-Chris

From libors at gmail.com  Sun Jan  4 16:22:15 2009
From: libors at gmail.com (Libor Spacek)
Date: Sun, 04 Jan 2009 22:22:15 -0000
Subject: [LLVMdev] "Phishing Attack" Solved
Message-ID: <op.um863di36yy425@ubangu>

Sorry about taking up the bandwith here, I have solved this interesting bug of my own now.
It turns out I had inadvertently inserted a shell script into my search path  which happened to have the same
name as one of the more obscure system programs used in the LLVM Makefile execution and this was trying to
connect to the remote machine instead of getting on with the job.... a warning against using short names for
executable shell scripts!


From isanbard at gmail.com  Sun Jan  4 16:44:17 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sun, 4 Jan 2009 14:44:17 -0800
Subject: [LLVMdev] RFA: TREE_READONLY in LLVM-GCC
In-Reply-To: <5A1F4DC3-D90F-476B-AE6F-6266CE643498@apple.com>
References: <198A9896-6114-45AD-A75F-2CA3B9A181E8@gmail.com>
	<5A1F4DC3-D90F-476B-AE6F-6266CE643498@apple.com>
Message-ID: <C657CD9A-E36A-4620-BB12-7AF99594CEA7@gmail.com>

On Jan 4, 2009, at 12:47 PM, Chris Lattner wrote:

> On Jan 4, 2009, at 3:44 AM, Bill Wendling wrote:
>
>> Hi LLVM-GCC hackers!
>>
>> I have a global variable that I want to mark as "TREE_READONLY" so
>> that it will become a "constant" in LLVM IR. This is for the new
>> blocks-related stuff, but that's not necessarily important for this
>> question. In particular, I want to mark the "block_holder" created in
>> "build_block_literal_tmp()" as read-only.
>>
>> My question to you is: Considering that LLVM-GCC uses only a small
>> part of the GCC source base, what affect will marking the
>> "block_holder" variable as TREE_READONLY have? Does LLVM-GCC run
>> through code that looks at this flag and act differently before it
>> generates the LLVM IR?
>
> Hi Bill,
>
> I think this change is fine and should go into the normal apple GCC as
> well.

I think Fariborz is resistant to this idea, but I can run it past him  
again.

> Setting TREE_READONLY means that it can go into the "constant"
> section of the executable, go in ROM, etc.  This is the same as the
> llvm constant bit on globals.
>
Okay. I'll make the patch. Thanks!

-bw


From evan.cheng at apple.com  Mon Jan  5 02:13:56 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 5 Jan 2009 00:13:56 -0800
Subject: [LLVMdev] Using CallingConvLower in ARM target
In-Reply-To: <F347CFB9-8B14-4BE9-8B57-856601D1E786@apple.com>
References: <305d6f60812270430xdf1ebb9gf6d99f94215ab66b@mail.gmail.com>
	<F347CFB9-8B14-4BE9-8B57-856601D1E786@apple.com>
Message-ID: <E94ECA83-B154-4807-B923-5D2FBDEA7D03@apple.com>

Hi Sandeep,

Dan's idea of adding CC custom lowering support is sound. Can you add  
that support?

Your patch looks good. I look forward to a more complete patch. But I  
do have a nitpick:

Index: include/llvm/CodeGen/CallingConvLower.h
===================================================================
--- include/llvm/CodeGen/CallingConvLower.h	(revision 60966)
+++ include/llvm/CodeGen/CallingConvLower.h	(working copy)
@@ -32,7 +32,8 @@
      Full,   // The value fills the full location.
      SExt,   // The value is sign extended in the location.
      ZExt,   // The value is zero extended in the location.
-    AExt    // The value is extended with undefined upper bits.
+    AExt,   // The value is extended with undefined upper bits.
+    BCnv    // The value is bitconverted in the location
      // TODO: a subset of the value is in the location.
    };

How about BCvt instead of BCnv? Also, please substitue bit-convert for  
bitconvert in comments.

Thanks,

Evan

On Jan 3, 2009, at 11:46 AM, Dan Gohman wrote:

>
> On Dec 27, 2008, at 4:30 AM, Sandeep Patel wrote:
>
>> Attached is a prototype patch that uses CCState to lower RET nodes in
>> the ARM target. Lowering CALL nodes will come later.
>>
>> This patch does not handle f64 and i64 types. For these types, it
>> would be ideal to request the conversions below:
>
> i64 isn't Legal on ARM, so it should already be handled.
>
>>
>>
>> def RetCC_ARM_APCS : CallingConv<[
>> CCIfType<[f32], CCBitConvertToType<i32>>,
>> CCIfType<[f64], CCBitConvertToType<i64>>,
>> CCIfType<[i64], CCExtractElements<2, i32>>,
>>
>> CCIfType<[i32], CCAssignToReg<[R0, R1]>>
>> ]>;
>>
>> The problem is that i64 handling requires splitting into 2 x i32
>> registers. I am not sure how to build CCExtractElements as shown. The
>> current organization of CCState::AnalyzeReturn does not allow for
>> reissuing of the RET with an altered set of operands which is the
>> solution used elsewhere. Can anyone suggest a better way to express
>> this lowering?
>
> One problem with this approach is that since i64 isn't legal, the
> bitcast would require custom C++ code in the ARM target to
> handle properly.  It might make sense to introduce something
> like
>
>    CCIfType<[f64], CCCustom>
>
> where CCCustom is a new entity that tells the calling convention
> code to to let the target do something not easily representable
> in the tablegen minilanguage.
>
> Dan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From evan.cheng at apple.com  Mon Jan  5 02:14:59 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 5 Jan 2009 00:14:59 -0800
Subject: [LLVMdev] hi, llvm-gcc  deal with va_arg() by word alignment.
In-Reply-To: <364780.96994.qm@web92402.mail.cnh.yahoo.com>
References: <364780.96994.qm@web92402.mail.cnh.yahoo.com>
Message-ID: <CA6545C7-28BC-49D9-A7EA-AA918641472C@apple.com>

Is your llvm-gcc frontend targeting x86? It does not generate target  
neutral bitcode.

Evan

On Jan 4, 2009, at 3:11 AM, ???? wrote:

> hi,
>      I am porting llvm to our embedded cpu.
> By my abi, long long type is aligned by 8 bytes.
> But now llvm-gcc frontend follows x86 abi, generate
> word-alignment LLVM-IR for va_arg().
>
>    In some degree, llvm-gcc frontend depends on targets.
> The best solution is llvm-gcc can create va_arg node,
> I can lower it at the backend.
>
>    Who can give a temporary solution to make frontend can
> create 8 byte alignment code for long long type?
>
> Thanks
>
>     renkun.
>
> ?????????????????????????????????? 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090105/4482352b/attachment.html 

From baldrick at free.fr  Mon Jan  5 04:03:06 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 5 Jan 2009 11:03:06 +0100
Subject: [LLVMdev] RFA: TREE_READONLY in LLVM-GCC
In-Reply-To: <5A1F4DC3-D90F-476B-AE6F-6266CE643498@apple.com>
References: <198A9896-6114-45AD-A75F-2CA3B9A181E8@gmail.com>
	<5A1F4DC3-D90F-476B-AE6F-6266CE643498@apple.com>
Message-ID: <200901051103.07098.baldrick@free.fr>

Hi Chris,

> I think this change is fine and should go into the normal apple GCC as  
> well.  Setting TREE_READONLY means that it can go into the "constant"  
> section of the executable, go in ROM, etc.  This is the same as the  
> llvm constant bit on globals.

for this I think it has to be static as well as readonly.

Ciao,

Duncan.

From baldrick at free.fr  Mon Jan  5 04:37:26 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 5 Jan 2009 11:37:26 +0100
Subject: [LLVMdev] hi, llvm-gcc  deal with va_arg() by word alignment.
In-Reply-To: <364780.96994.qm@web92402.mail.cnh.yahoo.com>
References: <364780.96994.qm@web92402.mail.cnh.yahoo.com>
Message-ID: <200901051137.26368.baldrick@free.fr>

Hi,

>      I am porting llvm to our embedded cpu.
> By my abi, long long type is aligned by 8 bytes.
> But now llvm-gcc frontend follows x86 abi, generate 
> word-alignment LLVM-IR for va_arg().

if llvm-gcc thinks the alignment is 4 but it is not then you
will get more problems than just with va_arg.  Why not teach
llvm-gcc about your target?

Ciao,

Duncan.

From isanbard at gmail.com  Mon Jan  5 05:42:16 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 5 Jan 2009 03:42:16 -0800
Subject: [LLVMdev] RFA: TREE_READONLY in LLVM-GCC
In-Reply-To: <200901051103.07098.baldrick@free.fr>
References: <198A9896-6114-45AD-A75F-2CA3B9A181E8@gmail.com>
	<5A1F4DC3-D90F-476B-AE6F-6266CE643498@apple.com>
	<200901051103.07098.baldrick@free.fr>
Message-ID: <EB787403-6A36-4575-8E57-6B2B9FDFA6C5@gmail.com>

I did mark it as TREE_CONSTANT. Is that enough?

-bw

On Jan 5, 2009, at 2:03 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Chris,
>
>> I think this change is fine and should go into the normal apple GCC  
>> as
>> well.  Setting TREE_READONLY means that it can go into the "constant"
>> section of the executable, go in ROM, etc.  This is the same as the
>> llvm constant bit on globals.
>
> for this I think it has to be static as well as readonly.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From baldrick at free.fr  Mon Jan  5 06:41:00 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 5 Jan 2009 13:41:00 +0100
Subject: [LLVMdev] RFA: TREE_READONLY in LLVM-GCC
In-Reply-To: <EB787403-6A36-4575-8E57-6B2B9FDFA6C5@gmail.com>
References: <198A9896-6114-45AD-A75F-2CA3B9A181E8@gmail.com>
	<200901051103.07098.baldrick@free.fr>
	<EB787403-6A36-4575-8E57-6B2B9FDFA6C5@gmail.com>
Message-ID: <200901051341.00617.baldrick@free.fr>

On Monday 05 January 2009 12:42:16 Bill Wendling wrote:
> I did mark it as TREE_CONSTANT. Is that enough?

No idea - if it works I guess it was enough :)  I was
actually thinking of TREE_STATIC:

/* In a VAR_DECL, nonzero means allocate static storage.
   In a FUNCTION_DECL, nonzero if function has been defined.
   In a CONSTRUCTOR, nonzero means allocate static storage.

   ??? This is also used in lots of other nodes in unclear ways which
   should be cleaned up some day.  */
#define TREE_STATIC(NODE) ((NODE)->common.static_flag)

Ciao,

Duncan.

From criswell at cs.uiuc.edu  Mon Jan  5 09:32:04 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Mon, 5 Jan 2009 09:32:04 -0600
Subject: [LLVMdev] link problem with llvm-pass
In-Reply-To: <B35FBC68-513F-4FC6-96C4-92B29F769B24@arcor.de>
References: <B2E52147-1E2B-4B11-8846-84EBFC8142DA@arcor.de>	<4960D0C2.8000809@uiuc.edu>
	<B35FBC68-513F-4FC6-96C4-92B29F769B24@arcor.de>
Message-ID: <496227F4.8020400@cs.uiuc.edu>

Nico wrote:
> Dear John,
>
> thanks! I was irritated by the path of the header file/declaration.
> It is not like the definition in a subdirectory. Sorry my fault.
>
> Is there an overview where classes and link options are mapped to each  
> other?
>   
If there is one, I do not know of it.

My method for determining which library to link is twofold:

1) Since I have a general understanding of LLVM's libraries, I can make 
educated guesses if I know what the pass does.  If it's an 
inter-procedural analysis pass, then it's in LLVMipa.  If it's something 
to do with code generation, then it's probably in LLVMCodeGen.  There's 
a list of the libraries at 
http://llvm.org/docs/UsingLibraries.html#descriptions.

2) If that doesn't work, I use xargs/grep to search the source base for 
the class's implementation.  I then look at the Makefile in the same 
directory to figure out which library it's being compiled into.

I know this may not seem convenient, but it actually works pretty well, 
and the longer you work with LLVM, the easier it gets.

-- John T.

> Kind regards,
> Nico
>
> On Jan 4, 2009, at 4:07 PM, John Criswell wrote:
>
>   


From filcab at gmail.com  Mon Jan  5 10:12:32 2009
From: filcab at gmail.com (Filipe Cabecinhas)
Date: Mon, 5 Jan 2009 16:12:32 +0000
Subject: [LLVMdev] Avoiding jump (branch) instructions in a LLVM
	JavaScript backend
In-Reply-To: <3db207a40901040929v234b15bs1d323349d1399c72@mail.gmail.com>
References: <3db207a40901040929v234b15bs1d323349d1399c72@mail.gmail.com>
Message-ID: <5FDE4BA0-A61D-42E3-8F21-D5AFF92ABB19@gmail.com>

Hi,

Some time ago a friend of mine made a conversion script from AGI (an  
early virtual machine) to Javascript, including rudimentary goto  
support. He says it's not the best code in the world but you can take  
a look around: http://web.ist.utl.pt/~antonio.afonso/agi/logic.phps.  
There's an AGI emulator that plays Leisure Suite Larry a directory  
above ;-)

You could also convert the LLVM's IR (SSA) to CPS and then you could  
just directly emit the javascript code :-P

Regards,

   F

On 4 Jan, 2009, at 17:29, Charles Ying wrote:

> Hello llvm-dev,
>
> I've been hacking on a JavaScript backend to LLVM, starting with the  
> CBackend as base.
>
> Sadly, JavaScript does not support a "goto" style of jump  
> instruction, making it "tricky" to code generate a jump instruction.
>
> What might you recommend for avoiding jump instructions? Is there a  
> transformation for something like this or any other ideas? The only  
> solution I see at the moment is to write a small VM execution loop  
> in JavaScript, but I was hoping that there might be other solutions.
>
> Thanks!
> Charles
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090105/cb04fb21/attachment.html 

From dpatel at apple.com  Mon Jan  5 10:31:04 2009
From: dpatel at apple.com (Devang Patel)
Date: Mon, 5 Jan 2009 08:31:04 -0800
Subject: [LLVMdev] how to get the llvm IR from C source code?
In-Reply-To: <495311D6.1020407@mxc.ca>
References: <e6bba8fe0812242030x4c54f48kcb6b1a0e45394f6a@mail.gmail.com>
	<000c01c9664c$4d7f3620$e87da260$@edu> <495311D6.1020407@mxc.ca>
Message-ID: <B2965FE6-3606-431D-BFD5-2BA75E9CB115@apple.com>


On Dec 24, 2008, at 8:53 PM, Nick Lewycky wrote:

> Keun Soo Yim wrote:
>>
>> Please run?
>>
>> $ llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc
>>
>> $ llvm-dis < hello.bc > hello.ll
>>
>> The first command is to generate a byte code
>>
>> and second is to translate the bytecode to a readable form.
>>
> llvm-gcc can emit the textual form directly too:
>
> llvm-gcc -O2 -emit-llvm hello.c -S -o hello.ll
> llvm-gcc -O2 -emit-llvm hello.c -S -o -
>
> the latter will print it to standard out.

BTW,  -O2 or any other optimization options can be omitted here if you  
intend to get raw (unoptimized) IR.
-
Devang





From dpatel at apple.com  Mon Jan  5 10:38:33 2009
From: dpatel at apple.com (Devang Patel)
Date: Mon, 5 Jan 2009 08:38:33 -0800
Subject: [LLVMdev] Questions on Parallelism and Data Dependence Analysis
In-Reply-To: <430170143.10735@zju.edu.cn>
References: <430170143.10735@zju.edu.cn>
Message-ID: <0541DAB5-7BD4-4F5F-BB4D-9C217EFB774C@apple.com>


On Dec 24, 2008, at 6:11 PM, Wenzhi Tao wrote:

> 2. Can I use the functions provided by llvm to get the real data  
> dependence(Read After Write) info on basic block level directly?
>    In other words, can I get the task graph(node: task viewed as  
> basic block or more coarse grain, edge: real data dependence)
>    from sequential program using llvm to explore task-level  
> parallelism by some proposed task scheduling algorithm?
>


It is possible. Wojciech Matyjewicz has done this.  See relevant  
thread (with attached patch)  http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016616.html

LLVM will benefit if data dependence analysis support is integrated in  
llvm mainline sources.

-
Devang




From mdevan.foobar at gmail.com  Mon Jan  5 11:34:29 2009
From: mdevan.foobar at gmail.com (Mahadevan R)
Date: Mon, 5 Jan 2009 23:04:29 +0530
Subject: [LLVMdev] Small doc fix.
Message-ID: <c8033d570901050934ncc5cc91j452afa9b200d2773@mail.gmail.com>

Hi,

The LLVM Assembly Language Reference [1] incorrectly states that the
prefix used for dll{import,export} is _imp__; it is actually __imp_.
The attached patch fixes this.

Thanks & Regards,
-Mahadevan.

[1] file:///home/mdevan/llvm/docs/LangRef.html#linkage
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc-dllimport-prefix.patch
Type: text/x-diff
Size: 1098 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090105/78ae396e/attachment.bin 

From brukman at gmail.com  Mon Jan  5 13:37:01 2009
From: brukman at gmail.com (Misha Brukman)
Date: Mon, 5 Jan 2009 14:37:01 -0500
Subject: [LLVMdev] Unit test patch, updated
In-Reply-To: <65DD53BE-BF0C-4C0C-9A59-86C0757B115B@apple.com>
References: <d1b71f830812301307w7dd9377fv1c19d927c02d1f40@mail.gmail.com>
	<f88b89a50812301432i128d08efud4bdbbc4fcf7a390@mail.gmail.com>
	<f88b89a50812301440o68c0b8afw9db6ad8642160449@mail.gmail.com>
	<d1b71f830812301454h73f8f4few2e96f1be35a18677@mail.gmail.com>
	<EC3652F4-03DB-48E0-B96C-7BBBFBF2703A@apple.com>
	<f88b89a50812311827s4dc2b610gd0982675ba654691@mail.gmail.com>
	<495C8B11.7020409@gmail.com>
	<65DD53BE-BF0C-4C0C-9A59-86C0757B115B@apple.com>
Message-ID: <f88b89a50901051137w54d0892bg3f3a1cc226721fbe@mail.gmail.com>

2009/1/1 Chris Lattner <clattner at apple.com>

>  On Jan 1, 2009, at 1:21 AM, Talin wrote:
> > I'm thinking that getting unit tests for the classes in ADT should
> > be an early goal.
>
> Can I suggest the AP[S]Int class?  If you look in llvm/test/Integer
> you'll see a whole bunch of tests that really want to be unit tests
> but that aren't.  :(


Chris, do you mean *all* the .ll files in that dir should become unittests,
or are you talking about some specific files that should be unittests, and
others that should stay as llvm-as/llvm-dis tests?

I'm assuming a##.* are prime candidates, what about the others?  Are the
double llvm-as/llvm-dis tests about bitcode printing/parsing or are they
really testing some auto-simplification built-in to the APSInt class?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090105/abe1854f/attachment.html 

From criswell at cs.uiuc.edu  Mon Jan  5 14:45:34 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Mon, 5 Jan 2009 14:45:34 -0600
Subject: [LLVMdev] Potential Downtime of LLVM Server on Jan. 6
In-Reply-To: <494C725F.9040606@uiuc.edu>
References: <494C725F.9040606@uiuc.edu>
Message-ID: <4962716E.706@cs.uiuc.edu>

Dear All,

Just a reminder that some work on our heating/cooling system will be 
done tomorrow between 8 am - noon Central time.  If server room 
temperatures get too high, the IT staff will start shutting machines down.

Since the LLVM server may need to be shut down on short notice, I can't 
guarantee that we can give you advance warning of it going offline.  I 
strongly urge everyone to avoid using SVN during 8-12 Central time tomorrow.

Thanks.

-- John T.

John Criswell wrote:
> Dear LLVMers,
>
> What: Potential Downtime of LLVM Web/SVN Server
>
> When: January 6, 2009 from 8:00 am Central time to 12:00 pm Central time 
> (4 hours)
>
> Why:
> On January 6, 2009, some maintenance will be done on the heating/cooling 
> system of Siebel Center (the building in which the LLVM web/SVN server 
> is located).  The cooling system will be turned off, and it's possible 
> that temperatures may rise in the server rooms.  If they rise too high, 
> the CS IT staff will shut down systems to prevent them from being damaged.
>
> Recommendations:
> My current recommendation is to avoid using SVN during the 4 hours of 
> maintenance.  With the number of machines maintained by our IT staff and 
> the fact that people are on vacation, I cannot guarantee that we can 
> provide advanced warning if/when the LLVM server is shut down.
>
> The last time they did work on the cooling system, no servers were shut 
> down.  However, you never know what will happen, so I recommend erring 
> on the side of caution.
>
> -- John T.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From clattner at apple.com  Mon Jan  5 16:30:33 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 5 Jan 2009 14:30:33 -0800
Subject: [LLVMdev] Unit test patch, updated
In-Reply-To: <f88b89a50901051137w54d0892bg3f3a1cc226721fbe@mail.gmail.com>
References: <d1b71f830812301307w7dd9377fv1c19d927c02d1f40@mail.gmail.com>
	<f88b89a50812301432i128d08efud4bdbbc4fcf7a390@mail.gmail.com>
	<f88b89a50812301440o68c0b8afw9db6ad8642160449@mail.gmail.com>
	<d1b71f830812301454h73f8f4few2e96f1be35a18677@mail.gmail.com>
	<EC3652F4-03DB-48E0-B96C-7BBBFBF2703A@apple.com>
	<f88b89a50812311827s4dc2b610gd0982675ba654691@mail.gmail.com>
	<495C8B11.7020409@gmail.com>
	<65DD53BE-BF0C-4C0C-9A59-86C0757B115B@apple.com>
	<f88b89a50901051137w54d0892bg3f3a1cc226721fbe@mail.gmail.com>
Message-ID: <82F40501-F7FA-4397-994E-30F822F5472F@apple.com>


On Jan 5, 2009, at 11:37 AM, Misha Brukman wrote:

> 2009/1/1 Chris Lattner <clattner at apple.com>
> On Jan 1, 2009, at 1:21 AM, Talin wrote:
> > I'm thinking that getting unit tests for the classes in ADT should
> > be an early goal.
>
> Can I suggest the AP[S]Int class?  If you look in llvm/test/Integer
> you'll see a whole bunch of tests that really want to be unit tests
> but that aren't.  :(
>
> Chris, do you mean *all* the .ll files in that dir should become  
> unittests, or are you talking about some specific files that should  
> be unittests, and others that should stay as llvm-as/llvm-dis tests?
>
> I'm assuming a##.* are prime candidates, what about the others?  Are  
> the double llvm-as/llvm-dis tests about bitcode printing/parsing or  
> are they really testing some auto-simplification built-in to the  
> APSInt class?

Oh, sorry, I just meant the "a*" tests, which are basically doing  
constant folding (but not checking the results!)

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090105/4a9ec14a/attachment.html 

From alex.lavoro.propio at gmail.com  Mon Jan  5 16:32:14 2009
From: alex.lavoro.propio at gmail.com (Alex)
Date: Mon, 5 Jan 2009 23:32:14 +0100
Subject: [LLVMdev] Look-ahead instruction selection
Message-ID: <4d77c5f20901051432v7fa453ecy62ff61101d92efc5@mail.gmail.com>

In .td file, if the pattern to match the DAG is:

(vector_shuffle (mul build_vector, build_vector))

is it possible to return 'mul' (SDNode*) instead of returning the first
'vector_shuffle'?

It seems to me that the default instruction selector can only return the
'root' node of the pattern.

Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090105/e8da2183/attachment.html 

From eli.friedman at gmail.com  Mon Jan  5 16:55:40 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 5 Jan 2009 14:55:40 -0800
Subject: [LLVMdev] Look-ahead instruction selection
In-Reply-To: <4d77c5f20901051432v7fa453ecy62ff61101d92efc5@mail.gmail.com>
References: <4d77c5f20901051432v7fa453ecy62ff61101d92efc5@mail.gmail.com>
Message-ID: <f5aa3e9b0901051455q4e2a8514yeeffccc96f9771dd@mail.gmail.com>

On Mon, Jan 5, 2009 at 2:32 PM, Alex <alex.lavoro.propio at gmail.com> wrote:
> In .td file, if the pattern to match the DAG is:
>
> (vector_shuffle (mul build_vector, build_vector))
>
> is it possible to return 'mul' (SDNode*) instead of returning the first
> 'vector_shuffle'?
>
> It seems to me that the default instruction selector can only return the
> 'root' node of the pattern.

The simplest thing to do is to map a vector_shuffle to another
vector_shuffle; there shouldn't be any issues with that, I think.  Is
there some reason you don't want to write it that way?

Note that you can use a custom PatFrag to match an instruction with a
single use... see, for example, "and_su" in X86InstrInfo.td.

-Eli

From dalej at apple.com  Mon Jan  5 16:59:09 2009
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 5 Jan 2009 14:59:09 -0800
Subject: [LLVMdev] [llvm-commits] [llvm-gcc-4.2] r61493 - in
	/llvm-gcc-4.2/trunk/gcc: ipa-inline.c passes.c
In-Reply-To: <200812301315.mBUDFiM7005690@zion.cs.uiuc.edu>
References: <200812301315.mBUDFiM7005690@zion.cs.uiuc.edu>
Message-ID: <EEB7A022-84DB-475B-8A66-41438159D51C@apple.com>


On Dec 30, 2008, at 5:15 AMPST, Duncan Sands wrote:

> Author: baldrick
> Date: Tue Dec 30 07:15:15 2008
> New Revision: 61493
>
> URL: http://llvm.org/viewvc/llvm-project?rev=61493&view=rev
> Log:
> Now that LLVM handles always_inline itself, run
> gcc's early inliner rather than the full inliner.
> This does a lot less inlining, and partially
> fixes PR3232.  On the other hand, this may cause
> regressions with webkit and friends (PR2353),
> but there's only one way to find out!

This causes a regression of approximately 10% when cpp is built with  
llvm-gcc.

I'm not sure what the criteria for putting this in should be; maybe we  
should discuss that before you try again.  I don't think "no  
regressions on anything" is reasonable; the compiler doesn't have  
enough information to do a perfect job of inlining, so some things are  
inevitably going to regress.  I do think cpp is one of the things that  
shouldn't regress, though.


From alex.lavoro.propio at gmail.com  Mon Jan  5 19:38:55 2009
From: alex.lavoro.propio at gmail.com (Alex)
Date: Mon, 5 Jan 2009 17:38:55 -0800 (PST)
Subject: [LLVMdev] Look-ahead instruction selection
In-Reply-To: <f5aa3e9b0901051455q4e2a8514yeeffccc96f9771dd@mail.gmail.com>
References: <4d77c5f20901051432v7fa453ecy62ff61101d92efc5@mail.gmail.com>
	<f5aa3e9b0901051455q4e2a8514yeeffccc96f9771dd@mail.gmail.com>
Message-ID: <21301588.post@talk.nabble.com>


Maybe I didn't describe the question very well.

I want to match these patterns:

  (and (mul node:$val0, node:$val1))
  (and (add node:$val0, node:$val1))
  (and (sub node:$val0, node:$val1))
  (and (udiv node:$val0, node:$val1))

into "four" different machines instructions, respectively:

  MUL_AND
  ADD_AND
  SUB_AND
  UDIV_AND

That is, this machine is capable of doing an arithmetic operation and a
"following" AND operation by a single machine instruction. There are a lot
of arithmetic operations but they can only be combined with a following AND
operation. It's important that only the following AND can be merged/combined
with the arithmetic operation. The pattern:

   (mul node:$val0, (AND))

can _not_ be matched.

The problem is, it seems to me, that the instruction returned in these
patterns is always the AND, which is the "root" of these partial DAG
pattern, instead of the arithmetic operation. The LLVM instruction selector
is capable of doing this "look ahead" matching? What is the suggested way to
do this?


PS: For GPU guys, I am trying to match the writemask operation after an
arithmetic operation.

  



Eli Friedman-2 wrote:
> 
> On Mon, Jan 5, 2009 at 2:32 PM, Alex <alex.lavoro.propio at gmail.com> wrote:
>> In .td file, if the pattern to match the DAG is:
>>
>> (vector_shuffle (mul build_vector, build_vector))
>>
>> is it possible to return 'mul' (SDNode*) instead of returning the first
>> 'vector_shuffle'?
>>
>> It seems to me that the default instruction selector can only return the
>> 'root' node of the pattern.
> 
> The simplest thing to do is to map a vector_shuffle to another
> vector_shuffle; there shouldn't be any issues with that, I think.  Is
> there some reason you don't want to write it that way?
> 
> Note that you can use a custom PatFrag to match an instruction with a
> single use... see, for example, "and_su" in X86InstrInfo.td.
> 
> -Eli
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 

-- 
View this message in context: http://www.nabble.com/Look-ahead-instruction-selection-tp21300925p21301588.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From mrs at apple.com  Mon Jan  5 20:14:06 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 5 Jan 2009 18:14:06 -0800
Subject: [LLVMdev] llvm doesn't build
Message-ID: <893740A1-25B3-4CE3-83B5-64698AC30507@apple.com>

:-(

$ svn up .
Updated to revision 61782.
$ make
Makefile:119: *** target file `unittests' has both : and :: entries.   
Stop.


From mrs at apple.com  Mon Jan  5 20:19:27 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 5 Jan 2009 18:19:27 -0800
Subject: [LLVMdev] llvm doesn't build
In-Reply-To: <893740A1-25B3-4CE3-83B5-64698AC30507@apple.com>
References: <893740A1-25B3-4CE3-83B5-64698AC30507@apple.com>
Message-ID: <CBBBCE33-2689-4304-9FDA-892435C8190F@apple.com>

On Jan 5, 2009, at 6:14 PM, Mike Stump wrote:

> :-(
>
> $ svn up .
> Updated to revision 61782.
> $ make
> Makefile:119: *** target file `unittests' has both : and :: entries.
> Stop.

Curious, a rebuild in clang, then another at the toplevel got it  
building again.  Seems like the Makefile is missing out on some bits.

From isanbard at gmail.com  Mon Jan  5 20:20:46 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 5 Jan 2009 18:20:46 -0800
Subject: [LLVMdev] llvm doesn't build
In-Reply-To: <893740A1-25B3-4CE3-83B5-64698AC30507@apple.com>
References: <893740A1-25B3-4CE3-83B5-64698AC30507@apple.com>
Message-ID: <16e5fdf90901051820x3726e831rdcd77617c4e3d698@mail.gmail.com>

On Mon, Jan 5, 2009 at 6:14 PM, Mike Stump <mrs at apple.com> wrote:
> :-(
>
> $ svn up .
> Updated to revision 61782.
> $ make
> Makefile:119: *** target file `unittests' has both : and :: entries.
> Stop.

Do a clean re-configure and make.

-bw

From isanbard at gmail.com  Mon Jan  5 21:35:10 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 5 Jan 2009 19:35:10 -0800
Subject: [LLVMdev] Look-ahead instruction selection
In-Reply-To: <21301588.post@talk.nabble.com>
References: <4d77c5f20901051432v7fa453ecy62ff61101d92efc5@mail.gmail.com>
	<f5aa3e9b0901051455q4e2a8514yeeffccc96f9771dd@mail.gmail.com>
	<21301588.post@talk.nabble.com>
Message-ID: <6FF71EA3-11E8-4DF8-8740-EF7456C7E957@gmail.com>

On Jan 5, 2009, at 5:38 PM, [Alex] wrote:

> Maybe I didn't describe the question very well.
>
> I want to match these patterns:
>
>  (and (mul node:$val0, node:$val1))
>  (and (add node:$val0, node:$val1))
>  (and (sub node:$val0, node:$val1))
>  (and (udiv node:$val0, node:$val1))
>
> into "four" different machines instructions, respectively:
>
>  MUL_AND
>  ADD_AND
>  SUB_AND
>  UDIV_AND
>
> That is, this machine is capable of doing an arithmetic operation  
> and a
> "following" AND operation by a single machine instruction. There are  
> a lot
> of arithmetic operations but they can only be combined with a  
> following AND
> operation. It's important that only the following AND can be merged/ 
> combined
> with the arithmetic operation. The pattern:
>
>   (mul node:$val0, (AND))
>
> can _not_ be matched.
>
> The problem is, it seems to me, that the instruction returned in these
> patterns is always the AND, which is the "root" of these partial DAG
> pattern, instead of the arithmetic operation. The LLVM instruction  
> selector
> is capable of doing this "look ahead" matching? What is the  
> suggested way to
> do this?
>
Have you tried using special patterns for these instructions? If you  
check in X86InstrInfo.td, there are some like this:

def : Pat<(store (or (srl (loadi16 addr:$dst), (i8 (trunc CX:$amt))),
                      (shl GR16:$src2, (i8 (trunc (sub 16, CX:$amt))))),
                  addr:$dst),
           (SHRD16mrCL addr:$dst, GR16:$src2)>;

You might have some luck with something along these lines:

def : Pat<(and (mul node:$val0, node:$val1), ...),
           (MUL_AND node:$val0, node:$val1)>;

(The pattern you have above seems incomplete because it lacks an extra  
"node:$val#" for the "and" part after the "mul" part.)

-bw

From isanbard at gmail.com  Mon Jan  5 21:35:45 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 5 Jan 2009 19:35:45 -0800
Subject: [LLVMdev] RFA: TREE_READONLY in LLVM-GCC
In-Reply-To: <200901051341.00617.baldrick@free.fr>
References: <198A9896-6114-45AD-A75F-2CA3B9A181E8@gmail.com>
	<200901051103.07098.baldrick@free.fr>
	<EB787403-6A36-4575-8E57-6B2B9FDFA6C5@gmail.com>
	<200901051341.00617.baldrick@free.fr>
Message-ID: <26D27966-F304-48C3-90C3-AD65B5C8D49B@gmail.com>

On Jan 5, 2009, at 4:41 AM, Duncan Sands wrote:

> On Monday 05 January 2009 12:42:16 Bill Wendling wrote:
>> I did mark it as TREE_CONSTANT. Is that enough?
>
> No idea - if it works I guess it was enough :)  I was
> actually thinking of TREE_STATIC:
>
I went ahead and just kept it as "TREE_CONSTANT". :-)

-bw


From scooter.phd at gmail.com  Mon Jan  5 22:27:50 2009
From: scooter.phd at gmail.com (Scott Michel)
Date: Mon, 5 Jan 2009 20:27:50 -0800
Subject: [LLVMdev] recent buildbot failure
Message-ID: <258cd3200901052027y20276bf0j15fc8aed558b6093@mail.gmail.com>

FWIW, I'm actually not to blame for build 1327's failure. There's no CellSPU
test to XFAIL.


-scooter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090105/cd0f26a1/attachment.html 

From manoel at fonetica.com.br  Tue Jan  6 05:02:51 2009
From: manoel at fonetica.com.br (=?ISO-8859-1?Q?Manoel=20Teixeira?=)
Date: Tue,  6 Jan 2009 09:02:51 -0200
Subject: [LLVMdev] LLVM Optmizer
Message-ID: <20090106110251.4851.qmail@hm885.locaweb.com.br>


 The following C code :
#include <stdio.h>
#include <stdlib.h>

int  TESTE2( int  parami , int paraml ,double  paramd  ) 
{
  int varx=0,vary;
  int nI =0;
  //varx= parami;
    if( parami > 0  ) 
	{
   varx = parami;
   vary = varx + 1;
	}
  else
  {
   varx = vary + 1;
   vary = paraml;
  }
varx = varx + parami + paraml;
  for( nI = 1 ;   nI <=  paraml; nI++)
  {
    varx =  varx + parami + 1 ;
	vary =  varx + nI;
  }
  vary = varx + 5;
  varx = vary + paraml;
 
return varx ;
}

Generates the IR :
; ModuleID = '/tmp/webcompile/_9908_0.bc'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"

define i32 @TESTE2(i32 %parami, i32 %paraml, double %paramd) nounwind readnone {
entry:
	%0 = shl i32 %parami, 1		; <i32> [#uses=1]
	%varx.110 = add i32 %0, %paraml		; <i32> [#uses=2]
	%1 = icmp slt i32 %paraml, 1		; <i1> [#uses=1]
	br i1 %1, label %bb5, label %bb3

bb3:		; preds = %bb3, %entry
	%indvar = phi i32 [ %indvar.next, %bb3 ], [ 0, %entry ]		; <i32> [#uses=3]
	%2 = add i32 %indvar, 2		; <i32> [#uses=1]
	%3 = icmp sgt i32 %2, %paraml		; <i1> [#uses=1]
	%indvar.next = add i32 %indvar, 1		; <i32> [#uses=1]
	br i1 %3, label %bb5.loopexit, label %bb3

bb5.loopexit:		; preds = %bb3
	%tmp14 = add i32 %parami, 1		; <i32> [#uses=1]
	%tmp15 = mul i32 %indvar, %tmp14		; <i32> [#uses=1]
	%varx.111 = add i32 %tmp15, %varx.110		; <i32> [#uses=1]
	%4 = add i32 %varx.111, %parami		; <i32> [#uses=1]
	%phitmp = add i32 %4, 1		; <i32> [#uses=1]
	br label %bb5

bb5:		; preds = %bb5.loopexit, %entry
	%varx.1.lcssa = phi i32 [ %varx.110, %entry ], [ %phitmp, %bb5.loopexit ]		; <i32> [#uses=1]
	%5 = add i32 %paraml, 5		; <i32> [#uses=1]
	%6 = add i32 %5, %varx.1.lcssa		; <i32> [#uses=1]
	ret i32 %6
}


While the MSVC generates the assemble :
PUBLIC	_TESTE
; Function compile flags: /Ogtpy
; File c:\msys\1.0\home\mteixeira\testeadvpl.c
;	COMDAT _TESTE
_TEXT	SEGMENT
_parami$ = 8						; size = 4
_paraml$ = 12						; size = 4
_paramd$ = 16						; size = 8
_TESTE	PROC						; COMDAT

; 6    :   int varx=0,vary;
; 7    :   int nI =0;
; 8    :   //varx= parami;
; 9    :     if( parami > 0  ) 

	mov	ecx, DWORD PTR _parami$[esp-4]

; 10   : 	{
; 11   :    varx = parami;
; 12   :    vary = 0;
; 13   : 	}
; 14   :   else
; 15   :   {
; 16   :    varx = 0;
; 17   :    vary = paraml;
; 18   :   }
; 19   :   for( nI = 1 ;   nI <=  paraml; nI++)

	mov	edx, DWORD PTR _paraml$[esp-4]
	xor	eax, eax
	test	ecx, ecx
	setle	al
	sub	eax, 1
	and	eax, ecx
	cmp	edx, 1
	jl	SHORT $LN3 at TESTE
	add	ecx, 1
	imul	ecx, edx
	add	eax, ecx
$LN3 at TESTE:

; 20   :   {
; 21   :     varx =  varx + parami + 1 ;
; 22   : 	vary =  varx + nI;
; 23   :   }
; 24   : 
; 25   : return varx ;
; 26   : }

	ret	0
_TESTE	ENDP
_TEXT	ENDS

 Running the same code, the objetc generated with MSVC is 600 times faster than that generate with the LLVM compiler
 Is threre any way to get the same optimzation with the LLVM?


Manoel Teixeira




From criswell at cs.uiuc.edu  Tue Jan  6 09:38:23 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Tue, 6 Jan 2009 09:38:23 -0600
Subject: [LLVMdev] Potential Downtime of LLVM Server on Jan. 6
In-Reply-To: <4962716E.706@cs.uiuc.edu>
References: <494C725F.9040606@uiuc.edu> <4962716E.706@cs.uiuc.edu>
Message-ID: <49637AEF.8070107@cs.uiuc.edu>

Dear All,

The scheduled time for the heating/cooling system maintenance that was 
given to me earlier was wrong.  The correct time for the maintenance 
will be 12:00 pm - 4:00 pm Central time.

So, go ahead and use SVN and Bugzilla this morning, but I strongly urge 
that you not use them from 12-4 Central time today.

-- John T.

John Criswell wrote:
> Dear All,
>
> Just a reminder that some work on our heating/cooling system will be 
> done tomorrow between 8 am - noon Central time.  If server room 
> temperatures get too high, the IT staff will start shutting machines down.
>
> Since the LLVM server may need to be shut down on short notice, I can't 
> guarantee that we can give you advance warning of it going offline.  I 
> strongly urge everyone to avoid using SVN during 8-12 Central time tomorrow.
>
> Thanks.
>
> -- John T.
>
>   


From criswell at cs.uiuc.edu  Tue Jan  6 12:13:30 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Tue, 6 Jan 2009 12:13:30 -0600
Subject: [LLVMdev] Heating/Cooling Maintenance Started
Message-ID: <49639F4A.9030700@cs.uiuc.edu>

Dear LLVMers,

The heating/cooling maintenance in our building has started.  I peeked 
into the server room in which the LLVM SVN server is stored, and it's 
already 81 degrees Fahrenheit in there.  Our IT staff will shut systems 
down once the temperature reaches 84 degrees Fahrenheit

Again, I strongly recommend that people not make any SVN commits or 
Bugzilla changes until the cooling system is back on at 4:00 pm Central 
time today.

-- John T.


From isanbard at gmail.com  Tue Jan  6 12:44:24 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 6 Jan 2009 10:44:24 -0800
Subject: [LLVMdev] LLVM Optmizer
In-Reply-To: <20090106110251.4851.qmail@hm885.locaweb.com.br>
References: <20090106110251.4851.qmail@hm885.locaweb.com.br>
Message-ID: <16e5fdf90901061044t79e513e0m106b313d7ced5d87@mail.gmail.com>

Hi Manoel,

More info is needed. What optimization level did you use when
compiling LLVM? What does the LLVM x86 assembly code look like? How is
this run? What are the times you're seeing? What is your system's
configuration?

-bw

On Tue, Jan 6, 2009 at 3:02 AM, Manoel Teixeira <manoel at fonetica.com.br> wrote:
>
>  The following C code :
> #include <stdio.h>
> #include <stdlib.h>
>
> int  TESTE2( int  parami , int paraml ,double  paramd  )
> {
>  int varx=0,vary;
>  int nI =0;
>  //varx= parami;
>    if( parami > 0  )
>        {
>   varx = parami;
>   vary = varx + 1;
>        }
>  else
>  {
>   varx = vary + 1;
>   vary = paraml;
>  }
> varx = varx + parami + paraml;
>  for( nI = 1 ;   nI <=  paraml; nI++)
>  {
>    varx =  varx + parami + 1 ;
>        vary =  varx + nI;
>  }
>  vary = varx + 5;
>  varx = vary + paraml;
>
> return varx ;
> }
>
> Generates the IR :
> ; ModuleID = '/tmp/webcompile/_9908_0.bc'
> target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
> target triple = "i386-pc-linux-gnu"
>
> define i32 @TESTE2(i32 %parami, i32 %paraml, double %paramd) nounwind readnone {
> entry:
>        %0 = shl i32 %parami, 1         ; <i32> [#uses=1]
>        %varx.110 = add i32 %0, %paraml         ; <i32> [#uses=2]
>        %1 = icmp slt i32 %paraml, 1            ; <i1> [#uses=1]
>        br i1 %1, label %bb5, label %bb3
>
> bb3:            ; preds = %bb3, %entry
>        %indvar = phi i32 [ %indvar.next, %bb3 ], [ 0, %entry ]         ; <i32> [#uses=3]
>        %2 = add i32 %indvar, 2         ; <i32> [#uses=1]
>        %3 = icmp sgt i32 %2, %paraml           ; <i1> [#uses=1]
>        %indvar.next = add i32 %indvar, 1               ; <i32> [#uses=1]
>        br i1 %3, label %bb5.loopexit, label %bb3
>
> bb5.loopexit:           ; preds = %bb3
>        %tmp14 = add i32 %parami, 1             ; <i32> [#uses=1]
>        %tmp15 = mul i32 %indvar, %tmp14                ; <i32> [#uses=1]
>        %varx.111 = add i32 %tmp15, %varx.110           ; <i32> [#uses=1]
>        %4 = add i32 %varx.111, %parami         ; <i32> [#uses=1]
>        %phitmp = add i32 %4, 1         ; <i32> [#uses=1]
>        br label %bb5
>
> bb5:            ; preds = %bb5.loopexit, %entry
>        %varx.1.lcssa = phi i32 [ %varx.110, %entry ], [ %phitmp, %bb5.loopexit ]               ; <i32> [#uses=1]
>        %5 = add i32 %paraml, 5         ; <i32> [#uses=1]
>        %6 = add i32 %5, %varx.1.lcssa          ; <i32> [#uses=1]
>        ret i32 %6
> }
>
>
> While the MSVC generates the assemble :
> PUBLIC  _TESTE
> ; Function compile flags: /Ogtpy
> ; File c:\msys\1.0\home\mteixeira\testeadvpl.c
> ;       COMDAT _TESTE
> _TEXT   SEGMENT
> _parami$ = 8                                            ; size = 4
> _paraml$ = 12                                           ; size = 4
> _paramd$ = 16                                           ; size = 8
> _TESTE  PROC                                            ; COMDAT
>
> ; 6    :   int varx=0,vary;
> ; 7    :   int nI =0;
> ; 8    :   //varx= parami;
> ; 9    :     if( parami > 0  )
>
>        mov     ecx, DWORD PTR _parami$[esp-4]
>
> ; 10   :        {
> ; 11   :    varx = parami;
> ; 12   :    vary = 0;
> ; 13   :        }
> ; 14   :   else
> ; 15   :   {
> ; 16   :    varx = 0;
> ; 17   :    vary = paraml;
> ; 18   :   }
> ; 19   :   for( nI = 1 ;   nI <=  paraml; nI++)
>
>        mov     edx, DWORD PTR _paraml$[esp-4]
>        xor     eax, eax
>        test    ecx, ecx
>        setle   al
>        sub     eax, 1
>        and     eax, ecx
>        cmp     edx, 1
>        jl      SHORT $LN3 at TESTE
>        add     ecx, 1
>        imul    ecx, edx
>        add     eax, ecx
> $LN3 at TESTE:
>
> ; 20   :   {
> ; 21   :     varx =  varx + parami + 1 ;
> ; 22   :        vary =  varx + nI;
> ; 23   :   }
> ; 24   :
> ; 25   : return varx ;
> ; 26   : }
>
>        ret     0
> _TESTE  ENDP
> _TEXT   ENDS
>
>  Running the same code, the objetc generated with MSVC is 600 times faster than that generate with the LLVM compiler
>  Is threre any way to get the same optimzation with the LLVM?
>
>
> Manoel Teixeira
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From dberlin at dberlin.org  Tue Jan  6 12:46:52 2009
From: dberlin at dberlin.org (Daniel Berlin)
Date: Tue, 6 Jan 2009 13:46:52 -0500
Subject: [LLVMdev] Revision 61765 causes ld to think eh_frame has errors
Message-ID: <4aca3dc20901061046y4faec3d0jc66b3db228f02e30@mail.gmail.com>

On x86_64-linux (ubuntu 8.04), we now have 3 test fails.

This happened as of revision 61765 (see
http://google1.osuosl.org:8011/builders/llvm-x86_64-linux/builds/1316).

The failure mode is:

Failed with unknown error (or has stderr output) at line 1
/usr/bin/ld: error in /tmp/llvm_wwflUD/false.o(.eh_frame); no
.eh_frame_hdr table will be created.

Failed with unknown error (or has stderr output) at line 1
/usr/bin/ld: error in /tmp/llvm_QbpfxH/hello.o(.eh_frame); no
.eh_frame_hdr table will be created.

Failed with unknown error (or has stderr output) at line 1
/usr/bin/ld: error in /tmp/llvm_cxO8Q6/together.o(.eh_frame); no
.eh_frame_hdr table will be created

61765 looks like it reverted some patches thinking they "weren't
needed". It appears at least binutils thinks they are :)

From obsidium at uni-paderborn.de  Tue Jan  6 19:54:52 2009
From: obsidium at uni-paderborn.de (Martin Tofall)
Date: Wed, 7 Jan 2009 02:54:52 +0100
Subject: [LLVMdev] opt pass plugins on Windows?
Message-ID: <878621325.20090107025452@uni-paderborn.de>

Hello,

I'm just starting out with LLVM, currently using Visual Studio on
Windows. Now I'd like to write a custom pass that can be loaded
dynamically as demonstrated in the 'hello world' tutorial.
So far my DLL loads OK but the actual pass registration does not seem
to work.
My question then is (as I could not find any information on the
subject): is this even possible on win32 or will I have to move to a
different development platform?

Thanks,
Martin


From regehr at cs.utah.edu  Tue Jan  6 20:11:12 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Tue, 6 Jan 2009 19:11:12 -0700 (MST)
Subject: [LLVMdev] LLVM Optmizer
In-Reply-To: <20090106110251.4851.qmail@hm885.locaweb.com.br>
References: <20090106110251.4851.qmail@hm885.locaweb.com.br>
Message-ID: <alpine.DEB.1.00.0901061909020.7163@babel.cs.utah.edu>

The code here is invalid, it executes an operation with undefined behavior 
in the else branch of the first if (read from uninitialized vary).

John



On Tue, 6 Jan 2009, Manoel Teixeira wrote:

>
> The following C code :
> #include <stdio.h>
> #include <stdlib.h>
>
> int  TESTE2( int  parami , int paraml ,double  paramd  )
> {
>  int varx=0,vary;
>  int nI =0;
>  //varx= parami;
>    if( parami > 0  )
> 	{
>   varx = parami;
>   vary = varx + 1;
> 	}
>  else
>  {
>   varx = vary + 1;
>   vary = paraml;
>  }
> varx = varx + parami + paraml;
>  for( nI = 1 ;   nI <=  paraml; nI++)
>  {
>    varx =  varx + parami + 1 ;
> 	vary =  varx + nI;
>  }
>  vary = varx + 5;
>  varx = vary + paraml;
>
> return varx ;
> }
>
> Generates the IR :
> ; ModuleID = '/tmp/webcompile/_9908_0.bc'
> target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
> target triple = "i386-pc-linux-gnu"
>
> define i32 @TESTE2(i32 %parami, i32 %paraml, double %paramd) nounwind readnone {
> entry:
> 	%0 = shl i32 %parami, 1		; <i32> [#uses=1]
> 	%varx.110 = add i32 %0, %paraml		; <i32> [#uses=2]
> 	%1 = icmp slt i32 %paraml, 1		; <i1> [#uses=1]
> 	br i1 %1, label %bb5, label %bb3
>
> bb3:		; preds = %bb3, %entry
> 	%indvar = phi i32 [ %indvar.next, %bb3 ], [ 0, %entry ]		; <i32> [#uses=3]
> 	%2 = add i32 %indvar, 2		; <i32> [#uses=1]
> 	%3 = icmp sgt i32 %2, %paraml		; <i1> [#uses=1]
> 	%indvar.next = add i32 %indvar, 1		; <i32> [#uses=1]
> 	br i1 %3, label %bb5.loopexit, label %bb3
>
> bb5.loopexit:		; preds = %bb3
> 	%tmp14 = add i32 %parami, 1		; <i32> [#uses=1]
> 	%tmp15 = mul i32 %indvar, %tmp14		; <i32> [#uses=1]
> 	%varx.111 = add i32 %tmp15, %varx.110		; <i32> [#uses=1]
> 	%4 = add i32 %varx.111, %parami		; <i32> [#uses=1]
> 	%phitmp = add i32 %4, 1		; <i32> [#uses=1]
> 	br label %bb5
>
> bb5:		; preds = %bb5.loopexit, %entry
> 	%varx.1.lcssa = phi i32 [ %varx.110, %entry ], [ %phitmp, %bb5.loopexit ]		; <i32> [#uses=1]
> 	%5 = add i32 %paraml, 5		; <i32> [#uses=1]
> 	%6 = add i32 %5, %varx.1.lcssa		; <i32> [#uses=1]
> 	ret i32 %6
> }
>
>
> While the MSVC generates the assemble :
> PUBLIC	_TESTE
> ; Function compile flags: /Ogtpy
> ; File c:\msys\1.0\home\mteixeira\testeadvpl.c
> ;	COMDAT _TESTE
> _TEXT	SEGMENT
> _parami$ = 8						; size = 4
> _paraml$ = 12						; size = 4
> _paramd$ = 16						; size = 8
> _TESTE	PROC						; COMDAT
>
> ; 6    :   int varx=0,vary;
> ; 7    :   int nI =0;
> ; 8    :   //varx= parami;
> ; 9    :     if( parami > 0  )
>
> 	mov	ecx, DWORD PTR _parami$[esp-4]
>
> ; 10   : 	{
> ; 11   :    varx = parami;
> ; 12   :    vary = 0;
> ; 13   : 	}
> ; 14   :   else
> ; 15   :   {
> ; 16   :    varx = 0;
> ; 17   :    vary = paraml;
> ; 18   :   }
> ; 19   :   for( nI = 1 ;   nI <=  paraml; nI++)
>
> 	mov	edx, DWORD PTR _paraml$[esp-4]
> 	xor	eax, eax
> 	test	ecx, ecx
> 	setle	al
> 	sub	eax, 1
> 	and	eax, ecx
> 	cmp	edx, 1
> 	jl	SHORT $LN3 at TESTE
> 	add	ecx, 1
> 	imul	ecx, edx
> 	add	eax, ecx
> $LN3 at TESTE:
>
> ; 20   :   {
> ; 21   :     varx =  varx + parami + 1 ;
> ; 22   : 	vary =  varx + nI;
> ; 23   :   }
> ; 24   :
> ; 25   : return varx ;
> ; 26   : }
>
> 	ret	0
> _TESTE	ENDP
> _TEXT	ENDS
>
> Running the same code, the objetc generated with MSVC is 600 times faster than that generate with the LLVM compiler
> Is threre any way to get the same optimzation with the LLVM?
>
>
> Manoel Teixeira
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From scottm at aero.org  Tue Jan  6 19:53:48 2009
From: scottm at aero.org (Scott Michel)
Date: Tue, 6 Jan 2009 17:53:48 -0800
Subject: [LLVMdev] Probably FAQ: can you insert BRCONDs during
	TargetLowering::LowerOperation?
Message-ID: <8988770C-643B-40C8-8B5B-B90F1791C59B@aero.org>

It's yet another CellSPU thing: integer division is a long code  
sequence we have to insert that has branches within it (test for 0  
divisor, etc.) Can't really emit the sequence of instructions via  
tblgen (can't have labels or BBs). The other alternative is a custom  
instruction emitter.

Life could be easier if I could insert BRCONDs and other branches  
from within target-dependent lowering -- if I had access to the  
current MBB.

Is this possible or just a FAQ?


-scooter

From clattner at apple.com  Wed Jan  7 00:07:20 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 6 Jan 2009 22:07:20 -0800
Subject: [LLVMdev] Probably FAQ: can you insert BRCONDs during
	TargetLowering::LowerOperation?
In-Reply-To: <8988770C-643B-40C8-8B5B-B90F1791C59B@aero.org>
References: <8988770C-643B-40C8-8B5B-B90F1791C59B@aero.org>
Message-ID: <81143244-8513-45E2-91EB-478DA2B879B9@apple.com>


On Jan 6, 2009, at 5:53 PM, Scott Michel wrote:

> It's yet another CellSPU thing: integer division is a long code
> sequence we have to insert that has branches within it (test for 0
> divisor, etc.) Can't really emit the sequence of instructions via
> tblgen (can't have labels or BBs). The other alternative is a custom
> instruction emitter.
>
> Life could be easier if I could insert BRCONDs and other branches
> from within target-dependent lowering -- if I had access to the
> current MBB.
>
> Is this possible or just a FAQ?

It isn't currently possible for a selection dag to represent more than  
one machine basic block.  I think Christopher Lamb had some code that  
did some of this, but I don't know how far he got.

The way we currently work around this is with a "custom scheduler  
insertion hook".  For example, see how SELECT_CC_* works on PPC: at  
isel time we claim that we have the operation, then the scheduler  
invokes a virtual function to insert it, which expands out into  
multiple MBBs.

-Chris

From scooter.phd at gmail.com  Wed Jan  7 01:37:12 2009
From: scooter.phd at gmail.com (Scott Michel)
Date: Tue, 6 Jan 2009 23:37:12 -0800
Subject: [LLVMdev] Probably FAQ: can you insert BRCONDs during
	TargetLowering::LowerOperation?
In-Reply-To: <81143244-8513-45E2-91EB-478DA2B879B9@apple.com>
References: <8988770C-643B-40C8-8B5B-B90F1791C59B@aero.org>
	<81143244-8513-45E2-91EB-478DA2B879B9@apple.com>
Message-ID: <258cd3200901062337v14c55ae2j2ebe196da588f1f8@mail.gmail.com>

Chris:

I was trying to avoid using the custom instruction emitter method. Not as if
I didn't look before I asked the question to see if there was an easier way.


-scooter

On Tue, Jan 6, 2009 at 10:07 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Jan 6, 2009, at 5:53 PM, Scott Michel wrote:
>
> > It's yet another CellSPU thing: integer division is a long code
> > sequence we have to insert that has branches within it (test for 0
> > divisor, etc.) Can't really emit the sequence of instructions via
> > tblgen (can't have labels or BBs). The other alternative is a custom
> > instruction emitter.
> >
> > Life could be easier if I could insert BRCONDs and other branches
> > from within target-dependent lowering -- if I had access to the
> > current MBB.
> >
> > Is this possible or just a FAQ?
>
> It isn't currently possible for a selection dag to represent more than
> one machine basic block.  I think Christopher Lamb had some code that
> did some of this, but I don't know how far he got.
>
> The way we currently work around this is with a "custom scheduler
> insertion hook".  For example, see how SELECT_CC_* works on PPC: at
> isel time we claim that we have the operation, then the scheduler
> invokes a virtual function to insert it, which expands out into
> multiple MBBs.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090106/e2d0b507/attachment-0001.html 

From clattner at apple.com  Wed Jan  7 02:18:39 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 7 Jan 2009 00:18:39 -0800
Subject: [LLVMdev] Probably FAQ: can you insert BRCONDs during
	TargetLowering::LowerOperation?
In-Reply-To: <258cd3200901062337v14c55ae2j2ebe196da588f1f8@mail.gmail.com>
References: <8988770C-643B-40C8-8B5B-B90F1791C59B@aero.org>
	<81143244-8513-45E2-91EB-478DA2B879B9@apple.com>
	<258cd3200901062337v14c55ae2j2ebe196da588f1f8@mail.gmail.com>
Message-ID: <F996D3D3-658F-4C9E-860F-555EE1421485@apple.com>


On Jan 6, 2009, at 11:37 PM, Scott Michel wrote:

> Chris:
>
> I was trying to avoid using the custom instruction emitter method.  
> Not as if I didn't look before I asked the question to see if there  
> was an easier way.

Then no, there is no other way.

-Chris


From lennart at augustsson.net  Wed Jan  7 02:29:27 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Wed, 7 Jan 2009 08:29:27 +0000
Subject: [LLVMdev] Extending the C API
Message-ID: <f4876cd70901070029m675a3df8o3469cd730143a51d@mail.gmail.com>

Are there any imminent plans to extend the C API to make it more complete?
Or should I just make a bug report with patches for the calls that I
need that are missing?

  -- Lennart

From romix.llvm at googlemail.com  Wed Jan  7 04:48:01 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Wed, 7 Jan 2009 11:48:01 +0100
Subject: [LLVMdev] Possible bug in the ARM backend?
Message-ID: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>

Hi,

I'm working on the iterated register coalescing graph coloring
allocator and try to test it with all backends available currently in
LLVM.
Initial tests with most of the backends are successful.

It turned out that my allocator triggers a specific assertion in the
RegScavenger and only for the ARM target. It looks like the LR
register is used for frame pointer related things,
but it is STILL available for register allocation according to the
ARMRegisterInfo.td:

def GPR : RegisterClass<"ARM", [i32], 32, [R0, R1, R2, R3, R4, R5, R6,
                                           R7, R8, R9, R10, R12, R11,
                                           LR, SP, PC]>


Let me now explain the problem step-by-step:

1) Here is the function's machine code before register allocation
(this code is produced by bugpoint from a bigger test-case):
    If you need the BC file, it is attached:

# Machine code for Insert():
Live Ins: R0 in VR#1025  R1 in VR#1026

entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0:
Live Ins: %R0 %R1
        %reg1026<def,dead> = MOVr %R1<kill>, 14, %reg0, %reg0
        %reg1025<def> = MOVr %R0<kill>, 14, %reg0, %reg0
        %reg1024<def> = MOVr %reg1025, 14, %reg0, %reg0
        CMPri %reg1025<kill>, 0, 14, %reg0, %CPSR<imp-def>
        Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill>
    Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2)

bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
    Predecessors according to CFG: 0x8fdac90 (#0)
        %reg1027<def> = MOVi 0, 14, %reg0, %reg0
        STR %reg1024<kill>, %reg1027<kill>, %reg0, 0, 14, %reg0,
Mem:ST(4,4) [0x8fc2d68 + 0]
        BX_RET 14, %reg0

UnifiedReturnBlock: 0x8fdad70, LLVM BB @0x8fc2cc0, ID#2:
    Predecessors according to CFG: 0x8fdac90 (#0)
        BX_RET 14, %reg0

# End machine code for Insert().


2) My register allocator produces a following allocation:

********** REGISTER MAP **********
[reg1024 -> LR]
[reg1025 -> R0]
[reg1026 -> R1]
[reg1027 -> R0]


The interesting bit is that it is:
- different from the linearscan result
- it assigned the LR reg to the reg1024, even though LR is not the
first register in the allocation order for the GPR register class.
  Even though, it ignores the preferred allocation order, it is not a
bug and is quite legal.


  BTW, I obtain the set of allocatable register using the following
code at the beginning of the runOnMachineFunction() of my register
allocator.
  Is anything wrong with it?

  mri = tm->getRegisterInfo();

  // Prepare regClass2AllowedSet for each register class
  // This should be done on a per function basis, because
  // some registers may get included/excluded on a per
  // function basic (e.g. frame pointer on X86)

  regClass2AllowedSet.clear();
  regClass2AllowedSet.resize(mri->getNumRegClasses() + 1);

  for (TargetRegisterInfo::regclass_iterator
       RCI = mri->regclass_begin(), RCE = mri->regclass_end();
       RCI != RCE; ++RCI) {

    int regClassId = (*RCI)->getID();
    regClass2AllowedSet[regClassId].resize(mri->getNumRegs() + 1);

    for (TargetRegisterClass::iterator I = (*RCI)->allocation_order_begin(*mf),
                                       E = (*RCI)->allocation_order_end(*mf);
         I != E; ++I)
      regClass2AllowedSet[regClassId].set(*I);
  }


3) This register allocation results in the following machine code,
after replacement of virtual regs by the assigned physical regs:

**** Post Machine Instrs ****
# Machine code for Insert():
Live Ins: R0 in VR#1025  R1 in VR#1026

entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0:
Live Ins: %R0 %R1
        %LR<def> = MOVr %R0, 14, %reg0, %reg0
        CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def>
        Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill>
    Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2)

bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
    Predecessors according to CFG: 0x8fdac90 (#0)
        %R0<def> = MOVi 0, 14, %reg0, %reg0
        STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
[0x8fc2d68 + 0]
        BX_RET 14, %reg0

UnifiedReturnBlock: 0x8fdad70, LLVM BB @0x8fc2cc0, ID#2:
    Predecessors according to CFG: 0x8fdac90 (#0)
        BX_RET 14, %reg0

# End machine code for Insert().


4) Then I get the following assertion:
     llc: /opt/llvm/lib/CodeGen/RegisterScavenging.cpp:223: void
llvm::RegScavenger::forward(): Assertion `isUsed(Reg) && "Using an
undefined register!"' failed.

    It is triggered by PrologEpilogInserter::replaceFrameIndices()
function. The undefined register is the LR register.

    If I dump the function at this point I see the following (the
instruction tiggering the assetion is marked by ***):

# Machine code for Insert():
  <fi#0>: size is 4 bytes, alignment is 4 bytes, at location [SP-4]
Live Ins: R0 in VR#1025  R1 in VR#1026

entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0:
Live Ins: %R0 %R1 %LR
        %SP<def> = SUBri %SP<kill>, 4, 14, %reg0, %reg0
        STR %LR<kill>, %SP, %reg0, 0, 14, %reg0
        %LR<def> = MOVr %R0, 14, %reg0, %reg0
        CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def>
        Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill>
    Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2)

bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
    Predecessors according to CFG: 0x8fdac90 (#0)
        %R0<def> = MOVi 0, 14, %reg0, %reg0
***     STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
[0x8fc2d68 + 0]
        %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
        %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
        BX_RET 14, %reg0

UnifiedReturnBlock: 0x8fdad70, LLVM BB @0x8fc2cc0, ID#2:
    Predecessors according to CFG: 0x8fdac90 (#0)
        %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
        %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
        BX_RET 14, %reg0

# End machine code for Insert().


  As you can see, PrologEpilogInserter has inserted at the beginning
of the function some code for manipulation of the frame pointer and
this inserted code uses the LR register.
  As far as I understand,  ARMRegisterInfo.td should exclude the LR
register from the set of allocatable registers for functions that
require frame pointer manipulation.
  But currently it is not the case, or?

  I hope that I provided enough information to explain my problem. I
also provided my initial analysis, but may be I'm wrong.

  Can someone more knowledgeable in ARM backend and LLVM's register
allocation framework have a look at it?
  If it is a bug in the ARM backend, could it be fixed?

  Thanks,
   Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugpoint-reduced-simplified.bc
Type: application/octet-stream
Size: 536 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/6bbb5738/attachment.obj 

From manoel at fonetica.com.br  Wed Jan  7 04:56:05 2009
From: manoel at fonetica.com.br (=?ISO-8859-1?Q?Manoel=20Teixeira?=)
Date: Wed,  7 Jan 2009 08:56:05 -0200
Subject: [LLVMdev] LLVM optmization
Message-ID: <20090107105605.27816.qmail@hm885.locaweb.com.br>


The following C test program was  compiled using LLVM with -O3 option  and MSVC with /O2.
The MSVC one is about 600 times faster than the one compiled with the LLVM.
We can see that the for loop in MSVC assembler is solved in the optimization pass more efficiently than that in LLVM.
Is there an way to get a optimization result in LLVM like that of the MSVC?
Manoel Teixeira 

#include <windows.h>
#include <stdio.h>

int  TESTE ( int  parami ,int  paraml ,double  paramd  ) 
{
  int varx=0,vary=0;
  int nI =0;

    if( parami > 0  ) 
	{
   varx = parami;
   vary = 0;
	}
  else
  {
   varx = 0;
   vary = paraml;
  }
  for( nI = 1 ;   nI <=  paraml; nI++)
  {
    varx =  varx + parami + 1 ;
	vary =  varx + nI;
  }

return varx ;
}
unsigned long thread_call( LPVOID c ) 
{
	int num = 1;
	int (*fp)(int, int, double) = (int (*)(int, int,double)) c;
	//printf("\n(1)threadid =  %ld seqt=%ld inum=%d",GetCurrentThreadId(),num,inum);
	int ret = fp(num,1000000000,1);
	printf("\n(2)leu %ld threadid =  %ld seqt=%ld ",ret , GetCurrentThreadId(),num);
	return (unsigned long) ret;
}
///cronometro
unsigned long tini;
unsigned long tfim;
#define getmilisecs(x) (x)
#define num_th 100
unsigned long milisecs() { return getmilisecs(tfim-tini);}; 
unsigned long secs() { return milisecs()/1000;}; 
const char *spenttime () 
{
	static char buffer[64];
	unsigned long systime			=	 secs();
	unsigned long milisectime		=	 milisecs()%1000;
	sprintf(buffer,"%02d:%02d:%02d:%03d",systime/3600,(systime%3600)/60,(systime%3600)%60,milisectime);
	return (const char*) buffer;
};
//fim cronometro
int main(int a, char **b)
{
 int i;
 DWORD  iThreadId;
 HANDLE mainThread[num_th];
 tfim 	= 	0;
 tini	=	GetTickCount();
 for(i=0;	i<	num_th;i++)
		mainThread[i] = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)thread_call, (LPVOID)TESTE, 0, (DWORD *)&iThreadId);
		
 //WaitForMultipleObjects(  num_th,  (const HANDLE* )mainThread,  TRUE,  INFINITE);
  for( i=0; i < num_th;  i++)
  {
	WaitForSingleObject( mainThread[i], INFINITE ); 
	 CloseHandle(mainThread[i]);
  }
  tfim = GetTickCount();
 
 printf("\n chamou = %s",spenttime () );
 return 0;
}
//////////////////////////

; ModuleID = 'testeadvpl.c'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-mingw32"
	%struct._SECURITY_ATTRIBUTES = type { i32, i8*, i32 }
@tfim = common global i32 0		; <i32*> [#uses=5]
@tini = common global i32 0		; <i32*> [#uses=5]
@.str = internal constant [38 x i8] c"\0A(2)leu %ld threadid =  %ld seqt=%ld \00"		; <[38 x i8]*> [#uses=1]
@buffer.30732 = internal global [64 x i8] zeroinitializer, align 32		; <[64 x i8]*> [#uses=1]
@.str1 = internal constant [20 x i8] c"%02d:%02d:%02d:%03d\00"		; <[20 x i8]*> [#uses=1]
@.str2 = internal constant [14 x i8] c"\0A chamou = %s\00"		; <[14 x i8]*> [#uses=1]

define i32 @TESTE(i32 %parami, i32 %paraml, double %paramd) nounwind readnone {
entry:
	%0 = icmp sgt i32 %parami, 0		; <i1> [#uses=1]
	%varx.0 = select i1 %0, i32 %parami, i32 0		; <i32> [#uses=1]
	%1 = icmp slt i32 %paraml, 1		; <i1> [#uses=1]
	br i1 %1, label %bb5, label %bb.nph

bb.nph:		; preds = %entry
	%2 = add i32 %parami, 1		; <i32> [#uses=2]
	br label %bb3

bb3:		; preds = %bb3, %bb.nph
	%indvar = phi i32 [ 0, %bb.nph ], [ %indvar.next, %bb3 ]		; <i32> [#uses=3]
	%tmp = icmp slt i32 %parami, 0		; <i1> [#uses=1]
	%smax = select i1 %tmp, i32 0, i32 %parami		; <i32> [#uses=1]
	%tmp11 = mul i32 %indvar, %2		; <i32> [#uses=1]
	%varx.18 = add i32 %tmp11, %smax		; <i32> [#uses=1]
	%3 = add i32 %2, %varx.18		; <i32> [#uses=1]
	%4 = add i32 %indvar, 2		; <i32> [#uses=1]
	%5 = icmp sgt i32 %4, %paraml		; <i1> [#uses=1]
	%indvar.next = add i32 %indvar, 1		; <i32> [#uses=1]
	br i1 %5, label %bb5, label %bb3

bb5:		; preds = %bb3, %entry
	%varx.1.lcssa = phi i32 [ %varx.0, %entry ], [ %3, %bb3 ]		; <i32> [#uses=1]
	ret i32 %varx.1.lcssa
}

define i32 @milisecs() nounwind readonly {
entry:
	%0 = load i32* @tfim, align 4		; <i32> [#uses=1]
	%1 = load i32* @tini, align 4		; <i32> [#uses=1]
	%2 = sub i32 %0, %1		; <i32> [#uses=1]
	ret i32 %2
}

define i32 @thread_call(i8* %c) nounwind {
entry:
	%0 = bitcast i8* %c to i32 (i32, i32, double)*		; <i32 (i32, i32, double)*> [#uses=1]
	%1 = tail call i32 %0(i32 1, i32 1000000000, double 1.000000e+000) nounwind		; <i32> [#uses=2]
	%2 = tail call x86_stdcallcc i32 @GetCurrentThreadId() nounwind		; <i32> [#uses=1]
	%3 = tail call i32 (i8*, ...)* @printf(i8* getelementptr ([38 x i8]* @.str, i32 0, i32 0), i32 %1, i32 %2, i32 1) nounwind		; <i32> [#uses=0]
	ret i32 %1
}

declare x86_stdcallcc i32 @GetCurrentThreadId()

declare i32 @printf(i8*, ...) nounwind

define i32 @secs() nounwind readonly {
entry:
	%0 = load i32* @tfim, align 4		; <i32> [#uses=1]
	%1 = load i32* @tini, align 4		; <i32> [#uses=1]
	%2 = sub i32 %0, %1		; <i32> [#uses=1]
	%3 = udiv i32 %2, 1000		; <i32> [#uses=1]
	ret i32 %3
}

define i8* @spenttime() nounwind {
entry:
	%0 = load i32* @tfim, align 4		; <i32> [#uses=1]
	%1 = load i32* @tini, align 4		; <i32> [#uses=1]
	%2 = sub i32 %0, %1		; <i32> [#uses=3]
	%3 = udiv i32 %2, 1000		; <i32> [#uses=1]
	%4 = urem i32 %2, 1000		; <i32> [#uses=1]
	%5 = urem i32 %3, 3600		; <i32> [#uses=2]
	%6 = urem i32 %5, 60		; <i32> [#uses=1]
	%7 = udiv i32 %5, 60		; <i32> [#uses=1]
	%8 = udiv i32 %2, 3600000		; <i32> [#uses=1]
	%9 = tail call i32 (i8*, i8*, ...)* @sprintf(i8* getelementptr ([64 x i8]* @buffer.30732, i32 0, i32 0), i8* getelementptr ([20 x i8]* @.str1, i32 0, i32 0), i32 %8, i32 %7, i32 %6, i32 %4) nounwind		; <i32> [#uses=0]
	ret i8* getelementptr ([64 x i8]* @buffer.30732, i32 0, i32 0)
}

declare i32 @sprintf(i8*, i8*, ...) nounwind

define i32 @main(i32 %a, i8** %b) nounwind {
entry:
	%mainThread = alloca [100 x i8*]		; <[100 x i8*]*> [#uses=2]
	%iThreadId = alloca i32		; <i32*> [#uses=1]
	store i32 0, i32* @tfim, align 4
	%0 = call x86_stdcallcc i32 @GetTickCount() nounwind		; <i32> [#uses=1]
	store i32 %0, i32* @tini, align 4
	br label %bb

bb:		; preds = %bb, %entry
	%i.0.reg2mem.0 = phi i32 [ 0, %entry ], [ %indvar.next14, %bb ]		; <i32> [#uses=2]
	%1 = call x86_stdcallcc i8* @CreateThread(%struct._SECURITY_ATTRIBUTES* null, i32 0, i32 (i8*)* @thread_call, i8* bitcast (i32 (i32, i32, double)* @TESTE to i8*), i32 0, i32* %iThreadId) nounwind		; <i8*> [#uses=1]
	%2 = getelementptr [100 x i8*]* %mainThread, i32 0, i32 %i.0.reg2mem.0		; <i8**> [#uses=1]
	store i8* %1, i8** %2, align 4
	%indvar.next14 = add i32 %i.0.reg2mem.0, 1		; <i32> [#uses=2]
	%exitcond15 = icmp eq i32 %indvar.next14, 100		; <i1> [#uses=1]
	br i1 %exitcond15, label %bb3, label %bb

bb3:		; preds = %bb3, %bb
	%i.1.reg2mem.0 = phi i32 [ 0, %bb ], [ %indvar.next, %bb3 ]		; <i32> [#uses=2]
	%3 = getelementptr [100 x i8*]* %mainThread, i32 0, i32 %i.1.reg2mem.0		; <i8**> [#uses=2]
	%4 = load i8** %3, align 4		; <i8*> [#uses=1]
	%5 = call x86_stdcallcc i32 @WaitForSingleObject(i8* %4, i32 -1) nounwind		; <i32> [#uses=0]
	%6 = load i8** %3, align 4		; <i8*> [#uses=1]
	%7 = call x86_stdcallcc i32 @CloseHandle(i8* %6) nounwind		; <i32> [#uses=0]
	%indvar.next = add i32 %i.1.reg2mem.0, 1		; <i32> [#uses=2]
	%exitcond = icmp eq i32 %indvar.next, 100		; <i1> [#uses=1]
	br i1 %exitcond, label %bb5, label %bb3

bb5:		; preds = %bb3
	%8 = call x86_stdcallcc i32 @GetTickCount() nounwind		; <i32> [#uses=2]
	store i32 %8, i32* @tfim, align 4
	%9 = load i32* @tini, align 4		; <i32> [#uses=1]
	%10 = sub i32 %8, %9		; <i32> [#uses=3]
	%11 = udiv i32 %10, 1000		; <i32> [#uses=1]
	%12 = urem i32 %10, 1000		; <i32> [#uses=1]
	%13 = urem i32 %11, 3600		; <i32> [#uses=2]
	%14 = urem i32 %13, 60		; <i32> [#uses=1]
	%15 = udiv i32 %13, 60		; <i32> [#uses=1]
	%16 = udiv i32 %10, 3600000		; <i32> [#uses=1]
	%17 = call i32 (i8*, i8*, ...)* @sprintf(i8* getelementptr ([64 x i8]* @buffer.30732, i32 0, i32 0), i8* getelementptr ([20 x i8]* @.str1, i32 0, i32 0), i32 %16, i32 %15, i32 %14, i32 %12) nounwind		; <i32> [#uses=0]
	%18 = call i32 (i8*, ...)* @printf(i8* getelementptr ([14 x i8]* @.str2, i32 0, i32 0), i8* getelementptr ([64 x i8]* @buffer.30732, i32 0, i32 0)) nounwind		; <i32> [#uses=0]
	ret i32 0
}

declare x86_stdcallcc i32 @GetTickCount()

declare x86_stdcallcc i8* @CreateThread(%struct._SECURITY_ATTRIBUTES*, i32, i32 (i8*)*, i8*, i32, i32*)

declare x86_stdcallcc i32 @WaitForSingleObject(i8*, i32)

declare x86_stdcallcc i32 @CloseHandle(i8*)
////////////////////////
; Listing generated by Microsoft (R) Optimizing Compiler Version 14.00.50727.762 

	TITLE	C:\msys\1.0\home\mteixeira\testeadvpl.c
	.686P
	.XMM
	include listing.inc
	.model	flat

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

_DATA	SEGMENT
COMM	_tini:DWORD
COMM	_tfim:DWORD
_DATA	ENDS
PUBLIC	_TESTE
; Function compile flags: /Ogtpy
; File c:\msys\1.0\home\mteixeira\testeadvpl.c
;	COMDAT _TESTE
_TEXT	SEGMENT
_parami$ = 8						; size = 4
_paraml$ = 12						; size = 4
_paramd$ = 16						; size = 8
_TESTE	PROC						; COMDAT

; 6    :   int varx=0,vary=0;
; 7    :   int nI =0;
; 8    :   //varx= parami;
; 9    :     if( parami > 0  ) 

	mov	ecx, DWORD PTR _parami$[esp-4]

; 10   : 	{
; 11   :    varx = parami;
; 12   :    vary = 0;
; 13   : 	}
; 14   :   else
; 15   :   {
; 16   :    varx = 0;
; 17   :    vary = paraml;
; 18   :   }
; 19   :   for( nI = 1 ;   nI <=  paraml; nI++)

	mov	edx, DWORD PTR _paraml$[esp-4]
	xor	eax, eax
	test	ecx, ecx
	setle	al
	sub	eax, 1
	and	eax, ecx
	cmp	edx, 1
	jl	SHORT $LN3 at TESTE
	add	ecx, 1
	imul	ecx, edx
	add	eax, ecx
$LN3 at TESTE:

; 20   :   {
; 21   :     varx =  varx + parami + 1 ;
; 22   : 	vary =  varx + nI;
; 23   :   }
; 24   : 
; 25   : return varx ;
; 26   : }

	ret	0
_TESTE	ENDP
_TEXT	ENDS
PUBLIC	??_C at _0CG@LBAPCNHJ@?6?$CI2?$CJleu?5?$CFld?5threadid?5?$DN?5?5?$CFld?5seqt@ ; `string'
PUBLIC	__real at 3ff0000000000000
PUBLIC	_thread_call
EXTRN	_printf:PROC
EXTRN	__imp__GetCurrentThreadId at 0:PROC
EXTRN	__fltused:DWORD
;	COMDAT ??_C at _0CG@LBAPCNHJ@?6?$CI2?$CJleu?5?$CFld?5threadid?5?$DN?5?5?$CFld?5seqt@
CONST	SEGMENT
??_C at _0CG@LBAPCNHJ@?6?$CI2?$CJleu?5?$CFld?5threadid?5?$DN?5?5?$CFld?5seqt@ DB 0aH
	DB	'(2)leu %ld threadid =  %ld seqt=%ld ', 00H	; `string'
CONST	ENDS
;	COMDAT __real at 3ff0000000000000
CONST	SEGMENT
__real at 3ff0000000000000 DQ 03ff0000000000000r	; 1
; Function compile flags: /Ogtpy
CONST	ENDS
;	COMDAT _thread_call
_TEXT	SEGMENT
_c$ = 8							; size = 4
_thread_call PROC					; COMDAT

; 29   : 	int num = 1;
; 30   : 	int (*fp)(int, int, double) = (int (*)(int, int,double)) c;
; 31   : 	//printf("\n(1)threadid =  %ld seqt=%ld inum=%d",GetCurrentThreadId(),num,inum);
; 32   : 	int ret = fp(num,1000000000,1);

	fld1
	push	esi
	sub	esp, 8
	fstp	QWORD PTR [esp]
	push	1000000000				; 3b9aca00H
	push	1
	call	DWORD PTR _c$[esp+16]
	add	esp, 16					; 00000010H

; 33   : 	printf("\n(2)leu %ld threadid =  %ld seqt=%ld ",ret , GetCurrentThreadId(),num);

	push	1
	mov	esi, eax
	call	DWORD PTR __imp__GetCurrentThreadId at 0
	push	eax
	push	esi
	push	OFFSET ??_C at _0CG@LBAPCNHJ@?6?$CI2?$CJleu?5?$CFld?5threadid?5?$DN?5?5?$CFld?5seqt@
	call	_printf
	add	esp, 16					; 00000010H

; 34   : 	return (unsigned long) ret;

	mov	eax, esi
	pop	esi

; 35   : }

	ret	0
_thread_call ENDP
_TEXT	ENDS
PUBLIC	_milisecs
; Function compile flags: /Ogtpy
;	COMDAT _milisecs
_TEXT	SEGMENT
_milisecs PROC						; COMDAT

; 41   : unsigned long milisecs() { return getmilisecs(tfim-tini);}; 

	mov	eax, DWORD PTR _tfim
	sub	eax, DWORD PTR _tini
	ret	0
_milisecs ENDP
_TEXT	ENDS
PUBLIC	_secs
; Function compile flags: /Ogtpy
;	COMDAT _secs
_TEXT	SEGMENT
_secs	PROC						; COMDAT

; 42   : unsigned long secs() { return milisecs()/1000;}; 

	mov	ecx, DWORD PTR _tfim
	sub	ecx, DWORD PTR _tini
	mov	eax, 274877907				; 10624dd3H
	mul	ecx
	shr	edx, 6
	mov	eax, edx
	ret	0
_secs	ENDP
_TEXT	ENDS
PUBLIC	??_C at _0BE@FFMOMMDD@?$CF02d?3?$CF02d?3?$CF02d?3?$CF03d?$AA@ ; `string'
PUBLIC	_spenttime
EXTRN	_sprintf:PROC
_BSS	SEGMENT
?buffer@?1??spenttime@@9 at 9 DB 040H DUP (?)		; `spenttime'::`2'::buffer
_BSS	ENDS
;	COMDAT ??_C at _0BE@FFMOMMDD@?$CF02d?3?$CF02d?3?$CF02d?3?$CF03d?$AA@
CONST	SEGMENT
??_C at _0BE@FFMOMMDD@?$CF02d?3?$CF02d?3?$CF02d?3?$CF03d?$AA@ DB '%02d:%02d:'
	DB	'%02d:%03d', 00H				; `string'
; Function compile flags: /Ogtpy
CONST	ENDS
;	COMDAT _spenttime
_TEXT	SEGMENT
_spenttime PROC						; COMDAT

; 45   : 	static char buffer[64];
; 46   : 	unsigned long systime			=	 secs();

	mov	eax, DWORD PTR _tfim
	sub	eax, DWORD PTR _tini
	xor	edx, edx
	mov	ecx, 1000				; 000003e8H
	div	ecx
	push	esi
	push	edi
	mov	esi, eax
	mov	edi, edx

; 47   : 	unsigned long milisectime		=	 milisecs()%1000;
; 48   : 	sprintf(buffer,"%02d:%02d:%02d:%03d",systime/3600,(systime%3600)/60,(systime%3600)%60,milisectime);

	mov	eax, -1851608123			; 91a2b3c5H
	mul	esi
	mov	ecx, edx
	shr	ecx, 11					; 0000000bH
	mov	edx, ecx
	imul	edx, 3600				; 00000e10H
	mov	eax, esi
	sub	eax, edx
	xor	edx, edx
	mov	esi, 60					; 0000003cH
	div	esi
	push	edi
	push	edx
	push	eax
	push	ecx
	push	OFFSET ??_C at _0BE@FFMOMMDD@?$CF02d?3?$CF02d?3?$CF02d?3?$CF03d?$AA@
	push	OFFSET ?buffer@?1??spenttime@@9 at 9
	call	_sprintf
	add	esp, 24					; 00000018H
	pop	edi

; 49   : 	return (const char*) buffer;

	mov	eax, OFFSET ?buffer@?1??spenttime@@9 at 9
	pop	esi

; 50   : };

	ret	0
_spenttime ENDP
_TEXT	ENDS
PUBLIC	??_C at _0O@BKPPOCPE@?6?5chamou?5?$DN?5?$CFs?$AA@	; `string'
PUBLIC	_main
EXTRN	__imp__CloseHandle at 4:PROC
EXTRN	__imp__WaitForSingleObject at 8:PROC
EXTRN	__imp__CreateThread at 24:PROC
EXTRN	__imp__GetTickCount at 0:PROC
;	COMDAT ??_C at _0O@BKPPOCPE@?6?5chamou?5?$DN?5?$CFs?$AA@
CONST	SEGMENT
??_C at _0O@BKPPOCPE@?6?5chamou?5?$DN?5?$CFs?$AA@ DB 0aH, ' chamou = %s', 00H ; `string'
; Function compile flags: /Ogtpy
CONST	ENDS
;	COMDAT _main
_TEXT	SEGMENT
_iThreadId$ = -404					; size = 4
_mainThread$ = -400					; size = 400
_a$ = 8							; size = 4
_b$ = 12						; size = 4
_main	PROC						; COMDAT

; 53   : {

	sub	esp, 404				; 00000194H
	push	ebx
	push	ebp
	push	esi
	push	edi

; 54   :  int i;
; 55   :  DWORD  iThreadId;
; 56   :  HANDLE mainThread[num_th];
; 57   :  tfim 	= 	0;

	mov	DWORD PTR _tfim, 0

; 58   :  tini	=	GetTickCount();

	call	DWORD PTR __imp__GetTickCount at 0

; 59   :  for(i=0;	i<	num_th;i++)

	mov	edi, DWORD PTR __imp__CreateThread at 24
	mov	DWORD PTR _tini, eax
	xor	esi, esi
$LL6 at main:

; 60   : 		mainThread[i] = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)thread_call, (LPVOID)TESTE, 0, (DWORD *)&iThreadId);

	lea	eax, DWORD PTR _iThreadId$[esp+420]
	push	eax
	push	0
	push	OFFSET _TESTE
	push	OFFSET _thread_call
	push	0
	push	0
	call	edi
	mov	DWORD PTR _mainThread$[esp+esi*4+420], eax
	add	esi, 1
	cmp	esi, 100				; 00000064H
	jl	SHORT $LL6 at main

; 61   : 		
; 62   :  //WaitForMultipleObjects(  num_th,  (const HANDLE* )mainThread,  TRUE,  INFINITE);
; 63   :   for( i=0; i < num_th;  i++)

	mov	ebx, DWORD PTR __imp__WaitForSingleObject at 8
	mov	ebp, DWORD PTR __imp__CloseHandle at 4
	xor	esi, esi
$LL3 at main:

; 64   :   {
; 65   : 	WaitForSingleObject( mainThread[i], INFINITE ); 

	mov	edi, DWORD PTR _mainThread$[esp+esi*4+420]
	push	-1
	push	edi
	call	ebx

; 66   : 	 CloseHandle(mainThread[i]);

	push	edi
	call	ebp
	add	esi, 1
	cmp	esi, 100				; 00000064H
	jl	SHORT $LL3 at main

; 67   :   }
; 68   :   tfim = GetTickCount();

	call	DWORD PTR __imp__GetTickCount at 0
	mov	DWORD PTR _tfim, eax

; 69   :  
; 70   :  printf("\n chamou = %s",spenttime () );

	sub	eax, DWORD PTR _tini
	xor	edx, edx
	mov	ecx, 1000				; 000003e8H
	div	ecx
	mov	esi, eax
	mov	edi, edx
	mov	eax, -1851608123			; 91a2b3c5H
	mul	esi
	mov	ecx, edx
	shr	ecx, 11					; 0000000bH
	mov	edx, ecx
	imul	edx, 3600				; 00000e10H
	mov	eax, esi
	sub	eax, edx
	xor	edx, edx
	mov	esi, 60					; 0000003cH
	div	esi
	push	edi
	push	edx
	push	eax
	push	ecx
	push	OFFSET ??_C at _0BE@FFMOMMDD@?$CF02d?3?$CF02d?3?$CF02d?3?$CF03d?$AA@
	push	OFFSET ?buffer@?1??spenttime@@9 at 9
	call	_sprintf
	push	OFFSET ?buffer@?1??spenttime@@9 at 9
	push	OFFSET ??_C at _0O@BKPPOCPE@?6?5chamou?5?$DN?5?$CFs?$AA@
	call	_printf
	add	esp, 32					; 00000020H
	pop	edi
	pop	esi
	pop	ebp

; 71   :  return 0;

	xor	eax, eax
	pop	ebx

; 72   : }

	add	esp, 404				; 00000194H
	ret	0
_main	ENDP
_TEXT	ENDS
END


From pb at linuxtv.org  Wed Jan  7 05:22:31 2009
From: pb at linuxtv.org (Patrick Boettcher)
Date: Wed, 7 Jan 2009 12:22:31 +0100 (CET)
Subject: [LLVMdev] LLVM DebugInfoBuilder
Message-ID: <alpine.LRH.1.10.0901071221540.19962@pub4.ifh.de>

Hi list,
hi Talin,

I'm working on a frontend to generate IR using the IRBuilder from LLVM.

Now I want to add source-level-debuginfo and for that I would like to use the 
DebugInfoBuilder as it is taking some of the burderns. Unfortunately it does 
not take all of them, yet.

As of today, even in SVN, it only can add a part of information needed. Of 
course I also need stoppoint, declare, function.start and region.start - all 
the stuff for inside a basicblock.

I'm relatively new to LLVM's Builder-idea, but I'm learning fast ;).

So, let me ask, before adding anything to this class myself, is it

a) the correct way to add the basic-block-stuff to this class?

b) has someone already done something in that direction which is can be shared? 
:)

best regards,
Patrick.

--
   Mail: patrick.boettcher at desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/

From gordonhenriksen at me.com  Wed Jan  7 07:17:17 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Wed, 07 Jan 2009 08:17:17 -0500
Subject: [LLVMdev] Extending the C API
In-Reply-To: <f4876cd70901070029m675a3df8o3469cd730143a51d@mail.gmail.com>
References: <f4876cd70901070029m675a3df8o3469cd730143a51d@mail.gmail.com>
Message-ID: <103B8F7D-F24C-4D39-A95A-468F8C9D81E7@me.com>

On Jan 7, 2009, at 03:29, Lennart Augustsson wrote:

> Are there any imminent plans to extend the C API to make it more  
> complete? Or should I just make a bug report with patches for the  
> calls that I need that are missing?


Patches are welcome.

? Gordon



From viridia at gmail.com  Wed Jan  7 09:40:00 2009
From: viridia at gmail.com (Talin)
Date: Wed, 07 Jan 2009 07:40:00 -0800
Subject: [LLVMdev] LLVM DebugInfoBuilder
In-Reply-To: <alpine.LRH.1.10.0901071156180.19962@pub4.ifh.de>
References: <alpine.LRH.1.10.0901071156180.19962@pub4.ifh.de>
Message-ID: <4964CCD0.3060502@gmail.com>

You are completely correct - the DebugInfoBuilder class as it currently 
stands is only half finished. I've been meaning to work on it further, 
however before that can happen I need to actually try and use the basic 
block stuff in a real program so that I can get a feel for how it works 
and what the API should look like. It may be a while before I get around 
to doing that, however, so if you have a design in mind then I'd say "go 
for it" :)

Another thing that needs to be done, besides the items you mention, is 
support for member field debug info. My thought on this was to use a 
"push/pop" model, whereby you start a new aggregate data structure with 
a "push" which sets the current context, and then "pop" when the data 
structure is finished. (Actually, there might only be a single function 
for both push and pop, which sets the new context and returns a pointer 
to the old context.) This allows all of the existing functions that are 
currently used to define globals to also work with member fields.

For the basic block stuff, my approach would be to first ask the 
question: "what benefit is there from using a builder as opposed to just 
creating the intrinsics manually?". The generic answer is that the 
"builder" design pattern generally helps by keeping track of common 
state that is used by multiple build operations. Note that for the 
source-line-number intrinsics, DebugInfoBuilder will need to work in 
conjunction with an IRBuilder that actually creates the instructions to 
be inserted. The IRBuilder already keeps track of the current block and 
insertion point, so the next logical question to ask is, what state do 
we need to keep track of other than what IRBuilder already manages? If 
the answer is "none", then it might be simpler to add new methods to 
IRBuilder rather than DebugInfoBuilder. If however there is additional 
context information that is shared between build operations, then it 
makes sense to let DebugInfoBuilder manage it.

-- Talin

Patrick Boettcher wrote:
> Hi list,
> hi Talin,
>
> I'm working on a frontend to generate IR using the IRBuilder from LLVM.
>
> Now I want to add source-level-debuginfo and for that I would like to 
> use the DebugInfoBuilder as it is taking some of the burderns. 
> Unfortunately it does not take all of them, yet.
>
> As of today, even in SVN, it only can add a part of information 
> needed. Of course I also need stoppoint, declare, function.start and 
> region.start - all the stuff for inside a basicblock.
>
> I'm relatively new to LLVM's Builder-idea, but I'm learning fast ;).
>
> So, let me ask, before adding anything to this class myself, is it
>
> a) the correct way to add the basic-block-stuff to this class?
>
> b) has someone already done something in that direction which is can 
> be shared? :)
>
> best regards,
> Patrick.
>
> -- 
>   Mail: patrick.boettcher at desy.de
>   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
>


From evan.cheng at apple.com  Wed Jan  7 10:25:24 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Wed, 7 Jan 2009 08:25:24 -0800
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
Message-ID: <4693CC4E-C418-4C66-9DAB-50443D26F40F@apple.com>


On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:

>
>
>  As you can see, PrologEpilogInserter has inserted at the beginning
> of the function some code for manipulation of the frame pointer and
> this inserted code uses the LR register.
>  As far as I understand,  ARMRegisterInfo.td should exclude the LR
> register from the set of allocatable registers for functions that
> require frame pointer manipulation.
>  But currently it is not the case, or?

No, LR is not the frame pointer. It's the link register (caller  
address). It should be available as a general purpose register. The  
bug is elsewhere. It has to do with kill / dead markers.

        %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
        %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
        BX_RET 14, %reg0

LR is restored here but it's not killed before the end of the block is  
reached. Should BX_RET use it?

Evan

>
>
>  I hope that I provided enough information to explain my problem. I
> also provided my initial analysis, but may be I'm wrong.
>
>  Can someone more knowledgeable in ARM backend and LLVM's register
> allocation framework have a look at it?
>  If it is a bug in the ARM backend, could it be fixed?
>
>  Thanks,
>   Roman
> <bugpoint-reduced-simplified.bc>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/486a2f0e/attachment.html 

From patrick.boettcher at desy.de  Wed Jan  7 05:16:07 2009
From: patrick.boettcher at desy.de (Patrick Boettcher)
Date: Wed, 7 Jan 2009 12:16:07 +0100 (CET)
Subject: [LLVMdev] LLVM DebugInfoBuilder
Message-ID: <alpine.LRH.1.10.0901071156180.19962@pub4.ifh.de>

Hi list,
hi Talin,

I'm working on a frontend to generate IR using the IRBuilder from LLVM.

Now I want to add source-level-debuginfo and for that I would like to use 
the DebugInfoBuilder as it is taking some of the burderns. Unfortunately 
it does not take all of them, yet.

As of today, even in SVN, it only can add a part of information needed. Of 
course I also need stoppoint, declare, function.start and region.start - 
all the stuff for inside a basicblock.

I'm relatively new to LLVM's Builder-idea, but I'm learning fast ;).

So, let me ask, before adding anything to this class myself, is it

a) the correct way to add the basic-block-stuff to this class?

b) has someone already done something in that direction which is 
can be shared? :)

best regards,
Patrick.

--
   Mail: patrick.boettcher at desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/

From scottm at aero.org  Wed Jan  7 11:21:18 2009
From: scottm at aero.org (Scott Michel)
Date: Wed, 7 Jan 2009 09:21:18 -0800
Subject: [LLVMdev] Probably FAQ: can you insert BRCONDs during
	TargetLowering::LowerOperation?
In-Reply-To: <F996D3D3-658F-4C9E-860F-555EE1421485@apple.com>
References: <8988770C-643B-40C8-8B5B-B90F1791C59B@aero.org>
	<81143244-8513-45E2-91EB-478DA2B879B9@apple.com>
	<258cd3200901062337v14c55ae2j2ebe196da588f1f8@mail.gmail.com>
	<F996D3D3-658F-4C9E-860F-555EE1421485@apple.com>
Message-ID: <2CFA4605-7968-4E60-9682-BDED67DBDBC3@aero.org>

Chris:

It occurred to me this morning that maybe the general solution to  
this particular type of problem is a custom/target-dependent DAG  
inserter pass, analogous to target lowering and DAG legalization. I'm  
not sure if this pass happens before or after legalization. Worth  
considering?

I suppose the best way to discuss this is to just write the code.  
However, some preliminary discussion is probably worthwhile to make  
sure that a target-dependent DAG inserter pass is invoked in the  
right place in the existing pass stream.


-scooter

On Jan 7, 2009, at 12:18 AM, Chris Lattner wrote:

>
> On Jan 6, 2009, at 11:37 PM, Scott Michel wrote:
>
>> Chris:
>>
>> I was trying to avoid using the custom instruction emitter method.
>> Not as if I didn't look before I asked the question to see if there
>> was an easier way.
>
> Then no, there is no other way.
>
> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From isanbard at gmail.com  Wed Jan  7 13:40:02 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 7 Jan 2009 11:40:02 -0800
Subject: [LLVMdev] LLVM optmization
In-Reply-To: <20090107105605.27816.qmail@hm885.locaweb.com.br>
References: <20090107105605.27816.qmail@hm885.locaweb.com.br>
Message-ID: <16e5fdf90901071140y3db1a899o9906828b0058303c@mail.gmail.com>

On Wed, Jan 7, 2009 at 2:56 AM, Manoel Teixeira <manoel at fonetica.com.br> wrote:
>
> The following C test program was  compiled using LLVM with -O3 option  and MSVC with /O2.
> The MSVC one is about 600 times faster than the one compiled with the LLVM.
> We can see that the for loop in MSVC assembler is solved in the optimization pass more efficiently than that in LLVM.
> Is there an way to get a optimization result in LLVM like that of the MSVC?
> Manoel Teixeira
>
> #include <windows.h>
> #include <stdio.h>
>
> int  TESTE ( int  parami ,int  paraml ,double  paramd  )
> {
>  int varx=0,vary=0;
>  int nI =0;
>
>    if( parami > 0  )
>        {
>   varx = parami;
>   vary = 0;
>        }
>  else
>  {
>   varx = 0;
>   vary = paraml;
>  }
>  for( nI = 1 ;   nI <=  paraml; nI++)
>  {
>    varx =  varx + parami + 1 ;
>        vary =  varx + nI;
>  }
>
> return varx ;
> }
> unsigned long thread_call( LPVOID c )
> {
>        int num = 1;
>        int (*fp)(int, int, double) = (int (*)(int, int,double)) c;
>        //printf("\n(1)threadid =  %ld seqt=%ld inum=%d",GetCurrentThreadId(),num,inum);
>        int ret = fp(num,1000000000,1);
>        printf("\n(2)leu %ld threadid =  %ld seqt=%ld ",ret , GetCurrentThreadId(),num);
>        return (unsigned long) ret;
> }
> ///cronometro
> unsigned long tini;
> unsigned long tfim;
> #define getmilisecs(x) (x)
> #define num_th 100
> unsigned long milisecs() { return getmilisecs(tfim-tini);};
> unsigned long secs() { return milisecs()/1000;};
> const char *spenttime ()
> {
>        static char buffer[64];
>        unsigned long systime                   =        secs();
>        unsigned long milisectime               =        milisecs()%1000;
>        sprintf(buffer,"%02d:%02d:%02d:%03d",systime/3600,(systime%3600)/60,(systime%3600)%60,milisectime);
>        return (const char*) buffer;
> };
> //fim cronometro
> int main(int a, char **b)
> {
>  int i;
>  DWORD  iThreadId;
>  HANDLE mainThread[num_th];
>  tfim   =       0;
>  tini   =       GetTickCount();

You're starting your count ...

>  for(i=0;       i<      num_th;i++)
>                mainThread[i] = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)thread_call, (LPVOID)TESTE, 0, (DWORD *)&iThreadId);
>
While doing a thread create method (which I don't have on my darwin
box) that calls "printf". "printf" is I/O bound and makes for a lousy
performance test.

Nevertheless, I've attached the .s file generated by LLVM from the IR
you gave. I can't see anything obviously wrong with it. Please point
out in it which parts are 600x slower than on Windows. I'm not able to
run it because I don't have a Windows box, and it requires some
Windows calls.

Note: The ASM is for a Darwin box. I didn't generate this code with
frame pointers disabled. This would improve performance, but you
didn't mention that you did the same for your Windows compile.

-bw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: y.s
Type: application/octet-stream
Size: 3984 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/2f929f53/attachment.obj 

From obsidium at uni-paderborn.de  Wed Jan  7 14:37:36 2009
From: obsidium at uni-paderborn.de (Martin Tofall)
Date: Wed, 7 Jan 2009 21:37:36 +0100
Subject: [LLVMdev] opt pass plugins on Windows?
In-Reply-To: <878621325.20090107025452@uni-paderborn.de>
References: <878621325.20090107025452@uni-paderborn.de>
Message-ID: <315912191.20090107213736@uni-paderborn.de>

Hello,

this is just a quick follow-up to my previous email. I now tried
statically linking the 'hello' pass to opt which does seem to work.
But I'm not sure if this is reliable or if I'm bound to run into
problems later, so any comments on this issue would be appreciated.

Martin

Wednesday, January 7, 2009, 2:54:52 AM, you wrote:

MT> Hello,

MT> I'm just starting out with LLVM, currently using Visual Studio on
MT> Windows. Now I'd like to write a custom pass that can be loaded
MT> dynamically as demonstrated in the 'hello world' tutorial.
MT> So far my DLL loads OK but the actual pass registration does not seem
MT> to work.
MT> My question then is (as I could not find any information on the
MT> subject): is this even possible on win32 or will I have to move to a
MT> different development platform?

MT> Thanks,
MT> Martin

MT> _______________________________________________
MT> LLVM Developers mailing list
MT> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
MT> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From brukman at gmail.com  Wed Jan  7 15:29:09 2009
From: brukman at gmail.com (Misha Brukman)
Date: Wed, 7 Jan 2009 16:29:09 -0500
Subject: [LLVMdev] Private headers and testing
In-Reply-To: <A1A26236-7A0F-4F76-B844-9E3182D819E2@apple.com>
References: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>
	<86C752D4-EB94-4A38-9D4B-DE9E42AFC166@apple.com>
	<f88b89a50901021348t4d3ec6fcocabbc15a8a67c177@mail.gmail.com>
	<A1A26236-7A0F-4F76-B844-9E3182D819E2@apple.com>
Message-ID: <f88b89a50901071329h2673c0c0t17853ca0bccfc01f@mail.gmail.com>

2009/1/3 Chris Lattner <clattner at apple.com>

> On Jan 2, 2009, at 1:48 PM, Misha Brukman wrote:
>
> 2009/1/2 Chris Lattner <clattner at apple.com>
>
>> On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:
>> Do you have a specific example of a unit test that would need these?  I
>> really think these should stay private.
>>
>
> Let's take lib/Transforms/Utils/CodeExtractor.cpp .  The public interface
> for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the
> high-level API.
>
> If I want to test some corner-case (consider the number of code paths in
> that code), I have to strain to come up with some combination of a Function
> and input BasicBlocks that will fit all the conditions from the outset.  Or,
> I can just feed each individual method in the class exactly the corner cases
> I will want it to handle, and verify its output (or side effects) exactly,
> to make sure I pin-pointed the issue.
>
> Sure, ok.  But that is a public API, I'm specifically interested in cases
> you need private API.
>

I'm not sure I understand what you mean.  What I am saying is that I want to
expose the innards of CodeExtractor.cpp in a header file, #include that in
the unittest, and move the implementation out of an anonymous namespace into
llvm::transforms::utils, or llvm::internal::transforms::utils, or similar,
so it can be unit-tested.  This is not about exposing the private API to
end-users of LLVM or even other LLVM libraries, just unittests.

The public API, while useful to the end-user, is limiting when it comes to
unit-testing.  "Unit" in this case is a single method of the actual
implementation (i.e., a method of the CodeExtractor class), not a single
function call of the high-level exported public API, which will exercise the
entire class and its many methods.

Misha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/f76ef1b4/attachment.html 

From clattner at apple.com  Wed Jan  7 15:33:40 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 7 Jan 2009 13:33:40 -0800
Subject: [LLVMdev] Private headers and testing
In-Reply-To: <f88b89a50901071329h2673c0c0t17853ca0bccfc01f@mail.gmail.com>
References: <f88b89a50901021221u4ca38930q763f33e119d5a37@mail.gmail.com>
	<86C752D4-EB94-4A38-9D4B-DE9E42AFC166@apple.com>
	<f88b89a50901021348t4d3ec6fcocabbc15a8a67c177@mail.gmail.com>
	<A1A26236-7A0F-4F76-B844-9E3182D819E2@apple.com>
	<f88b89a50901071329h2673c0c0t17853ca0bccfc01f@mail.gmail.com>
Message-ID: <4BF5104C-E12E-4D2B-A72C-2AF35D939B83@apple.com>


On Jan 7, 2009, at 1:29 PM, Misha Brukman wrote:

> 2009/1/3 Chris Lattner <clattner at apple.com>
> On Jan 2, 2009, at 1:48 PM, Misha Brukman wrote:
>> 2009/1/2 Chris Lattner <clattner at apple.com>
>> On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:
>> Do you have a specific example of a unit test that would need  
>> these?  I really think these should stay private.
>>
>> Let's take lib/Transforms/Utils/CodeExtractor.cpp .  The public  
>> interface for it is in include/llvm/Transform/Utils/ 
>> FunctionUtils.h, with only the high-level API.
>>
>> If I want to test some corner-case (consider the number of code  
>> paths in that code), I have to strain to come up with some  
>> combination of a Function and input BasicBlocks that will fit all  
>> the conditions from the outset.  Or, I can just feed each  
>> individual method in the class exactly the corner cases I will want  
>> it to handle, and verify its output (or side effects) exactly, to  
>> make sure I pin-pointed the issue.
> Sure, ok.  But that is a public API, I'm specifically interested in  
> cases you need private API.
>
> I'm not sure I understand what you mean.  What I am saying is that I  
> want to expose the innards of CodeExtractor.cpp in a header file,  
> #include that in the unittest, and move the implementation out of an  
> anonymous namespace into llvm::transforms::utils, or  
> llvm::internal::transforms::utils, or similar, so it can be unit- 
> tested.  This is not about exposing the private API to end-users of  
> LLVM or even other LLVM libraries, just unittests.
>
> The public API, while useful to the end-user, is limiting when it  
> comes to unit-testing.  "Unit" in this case is a single method of  
> the actual implementation (i.e., a method of the CodeExtractor  
> class), not a single function call of the high-level exported public  
> API, which will exercise the entire class and its many methods.

I am pretty strongly against that.  Specifically for CodeExtractor,  
what benefit do you gain by doing this?

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/5ca6e9a1/attachment.html 

From clattner at apple.com  Wed Jan  7 15:35:50 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 7 Jan 2009 13:35:50 -0800
Subject: [LLVMdev] LLVM DebugInfoBuilder
In-Reply-To: <alpine.LRH.1.10.0901071221540.19962@pub4.ifh.de>
References: <alpine.LRH.1.10.0901071221540.19962@pub4.ifh.de>
Message-ID: <0B93638D-EAB9-45F5-8C03-260213C56A8E@apple.com>


On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote:

> Hi list,
> hi Talin,
>
> I'm working on a frontend to generate IR using the IRBuilder from  
> LLVM.
>
> Now I want to add source-level-debuginfo and for that I would like  
> to use the
> DebugInfoBuilder as it is taking some of the burderns. Unfortunately  
> it does
> not take all of them, yet.

Instead of DebugInfoBuilder, I'd strongly recommend taking a look at  
include/llvm/Analysis/DebugInfo.h.  This is the interface that llvm- 
gcc and clang both use to produce debug info.  If it's ok with Talin,  
I'd like to eventually remove DebugInfoBuilder.  Analysis/DebugInfo.h  
provides a nice and efficient API for both creating and reading debug  
info, and abstracts the clients from the actual form (e.g. serialized  
into GlobalVariables) that the debug info takes.

-Chris

From viridia at gmail.com  Wed Jan  7 15:48:35 2009
From: viridia at gmail.com (Talin)
Date: Wed, 7 Jan 2009 13:48:35 -0800
Subject: [LLVMdev] LLVM DebugInfoBuilder
In-Reply-To: <0B93638D-EAB9-45F5-8C03-260213C56A8E@apple.com>
References: <alpine.LRH.1.10.0901071221540.19962@pub4.ifh.de>
	<0B93638D-EAB9-45F5-8C03-260213C56A8E@apple.com>
Message-ID: <d1b71f830901071348k1c87305co4fe30c3c2baeab5e@mail.gmail.com>

Fine by me :)

On Wed, Jan 7, 2009 at 1:35 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote:
>
> > Hi list,
> > hi Talin,
> >
> > I'm working on a frontend to generate IR using the IRBuilder from
> > LLVM.
> >
> > Now I want to add source-level-debuginfo and for that I would like
> > to use the
> > DebugInfoBuilder as it is taking some of the burderns. Unfortunately
> > it does
> > not take all of them, yet.
>
> Instead of DebugInfoBuilder, I'd strongly recommend taking a look at
> include/llvm/Analysis/DebugInfo.h.  This is the interface that llvm-
> gcc and clang both use to produce debug info.  If it's ok with Talin,
> I'd like to eventually remove DebugInfoBuilder.  Analysis/DebugInfo.h
> provides a nice and efficient API for both creating and reading debug
> info, and abstracts the clients from the actual form (e.g. serialized
> into GlobalVariables) that the debug info takes.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/ea4cd9bd/attachment.html 

From clattner at apple.com  Wed Jan  7 15:53:06 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 7 Jan 2009 13:53:06 -0800
Subject: [LLVMdev] LLVM DebugInfoBuilder
In-Reply-To: <d1b71f830901071348k1c87305co4fe30c3c2baeab5e@mail.gmail.com>
References: <alpine.LRH.1.10.0901071221540.19962@pub4.ifh.de>
	<0B93638D-EAB9-45F5-8C03-260213C56A8E@apple.com>
	<d1b71f830901071348k1c87305co4fe30c3c2baeab5e@mail.gmail.com>
Message-ID: <B6FB45AB-58E9-471D-A03E-4E6B2C3B140D@apple.com>


On Jan 7, 2009, at 1:48 PM, Talin wrote:

> Fine by me :)

Is it ok to remove DebugInfoBuilder now?  I don't think that anything  
in the tree is using it, what do you think Talin?

-Chris

>
>
> On Wed, Jan 7, 2009 at 1:35 PM, Chris Lattner <clattner at apple.com>  
> wrote:
>
> On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote:
>
> > Hi list,
> > hi Talin,
> >
> > I'm working on a frontend to generate IR using the IRBuilder from
> > LLVM.
> >
> > Now I want to add source-level-debuginfo and for that I would like
> > to use the
> > DebugInfoBuilder as it is taking some of the burderns. Unfortunately
> > it does
> > not take all of them, yet.
>
> Instead of DebugInfoBuilder, I'd strongly recommend taking a look at
> include/llvm/Analysis/DebugInfo.h.  This is the interface that llvm-
> gcc and clang both use to produce debug info.  If it's ok with Talin,
> I'd like to eventually remove DebugInfoBuilder.  Analysis/DebugInfo.h
> provides a nice and efficient API for both creating and reading debug
> info, and abstracts the clients from the actual form (e.g. serialized
> into GlobalVariables) that the debug info takes.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> -- 
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/d0fcca77/attachment.html 

From romix.llvm at googlemail.com  Wed Jan  7 16:24:17 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Wed, 7 Jan 2009 23:24:17 +0100
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <4693CC4E-C418-4C66-9DAB-50443D26F40F@apple.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
	<4693CC4E-C418-4C66-9DAB-50443D26F40F@apple.com>
Message-ID: <e50173bd0901071424l2a7d97c5pa208725459f01989@mail.gmail.com>

Hi Evan,

Thanks for your feedback!

2009/1/7 Evan Cheng <evan.cheng at apple.com>:
>
> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>
>
>  As you can see, PrologEpilogInserter has inserted at the beginning
> of the function some code for manipulation of the frame pointer and
> this inserted code uses the LR register.
>  As far as I understand,  ARMRegisterInfo.td should exclude the LR
> register from the set of allocatable registers for functions that
> require frame pointer manipulation.
>  But currently it is not the case, or?
>
> No, LR is not the frame pointer. It's the link register (caller address). It
> should be available as a general purpose register.

OK.

> The bug is elsewhere. It  has to do with kill / dead markers.
>        %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>        %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>        BX_RET 14, %reg0
> LR is restored here but it's not killed before the end of the block is
> reached.

Hmm. I have no idea about what ARM backend does. My register allocator
just assigns the registers as I explained in my original mail.
Then it lets VirtRegMap.cpp do its job, i.e. it lets it rewrite the
code and replace virtual registers by the assigned physical registers.
You can see the result in the step (3) of my original mail. In my
opinion, it still looks correct. May be this rewriting process does
something wrong?

Then PrologEpilogInserter and some other standard post RA passes are
invoked for the ARM backend. But I have not changed anything there, so
I have no idea what happens.

And, BTW, the instructions you mentioned above are after the
instruction triggering the assertion, which is:
STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) [0x8fc2d68 + 0]

> Should BX_RET use it?

I don't know the semantics of BX_RET on the ARM platform. May be it
uses BX_RET somehow.

BTW, an idea: May be it is easy to trigger exactly the same behaviour
with the linear scan if one does the following:
  - comment out dependency on the coalescer, so that it is not invoked
  - change the allocation order of the GPR register class for ARM, so
that it starts with the LR register.
,
Any ideas how to proceed with the current situation?

-Roman

>  I hope that I provided enough information to explain my problem. I
> also provided my initial analysis, but may be I'm wrong.
>
>  Can someone more knowledgeable in ARM backend and LLVM's register
> allocation framework have a look at it?
>  If it is a bug in the ARM backend, could it be fixed?
>
>  Thanks,
>   Roman
> <bugpoint-reduced-simplified.bc>
>

From viridia at gmail.com  Wed Jan  7 17:11:34 2009
From: viridia at gmail.com (Talin)
Date: Wed, 7 Jan 2009 15:11:34 -0800
Subject: [LLVMdev] LLVM DebugInfoBuilder
In-Reply-To: <B6FB45AB-58E9-471D-A03E-4E6B2C3B140D@apple.com>
References: <alpine.LRH.1.10.0901071221540.19962@pub4.ifh.de>
	<0B93638D-EAB9-45F5-8C03-260213C56A8E@apple.com>
	<d1b71f830901071348k1c87305co4fe30c3c2baeab5e@mail.gmail.com>
	<B6FB45AB-58E9-471D-A03E-4E6B2C3B140D@apple.com>
Message-ID: <d1b71f830901071511t65a27d80h342addf3e7a68323@mail.gmail.com>

Sure. My own compiler doesn't even use it at the moment (I had to rewrite
the code generator, and the new version doesn't yet support debug info.)

On Wed, Jan 7, 2009 at 1:53 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Jan 7, 2009, at 1:48 PM, Talin wrote:
>
> Fine by me :)
>
>
> Is it ok to remove DebugInfoBuilder now?  I don't think that anything in
> the tree is using it, what do you think Talin?
>
> -Chris
>
>
>
> On Wed, Jan 7, 2009 at 1:35 PM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote:
>>
>> > Hi list,
>> > hi Talin,
>> >
>> > I'm working on a frontend to generate IR using the IRBuilder from
>> > LLVM.
>> >
>> > Now I want to add source-level-debuginfo and for that I would like
>> > to use the
>> > DebugInfoBuilder as it is taking some of the burderns. Unfortunately
>> > it does
>> > not take all of them, yet.
>>
>> Instead of DebugInfoBuilder, I'd strongly recommend taking a look at
>> include/llvm/Analysis/DebugInfo.h.  This is the interface that llvm-
>> gcc and clang both use to produce debug info.  If it's ok with Talin,
>> I'd like to eventually remove DebugInfoBuilder.  Analysis/DebugInfo.h
>> provides a nice and efficient API for both creating and reading debug
>> info, and abstracts the clients from the actual form (e.g. serialized
>> into GlobalVariables) that the debug info takes.
>>
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> --
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/79efab57/attachment.html 

From viridia at gmail.com  Wed Jan  7 17:22:03 2009
From: viridia at gmail.com (Talin)
Date: Wed, 7 Jan 2009 15:22:03 -0800
Subject: [LLVMdev] LLVM DebugInfoBuilder
In-Reply-To: <B6FB45AB-58E9-471D-A03E-4E6B2C3B140D@apple.com>
References: <alpine.LRH.1.10.0901071221540.19962@pub4.ifh.de>
	<0B93638D-EAB9-45F5-8C03-260213C56A8E@apple.com>
	<d1b71f830901071348k1c87305co4fe30c3c2baeab5e@mail.gmail.com>
	<B6FB45AB-58E9-471D-A03E-4E6B2C3B140D@apple.com>
Message-ID: <d1b71f830901071522g15fd7e45j9203c465ec84364a@mail.gmail.com>

Looking at DebugInfo.h, there are a couple of minor features that
DebugInfoBuilder that I would miss:
1) The ability to pass in an LLVM type and have it figure out the size,
alignment, etc. without having to explicitly pass those values in as
parameters to the builder call.

2) The ability for the size & alignment to be specified as Constants rather
than as int64 so that the "gep trick" can be used to generate
target-agnostic debug info. (I don't know if there are other aspects of the
debug info which would prevent it from being target-agnostic.)

-- Talin

On Wed, Jan 7, 2009 at 1:53 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Jan 7, 2009, at 1:48 PM, Talin wrote:
>
> Fine by me :)
>
>
> Is it ok to remove DebugInfoBuilder now?  I don't think that anything in
> the tree is using it, what do you think Talin?
>
> -Chris
>
>
>
> On Wed, Jan 7, 2009 at 1:35 PM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote:
>>
>> > Hi list,
>> > hi Talin,
>> >
>> > I'm working on a frontend to generate IR using the IRBuilder from
>> > LLVM.
>> >
>> > Now I want to add source-level-debuginfo and for that I would like
>> > to use the
>> > DebugInfoBuilder as it is taking some of the burderns. Unfortunately
>> > it does
>> > not take all of them, yet.
>>
>> Instead of DebugInfoBuilder, I'd strongly recommend taking a look at
>> include/llvm/Analysis/DebugInfo.h.  This is the interface that llvm-
>> gcc and clang both use to produce debug info.  If it's ok with Talin,
>> I'd like to eventually remove DebugInfoBuilder.  Analysis/DebugInfo.h
>> provides a nice and efficient API for both creating and reading debug
>> info, and abstracts the clients from the actual form (e.g. serialized
>> into GlobalVariables) that the debug info takes.
>>
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> --
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/f072d0ec/attachment-0001.html 

From dpatel at apple.com  Wed Jan  7 17:48:51 2009
From: dpatel at apple.com (Devang Patel)
Date: Wed, 7 Jan 2009 15:48:51 -0800
Subject: [LLVMdev] LLVM DebugInfoBuilder
In-Reply-To: <d1b71f830901071522g15fd7e45j9203c465ec84364a@mail.gmail.com>
References: <alpine.LRH.1.10.0901071221540.19962@pub4.ifh.de>
	<0B93638D-EAB9-45F5-8C03-260213C56A8E@apple.com>
	<d1b71f830901071348k1c87305co4fe30c3c2baeab5e@mail.gmail.com>
	<B6FB45AB-58E9-471D-A03E-4E6B2C3B140D@apple.com>
	<d1b71f830901071522g15fd7e45j9203c465ec84364a@mail.gmail.com>
Message-ID: <8FAAF004-ACE6-4325-A795-D2EDA20687E7@apple.com>

DebugInfo.h is very light weight interface that allows one to  
manipulate llvm values that holds debugging information directly.

On Jan 7, 2009, at 3:22 PM, Talin wrote:

> Looking at DebugInfo.h, there are a couple of minor features that  
> DebugInfoBuilder that I would miss:
>
> 1) The ability to pass in an LLVM type and have it figure out the  
> size, alignment, etc. without having to explicitly pass those values  
> in as parameters to the builder call.

This can be added. But note, LLVM type lose lots info that can be  
expressed in a debugging information format like DWARF.

>
> 2) The ability for the size & alignment to be specified as Constants  
> rather than as int64 so that the "gep trick" can be used to generate  
> target-agnostic debug info. (I don't know if there are other aspects  
> of the debug info which would prevent it from being target-agnostic.)


-
Devang

>
> -- Talin
>
> On Wed, Jan 7, 2009 at 1:53 PM, Chris Lattner <clattner at apple.com>  
> wrote:
>
> On Jan 7, 2009, at 1:48 PM, Talin wrote:
>
>> Fine by me :)
>
> Is it ok to remove DebugInfoBuilder now?  I don't think that  
> anything in the tree is using it, what do you think Talin?
>
> -Chris
>
>>
>>
>> On Wed, Jan 7, 2009 at 1:35 PM, Chris Lattner <clattner at apple.com>  
>> wrote:
>>
>> On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote:
>>
>> > Hi list,
>> > hi Talin,
>> >
>> > I'm working on a frontend to generate IR using the IRBuilder from
>> > LLVM.
>> >
>> > Now I want to add source-level-debuginfo and for that I would like
>> > to use the
>> > DebugInfoBuilder as it is taking some of the burderns.  
>> Unfortunately
>> > it does
>> > not take all of them, yet.
>>
>> Instead of DebugInfoBuilder, I'd strongly recommend taking a look at
>> include/llvm/Analysis/DebugInfo.h.  This is the interface that llvm-
>> gcc and clang both use to produce debug info.  If it's ok with Talin,
>> I'd like to eventually remove DebugInfoBuilder.  Analysis/DebugInfo.h
>> provides a nice and efficient API for both creating and reading debug
>> info, and abstracts the clients from the actual form (e.g. serialized
>> into GlobalVariables) that the debug info takes.
>>
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>> -- 
>> -- Talin
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> -- 
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-
Devang



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/72bbec42/attachment.html 

From tjablin at CS.Princeton.EDU  Wed Jan  7 19:29:16 2009
From: tjablin at CS.Princeton.EDU (Thomas B. Jablin)
Date: Wed, 7 Jan 2009 20:29:16 -0500 (EST)
Subject: [LLVMdev] insertAfter method Patch
In-Reply-To: <1956725159.1290671231378044406.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU>
Message-ID: <1676105101.1290691231378156126.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU>

Hi,
I have added an insertAfter method to the ilist and Instruction classes. The methods are implemented as efficiently as the currently existing insert and insertBefore methods. The insertAfter method was created to mirror a similar method in another compiler in order to ease an ongoing port. The patch, which is very small is included as AddInsertBefore.patch. Additionally, I wrote a small test pass which demonstrates the correctness of insertAfter and have attached it as ScratchPass.cpp. Thanks.
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AddInsertAfter.patch
Type: text/x-diff
Size: 1874 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/40cad26d/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScratchPass.cpp
Type: text/x-c++src
Size: 1552 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/40cad26d/attachment-0001.bin 

From manoel at fonetica.com.br  Thu Jan  8 04:19:46 2009
From: manoel at fonetica.com.br (=?ISO-8859-1?Q?Manoel=20Teixeira?=)
Date: Thu,  8 Jan 2009 08:19:46 -0200
Subject: [LLVMdev] LLVMdev Digest, Vol 55, Issue 16
In-Reply-To: <mailman.333.1231364159.19801.llvmdev@cs.uiuc.edu>
References: <mailman.333.1231364159.19801.llvmdev@cs.uiuc.edu>
Message-ID: <20090108101946.28918.qmail@hm885.locaweb.com.br>

 1. Re: LLVM optmization (Bill Wendling)

  Hi,
  The IR is not wrong. I said that the assembler generated by MSVC is quicker. We can see that the for loop, in the TESTE function, is done without jump's in the MSVC and with jumps in LLVM. I think thats the point.
  If we don't use threads, the result is the same. My test were done with one billion interactions in the for loop. The MSVC spent  47 miliseconds and the LLVM version 32 seconds.
  Thanks,

Manoel Teixeira







Wed, 07 Jan 2009 15:35:59 -0600, llvmdev-request at cs.uiuc.edu escreveu:

> Send LLVMdev mailing list submissions to
> 	llvmdev at cs.uiuc.edu
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> or, via email, send a message with subject or body 'help' to
> 	llvmdev-request at cs.uiuc.edu
> 
> You can reach the person managing the list at
> 	llvmdev-owner at cs.uiuc.edu
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of LLVMdev digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: LLVM optmization (Bill Wendling)
>    2. Re: opt pass plugins on Windows? (Martin Tofall)
>    3. Re: Private headers and testing (Misha Brukman)
>    4. Re: Private headers and testing (Chris Lattner)
>    5. Re: LLVM DebugInfoBuilder (Chris Lattner)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 7 Jan 2009 11:40:02 -0800
> From: "Bill Wendling" <isanbard at gmail.com>
> Subject: Re: [LLVMdev] LLVM optmization
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Message-ID:
> 	<16e5fdf90901071140y3db1a899o9906828b0058303c at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Wed, Jan 7, 2009 at 2:56 AM, Manoel Teixeira <manoel at fonetica.com.br> wrote:
> >
> > The following C test program was  compiled using LLVM with -O3 option  and MSVC with /O2.
> > The MSVC one is about 600 times faster than the one compiled with the LLVM.
> > We can see that the for loop in MSVC assembler is solved in the optimization pass more efficiently than that in LLVM.
> > Is there an way to get a optimization result in LLVM like that of the MSVC?
> > Manoel Teixeira
> >
> > #include <windows.h>
> > #include <stdio.h>
> >
> > int  TESTE ( int  parami ,int  paraml ,double  paramd  )
> > {
> >  int varx=0,vary=0;
> >  int nI =0;
> >
> >    if( parami > 0  )
> >        {
> >   varx = parami;
> >   vary = 0;
> >        }
> >  else
> >  {
> >   varx = 0;
> >   vary = paraml;
> >  }
> >  for( nI = 1 ;   nI <=  paraml; nI++)
> >  {
> >    varx =  varx + parami + 1 ;
> >        vary =  varx + nI;
> >  }
> >
> > return varx ;
> > }
> > unsigned long thread_call( LPVOID c )
> > {
> >        int num = 1;
> >        int (*fp)(int, int, double) = (int (*)(int, int,double)) c;
> >        //printf("\n(1)threadid =  %ld seqt=%ld inum=%d",GetCurrentThreadId(),num,inum);
> >        int ret = fp(num,1000000000,1);
> >        printf("\n(2)leu %ld threadid =  %ld seqt=%ld ",ret , GetCurrentThreadId(),num);
> >        return (unsigned long) ret;
> > }
> > ///cronometro
> > unsigned long tini;
> > unsigned long tfim;
> > #define getmilisecs(x) (x)
> > #define num_th 100
> > unsigned long milisecs() { return getmilisecs(tfim-tini);};
> > unsigned long secs() { return milisecs()/1000;};
> > const char *spenttime ()
> > {
> >        static char buffer[64];
> >        unsigned long systime                   =        secs();
> >        unsigned long milisectime               =        milisecs()%1000;
> >        sprintf(buffer,"%02d:%02d:%02d:%03d",systime/3600,(systime%3600)/60,(systime%3600)%60,milisectime);
> >        return (const char*) buffer;
> > };
> > //fim cronometro
> > int main(int a, char **b)
> > {
> >  int i;
> >  DWORD  iThreadId;
> >  HANDLE mainThread[num_th];
> >  tfim   =       0;
> >  tini   =       GetTickCount();
> 
> You're starting your count ...
> 
> >  for(i=0;       i<      num_th;i++)
> >                mainThread[i] = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)thread_call, (LPVOID)TESTE, 0, (DWORD *)&iThreadId);
> >
> While doing a thread create method (which I don't have on my darwin
> box) that calls "printf". "printf" is I/O bound and makes for a lousy
> performance test.
> 
> Nevertheless, I've attached the .s file generated by LLVM from the IR
> you gave. I can't see anything obviously wrong with it. Please point
> out in it which parts are 600x slower than on Windows. I'm not able to
> run it because I don't have a Windows box, and it requires some
> Windows calls.
> 
> Note: The ASM is for a Darwin box. I didn't generate this code with
> frame pointers disabled. This would improve performance, but you
> didn't mention that you did the same for your Windows compile.
> 
> -bw
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: y.s
> Type: application/octet-stream
> Size: 3984 bytes
> Desc: not available
> Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/2f929f53/attachment-0001.obj 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 7 Jan 2009 21:37:36 +0100
> From: Martin Tofall <obsidium at uni-paderborn.de>
> Subject: Re: [LLVMdev] opt pass plugins on Windows?
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <315912191.20090107213736 at uni-paderborn.de>
> Content-Type: text/plain; charset=iso-8859-15
> 
> Hello,
> 
> this is just a quick follow-up to my previous email. I now tried
> statically linking the 'hello' pass to opt which does seem to work.
> But I'm not sure if this is reliable or if I'm bound to run into
> problems later, so any comments on this issue would be appreciated.
> 
> Martin
> 
> Wednesday, January 7, 2009, 2:54:52 AM, you wrote:
> 
> MT> Hello,
> 
> MT> I'm just starting out with LLVM, currently using Visual Studio on
> MT> Windows. Now I'd like to write a custom pass that can be loaded
> MT> dynamically as demonstrated in the 'hello world' tutorial.
> MT> So far my DLL loads OK but the actual pass registration does not seem
> MT> to work.
> MT> My question then is (as I could not find any information on the
> MT> subject): is this even possible on win32 or will I have to move to a
> MT> different development platform?
> 
> MT> Thanks,
> MT> Martin
> 
> MT> _______________________________________________
> MT> LLVM Developers mailing list
> MT> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> MT> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 7 Jan 2009 16:29:09 -0500
> From: "Misha Brukman" <brukman at gmail.com>
> Subject: Re: [LLVMdev] Private headers and testing
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Message-ID:
> 	<f88b89a50901071329h2673c0c0t17853ca0bccfc01f at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 2009/1/3 Chris Lattner <clattner at apple.com>
> 
> > On Jan 2, 2009, at 1:48 PM, Misha Brukman wrote:
> >
> > 2009/1/2 Chris Lattner <clattner at apple.com>
> >
> >> On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:
> >> Do you have a specific example of a unit test that would need these?  I
> >> really think these should stay private.
> >>
> >
> > Let's take lib/Transforms/Utils/CodeExtractor.cpp .  The public interface
> > for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the
> > high-level API.
> >
> > If I want to test some corner-case (consider the number of code paths in
> > that code), I have to strain to come up with some combination of a Function
> > and input BasicBlocks that will fit all the conditions from the outset.  Or,
> > I can just feed each individual method in the class exactly the corner cases
> > I will want it to handle, and verify its output (or side effects) exactly,
> > to make sure I pin-pointed the issue.
> >
> > Sure, ok.  But that is a public API, I'm specifically interested in cases
> > you need private API.
> >
> 
> I'm not sure I understand what you mean.  What I am saying is that I want to
> expose the innards of CodeExtractor.cpp in a header file, #include that in
> the unittest, and move the implementation out of an anonymous namespace into
> llvm::transforms::utils, or llvm::internal::transforms::utils, or similar,
> so it can be unit-tested.  This is not about exposing the private API to
> end-users of LLVM or even other LLVM libraries, just unittests.
> 
> The public API, while useful to the end-user, is limiting when it comes to
> unit-testing.  "Unit" in this case is a single method of the actual
> implementation (i.e., a method of the CodeExtractor class), not a single
> function call of the high-level exported public API, which will exercise the
> entire class and its many methods.
> 
> Misha
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/f76ef1b4/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 7 Jan 2009 13:33:40 -0800
> From: Chris Lattner <clattner at apple.com>
> Subject: Re: [LLVMdev] Private headers and testing
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <4BF5104C-E12E-4D2B-A72C-2AF35D939B83 at apple.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> On Jan 7, 2009, at 1:29 PM, Misha Brukman wrote:
> 
> > 2009/1/3 Chris Lattner <clattner at apple.com>
> > On Jan 2, 2009, at 1:48 PM, Misha Brukman wrote:
> >> 2009/1/2 Chris Lattner <clattner at apple.com>
> >> On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:
> >> Do you have a specific example of a unit test that would need  
> >> these?  I really think these should stay private.
> >>
> >> Let's take lib/Transforms/Utils/CodeExtractor.cpp .  The public  
> >> interface for it is in include/llvm/Transform/Utils/ 
> >> FunctionUtils.h, with only the high-level API.
> >>
> >> If I want to test some corner-case (consider the number of code  
> >> paths in that code), I have to strain to come up with some  
> >> combination of a Function and input BasicBlocks that will fit all  
> >> the conditions from the outset.  Or, I can just feed each  
> >> individual method in the class exactly the corner cases I will want  
> >> it to handle, and verify its output (or side effects) exactly, to  
> >> make sure I pin-pointed the issue.
> > Sure, ok.  But that is a public API, I'm specifically interested in  
> > cases you need private API.
> >
> > I'm not sure I understand what you mean.  What I am saying is that I  
> > want to expose the innards of CodeExtractor.cpp in a header file,  
> > #include that in the unittest, and move the implementation out of an  
> > anonymous namespace into llvm::transforms::utils, or  
> > llvm::internal::transforms::utils, or similar, so it can be unit- 
> > tested.  This is not about exposing the private API to end-users of  
> > LLVM or even other LLVM libraries, just unittests.
> >
> > The public API, while useful to the end-user, is limiting when it  
> > comes to unit-testing.  "Unit" in this case is a single method of  
> > the actual implementation (i.e., a method of the CodeExtractor  
> > class), not a single function call of the high-level exported public  
> > API, which will exercise the entire class and its many methods.
> 
> I am pretty strongly against that.  Specifically for CodeExtractor,  
> what benefit do you gain by doing this?
> 
> -Chris
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/5ca6e9a1/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 7 Jan 2009 13:35:50 -0800
> From: Chris Lattner <clattner at apple.com>
> Subject: Re: [LLVMdev] LLVM DebugInfoBuilder
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <0B93638D-EAB9-45F5-8C03-260213C56A8E at apple.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> 
> 
> On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote:
> 
> > Hi list,
> > hi Talin,
> >
> > I'm working on a frontend to generate IR using the IRBuilder from  
> > LLVM.
> >
> > Now I want to add source-level-debuginfo and for that I would like  
> > to use the
> > DebugInfoBuilder as it is taking some of the burderns. Unfortunately  
> > it does
> > not take all of them, yet.
> 
> Instead of DebugInfoBuilder, I'd strongly recommend taking a look at  
> include/llvm/Analysis/DebugInfo.h.  This is the interface that llvm- 
> gcc and clang both use to produce debug info.  If it's ok with Talin,  
> I'd like to eventually remove DebugInfoBuilder.  Analysis/DebugInfo.h  
> provides a nice and efficient API for both creating and reading debug  
> info, and abstracts the clients from the actual form (e.g. serialized  
> into GlobalVariables) that the debug info takes.
> 
> -Chris
> 
> 
> ------------------------------
> 
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> End of LLVMdev Digest, Vol 55, Issue 16
> ***************************************
> 
> 
> 
> 

From vladimir.guzma at tut.fi  Thu Jan  8 05:14:21 2009
From: vladimir.guzma at tut.fi (=?ISO-8859-15?Q?Vladim=EDr_Guzma?=)
Date: Thu, 08 Jan 2009 13:14:21 +0200
Subject: [LLVMdev] opt pass plugins on Windows?
In-Reply-To: <315912191.20090107213736@uni-paderborn.de>
References: <878621325.20090107025452@uni-paderborn.de>
	<315912191.20090107213736@uni-paderborn.de>
Message-ID: <4965E00D.7070809@tut.fi>

Hello,

What kind of error did you get with your first try with opt and Hello pass?
Is it somehow similar to errors reported in bug 2771?

Best regards,
Vlado

> Hello,
> 
> this is just a quick follow-up to my previous email. I now tried
> statically linking the 'hello' pass to opt which does seem to work.
> But I'm not sure if this is reliable or if I'm bound to run into
> problems later, so any comments on this issue would be appreciated.
> 
> Martin
> 
> Wednesday, January 7, 2009, 2:54:52 AM, you wrote:
> 
> MT> Hello,
> 
> MT> I'm just starting out with LLVM, currently using Visual Studio on
> MT> Windows. Now I'd like to write a custom pass that can be loaded
> MT> dynamically as demonstrated in the 'hello world' tutorial.
> MT> So far my DLL loads OK but the actual pass registration does not seem
> MT> to work.
> MT> My question then is (as I could not find any information on the
> MT> subject): is this even possible on win32 or will I have to move to a
> MT> different development platform?
> 
> MT> Thanks,
> MT> Martin
> 
> MT> _______________________________________________
> MT> LLVM Developers mailing list
> MT> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> MT> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From syoyofujita at gmail.com  Thu Jan  8 06:36:09 2009
From: syoyofujita at gmail.com (Syoyo Fujita)
Date: Thu, 8 Jan 2009 21:36:09 +0900
Subject: [LLVMdev] Loop elimination with floating point counter.
Message-ID: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>

Hi LLVM-ers,

I'd like to eliminate dead loop with floating point counter using
LLVM, but the following loop wasn't optimized by opt.

void
func() {
    float i;
    for (i = 0.0f; i < 1000.0f; i += 1.2f) {
    }
}

$ clang -emit-llvm-bc floop.c
$ opt -std-compile-opts floop.bc | llvm-dis

define void @func(...) nounwind  {
entry:
	br label %forinc

forinc:		; preds = %forinc, %entry
	%i.0.reg2mem.0 = phi float [ 0.000000e+00, %entry ], [ %add, %forinc
]	; <float> [#uses=1]
	%add = add float %i.0.reg2mem.0, 0x3FF3333340000000		; <float> [#uses=2]
	%cmp = fcmp olt float %add, 1.000000e+03		; <i1> [#uses=1]
	br i1 %cmp, label %forinc, label %afterfor

afterfor:		; preds = %forinc
	ret void
}

What I expected is just one instruction "ret void" in function "func".

Should I specify some specific optimizer pass for opt?
If so, what is the right optimization pass to specify for opt to
remove dead loop with floating point counter?

I've tested some loop optimization pass, e.g. -licm, -loop-deletion,
but nothing takes effect.

FYI, gcc -O3 also can't optimize such a loop, but icc -O3 can.

LLVM and clang used are recent version from svn.

Thanks in advance.

--
Syoyo

From Sanjiv.Gupta at microchip.com  Thu Jan  8 08:26:38 2009
From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com)
Date: Thu, 8 Jan 2009 07:26:38 -0700
Subject: [LLVMdev] PIC16 backend for llvm 2.5
Message-ID: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>

Hi Duncan,

We are targetting a reasonably functional PIC16 backend for llvm 2.5.
The only problem in our way is a local patch in ExpandIntegerOperand, which couldn't make its way to trunk so far. The discussion is contained in the following link:

 http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081103/069593.html

I now have time to take it up again and do whatever rework is required. I saw that you have made some changes  in the legalizer recently; let me know if the same discussion in the above thread still holds good and whether we can start working on it as described therein.

Thanks
- Sanjiv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090108/9b59f974/attachment.html 

From criswell at cs.uiuc.edu  Thu Jan  8 09:05:30 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 8 Jan 2009 09:05:30 -0600
Subject: [LLVMdev] insertAfter method Patch
In-Reply-To: <1676105101.1290691231378156126.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU>
References: <1676105101.1290691231378156126.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU>
Message-ID: <4966163A.2010601@cs.uiuc.edu>

Thomas B. Jablin wrote:
> Hi,
> I have added an insertAfter method to the ilist and Instruction classes. The methods are implemented as efficiently as the currently existing insert and insertBefore methods. The insertAfter method was created to mirror a similar method in another compiler in order to ease an ongoing port. The patch, which is very small is included as AddInsertBefore.patch. Additionally, I wrote a small test pass which demonstrates the correctness of insertAfter and have attached it as ScratchPass.cpp. Thanks.
> Tom

Small nitpick: in Instruction.cpp, the comment for insertAfter says 
insertBefore and not insertAfter.
:)

-- John T.


From baldrick at free.fr  Thu Jan  8 09:11:02 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 8 Jan 2009 16:11:02 +0100
Subject: [LLVMdev] PIC16 backend for llvm 2.5
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <200901081611.02513.baldrick@free.fr>

Hi Sanjiv,

> We are targetting a reasonably functional PIC16 backend for llvm 2.5.
> The only problem in our way is a local patch in ExpandIntegerOperand, which couldn't make its way to trunk so far. The discussion is contained in the following link:
> 
>  http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081103/069593.html
> 
> I now have time to take it up again and do whatever rework is required. I saw that you have made some changes  in the legalizer recently; let me know if the same discussion in the above thread still holds good and whether we can start working on it as described therein.

I don't remember what the discussion was about any more.  The link doesn't
contain much.  Anyway, as you may have noticed I changed the definition of
the target hook "ReplaceNodeResults".  Probably the same method, or one
with a similar definition, should be used for custom lowering in the case
of an illegal operand.  Would this solve your problem?

Ciao,

Duncan.

From tjablin at cs.princeton.edu  Thu Jan  8 09:15:19 2009
From: tjablin at cs.princeton.edu (Thomas Jablin)
Date: Thu, 08 Jan 2009 10:15:19 -0500
Subject: [LLVMdev] insertAfter method Patch
In-Reply-To: <4966163A.2010601@cs.uiuc.edu>
References: <1676105101.1290691231378156126.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU>
	<4966163A.2010601@cs.uiuc.edu>
Message-ID: <49661887.3090702@cs.princeton.edu>

John Criswell wrote:
> Small nitpick: in Instruction.cpp, the comment for insertAfter says 
> insertBefore and not insertAfter.
> :)
>
> -- John T.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   

Thanks for spotting the problem. Looking at the code again, I made the 
same mistake in the comment in Instruction.h.  Here is the patch with 
the corrected comments.
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AddInsertAfter.patch
Type: text/x-patch
Size: 1872 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090108/209a8a13/attachment.bin 

From dpatel at apple.com  Thu Jan  8 09:42:31 2009
From: dpatel at apple.com (Devang Patel)
Date: Thu, 8 Jan 2009 07:42:31 -0800
Subject: [LLVMdev] Loop elimination with floating point counter.
In-Reply-To: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
References: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
Message-ID: <C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>


On Jan 8, 2009, at 4:36 AM, Syoyo Fujita wrote:

> Hi LLVM-ers,
>
> I'd like to eliminate dead loop with floating point counter using
> LLVM, but the following loop wasn't optimized by opt.
>
> void
> func() {
>    float i;
>    for (i = 0.0f; i < 1000.0f; i += 1.2f) {
>    }
> }

FWIW, LLVM optimizer can eliminate this loop if i is incremented by 1.0f

Pl. file a bugzilla report.
Thanks,
-
Devang
>
>
> $ clang -emit-llvm-bc floop.c
> $ opt -std-compile-opts floop.bc | llvm-dis
>
> define void @func(...) nounwind  {
> entry:
> 	br label %forinc
>
> forinc:		; preds = %forinc, %entry
> 	%i.0.reg2mem.0 = phi float [ 0.000000e+00, %entry ], [ %add, %forinc
> ]	; <float> [#uses=1]
> 	%add = add float %i.0.reg2mem.0, 0x3FF3333340000000		; <float>  
> [#uses=2]
> 	%cmp = fcmp olt float %add, 1.000000e+03		; <i1> [#uses=1]
> 	br i1 %cmp, label %forinc, label %afterfor
>
> afterfor:		; preds = %forinc
> 	ret void
> }
>
> What I expected is just one instruction "ret void" in function "func".
>
> Should I specify some specific optimizer pass for opt?
> If so, what is the right optimization pass to specify for opt to
> remove dead loop with floating point counter?
>
> I've tested some loop optimization pass, e.g. -licm, -loop-deletion,
> but nothing takes effect.
>
> FYI, gcc -O3 also can't optimize such a loop, but icc -O3 can.
>
> LLVM and clang used are recent version from svn.
>
> Thanks in advance.
>
> --
> Syoyo
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




From syoyofujita at gmail.com  Thu Jan  8 11:22:43 2009
From: syoyofujita at gmail.com (Syoyo Fujita)
Date: Fri, 9 Jan 2009 02:22:43 +0900
Subject: [LLVMdev] Loop elimination with floating point counter.
In-Reply-To: <C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>
References: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
	<C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>
Message-ID: <1f06970b0901080922k1e80e4b6ree7239a9ff4c427e@mail.gmail.com>

Hi Devang,

Thanks. Yes, in the case variable i incremented by 1.0f is optimized.
I don't know why...
Anyway, I've filed this problem into bugzilla(Bug 3299)

--
Syoyo

On Fri, Jan 9, 2009 at 12:42 AM, Devang Patel <dpatel at apple.com> wrote:
>
> On Jan 8, 2009, at 4:36 AM, Syoyo Fujita wrote:
>
>> Hi LLVM-ers,
>>
>> I'd like to eliminate dead loop with floating point counter using
>> LLVM, but the following loop wasn't optimized by opt.
>>
>> void
>> func() {
>>    float i;
>>    for (i = 0.0f; i < 1000.0f; i += 1.2f) {
>>    }
>> }
>
> FWIW, LLVM optimizer can eliminate this loop if i is incremented by 1.0f
>
> Pl. file a bugzilla report.
> Thanks,
> -
> Devang
>>
>>
>> $ clang -emit-llvm-bc floop.c
>> $ opt -std-compile-opts floop.bc | llvm-dis
>>
>> define void @func(...) nounwind  {
>> entry:
>>       br label %forinc
>>
>> forinc:               ; preds = %forinc, %entry
>>       %i.0.reg2mem.0 = phi float [ 0.000000e+00, %entry ], [ %add, %forinc
>> ]     ; <float> [#uses=1]
>>       %add = add float %i.0.reg2mem.0, 0x3FF3333340000000             ; <float>
>> [#uses=2]
>>       %cmp = fcmp olt float %add, 1.000000e+03                ; <i1> [#uses=1]
>>       br i1 %cmp, label %forinc, label %afterfor
>>
>> afterfor:             ; preds = %forinc
>>       ret void
>> }
>>
>> What I expected is just one instruction "ret void" in function "func".
>>
>> Should I specify some specific optimizer pass for opt?
>> If so, what is the right optimization pass to specify for opt to
>> remove dead loop with floating point counter?
>>
>> I've tested some loop optimization pass, e.g. -licm, -loop-deletion,
>> but nothing takes effect.
>>
>> FYI, gcc -O3 also can't optimize such a loop, but icc -O3 can.
>>
>> LLVM and clang used are recent version from svn.
>>
>> Thanks in advance.
>>
>> --
>> Syoyo
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From resistor at mac.com  Thu Jan  8 11:34:19 2009
From: resistor at mac.com (Owen Anderson)
Date: Thu, 08 Jan 2009 09:34:19 -0800
Subject: [LLVMdev] Loop elimination with floating point counter.
In-Reply-To: <1f06970b0901080922k1e80e4b6ree7239a9ff4c427e@mail.gmail.com>
References: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
	<C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>
	<1f06970b0901080922k1e80e4b6ree7239a9ff4c427e@mail.gmail.com>
Message-ID: <5296F463-E937-4774-A4DE-26858DA14942@mac.com>

It's because with 1.0f, the loop index is simplified into an integer.   
With 1.2f, it isn't.  The loop deletion pass is dependent on the loop  
analyses being able to determine that the loop is finite, which they  
don't attempt to do for loops with floating point indices.  Attempting  
to do so would require additional reasoning about floating point  
precision issues.

--Owen

On Jan 8, 2009, at 9:22 AM, Syoyo Fujita wrote:

> Hi Devang,
>
> Thanks. Yes, in the case variable i incremented by 1.0f is optimized.
> I don't know why...
> Anyway, I've filed this problem into bugzilla(Bug 3299)
>
> --
> Syoyo
>
> On Fri, Jan 9, 2009 at 12:42 AM, Devang Patel <dpatel at apple.com>  
> wrote:
>>
>> On Jan 8, 2009, at 4:36 AM, Syoyo Fujita wrote:
>>
>>> Hi LLVM-ers,
>>>
>>> I'd like to eliminate dead loop with floating point counter using
>>> LLVM, but the following loop wasn't optimized by opt.
>>>
>>> void
>>> func() {
>>>   float i;
>>>   for (i = 0.0f; i < 1000.0f; i += 1.2f) {
>>>   }
>>> }
>>
>> FWIW, LLVM optimizer can eliminate this loop if i is incremented by  
>> 1.0f
>>
>> Pl. file a bugzilla report.
>> Thanks,
>> -
>> Devang
>>>
>>>
>>> $ clang -emit-llvm-bc floop.c
>>> $ opt -std-compile-opts floop.bc | llvm-dis
>>>
>>> define void @func(...) nounwind  {
>>> entry:
>>>      br label %forinc
>>>
>>> forinc:               ; preds = %forinc, %entry
>>>      %i.0.reg2mem.0 = phi float [ 0.000000e+00, %entry ], [ %add,  
>>> %forinc
>>> ]     ; <float> [#uses=1]
>>>      %add = add float %i.0.reg2mem.0,  
>>> 0x3FF3333340000000             ; <float>
>>> [#uses=2]
>>>      %cmp = fcmp olt float %add, 1.000000e+03                ;  
>>> <i1> [#uses=1]
>>>      br i1 %cmp, label %forinc, label %afterfor
>>>
>>> afterfor:             ; preds = %forinc
>>>      ret void
>>> }
>>>
>>> What I expected is just one instruction "ret void" in function  
>>> "func".
>>>
>>> Should I specify some specific optimizer pass for opt?
>>> If so, what is the right optimization pass to specify for opt to
>>> remove dead loop with floating point counter?
>>>
>>> I've tested some loop optimization pass, e.g. -licm, -loop-deletion,
>>> but nothing takes effect.
>>>
>>> FYI, gcc -O3 also can't optimize such a loop, but icc -O3 can.
>>>
>>> LLVM and clang used are recent version from svn.
>>>
>>> Thanks in advance.
>>>
>>> --
>>> Syoyo
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From mgeisse at gmx.net  Thu Jan  8 11:49:05 2009
From: mgeisse at gmx.net (Martin Geisse)
Date: Thu, 8 Jan 2009 18:49:05 +0100
Subject: [LLVMdev] Loop elimination with floating point counter.
In-Reply-To: <5296F463-E937-4774-A4DE-26858DA14942@mac.com>
References: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
	<C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>
	<1f06970b0901080922k1e80e4b6ree7239a9ff4c427e@mail.gmail.com>
	<5296F463-E937-4774-A4DE-26858DA14942@mac.com>
Message-ID: <759EC041-923A-4F12-9833-26EE246DF42F@gmx.net>

Isn't "simplifying" the loop index to an integer also dependent on  
precision issues? The following loop is infinite:

for (float i=0.0; i<...; i+=1.0) {}

where ... is a large "integral" float literal, e.g. 2^40. At some  
point, adding 1.0 to the loop index would not cause any changes  
because of precision issues. However, if the float type is replaced  
by some sufficiently large integer type, the loop terminates.

The necessary reasoning may be simpler though.

Greetings,
Martin Geisse

On Jan 8, 2009, at 6:34 PM, Owen Anderson wrote:

> It's because with 1.0f, the loop index is simplified into an integer.
> With 1.2f, it isn't.  The loop deletion pass is dependent on the loop
> analyses being able to determine that the loop is finite, which they
> don't attempt to do for loops with floating point indices.  Attempting
> to do so would require additional reasoning about floating point
> precision issues.
>
> --Owen
>

From obsidium at uni-paderborn.de  Thu Jan  8 13:29:58 2009
From: obsidium at uni-paderborn.de (Martin Tofall)
Date: Thu, 8 Jan 2009 20:29:58 +0100
Subject: [LLVMdev] opt pass plugins on Windows?
In-Reply-To: <4965E00D.7070809@tut.fi>
References: <878621325.20090107025452@uni-paderborn.de>
	<315912191.20090107213736@uni-paderborn.de>
	<4965E00D.7070809@tut.fi>
Message-ID: <139544140.20090108202958@uni-paderborn.de>

Hallo,

I did not get any error messages. The DLL is loaded by
DynamicLibrary::LoadLibraryPermanently but it looks like there is no
interface between opt and my DLL, so passes get registered separately
in opt and the DLL. I guess using DLLs simply won't work.

Thanks,
Martin

Thursday, January 8, 2009, 12:14:21 PM, you wrote:

VG> Hello,

VG> What kind of error did you get with your first try with opt and Hello pass?
VG> Is it somehow similar to errors reported in bug 2771?

VG> Best regards,
VG> Vlado

>> Hello,
>> 
>> this is just a quick follow-up to my previous email. I now tried
>> statically linking the 'hello' pass to opt which does seem to work.
>> But I'm not sure if this is reliable or if I'm bound to run into
>> problems later, so any comments on this issue would be appreciated.
>> 
>> Martin
>> 
>> Wednesday, January 7, 2009, 2:54:52 AM, you wrote:
>> 
>> MT> Hello,
>> 
>> MT> I'm just starting out with LLVM, currently using Visual Studio on
>> MT> Windows. Now I'd like to write a custom pass that can be loaded
>> MT> dynamically as demonstrated in the 'hello world' tutorial.
>> MT> So far my DLL loads OK but the actual pass registration does not seem
>> MT> to work.
>> MT> My question then is (as I could not find any information on the
>> MT> subject): is this even possible on win32 or will I have to move to a
>> MT> different development platform?
>> 
>> MT> Thanks,
>> MT> Martin
>> 
>> MT> _______________________________________________
>> MT> LLVM Developers mailing list
>> MT> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> MT> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

VG> _______________________________________________
VG> LLVM Developers mailing list
VG> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
VG> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From bharadwajy at gmail.com  Thu Jan  8 14:51:54 2009
From: bharadwajy at gmail.com (S. Bharadwaj Yadavalli)
Date: Thu, 8 Jan 2009 15:51:54 -0500
Subject: [LLVMdev] Build failure on x86_64
Message-ID: <d8adb8240901081251w63dc079eve0eb3d80759cf68b@mail.gmail.com>

Hello!

I see the following build failure of the sources at the top of the trunk, on
x86_64.

make[2]: Entering directory `<llvm-root>/build/llvm/lib/AsmParser'
llvm[2]: Compiling LLLexer.cpp for Release build
llvm[2]: Compiling LLParser.cpp for Release build
<llvm-root>/src/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool
llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int,
bool, unsigned int)':
<llvm-root>/src/llvm/lib/AsmParser/LLParser.cpp:446: warning: 'IsConstant'
may be used uninitialized in this function
llvm[2]: Compiling Parser.cpp for Release build
llvm[2]: Compiling llvmAsmParser.cpp for Release build
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:15:29: error:
ParserInternals.h: No such file or directory
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:83: error: 'ValID' was
not declared in this scope
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:83: error: template
argument 1 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:83: error: template
argument 3 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:83: error: template
argument 4 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:88: error: 'ValID' was
not declared in this scope
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:88: error: template
argument 1 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:88: error: template
argument 2 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:88: error: template
argument 4 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: 'ValID' was
not declared in this scope
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: template
argument 2 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: template
argument 1 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: template
argument 3 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: template
argument 4 is invalid
<llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:136: error: 'ValID' has
not been declared

<...>

I configured the build as follows:

<llvm-root>/src/llvm/configure
--with-llvmgccdir=<llvm-root>/install/llvm-gcc-4.2 --enable-optimized
--enable-jit --prefix=<llvm-root>/install/llvm

$ svn info
Path: .
URL: http://llvm.org/svn/llvm-project/llvm/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 61936
Node Kind: directory
Schedule: normal
Last Changed Author: lattner
Last Changed Rev: 61934
Last Changed Date: 2009-01-08 14:28:38 -0500 (Thu, 08 Jan 2009)

$ uname -a
Linux <my-hostname> 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008
x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 8.04.1 \n \l

The above configuration has been working with earlier versions (though I am
not sure of the exact version).

Is this a known issue?

Thanks,

Bharadwaj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090108/5b0e37eb/attachment.html 

From bwatt at us.ibm.com  Thu Jan  8 15:31:31 2009
From: bwatt at us.ibm.com (Brian Watt)
Date: Thu, 8 Jan 2009 15:31:31 -0600
Subject: [LLVMdev] Build failure on x86_64
In-Reply-To: <d8adb8240901081251w63dc079eve0eb3d80759cf68b@mail.gmail.com>
Message-ID: <OFAB9A00AB.1F4C41FF-ON86257538.0075F1E5-86257538.00763E7A@us.ibm.com>

Me too, so I removed the old AsmParser directory and re-checked it out 
from SVN to get the latest and the build finished OK.

Brian Watt, IBM

llvmdev-bounces at cs.uiuc.edu wrote on 01/08/2009 02:51:54 PM:

> 
> Hello!
> 
> I see the following build failure of the sources at the top of the 
> trunk, on x86_64.
> 
> make[2]: Entering directory `<llvm-root>/build/llvm/lib/AsmParser'
> llvm[2]: Compiling LLLexer.cpp for Release build 
> llvm[2]: Compiling LLParser.cpp for Release build 
> <llvm-root>/src/llvm/lib/AsmParser/LLParser.cpp: In member function 
> 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, 
> unsigned int, bool, unsigned int)':
> <llvm-root>/src/llvm/lib/AsmParser/LLParser.cpp:446: warning: 
> 'IsConstant' may be used uninitialized in this function
> llvm[2]: Compiling Parser.cpp for Release build 
> llvm[2]: Compiling llvmAsmParser.cpp for Release build 
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:15:29: error: 
> ParserInternals.h: No such file or directory
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:83: error: 
> 'ValID' was not declared in this scope
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:83: error: 
> template argument 1 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:83: error: 
> template argument 3 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:83: error: 
> template argument 4 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:88: error: 
> 'ValID' was not declared in this scope
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:88: error: 
> template argument 1 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:88: error: 
> template argument 2 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:88: error: 
> template argument 4 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: 
> 'ValID' was not declared in this scope
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: 
> template argument 2 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: 
> template argument 1 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: 
> template argument 3 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:96: error: 
> template argument 4 is invalid
> <llvm-root>/src/llvm/lib/AsmParser/llvmAsmParser.y:136: error: 
> 'ValID' has not been declared
> 
> <...>
> 
> I configured the build as follows:
> 
> <llvm-root>/src/llvm/configure  --with-llvmgccdir=<llvm-
> root>/install/llvm-gcc-4.2 --enable-optimized --enable-jit --
> prefix=<llvm-root>/install/llvm
> 
> $ svn info
> Path: .
> URL: http://llvm.org/svn/llvm-project/llvm/trunk
> Repository Root: http://llvm.org/svn/llvm-project
> Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
> Revision: 61936
> Node Kind: directory
> Schedule: normal
> Last Changed Author: lattner
> Last Changed Rev: 61934
> Last Changed Date: 2009-01-08 14:28:38 -0500 (Thu, 08 Jan 2009)
> 
> $ uname -a
> Linux <my-hostname> 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC
> 2008 x86_64 GNU/Linux
> $ cat /etc/issue
> Ubuntu 8.04.1 \n \l
> 
> The above configuration has been working with earlier versions 
> (though I am not sure of the exact version).
> 
> Is this a known issue?
> 
> Thanks,
> 
> Bharadwaj_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090108/75709d2d/attachment.html 

From markleone at gmail.com  Thu Jan  8 15:35:57 2009
From: markleone at gmail.com (Mark Leone)
Date: Thu, 8 Jan 2009 13:35:57 -0800
Subject: [LLVMdev] Integer typedefs for MSVC
Message-ID: <761659910901081335p657312dco31b43df1dec944a7@mail.gmail.com>

LLVM's typedefs for int32_t etc. under MSVC (in Support/DataTypes.h)
conflict with those used by other third-party libraries.  Instead of these:
#ifdef _MSC_VER
typedef __int64 int64_t;
typedef unsigned __int64 uint64_t;
typedef signed int int32_t;
typedef unsigned int uint32_t;
typedef short int16_t;
typedef unsigned short uint16_t;
typedef signed char int8_t;
typedef unsigned char uint8_t;
typedef signed int ssize_t;
#endif

it would be preferable to use these:

typedef __int8 int8_t;
typedef __int16 int16_t;
typedef __int32 int32_t;
typedef __int64 int64_t;
typedef unsigned __int8 uint8_t;
typedef unsigned __int16 uint16_t;
typedef unsigned __int32 uint32_t;
typedef unsigned __int64 uint64_t;

Does anyone feel strongly about this?

- Mark Leone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090108/36618bd6/attachment.html 

From clattner at apple.com  Thu Jan  8 16:42:58 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 8 Jan 2009 14:42:58 -0800
Subject: [LLVMdev] Integer typedefs for MSVC
In-Reply-To: <761659910901081335p657312dco31b43df1dec944a7@mail.gmail.com>
References: <761659910901081335p657312dco31b43df1dec944a7@mail.gmail.com>
Message-ID: <5EF86663-2665-450A-B909-2C81A5502CE4@apple.com>


On Jan 8, 2009, at 1:35 PM, Mark Leone wrote:

> LLVM's typedefs for int32_t etc. under MSVC (in Support/DataTypes.h)  
> conflict with those used by other third-party libraries.  Instead of  
> these:
>
> #ifdef _MSC_VER
> typedef __int64 int64_t;
> typedef unsigned __int64 uint64_t;
> typedef signed int int32_t;
> typedef unsigned int uint32_t;
> typedef short int16_t;
> typedef unsigned short uint16_t;
> typedef signed char int8_t;
> typedef unsigned char uint8_t;
> typedef signed int ssize_t;
> #endif
>
> it would be preferable to use these:
>
> typedef __int8 int8_t;
> typedef __int16 int16_t;
> typedef __int32 int32_t;
> typedef __int64 int64_t;
> typedef unsigned __int8 uint8_t;
> typedef unsigned __int16 uint16_t;
> typedef unsigned __int32 uint32_t;
> typedef unsigned __int64 uint64_t;
>
> Does anyone feel strongly about this?

That sounds fine to me,

-Chris

From wurstgebaeck at googlemail.com  Thu Jan  8 17:46:16 2009
From: wurstgebaeck at googlemail.com (Jan Rehders)
Date: Fri, 9 Jan 2009 00:46:16 +0100
Subject: [LLVMdev] Loop elimination with floating point counter.
In-Reply-To: <759EC041-923A-4F12-9833-26EE246DF42F@gmx.net>
References: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
	<C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>
	<1f06970b0901080922k1e80e4b6ree7239a9ff4c427e@mail.gmail.com>
	<5296F463-E937-4774-A4DE-26858DA14942@mac.com>
	<759EC041-923A-4F12-9833-26EE246DF42F@gmx.net>
Message-ID: <E28DE09A-6651-453B-8F5C-1A796E35D954@gmail.com>

Martin,

> Isn't "simplifying" the loop index to an integer also dependent on
> precision issues? The following loop is infinite:
>
> for (float i=0.0; i<...; i+=1.0) {}
>
> where ... is a large "integral" float literal, e.g. 2^40.

it is. But luckily at least llvm-gcc appears to be smart enough to  
check against the end
value. I've just tested the following snippet (compiled using llvm-gcc  
-c -O3 --emit-llvm)

void foo() {
     float f;
     for( f = 0.0; f < 100.0f; f += 1.0f ) {
     }
}
=>
define void @foo() nounwind readnone {
entry:
	ret void
}

void foo() {
     float f;
     for( f = 0.0; f < 101.0f; f += 1.0f ) {
     }
}
=>
define void @foo() nounwind readnone {
entry:
	br label %bb

bb:		; preds = %bb, %entry
	%f.0.reg2mem.0 = phi float [ 0.000000e+00, %entry ], [ %0, %bb ]		;  
<float> [#uses=1]
	%0 = add float %f.0.reg2mem.0, 1.000000e+00		; <float> [#uses=2]
	%1 = fcmp olt float %0, 1.010000e+02		; <i1> [#uses=1]
	br i1 %1, label %bb, label %return

return:		; preds = %bb
	ret void
}

So everything is fine here

Jan


From resistor at mac.com  Thu Jan  8 18:45:27 2009
From: resistor at mac.com (Owen Anderson)
Date: Thu, 08 Jan 2009 16:45:27 -0800
Subject: [LLVMdev] Loop elimination with floating point counter.
In-Reply-To: <759EC041-923A-4F12-9833-26EE246DF42F@gmx.net>
References: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
	<C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>
	<1f06970b0901080922k1e80e4b6ree7239a9ff4c427e@mail.gmail.com>
	<5296F463-E937-4774-A4DE-26858DA14942@mac.com>
	<759EC041-923A-4F12-9833-26EE246DF42F@gmx.net>
Message-ID: <92381DB0-F6B9-4AD8-8242-7F03B280C132@mac.com>

I assume it checks that the end condition and the increment can both  
be represented precisely with integer types.

--Owen

On Jan 8, 2009, at 9:49 AM, Martin Geisse wrote:

> Isn't "simplifying" the loop index to an integer also dependent on
> precision issues? The following loop is infinite:
>
> for (float i=0.0; i<...; i+=1.0) {}
>
> where ... is a large "integral" float literal, e.g. 2^40. At some
> point, adding 1.0 to the loop index would not cause any changes
> because of precision issues. However, if the float type is replaced
> by some sufficiently large integer type, the loop terminates.
>
> The necessary reasoning may be simpler though.
>
> Greetings,
> Martin Geisse
>
> On Jan 8, 2009, at 6:34 PM, Owen Anderson wrote:
>
>> It's because with 1.0f, the loop index is simplified into an integer.
>> With 1.2f, it isn't.  The loop deletion pass is dependent on the loop
>> analyses being able to determine that the loop is finite, which they
>> don't attempt to do for loops with floating point indices.   
>> Attempting
>> to do so would require additional reasoning about floating point
>> precision issues.
>>
>> --Owen
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From viridia at gmail.com  Thu Jan  8 21:07:06 2009
From: viridia at gmail.com (Talin)
Date: Thu, 08 Jan 2009 19:07:06 -0800
Subject: [LLVMdev] LLVM DebugInfoBuilder
In-Reply-To: <8FAAF004-ACE6-4325-A795-D2EDA20687E7@apple.com>
References: <alpine.LRH.1.10.0901071221540.19962@pub4.ifh.de>	<0B93638D-EAB9-45F5-8C03-260213C56A8E@apple.com>	<d1b71f830901071348k1c87305co4fe30c3c2baeab5e@mail.gmail.com>	<B6FB45AB-58E9-471D-A03E-4E6B2C3B140D@apple.com>	<d1b71f830901071522g15fd7e45j9203c465ec84364a@mail.gmail.com>
	<8FAAF004-ACE6-4325-A795-D2EDA20687E7@apple.com>
Message-ID: <4966BF5A.1000505@gmail.com>

Devang Patel wrote:
> DebugInfo.h is very light weight interface that allows one to 
> manipulate llvm values that holds debugging information directly.
>
> On Jan 7, 2009, at 3:22 PM, Talin wrote:
>
>> Looking at DebugInfo.h, there are a couple of minor features that 
>> DebugInfoBuilder that I would miss:
>>
>> 1) The ability to pass in an LLVM type and have it figure out the 
>> size, alignment, etc. without having to explicitly pass those values 
>> in as parameters to the builder call.
>
> This can be added. But note, LLVM type lose lots info that can be 
> expressed in a debugging information format like DWARF.
I understand - which is why the DebugInfoBuilder class took additional 
parameters to supply the missing information. In other words, instead of 
8 parameters to describe a type, it accepted an LLVM type + 4 additional 
parameters. That also allowed the DebugInfoBuilder to measure the size 
of the type using a constant GEP rather than having the application 
programmer supply a hard-coded size.
>>
>> 2) The ability for the size & alignment to be specified as Constants 
>> rather than as int64 so that the "gep trick" can be used to generate 
>> target-agnostic debug info. (I don't know if there are other aspects 
>> of the debug info which would prevent it from being target-agnostic.)
>
>
> -
> Devang
>
>>
>> -- Talin
>>
>> On Wed, Jan 7, 2009 at 1:53 PM, Chris Lattner <clattner at apple.com> 
>> wrote:
>>
>> On Jan 7, 2009, at 1:48 PM, Talin wrote:
>>
>>> Fine by me :)
>>
>> Is it ok to remove DebugInfoBuilder now?  I don't think that anything 
>> in the tree is using it, what do you think Talin?
>>
>> -Chris
>>
>>>
>>>
>>> On Wed, Jan 7, 2009 at 1:35 PM, Chris Lattner <clattner at apple.com> 
>>> wrote:
>>>
>>> On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote:
>>>
>>> > Hi list,
>>> > hi Talin,
>>> >
>>> > I'm working on a frontend to generate IR using the IRBuilder from
>>> > LLVM.
>>> >
>>> > Now I want to add source-level-debuginfo and for that I would like
>>> > to use the
>>> > DebugInfoBuilder as it is taking some of the burderns. Unfortunately
>>> > it does
>>> > not take all of them, yet.
>>>
>>> Instead of DebugInfoBuilder, I'd strongly recommend taking a look at
>>> include/llvm/Analysis/DebugInfo.h.  This is the interface that llvm-
>>> gcc and clang both use to produce debug info.  If it's ok with Talin,
>>> I'd like to eventually remove DebugInfoBuilder.  Analysis/DebugInfo.h
>>> provides a nice and efficient API for both creating and reading debug
>>> info, and abstracts the clients from the actual form (e.g. serialized
>>> into GlobalVariables) that the debug info takes.
>>>
>>> -Chris
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>>
>>> -- 
>>> -- Talin
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>>
>> -- 
>> -- Talin
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> -
> Devang
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From dberlin at dberlin.org  Thu Jan  8 22:11:51 2009
From: dberlin at dberlin.org (Daniel Berlin)
Date: Thu, 8 Jan 2009 23:11:51 -0500
Subject: [LLVMdev] Loop elimination with floating point counter.
In-Reply-To: <92381DB0-F6B9-4AD8-8242-7F03B280C132@mac.com>
References: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
	<C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>
	<1f06970b0901080922k1e80e4b6ree7239a9ff4c427e@mail.gmail.com>
	<5296F463-E937-4774-A4DE-26858DA14942@mac.com>
	<759EC041-923A-4F12-9833-26EE246DF42F@gmx.net>
	<92381DB0-F6B9-4AD8-8242-7F03B280C132@mac.com>
Message-ID: <4aca3dc20901082011u74266dc2mf88e3490a6145e01@mail.gmail.com>

FWIW, I believe icc -O3 turns on the equivalent of -ffast-math by default.
I could be misremembering which compilers do this though :)
This flag allows you to make all kinds of nice simplfiying assumptions
about floating point.

On Thu, Jan 8, 2009 at 7:45 PM, Owen Anderson <resistor at mac.com> wrote:
> I assume it checks that the end condition and the increment can both
> be represented precisely with integer types.
>
> --Owen
>
> On Jan 8, 2009, at 9:49 AM, Martin Geisse wrote:
>
>> Isn't "simplifying" the loop index to an integer also dependent on
>> precision issues? The following loop is infinite:
>>
>> for (float i=0.0; i<...; i+=1.0) {}
>>
>> where ... is a large "integral" float literal, e.g. 2^40. At some
>> point, adding 1.0 to the loop index would not cause any changes
>> because of precision issues. However, if the float type is replaced
>> by some sufficiently large integer type, the loop terminates.
>>
>> The necessary reasoning may be simpler though.
>>
>> Greetings,
>> Martin Geisse
>>
>> On Jan 8, 2009, at 6:34 PM, Owen Anderson wrote:
>>
>>> It's because with 1.0f, the loop index is simplified into an integer.
>>> With 1.2f, it isn't.  The loop deletion pass is dependent on the loop
>>> analyses being able to determine that the loop is finite, which they
>>> don't attempt to do for loops with floating point indices.
>>> Attempting
>>> to do so would require additional reasoning about floating point
>>> precision issues.
>>>
>>> --Owen
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From Sanjiv.Gupta at microchip.com  Thu Jan  8 22:23:41 2009
From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com)
Date: Thu, 8 Jan 2009 21:23:41 -0700
Subject: [LLVMdev] PIC16 backend for llvm 2.5
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
	<200901081611.02513.baldrick@free.fr>
Message-ID: <F536B7C316F9474E9F7091239725AC9A4E900B@CHN-CL-MAIL01.mchp-main.com>

Well, the first email is here.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068667.html



-----Original Message-----
From: Duncan Sands [mailto:baldrick at free.fr]
Sent: Thu 1/8/2009 8:41 PM
To: Sanjiv Kumar Gupta - I00171
Cc: llvmdev at cs.uiuc.edu
Subject: Re: PIC16 backend for llvm 2.5
 
Hi Sanjiv,

> We are targetting a reasonably functional PIC16 backend for llvm 2.5.
> The only problem in our way is a local patch in ExpandIntegerOperand, which couldn't make its way to trunk so far. The discussion is contained in the following link:
> 
>  http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081103/069593.html
> 
> I now have time to take it up again and do whatever rework is required. I saw that you have made some changes  in the legalizer recently; let me know if the same discussion in the above thread still holds good and whether we can start working on it as described therein.

I don't remember what the discussion was about any more.  The link doesn't
contain much.  Anyway, as you may have noticed I changed the definition of
the target hook "ReplaceNodeResults".  Probably the same method, or one
with a similar definition, should be used for custom lowering in the case
of an illegal operand.  Would this solve your problem?

Ciao,

Duncan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090108/7d64a581/attachment.html 

From romix.llvm at googlemail.com  Fri Jan  9 03:36:15 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Fri, 9 Jan 2009 10:36:15 +0100
Subject: [LLVMdev] Is it possible to use the SimpleRegisterCoalescing pass
	in an iterative way?
Message-ID: <e50173bd0901090136n5c7337fcs8e1ab01d8bacd6b1@mail.gmail.com>

Hi,

I'm implementing some variations of graph-coloring register allocators for LLVM.
Many of them perform their phases (e.g. coalescing, graph
simplification, spilling,  color selection) in an iterative way. Since
LLVM provides an implementation of the coalescing in the
SimpleRegisterCoalescing class already, I would like to reuse it (even
though I could of course create my own coalescing implementation). But
this class is a MachineFunctionPass.

I'm wondering, if it is possible to use this pass from another pass
(i.e. regalloc) in an iterative way:
I need to invoke it multiple times for the same MachineFunction at
certain places in my regalloc pass implementation.
May be some sort of analysis update can be performed? Or is it
designed to be used just once per MachineFunction?

Also overall, it would be interesting to know how LLVM supports such
kind of iterative algorithms? What are the ways to formulate the
independent phases of those algorithms as reusable passes that could
be used in an iterative way?

Thanks,
-Roman

From Christian.Sayer at dibcom.fr  Fri Jan  9 04:50:57 2009
From: Christian.Sayer at dibcom.fr (Christian Sayer)
Date: Fri, 9 Jan 2009 11:50:57 +0100
Subject: [LLVMdev] implicit CC register Defs cause "physreg was not killed
 in defining block!" assert
Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4AE9D9D380FD@FRPAR1CL009.coe.adi.dibcom.com>

Hello,

For my backend, I define and use a CC register similiarly to the EFLAGS register in X86 (I call it CCFLAGS).
But if I make all arithmetic/logic instructions affect it ('let Defs = [CCFLAGS] in...' in InstrInfo.td) I run into

  // The only case we should have a dead physreg here without a killing or
  // instruction where we know it's dead is if it is live-in to the function
  // and never used.
  assert(!CopyMI && "physreg was not killed in defining block!");

in LiveIntervals::handlePhysicalRegisterDef().

The dump() of the MBB from the debugger looks like the following:

entry.ifcont267_crit_edge: 0x12bc368, LLVM BB @0x12bb900, ID#2:
    Predecessors according to CFG: 0x12bc290 (#0) 0x12bca70 (#1)
        %reg1033<def> = addC %reg1025<kill>, 0, %CCFLAGS<imp-def,dead>
        %reg1032<def> = addC %reg1024<kill>, 0, %CCFLAGS<imp-def,dead>
        %reg1095<def> = addC %reg1028, 0, %CCFLAGS<imp-def>
        %reg1096<def> = addC %reg1029<kill>, 0, %CCFLAGS<imp-def>
        %reg1097<def> = addC %reg1033<kill>, 0, %CCFLAGS<imp-def>
        %reg1098<def> = addC %reg1028<kill>, 0, %CCFLAGS<imp-def>
        %reg1099<def> = addC %reg1031<kill>, 0, %CCFLAGS<imp-def>
        %reg1100<def> = addC %reg1030, 0, %CCFLAGS<imp-def>
        %reg1101<def> = addC %reg1032<kill>, 0, %CCFLAGS<imp-def>
        %reg1102<def> = addC %reg1030<kill>, 0, %CCFLAGS<imp-def>
        br mbb<ifcont267,0x12bc518>
    Successors according to CFG: 0x12bc518 (#4)



Do you have any idea what could be wrong, or how to further debug the problem?

Thanks a lot,
Christian


 --







sorry about that, but there is nothing I can do about it:

CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you.


From baldrick at free.fr  Fri Jan  9 05:53:23 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 9 Jan 2009 12:53:23 +0100
Subject: [LLVMdev] PIC16 backend for llvm 2.5
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A4E900B@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
	<200901081611.02513.baldrick@free.fr>
	<F536B7C316F9474E9F7091239725AC9A4E900B@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <200901091253.24536.baldrick@free.fr>

Hi Sanjiv,

> Well, the first email is here.
> 
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068667.html

thanks, I remember now (more or less).  So would something like ReplaceNodeResults
solve the problem?

Ciao,

Duncan.

From Sanjiv.Gupta at microchip.com  Fri Jan  9 08:45:55 2009
From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com)
Date: Fri, 9 Jan 2009 07:45:55 -0700
Subject: [LLVMdev] PIC16 backend for llvm 2.5
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
	<200901081611.02513.baldrick@free.fr>
	<F536B7C316F9474E9F7091239725AC9A4E900B@CHN-CL-MAIL01.mchp-main.com>
	<200901091253.24536.baldrick@free.fr>
Message-ID: <F536B7C316F9474E9F7091239725AC9A4E900E@CHN-CL-MAIL01.mchp-main.com>

 
>> Well, the first email is here.
>> 
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068667.html

>thanks, I remember now (more or less).  So would something like ReplaceNodeResults
>solve the problem?

I think it will. We will try that out and post changes.
Thanks for all your help.

Regards,
Sanjiv

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090109/79ccfaac/attachment.html 

From jay.foad at gmail.com  Fri Jan  9 10:22:30 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Fri, 9 Jan 2009 16:22:30 +0000
Subject: [LLVMdev] llvm-ld -On ?
Message-ID: <ee2e06e90901090822s92c7afcmfd3359d89f4b00e9@mail.gmail.com>

It appears that in LLVM 2.4, llvm-ld no longer accepts -On options to
control optimisation.

1. This isn't mentioned in the 2.4 release notes.

2. The man page (http://llvm.org/cmds/llvm-ld.html) still mentions -On
in a couple of places.

I only noticed this because we have a "gcc"-like driver program which
was passing through any -O options to the linker (even though the
linker was probably ignoring them).

Thanks,
Jay.

From kamm at incasoftware.de  Fri Jan  9 07:20:19 2009
From: kamm at incasoftware.de (Christian Kamm)
Date: Fri, 9 Jan 2009 14:20:19 +0100
Subject: [LLVMdev] LLVM based D compiler released
Message-ID: <200901091420.19412.kamm@incasoftware.de>


Maybe it's time to add it to the LLVM projects list. :)
The original annoucement on digitalmars.D.announce and 
http://www.incasoftware.de/~kamm/projects/index.php/2009/01/09/ldc-09-released/
was:

---

The first version of LDC (http://www.dsource.org/projects/ldc), the LLVM
based compiler for version one of the D programming language has been
released for x86-32 Linux. Get it here:
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.tbz2

We had already announced this release during the Tango conference in
September (we hope the video of our presentation will be out soon), but -
as was to be expected - it took a bit longer than planned.

LDC ships with a precompiled Tango rev 4237 and passes all except two of
Tango's unittests (io.digest.Md2 and text.locale.Posix fail). DStress
results also look favorable. The chances are good that your code will work
with it too!

There are several known issues, the most severe being:
 * LDC does not compile DWT successfully for unknown reasons
 * an LLVM 2.4 bug sometimes leads to linker errors when unreachable code is
   optimized away
 * LDC doesn't fully follow the D calling convention (but it's close!)
 * we inherit every DMD-frontend related bug in the D bug tracker
 * ... there are more in our tracker

If you encounter a bug, please check our bug tracker and create a new ticket
if the issue isn't listed yet. Maybe you are feeling adventurous and want
to try fixing it yourself; in that case take a look at our getting started
guide. 

LDC could support other platforms. Furthest along so far are
 * x86-64 Linux: needs people to start fixing smaller bugs, exception bug
   (LLVM issue)
 * x86-32 Mac: small runtime issues, needs tests
 * x86-32 Windows: exceptions not supported (LLVM issue)

but support for these platforms won't improve on its own! Several friendly
people have offered their help - we need more of those!
 
For those with big CTFE memory needs, we have an experimental version of LDC
available
http://www.incasoftware.de/~kamm/ldc/ldc-0.9-gc.tbz2
which has the compile-time garbage collector enabled. In the future, we're
going to experiment with a forward reference hack, but right now it still
introduces too many regressions. 
 
Feedback and questions are appreciated and should go to the mailing list:
ldc-dev at googlegroups.com. Alternatively, we're often seen in #ldc on
FreeNode.

Tomas Lindquist Olsen, Christian Kamm

From clattner at apple.com  Fri Jan  9 11:46:26 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 9 Jan 2009 09:46:26 -0800
Subject: [LLVMdev] Intern opening
Message-ID: <EDA825E8-D745-426C-A57D-92C78135687E@apple.com>

Hi Everyone,

The Apple compiler group is looking for an outstanding intern to fill  
an internship opening this summer.  The position is a paid 3 month  
position in the Cupertino, CA area.  We are looking for a candidate  
with Clang and/or LLVM optimizer/backend hacking experience, and  
strongly prefer candidates who have contributed code to the public  
repositories.

If you are interested in the position, please send me your resume/CV  
and any other related info by Jan 23.  Thanks!

-Chris


From evan.cheng at apple.com  Fri Jan  9 12:45:41 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 9 Jan 2009 10:45:41 -0800
Subject: [LLVMdev] Probably FAQ: can you insert BRCONDs during
	TargetLowering::LowerOperation?
In-Reply-To: <2CFA4605-7968-4E60-9682-BDED67DBDBC3@aero.org>
References: <8988770C-643B-40C8-8B5B-B90F1791C59B@aero.org>
	<81143244-8513-45E2-91EB-478DA2B879B9@apple.com>
	<258cd3200901062337v14c55ae2j2ebe196da588f1f8@mail.gmail.com>
	<F996D3D3-658F-4C9E-860F-555EE1421485@apple.com>
	<2CFA4605-7968-4E60-9682-BDED67DBDBC3@aero.org>
Message-ID: <E143A5EC-30E4-4EAA-B843-97ECACBAD081@apple.com>


On Jan 7, 2009, at 9:21 AM, Scott Michel wrote:

> Chris:
>
> It occurred to me this morning that maybe the general solution to
> this particular type of problem is a custom/target-dependent DAG
> inserter pass, analogous to target lowering and DAG legalization. I'm
> not sure if this pass happens before or after legalization. Worth
> considering?

That doesn't seem much cleaner than the current hack. The correct  
solution, which we intend to pursue some day, is to do whole function  
instruction selection.

Evan

>
>
> I suppose the best way to discuss this is to just write the code.
> However, some preliminary discussion is probably worthwhile to make
> sure that a target-dependent DAG inserter pass is invoked in the
> right place in the existing pass stream.
>
>
> -scooter
>
> On Jan 7, 2009, at 12:18 AM, Chris Lattner wrote:
>
>>
>> On Jan 6, 2009, at 11:37 PM, Scott Michel wrote:
>>
>>> Chris:
>>>
>>> I was trying to avoid using the custom instruction emitter method.
>>> Not as if I didn't look before I asked the question to see if there
>>> was an easier way.
>>
>> Then no, there is no other way.
>>
>> -Chris
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From evan.cheng at apple.com  Fri Jan  9 13:05:45 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 9 Jan 2009 11:05:45 -0800
Subject: [LLVMdev] RFC: Store alignment should be LValue alignment,
	not source alignment
Message-ID: <4AD4572C-0164-47ED-892E-92F082A47820@apple.com>

Hi all,

Please review this patch. It's fixing PR3232 comment #8. Function bar  
from 2008-03-24-BitFiled-And-Alloca.c compiles to:

         %struct.Key = type { { i32, i32 } }
...
define i32 @bar(i64 %key_token2) nounwind {
entry:
         %key_token2_addr = alloca i64           ; <i64*> [#uses=2]
         %retval = alloca i32            ; <i32*> [#uses=2]
         %iospec = alloca %struct.Key            ; <%struct.Key*>  
[#uses=3]
         %ret = alloca i32               ; <i32*> [#uses=2]
         %0 = alloca i32         ; <i32*> [#uses=2]
         %"alloca point" = bitcast i32 0 to i32          ; <i32>  
[#uses=0]
         store i64 %key_token2, i64* %key_token2_addr
         %1 = getelementptr %struct.Key* %iospec, i32 0, i32  
0           ; <{ i32, i32 }*> [#uses=2]
	%2 = getelementptr { i32, i32 }* %1, i32 0, i32 0               ;  
<i32*> [#uses=1]
         store i32 0, i32* %2, align 4
         %3 = getelementptr { i32, i32 }* %1, i32 0, i32  
1               ; <i32*> [#uses=1]
         store i32 0, i32* %3, align 4
         %4 = getelementptr %struct.Key* %iospec, i32 0, i32  
0           ; <{ i32, i32 }*> [#uses=1]
         %5 = bitcast { i32, i32 }* %4 to i64*           ; <i64*>  
[#uses=1]
         %6 = load i64* %key_token2_addr, align 8                ;  
<i64> [#uses=1]
         store i64 %6, i64* %5, align 8
...

The store alignment 8 is wrong. The address iospec has 4-byte  
alignment. The problem is llvm-gcc TreeToLLVM::EmitMODIFY_EXPR:

   LValue LV = EmitLV(lhs);
   bool isVolatile = TREE_THIS_VOLATILE(lhs);
   unsigned Alignment = expr_align(exp) / 8

It's using the alignment of the expression, rather than the memory  
object of LValue.

The patch saves the alignment of the memory object in LValue returned  
by EmitLV(). Please review it carefully as I am not entirely  
comfortable hacking on llvm-gcc. :-)

Evan


Index: gcc/llvm-convert.cpp
===================================================================
--- gcc/llvm-convert.cpp	(revision 61984)
+++ gcc/llvm-convert.cpp	(working copy)
@@ -1150,9 +1150,18 @@ LValue TreeToLLVM::EmitLV(tree exp) {
    case IMAGPART_EXPR: return EmitLV_XXXXPART_EXPR(exp, 1);

    // Constants.
-  case LABEL_DECL:   return TreeConstantToLLVM::EmitLV_LABEL_DECL(exp);
-  case COMPLEX_CST:  return  
LValue(TreeConstantToLLVM::EmitLV_COMPLEX_CST(exp));
-  case STRING_CST:   return  
LValue(TreeConstantToLLVM::EmitLV_STRING_CST(exp));
+  case LABEL_DECL: {
+    Value *Ptr = TreeConstantToLLVM::EmitLV_LABEL_DECL(exp);
+    return LValue(Ptr, DECL_ALIGN(exp) / 8);
+  }
+  case COMPLEX_CST: {
+    Value *Ptr = TreeConstantToLLVM::EmitLV_COMPLEX_CST(exp);
+    return LValue(Ptr, TYPE_ALIGN(TREE_TYPE(exp)) / 8);
+  }
+  case STRING_CST: {
+    Value *Ptr = TreeConstantToLLVM::EmitLV_STRING_CST(exp);
+    return LValue(Ptr, TYPE_ALIGN(TREE_TYPE(exp)) / 8);
+  }

    // Type Conversion.
    case VIEW_CONVERT_EXPR: return EmitLV_VIEW_CONVERT_EXPR(exp);
@@ -1165,9 +1174,11 @@ LValue TreeToLLVM::EmitLV(tree exp) {
    case WITH_SIZE_EXPR:
      // The address is the address of the operand.
      return EmitLV(TREE_OPERAND(exp, 0));
-  case INDIRECT_REF:
+  case INDIRECT_REF: {
      // The lvalue is just the address.
-    return Emit(TREE_OPERAND(exp, 0), 0);
+    tree Op = TREE_OPERAND(exp, 0);
+    return LValue(Emit(Op, 0), expr_align(Op) / 8);
+  }
    }
  }

@@ -2290,7 +2301,7 @@ Value *TreeToLLVM::EmitLoadOfLValue(tree
    LValue LV = EmitLV(exp);
    bool isVolatile = TREE_THIS_VOLATILE(exp);
    const Type *Ty = ConvertType(TREE_TYPE(exp));
-  unsigned Alignment = expr_align(exp) / 8;
+  unsigned Alignment = LV.getAlignment();
    if (TREE_CODE(exp) == COMPONENT_REF)
      if (const StructType *STy =
          dyn_cast<StructType>(ConvertType(TREE_TYPE(TREE_OPERAND(exp,  
0)))))
@@ -2963,7 +2974,7 @@ Value *TreeToLLVM::EmitMODIFY_EXPR(tree

    LValue LV = EmitLV(lhs);
    bool isVolatile = TREE_THIS_VOLATILE(lhs);
-  unsigned Alignment = expr_align(lhs) / 8;
+  unsigned Alignment = LV.getAlignment();
    if (TREE_CODE(lhs) == COMPONENT_REF)
      if (const StructType *STy =
          dyn_cast<StructType>(ConvertType(TREE_TYPE(TREE_OPERAND(lhs,  
0)))))
@@ -3157,7 +3168,7 @@ Value *TreeToLLVM::EmitVIEW_CONVERT_EXPR
        LValue LV = EmitLV(Op);
        assert(!LV.isBitfield() && "Expected an aggregate operand!");
        bool isVolatile = TREE_THIS_VOLATILE(Op);
-      unsigned Alignment = expr_align(Op) / 8;
+      unsigned Alignment = LV.getAlignment();

        EmitAggregateCopy(Target, MemRef(LV.Ptr, Alignment, isVolatile),
                          TREE_TYPE(exp));
@@ -5885,9 +5896,10 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp)
    Value *Decl = DECL_LLVM(exp);
    if (Decl == 0) {
      if (errorcount || sorrycount) {
-      const PointerType *Ty =
-        PointerType::getUnqual(ConvertType(TREE_TYPE(exp)));
-      return ConstantPointerNull::get(Ty);
+      const Type *Ty = ConvertType(TREE_TYPE(exp));
+      const PointerType *PTy = PointerType::getUnqual(Ty);
+      LValue LV(ConstantPointerNull::get(PTy),  
TD.getABITypeAlignment(Ty));
+      return LV;
      }
      assert(0 && "INTERNAL ERROR: Referencing decl that hasn't been  
laid out");
      abort();
@@ -5924,7 +5936,13 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp)
    // type void.
    if (Ty == Type::VoidTy) Ty = StructType::get(NULL, NULL);
    const PointerType *PTy = PointerType::getUnqual(Ty);
-  return BitCastToType(Decl, PTy);
+  unsigned Alignment = Ty->isSized() ? TD.getABITypeAlignment(Ty) : 1;
+  if (DECL_ALIGN_UNIT(exp)) {
+    if (DECL_USER_ALIGN(exp) || Alignment <  
(unsigned)DECL_ALIGN_UNIT(exp))
+      Alignment = DECL_ALIGN_UNIT(exp);
+  }
+
+  return LValue(BitCastToType(Decl, PTy), Alignment);
  }

  LValue TreeToLLVM::EmitLV_ARRAY_REF(tree exp) {
@@ -5932,22 +5950,23 @@ LValue TreeToLLVM::EmitLV_ARRAY_REF(tree
    // of ElementTy in the case of ARRAY_RANGE_REF.

    tree Array = TREE_OPERAND(exp, 0);
-  tree ArrayType = TREE_TYPE(Array);
+  tree ArrayTreeType = TREE_TYPE(Array);
    tree Index = TREE_OPERAND(exp, 1);
    tree IndexType = TREE_TYPE(Index);
-  tree ElementType = TREE_TYPE(ArrayType);
+  tree ElementType = TREE_TYPE(ArrayTreeType);

-  assert((TREE_CODE (ArrayType) == ARRAY_TYPE ||
-          TREE_CODE (ArrayType) == POINTER_TYPE ||
-          TREE_CODE (ArrayType) == REFERENCE_TYPE ||
-          TREE_CODE (ArrayType) == BLOCK_POINTER_TYPE) &&
+  assert((TREE_CODE (ArrayTreeType) == ARRAY_TYPE ||
+          TREE_CODE (ArrayTreeType) == POINTER_TYPE ||
+          TREE_CODE (ArrayTreeType) == REFERENCE_TYPE ||
+          TREE_CODE (ArrayTreeType) == BLOCK_POINTER_TYPE) &&
           "Unknown ARRAY_REF!");

    // As an LLVM extension, we allow ARRAY_REF with a pointer as the  
first
    // operand.  This construct maps directly to a getelementptr  
instruction.
    Value *ArrayAddr;
+  unsigned ArrayAlign;

-  if (TREE_CODE(ArrayType) == ARRAY_TYPE) {
+  if (TREE_CODE(ArrayTreeType) == ARRAY_TYPE) {
      // First subtract the lower bound, if any, in the type of the  
index.
      tree LowerBound = array_ref_low_bound(exp);
      if (!integer_zerop(LowerBound))
@@ -5956,8 +5975,10 @@ LValue TreeToLLVM::EmitLV_ARRAY_REF(tree
      LValue ArrayAddrLV = EmitLV(Array);
      assert(!ArrayAddrLV.isBitfield() && "Arrays cannot be  
bitfields!");
      ArrayAddr = ArrayAddrLV.Ptr;
+    ArrayAlign = ArrayAddrLV.Alignment;
    } else {
      ArrayAddr = Emit(Array, 0);
+    ArrayAlign = expr_align(ArrayTreeType) / 8;
    }

    Value *IndexVal = Emit(Index, 0);
@@ -5971,20 +5992,27 @@ LValue TreeToLLVM::EmitLV_ARRAY_REF(tree
      IndexVal = CastToSIntType(IndexVal, IntPtrTy);

    // If this is an index into an LLVM array, codegen as a GEP.
-  if (isArrayCompatible(ArrayType)) {
+  if (isArrayCompatible(ArrayTreeType)) {
      Value *Idxs[2] = { ConstantInt::get(Type::Int32Ty, 0), IndexVal };
      Value *Ptr = Builder.CreateGEP(ArrayAddr, Idxs, Idxs + 2);
-    return BitCastToType(Ptr,
-                          
PointerType::getUnqual(ConvertType(TREE_TYPE(exp))));
+    const Type *ATy = cast<PointerType>(ArrayAddr->getType())- 
 >getElementType();
+    const Type *ElementTy = cast<ArrayType>(ATy)->getElementType();
+    unsigned Alignment = MinAlign(ArrayAlign,  
TD.getABITypeSize(ElementTy));
+    return LValue(BitCastToType(Ptr,
+                            
PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))),
+                  Alignment);
    }

    // If we are indexing over a fixed-size type, just use a GEP.
-  if (isSequentialCompatible(ArrayType)) {
-    const Type *PtrElementTy =  
PointerType::getUnqual(ConvertType(ElementType));
+  if (isSequentialCompatible(ArrayTreeType)) {
+    const Type *ElementTy = ConvertType(ElementType);
+    const Type *PtrElementTy = PointerType::getUnqual(ElementTy);
      ArrayAddr = BitCastToType(ArrayAddr, PtrElementTy);
      Value *Ptr = Builder.CreateGEP(ArrayAddr, IndexVal);
-    return BitCastToType(Ptr,
-                          
PointerType::getUnqual(ConvertType(TREE_TYPE(exp))));
+    unsigned Alignment = MinAlign(ArrayAlign,  
TD.getABITypeAlignment(ElementTy));
+    return LValue(BitCastToType(Ptr,
+                            
PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))),
+                  Alignment);
    }

    // Otherwise, just do raw, low-level pointer arithmetic.  FIXME:  
this could be
@@ -5992,14 +6020,21 @@ LValue TreeToLLVM::EmitLV_ARRAY_REF(tree
    //   float foo(int w, float A[][w], int g) { return A[g][0]; }

    ArrayAddr = BitCastToType(ArrayAddr,  
PointerType::getUnqual(Type::Int8Ty));
-  if (VOID_TYPE_P(TREE_TYPE(ArrayType)))
-    return Builder.CreateGEP(ArrayAddr, IndexVal);
+  if (VOID_TYPE_P(TREE_TYPE(ArrayTreeType))) {
+    unsigned Alignment = MinAlign(ArrayAlign,
+                                   
TD.getABITypeAlignment(Type::Int8Ty));
+    return LValue(Builder.CreateGEP(ArrayAddr, IndexVal), Alignment);
+  }

    Value *TypeSize = Emit(array_ref_element_size(exp), 0);
    TypeSize = CastToUIntType(TypeSize, IntPtrTy);
    IndexVal = Builder.CreateMul(IndexVal, TypeSize);
    Value *Ptr = Builder.CreateGEP(ArrayAddr, IndexVal);
-  return  
BitCastToType(Ptr,PointerType::getUnqual(ConvertType(TREE_TYPE(exp))));
+  unsigned Alignment = MinAlign(ArrayAlign,
+                                cast<ConstantInt>(IndexVal)- 
 >getZExtValue());
+  return LValue(BitCastToType(Ptr,
+                            
PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))),
+                Alignment);
  }

  /// getFieldOffsetInBits - Return the offset (in bits) of a  
FIELD_DECL in a
@@ -6028,8 +6063,9 @@ static unsigned getComponentRefOffsetInB

  LValue TreeToLLVM::EmitLV_COMPONENT_REF(tree exp) {
    LValue StructAddrLV = EmitLV(TREE_OPERAND(exp, 0));
-  tree FieldDecl = TREE_OPERAND(exp, 1);
-
+  tree FieldDecl = TREE_OPERAND(exp, 1);
+  unsigned LVAlign = DECL_PACKED(FieldDecl) ? 1 :  
StructAddrLV.Alignment;
+
    assert((TREE_CODE(DECL_CONTEXT(FieldDecl)) == RECORD_TYPE ||
            TREE_CODE(DECL_CONTEXT(FieldDecl)) == UNION_TYPE  ||
            TREE_CODE(DECL_CONTEXT(FieldDecl)) == QUAL_UNION_TYPE));
@@ -6064,7 +6100,9 @@ LValue TreeToLLVM::EmitLV_COMPONENT_REF(
      // the offset from BitStart.
      if (MemberIndex) {
        const StructLayout *SL =  
TD.getStructLayout(cast<StructType>(StructTy));
-      BitStart -= SL->getElementOffset(MemberIndex) * 8;
+      unsigned Offset = SL->getElementOffset(MemberIndex);
+      BitStart -= Offset * 8;
+      LVAlign = MinAlign(LVAlign, Offset);
      }

      // If the FIELD_DECL has an annotate attribute on it, emit it.
@@ -6130,7 +6168,7 @@ LValue TreeToLLVM::EmitLV_COMPONENT_REF(
          if (AnnotateAttr)
            AnnotateAttr = lookup_attribute("annotate", AnnotateAttr);
        }
-    }
+    }
    } else {
      Value *Offset = Emit(field_offset, 0);

@@ -6150,6 +6188,7 @@ LValue TreeToLLVM::EmitLV_COMPONENT_REF(
        Offset = Builder.CreateAdd(Offset,
          ConstantInt::get(Offset->getType(), ByteOffset));
        BitStart -= ByteOffset*8;
+      LVAlign = MinAlign(LVAlign, ByteOffset);
      }

      Value *Ptr = CastToType(Instruction::PtrToInt, StructAddrLV.Ptr,
@@ -6221,6 +6260,7 @@ LValue TreeToLLVM::EmitLV_COMPONENT_REF(

        // Compute the byte offset, and add it to the pointer.
        unsigned ByteOffset = NumAlignmentUnits*ByteAlignment;
+      LVAlign = MinAlign(LVAlign, ByteOffset);

        Constant *Offset = ConstantInt::get(TD.getIntPtrType(),  
ByteOffset);
        FieldPtr = CastToType(Instruction::PtrToInt, FieldPtr,
@@ -6242,17 +6282,18 @@ LValue TreeToLLVM::EmitLV_COMPONENT_REF(

      // Okay, everything is good.  Return this as a bitfield if we  
can't
      // return it as a normal l-value. (e.g. "struct X { int X :  
32 };" ).
+    // Conservatively return LValue with alignment 1.
      if (BitfieldSize != LLVMValueBitSize || BitStart != 0)
-      return LValue(FieldPtr, BitStart, BitfieldSize);
+      return LValue(FieldPtr, 1, BitStart, BitfieldSize);
    } else {
      // Make sure we return a pointer to the right type.
-    FieldPtr = BitCastToType(FieldPtr,
-                           
PointerType::getUnqual(ConvertType(TREE_TYPE(exp))));
+    const Type *EltTy = ConvertType(TREE_TYPE(exp));
+    FieldPtr = BitCastToType(FieldPtr, PointerType::getUnqual(EltTy));
    }

    assert(BitStart == 0 &&
           "It's a bitfield reference or we didn't get to the field!");
-  return LValue(FieldPtr);
+  return LValue(FieldPtr, LVAlign);
  }

  LValue TreeToLLVM::EmitLV_BIT_FIELD_REF(tree exp) {
@@ -6284,17 +6325,27 @@ LValue TreeToLLVM::EmitLV_BIT_FIELD_REF(
    }

    // If this is referring to the whole field, return the whole thing.
-  if (BitStart == 0 && BitSize == ValueSizeInBits)
-    return LValue(BitCastToType(Ptr.Ptr,  
PointerType::getUnqual(ValTy)));
+  if (BitStart == 0 && BitSize == ValueSizeInBits) {
+    return LValue(BitCastToType(Ptr.Ptr,  
PointerType::getUnqual(ValTy)),
+                  Ptr.Alignment);
+  }

-  return LValue(BitCastToType(Ptr.Ptr,  
PointerType::getUnqual(ValTy)), BitStart,
-                BitSize);
+  return LValue(BitCastToType(Ptr.Ptr,  
PointerType::getUnqual(ValTy)), 1,
+                BitStart, BitSize);
  }

  LValue TreeToLLVM::EmitLV_XXXXPART_EXPR(tree exp, unsigned Idx) {
    LValue Ptr = EmitLV(TREE_OPERAND(exp, 0));
-  assert(!Ptr.isBitfield() && "BIT_FIELD_REF operands cannot be  
bitfields!");
-  return LValue(Builder.CreateStructGEP(Ptr.Ptr, Idx));
+  assert(!Ptr.isBitfield() &&
+         "REALPART_EXPR / IMAGPART_EXPR operands cannot be  
bitfields!");
+  unsigned Alignment;
+  if (Idx == 0)
+    // REALPART alignment is same as the complex operand.
+    Alignment = Ptr.Alignment;
+  else
+    // IMAGPART alignment = MinAlign(Ptr.Alignment, sizeof field);
+    Alignment = MinAlign(Ptr.Alignment, TD.getABITypeSize(Ptr.Ptr- 
 >getType()));
+  return LValue(Builder.CreateStructGEP(Ptr.Ptr, Idx), Alignment);
  }

  LValue TreeToLLVM::EmitLV_VIEW_CONVERT_EXPR(tree exp) {
@@ -6310,24 +6361,30 @@ LValue TreeToLLVM::EmitLV_VIEW_CONVERT_E
    } else {
      // If the input is a scalar, emit to a temporary.
      Value *Dest = CreateTemporary(ConvertType(TREE_TYPE(Op)));
-    Builder.CreateStore(Emit(Op, 0), Dest);
+    StoreInst *S = Builder.CreateStore(Emit(Op, 0), Dest);
      // The type is the type of the expression.
      Dest = BitCastToType(Dest,
                            
PointerType::getUnqual(ConvertType(TREE_TYPE(exp))));
-    return LValue(Dest);
+    return LValue(Dest, S->getAlignment());
    }
  }

  LValue TreeToLLVM::EmitLV_EXC_PTR_EXPR(tree exp) {
    CreateExceptionValues();
    // Cast the address pointer to the expected type.
-  return BitCastToType(ExceptionValue,
-                        
PointerType::getUnqual(ConvertType(TREE_TYPE(exp))));
+  unsigned Alignment =  
TD.getABITypeAlignment(cast<PointerType>(ExceptionValue->
+                                                  getType())- 
 >getElementType());
+  return LValue(BitCastToType(ExceptionValue,
+                               
PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))),
+                Alignment);
  }

  LValue TreeToLLVM::EmitLV_FILTER_EXPR(tree exp) {
    CreateExceptionValues();
-  return ExceptionSelectorValue;
+  unsigned Alignment =
+    TD.getABITypeAlignment(cast<PointerType>(ExceptionSelectorValue->
+                                             getType())- 
 >getElementType());
+  return LValue(ExceptionSelectorValue, Alignment);
  }

  // 
= 
= 
=---------------------------------------------------------------------- 
===//
Index: gcc/llvm-internal.h
===================================================================
--- gcc/llvm-internal.h	(revision 61984)
+++ gcc/llvm-internal.h	(working copy)
@@ -251,23 +251,30 @@ struct MemRef {
  };

  /// LValue - This struct represents an lvalue in the program.  In  
particular,
-/// the Ptr member indicates the memory that the lvalue lives in.  If  
this is
-/// a bitfield reference, BitStart indicates the first bit in the  
memory that
-/// is part of the field and BitSize indicates the extent.
+/// the Ptr member indicates the memory that the lvalue lives in.   
Alignment
+/// is the alignment of the memory (in bytes).If this is a bitfield  
reference,
+/// BitStart indicates the first bit in the memory that is part of  
the field
+/// and BitSize indicates the extent.
  ///
  /// "LValue" is intended to be a light-weight object passed around  
by-value.
  struct LValue {
    Value *Ptr;
+  unsigned char Alignment;
    unsigned char BitStart;
    unsigned char BitSize;

-  LValue(Value *P) : Ptr(P), BitStart(255), BitSize(255) {}
-  LValue(Value *P, unsigned BSt, unsigned BSi)
-    : Ptr(P), BitStart(BSt), BitSize(BSi) {
+  LValue(Value *P, unsigned Align)
+    : Ptr(P), Alignment(Align), BitStart(255), BitSize(255) {}
+  LValue(Value *P, unsigned Align, unsigned BSt, unsigned BSi)
+  : Ptr(P), Alignment(Align), BitStart(BSt), BitSize(BSi) {
        assert(BitStart == BSt && BitSize == BSi &&
               "Bit values larger than 256?");
+    }
+
+  unsigned getAlignment() const {
+    assert(Alignment && "LValue alignment cannot be zero!");
+    return Alignment;
    }
-
    bool isBitfield() const { return BitStart != 255; }
  };





From evan.cheng at apple.com  Fri Jan  9 13:37:30 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 9 Jan 2009 11:37:30 -0800
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <e50173bd0901071424l2a7d97c5pa208725459f01989@mail.gmail.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
	<4693CC4E-C418-4C66-9DAB-50443D26F40F@apple.com>
	<e50173bd0901071424l2a7d97c5pa208725459f01989@mail.gmail.com>
Message-ID: <1A872920-7D3B-4D11-9FCE-C34FC8C6DFD7@apple.com>

This looks like a bar in ARMInstrInfo.td:

BX_RET should be marked with Uses = [LR] since it uses LR. However,  
this won't work if there is a call BL before the BX_RET. BL is marked  
as if it implicitly define LR. So we'll end up with this (hello world  
example):

Live Ins: %LR %R7
         %SP<def> = SUBri %SP<kill>, 8, 14, %reg0, %reg0
         STR %LR<kill>, %SP, %reg0, 4, 14, %reg0
         STR %R7<kill>, %SP, %reg0, 0, 14, %reg0
         %R7<def> = MOVr %SP, 14, %reg0, %reg0
         %R0<def> = LDR <cp#0>, %reg0, 0, 14, %reg0, Mem:LD(4,4)  
[<unknown> + 0]
         BL <ga:puts>, %R0<kill>, %R0<imp-def,dead>, %R1<imp- 
def,dead>, %R2<imp-def,dead>, %R3<imp-def,dead>, %R12<imp-def,dead>,  
%LR<imp-def>, %D0<imp-def,dead>, %D1<imp-def,de\
ad>, %D2<imp-def,dead>, %D3<imp-def,dead>, %D4<imp-def,dead>, %D5<imp- 
def,dead>, %D6<imp-def,dead>, %D7<imp-def,dead>, %CPSR<imp-def,dead>
         %R0<def> = MOVi 0, 14, %reg0, %reg0
         %R7<def> = LDR %SP, %reg0, 0, 14, %reg0
         %LR<def> = LDR %SP, %reg0, 4, 14, %reg0
	%SP<def> = ADDri %SP<kill>, 8, 14, %reg0, %reg0
         BX_RET 14, %reg0, %R0<imp-use,kill>, %LR<imp-use,kill>

The LR defined by BL is not killed before the PEI inserted LR restore.  
The register scavenger doesn't like this.

The issue is while BL does modifies LR, it doesn't actually defines LR  
so later instructions can use it. I'll think about how to fix this.   
It's not obvious to me at this point.

Evan

On Jan 7, 2009, at 2:24 PM, Roman Levenstein wrote:

> Hi Evan,
>
> Thanks for your feedback!
>
> 2009/1/7 Evan Cheng <evan.cheng at apple.com>:
>>
>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>
>>
>> As you can see, PrologEpilogInserter has inserted at the beginning
>> of the function some code for manipulation of the frame pointer and
>> this inserted code uses the LR register.
>> As far as I understand,  ARMRegisterInfo.td should exclude the LR
>> register from the set of allocatable registers for functions that
>> require frame pointer manipulation.
>> But currently it is not the case, or?
>>
>> No, LR is not the frame pointer. It's the link register (caller  
>> address). It
>> should be available as a general purpose register.
>
> OK.
>
>> The bug is elsewhere. It  has to do with kill / dead markers.
>>       %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>>       %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>>       BX_RET 14, %reg0
>> LR is restored here but it's not killed before the end of the block  
>> is
>> reached.
>
> Hmm. I have no idea about what ARM backend does. My register allocator
> just assigns the registers as I explained in my original mail.
> Then it lets VirtRegMap.cpp do its job, i.e. it lets it rewrite the
> code and replace virtual registers by the assigned physical registers.
> You can see the result in the step (3) of my original mail. In my
> opinion, it still looks correct. May be this rewriting process does
> something wrong?
>
> Then PrologEpilogInserter and some other standard post RA passes are
> invoked for the ARM backend. But I have not changed anything there, so
> I have no idea what happens.
>
> And, BTW, the instructions you mentioned above are after the
> instruction triggering the assertion, which is:
> STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)  
> [0x8fc2d68 + 0]
>
>> Should BX_RET use it?
>
> I don't know the semantics of BX_RET on the ARM platform. May be it
> uses BX_RET somehow.
>
> BTW, an idea: May be it is easy to trigger exactly the same behaviour
> with the linear scan if one does the following:
>  - comment out dependency on the coalescer, so that it is not invoked
>  - change the allocation order of the GPR register class for ARM, so
> that it starts with the LR register.
> ,
> Any ideas how to proceed with the current situation?
>
> -Roman
>
>> I hope that I provided enough information to explain my problem. I
>> also provided my initial analysis, but may be I'm wrong.
>>
>> Can someone more knowledgeable in ARM backend and LLVM's register
>> allocation framework have a look at it?
>> If it is a bug in the ARM backend, could it be fixed?
>>
>> Thanks,
>>  Roman
>> <bugpoint-reduced-simplified.bc>
>>


From dalej at apple.com  Fri Jan  9 13:54:05 2009
From: dalej at apple.com (Dale Johannesen)
Date: Fri, 9 Jan 2009 11:54:05 -0800
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <1A872920-7D3B-4D11-9FCE-C34FC8C6DFD7@apple.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
	<4693CC4E-C418-4C66-9DAB-50443D26F40F@apple.com>
	<e50173bd0901071424l2a7d97c5pa208725459f01989@mail.gmail.com>
	<1A872920-7D3B-4D11-9FCE-C34FC8C6DFD7@apple.com>
Message-ID: <F26586BA-7F39-4CB7-998B-3D63DE6D9360@apple.com>


On Jan 9, 2009, at 11:37 AMPST, Evan Cheng wrote:

> This looks like a bar in ARMInstrInfo.td:
>
> BX_RET should be marked with Uses = [LR] since it uses LR. However,
> this won't work if there is a call BL before the BX_RET. BL is marked
> as if it implicitly define LR. So we'll end up with this (hello world
> example):

PPC has the call (BL) marked with Defs=LR and the return (BLR)
marked with Uses=LR, and works AFAIK.  Let me figure out what's  
different...

> Live Ins: %LR %R7
>         %SP<def> = SUBri %SP<kill>, 8, 14, %reg0, %reg0
>         STR %LR<kill>, %SP, %reg0, 4, 14, %reg0
>         STR %R7<kill>, %SP, %reg0, 0, 14, %reg0
>         %R7<def> = MOVr %SP, 14, %reg0, %reg0
>         %R0<def> = LDR <cp#0>, %reg0, 0, 14, %reg0, Mem:LD(4,4)
> [<unknown> + 0]
>         BL <ga:puts>, %R0<kill>, %R0<imp-def,dead>, %R1<imp-
> def,dead>, %R2<imp-def,dead>, %R3<imp-def,dead>, %R12<imp-def,dead>,
> %LR<imp-def>, %D0<imp-def,dead>, %D1<imp-def,de\
> ad>, %D2<imp-def,dead>, %D3<imp-def,dead>, %D4<imp-def,dead>, %D5<imp-
> def,dead>, %D6<imp-def,dead>, %D7<imp-def,dead>, %CPSR<imp-def,dead>
>         %R0<def> = MOVi 0, 14, %reg0, %reg0
>         %R7<def> = LDR %SP, %reg0, 0, 14, %reg0
>         %LR<def> = LDR %SP, %reg0, 4, 14, %reg0
> 	%SP<def> = ADDri %SP<kill>, 8, 14, %reg0, %reg0
>         BX_RET 14, %reg0, %R0<imp-use,kill>, %LR<imp-use,kill>
>
> The LR defined by BL is not killed before the PEI inserted LR restore.
> The register scavenger doesn't like this.
>
> The issue is while BL does modifies LR, it doesn't actually defines LR
> so later instructions can use it. I'll think about how to fix this.
> It's not obvious to me at this point.
>
> Evan
>
> On Jan 7, 2009, at 2:24 PM, Roman Levenstein wrote:
>
>> Hi Evan,
>>
>> Thanks for your feedback!
>>
>> 2009/1/7 Evan Cheng <evan.cheng at apple.com>:
>>>
>>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>>
>>>
>>> As you can see, PrologEpilogInserter has inserted at the beginning
>>> of the function some code for manipulation of the frame pointer and
>>> this inserted code uses the LR register.
>>> As far as I understand,  ARMRegisterInfo.td should exclude the LR
>>> register from the set of allocatable registers for functions that
>>> require frame pointer manipulation.
>>> But currently it is not the case, or?
>>>
>>> No, LR is not the frame pointer. It's the link register (caller
>>> address). It
>>> should be available as a general purpose register.
>>
>> OK.
>>
>>> The bug is elsewhere. It  has to do with kill / dead markers.
>>>      %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>>>      %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>>>      BX_RET 14, %reg0
>>> LR is restored here but it's not killed before the end of the block
>>> is
>>> reached.
>>
>> Hmm. I have no idea about what ARM backend does. My register  
>> allocator
>> just assigns the registers as I explained in my original mail.
>> Then it lets VirtRegMap.cpp do its job, i.e. it lets it rewrite the
>> code and replace virtual registers by the assigned physical  
>> registers.
>> You can see the result in the step (3) of my original mail. In my
>> opinion, it still looks correct. May be this rewriting process does
>> something wrong?
>>
>> Then PrologEpilogInserter and some other standard post RA passes are
>> invoked for the ARM backend. But I have not changed anything there,  
>> so
>> I have no idea what happens.
>>
>> And, BTW, the instructions you mentioned above are after the
>> instruction triggering the assertion, which is:
>> STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>> [0x8fc2d68 + 0]
>>
>>> Should BX_RET use it?
>>
>> I don't know the semantics of BX_RET on the ARM platform. May be it
>> uses BX_RET somehow.
>>
>> BTW, an idea: May be it is easy to trigger exactly the same behaviour
>> with the linear scan if one does the following:
>> - comment out dependency on the coalescer, so that it is not invoked
>> - change the allocation order of the GPR register class for ARM, so
>> that it starts with the LR register.
>> ,
>> Any ideas how to proceed with the current situation?
>>
>> -Roman
>>
>>> I hope that I provided enough information to explain my problem. I
>>> also provided my initial analysis, but may be I'm wrong.
>>>
>>> Can someone more knowledgeable in ARM backend and LLVM's register
>>> allocation framework have a look at it?
>>> If it is a bug in the ARM backend, could it be fixed?
>>>
>>> Thanks,
>>> Roman
>>> <bugpoint-reduced-simplified.bc>
>>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From evan.cheng at apple.com  Fri Jan  9 13:55:37 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 9 Jan 2009 11:55:37 -0800
Subject: [LLVMdev] Is it possible to use the SimpleRegisterCoalescing
	pass in an iterative way?
In-Reply-To: <e50173bd0901090136n5c7337fcs8e1ab01d8bacd6b1@mail.gmail.com>
References: <e50173bd0901090136n5c7337fcs8e1ab01d8bacd6b1@mail.gmail.com>
Message-ID: <C8BA4D72-4912-4FEE-8AE5-FCBB0934D773@apple.com>

SimpleRegisterCoalescer is a super class of RegisterCoalescer. A  
RegisterCoalescer can be run both as a pass or directly. Perhaps the  
answer is as simple as implementing coalesceFunction.

Evan

On Jan 9, 2009, at 1:36 AM, Roman Levenstein wrote:

> Hi,
>
> I'm implementing some variations of graph-coloring register  
> allocators for LLVM.
> Many of them perform their phases (e.g. coalescing, graph
> simplification, spilling,  color selection) in an iterative way. Since
> LLVM provides an implementation of the coalescing in the
> SimpleRegisterCoalescing class already, I would like to reuse it (even
> though I could of course create my own coalescing implementation). But
> this class is a MachineFunctionPass.
>
> I'm wondering, if it is possible to use this pass from another pass
> (i.e. regalloc) in an iterative way:
> I need to invoke it multiple times for the same MachineFunction at
> certain places in my regalloc pass implementation.
> May be some sort of analysis update can be performed? Or is it
> designed to be used just once per MachineFunction?
>
> Also overall, it would be interesting to know how LLVM supports such
> kind of iterative algorithms? What are the ways to formulate the
> independent phases of those algorithms as reusable passes that could
> be used in an iterative way?
>
> Thanks,
> -Roman


From evan.cheng at apple.com  Fri Jan  9 14:00:02 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 9 Jan 2009 12:00:02 -0800
Subject: [LLVMdev] implicit CC register Defs cause "physreg was not
	killed in defining block!" assert
In-Reply-To: <57C38DA176A0A34A9B9F3CCCE33D3C4AE9D9D380FD@FRPAR1CL009.coe.adi.dibcom.com>
References: <57C38DA176A0A34A9B9F3CCCE33D3C4AE9D9D380FD@FRPAR1CL009.coe.adi.dibcom.com>
Message-ID: <0F0A96F8-B4D0-4D2E-9187-A2988B32C38A@apple.com>

A physical register cannot be live across the block. So it must have a  
use in the block or it must be marked dead. From your dump, it looks  
like the CCFLAGS defs are not being marked dead. It's unclear where  
things went wrong, but you can step through LiveVariables to debug this.

Evan

On Jan 9, 2009, at 2:50 AM, Christian Sayer wrote:

> Hello,
>
> For my backend, I define and use a CC register similiarly to the  
> EFLAGS register in X86 (I call it CCFLAGS).
> But if I make all arithmetic/logic instructions affect it ('let Defs  
> = [CCFLAGS] in...' in InstrInfo.td) I run into
>
>  // The only case we should have a dead physreg here without a  
> killing or
>  // instruction where we know it's dead is if it is live-in to the  
> function
>  // and never used.
>  assert(!CopyMI && "physreg was not killed in defining block!");
>
> in LiveIntervals::handlePhysicalRegisterDef().
>
> The dump() of the MBB from the debugger looks like the following:
>
> entry.ifcont267_crit_edge: 0x12bc368, LLVM BB @0x12bb900, ID#2:
>    Predecessors according to CFG: 0x12bc290 (#0) 0x12bca70 (#1)
>        %reg1033<def> = addC %reg1025<kill>, 0, %CCFLAGS<imp-def,dead>
>        %reg1032<def> = addC %reg1024<kill>, 0, %CCFLAGS<imp-def,dead>
>        %reg1095<def> = addC %reg1028, 0, %CCFLAGS<imp-def>
>        %reg1096<def> = addC %reg1029<kill>, 0, %CCFLAGS<imp-def>
>        %reg1097<def> = addC %reg1033<kill>, 0, %CCFLAGS<imp-def>
>        %reg1098<def> = addC %reg1028<kill>, 0, %CCFLAGS<imp-def>
>        %reg1099<def> = addC %reg1031<kill>, 0, %CCFLAGS<imp-def>
>        %reg1100<def> = addC %reg1030, 0, %CCFLAGS<imp-def>
>        %reg1101<def> = addC %reg1032<kill>, 0, %CCFLAGS<imp-def>
>        %reg1102<def> = addC %reg1030<kill>, 0, %CCFLAGS<imp-def>
>        br mbb<ifcont267,0x12bc518>
>    Successors according to CFG: 0x12bc518 (#4)
>
>
>
> Do you have any idea what could be wrong, or how to further debug  
> the problem?
>
> Thanks a lot,
> Christian
>
>
> --
>
>
>
>
>
>
>
> sorry about that, but there is nothing I can do about it:
>
> CONFIDENTIAL NOTICE: The contents of this message, including any  
> attachments, are confidential and are intended solely for the use of  
> the person or entity to whom the message was addressed. If you are  
> not the intended recipient of this message, please be advised that  
> any dissemination, distribution, or use of the contents of this  
> message is strictly prohibited. If you received this message in  
> error, please notify the sender. Please also permanently delete all  
> copies of the original message and any attached documentation. Thank  
> you.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From dalej at apple.com  Fri Jan  9 14:04:07 2009
From: dalej at apple.com (Dale Johannesen)
Date: Fri, 9 Jan 2009 12:04:07 -0800
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <F26586BA-7F39-4CB7-998B-3D63DE6D9360@apple.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
	<4693CC4E-C418-4C66-9DAB-50443D26F40F@apple.com>
	<e50173bd0901071424l2a7d97c5pa208725459f01989@mail.gmail.com>
	<1A872920-7D3B-4D11-9FCE-C34FC8C6DFD7@apple.com>
	<F26586BA-7F39-4CB7-998B-3D63DE6D9360@apple.com>
Message-ID: <D391A953-12D5-405D-BEB0-8A5EA968D7EA@apple.com>


On Jan 9, 2009, at 11:54 AMPST, Dale Johannesen wrote:
> On Jan 9, 2009, at 11:37 AMPST, Evan Cheng wrote:
>> This looks like a bar in ARMInstrInfo.td:
>>
>> BX_RET should be marked with Uses = [LR] since it uses LR. However,
>> this won't work if there is a call BL before the BX_RET. BL is marked
>> as if it implicitly define LR. So we'll end up with this (hello world
>> example):
>
> PPC has the call (BL) marked with Defs=LR and the return (BLR)
> marked with Uses=LR, and works AFAIK.  Let me figure out what's  
> different...

OK, it's got special MFLR/MTLR instructions to do the save/restore of  
LR (actually
they go through a GR first) which are marked as use/def of LR.  You  
could simulate
something like that on ARM I guess.

>> Live Ins: %LR %R7
>>        %SP<def> = SUBri %SP<kill>, 8, 14, %reg0, %reg0
>>        STR %LR<kill>, %SP, %reg0, 4, 14, %reg0
>>        STR %R7<kill>, %SP, %reg0, 0, 14, %reg0
>>        %R7<def> = MOVr %SP, 14, %reg0, %reg0
>>        %R0<def> = LDR <cp#0>, %reg0, 0, 14, %reg0, Mem:LD(4,4)
>> [<unknown> + 0]
>>        BL <ga:puts>, %R0<kill>, %R0<imp-def,dead>, %R1<imp-
>> def,dead>, %R2<imp-def,dead>, %R3<imp-def,dead>, %R12<imp-def,dead>,
>> %LR<imp-def>, %D0<imp-def,dead>, %D1<imp-def,de\
>> ad>, %D2<imp-def,dead>, %D3<imp-def,dead>, %D4<imp-def,dead>,  
>> %D5<imp-
>> def,dead>, %D6<imp-def,dead>, %D7<imp-def,dead>, %CPSR<imp-def,dead>
>>        %R0<def> = MOVi 0, 14, %reg0, %reg0
>>        %R7<def> = LDR %SP, %reg0, 0, 14, %reg0
>>        %LR<def> = LDR %SP, %reg0, 4, 14, %reg0
>> 	%SP<def> = ADDri %SP<kill>, 8, 14, %reg0, %reg0
>>        BX_RET 14, %reg0, %R0<imp-use,kill>, %LR<imp-use,kill>
>>
>> The LR defined by BL is not killed before the PEI inserted LR  
>> restore.
>> The register scavenger doesn't like this.
>>
>> The issue is while BL does modifies LR, it doesn't actually defines  
>> LR
>> so later instructions can use it. I'll think about how to fix this.
>> It's not obvious to me at this point.
>>
>> Evan
>>
>> On Jan 7, 2009, at 2:24 PM, Roman Levenstein wrote:
>>
>>> Hi Evan,
>>>
>>> Thanks for your feedback!
>>>
>>> 2009/1/7 Evan Cheng <evan.cheng at apple.com>:
>>>>
>>>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>>>
>>>>
>>>> As you can see, PrologEpilogInserter has inserted at the beginning
>>>> of the function some code for manipulation of the frame pointer and
>>>> this inserted code uses the LR register.
>>>> As far as I understand,  ARMRegisterInfo.td should exclude the LR
>>>> register from the set of allocatable registers for functions that
>>>> require frame pointer manipulation.
>>>> But currently it is not the case, or?
>>>>
>>>> No, LR is not the frame pointer. It's the link register (caller
>>>> address). It
>>>> should be available as a general purpose register.
>>>
>>> OK.
>>>
>>>> The bug is elsewhere. It  has to do with kill / dead markers.
>>>>     %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>>>>     %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>>>>     BX_RET 14, %reg0
>>>> LR is restored here but it's not killed before the end of the block
>>>> is
>>>> reached.
>>>
>>> Hmm. I have no idea about what ARM backend does. My register  
>>> allocator
>>> just assigns the registers as I explained in my original mail.
>>> Then it lets VirtRegMap.cpp do its job, i.e. it lets it rewrite the
>>> code and replace virtual registers by the assigned physical  
>>> registers.
>>> You can see the result in the step (3) of my original mail. In my
>>> opinion, it still looks correct. May be this rewriting process does
>>> something wrong?
>>>
>>> Then PrologEpilogInserter and some other standard post RA passes are
>>> invoked for the ARM backend. But I have not changed anything  
>>> there, so
>>> I have no idea what happens.
>>>
>>> And, BTW, the instructions you mentioned above are after the
>>> instruction triggering the assertion, which is:
>>> STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>>> [0x8fc2d68 + 0]
>>>
>>>> Should BX_RET use it?
>>>
>>> I don't know the semantics of BX_RET on the ARM platform. May be it
>>> uses BX_RET somehow.
>>>
>>> BTW, an idea: May be it is easy to trigger exactly the same  
>>> behaviour
>>> with the linear scan if one does the following:
>>> - comment out dependency on the coalescer, so that it is not invoked
>>> - change the allocation order of the GPR register class for ARM, so
>>> that it starts with the LR register.
>>> ,
>>> Any ideas how to proceed with the current situation?
>>>
>>> -Roman
>>>
>>>> I hope that I provided enough information to explain my problem. I
>>>> also provided my initial analysis, but may be I'm wrong.
>>>>
>>>> Can someone more knowledgeable in ARM backend and LLVM's register
>>>> allocation framework have a look at it?
>>>> If it is a bug in the ARM backend, could it be fixed?
>>>>
>>>> Thanks,
>>>> Roman
>>>> <bugpoint-reduced-simplified.bc>
>>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From baldrick at free.fr  Fri Jan  9 14:33:50 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 9 Jan 2009 21:33:50 +0100
Subject: [LLVMdev] RFC: Store alignment should be LValue alignment,
	not source alignment
In-Reply-To: <4AD4572C-0164-47ED-892E-92F082A47820@apple.com>
References: <4AD4572C-0164-47ED-892E-92F082A47820@apple.com>
Message-ID: <200901092133.50605.baldrick@free.fr>

Hi Evan,

>    LValue LV = EmitLV(lhs);
>    bool isVolatile = TREE_THIS_VOLATILE(lhs);
>    unsigned Alignment = expr_align(exp) / 8
> 
> It's using the alignment of the expression, rather than the memory  
> object of LValue.

can't you just use expr_align(lhs) instead?

> The patch saves the alignment of the memory object in LValue returned  
> by EmitLV(). Please review it carefully as I am not entirely  
> comfortable hacking on llvm-gcc. :-)

In the long run, LValue and MemRef should be merged, but that can
wait until later I suppose.

> +  case LABEL_DECL: {
> +    Value *Ptr = TreeConstantToLLVM::EmitLV_LABEL_DECL(exp);
> +    return LValue(Ptr, DECL_ALIGN(exp) / 8);
> +  }
> +  case COMPLEX_CST: {
> +    Value *Ptr = TreeConstantToLLVM::EmitLV_COMPLEX_CST(exp);
> +    return LValue(Ptr, TYPE_ALIGN(TREE_TYPE(exp)) / 8);
> +  }
> +  case STRING_CST: {
> +    Value *Ptr = TreeConstantToLLVM::EmitLV_STRING_CST(exp);
> +    return LValue(Ptr, TYPE_ALIGN(TREE_TYPE(exp)) / 8);
> +  }

These are all equivalent to using expr_align, right?

> @@ -2290,7 +2301,7 @@ Value *TreeToLLVM::EmitLoadOfLValue(tree
>     LValue LV = EmitLV(exp);
>     bool isVolatile = TREE_THIS_VOLATILE(exp);
>     const Type *Ty = ConvertType(TREE_TYPE(exp));
> -  unsigned Alignment = expr_align(exp) / 8;
> +  unsigned Alignment = LV.getAlignment();

Here expr_align(exp) is correct I think.

> @@ -2963,7 +2974,7 @@ Value *TreeToLLVM::EmitMODIFY_EXPR(tree
> 
>     LValue LV = EmitLV(lhs);
>     bool isVolatile = TREE_THIS_VOLATILE(lhs);
> -  unsigned Alignment = expr_align(lhs) / 8;
> +  unsigned Alignment = LV.getAlignment();

Here I think expr_align(lhs) was correct.

>         LValue LV = EmitLV(Op);
>         assert(!LV.isBitfield() && "Expected an aggregate operand!");
>         bool isVolatile = TREE_THIS_VOLATILE(Op);
> -      unsigned Alignment = expr_align(Op) / 8;
> +      unsigned Alignment = LV.getAlignment();

This also looks like it was already ok.

>       if (errorcount || sorrycount) {
> -      const PointerType *Ty =
> -        PointerType::getUnqual(ConvertType(TREE_TYPE(exp)));
> -      return ConstantPointerNull::get(Ty);
> +      const Type *Ty = ConvertType(TREE_TYPE(exp));
> +      const PointerType *PTy = PointerType::getUnqual(Ty);
> +      LValue LV(ConstantPointerNull::get(PTy),  
> TD.getABITypeAlignment(Ty));
> +      return LV;

If the type is opaque or abstract, won't this assert getting the
alignment?  You might as well use 1 here, since compilation is
going to fail anyway.

> @@ -5924,7 +5936,13 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp)
>     // type void.
>     if (Ty == Type::VoidTy) Ty = StructType::get(NULL, NULL);
>     const PointerType *PTy = PointerType::getUnqual(Ty);
> -  return BitCastToType(Decl, PTy);
> +  unsigned Alignment = Ty->isSized() ? TD.getABITypeAlignment(Ty) : 1;

Can't you just use expr_align here?  That said, I'm not sure what
this case is doing.

> +  if (DECL_ALIGN_UNIT(exp)) {
> +    if (DECL_USER_ALIGN(exp) || Alignment <  
> (unsigned)DECL_ALIGN_UNIT(exp))
> +      Alignment = DECL_ALIGN_UNIT(exp);
> +  }
> +
> +  return LValue(BitCastToType(Decl, PTy), Alignment);

Since I don't know what this case handles, I can't comment on this.

>       LValue ArrayAddrLV = EmitLV(Array);
>       assert(!ArrayAddrLV.isBitfield() && "Arrays cannot be  
> bitfields!");
>       ArrayAddr = ArrayAddrLV.Ptr;
> +    ArrayAlign = ArrayAddrLV.Alignment;

Couldn't this be expr_align(Array)?

> +    const Type *ATy = cast<PointerType>(ArrayAddr->getType())- 
>  >getElementType();
> +    const Type *ElementTy = cast<ArrayType>(ATy)->getElementType();
> +    unsigned Alignment = MinAlign(ArrayAlign,  
> TD.getABITypeSize(ElementTy));

Why these manipulations?  These happens several more times below.

> @@ -6028,8 +6063,9 @@ static unsigned getComponentRefOffsetInB
> 
>   LValue TreeToLLVM::EmitLV_COMPONENT_REF(tree exp) {
>     LValue StructAddrLV = EmitLV(TREE_OPERAND(exp, 0));
> -  tree FieldDecl = TREE_OPERAND(exp, 1);
> -
> +  tree FieldDecl = TREE_OPERAND(exp, 1);
> +  unsigned LVAlign = DECL_PACKED(FieldDecl) ? 1 :  
> StructAddrLV.Alignment;

Can't this be expr_align(exp)?

I'll stop here, because I still don't understand the need
for incorporating the alignment into LValue.

Ciao,

Duncan.

From evan.cheng at apple.com  Fri Jan  9 15:50:17 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 9 Jan 2009 13:50:17 -0800
Subject: [LLVMdev] RFC: Store alignment should be LValue alignment,
	not source alignment
In-Reply-To: <200901092133.50605.baldrick@free.fr>
References: <4AD4572C-0164-47ED-892E-92F082A47820@apple.com>
	<200901092133.50605.baldrick@free.fr>
Message-ID: <C16F01DD-0F74-4DA4-A576-5D699CADAE7E@apple.com>


On Jan 9, 2009, at 12:33 PM, Duncan Sands wrote:

> Hi Evan,
>
>>   LValue LV = EmitLV(lhs);
>>   bool isVolatile = TREE_THIS_VOLATILE(lhs);
>>   unsigned Alignment = expr_align(exp) / 8
>>
>> It's using the alignment of the expression, rather than the memory
>> object of LValue.
>
> can't you just use expr_align(lhs) instead?

No. My earlier comment is wrong. Under EmitMODIFY_EXPR, it was using  
expr_align(lhs). But it's still wrong. See this example:

extern int bar(unsigned long long key_token2)
{
...
__attribute__ ((unused)) Key iospec = (Key) key_token2;

In the EmitMODIFY_EXPR case, lhs is a component_ref for this:

Here is that it looks like:

(gdb) call debug_tree(lhs)
  <component_ref 0x42cd1750
     type <integer_type 0x42c0c540 long long unsigned int sizes- 
gimplified public unsigned DI
         size <integer_cst 0x42c04930 constant invariant 64>
         unit size <integer_cst 0x42c04960 constant invariant 8>
         align 64 symtab 2 alias set -1 precision 64 min <integer_cst  
0x42c04a50 0> max <integer_cst 0x42c04a20 18446744073709551615>
	LLVM:  i64>

     arg 0 <var_decl 0x42cd6850 iospec
         type <union_type 0x42cd65b0 Key sizes-gimplified type_0 DI  
size <integer_cst 0x42c04930 64> unit size <integer_cst 0x42c04960 8>
             align 32 symtab 0 alias set -1 fields <field_decl  
0x42cd6310 key_io>>
         used asm-frame-size 0 DI file t.c line 87 size <integer_cst  
0x42c04930 64> unit size <integer_cst 0x42c04960 8>
         align 32 context <function_decl 0x42cbb600 bar> attributes  
<tree_list 0x42cc9c80>
         LLVM: %struct.Key* %iospec>
     arg 1 <field_decl 0x42cd6540 lkey type <integer_type 0x42c0c540  
long long unsigned int>
	unsigned asm-frame-size 0 DI file t.c line 61 size <integer_cst  
0x42c04930 64> unit size <integer_cst 0x42c04960 8>
	align 32 offset_align 128
	offset <integer_cst 0x42c04210 constant invariant 0>
	bit offset <integer_cst 0x42c04de0 constant invariant 0> context  
<union_type 0x42cbdc40 _Key>>>

Note type of component_ref is i64 with 8-byte alignment.   
expr_align(lhs) would return 64 here. However, the address of the  
store is iospec, which is 32-bit aligned.

>
>
>> The patch saves the alignment of the memory object in LValue returned
>> by EmitLV(). Please review it carefully as I am not entirely
>> comfortable hacking on llvm-gcc. :-)
>
> In the long run, LValue and MemRef should be merged, but that can
> wait until later I suppose.
>
>> +  case LABEL_DECL: {
>> +    Value *Ptr = TreeConstantToLLVM::EmitLV_LABEL_DECL(exp);
>> +    return LValue(Ptr, DECL_ALIGN(exp) / 8);
>> +  }
>> +  case COMPLEX_CST: {
>> +    Value *Ptr = TreeConstantToLLVM::EmitLV_COMPLEX_CST(exp);
>> +    return LValue(Ptr, TYPE_ALIGN(TREE_TYPE(exp)) / 8);
>> +  }
>> +  case STRING_CST: {
>> +    Value *Ptr = TreeConstantToLLVM::EmitLV_STRING_CST(exp);
>> +    return LValue(Ptr, TYPE_ALIGN(TREE_TYPE(exp)) / 8);
>> +  }
>
> These are all equivalent to using expr_align, right?

Yes.

>
>
>> @@ -2290,7 +2301,7 @@ Value *TreeToLLVM::EmitLoadOfLValue(tree
>>    LValue LV = EmitLV(exp);
>>    bool isVolatile = TREE_THIS_VOLATILE(exp);
>>    const Type *Ty = ConvertType(TREE_TYPE(exp));
>> -  unsigned Alignment = expr_align(exp) / 8;
>> +  unsigned Alignment = LV.getAlignment();
>
> Here expr_align(exp) is correct I think.

Not true. The result of the load might be have a generic type. For  
example, it can be i64 with alignment 64. However, the address can be  
64-bit wide but with a different alignment. LLVM load / store  
instruction alignments are equal to alignment of the memory location,  
not the value being loaded or stored.

>
>
>> @@ -2963,7 +2974,7 @@ Value *TreeToLLVM::EmitMODIFY_EXPR(tree
>>
>>    LValue LV = EmitLV(lhs);
>>    bool isVolatile = TREE_THIS_VOLATILE(lhs);
>> -  unsigned Alignment = expr_align(lhs) / 8;
>> +  unsigned Alignment = LV.getAlignment();
>
> Here I think expr_align(lhs) was correct.

No. See before.

>
>
>>        LValue LV = EmitLV(Op);
>>        assert(!LV.isBitfield() && "Expected an aggregate operand!");
>>        bool isVolatile = TREE_THIS_VOLATILE(Op);
>> -      unsigned Alignment = expr_align(Op) / 8;
>> +      unsigned Alignment = LV.getAlignment();
>
> This also looks like it was already ok.
>
>>      if (errorcount || sorrycount) {
>> -      const PointerType *Ty =
>> -        PointerType::getUnqual(ConvertType(TREE_TYPE(exp)));
>> -      return ConstantPointerNull::get(Ty);
>> +      const Type *Ty = ConvertType(TREE_TYPE(exp));
>> +      const PointerType *PTy = PointerType::getUnqual(Ty);
>> +      LValue LV(ConstantPointerNull::get(PTy),
>> TD.getABITypeAlignment(Ty));
>> +      return LV;
>
> If the type is opaque or abstract, won't this assert getting the
> alignment?  You might as well use 1 here, since compilation is
> going to fail anyway.

Makes sense.

>
>
>> @@ -5924,7 +5936,13 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp)
>>    // type void.
>>    if (Ty == Type::VoidTy) Ty = StructType::get(NULL, NULL);
>>    const PointerType *PTy = PointerType::getUnqual(Ty);
>> -  return BitCastToType(Decl, PTy);
>> +  unsigned Alignment = Ty->isSized() ?  
>> TD.getABITypeAlignment(Ty) : 1;
>
> Can't you just use expr_align here?  That said, I'm not sure what
> this case is doing.

I am not entirely sure. One thing I noticed is a gcc assigns alignment  
64 to a i64 parameter. But TD.getABITypeAlignment will return 32 here  
(which is correct).

>
>
>> +  if (DECL_ALIGN_UNIT(exp)) {
>> +    if (DECL_USER_ALIGN(exp) || Alignment <
>> (unsigned)DECL_ALIGN_UNIT(exp))
>> +      Alignment = DECL_ALIGN_UNIT(exp);
>> +  }
>> +
>> +  return LValue(BitCastToType(Decl, PTy), Alignment);
>
> Since I don't know what this case handles, I can't comment on this.
>
>>      LValue ArrayAddrLV = EmitLV(Array);
>>      assert(!ArrayAddrLV.isBitfield() && "Arrays cannot be
>> bitfields!");
>>      ArrayAddr = ArrayAddrLV.Ptr;
>> +    ArrayAlign = ArrayAddrLV.Alignment;
>
> Couldn't this be expr_align(Array)?
>
>> +    const Type *ATy = cast<PointerType>(ArrayAddr->getType())-
>>> getElementType();
>> +    const Type *ElementTy = cast<ArrayType>(ATy)->getElementType();
>> +    unsigned Alignment = MinAlign(ArrayAlign,
>> TD.getABITypeSize(ElementTy));
>
> Why these manipulations?  These happens several more times below.

According to Chris, alignment of a vector element is MinAlign(alignof  
vector, sizeof vector element).

>
>
>> @@ -6028,8 +6063,9 @@ static unsigned getComponentRefOffsetInB
>>
>>  LValue TreeToLLVM::EmitLV_COMPONENT_REF(tree exp) {
>>    LValue StructAddrLV = EmitLV(TREE_OPERAND(exp, 0));
>> -  tree FieldDecl = TREE_OPERAND(exp, 1);
>> -
>> +  tree FieldDecl = TREE_OPERAND(exp, 1);
>> +  unsigned LVAlign = DECL_PACKED(FieldDecl) ? 1 :
>> StructAddrLV.Alignment;
>
> Can't this be expr_align(exp)?

No. It will just return alignment of the expression type.

>
>
> I'll stop here, because I still don't understand the need
> for incorporating the alignment into LValue.

Hopefully my earlier explanation makes sense on why this is necessary.

Evan

>
>
> Ciao,
>
> Duncan.


From Shingoshi at comcast.net  Fri Jan  9 15:52:46 2009
From: Shingoshi at comcast.net (Xavian-Anderson Macpherson)
Date: Fri, 09 Jan 2009 13:52:46 -0800
Subject: [LLVMdev] Just how much can llvm be used?
Message-ID: <4967C72E.8080800@comcast.net>

First let me admit that I'm completely uninformed here!

1. Will llvm produce errors if llc is used to compile itself?
2. Will make produce subsequent errors if compiled first by llc/llvm?
3. Can llc be used to compile the entire Linux toolchain?

Shingoshi
-- 

From isanbard at gmail.com  Fri Jan  9 16:16:44 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Fri, 9 Jan 2009 14:16:44 -0800
Subject: [LLVMdev] Just how much can llvm be used?
In-Reply-To: <4967C72E.8080800@comcast.net>
References: <4967C72E.8080800@comcast.net>
Message-ID: <16e5fdf90901091416n526b5008u727eef1e45c1d124@mail.gmail.com>

On Fri, Jan 9, 2009 at 1:52 PM, Xavian-Anderson Macpherson
<Shingoshi at comcast.net> wrote:
> First let me admit that I'm completely uninformed here!
>
> 1. Will llvm produce errors if llc is used to compile itself?
> 2. Will make produce subsequent errors if compiled first by llc/llvm?

If by these two questions you mean "can LLVM self-host" (i.e., GCC
compiles LLVM and that LLVM then compiles LLVM) and runs without
(known) errors, then yes.

-bw

> 3. Can llc be used to compile the entire Linux toolchain?
>
> Shingoshi
> --
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From tomas.l.olsen at gmail.com  Fri Jan  9 16:47:36 2009
From: tomas.l.olsen at gmail.com (Tomas Lindquist Olsen)
Date: Fri, 9 Jan 2009 23:47:36 +0100
Subject: [LLVMdev] naked assembler / function written entirely in asm
Message-ID: <7aa9f8a40901091447n142862bbye7028ef218ce133a@mail.gmail.com>

Hi everybody.

I'm having (yet) another look at trying to get naked functions from D (1)
working in our LLVM D Compiler - LDC (2).

I have this test case:

/// D CODE
///
extern(C) int printf(char*, ...);

ulong retval() {
    asm { naked; mov EAX, 0xff; mov EDX, 0xaa; ret; }
}

ulong retval2() {
    return (cast(ulong)0xaa << 32) | 0xff;
}

void main() {
    printf("%llu\n%llu\n", retval(), retval2());
}
///
///

I've tried out a few things. This currently compiles to:

///
///
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i686-pc-linux-gnu"

@.str1 = internal constant [11 x i8] c"%llu\0A%llu\0A\00"               ;
<[11 x i8]*> [#uses=1]

declare i32 @printf(i8*, ...)

define x86_stdcallcc i64 @_D3bar6retvalFZm() noinline {
entry:
        call void asm sideeffect "movl $0, %eax ; movl $1, %edx ; ret ",
"i,i,~{eax},~{edx}"(i32 255, i32 170)
        unreachable
}

define x86_stdcallcc i64 @_D3bar7retval2FZm() {
entry:
        ret i64 730144440575
}

define x86_stdcallcc i32 @_Dmain({ i32, { i32, i8* }* } %unnamed) {
entry:
        %tmp = call x86_stdcallcc i64 @_D3bar6retvalFZm()               ;
<i64> [#uses=1]
        %tmp1 = call x86_stdcallcc i64 @_D3bar7retval2FZm()             ;
<i64> [#uses=1]
        %tmp2 = call i32 (i8*, ...)* @printf(i8* getelementptr ([11 x i8]*
@.str1, i32 0, i32 0), i64 %tmp, i64 %tmp1)           ; <i32> [#uses=0]
        ret i32 0
}
///
///

When this is linked as an application, without being optimized, it works as
expected.
But when optimized, _Dmain is reduced to:

///
///
define x86_stdcallcc i32 @_Dmain({ i32, { i32, i8* }* } %unnamed) noreturn
nounwind {
entry:
        %tmp = call x86_stdcallcc i64 @_D3bar6retvalFZm()               ;
<i64> [#uses=0]
        unreachable
}
///
///

If the first impl is changed to:

///
///
define x86_stdcallcc i64 @_D3bar6retvalFZm() noinline {
entry:
        call void asm sideeffect "movl $0, %eax ; movl $1, %edx ; ret ",
"i,i,~{eax},~{edx}"(i32 255, i32 170)
        ret i64 undef ;
}
///
///

It still works when not optimized. However, when optimized, then _Dmain
becomes:

///
///
define x86_stdcallcc i32 @_Dmain({ i32, { i32, i8* }* } %unnamed) {
entry:
        %tmp = call x86_stdcallcc i64 @_D3bar6retvalFZm()               ;
<i64> [#uses=0]
        %tmp1 = call x86_stdcallcc i64 @_D3bar7retval2FZm()             ;
<i64> [#uses=0]
        %tmp2 = call i32 (i8*, ...)* @printf(i8* getelementptr ([11 x i8]*
@.str1, i32 0, i32 0), i64 undef, i64 730144440575)           ; <i32>
[#uses=0]
        ret i32 0
}
///
///


which (as expected) prints a bogus value.

I realize I'm entering some undefined/invalid territory here, but I'd really
like to get some ideas for what I could do to make this D code work.
Ideally I would like a naked attribute for a function which would mean that
the entire function is composed of a single asm block.

Module level assembler could probably be used for this, but it would be nice
if we could get away with using a single asm translator in the compiler.

Thanx in advance,
- Tomas Lindquist Olsen

----------------------

(1): http://digitalmars.com/d/1.0/index.html
(2): http://dsource.org/projects/ldc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090109/e4d76103/attachment.html 

From evan.cheng at apple.com  Fri Jan  9 19:40:53 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 9 Jan 2009 17:40:53 -0800
Subject: [LLVMdev] How to represent zero-sized string?
Message-ID: <6178A207-AE10-492F-849D-71A54DE5A1E9@apple.com>

Hi all,

int main() {
   t("");
   return 0;
}

On Mac OS X, llvm-gcc compiles the zero-sized string to:
.lcomm  LC,1,0

gcc:
         .cstring
LC0:
         .ascii "\0"

The difference seems innocent enough. However, in objc if the zero- 
sized string is part of a cfstring, it causes a problem. The linker  
expects it in the readonly __cstring section, but llvm puts it in the  
read / write bss section.

The problem is llvm represents this as

@"\01LC" = internal constant [1 x i8] zeroinitializer

CodeGen can tell it should go into a read only section, but it cannot  
know it's a cstring. Any ideas how I can fix this? If I write the zero- 
sized string as c"A\00", bitcode reader still turns it back to  
zeroinitializer.

Thanks,

Evan

From eli.friedman at gmail.com  Sat Jan 10 03:21:06 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sat, 10 Jan 2009 01:21:06 -0800
Subject: [LLVMdev] How to represent zero-sized string?
In-Reply-To: <6178A207-AE10-492F-849D-71A54DE5A1E9@apple.com>
References: <6178A207-AE10-492F-849D-71A54DE5A1E9@apple.com>
Message-ID: <f5aa3e9b0901100121h5ceb08f8v44844428472286e3@mail.gmail.com>

On Fri, Jan 9, 2009 at 5:40 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> The difference seems innocent enough. However, in objc if the zero-
> sized string is part of a cfstring, it causes a problem. The linker
> expects it in the readonly __cstring section, but llvm puts it in the
> read / write bss section.

That seems extremely weird... what sort of magic is objc using that
could possibly care where a string is stored?  Can you give a more
complete testcase?   It sounds like LLVM isn't modelling something
which it really should be...

> The problem is llvm represents this as
>
> @"\01LC" = internal constant [1 x i8] zeroinitializer
>
> CodeGen can tell it should go into a read only section, but it cannot
> know it's a cstring. Any ideas how I can fix this? If I write the zero-
> sized string as c"A\00", bitcode reader still turns it back to
> zeroinitializer.

LangRef claims that you can specify a section for globals, although I
can't actually manage to get it to work...

-Eli

From isanbard at gmail.com  Sat Jan 10 19:46:22 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sat, 10 Jan 2009 17:46:22 -0800
Subject: [LLVMdev] How to represent zero-sized string?
In-Reply-To: <f5aa3e9b0901100121h5ceb08f8v44844428472286e3@mail.gmail.com>
References: <6178A207-AE10-492F-849D-71A54DE5A1E9@apple.com>
	<f5aa3e9b0901100121h5ceb08f8v44844428472286e3@mail.gmail.com>
Message-ID: <9E0E1F18-A46F-4440-BC83-6AC34F1A2B34@gmail.com>

On Jan 10, 2009, at 1:21 AM, Eli Friedman wrote:

> On Fri, Jan 9, 2009 at 5:40 PM, Evan Cheng <evan.cheng at apple.com>  
> wrote:
>> The difference seems innocent enough. However, in objc if the zero-
>> sized string is part of a cfstring, it causes a problem. The linker
>> expects it in the readonly __cstring section, but llvm puts it in the
>> read / write bss section.
>
> That seems extremely weird... what sort of magic is objc using that
> could possibly care where a string is stored?  Can you give a more
> complete testcase?   It sounds like LLVM isn't modelling something
> which it really should be...
>
The runtime probably has various requirements about this.

>> The problem is llvm represents this as
>>
>> @"\01LC" = internal constant [1 x i8] zeroinitializer
>>
>> CodeGen can tell it should go into a read only section, but it cannot
>> know it's a cstring. Any ideas how I can fix this? If I write the  
>> zero-
>> sized string as c"A\00", bitcode reader still turns it back to
>> zeroinitializer.
>
> LangRef claims that you can specify a section for globals, although I
> can't actually manage to get it to work...
>
We normally specify the sections in the config/darwin.c file for  
various special kinds of OBJC names (see  
darwin_objc_llvm_special_name_section()). Perhaps we could do the same  
for this? Obviously, it's not a special name, but if we could tag the  
global with the correct section then perhaps all will be well.

-bw


From clattner at apple.com  Sat Jan 10 21:54:58 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 10 Jan 2009 19:54:58 -0800
Subject: [LLVMdev] naked assembler / function written entirely in asm
In-Reply-To: <7aa9f8a40901091447n142862bbye7028ef218ce133a@mail.gmail.com>
References: <7aa9f8a40901091447n142862bbye7028ef218ce133a@mail.gmail.com>
Message-ID: <2F5493BF-FA19-468D-AFC0-EDEBEEF1E314@apple.com>

On Jan 9, 2009, at 2:47 PM, Tomas Lindquist Olsen wrote:
> Hi everybody.
>
> I'm having (yet) another look at trying to get naked functions from  
> D (1) working in our LLVM D Compiler - LDC (2).

> Module level assembler could probably be used for this, but it would  
> be nice if we could get away
> with using a single asm translator in the compiler.

I really do think that module-level asm is the right solution here.   
Unfortunately, the semantics of naked functions are very touchy, and  
you don't want (for example) the inliner to try inlining these things.

-Chris

From nicholas at mxc.ca  Sun Jan 11 02:24:15 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sun, 11 Jan 2009 00:24:15 -0800
Subject: [LLVMdev] malloc vs malloc
In-Reply-To: <A9C8E082-D996-4AED-903A-05C7376D0E20@apple.com>
References: <200812231714.08173.jon@ffconsultancy.com>
	<A9C8E082-D996-4AED-903A-05C7376D0E20@apple.com>
Message-ID: <4969ACAF.3090604@mxc.ca>

Chris Lattner wrote:
> On Dec 23, 2008, at 9:14 AM, Jon Harrop wrote:
>> I discovered that LLVM's malloc only allows a 32-bit size argument,  
>> so you
>> cannot use it to allocate huge blocks on 64-bit machines. So I  
>> considered
>> replacing all of my uses of LLVM's malloc instruction with calls to  
>> the libc
>> malloc function instead. That got me wondering why LLVM even has its  
>> own
>> malloc intrinsic anyway...
>>
>> Am I correct in assuming that LLVM's malloc intrinsic exists so that  
>> some
>> optimization passes can rewrite it, e.g. replacing heap allocation  
>> with stack
>> allocation when no part of the allocated value escapes scope? So  
>> replacing
>> all of my uses of LLVM's malloc with libc's malloc might hamper LLVM's
>> optimizations and degrade performance?
> 
> Hi Jon,
> 
> There is no good reason for malloc to be an instruction anymore.  I'd  
> be very happy if it got removed.  Even if we keep it, malloc/alloca  
> should be extended to optionally take 64-bit sizes.

I'm curious. Do we want to keep the free instruction?

Nick

> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


From clattner at apple.com  Sun Jan 11 13:22:38 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 11 Jan 2009 11:22:38 -0800
Subject: [LLVMdev] malloc vs malloc
In-Reply-To: <4969ACAF.3090604@mxc.ca>
References: <200812231714.08173.jon@ffconsultancy.com>
	<A9C8E082-D996-4AED-903A-05C7376D0E20@apple.com>
	<4969ACAF.3090604@mxc.ca>
Message-ID: <8E165ED9-864B-4C14-A1C7-F791292EADAD@apple.com>

>> There is no good reason for malloc to be an instruction anymore.  I'd
>> be very happy if it got removed.  Even if we keep it, malloc/alloca
>> should be extended to optionally take 64-bit sizes.
>
> I'm curious. Do we want to keep the free instruction?

No, there's no reason to.

-Chris

From Sachin.Punyani at microchip.com  Sun Jan 11 21:23:03 2009
From: Sachin.Punyani at microchip.com (Sachin.Punyani at microchip.com)
Date: Sun, 11 Jan 2009 20:23:03 -0700
Subject: [LLVMdev] Doubt over lib call generation
Message-ID: <F536B7C316F9474E9F7091239725AC9A01C7DC15@CHN-CL-MAIL01.mchp-main.com>

Hi,

 

The lib call (generated through LLVM framework) for 64 bit operation
returns 64 bit value. But only the lower 32 bits are consumed. Even the
users of higher part are consuming the lower 32 bit value only. 

 

Consider the case in Sparc or ARM

 

long long lla, llb;

int ia;

 

void fun() {

  lla = llb << ia;

}

 

For such targets in the DAG after LegalizeTypes the higher 32 bits are
ignored. Why are these higher 32 bits ignored? 

 

This is happening for all the lib calls returning integer value of non
legal type.

 

Regards

Sachin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090111/b3b69285/attachment.html 

From baldrick at free.fr  Mon Jan 12 02:45:10 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 12 Jan 2009 09:45:10 +0100
Subject: [LLVMdev] Doubt over lib call generation
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A01C7DC15@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A01C7DC15@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <200901120945.11173.baldrick@free.fr>

Hi,

> Consider the case in Sparc or ARM

can you please provide a testcase in bitcode (or
LLVM assembler) form.

Thanks,

Duncan.

From Sachin.Punyani at microchip.com  Mon Jan 12 03:25:36 2009
From: Sachin.Punyani at microchip.com (Sachin.Punyani at microchip.com)
Date: Mon, 12 Jan 2009 02:25:36 -0700
Subject: [LLVMdev] Doubt over lib call generation
In-Reply-To: <200901120945.11173.baldrick@free.fr>
References: <F536B7C316F9474E9F7091239725AC9A01C7DC15@CHN-CL-MAIL01.mchp-main.com>
	<200901120945.11173.baldrick@free.fr>
Message-ID: <F536B7C316F9474E9F7091239725AC9A01C7DD5E@CHN-CL-MAIL01.mchp-main.com>


> 
> Hi,
> 
> > Consider the case in Sparc or ARM
> 
> can you please provide a testcase in bitcode (or
> LLVM assembler) form.
> 

Please find the bitcode file and C file attached with.

Regards
Sachin

> Thanks,
> 
> Duncan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trysparc.bc
Type: application/octet-stream
Size: 476 bytes
Desc: trysparc.bc
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090112/9d3244f6/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trysparc.c
Type: application/octet-stream
Size: 67 bytes
Desc: trysparc.c
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090112/9d3244f6/attachment-0001.obj 

From baldrick at free.fr  Mon Jan 12 08:25:07 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 12 Jan 2009 15:25:07 +0100
Subject: [LLVMdev] Doubt over lib call generation
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A01C7DD5E@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A01C7DC15@CHN-CL-MAIL01.mchp-main.com>
	<200901120945.11173.baldrick@free.fr>
	<F536B7C316F9474E9F7091239725AC9A01C7DD5E@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <200901121525.07820.baldrick@free.fr>

> > > Consider the case in Sparc or ARM
> > 
> > can you please provide a testcase in bitcode (or
> > LLVM assembler) form.
> > 
> 
> Please find the bitcode file and C file attached with.

Thanks.  It looks to me like the entire 64 bit result
of __ashrdi3 is being used.  In the SelectionDAG you
can see this clearly, and in the final assembler the
two 32 bit halves seem to correspond to %o1 and %o0:

        call __ashrdi3
        nop
        add %l0, %lo(lla), %l1
        st %o1, [%l1+4]
        st %o0, [%l0+%lo(lla)]

Ciao,

Duncan.

From e.ge at gmx.net  Mon Jan 12 10:10:27 2009
From: e.ge at gmx.net (Edgar Geisler)
Date: Mon, 12 Jan 2009 17:10:27 +0100
Subject: [LLVMdev] IR code generation and JIT execution in a multithread
	environment
Message-ID: <000c01c974d0$49271f10$db755d30$@ge@gmx.net>

Hi Everyone,

my goal is to create a service with multiple threads, each of them
generating IR code and JIT'ing/executing it in their threads 
and some threads will share generated code through a code repository...

1. Is there a guideline/docu out there, which describes serialization of
some LLVM objects, 
especially llvm::ExecutionEngine, llvm::ModuleProvider, llvm::Module?
2. Since llvm::ExecutionEngine can contain multiple llvm::ModuleProvider
instances, 
is it a good idea to keep it as a base of a code repository?
3. Is the memory consumption by the llvm::ExecutionEngine controllable 
(i.e. via LRU algorithm for llvm::ModuleProvider instances)?

Best regards
Edgar Geisler


From gohman at apple.com  Mon Jan 12 10:24:50 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 12 Jan 2009 08:24:50 -0800
Subject: [LLVMdev] malloc vs malloc
In-Reply-To: <8E165ED9-864B-4C14-A1C7-F791292EADAD@apple.com>
References: <200812231714.08173.jon@ffconsultancy.com>
	<A9C8E082-D996-4AED-903A-05C7376D0E20@apple.com>
	<4969ACAF.3090604@mxc.ca>
	<8E165ED9-864B-4C14-A1C7-F791292EADAD@apple.com>
Message-ID: <404B7F2A-2BF7-4061-B2FB-796CA0746327@apple.com>


On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote:

>>> There is no good reason for malloc to be an instruction anymore.   
>>> I'd
>>> be very happy if it got removed.  Even if we keep it, malloc/alloca
>>> should be extended to optionally take 64-bit sizes.
>>
>> I'm curious. Do we want to keep the free instruction?
>
> No, there's no reason to.


There still are reasons to have it; just grep around for FreeInst.   
Function
attributes are not yet sufficient to replace all of those yet.

And if the ailgnment attribute on MallocInst were implemented, perhaps
via posix_memalign or other target-specific mechanisms, then MallocInst
would also have a reason to be kept.

Dan


From Micah.Villmow at amd.com  Mon Jan 12 10:26:45 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Mon, 12 Jan 2009 08:26:45 -0800
Subject: [LLVMdev] issues with my DYNAMIC_STACKALLOC impl
Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C601C91@ssanexmb1.amd.com>

I have a very simple kernel that exposes a bug in the backend I am
working on and I cannot figure out how to fix the problem. I've narrowed
down the issue to be with dynamic stack allocation. The problem I am
having is that if I declare a variable inside of the loop, the code that
my backend generates produces incorrect results; however, if I move this
declaration outside of the loop the generated code works correctly.

I've attached the two files two files.

My backend does not have a stack pointer and no memory allocations. So I
really can't use any of the approaches of the currently implemented
backends. What I would like to do is to just turn all of the stack
allocations into register moves to virtual registers. Any tips or hints
would be greatly appreciated.

 

Thanks, 

 

Micah Villmow

Systems Engineer

Advanced Technology & Performance

Advanced Micro Devices Inc.

S1-609 One AMD Place

Sunnyvale, CA. 94085

P: 408-749-3966

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090112/b364f607/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a-bad.ll
Type: application/octet-stream
Size: 5131 bytes
Desc: a-bad.ll
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090112/b364f607/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a-good.ll
Type: application/octet-stream
Size: 5131 bytes
Desc: a-good.ll
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090112/b364f607/attachment-0003.obj 

From Christian.Sayer at dibcom.fr  Mon Jan 12 11:33:10 2009
From: Christian.Sayer at dibcom.fr (Christian Sayer)
Date: Mon, 12 Jan 2009 18:33:10 +0100
Subject: [LLVMdev] implicit CC register Defs cause "physreg was not
 killed in defining block!" assert
In-Reply-To: <0F0A96F8-B4D0-4D2E-9187-A2988B32C38A@apple.com>
References: <57C38DA176A0A34A9B9F3CCCE33D3C4AE9D9D380FD@FRPAR1CL009.coe.adi.dibcom.com>
	<0F0A96F8-B4D0-4D2E-9187-A2988B32C38A@apple.com>
Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4AE9D9D38100@FRPAR1CL009.coe.adi.dibcom.com>

Evan,

>A physical register cannot be live across the block. So it
>must have a use in the block or it must be marked dead. From
>your dump, it looks like the CCFLAGS defs are not being marked
>dead. It's unclear where things went wrong, but you can step
>through LiveVariables to debug this.

Thanks for your response. I did quite some stepping through the llc
passes, and it turned out what now looks fairly obvious:
The instructions containing the CCFLAGS which are not marked dead
in the dump below (line 3+) are reg-to-reg copies inserted by the PHI elimination.
In my backend, a mov instruction is currently implemented as an add with
constant 0 (affecting condition codes).
Now LiveVariables gets executed before PHI elimination, so I am trying
to figure out if there is code in PNE which is supposed to update the
defs. Otherwise I might try to re-run LiveVariables after PNE, or
some similiar approach combining these two passes - unless you tell
me they don't get marked dead because of an implementation flaw in my
backend (or something completely else : )

Thanks again,
Christian


>>        %reg1033<def> = addC %reg1025<kill>, 0, %CCFLAGS<imp-def,dead>
>>        %reg1032<def> = addC %reg1024<kill>, 0, %CCFLAGS<imp-def,dead>
>>        %reg1095<def> = addC %reg1028, 0, %CCFLAGS<imp-def>
>>        %reg1096<def> = addC %reg1029<kill>, 0, %CCFLAGS<imp-def>
>>        %reg1097<def> = addC %reg1033<kill>, 0, %CCFLAGS<imp-def>
>>        %reg1098<def> = addC %reg1028<kill>, 0, %CCFLAGS<imp-def>
>>        %reg1099<def> = addC %reg1031<kill>, 0, %CCFLAGS<imp-def>
>>        %reg1100<def> = addC %reg1030, 0, %CCFLAGS<imp-def>
>>        %reg1101<def> = addC %reg1032<kill>, 0, %CCFLAGS<imp-def>
>>        %reg1102<def> = addC %reg1030<kill>, 0, %CCFLAGS<imp-def>
>>        br mbb<ifcont267,0x12bc518>






--








sorry about that, but there is nothing I can do about it:

CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you.


From gordonhenriksen at me.com  Mon Jan 12 11:34:59 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Mon, 12 Jan 2009 12:34:59 -0500
Subject: [LLVMdev] IR code generation and JIT execution in a multithread
 environment
In-Reply-To: <000c01c974d0$49271f10$db755d30$%ge@gmx.net>
References: <000c01c974d0$49271f10$db755d30$%ge@gmx.net>
Message-ID: <D50AD1A4-74EB-47AF-8558-EFDF2F185961@me.com>

On Jan 12, 2009, at 11:10, Edgar Geisler wrote:

> my goal is to create a service with multiple threads, each of them  
> generating IR code and JIT'ing/executing it in their threads and  
> some threads will share generated code through a code repository...


Hi Edgar,

Module and Value are unsafe for concurrent access--even disjoint  
instances thereof. So you'll need to hold a global mutex while  
loading, building, or transforming IR. The JIT can execute threaded  
code, but itself holds a global lock during code generation.

I think serializing code generation in a JIT will usually be adequate,  
since presumably the compiled program (rather than the compiler)  
should dominate runtime. However, if your project truly needs  
concurrent JIT compilation, LLVM doesn't yet meet your needs. Chris  
Lattner has disclosed an open project at Apple for providing  
multithreaded code generation and IR manipulation, but no code has yet  
hit the repository AFAIK.

You could certainly spawn subprocesses to do concurrent static code  
generation, however.

? Gordon



From tscud at cray.com  Mon Jan 12 11:35:54 2009
From: tscud at cray.com (Tony Scudiero)
Date: Mon, 12 Jan 2009 11:35:54 -0600
Subject: [LLVMdev] GlobalVaraible and Function have the same name
Message-ID: <496B7F7A.1030903@cray.com>

Hi all,

I just walked across an interesting situation in 
Module::getOrInsertFunction(Name, Type) in the LLVM C API.

In my particular case:

One of the first things we do is add a global variable named foo which 
is a [ 100 x i64 ].

Later we add a function    void foo(...)

unfortunately, when we do the getOrInsertFunction we get back

 void (...) *  bitcast ([100 x i64]* @foo_ to void (...)*)

because the symbol foo already exists in the ValueSymbolTable.

Am I correct in interpreting this as a constraint that no two items in 
the ValueSymbolTable
can have the same name, even if they're of entirely different types (in 
this case Function entry point and
global variable) ?  Is there any way, short of renaming on our end, 
around this? Thanks!


    -Tony S.





From clattner at apple.com  Mon Jan 12 12:25:11 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Jan 2009 10:25:11 -0800
Subject: [LLVMdev] malloc vs malloc
In-Reply-To: <404B7F2A-2BF7-4061-B2FB-796CA0746327@apple.com>
References: <200812231714.08173.jon@ffconsultancy.com>
	<A9C8E082-D996-4AED-903A-05C7376D0E20@apple.com>
	<4969ACAF.3090604@mxc.ca>
	<8E165ED9-864B-4C14-A1C7-F791292EADAD@apple.com>
	<404B7F2A-2BF7-4061-B2FB-796CA0746327@apple.com>
Message-ID: <50EBB56E-E8BE-49C1-83CD-5B385005A523@apple.com>


On Jan 12, 2009, at 8:24 AM, Dan Gohman wrote:

>
> On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote:
>
>>>> There is no good reason for malloc to be an instruction anymore.
>>>> I'd
>>>> be very happy if it got removed.  Even if we keep it, malloc/alloca
>>>> should be extended to optionally take 64-bit sizes.
>>>
>>> I'm curious. Do we want to keep the free instruction?
>>
>> No, there's no reason to.
>
>
> There still are reasons to have it; just grep around for FreeInst.
> Function
> attributes are not yet sufficient to replace all of those yet.
>
> And if the ailgnment attribute on MallocInst were implemented, perhaps
> via posix_memalign or other target-specific mechanisms, then  
> MallocInst
> would also have a reason to be kept.

isa<FreeInst>(X) can be replaced with:

bool isFree(Instruction *X) {
   if (CallInst *CI = dyn_cast<CallInst>(X))
     if (Function *F = CI->getCalledFunction())
       if (F->isName("free") && F->hasExternalLinkage())
         return true;
   return false;
}

There is no need to have an actual IR object for it.  posix_memalign,  
calloc, valloc and others are all great reasons why we shouldn't have  
a MallocInst either.

-Chris

From eli.friedman at gmail.com  Mon Jan 12 12:41:32 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 12 Jan 2009 10:41:32 -0800
Subject: [LLVMdev] issues with my DYNAMIC_STACKALLOC impl
In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C601C91@ssanexmb1.amd.com>
References: <5BA674C5FF7B384A92C2C95D8CC71E1C601C91@ssanexmb1.amd.com>
Message-ID: <f5aa3e9b0901121041m643e9707u185f722781c8e74a@mail.gmail.com>

On Mon, Jan 12, 2009 at 8:26 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> I have a very simple kernel that exposes a bug in the backend I am working
> on and I cannot figure out how to fix the problem. I've narrowed down the
> issue to be with dynamic stack allocation. The problem I am having is that
> if I declare a variable inside of the loop, the code that my backend
> generates produces incorrect results; however, if I move this declaration
> outside of the loop the generated code works correctly.

I haven't looked carefully, but alloca's outside of the entry block
are treated significantly differently from those outside of it.  The
issue is that the loop could capture the pointer, so it needs a new
memory location every trip through the loop.

> I've attached the two files two files.
>
> My backend does not have a stack pointer and no memory allocations.

If you can't do allocation, you shouldn't try to deal with IL with
allocas outside of the entry block.

-Eli

From clattner at apple.com  Mon Jan 12 12:51:37 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Jan 2009 10:51:37 -0800
Subject: [LLVMdev] GlobalVaraible and Function have the same name
In-Reply-To: <496B7F7A.1030903@cray.com>
References: <496B7F7A.1030903@cray.com>
Message-ID: <D7DB40A3-3D09-4487-AF30-A12F7BAEA0C7@apple.com>

On Jan 12, 2009, at 9:35 AM, Tony Scudiero wrote:
> Am I correct in interpreting this as a constraint that no two items in
> the ValueSymbolTable
> can have the same name, even if they're of entirely different types  
> (in
> this case Function entry point and
> global variable)?

Yes.

>  Is there any way, short of renaming on our end,
> around this? Thanks!

You can use some form of name mangling.  This is what C++ compilers do  
to implement support for overloading.

-Chris

From clattner at apple.com  Mon Jan 12 13:03:43 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Jan 2009 11:03:43 -0800
Subject: [LLVMdev] llvm-ld -On ?
In-Reply-To: <ee2e06e90901090822s92c7afcmfd3359d89f4b00e9@mail.gmail.com>
References: <ee2e06e90901090822s92c7afcmfd3359d89f4b00e9@mail.gmail.com>
Message-ID: <802099EF-A759-486D-9805-8F8031D6E4AF@apple.com>


On Jan 9, 2009, at 8:22 AM, Jay Foad wrote:

> It appears that in LLVM 2.4, llvm-ld no longer accepts -On options to
> control optimisation.

LLVM 2.3 and previously accepted and ignored them, llvm-ld now rejects  
them.  A lot of the llvm-ld man page were theoretical features that  
were never implemented unfortunately.

> 1. This isn't mentioned in the 2.4 release notes.

Sorry.

> 2. The man page (http://llvm.org/cmds/llvm-ld.html) still mentions -On
> in a couple of places.

Fixed.

-Chris

From gordonhenriksen at me.com  Mon Jan 12 14:19:29 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Mon, 12 Jan 2009 15:19:29 -0500
Subject: [LLVMdev] GlobalVaraible and Function have the same name
In-Reply-To: <496B7F7A.1030903@cray.com>
References: <496B7F7A.1030903@cray.com>
Message-ID: <C6E7E29F-94D0-49CA-AE48-D79650E9CA58@me.com>

On 2009-01-12, at 12:35, Tony Scudiero wrote:

> Am I correct in interpreting this as a constraint that no two items  
> in the ValueSymbolTable can have the same name, even if they're of  
> entirely different types (in this case Function entry point and  
> global variable) ?  Is there any way, short of renaming on our end,   
> around this? Thanks!


That's correct; LLVM does not support overloading symbols based on  
type. Neither does the linker, though. If you're implementing a high  
level language, you may need to implement name mangling.

http://en.wikipedia.org/wiki/Name_mangling

? Gordon



From gohman at apple.com  Mon Jan 12 15:36:21 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 12 Jan 2009 13:36:21 -0800
Subject: [LLVMdev] Small doc fix.
In-Reply-To: <c8033d570901050934ncc5cc91j452afa9b200d2773@mail.gmail.com>
References: <c8033d570901050934ncc5cc91j452afa9b200d2773@mail.gmail.com>
Message-ID: <245DB756-64E9-4E72-AD8D-EF8C5F629C7F@apple.com>

Applied, thanks!

Dan

On Jan 5, 2009, at 9:34 AM, Mahadevan R wrote:

> Hi,
>
> The LLVM Assembly Language Reference [1] incorrectly states that the
> prefix used for dll{import,export} is _imp__; it is actually __imp_.
> The attached patch fixes this.
>
> Thanks & Regards,
> -Mahadevan.
>
> [1] file:///home/mdevan/llvm/docs/LangRef.html#linkage
> <doc-dllimport- 
> prefix.patch>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From gohman at apple.com  Mon Jan 12 15:38:47 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 12 Jan 2009 13:38:47 -0800
Subject: [LLVMdev] Creating an LLVM Project
In-Reply-To: <8B6BB0A6-FD7C-4FDE-ABFB-5862983F710F@gmx.net>
References: <8B6BB0A6-FD7C-4FDE-ABFB-5862983F710F@gmx.net>
Message-ID: <67930BD4-FFD2-4E17-AAF2-52DC99706755@apple.com>


On Jan 3, 2009, at 10:20 AM, Martin Geisse wrote:
>
> 2. The line
>
> AutoRegen.sh
>
> ("Create a Project from the Sample Project", step 5) should be
> changed to
>
> ./AutoRegen.sh
>
> so it will work if . is not in the path.

Fixed.

>
>
> 3. In "Create a Project from the Sample Project", step 6 the
> arguments are used to "tell your project where the LLVM source/object
> tree is located. The tutorial doesn't really give a good hint which
> directory is meant. For example, the source is located partly in the
> lib/ and partly in the tools/ subdirectory of the main llvm
> directory. It might also refer to the main llvm directory, but the
> simple fact that the source and object directories - which are both
> within the main llvm directory -- must be specified separately
> suggests that this is not the case. In general, it left me (and
> probably others) clueless which path to specify.

It seems pretty intuitive to people already familiar with
autoconf-style srcdir!=objdir builds. Can you sugggest a
better wording?

Thanks,

Dan


From dag at cray.com  Mon Jan 12 16:00:32 2009
From: dag at cray.com (David Greene)
Date: Mon, 12 Jan 2009 16:00:32 -0600
Subject: [LLVMdev] Is it possible to use the SimpleRegisterCoalescing
	pass in an iterative way?
In-Reply-To: <e50173bd0901090136n5c7337fcs8e1ab01d8bacd6b1@mail.gmail.com>
References: <e50173bd0901090136n5c7337fcs8e1ab01d8bacd6b1@mail.gmail.com>
Message-ID: <200901121600.32950.dag@cray.com>

On Friday 09 January 2009 03:36, Roman Levenstein wrote:
> Hi,
>
> I'm implementing some variations of graph-coloring register allocators for
> LLVM. Many of them perform their phases (e.g. coalescing, graph
> simplification, spilling,  color selection) in an iterative way. Since
> LLVM provides an implementation of the coalescing in the
> SimpleRegisterCoalescing class already, I would like to reuse it (even
> though I could of course create my own coalescing implementation). But
> this class is a MachineFunctionPass.
>
> I'm wondering, if it is possible to use this pass from another pass
> (i.e. regalloc) in an iterative way:
> I need to invoke it multiple times for the same MachineFunction at
> certain places in my regalloc pass implementation.
> May be some sort of analysis update can be performed? Or is it
> designed to be used just once per MachineFunction?

Hi Roman,

I did this a while back when implementing iterative register coalescing.  My 
guess is you're trying to do the same with the Generaslized Graph Coloring 
algorithm,.

It's not easy to accomplish within the LLVM framework.  I've made a number of 
structural changes to our code here and it's in a bit of a state of bitrot due 
to upstream changes we haven't merged in yet.

I got some of this work merged upstream in the RegisterCoalescer and 
RegallocQuery interfaces.  RegallocQuery is supposed to be an opaque 
communication conduit between register allocators and coalescers such that 
the allocator can update the coalescer when it makes changes and vice versa.

When I did the full implementation I found I had to make more changes to 
RegallocQuery.  I have not pushed those upstream for various reasons, 
including that at the time the register coalescing code was in a great state 
of flux and it was difficult to track.  It will be a bit of work to get it all 
up-to-date for merging.

Evan is right that coalesceFunction is the primary interface to invoke the 
coalescer.  The iterative coalescer I wrote implements that function.  The 
iterative coalescer is also a FunctionPass which does nothing.  It's simply 
there to fulfill the requirement that the register allocator depends on a 
coalescer.  This way I could use the SimpleRegisterCoalescer or the new 
iterative coalescer in a pluggable manner.  The generalized graph coloring 
allocator holds a reference to the coalescer.  SimpleRegisterCoalescing does 
nothing in its implementation of coalesceFunction.

This is all very far from ideal.  What we really need is a PassManager that 
knows about multually dependent, iterative algorithms.  I thought about this a 
bit back in the day and came up with the idea of a hierarchy of PassManagers.  
A set of iterative passes could live in a PassManager under the top-level 
PassManager and the child PassManager could specify dependencies for all of 
the passes it manages.  I didn't get very far with this so I don't know it 
it's a viable solution.

The iterative coalescer does its own correctness and profitability analysis 
but reuses the code from SimpleRegisterCoalescing to do the actual LLVM IR and 
dataflow updates.  That's non-trivial work.  The code to do this in 
SimpleRegisterCoalescing is a bit...well...convoluted.  :)  I did a 
significant amount of work to separate that code out from the dataflow and 
profitability analysis that determines when to coalesce copies.

This I think is very valuable work and I'd like to push it back.  It's always 
good to separate analyses and updates as much as possible so that things can 
be reused.

But I can't promise that I'll be able to merge all of the work I've  done.  We 
have quite a bit going on here right now and I've been moved to other bits of 
work.  I'll see if I can get some things accomplished out-of-band.

                                                       -Dave

From criswell at cs.uiuc.edu  Mon Jan 12 16:02:23 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Mon, 12 Jan 2009 16:02:23 -0600
Subject: [LLVMdev] Creating an LLVM Project
In-Reply-To: <67930BD4-FFD2-4E17-AAF2-52DC99706755@apple.com>
References: <8B6BB0A6-FD7C-4FDE-ABFB-5862983F710F@gmx.net>
	<67930BD4-FFD2-4E17-AAF2-52DC99706755@apple.com>
Message-ID: <496BBDEF.7040204@cs.uiuc.edu>

Dan Gohman wrote:
> On Jan 3, 2009, at 10:20 AM, Martin Geisse wrote:
>   
>> 2. The line
>>
>> AutoRegen.sh
>>
>> ("Create a Project from the Sample Project", step 5) should be
>> changed to
>>
>> ./AutoRegen.sh
>>
>> so it will work if . is not in the path.
>>     
>
> Fixed.
>
>   
>> 3. In "Create a Project from the Sample Project", step 6 the
>> arguments are used to "tell your project where the LLVM source/object
>> tree is located. The tutorial doesn't really give a good hint which
>> directory is meant. For example, the source is located partly in the
>> lib/ and partly in the tools/ subdirectory of the main llvm
>> directory. It might also refer to the main llvm directory, but the
>> simple fact that the source and object directories - which are both
>> within the main llvm directory -- must be specified separately
>> suggests that this is not the case. In general, it left me (and
>> probably others) clueless which path to specify.
>>     
>
> It seems pretty intuitive to people already familiar with
> autoconf-style srcdir!=objdir builds. Can you sugggest a
> better wording?
>   
Hrm.  The projects document assumes that the reader is already familiar
with other LLVM build system issues.  It would be better if that were
clarified.

I suppose we could do one of two things:

1) Point back to the Getting Started Guide where srcdir and objdir are
more clearly defined.
2) Add a note in the beginning of the document explaining what
prerequisite material is needed and where to read it.

Thoughts on which would be better?  Is the srcdir/objdir issue the only
unclear bit in that document?

-- John T.


> Thanks,
>
> Dan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From mgeisse at gmx.net  Mon Jan 12 16:09:16 2009
From: mgeisse at gmx.net (Martin Geisse)
Date: Mon, 12 Jan 2009 23:09:16 +0100
Subject: [LLVMdev] Creating an LLVM Project
In-Reply-To: <67930BD4-FFD2-4E17-AAF2-52DC99706755@apple.com>
References: <8B6BB0A6-FD7C-4FDE-ABFB-5862983F710F@gmx.net>
	<67930BD4-FFD2-4E17-AAF2-52DC99706755@apple.com>
Message-ID: <5C91A64C-49C7-453C-886C-3B1BF2DFB451@gmx.net>


On Jan 12, 2009, at 10:38 PM, Dan Gohman wrote:

>>
>> 3. In "Create a Project from the Sample Project", step 6 the
>> arguments are used to "tell your project where the LLVM source/object
>> tree is located. The tutorial doesn't really give a good hint which
>> directory is meant. For example, the source is located partly in the
>> lib/ and partly in the tools/ subdirectory of the main llvm
>> directory. It might also refer to the main llvm directory, but the
>> simple fact that the source and object directories - which are both
>> within the main llvm directory -- must be specified separately
>> suggests that this is not the case. In general, it left me (and
>> probably others) clueless which path to specify.
>
> It seems pretty intuitive to people already familiar with
> autoconf-style srcdir!=objdir builds.

That has to be the reason I didn't understand it :)

> Can you sugggest a
> better wording?
>
> Thanks,
>
> Dan
>

Unfortunately, no, because I still have no clue what path has to be  
passed (I did not investigate any further because the autoconf  
version conflict (bug 1220, pointed out by me22) prevented me from  
configuring the paths at all. I got it working with some manual  
hacking though.

Anyways, it didn't even come to my mind that this is a standard  
feature of autoconf. Maybe a hint in that direction and/or a short  
example would be helpful.

Greetings,
Martin Geisse


From lists at grahamwakefield.net  Mon Jan 12 15:08:37 2009
From: lists at grahamwakefield.net (Graham Wakefield)
Date: Mon, 12 Jan 2009 13:08:37 -0800
Subject: [LLVMdev] IR code generation and JIT execution in a multithread
	environment
In-Reply-To: <D50AD1A4-74EB-47AF-8558-EFDF2F185961@me.com>
References: <000c01c974d0$49271f10$db755d30$%ge@gmx.net>
	<D50AD1A4-74EB-47AF-8558-EFDF2F185961@me.com>
Message-ID: <C920620B-CA68-45BB-ADD7-CB4523A41C79@grahamwakefield.net>

Quick related Q:
Does the global lock of the JIT during code generation prevent  
concurrent execution of already JIT-ted code?
Thanks.

On Jan 12, 2009, at 9:34 AM, Gordon Henriksen wrote:

> On Jan 12, 2009, at 11:10, Edgar Geisler wrote:
>
>> my goal is to create a service with multiple threads, each of them
>> generating IR code and JIT'ing/executing it in their threads and
>> some threads will share generated code through a code repository...
>
>
> Hi Edgar,
>
> Module and Value are unsafe for concurrent access--even disjoint
> instances thereof. So you'll need to hold a global mutex while
> loading, building, or transforming IR. The JIT can execute threaded
> code, but itself holds a global lock during code generation.
>
> I think serializing code generation in a JIT will usually be adequate,
> since presumably the compiled program (rather than the compiler)
> should dominate runtime. However, if your project truly needs
> concurrent JIT compilation, LLVM doesn't yet meet your needs. Chris
> Lattner has disclosed an open project at Apple for providing
> multithreaded code generation and IR manipulation, but no code has yet
> hit the repository AFAIK.
>
> You could certainly spawn subprocesses to do concurrent static code
> generation, however.
>
> ? Gordon
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From nicolas.geoffray at lip6.fr  Mon Jan 12 17:11:33 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Tue, 13 Jan 2009 00:11:33 +0100
Subject: [LLVMdev] IR code generation and JIT execution in a multithread
 environment
In-Reply-To: <C920620B-CA68-45BB-ADD7-CB4523A41C79@grahamwakefield.net>
References: <000c01c974d0$49271f10$db755d30$%ge@gmx.net>	<D50AD1A4-74EB-47AF-8558-EFDF2F185961@me.com>
	<C920620B-CA68-45BB-ADD7-CB4523A41C79@grahamwakefield.net>
Message-ID: <496BCE25.3030008@lip6.fr>

Graham Wakefield wrote:
> Quick related Q:
> Does the global lock of the JIT during code generation prevent  
> concurrent execution of already JIT-ted code?
>   

No, it's not related.

Nicolas

From nickamy at paradise.net.nz  Mon Jan 12 18:06:32 2009
From: nickamy at paradise.net.nz (Nicholas Chapman)
Date: Tue, 13 Jan 2009 13:06:32 +1300
Subject: [LLVMdev] Crash when using InstallLazyFunctionCreator and JIT on
	Linux x64.
Message-ID: <496BDB08.1020504@paradise.net.nz>

Hi everyone,
I'm running into a problem using JIT compilation on Linux x86-64.
LLVM revision is 62079.
I've installed a lazy function creator using InstallLazyFunctionCreator().
I return the value 0x5ce64e from my lazyFunctionCreator function.
However, the disassembled JIT'd function looks like this:

0x00007f45ef2b6018:    sub    $0x8,%rsp
0x00007f45ef2b601c:    mov    $0x7f45ef2b6010,%rax
0x00007f45ef2b6026:    movss  (%rax,%riz,1),%xmm0
0x00007f45ef2b602b:    movss  %xmm0,0x4(%rsp)
0x00007f45ef2b6031:    callq  0x7f46005ce64e
0x00007f45ef2b6036:    ucomiss 0x4(%rsp),%xmm0
0x00007f45ef2b603b:    setnp  %cl
0x00007f45ef2b603e:    sete   %al
0x00007f45ef2b6041:    and    %cl,%al
0x00007f45ef2b6043:    add    $0x8,%rsp
0x00007f45ef2b6047:    retq  

As you can see, the upper 32 bits of the function address that the 
function is making a call to are incorrect.
Consequently, the program makes an invalid memory access when jumping to 
0x7f46005ce64e.
Is this a known bug, or am I doing something wrong?
Any help would be greatly appreciated.
Thanks,
    Nicholas Chapman


From zhousheng00 at gmail.com  Mon Jan 12 21:16:20 2009
From: zhousheng00 at gmail.com (Zhou Sheng)
Date: Tue, 13 Jan 2009 11:16:20 +0800
Subject: [LLVMdev] llvm-gcc doesnt honor volatile quantifier of the array
	type?
Message-ID: <8abe0dc60901121916q5e67a8c7x4915d93966a4ad@mail.gmail.com>

Hi,


I encountered a problem about volatile quantifier when using llvm-gcc, here
is the example:

#define N 10

int sum(volatile int a[N]) {
   int sum = 0;
   unsigned i = 0;
   for (i = 0; i < N; ++i)
       sum += a[i];

   return sum;
}


If I compile it as C code, then llvm-gcc will dump:

define i32 @sum(i32* nocapture %a) nounwind {
bb1.thread:
    %0 = volatile load i32* %a, align 4     ; <i32> [#uses=1]
    %1 = getelementptr i32* %a, i32 1       ; <i32*> [#uses=1]
    %2 = volatile load i32* %1, align 4     ; <i32> [#uses=1]
    %3 = add i32 %2, %0     ; <i32> [#uses=1]
   ...
}

We can see the load is "volatile", this is correct and expected.


But when I compile the example as C++ code, then llvm-gcc dump:

define i32 @_Z3sumPVi(i32* nocapture %a) nounwind readonly {
bb1.thread:
    %0 = load i32* %a, align 4      ; <i32> [#uses=1]
    %1 = getelementptr i32* %a, i32 1       ; <i32*> [#uses=1]
    %2 = load i32* %1, align 4      ; <i32> [#uses=1]
    %3 = add i32 %2, %0     ; <i32> [#uses=1]
    ...
}

No volatile keeps, is it expected or a bug for llvm-gcc?

Anyone can help me?  Thanks in advance.


Sheng.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090113/b186e753/attachment.html 

From evan.cheng at apple.com  Mon Jan 12 21:35:14 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 12 Jan 2009 19:35:14 -0800
Subject: [LLVMdev] IR code generation and JIT execution in a multithread
	environment
In-Reply-To: <000c01c974d0$49271f10$db755d30$%ge@gmx.net>
References: <000c01c974d0$49271f10$db755d30$%ge@gmx.net>
Message-ID: <9BF37FAB-92BD-49A0-8B9A-CC789EA3068B@apple.com>


On Jan 12, 2009, at 8:10 AM, Edgar Geisler wrote:

> Hi Everyone,
>
> my goal is to create a service with multiple threads, each of them
> generating IR code and JIT'ing/executing it in their threads
> and some threads will share generated code through a code  
> repository...
>
> 1. Is there a guideline/docu out there, which describes  
> serialization of
> some LLVM objects,
> especially llvm::ExecutionEngine, llvm::ModuleProvider, llvm::Module?
> 2. Since llvm::ExecutionEngine can contain multiple  
> llvm::ModuleProvider
> instances,
> is it a good idea to keep it as a base of a code repository?
> 3. Is the memory consumption by the llvm::ExecutionEngine controllable
> (i.e. via LRU algorithm for llvm::ModuleProvider instances)?

Default implementation doesn't do a lot. I think it tries to coalesce  
freed memory blocks, but not much more. You can provide your own  
memory manager though.

Evan

>
>
> Best regards
> Edgar Geisler
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From nicholas at mxc.ca  Mon Jan 12 21:45:28 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 12 Jan 2009 19:45:28 -0800
Subject: [LLVMdev] malloc vs malloc
In-Reply-To: <50EBB56E-E8BE-49C1-83CD-5B385005A523@apple.com>
References: <200812231714.08173.jon@ffconsultancy.com>	<A9C8E082-D996-4AED-903A-05C7376D0E20@apple.com>	<4969ACAF.3090604@mxc.ca>	<8E165ED9-864B-4C14-A1C7-F791292EADAD@apple.com>	<404B7F2A-2BF7-4061-B2FB-796CA0746327@apple.com>
	<50EBB56E-E8BE-49C1-83CD-5B385005A523@apple.com>
Message-ID: <496C0E58.6090705@mxc.ca>

Chris Lattner wrote:
> On Jan 12, 2009, at 8:24 AM, Dan Gohman wrote:
> 
>> On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote:
>>
>>>>> There is no good reason for malloc to be an instruction anymore.
>>>>> I'd
>>>>> be very happy if it got removed.  Even if we keep it, malloc/alloca
>>>>> should be extended to optionally take 64-bit sizes.
>>>> I'm curious. Do we want to keep the free instruction?
>>> No, there's no reason to.
>>
>> There still are reasons to have it; just grep around for FreeInst.
>> Function
>> attributes are not yet sufficient to replace all of those yet.
>>
>> And if the ailgnment attribute on MallocInst were implemented, perhaps
>> via posix_memalign or other target-specific mechanisms, then  
>> MallocInst
>> would also have a reason to be kept.
> 
> isa<FreeInst>(X) can be replaced with:
> 
> bool isFree(Instruction *X) {
>    if (CallInst *CI = dyn_cast<CallInst>(X))
>      if (Function *F = CI->getCalledFunction())
>        if (F->isName("free") && F->hasExternalLinkage())

Surely you mean "llvm.free" or something, right? I don't think we want 
to start assigning meaning to otherwise arbitrary function names.

Nick

>          return true;
>    return false;
> }
> 
> There is no need to have an actual IR object for it.  posix_memalign,  
> calloc, valloc and others are all great reasons why we shouldn't have  
> a MallocInst either.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


From regehr at cs.utah.edu  Mon Jan 12 22:07:52 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Mon, 12 Jan 2009 21:07:52 -0700 (MST)
Subject: [LLVMdev] llvm-gcc doesnt honor volatile quantifier of the
 array type?
In-Reply-To: <8abe0dc60901121916q5e67a8c7x4915d93966a4ad@mail.gmail.com>
References: <8abe0dc60901121916q5e67a8c7x4915d93966a4ad@mail.gmail.com>
Message-ID: <alpine.DEB.1.00.0901122059030.22687@babel.cs.utah.edu>

This looks wrong to me, though the x86 backend produces code that does the 
right thing (reads each element once).

If you change the code (see below) to read each element twice, llvm-gcc 
still does the right thing but llvm-g++ does not (i.e. it fails to read 
aech location twice).  Current versions of gcc/g++ also look wrong.

All 4 compilers (gcc,g++,llvm-gcc,llvm-g++) do the right thing when the 
array is global.

John


#define N 3

typedef volatile int vint;

int sum(vint a[N]) {
   int sum = 0;
   unsigned i;
   for (i = 0; i < N; i++)
     sum += a[i] + a[i];
   return sum;
}



On Tue, 13 Jan 2009, Zhou Sheng wrote:

> Hi,
>
>
> I encountered a problem about volatile quantifier when using llvm-gcc, here
> is the example:
>
> #define N 10
>
> int sum(volatile int a[N]) {
>   int sum = 0;
>   unsigned i = 0;
>   for (i = 0; i < N; ++i)
>       sum += a[i];
>
>   return sum;
> }
>
>
> If I compile it as C code, then llvm-gcc will dump:
>
> define i32 @sum(i32* nocapture %a) nounwind {
> bb1.thread:
>    %0 = volatile load i32* %a, align 4     ; <i32> [#uses=1]
>    %1 = getelementptr i32* %a, i32 1       ; <i32*> [#uses=1]
>    %2 = volatile load i32* %1, align 4     ; <i32> [#uses=1]
>    %3 = add i32 %2, %0     ; <i32> [#uses=1]
>   ...
> }
>
> We can see the load is "volatile", this is correct and expected.
>
>
> But when I compile the example as C++ code, then llvm-gcc dump:
>
> define i32 @_Z3sumPVi(i32* nocapture %a) nounwind readonly {
> bb1.thread:
>    %0 = load i32* %a, align 4      ; <i32> [#uses=1]
>    %1 = getelementptr i32* %a, i32 1       ; <i32*> [#uses=1]
>    %2 = load i32* %1, align 4      ; <i32> [#uses=1]
>    %3 = add i32 %2, %0     ; <i32> [#uses=1]
>    ...
> }
>
> No volatile keeps, is it expected or a bug for llvm-gcc?
>
> Anyone can help me?  Thanks in advance.
>
>
> Sheng.
>

From clattner at apple.com  Mon Jan 12 22:29:21 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Jan 2009 20:29:21 -0800
Subject: [LLVMdev] malloc vs malloc
In-Reply-To: <496C0E58.6090705@mxc.ca>
References: <200812231714.08173.jon@ffconsultancy.com>
	<A9C8E082-D996-4AED-903A-05C7376D0E20@apple.com>
	<4969ACAF.3090604@mxc.ca>
	<8E165ED9-864B-4C14-A1C7-F791292EADAD@apple.com>
	<404B7F2A-2BF7-4061-B2FB-796CA0746327@apple.com>
	<50EBB56E-E8BE-49C1-83CD-5B385005A523@apple.com>
	<496C0E58.6090705@mxc.ca>
Message-ID: <FD6D8D10-03A6-41B3-AF03-7D2DECB95FB3@apple.com>

On Jan 12, 2009, at 7:45 PM, Nick Lewycky wrote:
>> isa<FreeInst>(X) can be replaced with:
>>
>> bool isFree(Instruction *X) {
>>   if (CallInst *CI = dyn_cast<CallInst>(X))
>>     if (Function *F = CI->getCalledFunction())
>>       if (F->isName("free") && F->hasExternalLinkage())
>
> Surely you mean "llvm.free" or something, right? I don't think we want
> to start assigning meaning to otherwise arbitrary function names.

No, I mean "free".  Dan Gohman and I discussed this today.  A short  
version in no particular order is:

1) in practice, IMO, everyone building for user space has libc in  
their address space, even if they are supporting some non-C language  
like haskell or ocaml or something.
2) in practice, IMO, if an app is in kernel space or embedded, if they  
use a symbol (e.g. printf) it almost certainly does what ansi says it  
does.
3) I really think the functionality of simplifylibcalls should be  
moved into instcombine someday, so that it is run more than once and  
is iterative.
4) we want other passes to be able to optimize libcalls.  For example,  
the stuff I added in r61918 requires GVN or memcpyopt to optimize  
things like strlen.
5) regardless of #1/2, we want to support things like -fno-builtin- 
free someday.  -ffree-standing would also imply this sort of thing, as  
would -fno-builtins etc.
6) there are other routines that we want to make assumptions about,  
that are almost certainly true, but are not standard conformant.  I'm  
thinking things like "operator new is sane and thus the result is  
noalias".  This specific example should be controlled by something  
like -foperator-new-is-sane, and probably default to on.

To me, there are two solutions.  One bad solution, for various  
reasons, is to create an llvm.foo for every foo function we want to  
optimize.  IMO, a better solution is to introduce *one* new function  
attribute "is normal" or "may not be normal" (name suggestions  
welcome, pick your parity) which can be set on a function.  All  
existing libcall optimization stuff would be predicated on the  
function being named the right thing, external, and "normal".  This  
would allow language independent optimizations like instcombine to do  
this stuff.

-Chris

From regehr at cs.utah.edu  Mon Jan 12 23:20:02 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Mon, 12 Jan 2009 22:20:02 -0700 (MST)
Subject: [LLVMdev] llvm-gcc doesnt honor volatile quantifier of the
 array type?
In-Reply-To: <alpine.DEB.1.00.0901122059030.22687@babel.cs.utah.edu>
References: <8abe0dc60901121916q5e67a8c7x4915d93966a4ad@mail.gmail.com>
	<alpine.DEB.1.00.0901122059030.22687@babel.cs.utah.edu>
Message-ID: <alpine.DEB.1.00.0901122219500.24593@babel.cs.utah.edu>

I filed a bug on this:

http://llvm.org/bugs/show_bug.cgi?id=3320

John



On Mon, 12 Jan 2009, John Regehr wrote:

> This looks wrong to me, though the x86 backend produces code that does the
> right thing (reads each element once).
>
> If you change the code (see below) to read each element twice, llvm-gcc
> still does the right thing but llvm-g++ does not (i.e. it fails to read
> aech location twice).  Current versions of gcc/g++ also look wrong.
>
> All 4 compilers (gcc,g++,llvm-gcc,llvm-g++) do the right thing when the
> array is global.
>
> John
>
>
> #define N 3
>
> typedef volatile int vint;
>
> int sum(vint a[N]) {
>   int sum = 0;
>   unsigned i;
>   for (i = 0; i < N; i++)
>     sum += a[i] + a[i];
>   return sum;
> }
>
>
>
> On Tue, 13 Jan 2009, Zhou Sheng wrote:
>
>> Hi,
>>
>>
>> I encountered a problem about volatile quantifier when using llvm-gcc, here
>> is the example:
>>
>> #define N 10
>>
>> int sum(volatile int a[N]) {
>>   int sum = 0;
>>   unsigned i = 0;
>>   for (i = 0; i < N; ++i)
>>       sum += a[i];
>>
>>   return sum;
>> }
>>
>>
>> If I compile it as C code, then llvm-gcc will dump:
>>
>> define i32 @sum(i32* nocapture %a) nounwind {
>> bb1.thread:
>>    %0 = volatile load i32* %a, align 4     ; <i32> [#uses=1]
>>    %1 = getelementptr i32* %a, i32 1       ; <i32*> [#uses=1]
>>    %2 = volatile load i32* %1, align 4     ; <i32> [#uses=1]
>>    %3 = add i32 %2, %0     ; <i32> [#uses=1]
>>   ...
>> }
>>
>> We can see the load is "volatile", this is correct and expected.
>>
>>
>> But when I compile the example as C++ code, then llvm-gcc dump:
>>
>> define i32 @_Z3sumPVi(i32* nocapture %a) nounwind readonly {
>> bb1.thread:
>>    %0 = load i32* %a, align 4      ; <i32> [#uses=1]
>>    %1 = getelementptr i32* %a, i32 1       ; <i32*> [#uses=1]
>>    %2 = load i32* %1, align 4      ; <i32> [#uses=1]
>>    %3 = add i32 %2, %0     ; <i32> [#uses=1]
>>    ...
>> }
>>
>> No volatile keeps, is it expected or a bug for llvm-gcc?
>>
>> Anyone can help me?  Thanks in advance.
>>
>>
>> Sheng.
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From echeng at apple.com  Tue Jan 13 00:38:33 2009
From: echeng at apple.com (Evan Cheng)
Date: Mon, 12 Jan 2009 22:38:33 -0800
Subject: [LLVMdev] insertAfter method Patch
In-Reply-To: <49661887.3090702@cs.princeton.edu>
References: <1676105101.1290691231378156126.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU>
	<4966163A.2010601@cs.uiuc.edu> <49661887.3090702@cs.princeton.edu>
Message-ID: <6BF96D9A-4D13-4975-96C3-6C983DEC2643@apple.com>

Looks fine. Have you committed this?

Evan
On Jan 8, 2009, at 7:15 AM, Thomas Jablin wrote:

> John Criswell wrote:
>> Small nitpick: in Instruction.cpp, the comment for insertAfter says  
>> insertBefore and not insertAfter.
>> :)
>>
>> -- John T.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> Thanks for spotting the problem. Looking at the code again, I made  
> the same mistake in the comment in Instruction.h.  Here is the patch  
> with the corrected comments.
> Tom
> <AddInsertAfter.patch>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From echeng at apple.com  Tue Jan 13 00:46:36 2009
From: echeng at apple.com (Evan Cheng)
Date: Mon, 12 Jan 2009 22:46:36 -0800
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
Message-ID: <02AF6D36-5ABC-45F9-830D-E970760DC768@apple.com>


On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:

> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>    Predecessors according to CFG: 0x8fdac90 (#0)
>        %R0<def> = MOVi 0, 14, %reg0, %reg0
> ***     STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
> [0x8fc2d68 + 0]
>        %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>        %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>        BX_RET 14, %reg0

Ok, ignore my earlier email about BX_RET. The issue is LR should be  
added to livein of BB #1.

**** Post Machine Instrs ****
# Machine code for Insert():
Live Ins: R0 in VR#1025  R1 in VR#1026

entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0:
Live Ins: %R0 %R1
        %LR<def> = MOVr %R0, 14, %reg0, %reg0
        CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def>
        Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill>
    Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2)

bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
    Predecessors according to CFG: 0x8fdac90 (#0)
        %R0<def> = MOVi 0, 14, %reg0, %reg0
        STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
[0x8fc2d68 + 0]
        BX_RET 14, %reg0

Here the STR is using LR, but there isn't a def earlier.

Evan

From clattner at apple.com  Tue Jan 13 01:44:17 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Jan 2009 23:44:17 -0800
Subject: [LLVMdev] insertAfter method Patch
In-Reply-To: <49661887.3090702@cs.princeton.edu>
References: <1676105101.1290691231378156126.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU>
	<4966163A.2010601@cs.uiuc.edu> <49661887.3090702@cs.princeton.edu>
Message-ID: <39D0C989-8D96-41F7-8A21-260545024F4A@apple.com>


On Jan 8, 2009, at 7:15 AM, Thomas Jablin wrote:

> John Criswell wrote:
>> Small nitpick: in Instruction.cpp, the comment for insertAfter says  
>> insertBefore and not insertAfter.
>> :)
>>
>> -- John T.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> Thanks for spotting the problem. Looking at the code again, I made  
> the same mistake in the comment in Instruction.h.  Here is the patch  
> with the corrected comments.
> Tom

Applied, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090112/072078.html



From libors at gmail.com  Tue Jan 13 03:12:12 2009
From: libors at gmail.com (Libor Spacek)
Date: Tue, 13 Jan 2009 09:12:12 -0000
Subject: [LLVMdev] Creating an LLVM Project
In-Reply-To: <mailman.90.1231818341.5394.llvmdev@cs.uiuc.edu>
References: <mailman.90.1231818341.5394.llvmdev@cs.uiuc.edu>
Message-ID: <op.unouik2p6yy425@ubangu>

On Tue, 13 Jan 2009 03:45:41 -0000, <llvmdev-request at cs.uiuc.edu> wrote:

> Hrm.  The projects document assumes that the reader is already familiar
> with other LLVM build system issues.  It would be better if that were
> clarified.
> 
> I suppose we could do one of two things:
> 
> 1) Point back to the Getting Started Guide where srcdir and objdir are
> more clearly defined.
> 2) Add a note in the beginning of the document explaining what
> prerequisite material is needed and where to read it.
> 
> Thoughts on which would be better?  Is the srcdir/objdir issue the only
> unclear bit in that document?
> 
> -- John T.


As a beginner, I found the following additional points difficult:

1) It is not emphasised enough that the paths must be hard-coded full paths.
But why? This makes portability of one's project impossible.

2) None of it even begins to work in practice, unless you happen to have
the same old version of autoconf.

Libor

From romix.llvm at googlemail.com  Tue Jan 13 02:27:21 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Tue, 13 Jan 2009 09:27:21 +0100
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <02AF6D36-5ABC-45F9-830D-E970760DC768@apple.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
	<02AF6D36-5ABC-45F9-830D-E970760DC768@apple.com>
Message-ID: <e50173bd0901130027x76a831dew5a23a2128d23703@mail.gmail.com>

2009/1/13 Evan Cheng <echeng at apple.com>:
>
> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>
>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>   Predecessors according to CFG: 0x8fdac90 (#0)
>>       %R0<def> = MOVi 0, 14, %reg0, %reg0
>> ***     STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>> [0x8fc2d68 + 0]
>>       %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>>       %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>>       BX_RET 14, %reg0
>
> Ok, ignore my earlier email about BX_RET. The issue is LR should be added to
> livein of BB #1.

Who should do it?
Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables
should do it or do you mean that my regalloc should do it?

> **** Post Machine Instrs ****
> # Machine code for Insert():
> Live Ins: R0 in VR#1025  R1 in VR#1026
>
> entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0:
> Live Ins: %R0 %R1
>       %LR<def> = MOVr %R0, 14, %reg0, %reg0
>       CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def>
>       Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill>
>   Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2)
>
> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>   Predecessors according to CFG: 0x8fdac90 (#0)
>       %R0<def> = MOVi 0, 14, %reg0, %reg0
>       STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
> [0x8fc2d68 + 0]
>       BX_RET 14, %reg0
>
> Here the STR is using LR, but there isn't a def earlier.

May be I overlook something, but doesn't
 %LR<def> = MOVr %R0, 14, %reg0, %reg0
in MBB#0 define the LR? It should be enough, or?

-Roman

From clattner at apple.com  Tue Jan 13 02:32:47 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 13 Jan 2009 00:32:47 -0800
Subject: [LLVMdev] make bugpoint-jit
Message-ID: <008A021F-F120-4687-B632-CE60DF135C1C@apple.com>

Does anyone have an objection to making the 'make bugpoint-jit'  
targets default to passing  -safe-run-llc?

When debugging JIT problems, usually llc is known-good.  Using -safe- 
run-llc makes things like fastcc and other things work better than  
relying on the CBE.

-Chris

From romix.llvm at googlemail.com  Tue Jan 13 02:54:28 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Tue, 13 Jan 2009 09:54:28 +0100
Subject: [LLVMdev] Is it possible to use the SimpleRegisterCoalescing
	pass in an iterative way?
In-Reply-To: <200901121600.32950.dag@cray.com>
References: <e50173bd0901090136n5c7337fcs8e1ab01d8bacd6b1@mail.gmail.com>
	<200901121600.32950.dag@cray.com>
Message-ID: <e50173bd0901130054m47b2582fk7bb8080f3c1e8da5@mail.gmail.com>

Hi Dave,

Thanks a lot for such an elaborative answer!

2009/1/12 David Greene <dag at cray.com>:
> On Friday 09 January 2009 03:36, Roman Levenstein wrote:
>> Hi,
>>
>> I'm implementing some variations of graph-coloring register allocators for
>> LLVM. Many of them perform their phases (e.g. coalescing, graph
>> simplification, spilling,  color selection) in an iterative way. Since
>> LLVM provides an implementation of the coalescing in the
>> SimpleRegisterCoalescing class already, I would like to reuse it (even
>> though I could of course create my own coalescing implementation). But
>> this class is a MachineFunctionPass.
>>
>> I'm wondering, if it is possible to use this pass from another pass
>> (i.e. regalloc) in an iterative way:
>> I need to invoke it multiple times for the same MachineFunction at
>> certain places in my regalloc pass implementation.
>> May be some sort of analysis update can be performed? Or is it
>> designed to be used just once per MachineFunction?
>
> Hi Roman,
>
> I did this a while back when implementing iterative register coalescing.  My
> guess is you're trying to do the same with the Generaslized Graph Coloring
> algorithm,.

You are absolutely right.

> It's not easy to accomplish within the LLVM framework.  I've made a number of
> structural changes to our code here and it's in a bit of a state of bitrot due
> to upstream changes we haven't merged in yet.
>
> I got some of this work merged upstream in the RegisterCoalescer and
> RegallocQuery interfaces.  RegallocQuery is supposed to be an opaque
> communication conduit between register allocators and coalescers such that
> the allocator can update the coalescer when it makes changes and vice versa.

Yes. Initially I didn't notice RegallocQuery in the header files. But
after Even pointed out that it can be used, I had a closer look at it.

> When I did the full implementation I found I had to make more changes to
> RegallocQuery.

Yes. This was exactly my conclusion. Namely, it would require quite
some work to implement a coalescer this way using this interface.
Too many pieces are missing yet.

> I have not pushed those upstream for various reasons,
> including that at the time the register coalescing code was in a great state
> of flux and it was difficult to track.  It will be a bit of work to get it all
> up-to-date for merging.

I see.

> Evan is right that coalesceFunction is the primary interface to invoke the
> coalescer.  The iterative coalescer I wrote implements that function.  The
> iterative coalescer is also a FunctionPass which does nothing.  It's simply
> there to fulfill the requirement that the register allocator depends on a
> coalescer.  This way I could use the SimpleRegisterCoalescer or the new
> iterative coalescer in a pluggable manner.

Yes. Using coalescers in a pluggable manner would be the ideal solution.

> The generalized graph coloring
> allocator holds a reference to the coalescer.  SimpleRegisterCoalescing does
> nothing in its implementation of coalesceFunction.

The idea with the empty pass is really nice, but looks a bit like a hack ;-)

> This is all very far from ideal.

;-)

> What we really need is a PassManager that
> knows about multually dependent, iterative algorithms.  I thought about this a
> bit back in the day and came up with the idea of a hierarchy of PassManagers.
> A set of iterative passes could live in a PassManager under the top-level
> PassManager and the child PassManager could specify dependencies for all of
> the passes it manages.  I didn't get very far with this so I don't know it
> it's a viable solution.

I was also thinking about something of this kind. But I was too lazy
to come up with a practical solution for it.

> The iterative coalescer does its own correctness and profitability analysis
> but reuses the code from SimpleRegisterCoalescing to do the actual LLVM IR and
> dataflow updates.  That's non-trivial work.

Oh, yes.

> The code to do this in SimpleRegisterCoalescing is a bit...well...convoluted.  :)

I'd say that the whole SimpleRegisterCoalescing is a
bit...well...overcomplicated :-)

It does a very, very good job doing aggressive coalescing (and taking
into account subtle subregs related things and updating the
LiveIntervals information), but IMHO it became so complex that it is
almost unmaintainable. I've seen different coalescers for graph
coloring (Chitin, Chaitin-Briggs, iterated register coalescing,
chordal graph based ones) and linear scan (Wimmer-based) register
allocators. But SimpleRegisterCoalescing in LLVM (I particulary like
"Simple" in its name ;-) is by far the most complex one I've seen so
far.  I think, only Evan can completely understand it by now. And
there are still subtle bugs in it being found every week or two and
fixed in the mainline. It is not a very good sign...

Not that I have a constructive solution for it, but may at some point
it should be split into independent parts that are more
understandable? Or may be it should be even completely redesigned to
become more understandable?

> I did a significant amount of work to separate that code out from the dataflow and
> profitability analysis that determines when to coalesce copies.

> This I think is very valuable work and I'd like to push it back.  It's always
> good to separate analyses and updates as much as possible so that things can
> be reused.

Absolutely!

> But I can't promise that I'll be able to merge all of the work I've  done.  We
> have quite a bit going on here right now and I've been moved to other bits of
> work.  I'll see if I can get some things accomplished out-of-band.

It would be very good, if you could push this code back to LLVM and
make it available for others.
I hope very much that you'll find some time for it!

On my side, after looking at alternatives, I decided to use my own
custom coalescers for now. They are small, clean and do what I need.
And I have even a limited reuse among the three GC-based register
allocators I'm working on (Chitin, Chitin-Briggs, iterated register
coalescing). It is not an ideal solution; but for now I'm more
concerned about the quality and speed of my register allocators. Once
I'm happy with that, I'll probably have a closer look and refactor the
code to make it more reusable as a part of a framework.

-Roman

From Sachin.Punyani at microchip.com  Tue Jan 13 04:08:51 2009
From: Sachin.Punyani at microchip.com (Sachin.Punyani at microchip.com)
Date: Tue, 13 Jan 2009 03:08:51 -0700
Subject: [LLVMdev] [llvm-commits] [llvm] r58505 -
	/llvm/trunk/lib/VMCore/Type.cpp
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A01C7DEFD@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A01C7DEFD@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <F536B7C316F9474E9F7091239725AC9A01C7E040@CHN-CL-MAIL01.mchp-main.com>

> 
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> bounces at cs.uiuc.edu] On Behalf Of Chris Lattner
> Sent: Saturday, November 01, 2008 1:49 AM
> To: Commit Messages and Patches for LLVM
> Subject: Re: [llvm-commits] [llvm] r58505 -
> /llvm/trunk/lib/VMCore/Type.cpp
> 
> On Oct 31, 2008, at 3:26 AM, Sanjiv Gupta wrote:
> 
> > Author: sgupta
> > Date: Fri Oct 31 05:26:20 2008
> > New Revision: 58505
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=58505&view=rev
> > Log:
> > For some targets pointer and int are 16-bits. Allow 16-bits as a
> > valid index
> > in such cases.
> 
> Sanjiv,
> 
> Are you planning to make changes to the bc reader/writer, docs, and
> other parts of the compiler to support this change?  I'd strongly
> prefer to you produce a more holistic patch that makes this change
> instead of a couple individual places.
> 

Hi Chris,

I am starting an old pending task. This is to make 16 bit integer a
valid index.

Above in the mail is the link to modification that Sanjiv made. Also, I
have just gone through an old discussion related to index validity. Here
is the link -
http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-July/015674.html

Can you please provide some pointers to what kind of changes bc
reader/writer or other areas of compiler would require.

Regards
Sachin

> I think this is the right way to go, but I don't want to get stuck
> with half of the change in the tree but it not working 100%.
> 
> -Chris
> 



From evan.cheng at apple.com  Tue Jan 13 04:19:32 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 13 Jan 2009 02:19:32 -0800
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <e50173bd0901130027x76a831dew5a23a2128d23703@mail.gmail.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
	<02AF6D36-5ABC-45F9-830D-E970760DC768@apple.com>
	<e50173bd0901130027x76a831dew5a23a2128d23703@mail.gmail.com>
Message-ID: <62E18334-B36C-41BF-8CA8-7F86448E9632@apple.com>



On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com 
 > wrote:

> 2009/1/13 Evan Cheng <echeng at apple.com>:
>>
>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>
>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>>  Predecessors according to CFG: 0x8fdac90 (#0)
>>>      %R0<def> = MOVi 0, 14, %reg0, %reg0
>>> ***     STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>>> [0x8fc2d68 + 0]
>>>      %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>>>      %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>>>      BX_RET 14, %reg0
>>
>> Ok, ignore my earlier email about BX_RET. The issue is LR should be  
>> added to
>> livein of BB #1.
>
> Who should do it?
> Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables
> should do it or do you mean that my regalloc should do it?

Register allocator should update mbb Livein info.

>
>
>> **** Post Machine Instrs ****
>> # Machine code for Insert():
>> Live Ins: R0 in VR#1025  R1 in VR#1026
>>
>> entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0:
>> Live Ins: %R0 %R1
>>      %LR<def> = MOVr %R0, 14, %reg0, %reg0
>>      CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def>
>>      Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill>
>>  Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2)
>>
>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>  Predecessors according to CFG: 0x8fdac90 (#0)
>>      %R0<def> = MOVi 0, 14, %reg0, %reg0
>>      STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>> [0x8fc2d68 + 0]
>>      BX_RET 14, %reg0
>>
>> Here the STR is using LR, but there isn't a def earlier.
>
> May be I overlook something, but doesn't
> %LR<def> = MOVr %R0, 14, %reg0, %reg0
> in MBB#0 define the LR? It should be enough, or?

Every machine basic block must list physical register livein's.

Evan

>
>
> -Roman

From romix.llvm at googlemail.com  Tue Jan 13 04:38:56 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Tue, 13 Jan 2009 11:38:56 +0100
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <62E18334-B36C-41BF-8CA8-7F86448E9632@apple.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
	<02AF6D36-5ABC-45F9-830D-E970760DC768@apple.com>
	<e50173bd0901130027x76a831dew5a23a2128d23703@mail.gmail.com>
	<62E18334-B36C-41BF-8CA8-7F86448E9632@apple.com>
Message-ID: <e50173bd0901130238ic28dae8l24071597555427c0@mail.gmail.com>

Hi again,

2009/1/13 Evan Cheng <evan.cheng at apple.com>:
>
>
> On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com>
> wrote:
>
>> 2009/1/13 Evan Cheng <echeng at apple.com>:
>>>
>>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>>
>>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>>>  Predecessors according to CFG: 0x8fdac90 (#0)
>>>>     %R0<def> = MOVi 0, 14, %reg0, %reg0
>>>> ***     STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>>>> [0x8fc2d68 + 0]
>>>>     %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>>>>     %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>>>>     BX_RET 14, %reg0
>>>
>>> Ok, ignore my earlier email about BX_RET. The issue is LR should be added
>>> to
>>> livein of BB #1.
>>
>> Who should do it?
>> Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables
>> should do it or do you mean that my regalloc should do it?
>
> Register allocator should update mbb Livein info.

OK.

>>
>>
>>> **** Post Machine Instrs ****
>>> # Machine code for Insert():
>>> Live Ins: R0 in VR#1025  R1 in VR#1026
>>>
>>> entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0:
>>> Live Ins: %R0 %R1
>>>     %LR<def> = MOVr %R0, 14, %reg0, %reg0
>>>     CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def>
>>>     Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill>
>>>  Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2)
>>>
>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>>  Predecessors according to CFG: 0x8fdac90 (#0)
>>>     %R0<def> = MOVi 0, 14, %reg0, %reg0
>>>     STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>>> [0x8fc2d68 + 0]
>>>     BX_RET 14, %reg0
>>>
>>> Here the STR is using LR, but there isn't a def earlier.
>>
>> May be I overlook something, but doesn't
>> %LR<def> = MOVr %R0, 14, %reg0, %reg0
>> in MBB#0 define the LR? It should be enough, or?
>
> Every machine basic block must list physical register livein's.

One question, just to be sure I understand you correctly. You mean
that after the RegAlloc has assigned physical registers to
LiveIntervals and before it calls the VRM to rewrite the function, it
should explicitly add lives-ins for each MBB, just like LinearScan
does it at the end of the RALinScan::linearScan() function???

E.g. like this:

  // Add live-ins to every BB except for entry. Also perform trivial coalescing.
  MachineFunction::iterator EntryMBB = mf_->begin();
  SmallVector<MachineBasicBlock*, 8> LiveInMBBs;
  for (LiveIntervals::iterator i = li_->begin(), e = li_->end(); i != e; ++i) {
    LiveInterval &cur = *i->second;
    unsigned Reg = 0;
    bool isPhys = TargetRegisterInfo::isPhysicalRegister(cur.reg);
    if (isPhys)
      Reg = cur.reg;
    else if (vrm_->isAssignedReg(cur.reg))
      Reg = attemptTrivialCoalescing(cur, vrm_->getPhys(cur.reg));
    if (!Reg)
      continue;
    // Ignore splited live intervals.
    if (!isPhys && vrm_->getPreSplitReg(cur.reg))
      continue;
    for (LiveInterval::Ranges::const_iterator I = cur.begin(), E = cur.end();
         I != E; ++I) {
      const LiveRange &LR = *I;
      if (li_->findLiveInMBBs(LR.start, LR.end, LiveInMBBs)) {
        for (unsigned i = 0, e = LiveInMBBs.size(); i != e; ++i)
          if (LiveInMBBs[i] != EntryMBB)
            LiveInMBBs[i]->addLiveIn(Reg);
        LiveInMBBs.clear();
      }
    }
  }

If it is the case, it is OK. It was not clear for me that one has to
do it in the regalloc. My assumption was that VRM would do it.

Thanks a lot,
  Roman

From jay.foad at gmail.com  Tue Jan 13 04:51:09 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Tue, 13 Jan 2009 10:51:09 +0000
Subject: [LLVMdev] llvm-ld -On ?
In-Reply-To: <802099EF-A759-486D-9805-8F8031D6E4AF@apple.com>
References: <ee2e06e90901090822s92c7afcmfd3359d89f4b00e9@mail.gmail.com>
	<802099EF-A759-486D-9805-8F8031D6E4AF@apple.com>
Message-ID: <ee2e06e90901130251ra637685t875592908267446e@mail.gmail.com>

>> It appears that in LLVM 2.4, llvm-ld no longer accepts -On options to
>> control optimisation.
>
> LLVM 2.3 and previously accepted and ignored them, llvm-ld now rejects
> them.  A lot of the llvm-ld man page were theoretical features that
> were never implemented unfortunately.

Fair enough.

>> 2. The man page (http://llvm.org/cmds/llvm-ld.html) still mentions -On
>> in a couple of places.
>
> Fixed.

Thanks!

Jay.

From Christian.Sayer at dibcom.fr  Tue Jan 13 05:56:04 2009
From: Christian.Sayer at dibcom.fr (Christian Sayer)
Date: Tue, 13 Jan 2009 12:56:04 +0100
Subject: [LLVMdev] implicit CC register Defs cause "physreg was not
 killed in defining block!" assert
In-Reply-To: <57C38DA176A0A34A9B9F3CCCE33D3C4AE9D9D38100@FRPAR1CL009.coe.adi.dibcom.com>
References: <57C38DA176A0A34A9B9F3CCCE33D3C4AE9D9D380FD@FRPAR1CL009.coe.adi.dibcom.com>
	<0F0A96F8-B4D0-4D2E-9187-A2988B32C38A@apple.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AE9D9D38100@FRPAR1CL009.coe.adi.dibcom.com>
Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4AE9D9D38101@FRPAR1CL009.coe.adi.dibcom.com>

Hi,

I was a little confused by all the passes I went through last time.
LiveVariables *is* actually being run before and after PNE (of course,
because it crashed in the second run...)

The problem was that the CCFLAGS register was not marked
non-allocatable. AFAICS this is also the case in the X86 backend, which
I took as model, although it does not make problems there - but maybe
it should not be anyway?

>The instructions containing the CCFLAGS which are not marked dead
>in the dump below (line 3+) are reg-to-reg copies inserted by
>the PHI elimination.
>In my backend, a mov instruction is currently implemented as
>an add with
>constant 0 (affecting condition codes).
>Now LiveVariables gets executed before PHI elimination, so I am trying
>to figure out if there is code in PNE which is supposed to update the
>defs. Otherwise I might try to re-run LiveVariables after PNE, or
>some similiar approach combining these two passes - unless you tell
>me they don't get marked dead because of an implementation flaw in my
>backend
...which turned out to be the correct assumption ; )

Regards,
Christian





--





sorry about that, but there is nothing I can do about it:

CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you.


From gafunchal at gmail.com  Tue Jan 13 06:03:31 2009
From: gafunchal at gmail.com (Giovanni Funchal)
Date: Tue, 13 Jan 2009 13:03:31 +0100
Subject: [LLVMdev] llvm.memory.barrier
Message-ID: <c475e2e60901130403h26001c5cm296c1ba853251140@mail.gmail.com>

Can you please clarify the meaning of:

llvm.memory.barrier(i1 false, i1 false, i1 false, i1 false, i1 false)

Does it behave as:

__asm__ __volatile__ ("":::"memory");

Note: for gcc, this empty inline assembly behaves as a compiler
barrier which prevents optimizations across it, but it does not ensure
anything on CPU reordering ("volatile" prevents it from being
reordered *by the compiler* and "memory" in the clobber list prevents
caching memory values in registers).

I'm not totally sure this is good practice, but this "compiler only"
barrier is used in low level code (drivers, threading libraries and
the linux kernel for instance) to prevent loops from being optimized
away in spinlocks, but also sometimes to force reloading values from
memory.

A strongly related question:

%result1 = load i32* %ptr
call void @llvm.memory.barrier(i1 true, i1 false, i1 false, i1 false, i1 false)
%result2 = load i32* %ptr

Can the code above be optimized (fusion of %result1,2) given an
architecture in which that memory barrier is not needed ?

The LLVM Language Reference states that, in architectures that do not
need some types of barrier, these become "noops" and, as far as I
know, nothing can be assumed about reordering and optimization of
noops.

All kinds of memory barrier should imply a compiler barrier in the
sense that I mentioned above, or at least this seems more logical to
me.

Thanks,
-- Giovanni

From romix.llvm at googlemail.com  Tue Jan 13 06:46:30 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Tue, 13 Jan 2009 13:46:30 +0100
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <e50173bd0901130238ic28dae8l24071597555427c0@mail.gmail.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
	<02AF6D36-5ABC-45F9-830D-E970760DC768@apple.com>
	<e50173bd0901130027x76a831dew5a23a2128d23703@mail.gmail.com>
	<62E18334-B36C-41BF-8CA8-7F86448E9632@apple.com>
	<e50173bd0901130238ic28dae8l24071597555427c0@mail.gmail.com>
Message-ID: <e50173bd0901130446k20be8b7ax112053acc176afa5@mail.gmail.com>

Hi Evan,

OK, I got it. Your advice about LiveIn regs saved my day! Now ARM
failures are in the past.

Thanks a lot!
-Roman


2009/1/13 Roman Levenstein <romix.llvm at googlemail.com>:
> Hi again,
>
> 2009/1/13 Evan Cheng <evan.cheng at apple.com>:
>>
>>
>> On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com>
>> wrote:
>>
>>> 2009/1/13 Evan Cheng <echeng at apple.com>:
>>>>
>>>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>>>
>>>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>>>>  Predecessors according to CFG: 0x8fdac90 (#0)
>>>>>     %R0<def> = MOVi 0, 14, %reg0, %reg0
>>>>> ***     STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>>>>> [0x8fc2d68 + 0]
>>>>>     %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>>>>>     %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>>>>>     BX_RET 14, %reg0
>>>>
>>>> Ok, ignore my earlier email about BX_RET. The issue is LR should be added
>>>> to
>>>> livein of BB #1.
>>>
>>> Who should do it?
>>> Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables
>>> should do it or do you mean that my regalloc should do it?
>>
>> Register allocator should update mbb Livein info.
>
> OK.
>
>>>
>>>
>>>> **** Post Machine Instrs ****
>>>> # Machine code for Insert():
>>>> Live Ins: R0 in VR#1025  R1 in VR#1026
>>>>
>>>> entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0:
>>>> Live Ins: %R0 %R1
>>>>     %LR<def> = MOVr %R0, 14, %reg0, %reg0
>>>>     CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def>
>>>>     Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill>
>>>>  Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2)
>>>>
>>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>>>  Predecessors according to CFG: 0x8fdac90 (#0)
>>>>     %R0<def> = MOVi 0, 14, %reg0, %reg0
>>>>     STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>>>> [0x8fc2d68 + 0]
>>>>     BX_RET 14, %reg0
>>>>
>>>> Here the STR is using LR, but there isn't a def earlier.
>>>
>>> May be I overlook something, but doesn't
>>> %LR<def> = MOVr %R0, 14, %reg0, %reg0
>>> in MBB#0 define the LR? It should be enough, or?
>>
>> Every machine basic block must list physical register livein's.
>
> One question, just to be sure I understand you correctly. You mean
> that after the RegAlloc has assigned physical registers to
> LiveIntervals and before it calls the VRM to rewrite the function, it
> should explicitly add lives-ins for each MBB, just like LinearScan
> does it at the end of the RALinScan::linearScan() function???
>
> E.g. like this:
>
>  // Add live-ins to every BB except for entry. Also perform trivial coalescing.
>  MachineFunction::iterator EntryMBB = mf_->begin();
>  SmallVector<MachineBasicBlock*, 8> LiveInMBBs;
>  for (LiveIntervals::iterator i = li_->begin(), e = li_->end(); i != e; ++i) {
>    LiveInterval &cur = *i->second;
>    unsigned Reg = 0;
>    bool isPhys = TargetRegisterInfo::isPhysicalRegister(cur.reg);
>    if (isPhys)
>      Reg = cur.reg;
>    else if (vrm_->isAssignedReg(cur.reg))
>      Reg = attemptTrivialCoalescing(cur, vrm_->getPhys(cur.reg));
>    if (!Reg)
>      continue;
>    // Ignore splited live intervals.
>    if (!isPhys && vrm_->getPreSplitReg(cur.reg))
>      continue;
>    for (LiveInterval::Ranges::const_iterator I = cur.begin(), E = cur.end();
>         I != E; ++I) {
>      const LiveRange &LR = *I;
>      if (li_->findLiveInMBBs(LR.start, LR.end, LiveInMBBs)) {
>        for (unsigned i = 0, e = LiveInMBBs.size(); i != e; ++i)
>          if (LiveInMBBs[i] != EntryMBB)
>            LiveInMBBs[i]->addLiveIn(Reg);
>        LiveInMBBs.clear();
>      }
>    }
>  }
>
> If it is the case, it is OK. It was not clear for me that one has to
> do it in the regalloc. My assumption was that VRM would do it.
>
> Thanks a lot,
>  Roman
>

From romix.llvm at googlemail.com  Tue Jan 13 07:05:23 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Tue, 13 Jan 2009 14:05:23 +0100
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
	target)?
Message-ID: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>

Hi again,

Now, after I fixed the graph coloring regalloc bug that was triggered
by the ARM target, I continue testing and found another bug, this time
on the XCore target. First I thought that it is again specific to my
register allocator, but it seems to be trigerred also by LLVM's
linearscan register allocator.

I don't know if the XCore target is stable enough in LLVM, or may be I
should just safely skip it during testing because it is not mature
yet. Anyway, I report it here - may be it is of some interest.

The crash happens in LiveIntervalsAnalysis, inside the spilling
function. From what I observe, I'd say it is related to
rematerializable intervals.

The assertion says:
/opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142:
llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int):
Assertion `I != r2iMap_.end() && "Interval does not exist for
register"' failed.

I attach the BC file generated by bugpoint, so that you can reproduce it.

The command-line I use is:
llc --regalloc=linearscan --march=xcore  -f bugpoint-reduced-simplified.bc

Any ideas about the reasons of this bug?

Thanks,
  -Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugpoint-reduced-simplified.bc
Type: application/octet-stream
Size: 524 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090113/40f21f5a/attachment.obj 

From baldrick at free.fr  Tue Jan 13 07:55:06 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 13 Jan 2009 14:55:06 +0100
Subject: [LLVMdev] LLVM optmization
In-Reply-To: <20090107105605.27816.qmail@hm885.locaweb.com.br>
References: <20090107105605.27816.qmail@hm885.locaweb.com.br>
Message-ID: <200901131455.06352.baldrick@free.fr>

Hi Manoel,

> The following C test program was  compiled using LLVM with -O3 option  and MSVC with /O2.
> The MSVC one is about 600 times faster than the one compiled with the LLVM.
> We can see that the for loop in MSVC assembler is solved in the optimization pass more efficiently than that in LLVM.
> Is there an way to get a optimization result in LLVM like that of the MSVC?

can you please provide a testcase that doesn't need windows.
I don't think many people around here have windows...

Ciao,

Duncan.

From jcriswel at bigw.org  Tue Jan 13 08:16:21 2009
From: jcriswel at bigw.org (John Criswell)
Date: Tue, 13 Jan 2009 08:16:21 -0600
Subject: [LLVMdev] [Fwd: Re:  insertAfter method Patch]
Message-ID: <496CA235.30201@bigw.org>

Dear All,

Should this patch be committed now?  I just did a quick read-over of it 
when it was first submitted.

-- John T.

-------------- next part --------------
An embedded message was scrubbed...
From: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU>
Subject: Re: [LLVMdev] insertAfter method Patch
Date: Mon, 12 Jan 2009 15:58:34 -0500 (EST)
Size: 4813
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090113/9fc69d11/attachment.eml 

From abh.spark at gmail.com  Tue Jan 13 11:21:53 2009
From: abh.spark at gmail.com (abhishek Singh)
Date: Tue, 13 Jan 2009 22:51:53 +0530
Subject: [LLVMdev] adding a new member to basic block class
Message-ID: <6ac719070901130921x1ef9f6c4w176cd3fa0d8fe19a@mail.gmail.com>

Hi all,i am writing a llvm pass and want to add an extra member to basic
block class.
can i do it by changing class definition in basicblock.h??
do i need to recompile complete llvm after changing this class??

thanks alot,
Abhishek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090113/5cd918d3/attachment.html 

From echeng at apple.com  Tue Jan 13 11:27:43 2009
From: echeng at apple.com (Evan Cheng)
Date: Tue, 13 Jan 2009 09:27:43 -0800
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
	target)?
In-Reply-To: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>
References: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>
Message-ID: <4B61743B-58F1-4888-9420-FC7D79228AF6@apple.com>

Please file a bug report. I'll look at it when I find the time.

Evan

On Jan 13, 2009, at 5:05 AM, Roman Levenstein wrote:

> Hi again,
>
> Now, after I fixed the graph coloring regalloc bug that was triggered
> by the ARM target, I continue testing and found another bug, this time
> on the XCore target. First I thought that it is again specific to my
> register allocator, but it seems to be trigerred also by LLVM's
> linearscan register allocator.
>
> I don't know if the XCore target is stable enough in LLVM, or may be I
> should just safely skip it during testing because it is not mature
> yet. Anyway, I report it here - may be it is of some interest.
>
> The crash happens in LiveIntervalsAnalysis, inside the spilling
> function. From what I observe, I'd say it is related to
> rematerializable intervals.
>
> The assertion says:
> /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142:
> llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int):
> Assertion `I != r2iMap_.end() && "Interval does not exist for
> register"' failed.
>
> I attach the BC file generated by bugpoint, so that you can  
> reproduce it.
>
> The command-line I use is:
> llc --regalloc=linearscan --march=xcore  -f bugpoint-reduced- 
> simplified.bc
>
> Any ideas about the reasons of this bug?
>
> Thanks,
>  -Roman
> <bugpoint-reduced-simplified.bc>


From mdevan.foobar at gmail.com  Tue Jan 13 11:30:49 2009
From: mdevan.foobar at gmail.com (Mahadevan R)
Date: Tue, 13 Jan 2009 23:00:49 +0530
Subject: [LLVMdev] ParseError::getMessage() API.
Message-ID: <c8033d570901130930ia41bda4mc01eda49253903a9@mail.gmail.com>

Hi,

The method ParseError::getMessage() seems to have got deleted from
lib/AsmParser/Parser.cpp during the parser rewrite. Right now it's
there in the header (include/llvm/Assembly/Parser.h) but not in
lib/AsmParser/Parser.cpp.

Is this API still valid? Or is it PrintError() that's meant to be used?

Thanks & Regards,
-Mahadevan.

From echeng at apple.com  Tue Jan 13 11:30:52 2009
From: echeng at apple.com (Evan Cheng)
Date: Tue, 13 Jan 2009 09:30:52 -0800
Subject: [LLVMdev] Possible bug in the ARM backend?
In-Reply-To: <e50173bd0901130238ic28dae8l24071597555427c0@mail.gmail.com>
References: <e50173bd0901070248t10dbd866tf6db7c41db7efd35@mail.gmail.com>
	<02AF6D36-5ABC-45F9-830D-E970760DC768@apple.com>
	<e50173bd0901130027x76a831dew5a23a2128d23703@mail.gmail.com>
	<62E18334-B36C-41BF-8CA8-7F86448E9632@apple.com>
	<e50173bd0901130238ic28dae8l24071597555427c0@mail.gmail.com>
Message-ID: <EA86507B-6BBD-4B2D-97FF-F329F93459B6@apple.com>


On Jan 13, 2009, at 2:38 AM, Roman Levenstein wrote:

> Hi again,
>
> 2009/1/13 Evan Cheng <evan.cheng at apple.com>:
>>
>>
>> On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com 
>> >
>> wrote:
>>
>>> 2009/1/13 Evan Cheng <echeng at apple.com>:
>>>>
>>>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>>>
>>>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>>>> Predecessors according to CFG: 0x8fdac90 (#0)
>>>>>    %R0<def> = MOVi 0, 14, %reg0, %reg0
>>>>> ***     STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>>>>> [0x8fc2d68 + 0]
>>>>>    %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>>>>>    %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>>>>>    BX_RET 14, %reg0
>>>>
>>>> Ok, ignore my earlier email about BX_RET. The issue is LR should  
>>>> be added
>>>> to
>>>> livein of BB #1.
>>>
>>> Who should do it?
>>> Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables
>>> should do it or do you mean that my regalloc should do it?
>>
>> Register allocator should update mbb Livein info.
>
> OK.
>
>>>
>>>
>>>> **** Post Machine Instrs ****
>>>> # Machine code for Insert():
>>>> Live Ins: R0 in VR#1025  R1 in VR#1026
>>>>
>>>> entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0:
>>>> Live Ins: %R0 %R1
>>>>    %LR<def> = MOVr %R0, 14, %reg0, %reg0
>>>>    CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def>
>>>>    Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill>
>>>> Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2)
>>>>
>>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>>> Predecessors according to CFG: 0x8fdac90 (#0)
>>>>    %R0<def> = MOVi 0, 14, %reg0, %reg0
>>>>    STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>>>> [0x8fc2d68 + 0]
>>>>    BX_RET 14, %reg0
>>>>
>>>> Here the STR is using LR, but there isn't a def earlier.
>>>
>>> May be I overlook something, but doesn't
>>> %LR<def> = MOVr %R0, 14, %reg0, %reg0
>>> in MBB#0 define the LR? It should be enough, or?
>>
>> Every machine basic block must list physical register livein's.
>
> One question, just to be sure I understand you correctly. You mean
> that after the RegAlloc has assigned physical registers to
> LiveIntervals and before it calls the VRM to rewrite the function, it
> should explicitly add lives-ins for each MBB, just like LinearScan
> does it at the end of the RALinScan::linearScan() function???
>
> E.g. like this:
>
>  // Add live-ins to every BB except for entry. Also perform trivial  
> coalescing.
>  MachineFunction::iterator EntryMBB = mf_->begin();
>  SmallVector<MachineBasicBlock*, 8> LiveInMBBs;
>  for (LiveIntervals::iterator i = li_->begin(), e = li_->end(); i !=  
> e; ++i) {
>    LiveInterval &cur = *i->second;
>    unsigned Reg = 0;
>    bool isPhys = TargetRegisterInfo::isPhysicalRegister(cur.reg);
>    if (isPhys)
>      Reg = cur.reg;
>    else if (vrm_->isAssignedReg(cur.reg))
>      Reg = attemptTrivialCoalescing(cur, vrm_->getPhys(cur.reg));
>    if (!Reg)
>      continue;
>    // Ignore splited live intervals.
>    if (!isPhys && vrm_->getPreSplitReg(cur.reg))
>      continue;
>    for (LiveInterval::Ranges::const_iterator I = cur.begin(), E =  
> cur.end();
>         I != E; ++I) {
>      const LiveRange &LR = *I;
>      if (li_->findLiveInMBBs(LR.start, LR.end, LiveInMBBs)) {
>        for (unsigned i = 0, e = LiveInMBBs.size(); i != e; ++i)
>          if (LiveInMBBs[i] != EntryMBB)
>            LiveInMBBs[i]->addLiveIn(Reg);
>        LiveInMBBs.clear();
>      }
>    }
>  }

Only the last part.

>
>
> If it is the case, it is OK. It was not clear for me that one has to
> do it in the regalloc. My assumption was that VRM would do it.

One day I'd like to factor out the code to do it with an analysis  
pass. But unfortunately it's done by the allocators for now. It might  
be ok to move it to VRM. If you want to make that change I am ok with  
it.

Evan
>
>
> Thanks a lot,
>  Roman


From e.ge at gmx.net  Tue Jan 13 12:39:02 2009
From: e.ge at gmx.net (Edgar Geisler)
Date: Tue, 13 Jan 2009 19:39:02 +0100
Subject: [LLVMdev] IR code generation and JIT execution in a multithread
	environment
In-Reply-To: <D50AD1A4-74EB-47AF-8558-EFDF2F185961@me.com>
References: <000c01c974d0$49271f10$db755d30$%ge@gmx.net>
	<D50AD1A4-74EB-47AF-8558-EFDF2F185961@me.com>
Message-ID: <004e01c975ae$391c3900$ab54ab00$@ge@gmx.net>

Hi Gordon,

> Module and Value are unsafe for concurrent access--even disjoint
> instances thereof. So you'll need to hold a global mutex while
> loading, building, or transforming IR. 

>From my (limited) point of view it would be nice to have some
fine grained lock mechanisms for IR/JIT generation. AFAIK the
critical sections during IR (Module) generation are the alteration 
or access to the static/global Type-/ValueMaps. Wouldn't it be
sufficient to protect them by some kind of 'null'-mutex and leaving the
implemtation to the particular project?

> I think serializing code generation in a JIT will usually be adequate,
> since presumably the compiled program (rather than the compiler)
> should dominate runtime. However, if your project truly needs
> concurrent JIT compilation, LLVM doesn't yet meet your needs. 

I am using LLVM as a kind of glue between a controlling process (exe) and 
some services (lib). Within my mentioned scenario IR/JIT generation
dominates 
runtime with an average factor of 5-10. Simply speaking, executing a
service needs ~ 10 ms while IR/JIT generation for this service needs 
~ 40 - 100 ms on the average. So, if the controller gets a bulk
of service requests, it can be expected that the requests will be lined up
at a global Module generator or at the global JIT generator mutex. 

Edgar


From richard at xmos.com  Tue Jan 13 13:20:01 2009
From: richard at xmos.com (Richard Osborne)
Date: Tue, 13 Jan 2009 19:20:01 +0000
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
 target)?
In-Reply-To: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>
References: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>
Message-ID: <496CE961.2030003@xmos.com>

Roman Levenstein wrote:
> Hi again,
>
> Now, after I fixed the graph coloring regalloc bug that was triggered
> by the ARM target, I continue testing and found another bug, this time
> on the XCore target. First I thought that it is again specific to my
> register allocator, but it seems to be trigerred also by LLVM's
> linearscan register allocator.
>
> I don't know if the XCore target is stable enough in LLVM, or may be I
> should just safely skip it during testing because it is not mature
> yet. Anyway, I report it here - may be it is of some interest.
>
> The crash happens in LiveIntervalsAnalysis, inside the spilling
> function. From what I observe, I'd say it is related to
> rematerializable intervals.
>
> The assertion says:
> /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142:
> llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int):
> Assertion `I != r2iMap_.end() && "Interval does not exist for
> register"' failed.
>
> I attach the BC file generated by bugpoint, so that you can reproduce it.
>
> The command-line I use is:
> llc --regalloc=linearscan --march=xcore  -f bugpoint-reduced-simplified.bc
>
> Any ideas about the reasons of this bug?
>
> Thanks,
>   -Roman
It looks like it is trying to rematerialize a load from fixed stack slot 
(LDWSP instruction). This has an implicit use of the SP register which 
is non allocatable.

rewriteInstructionsForSpills calls getReMatImplicitUse which returns the 
SP register. This is then followed by a call to getInterval for this 
register which fails. The attached patch causes getReMatImplicitUse to 
ignore non allocatable physical registers, which fixes the issue for me. 
Does this look OK?

-- 
Richard Osborne | XMOS
http://www.xmos.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.patch
Type: text/x-patch
Size: 613 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090113/d7bee43f/attachment.bin 

From isanbard at gmail.com  Tue Jan 13 14:06:43 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 13 Jan 2009 12:06:43 -0800
Subject: [LLVMdev] adding a new member to basic block class
In-Reply-To: <6ac719070901130921x1ef9f6c4w176cd3fa0d8fe19a@mail.gmail.com>
References: <6ac719070901130921x1ef9f6c4w176cd3fa0d8fe19a@mail.gmail.com>
Message-ID: <16e5fdf90901131206t8a77e4dm1a6442da4d936df3@mail.gmail.com>

On Tue, Jan 13, 2009 at 9:21 AM, abhishek Singh <abh.spark at gmail.com> wrote:
> Hi all,
> i am writing a llvm pass and want to add an extra member to basic block
> class.
> can i do it by changing class definition in basicblock.h??
> do i need to recompile complete llvm after changing this class??
>
Yes to both questions. But you should ask yourself 'why' and whether
there's another way that could be done.

-bw

From duncan at duncanpierce.org  Tue Jan 13 15:50:46 2009
From: duncan at duncanpierce.org (Duncan Pierce)
Date: Tue, 13 Jan 2009 21:50:46 +0000
Subject: [LLVMdev] Build problems on MinGW
Message-ID: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>

Hello everyone,

I'm struggling to get a working LLVM installation on MinGW on Windows
Vista. I have the following packages:

* LLVM 2.4
* Gnu make 3.81
* GCC 3.4.5 (mingw-vista special r3)
* Perl 5.6.1
* Texinfo 4.11
* LD (which I took to be representative of Binutils version) 2.17.50 20060824

None of these are marked "bad" in your compatibility matrix, but not
many of them are marked "good" either.

During build I get lots of missing symbol errors from LD. Near the end
it goes through a monster link step that spews many screenfuls of link
errors. Here's an example from near the end:

c:/mingw/src/llvm-2.4/Release/lib/libLLVMBitWriter.a(ValueEnumerator.o):ValueEnumerator.cpp:(.text$_ZNSt6vectorIN4llvm11
AttrListPtrESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_[std::vector<llvm::AttrListPtr,
std::al
locator<llvm::AttrListPtr>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::AttrListPtr*,
std::vector<llvm::AttrListP
tr, std::allocator<llvm::AttrListPtr> > >, llvm::AttrListPtr
const&)]+0x1b5): undefined reference to `llvm::AttrListPtr:
:AttrListPtr(llvm::AttrListPtr const&)'
collect2: ld returned 1 exit status

I'm not concerned with working on LLVM itself - I just want to use it,
so if there's an alternative way to get a working system on Windows
I'm open to suggestions.

Thanks for your help,
Duncan Pierce

From anton at korobeynikov.info  Tue Jan 13 16:41:42 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 14 Jan 2009 01:41:42 +0300
Subject: [LLVMdev] Build problems on MinGW
In-Reply-To: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
Message-ID: <F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>

Hello, Duncan

> * LD (which I took to be representative of Binutils version) 2.17.50  
> 20060824
> None of these are marked "bad" in your compatibility matrix, but not
> many of them are marked "good" either.
>
> During build I get lots of missing symbol errors from LD. Near the end
> it goes through a monster link step that spews many screenfuls of link
> errors. Here's an example from near the end:
Smells like binutils problem. In the past I filled 2 or 3 binutils  
bugs as a result of LLVM compilation on mingw (all of them were fixed,  
but I don't recall the specific versions of binutils, unfortunately).

Why you're using such old binutils? 2.18.50-20080109 definitely worked  
for me (and release binaries were built so...).

---
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090114/6d58fd2f/attachment.html 

From tonic at nondot.org  Tue Jan 13 17:34:04 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Tue, 13 Jan 2009 15:34:04 -0800 (PST)
Subject: [LLVMdev] LLVM 2.5 Code Freeze 1/21/09
Message-ID: <Pine.LNX.4.62.0901131530090.2083@nondot.org>


This is a reminder that the LLVM 2.5 code freeze is on 1/21/09 9PM PST 
(just a week away). As a courtesy, please do not check in major changes 
too close to the code freeze date.

Thanks,
Tanya Lattner

From evan.cheng at apple.com  Wed Jan 14 03:14:42 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Wed, 14 Jan 2009 01:14:42 -0800
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
 target)?
In-Reply-To: <496CE961.2030003@xmos.com>
References: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>
	<496CE961.2030003@xmos.com>
Message-ID: <7F82EBB1-40B8-4081-B2EE-0F23A9FFFB1D@apple.com>



On Jan 13, 2009, at 11:20 AM, Richard Osborne <richard at xmos.com> wrote:

> Roman Levenstein wrote:
>> Hi again,
>>
>> Now, after I fixed the graph coloring regalloc bug that was triggered
>> by the ARM target, I continue testing and found another bug, this  
>> time
>> on the XCore target. First I thought that it is again specific to my
>> register allocator, but it seems to be trigerred also by LLVM's
>> linearscan register allocator.
>>
>> I don't know if the XCore target is stable enough in LLVM, or may  
>> be I
>> should just safely skip it during testing because it is not mature
>> yet. Anyway, I report it here - may be it is of some interest.
>>
>> The crash happens in LiveIntervalsAnalysis, inside the spilling
>> function. From what I observe, I'd say it is related to
>> rematerializable intervals.
>>
>> The assertion says:
>> /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142:
>> llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int):
>> Assertion `I != r2iMap_.end() && "Interval does not exist for
>> register"' failed.
>>
>> I attach the BC file generated by bugpoint, so that you can  
>> reproduce it.
>>
>> The command-line I use is:
>> llc --regalloc=linearscan --march=xcore  -f bugpoint-reduced- 
>> simplified.bc
>>
>> Any ideas about the reasons of this bug?
>>
>> Thanks,
>>  -Roman
> It looks like it is trying to rematerialize a load from fixed stack  
> slot (LDWSP instruction). This has an implicit use of the SP  
> register which is non allocatable.
>
> rewriteInstructionsForSpills calls getReMatImplicitUse which returns  
> the SP register. This is then followed by a call to getInterval for  
> this register which fails. The attached patch causes  
> getReMatImplicitUse to ignore non allocatable physical registers,  
> which fixes the issue for me. Does this look OK?

This patch assumes non allocatable registers are available at any  
point. I don't think that's a safe. Can you change LDWSP so it doesn't  
implicitly use sp? Once the frame index object is lowered by PEI, it  
can be rewritten to explicitly use sp. Would that work?

Evan

>
>
> -- 
> Richard Osborne | XMOS
> http://www.xmos.com
>
>
> Index: lib/CodeGen/LiveIntervalAnalysis.cpp  
> ===================================================================  
> --- lib/CodeGen/LiveIntervalAnalysis.cpp	(revision 60478) +++ lib/ 
> CodeGen/LiveIntervalAnalysis.cpp	(working copy) @@ -820,6 +820,9 @@  
> unsigned Reg = MO.getReg(); if (Reg == 0 || Reg == li.reg) continue;  
> + if (TargetRegisterInfo::isPhysicalRegister(Reg) && + ! 
> allocatableRegs_[Reg]) + continue; // FIXME: For now, only remat MI  
> with at most one register operand. assert(!RegOp && "Can't  
> rematerialize instruction with multiple register operand!");
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From baldrick at free.fr  Wed Jan 14 03:31:52 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 14 Jan 2009 10:31:52 +0100
Subject: [LLVMdev] LLVM optmization
In-Reply-To: <20090113150810.22886.qmail@hm885.locaweb.com.br>
References: <200901131455.06352.baldrick@free.fr>
	<20090113150810.22886.qmail@hm885.locaweb.com.br>
Message-ID: <200901141031.53062.baldrick@free.fr>

Hi Manoel,

>  Hi, Duncan.
> 
>  Here an example :
> #include <stdio.h>
> #include <stdlib.h>
> //
> int  TESTE ( int  parami ,int  paraml   ) 
> {
>   int varx=0;
>   int nI =0;
>   
>   if( parami  > 0 )
>   {
>     varx = parami;
>   }
>   else
>   {
>     varx = 1;
>    }
>   
>   for( nI = 1 ;   nI <=  paraml; nI++)
>   {
>     varx =  varx +  parami+ 1;
>   }
> 
> return varx ;
> }
> 
> int main(int argc, char **argv)
> {
>    if( argc < 3 )
>      return 0;
>    return TESTE(atoi(argv[1]),atoi(argv[2]));
> }
> 
>  I don't know how gcc4 resolves the for loop, but the MSVC is great in this example.

gcc-4.3 also eliminates the loop entirely and directly calculates the value of varx.

>  If I change the paraml  and put a constant, the LLVM optmizes very well.

It looks like LLVM's scalar evolution code isn't handling your testcase well.

Ciao,

Duncan.

From richard at xmos.com  Wed Jan 14 05:14:35 2009
From: richard at xmos.com (Richard Osborne)
Date: Wed, 14 Jan 2009 11:14:35 +0000
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
 target)?
In-Reply-To: <7F82EBB1-40B8-4081-B2EE-0F23A9FFFB1D@apple.com>
References: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>	<496CE961.2030003@xmos.com>
	<7F82EBB1-40B8-4081-B2EE-0F23A9FFFB1D@apple.com>
Message-ID: <496DC91B.2060604@xmos.com>

Evan Cheng wrote:
> On Jan 13, 2009, at 11:20 AM, Richard Osborne <richard at xmos.com> wrote:
>
>   
>> Roman Levenstein wrote:
>>     
>>> Hi again,
>>>
>>> Now, after I fixed the graph coloring regalloc bug that was triggered
>>> by the ARM target, I continue testing and found another bug, this  
>>> time
>>> on the XCore target. First I thought that it is again specific to my
>>> register allocator, but it seems to be trigerred also by LLVM's
>>> linearscan register allocator.
>>>
>>> I don't know if the XCore target is stable enough in LLVM, or may  
>>> be I
>>> should just safely skip it during testing because it is not mature
>>> yet. Anyway, I report it here - may be it is of some interest.
>>>
>>> The crash happens in LiveIntervalsAnalysis, inside the spilling
>>> function. From what I observe, I'd say it is related to
>>> rematerializable intervals.
>>>
>>> The assertion says:
>>> /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142:
>>> llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int):
>>> Assertion `I != r2iMap_.end() && "Interval does not exist for
>>> register"' failed.
>>>
>>> I attach the BC file generated by bugpoint, so that you can  
>>> reproduce it.
>>>
>>> The command-line I use is:
>>> llc --regalloc=linearscan --march=xcore  -f bugpoint-reduced- 
>>> simplified.bc
>>>
>>> Any ideas about the reasons of this bug?
>>>
>>> Thanks,
>>>  -Roman
>>>       
>> It looks like it is trying to rematerialize a load from fixed stack  
>> slot (LDWSP instruction). This has an implicit use of the SP  
>> register which is non allocatable.
>>
>> rewriteInstructionsForSpills calls getReMatImplicitUse which returns  
>> the SP register. This is then followed by a call to getInterval for  
>> this register which fails. The attached patch causes  
>> getReMatImplicitUse to ignore non allocatable physical registers,  
>> which fixes the issue for me. Does this look OK?
>>     
>
> This patch assumes non allocatable registers are available at any  
> point. I don't think that's a safe. Can you change LDWSP so it doesn't  
> implicitly use sp? Once the frame index object is lowered by PEI, it  
> can be rewritten to explicitly use sp. Would that work?
>
> Evan
OK, that make sense, I'll take a look at changing this. I've added a bug 
for the issue:

http://llvm.org/bugs/show_bug.cgi?id=3324

There is currently no Backend: XCore component in bugzilla so I've put 
it under new-bugs. Could someone add this component for me.

Thanks

-- 
Richard Osborne | XMOS
http://www.xmos.com



From syoyofujita at gmail.com  Wed Jan 14 07:11:53 2009
From: syoyofujita at gmail.com (Syoyo Fujita)
Date: Wed, 14 Jan 2009 22:11:53 +0900
Subject: [LLVMdev] Loop elimination with floating point counter.
In-Reply-To: <4aca3dc20901082011u74266dc2mf88e3490a6145e01@mail.gmail.com>
References: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
	<C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>
	<1f06970b0901080922k1e80e4b6ree7239a9ff4c427e@mail.gmail.com>
	<5296F463-E937-4774-A4DE-26858DA14942@mac.com>
	<759EC041-923A-4F12-9833-26EE246DF42F@gmx.net>
	<92381DB0-F6B9-4AD8-8242-7F03B280C132@mac.com>
	<4aca3dc20901082011u74266dc2mf88e3490a6145e01@mail.gmail.com>
Message-ID: <1f06970b0901140511ufea2358u92f458c9d252282@mail.gmail.com>

Thanks for many comments.

The loop with finite fp values(which could be representable in IEEE754
fp format) such like,

void
foo() {
    float i;

    for (i = 0.0f; i < 1000.0f; i += 1.2f) {
    }
}

could reach the end condition under any fp rounding mode,
and eliminating the loop has no side effects.
(for example, floating point control register does not change because
the increment does not cause the overflow)

Thus I believe the loop as shown above could be removed safely.


FYI, gcc -O3 turns fp loop counter into integer, but gcc does not
optimize further(eliminate the loop).

$ gcc -O3 floop.c

_foo:
	pushl	%ebp
	movl	$834, %eax
	movl	%esp, %ebp
	.align 4,0x90
L2:
	decl	%eax
	jne	L2

--
Syoyo

On Fri, Jan 9, 2009 at 1:11 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> FWIW, I believe icc -O3 turns on the equivalent of -ffast-math by default.
> I could be misremembering which compilers do this though :)
> This flag allows you to make all kinds of nice simplfiying assumptions
> about floating point.
>
> On Thu, Jan 8, 2009 at 7:45 PM, Owen Anderson <resistor at mac.com> wrote:
>> I assume it checks that the end condition and the increment can both
>> be represented precisely with integer types.
>>
>> --Owen
>>
>> On Jan 8, 2009, at 9:49 AM, Martin Geisse wrote:
>>
>>> Isn't "simplifying" the loop index to an integer also dependent on
>>> precision issues? The following loop is infinite:
>>>
>>> for (float i=0.0; i<...; i+=1.0) {}
>>>
>>> where ... is a large "integral" float literal, e.g. 2^40. At some
>>> point, adding 1.0 to the loop index would not cause any changes
>>> because of precision issues. However, if the float type is replaced
>>> by some sufficiently large integer type, the loop terminates.
>>>
>>> The necessary reasoning may be simpler though.
>>>
>>> Greetings,
>>> Martin Geisse
>>>
>>> On Jan 8, 2009, at 6:34 PM, Owen Anderson wrote:
>>>
>>>> It's because with 1.0f, the loop index is simplified into an integer.
>>>> With 1.2f, it isn't.  The loop deletion pass is dependent on the loop
>>>> analyses being able to determine that the loop is finite, which they
>>>> don't attempt to do for loops with floating point indices.
>>>> Attempting
>>>> to do so would require additional reasoning about floating point
>>>> precision issues.
>>>>
>>>> --Owen
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From alex.lavoro.propio at gmail.com  Wed Jan 14 07:58:17 2009
From: alex.lavoro.propio at gmail.com (Alex)
Date: Wed, 14 Jan 2009 14:58:17 +0100
Subject: [LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)
Message-ID: <4d77c5f20901140558v7332be81j8f7a90fb67183a39@mail.gmail.com>

It seems that it's not allowed to two same 'ComplexPattern's  in a 'def',
because TableGen generate the same variable names for the two ComplexPatterns.
If I understand the source code of TableGen correctly, it's not designed to
use more than one ComplexPattern instance (no matter they are the same or not).

In the following example, two 'regsw' are used to match the operands of mul.

def regsw : Operand<v4i32>,
            ComplexPattern<v4i32, 2, "SelectRegsw", []> {
  let PrintMethod = "printSrcReg";
  let MIOperandInfo = (ops VR128, i8imm);
}

def MUL_1 : FooInst<(outs VR128:$dst),
                    (ins regsw:$src0, regsw:$src1),
                    "mul $dst, $src0, $src1",
                    [(set VR128:$dst, (mul regsw:$src0, regsw:$src1))]>;


The code generate by TableGen is:

SDNode *Select_ISD_MUL_v4i32(const SDValue &N) {
  SDValue N0 = N.getOperand(0);
  SDValue CPTmp0;
  SDValue CPTmp1;
  if (SelectRegsw(N, N0, CPTmp0, CPTmp1)) {
    SDValue N1 = N.getOperand(1);
    SDValue CPTmp0;
    SDValue CPTmp1;
    if (SelectRegsw(N, N1, CPTmp0, CPTmp1)) {
      return Emit_1(N, FooVS::MUL_1, MVT::v4i32, CPTmp0, CPTmp1);
    }
  }

From jonas.maebe at elis.ugent.be  Wed Jan 14 10:29:02 2009
From: jonas.maebe at elis.ugent.be (Jonas Maebe)
Date: Wed, 14 Jan 2009 17:29:02 +0100
Subject: [LLVMdev] malloc vs malloc
In-Reply-To: <FD6D8D10-03A6-41B3-AF03-7D2DECB95FB3@apple.com>
References: <200812231714.08173.jon@ffconsultancy.com>
	<A9C8E082-D996-4AED-903A-05C7376D0E20@apple.com>
	<4969ACAF.3090604@mxc.ca>
	<8E165ED9-864B-4C14-A1C7-F791292EADAD@apple.com>
	<404B7F2A-2BF7-4061-B2FB-796CA0746327@apple.com>
	<50EBB56E-E8BE-49C1-83CD-5B385005A523@apple.com>
	<496C0E58.6090705@mxc.ca>
	<FD6D8D10-03A6-41B3-AF03-7D2DECB95FB3@apple.com>
Message-ID: <5CB3FAD1-EB2A-4A8C-B640-E881A5AB08C2@elis.ugent.be>


On 13 Jan 2009, at 05:29, Chris Lattner wrote:

> 1) in practice, IMO, everyone building for user space has libc in
> their address space, even if they are supporting some non-C language
> like haskell or ocaml or something.

This is not true at least for the Free Pascal Compiler on non-Mac OS X  
and non-Solaris platforms. Normally, we directly use syscalls and link  
to nothing system-installed. The reason for this approach is that on  
e.g. Linux and FreeBSD, it almost guarantees spotless binary  
compatibility across different versions and/or distributions (while  
depending on any system library whatsoever almost guarantees absence  
of binary compatibility over time in most situations).

On the other hand, since we uppercase and mangle all of our assembler- 
level identifiers by default, it is unlikely that an identifier named  
"free" will actually exist. But it's not impossible (anyone can define  
aliases for functions/variables using any name).

> 5) regardless of #1/2, we want to support things like -fno-builtin- 
> free someday.  -ffree-standing would also imply this sort of thing,  
> as would -no-builtins etc.


Yes, please!


Jonas

From romix.llvm at googlemail.com  Wed Jan 14 10:43:33 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Wed, 14 Jan 2009 17:43:33 +0100
Subject: [LLVMdev] FP problems in different backends?
Message-ID: <e50173bd0901140843k9885949o66f5dd02ca994100@mail.gmail.com>

Hi,

Here is yet another bug/miscompilation I've found while testing my
register allocator.

The compilation of the attached BC file fails on multiple backends, namely:
 ia64, mips, mipsel, alpha

The failures are different from backend to backend (wrong register
classes, wrong operand types, etc). Please, just try to compile using
the attached BC file. I guess, it is related to the FP support.

May be I'm testing in the wong way?
What I currently do is:
1) I compile the source file on my X86 machine, using the following options:
   llvm-gcc -O6 -c -emit-llvm -o obj/cf1.c.bc cf1.c

I get this disassembled ll file:
; ModuleID = 'cf1.c.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"
@fl = external global float             ; <float*> [#uses=1]
@a = weak global i32 0          ; <i32*> [#uses=1]

define void @mai() nounwind {
entry:
        %tmp = load float* @fl, align 4         ; <float> [#uses=1]
        %tmp1 = fcmp une float %tmp, 0.000000e+00               ; <i1> [#uses=1]
        br i1 %tmp1, label %bb, label %UnifiedReturnBlock

bb:             ; preds = %entry
        store i32 10, i32* @a, align 4
        ret void

UnifiedReturnBlock:             ; preds = %entry
        ret void
}


2) I generate code from the BC file using these e.g. options:
   llc --regalloc=linearscan -f cf1.c.bc -march=ia64

Could it be that llvm-gcc produces a target specific BC file and takes
e.g. target specific FP implementation and representation into
account? If so, how can I produce a correct BC file for a given
target, e.g. mips and afterwards test it?

I also attach a very simple original C source file.

Can someone confirm these failures? Any ideas about what is wrong with
this input file?

-Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cf1.c.bc
Type: application/octet-stream
Size: 524 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090114/e0814cff/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cf1.c
Type: application/octet-stream
Size: 103 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090114/e0814cff/attachment-0001.obj 

From romix.llvm at googlemail.com  Wed Jan 14 10:49:59 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Wed, 14 Jan 2009 17:49:59 +0100
Subject: [LLVMdev] ia64 target problems with ELF sections
Message-ID: <e50173bd0901140849r2269ecd4r21ab01644e1661d9@mail.gmail.com>

Hi,

Compilation of the the following very simple file crashes with
--march=ia64 on my x86 machine.

; ModuleID = 'bugpoint-reduced-simplified.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"
@x = weak global [8 x i32] zeroinitializer, align 32            ; <[8
x i32]*> [#uses=0]
@.str = internal constant [4 x i8] c"%c \00"            ; <[4 x i8]*> [#uses=0]
@rows = weak global [8 x i32] zeroinitializer, align 32         ; <[8
x i32]*> [#uses=0]
@up = weak global [15 x i32] zeroinitializer, align 32          ; <[15
x i32]*> [#uses=0]
@down = weak global [15 x i32] zeroinitializer, align 32
 ; <[15 x i32]*> [#uses=0]

declare i32 @print() nounwind

declare i32 @printf(i8*, ...) nounwind

declare i32 @putchar(i32)

declare i32 @queens(i32) nounwind

define i32 @main() nounwind {
entry:
        unreachable
}

I use this command to compile:
llc -f bugpoint-reduced-simplified.bc  --regalloc=linearscan --march=ia64

The assertion is:

llc: /opt/llvm/lib/Target/ELFTargetAsmInfo.cpp:133: const
llvm::Section* llvm::ELFTargetAsmInfo::MergeableStringSection(const
llvm::GlobalVariable*) const: Assertion `getCStringSection() &&
"Should have string section prefix"' failed.

Is it a bug in the ia64 backend?

Thanks,
 -Roman

P.S. BC file is attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugpoint-reduced-simplified.bc
Type: application/octet-stream
Size: 576 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090114/a921a9ff/attachment.obj 

From dag at cray.com  Wed Jan 14 11:37:30 2009
From: dag at cray.com (David Greene)
Date: Wed, 14 Jan 2009 11:37:30 -0600
Subject: [LLVMdev] Memory Dependence Analysis
Message-ID: <200901141137.30627.dag@cray.com>

Back in August, several of us participated in a discussion about getting a 
more robust memory dependence analysis framework into LLVM.  Wojtek
Matyjewicz has done some work on this and he attached a patch to an e-mail at 
the time that built against an older version of LLVM.

Wojtek, what's the status of this patch?  Does it build against HEAD?  Do you 
plan to check it in any time soon?

I've just run into a couple of situations where I need memory dependence 
information.  The memory dependence analysis in llvm 2.3 provides very 
conservative information but it would be nice to have something better.

We're in the middle of upgrading to 2.4 here and I see that 
MemoryDependenceAnalysis has changed a bit.  What are the major changes here?

There are a couple of additional requirements I've run into over the last few 
days:

1. I need something that can operate on MachineInstructions.  Currently 
nothing in LLVM supports this.  One of the places I want memory dependence 
analaysis is in the spiller to eliminate useless spills and reloads.

2. I need something that understands false sharing.  That is, optionally the 
memory dependence analysis should return dependencies that might not be exact 
aliases in memory but that might touch the same cache line.  This is important 
for efficient parallelization among other things.

Any thoughts on either of these requirements?

I'm going to see if I can convince management to let me devote some time to 
this.  It may be the case that they want me to interface to our existing 
memory dependence information in our optimizer.  While we want to be able to 
do that, I also want to improve LLVM's native analysis.

                                         -Dave

From brandner at complang.tuwien.ac.at  Wed Jan 14 11:59:03 2009
From: brandner at complang.tuwien.ac.at (Brandner Florian)
Date: Wed, 14 Jan 2009 18:59:03 +0100
Subject: [LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)
In-Reply-To: <4d77c5f20901140558v7332be81j8f7a90fb67183a39@mail.gmail.com>
References: <4d77c5f20901140558v7332be81j8f7a90fb67183a39@mail.gmail.com>
Message-ID: <496E27E7.2050203@complang.tuwien.ac.at>

Alex schrieb:
> It seems that it's not allowed to two same 'ComplexPattern's  in a 'def',
> because TableGen generate the same variable names for the two ComplexPatterns.
> If I understand the source code of TableGen correctly, it's not designed to
> use more than one ComplexPattern instance (no matter they are the same or not).

I've run into this too, the problem is that variables generated for the
ComplexPattern get the same name(s).

I have a patch against llvm 2.4 that fixes this issue, but did not have
the time to post the patch here. I'll do so by tomorrow.

florian




From clattner at apple.com  Wed Jan 14 12:16:43 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 14 Jan 2009 10:16:43 -0800
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
	target)?
In-Reply-To: <496DC91B.2060604@xmos.com>
References: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>
	<496CE961.2030003@xmos.com>
	<7F82EBB1-40B8-4081-B2EE-0F23A9FFFB1D@apple.com>
	<496DC91B.2060604@xmos.com>
Message-ID: <26D082C5-D0D5-4C61-8F19-9FEDD6E13F54@apple.com>


On Jan 14, 2009, at 3:14 AM, Richard Osborne wrote:

>> Evan
> OK, that make sense, I'll take a look at changing this. I've added a  
> bug
> for the issue:
>
> http://llvm.org/bugs/show_bug.cgi?id=3324
>
> There is currently no Backend: XCore component in bugzilla so I've put
> it under new-bugs. Could someone add this component for me.

Added.  You should also be automatically CC'd on anything filed to  
that component,

-Chris

From richard at xmos.com  Wed Jan 14 12:35:24 2009
From: richard at xmos.com (Richard Osborne)
Date: Wed, 14 Jan 2009 18:35:24 +0000
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
 target)?
In-Reply-To: <26D082C5-D0D5-4C61-8F19-9FEDD6E13F54@apple.com>
References: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>	<496CE961.2030003@xmos.com>	<7F82EBB1-40B8-4081-B2EE-0F23A9FFFB1D@apple.com>	<496DC91B.2060604@xmos.com>
	<26D082C5-D0D5-4C61-8F19-9FEDD6E13F54@apple.com>
Message-ID: <496E306C.2000009@xmos.com>

Chris Lattner wrote:
> On Jan 14, 2009, at 3:14 AM, Richard Osborne wrote:
>
>   
>>> Evan
>>>       
>> OK, that make sense, I'll take a look at changing this. I've added a  
>> bug
>> for the issue:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=3324
>>
>> There is currently no Backend: XCore component in bugzilla so I've put
>> it under new-bugs. Could someone add this component for me.
>>     
>
> Added.  You should also be automatically CC'd on anything filed to  
> that component,
>
> -Chris
>   
Thanks,

I've just commited a fix in r62238:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090112/072150.html

-- 
Richard Osborne | XMOS
http://www.xmos.com



From anton at korobeynikov.info  Wed Jan 14 13:11:29 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 14 Jan 2009 22:11:29 +0300
Subject: [LLVMdev] ia64 target problems with ELF sections
In-Reply-To: <e50173bd0901140849r2269ecd4r21ab01644e1661d9@mail.gmail.com>
References: <e50173bd0901140849r2269ecd4r21ab01644e1661d9@mail.gmail.com>
Message-ID: <D4ED53E4-18AD-4C1A-9E0E-B55501D02978@korobeynikov.info>

Hello, Roman

> llc: /opt/llvm/lib/Target/ELFTargetAsmInfo.cpp:133: const
> llvm::Section* llvm::ELFTargetAsmInfo::MergeableStringSection(const
> llvm::GlobalVariable*) const: Assertion `getCStringSection() &&
> "Should have string section prefix"' failed.
>
> Is it a bug in the ia64 backend?
In general - yes. Please file a PR. I should introduce a fallback for  
such case.

---
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From lists at grahamwakefield.net  Wed Jan 14 14:44:13 2009
From: lists at grahamwakefield.net (Graham Wakefield)
Date: Wed, 14 Jan 2009 12:44:13 -0800
Subject: [LLVMdev] quick q configuring osx
Message-ID: <7EFE86AF-E134-43F9-B8F8-3799E007B0CB@grahamwakefield.net>

Sorry if this is a newb q... I'm developing an application on a 10.5  
machine but want to target the 10.4 SDK. Is there a magic incantation  
for the llvm configure script to set the sysroot path, equivalent to  
e.g. --with-sysroot "/Developer/SDKs/MacOSX10.4u.sdk"?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090114/23a27640/attachment.html 

From clattner at apple.com  Wed Jan 14 14:48:01 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 14 Jan 2009 12:48:01 -0800
Subject: [LLVMdev] quick q configuring osx
In-Reply-To: <7EFE86AF-E134-43F9-B8F8-3799E007B0CB@grahamwakefield.net>
References: <7EFE86AF-E134-43F9-B8F8-3799E007B0CB@grahamwakefield.net>
Message-ID: <63C1D2E9-22E4-4A15-A567-8EA29E6869C6@apple.com>


On Jan 14, 2009, at 12:44 PM, Graham Wakefield wrote:

> Sorry if this is a newb q... I'm developing an application on a 10.5  
> machine but want to target the 10.4 SDK. Is there a magic  
> incantation for the llvm configure script to set the sysroot path,  
> equivalent to e.g. --with-sysroot "/Developer/SDKs/MacOSX10.4u.sdk"?
>
Try 'make UNIVERSAL_SDK_PATH=/Developer/SDKs/MacOSX10.4u.sdk/'.

There are some comments in llvm/Makefile.rules that can help,

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090114/d028f5b9/attachment.html 

From devlists at shadowlab.org  Wed Jan 14 15:29:17 2009
From: devlists at shadowlab.org (Jean-Daniel Dupas)
Date: Wed, 14 Jan 2009 22:29:17 +0100
Subject: [LLVMdev] quick q configuring osx
In-Reply-To: <63C1D2E9-22E4-4A15-A567-8EA29E6869C6@apple.com>
References: <7EFE86AF-E134-43F9-B8F8-3799E007B0CB@grahamwakefield.net>
	<63C1D2E9-22E4-4A15-A567-8EA29E6869C6@apple.com>
Message-ID: <6D9E2400-E6FB-431E-A406-AA1D6CC357F9@shadowlab.org>


Le 14 janv. 09 ? 21:48, Chris Lattner a ?crit :

>
> On Jan 14, 2009, at 12:44 PM, Graham Wakefield wrote:
>
>> Sorry if this is a newb q... I'm developing an application on a  
>> 10.5 machine but want to target the 10.4 SDK. Is there a magic  
>> incantation for the llvm configure script to set the sysroot path,  
>> equivalent to e.g. --with-sysroot "/Developer/SDKs/MacOSX10.4u.sdk"?
>>
> Try 'make UNIVERSAL_SDK_PATH=/Developer/SDKs/MacOSX10.4u.sdk/'.
>
> There are some comments in llvm/Makefile.rules that can help,

Note that you don't have to use 10.4 SDK to target Tiger. You just  
have to set the "macosx version min" (either using the gcc flag - 
mmacosx-version-min=10.4 or using the MACOSX_DEPLOYMENT_TARGET env var)

env MACOSX_DEPLOYMENT_TARGET=10.4 make


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090114/495ea1f3/attachment.html 

From eli.friedman at gmail.com  Wed Jan 14 15:37:12 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 14 Jan 2009 13:37:12 -0800
Subject: [LLVMdev] FP problems in different backends?
In-Reply-To: <e50173bd0901140843k9885949o66f5dd02ca994100@mail.gmail.com>
References: <e50173bd0901140843k9885949o66f5dd02ca994100@mail.gmail.com>
Message-ID: <f5aa3e9b0901141337u360e85e2k4087eba44ace6178@mail.gmail.com>

On Wed, Jan 14, 2009 at 8:43 AM, Roman Levenstein
<romix.llvm at googlemail.com> wrote:
> The compilation of the attached BC file fails on multiple backends, namely:
>  ia64, mips, mipsel, alpha

Hmm, looks like real bugs. None of those backends are very widely
used, so it's not too surprising there are issues.   ia64 and alpha
are experimental, so issues are expected.  I'm not sure of the status
of the mips backend; it might be worth filing a bug for that.

> May be I'm testing in the wong way?

Well, in general, the output of llvm-gcc isn't portable, but besides
platform-specific intrinsics, llc shouldn't abort.  Your testing
methodology isn't off as long as you don't care whether the result
actually runs, and there isn't anything wrong with the input files as
far as I can tell.

-Eli

From prakash.prabhu at gmail.com  Wed Jan 14 16:14:47 2009
From: prakash.prabhu at gmail.com (Prakash Prabhu)
Date: Wed, 14 Jan 2009 17:14:47 -0500
Subject: [LLVMdev] Mapping between LLVM bitcode and C source
Message-ID: <85a4cc050901141414r54154c23me87cc4392d3ed566@mail.gmail.com>

Hi,

Is there a way, from within an opt pass, to find the correspondence
between an LLVM IR object and C source code (basically line number
info similar to the one used with gcc + gdb to help debugging ),
assuming either a llvm-gcc front end ?

Sorry if this question was asked before.

Thanks for your time.

- Prakash

From lists at grahamwakefield.net  Wed Jan 14 17:43:43 2009
From: lists at grahamwakefield.net (Graham Wakefield)
Date: Wed, 14 Jan 2009 15:43:43 -0800
Subject: [LLVMdev] quick q configuring osx
In-Reply-To: <6D9E2400-E6FB-431E-A406-AA1D6CC357F9@shadowlab.org>
References: <7EFE86AF-E134-43F9-B8F8-3799E007B0CB@grahamwakefield.net>
	<63C1D2E9-22E4-4A15-A567-8EA29E6869C6@apple.com>
	<6D9E2400-E6FB-431E-A406-AA1D6CC357F9@shadowlab.org>
Message-ID: <5A2C821C-AA78-48BB-BA6B-83D1BC47F195@grahamwakefield.net>

Hi,

For the record, adding
   UNIVERSAL_SDK_PATH=/Developer/SDKs/MacOSX10.4u.sdk/
was insufficient to restrict the .a/.o files to link against the 10.4  
sdk, but
   env MACOSX_DEPLOYMENT_TARGET=10.4 make
did the trick.

Thanks!

On Jan 14, 2009, at 1:29 PM, Jean-Daniel Dupas wrote:

>
> Le 14 janv. 09 ? 21:48, Chris Lattner a ?crit :
>
>>
>> On Jan 14, 2009, at 12:44 PM, Graham Wakefield wrote:
>>
>>> Sorry if this is a newb q... I'm developing an application on a  
>>> 10.5 machine but want to target the 10.4 SDK. Is there a magic  
>>> incantation for the llvm configure script to set the sysroot path,  
>>> equivalent to e.g. --with-sysroot "/Developer/SDKs/MacOSX10.4u.sdk"?
>>>
>> Try 'make UNIVERSAL_SDK_PATH=/Developer/SDKs/MacOSX10.4u.sdk/'.
>>
>> There are some comments in llvm/Makefile.rules that can help,
>
> Note that you don't have to use 10.4 SDK to target Tiger. You just  
> have to set the "macosx version min" (either using the gcc flag - 
> mmacosx-version-min=10.4 or using the MACOSX_DEPLOYMENT_TARGET env  
> var)
>
> env MACOSX_DEPLOYMENT_TARGET=10.4 make
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090114/35348663/attachment-0001.html 

From snaroff at apple.com  Wed Jan 14 18:09:13 2009
From: snaroff at apple.com (steve naroff)
Date: Wed, 14 Jan 2009 16:09:13 -0800
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
Message-ID: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>

Folks,

Is anyone still using the Visual Studio solution files in the win32  
directory?

If they aren't being maintained, they should probably be removed (to  
avoid any confusion).

Thanks for any feedback,

snaroff

From Micah.Villmow at amd.com  Wed Jan 14 18:19:50 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Wed, 14 Jan 2009 16:19:50 -0800
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
In-Reply-To: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAD90@ssanexmb1.amd.com>

I am still using them for llc/llvm-as/opt/llvm-dis/tablegen and a few
others.

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of steve naroff
Sent: Wednesday, January 14, 2009 4:09 PM
To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln

Folks,

Is anyone still using the Visual Studio solution files in the win32  
directory?

If they aren't being maintained, they should probably be removed (to  
avoid any confusion).

Thanks for any feedback,

snaroff
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




From ofv at wanadoo.es  Wed Jan 14 18:42:41 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 15 Jan 2009 01:42:41 +0100
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<5BA674C5FF7B384A92C2C95D8CC71E1C6DAD90@ssanexmb1.amd.com>
Message-ID: <m3vdshz9fi.fsf@telefonica.net>

"Villmow, Micah" <Micah.Villmow at amd.com> writes:

> I am still using them for llc/llvm-as/opt/llvm-dis/tablegen and a few
> others.

The VS project files generated with CMake should build those.

-- 
Oscar


From xaero_1 at hotmail.com  Wed Jan 14 18:43:11 2009
From: xaero_1 at hotmail.com (Lee Wanghao)
Date: Thu, 15 Jan 2009 08:43:11 +0800
Subject: [LLVMdev] Ubuntu LLVM compiled a page of Simit-ARM with errors
In-Reply-To: <1F4C6884-0634-4117-871A-CC9DA856A8BE@apple.com>
References: <BAY116-W429B225B8FDDAA1102DC7AC0D60@phx.gbl>
	<1F4C6884-0634-4117-871A-CC9DA856A8BE@apple.com>
Message-ID: <BAY116-W1848550DEA7BF7A2120E3EC0D70@phx.gbl>






Hi Everyone,I am new to LLVM and I am not sure if its capable of being a compilationstrategy to accelerate Dynamic Compiled Instruction set Simulation.I have tried changing the source code of: http://simit-arm.sourceforge.net/ tocompile pages of C++ code (translated from Arm Assembly) on the fly usingllvm-g++ and it gave the following errors:In file included from/home/wanghao/Desktop/SimIt-ARM-3.0/build/include/bittypes.h:22,                 from/home/wanghao/Desktop/SimIt-ARM-3.0/build/include/misc.h:20,                 from/home/wanghao/Desktop/SimIt-ARM-3.0/build/include/armemul.h:20,                 from/home/wanghao/Desktop/SimIt-ARM-3.0/build/include/arch.hpp:120,                 from/home/wanghao/Desktop/SimIt-ARM-3.0/build/include/arch_jit.hpp:20,                 from /home/wanghao/.ema/u512//Xcompiled_0.cpp:1:/usr/include/inttypes.h:385: error: `__extern_inline' does not name a type/usr/include/inttypes.h:401: error: `__extern_inline' does not name a type/usr/includ!
 e/inttypes.h:415: error: `__extern_inline' does not name a type/usr/include/inttypes.h:432: error: `__extern_inline' does not name a typeIn file included from/home/wanghao/Desktop/SimIt-ARM-3.0/build/include/dyn_arm_emul.hpp:18,                 from /home/wanghao/.ema/u512//Xcompiled_0.cpp:2:/usr/include/pthread.h:1110: error: expected constructor, destructor, or typeconversion/usr/include/pthread.h:1110: error: expected `,' or `;'Total user time  : 3.188 sec.Total system time: 0.472 sec.Simulation user time  : 2.892 sec.Simulation system time: 0.400 sec.Caching user time  : 0.296 sec.Caching system time: 0.072 sec.Simulation speed : 2.285e+07 inst/sec.Total instructions : 83634854 (83M)Requested blocks  : 1.Cache-hit count : 0.Connected servers/threads : 2 of 2.Compilation count :  thread 0: 0  thread 1: 0Please also advise on whether LLVM-GCC is able to do any aid to Instruction SetSimulation. Thanks in advance.RegardsWang Hao Lee
_________________________________________________________________
What can you do with the new Windows Live? Find out
http://www.microsoft.com/windows/windowslive/default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090115/f49a754b/attachment.html 

From clattner at apple.com  Thu Jan 15 01:57:05 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 14 Jan 2009 23:57:05 -0800
Subject: [LLVMdev] [llvm-commits] [llvm] r58505 -
	/llvm/trunk/lib/VMCore/Type.cpp
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A01C7E040@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A01C7DEFD@CHN-CL-MAIL01.mchp-main.com>
	<F536B7C316F9474E9F7091239725AC9A01C7E040@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <097F2801-4345-4032-8075-C7A04F298A85@apple.com>

On Jan 13, 2009, at 2:08 AM, Sachin.Punyani at microchip.com wrote:
> I am starting an old pending task. This is to make 16 bit integer a
> valid index.

Great!

> Above in the mail is the link to modification that Sanjiv made.  
> Also, I
> have just gone through an old discussion related to index validity.  
> Here
> is the link -
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-July/015674.html
>
> Can you please provide some pointers to what kind of changes bc
> reader/writer or other areas of compiler would require.

At the minimum, we need to be able to write a GEP with a 16-bit index  
in a .ll file, and do:

llvm-as < foo.ll | llvm-dis | llvm-as | llvm-dis

and get the same gep out.  This means that we need a way to encode the  
index in the .bc file.  Also, the description in docs/LangRef.html and  
the getelementptr FAQ need to be updated.

Thanks for tackling this!

-Chris

From baldrick at free.fr  Thu Jan 15 02:43:49 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 15 Jan 2009 09:43:49 +0100
Subject: [LLVMdev] Ubuntu LLVM compiled a page of Simit-ARM with errors
In-Reply-To: <BAY116-W1848550DEA7BF7A2120E3EC0D70@phx.gbl>
References: <BAY116-W429B225B8FDDAA1102DC7AC0D60@phx.gbl>
	<1F4C6884-0634-4117-871A-CC9DA856A8BE@apple.com>
	<BAY116-W1848550DEA7BF7A2120E3EC0D70@phx.gbl>
Message-ID: <200901150943.50140.baldrick@free.fr>

Hi, llvm-gcc uses the C99 definition of external inline,
same as gcc-4.3.  Do you see the same problem if you compile
with gcc-4.3?

Ciao,

Duncan.

From brandner at complang.tuwien.ac.at  Thu Jan 15 02:50:30 2009
From: brandner at complang.tuwien.ac.at (Brandner)
Date: Thu, 15 Jan 2009 09:50:30 +0100
Subject: [LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)
In-Reply-To: <496E27E7.2050203@complang.tuwien.ac.at>
References: <4d77c5f20901140558v7332be81j8f7a90fb67183a39@mail.gmail.com>
	<496E27E7.2050203@complang.tuwien.ac.at>
Message-ID: <200901150950.31241.brandner@complang.tuwien.ac.at>

On Wednesday 14 January 2009 18:59:03 Brandner Florian wrote:
> I have a patch against llvm 2.4 that fixes this issue, but did not have
> the time to post the patch here. I'll do so by tomorrow.

here is the patch, still against llvm 2.4. I had a short look on trunk, but it 
seems that there are several conflicts. Maybe a tablgen expert should have a 
look at this - I also do not know if there are changes needed for the 
FastISelEmitter.

I hope this is a starting point for you,
florian

ps: We have a working compiler here that relies on these changes, so it does 
not seem to break anything, at least for our private backend.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiple-complexpatterns.patch
Type: text/x-patch
Size: 2958 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090115/fe4ad532/attachment-0001.bin 

From g.mondada at etel.ch  Thu Jan 15 03:08:40 2009
From: g.mondada at etel.ch (Mondada Gabriele)
Date: Thu, 15 Jan 2009 10:08:40 +0100
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
In-Reply-To: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
Message-ID: <4EA20108F62E0346A80AFB03445370F2041018B1@de01ex08.GLOBAL.JHCN.NET>

Hi,
I just moved to the CMake solution. By the way, the generated libs haven't the same names. In my opinion, we have to choose one way and remove the other one. If it helps, you can put in the win32 directory the result of CMake, or add a script that generate this win32 directory with cmake.
Gab

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of steve naroff
> Sent: Thursday, January 15, 2009 1:09 AM
> To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
> Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
> 
> Folks,
> 
> Is anyone still using the Visual Studio solution files in the win32
> directory?
> 
> If they aren't being maintained, they should probably be removed (to
> avoid any confusion).
> 
> Thanks for any feedback,
> 
> snaroff
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From nicolas at capens.net  Thu Jan 15 03:19:27 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Thu, 15 Jan 2009 10:19:27 +0100
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
In-Reply-To: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
Message-ID: <009c01c976f2$5d972700$18c57500$@net>

Hi Steve,

The Visual Studio solution and project files are quite handy. CMake creates
absolute paths instead of relative paths, making it cumbersome to move
things around. Also, for newcomers (e.g. students) it's really great to be
able to download the package, open the solution and compile without any
complication.

They haven't been updated in a while, but it would be nice to have working
ones in the 2.5 release...

Cheers,

Nicolas


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of steve naroff
Sent: donderdag 15 januari 2009 1:09
To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln

Folks,

Is anyone still using the Visual Studio solution files in the win32  
directory?

If they aren't being maintained, they should probably be removed (to  
avoid any confusion).

Thanks for any feedback,

snaroff
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From romix.llvm at googlemail.com  Thu Jan 15 03:35:57 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Thu, 15 Jan 2009 10:35:57 +0100
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
	target)?
In-Reply-To: <496E306C.2000009@xmos.com>
References: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>
	<496CE961.2030003@xmos.com>
	<7F82EBB1-40B8-4081-B2EE-0F23A9FFFB1D@apple.com>
	<496DC91B.2060604@xmos.com>
	<26D082C5-D0D5-4C61-8F19-9FEDD6E13F54@apple.com>
	<496E306C.2000009@xmos.com>
Message-ID: <e50173bd0901150135o7c02997amf0b597aacb47bb87@mail.gmail.com>

Hi Richard,

Thanks for working on this! Your patched solved my initial problem,
but introduced another one. Please find attached another BC file that
fails on xcore with the linear scan regalloc.

This is the error message I get
eliminateFrameIndex Frame size too big: -3
0   llc       0x08affd1e
1   libc.so.6 0xb7d35a01 abort + 257
2   llc       0x081a0972
llvm::XCoreRegisterInfo::eliminateFrameIndex(llvm::ilist_iterator<llvm::MachineInstr>,
int, llvm::RegScavenger*) const + 1570
Aborted

Could you check what is still wrong?

-Roman

2009/1/14, Richard Osborne <richard at xmos.com>:
> Chris Lattner wrote:
>  > On Jan 14, 2009, at 3:14 AM, Richard Osborne wrote:
>  >
>  >
>  >>> Evan
>  >>>
>  >> OK, that make sense, I'll take a look at changing this. I've added a
>  >> bug
>  >> for the issue:
>  >>
>  >> http://llvm.org/bugs/show_bug.cgi?id=3324
>  >>
>  >> There is currently no Backend: XCore component in bugzilla so I've put
>  >> it under new-bugs. Could someone add this component for me.
>  >>
>  >
>  > Added.  You should also be automatically CC'd on anything filed to
>  > that component,
>  >
>  > -Chris
>  >
>
> Thanks,
>
>  I've just commited a fix in r62238:
>
>  http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090112/072150.html
>
>
>  --
>  Richard Osborne | XMOS
>  http://www.xmos.com
>
>
>  _______________________________________________
>
> LLVM Developers mailing list
>  LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>  http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Queens.c.bc
Type: application/octet-stream
Size: 7956 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090115/8a43e08f/attachment.obj 

From romix.llvm at googlemail.com  Thu Jan 15 03:51:31 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Thu, 15 Jan 2009 10:51:31 +0100
Subject: [LLVMdev] ia64 target problems with ELF sections
In-Reply-To: <D4ED53E4-18AD-4C1A-9E0E-B55501D02978@korobeynikov.info>
References: <e50173bd0901140849r2269ecd4r21ab01644e1661d9@mail.gmail.com>
	<D4ED53E4-18AD-4C1A-9E0E-B55501D02978@korobeynikov.info>
Message-ID: <e50173bd0901150151j1681ade0m33e0b1a7ac329433@mail.gmail.com>

Done!

Bugzilla PR for this problem can be found here:
http://llvm.org/bugs/show_bug.cgi?id=3327

-Roman


2009/1/14, Anton Korobeynikov <anton at korobeynikov.info>:
> Hello, Roman
>
>
>  > llc: /opt/llvm/lib/Target/ELFTargetAsmInfo.cpp:133: const
>  > llvm::Section* llvm::ELFTargetAsmInfo::MergeableStringSection(const
>  > llvm::GlobalVariable*) const: Assertion `getCStringSection() &&
>  > "Should have string section prefix"' failed.
>  >
>  > Is it a bug in the ia64 backend?
>
> In general - yes. Please file a PR. I should introduce a fallback for
>  such case.
>
>  ---
>  With best regards, Anton Korobeynikov
>  Faculty of Mathematics and Mechanics, Saint Petersburg State University
>
>  _______________________________________________
>  LLVM Developers mailing list
>  LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>  http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From richard at xmos.com  Thu Jan 15 05:57:45 2009
From: richard at xmos.com (Richard Osborne)
Date: Thu, 15 Jan 2009 11:57:45 +0000
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
 target)?
In-Reply-To: <e50173bd0901150135o7c02997amf0b597aacb47bb87@mail.gmail.com>
References: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>	<496CE961.2030003@xmos.com>	<7F82EBB1-40B8-4081-B2EE-0F23A9FFFB1D@apple.com>	<496DC91B.2060604@xmos.com>	<26D082C5-D0D5-4C61-8F19-9FEDD6E13F54@apple.com>	<496E306C.2000009@xmos.com>
	<e50173bd0901150135o7c02997amf0b597aacb47bb87@mail.gmail.com>
Message-ID: <496F24B9.7040504@xmos.com>

Roman Levenstein wrote:
> Hi Richard,
>
> Thanks for working on this! Your patched solved my initial problem,
> but introduced another one. Please find attached another BC file that
> fails on xcore with the linear scan regalloc.
>
> This is the error message I get
> eliminateFrameIndex Frame size too big: -3
> 0   llc       0x08affd1e
> 1   libc.so.6 0xb7d35a01 abort + 257
> 2   llc       0x081a0972
> llvm::XCoreRegisterInfo::eliminateFrameIndex(llvm::ilist_iterator<llvm::MachineInstr>,
> int, llvm::RegScavenger*) const + 1570
> Aborted
>
> Could you check what is still wrong?
>
> -Roman
I had a fix for this in my local branch which I hadn't got around to 
commiting. This should be fixed in 62258.

http://llvm.org/viewvc/llvm-project?rev=62258&view=rev

-- 
Richard Osborne | XMOS
http://www.xmos.com



From ofv at wanadoo.es  Thu Jan 15 07:50:45 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 15 Jan 2009 14:50:45 +0100
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<4EA20108F62E0346A80AFB03445370F2041018B1@de01ex08.GLOBAL.JHCN.NET>
Message-ID: <m3r634znii.fsf@telefonica.net>

Mondada Gabriele <g.mondada at etel.ch> writes:

> I just moved to the CMake solution. By the way, the generated libs
> haven't the same names.

Which ones? The only difference is that we now generate .lib files where
.obj were generated on the past, and require a parameter to be passed to
the linker for including them on the final executable.

> In my opinion, we have to choose one way and remove the other one. If
> it helps, you can put in the win32 directory the result of CMake,

On the release tarball? It seems a good idea (as far as someone
volunteers to do the work) but someone mentioned on this thread that the
project files generated with CMake contains absolute paths.

> or add a script that generate this win32 directory with cmake.

The amount of work saved by such script would be almost nil, and it can
cause problems on setups with more than one compiler installed.

-- 
Oscar


From romix.llvm at googlemail.com  Thu Jan 15 07:52:50 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Thu, 15 Jan 2009 14:52:50 +0100
Subject: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore
	target)?
In-Reply-To: <496F24B9.7040504@xmos.com>
References: <e50173bd0901130505v29e044e8ged3d5a9450ac43fa@mail.gmail.com>
	<496CE961.2030003@xmos.com>
	<7F82EBB1-40B8-4081-B2EE-0F23A9FFFB1D@apple.com>
	<496DC91B.2060604@xmos.com>
	<26D082C5-D0D5-4C61-8F19-9FEDD6E13F54@apple.com>
	<496E306C.2000009@xmos.com>
	<e50173bd0901150135o7c02997amf0b597aacb47bb87@mail.gmail.com>
	<496F24B9.7040504@xmos.com>
Message-ID: <e50173bd0901150552h191093e7w87334e608e6bd2ee@mail.gmail.com>

Hi Richard,

2009/1/15, Richard Osborne <richard at xmos.com>:
> Roman Levenstein wrote:
>  > Hi Richard,
>  >
>  > Thanks for working on this! Your patched solved my initial problem,
>  > but introduced another one. Please find attached another BC file that
>  > fails on xcore with the linear scan regalloc.
>  >
>  > This is the error message I get
>  > eliminateFrameIndex Frame size too big: -3
>  > 0   llc       0x08affd1e
>  > 1   libc.so.6 0xb7d35a01 abort + 257
>  > 2   llc       0x081a0972
>  > llvm::XCoreRegisterInfo::eliminateFrameIndex(llvm::ilist_iterator<llvm::MachineInstr>,
>  > int, llvm::RegScavenger*) const + 1570
>  > Aborted
>  >
>  > Could you check what is still wrong?
>  >
>  > -Roman
>
> I had a fix for this in my local branch which I hadn't got around to
>  commiting. This should be fixed in 62258.
>
>  http://llvm.org/viewvc/llvm-project?rev=62258&view=rev

Thanks! That solved my problem. No more crashes related to the LR
register on XCore!

-Roman

From ofv at wanadoo.es  Thu Jan 15 08:02:31 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 15 Jan 2009 15:02:31 +0100
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<009c01c976f2$5d972700$18c57500$@net>
Message-ID: <m3iqogzmyw.fsf@telefonica.net>

"Nicolas Capens" <nicolas at capens.net> writes:

> The Visual Studio solution and project files are quite handy. CMake creates
> absolute paths instead of relative paths, making it cumbersome to move
> things around. Also, for newcomers (e.g. students) it's really great to be
> able to download the package, open the solution and compile without any
> complication.
>
> They haven't been updated in a while, but it would be nice to have working
> ones in the 2.5 release...

There is a contradiction among this two paragraphs: the first one says
"they are convenient" and the second one says "they are outdated".

The primary goal of the LLVM CMake build system was to alleviate
maintenance work, the second was to support all VS versions wich are C++
compliant enough to compile LLVM. Another nice side-effect is that now
VS users can build all LLVM targets. The VS project files under win32/
are good enough as far as someone maintains them, you have the correct
VS version and don't need the missing functionality.

Finally, a student that works with LLVM is not a computer newbie: he
knows how to follow web links, install a piece of software, and
copy/paste onto a console. This process requires less time than the LLVM
build itself.

Of course, this requires that the LLVM CMake instructions should become
integrated into the LLVM docs. I hope to do this before the 2.5 release.

-- 
Oscar


From g.mondada at etel.ch  Thu Jan 15 10:30:18 2009
From: g.mondada at etel.ch (Mondada Gabriele)
Date: Thu, 15 Jan 2009 17:30:18 +0100
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
In-Reply-To: <m3r634znii.fsf@telefonica.net>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<4EA20108F62E0346A80AFB03445370F2041018B1@de01ex08.GLOBAL.JHCN.NET>
	<m3r634znii.fsf@telefonica.net>
Message-ID: <4EA20108F62E0346A80AFB03445370F2041018B3@de01ex08.GLOBAL.JHCN.NET>

> > I just moved to the CMake solution. By the way, the generated libs
> > haven't the same names.
> 
> Which ones? The only difference is that we now generate .lib files
> where
> .obj were generated on the past, and require a parameter to be passed
> to
> the linker for including them on the final executable.

I was linking with 
VMCore.lib support.lib System.lib Analysis.lib CodeGen.lib Target.lib Transforms.lib
and I'm now linking with
LLVMVMCore.lib LLVMScalarOpts.lib LLVMSelectionDAG.lib LLVMSupport.lib LLVMSystem.lib LLVMAnalysis.lib LLVMCodeGen.lib LLVMTarget.lib LLVMTransformUtils.lib LLVMAsmPrinter.lib
 
> > In my opinion, we have to choose one way and remove the other one. If
> > it helps, you can put in the win32 directory the result of CMake,
> 
> On the release tarball? It seems a good idea (as far as someone
> volunteers to do the work) but someone mentioned on this thread that
> the
> project files generated with CMake contains absolute paths.

Right, I just look inside the .vcproj files generated by CMake and paths are absolute, even by using the command line version of cmake and by specifying relative paths. 



From ofv at wanadoo.es  Thu Jan 15 10:43:34 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 15 Jan 2009 17:43:34 +0100
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
Message-ID: <m3ab9szfih.fsf@telefonica.net>

Makslane Ara?jo Rodrigues
<makslane at hotmail.com> writes:

> Please, don't remove, I'm using!!!

What's preventing you from using CMake?

Is there some problem we can solve?

-- 
Oscar


From ofv at wanadoo.es  Thu Jan 15 10:48:16 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 15 Jan 2009 17:48:16 +0100
Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<4EA20108F62E0346A80AFB03445370F2041018B1@de01ex08.GLOBAL.JHCN.NET>
	<m3r634znii.fsf@telefonica.net>
	<4EA20108F62E0346A80AFB03445370F2041018B3@de01ex08.GLOBAL.JHCN.NET>
Message-ID: <m363kgzfan.fsf@telefonica.net>

Mondada Gabriele <g.mondada at etel.ch> writes:

>> > I just moved to the CMake solution. By the way, the generated libs
>> > haven't the same names.
>> 
>> Which ones? The only difference is that we now generate .lib files
>> where .obj were generated on the past, and require a parameter to be
>> passed to the linker for including them on the final executable.
>
> I was linking with VMCore.lib support.lib System.lib Analysis.lib
> CodeGen.lib Target.lib Transforms.lib
> and I'm now linking with
> LLVMVMCore.lib LLVMScalarOpts.lib LLVMSelectionDAG.lib LLVMSupport.lib
> LLVMSystem.lib LLVMAnalysis.lib LLVMCodeGen.lib LLVMTarget.lib
> LLVMTransformUtils.lib LLVMAsmPrinter.lib

I forgot that.

Please note that the LLVM CMake build generator works for VS, MinGW,
Linux, OS/X... The same library names are used across all platforms
(plus platform-dependent prefixes/suffixes). The best part of this is
that a single CMake specification for your compiler would work on all
platforms LLVM supports with almost no changes.

-- 
Oscar


From Micah.Villmow at amd.com  Thu Jan 15 11:40:55 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Thu, 15 Jan 2009 09:40:55 -0800
Subject: [LLVMdev] Bug in documentation, TargetRegisterInfo.h
Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAE89@ssanexmb1.amd.com>

/// emitProlog/emitEpilog - These methods insert prolog and epilog code
into

  /// the function. The return value is the number of instructions

  /// added to (negative if removed from) the basic block (entry for
prologue).

  ///

  virtual void emitPrologue(MachineFunction &MF) const = 0;

  virtual void emitEpilogue(MachineFunction &MF,

                            MachineBasicBlock &MBB) const = 0;

 

 

There is no return type for these functions but the documentation states
that there should be.

 

Micah Villmow

Systems Engineer

Advanced Technology & Performance

Advanced Micro Devices Inc.

S1-609 One AMD Place

Sunnyvale, CA. 94085

P: 408-749-3966

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090115/a082cb2a/attachment.html 

From makslane at hotmail.com  Thu Jan 15 09:15:25 2009
From: makslane at hotmail.com (=?Windows-1252?Q?Makslane_Ara=FAjo_Rodrigues?=)
Date: Thu, 15 Jan 2009 18:15:25 +0300
Subject: [LLVMdev] [cfe-dev] win32/llvm.sln, win32/clang.sln
In-Reply-To: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
Message-ID: <COL106-W317196965D359213B5C8A1DDD70@phx.gbl>


Please, don't remove, I'm using!!!

 

Regards,

Makslane

> From: snaroff at apple.com
> To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
> Date: Wed, 14 Jan 2009 16:09:13 -0800
> Subject: [cfe-dev] win32/llvm.sln, win32/clang.sln
> 
> Folks,
> 
> Is anyone still using the Visual Studio solution files in the win32  
> directory?
> 
> If they aren't being maintained, they should probably be removed (to  
> avoid any confusion).
> 
> Thanks for any feedback,
> 
> snaroff
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_________________________________________________________________
Mais do que emails! Confira tudo o que Windows Live? pode oferecer.
http://www.microsoft.com/windows/windowslive/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090115/2aee967f/attachment-0001.html 

From dgregor at apple.com  Thu Jan 15 11:03:48 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 15 Jan 2009 09:03:48 -0800
Subject: [LLVMdev] [cfe-dev] win32/llvm.sln, win32/clang.sln
In-Reply-To: <m3ab9szfih.fsf@telefonica.net>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
	<m3ab9szfih.fsf@telefonica.net>
Message-ID: <14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>


On Jan 15, 2009, at 8:43 AM, ?scar Fuentes wrote:

> Makslane Ara?jo Rodrigues
> <makslane at hotmail.com> writes:
>
>> Please, don't remove, I'm using!!!
>
> What's preventing you from using CMake?
>
> Is there some problem we can solve?

At some point, we'll need to deal with the testing issue in the CMake  
build system. Clang, for example, uses some GNU make magic to run its  
tests, which we'll need to replace with something more platform- 
neutral in CMake.

That shouldn't prevent anyone who is using the current VS project  
files from switching to CMake, though.

	- Doug



From ofv at wanadoo.es  Thu Jan 15 11:46:34 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 15 Jan 2009 18:46:34 +0100
Subject: [LLVMdev] Testing and CMake (was: win32/llvm.sln, win32/clang.sln)
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
	<m3ab9szfih.fsf@telefonica.net>
	<14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>
Message-ID: <m31vv4zclh.fsf_-_@telefonica.net>

Douglas Gregor <dgregor at apple.com> writes:

>>> Please, don't remove, I'm using!!!
>>
>> What's preventing you from using CMake?
>>
>> Is there some problem we can solve?
>
> At some point, we'll need to deal with the testing issue in the CMake  
> build system. Clang, for example, uses some GNU make magic to run its  
> tests, which we'll need to replace with something more platform- 
> neutral in CMake.

Testing was (is) the big roadblock for the LLVM CMake system. It is not
practical to duplicate the make-based system we have now, but I think a
good compromise can be achieved by invoking a script instead of
`make'. The build could use this script for doing full testing, so

"make all check"

would keep working, although for partial testing the script would be
mandatory. If this is not already working, is due to lack of time here.

OTOH, I haven't followed in detail all that discussion around a new
testing framework (plus the introduction of C++ unit tests). I need to
relearn was going on and see how that affects my plans.

> That shouldn't prevent anyone who is using the current VS project  
> files from switching to CMake, though.

Right. Current VS project files does not support testing at all.

-- 
Oscar


From snaroff at apple.com  Thu Jan 15 12:16:27 2009
From: snaroff at apple.com (steve naroff)
Date: Thu, 15 Jan 2009 10:16:27 -0800
Subject: [LLVMdev] [cfe-dev] Testing and CMake (was: win32/llvm.sln,
	win32/clang.sln)
In-Reply-To: <m31vv4zclh.fsf_-_@telefonica.net>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
	<m3ab9szfih.fsf@telefonica.net>
	<14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>
	<m31vv4zclh.fsf_-_@telefonica.net>
Message-ID: <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>

Hi Oscar,

For development, CMake is working great for me. I rarely get build  
errors related to the project file being out-of-date.

Is it true that CMake only generates absolute paths? Any idea on the  
difficulty of generating relative paths? I consider this a pretty big  
obstacle...

Thanks for all your hard work on this,

snaroff

On Jan 15, 2009, at 9:46 AM, ?scar Fuentes wrote:

> Douglas Gregor <dgregor at apple.com> writes:
>
>>>> Please, don't remove, I'm using!!!
>>>
>>> What's preventing you from using CMake?
>>>
>>> Is there some problem we can solve?
>>
>> At some point, we'll need to deal with the testing issue in the CMake
>> build system. Clang, for example, uses some GNU make magic to run its
>> tests, which we'll need to replace with something more platform-
>> neutral in CMake.
>
> Testing was (is) the big roadblock for the LLVM CMake system. It is  
> not
> practical to duplicate the make-based system we have now, but I  
> think a
> good compromise can be achieved by invoking a script instead of
> `make'. The build could use this script for doing full testing, so
>
> "make all check"
>
> would keep working, although for partial testing the script would be
> mandatory. If this is not already working, is due to lack of time  
> here.
>
> OTOH, I haven't followed in detail all that discussion around a new
> testing framework (plus the introduction of C++ unit tests). I need to
> relearn was going on and see how that affects my plans.
>
>> That shouldn't prevent anyone who is using the current VS project
>> files from switching to CMake, though.
>
> Right. Current VS project files does not support testing at all.
>
> -- 
> Oscar
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



From cedric.venet at laposte.net  Thu Jan 15 12:43:28 2009
From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=)
Date: Thu, 15 Jan 2009 19:43:28 +0100
Subject: [LLVMdev] [cfe-dev] Testing and CMake
In-Reply-To: <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>	<m3ab9szfih.fsf@telefonica.net>	<14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>	<m31vv4zclh.fsf_-_@telefonica.net>
	<638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>
Message-ID: <496F83D0.6040006@laposte.net>


>
> Is it true that CMake only generates absolute paths? Any idea on the  
> difficulty of generating relative paths? I consider this a pretty big  
> obstacle...
>   

It is probably impossible, by design:

 From the CMake FAQ: http://www.cmake.org/Wiki/CMake_FAQ

Why does CMake use full paths, or can I copy my build tree?

CMake uses full paths because:
- configured header files may have full paths in them, and moving those 
files without re-configuring would cause upredictable behavior.
- because cmake supports out of source builds, if custom commands used 
relative paths to the source tree, they would not work when they are run 
in the build tree because the current directory would be incorrect.
- on Unix systems rpaths might be built into executables so they can 
find shared libraries at run time. If the build tree is moved old 
executables may use the old shared libraries, and not the new ones.

Can the build tree be copied or moved?
The short answer is NO. The reason is because full paths are used in 
CMake, see above. The main problem is that cmake would need to detect 
when the binary tree has been moved and rerun. Often when people want to 
move a binary tree it is so that they can distribute it to other users 
who may not have cmake in which case this would not work even if cmake 
would detect the move.
The workaround is to create a new build tree without copying or moving 
the old one.



From pb at linuxtv.org  Thu Jan 15 12:48:31 2009
From: pb at linuxtv.org (Patrick Boettcher)
Date: Thu, 15 Jan 2009 19:48:31 +0100 (CET)
Subject: [LLVMdev] [cfe-dev] Testing and CMake (was: win32/llvm.sln,
 win32/clang.sln)
In-Reply-To: <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
	<m3ab9szfih.fsf@telefonica.net>
	<14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>
	<m31vv4zclh.fsf_-_@telefonica.net>
	<638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>
Message-ID: <alpine.LRH.1.10.0901151942330.28478@pub2.ifh.de>

Hi Steve,

On Thu, 15 Jan 2009, steve naroff wrote:
> For development, CMake is working great for me. I rarely get build
> errors related to the project file being out-of-date.
>
> Is it true that CMake only generates absolute paths? Any idea on the
> difficulty of generating relative paths? I consider this a pretty big
> obstacle...

I did not follow the full-thread, just reading this Email and I hope I'm 
getting it right:

We had the same problem (relative paths) and it turned out to be 
relatively (got the language joke here? ;)) easy, at least with cmake 2.6, 
in a local project.

set(CMAKE_USE_RELATIVE_PATHS ON)

It works well for vcproj-generation. In Linux I could not test it 
comprehensively yet (as to why it is possible to copy a repository and 
build it in its new place w/o re-cmaking.)

In addition we are setting

set(CMAKE_SUPPRESS_REGENERATION ON)

in order to not have a dependency on the CMakeLists when creating the 
vcproj-file.

HTH,
Patrick.


From ofv at wanadoo.es  Thu Jan 15 13:38:36 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 15 Jan 2009 20:38:36 +0100
Subject: [LLVMdev] [cfe-dev] Testing and CMake
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
	<m3ab9szfih.fsf@telefonica.net>
	<14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>
	<m31vv4zclh.fsf_-_@telefonica.net>
	<638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>
	<alpine.LRH.1.10.0901151942330.28478@pub2.ifh.de>
Message-ID: <m3wscwxsub.fsf@telefonica.net>

Patrick Boettcher <pb at linuxtv.org> writes:

>> For development, CMake is working great for me. I rarely get build
>> errors related to the project file being out-of-date.
>>
>> Is it true that CMake only generates absolute paths? Any idea on the
>> difficulty of generating relative paths? I consider this a pretty big
>> obstacle...
>
> I did not follow the full-thread, just reading this Email and I hope I'm 
> getting it right:
>
> We had the same problem (relative paths) and it turned out to be 
> relatively (got the language joke here? ;)) easy, at least with cmake 2.6, 
> in a local project.
>
> set(CMAKE_USE_RELATIVE_PATHS ON)
>
> It works well for vcproj-generation. In Linux I could not test it 
> comprehensively yet (as to why it is possible to copy a repository and 
> build it in its new place w/o re-cmaking.)

Hmmm...

  CMAKE_USE_RELATIVE_PATHS
       Use relative paths (May not work!).

       If this is set to TRUE, then the CMake will use relative paths between
       the source and binary tree.  This option does not work for more
       complicated projects, and relative paths are used when possible.  In
       general, it is not possible to move CMake generated makefiles to a
       different location regardless of the value of this variable.


> In addition we are setting
>
> set(CMAKE_SUPPRESS_REGENERATION ON)
>
> in order to not have a dependency on the CMakeLists when creating the 
> vcproj-file.

This looks like asking for trouble. Why are you doing this?

-- 
Oscar


From ofv at wanadoo.es  Thu Jan 15 13:40:59 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 15 Jan 2009 20:40:59 +0100
Subject: [LLVMdev] [cfe-dev] Testing and CMake
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
	<m3ab9szfih.fsf@telefonica.net>
	<14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>
	<m31vv4zclh.fsf_-_@telefonica.net>
	<638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>
Message-ID: <m3sknkxsqc.fsf@telefonica.net>

Hello Steve.

steve naroff <snaroff at apple.com> writes:

> For development, CMake is working great for me. I rarely get build  
> errors related to the project file being out-of-date.
>
> Is it true that CMake only generates absolute paths? Any idea on the  
> difficulty of generating relative paths? I consider this a pretty big  
> obstacle...

Well, the fact that you didn't *still* noticed this limitation makes me
think that this is rarely needed :-)

Can you describe on which scenario do you require to move around build
trees?

-- 
Oscar


From snaroff at apple.com  Thu Jan 15 14:06:11 2009
From: snaroff at apple.com (steve naroff)
Date: Thu, 15 Jan 2009 12:06:11 -0800
Subject: [LLVMdev] [cfe-dev] Testing and CMake
In-Reply-To: <m3sknkxsqc.fsf@telefonica.net>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
	<m3ab9szfih.fsf@telefonica.net>
	<14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>
	<m31vv4zclh.fsf_-_@telefonica.net>
	<638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>
	<m3sknkxsqc.fsf@telefonica.net>
Message-ID: <BBC04B4D-FC99-4605-945C-48BC75CA3485@apple.com>


On Jan 15, 2009, at 11:40 AM, ?scar Fuentes wrote:

> Hello Steve.
>
> steve naroff <snaroff at apple.com> writes:
>
>> For development, CMake is working great for me. I rarely get build
>> errors related to the project file being out-of-date.
>>
>> Is it true that CMake only generates absolute paths? Any idea on the
>> difficulty of generating relative paths? I consider this a pretty big
>> obstacle...
>
> Well, the fact that you didn't *still* noticed this limitation makes  
> me
> think that this is rarely needed :-)
>

I haven't noticed it because I've been on the "development" side  
(where the absolute paths aren't a problem).

> Can you describe on which scenario do you require to move around build
> trees?
>

Sure...

As various clang features mature, we enter a "deployment" phase. As  
part of deployment, it is necessary to provide Apple's Build &  
Integration team a self-contained source tree that builds properly.  
This is where the rub is. It isn't appropriate to ask B&I engineers to  
use "cmake".

That said, I want to generate the VS solution files on my local  
machine and then copy them to a B&I machine and have everything "just  
work". For example:

snaroffBook% ls /Volumes/Data/WindowsShared/objc_translate-9/
llvm		vs2005-build

The VS solution files located in "vs2005-build" were built with the  
following command "cmake ../llvm". Since I am using a relative path on  
the command line, I assumed it would use relative paths (my bad  
assumption).

Another point...I have no need to ever "move" the cmake generated  
build files away from the source tree. The source tree and the build  
tree will always move in lock step (which simplifies the problem I am  
looking to solve).

Thanks for any help with this,

snaroff

> -- 
> Oscar
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



From Micah.Villmow at amd.com  Thu Jan 15 15:54:32 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Thu, 15 Jan 2009 13:54:32 -0800
Subject: [LLVMdev] Hitting assertion, unsure why
Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2B@ssanexmb1.amd.com>

I am hitting this assertion:

assert(I != VRBaseMap.end() && "Node emitted out of order - late");

 

I am not sure why this assertion is being triggered or what I changed
that is causing it.

This is asserting when SDValue is FrameIndexSDNode 1.

 

I don't have any code that modified frameindices until my overloaded
RegisterInfo function.

 

I've attached the bc file. If I generate an unoptimized bc file then
there is no issue, only when I turn optimizations on do I hit this
problem.

 

Thanks for any hints,

 

Micah Villmow

Systems Engineer

Advanced Technology & Performance

Advanced Micro Devices Inc.

S1-609 One AMD Place

Sunnyvale, CA. 94085

P: 408-749-3966

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090115/55e30c83/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-opt.bc
Type: application/octet-stream
Size: 1032 bytes
Desc: test-opt.bc
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090115/55e30c83/attachment-0001.obj 

From isanbard at gmail.com  Thu Jan 15 16:07:26 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Thu, 15 Jan 2009 14:07:26 -0800
Subject: [LLVMdev] Hitting assertion, unsure why
In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2B@ssanexmb1.amd.com>
References: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2B@ssanexmb1.amd.com>
Message-ID: <16e5fdf90901151407k6c94e652y3c8620e38b5d7c6@mail.gmail.com>

On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> I am hitting this assertion:
>
> assert(I != VRBaseMap.end() && "Node emitted out of order - late");
>
> I am not sure why this assertion is being triggered or what I changed that
> is causing it.
>
> This is asserting when SDValue is FrameIndexSDNode 1.
>
> I don't have any code that modified frameindices until my overloaded
> RegisterInfo function.
>
> I've attached the bc file. If I generate an unoptimized bc file then there
> is no issue, only when I turn optimizations on do I hit this problem.
>
I got this too. It's related to debug information being in flux right
now. I believe that Devang is working on a fix for this right now.

-bw

From Micah.Villmow at amd.com  Thu Jan 15 16:20:41 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Thu, 15 Jan 2009 14:20:41 -0800
Subject: [LLVMdev] Hitting assertion, unsure why
In-Reply-To: <16e5fdf90901151407k6c94e652y3c8620e38b5d7c6@mail.gmail.com>
References: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2B@ssanexmb1.amd.com>
	<16e5fdf90901151407k6c94e652y3c8620e38b5d7c6@mail.gmail.com>
Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2E@ssanexmb1.amd.com>

Is there any known method/hack of bypassing this?

Thanks,

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Bill Wendling
Sent: Thursday, January 15, 2009 2:07 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Hitting assertion, unsure why

On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah <Micah.Villmow at amd.com>
wrote:
> I am hitting this assertion:
>
> assert(I != VRBaseMap.end() && "Node emitted out of order - late");
>
> I am not sure why this assertion is being triggered or what I changed
that
> is causing it.
>
> This is asserting when SDValue is FrameIndexSDNode 1.
>
> I don't have any code that modified frameindices until my overloaded
> RegisterInfo function.
>
> I've attached the bc file. If I generate an unoptimized bc file then
there
> is no issue, only when I turn optimizations on do I hit this problem.
>
I got this too. It's related to debug information being in flux right
now. I believe that Devang is working on a fix for this right now.

-bw
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




From isanbard at gmail.com  Thu Jan 15 16:26:26 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Thu, 15 Jan 2009 14:26:26 -0800
Subject: [LLVMdev] Hitting assertion, unsure why
In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2E@ssanexmb1.amd.com>
References: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2B@ssanexmb1.amd.com>
	<16e5fdf90901151407k6c94e652y3c8620e38b5d7c6@mail.gmail.com>
	<5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2E@ssanexmb1.amd.com>
Message-ID: <16e5fdf90901151426n4f4390c8rcabf516e00f95647@mail.gmail.com>

Don't generate debug info at this time (you can use "opt
-strip-debug")? :-) Otherwise, I'm not sure.

-bw

On Thu, Jan 15, 2009 at 2:20 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> Is there any known method/hack of bypassing this?
>
> Thanks,
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Bill Wendling
> Sent: Thursday, January 15, 2009 2:07 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Hitting assertion, unsure why
>
> On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah <Micah.Villmow at amd.com>
> wrote:
>> I am hitting this assertion:
>>
>> assert(I != VRBaseMap.end() && "Node emitted out of order - late");
>>
>> I am not sure why this assertion is being triggered or what I changed
> that
>> is causing it.
>>
>> This is asserting when SDValue is FrameIndexSDNode 1.
>>
>> I don't have any code that modified frameindices until my overloaded
>> RegisterInfo function.
>>
>> I've attached the bc file. If I generate an unoptimized bc file then
> there
>> is no issue, only when I turn optimizations on do I hit this problem.
>>
> I got this too. It's related to debug information being in flux right
> now. I believe that Devang is working on a fix for this right now.
>
> -bw
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From yim6 at illinois.edu  Thu Jan 15 16:36:41 2009
From: yim6 at illinois.edu (Keun Soo Yim)
Date: Thu, 15 Jan 2009 16:36:41 -0600
Subject: [LLVMdev] Testcase for OS kernel
Message-ID: <00cc01c97761$bd985560$38c90020$@edu>

 

 Hi,

 

 The source attached at the bottom is a testcase which causes a back-end
error in LLVM 2.4.

 These types of assembly routines are mainly used in OS kernels. 

 I checked that GCC 4.3 works for this routine.

 

 The error messsage is ...

         Couldn't allocate output reg for constraint 'A'!

 

 I just need help or comments so that I could analyze and fix this bug.

 My question is how can we efficiently debug this type of bug?

 

 1. Typically we have a large size of testcase source code. 

 Thus we need to locate the specific location of bug in the testcase source
code.

 Is there any debugging message that LLVM gives to make it easy to identify
this information?

 I don't except that information in source code because that is belong to
GCC front-end

 but what about in terms of LLVM asm code, e.g., line # of LLVM asm code
that generate this error.

 

 2. Then we need to find a code in LLVM that generates this error message.

 But how can I efficiently find that buggy routine in LLVM pass or backend?

 

 Thanks,

 Keun Soo

 

-----

 

/*

 * @title   A Testcase for LLVM

 * 

 * @about   This faces an error with LLVM 2.4 (but not with GCCC)

 *          The error messsage is ...

 *              Couldn't allocate output reg for constraint 'A'!

 * 

 * @author  Keun Soo Yim

 */

 

struct a_struct{

    unsigned int a,b;

};

 

void x()

{

    long err;

    struct a_struct a;

    struct a_struct *pa;

 

    __asm__ __volatile__(

            "1: movl 0(%2),%%eax\n"

            "2: movl 4(%2),%%edx\n"

            "3:\n" ".section .fixup,\"ax\"\n"

            "4: movl %3,%0\n"

            "   xorl %%eax,%%eax\n"

            "   xorl %%edx,%%edx\n"

            "   jmp 3b\n" ".previous\n"

            ".section __ex_table,\"a\"\n"

            "   .align 4\n"

            "   .long 1b,4b\n"

            "   .long 2b,4b\n"

            ".previous" :   "=r" (err),

                            "=&A" (((a)))

                        :   "r" (((pa))),

                            "i"(-14),

                            "0"(err));

}

                                         

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090115/4ee901bf/attachment.html 

From criswell at cs.uiuc.edu  Thu Jan 15 17:23:30 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 15 Jan 2009 17:23:30 -0600
Subject: [LLVMdev] Testcase for OS kernel
In-Reply-To: <00cc01c97761$bd985560$38c90020$@edu>
References: <00cc01c97761$bd985560$38c90020$@edu>
Message-ID: <496FC572.8070304@cs.uiuc.edu>

Keun Soo Yim wrote:
>  Hi,
>
>  The source attached at the bottom is a testcase which causes a back-end error in LLVM 2.4.
>  These types of assembly routines are mainly used in OS kernels.
>  I checked that GCC 4.3 works for this routine.
>
>  The error messsage is ...
>          Couldn't allocate output reg for constraint 'A'!
>
>  I just need help or comments so that I could analyze and fix this bug.
>  My question is how can we efficiently debug this type of bug?
>
>  1. Typically we have a large size of testcase source code.
>  Thus we need to locate the specific location of bug in the testcase source code.
>  Is there any debugging message that LLVM gives to make it easy to identify this information?
>  I don?t except that information in source code because that is belong to GCC front-end
>  but what about in terms of LLVM asm code, e.g., line # of LLVM asm code that generate this error.
>   
Have you used LLVM's bugpoint tool before?  It won't tell you the line
number of the LLVM assembly that's causing the problem, but it can
automatically reduce large test cases to small test cases.  It looks
like the test case you've attached below is pretty small, but if you had
a larger testcase, bugpoint can reduce it for you.
>  2. Then we need to find a code in LLVM that generates this error message.
>  But how can I efficiently find that buggy routine in LLVM pass or backend?
>   
If it's an assertion, you can run the gdb command on the whatever LLVM
tool you're having problems with.  If you run it on the debug version of
the tool, the asserts will break into the debugger, and you can get a
stack trace with source filename and line numbers.

If it's not an assertion, I'd just search through the code for the error
message.  I would use a combination of find/grep to do that:

cd llvm
find . -type f -print | xargs grep -l "Couldn't allocate output reg"

-- John T.

>  Thanks,
>  Keun Soo
>
> -----
>
> /*
>  * @title   A Testcase for LLVM
>  *
>  * @about   This faces an error with LLVM 2.4 (but not with GCCC)
>  *          The error messsage is ...
>  *              Couldn't allocate output reg for constraint 'A'!
>  *
>  * @author  Keun Soo Yim
>  */
>
> struct a_struct{
>     unsigned int a,b;
> };
>
> void x()
> {
>     long err;
>     struct a_struct a;
>     struct a_struct *pa;
>
>     __asm__ __volatile__(
>             "1: movl 0(%2),%%eax\n"
>             "2: movl 4(%2),%%edx\n"
>             "3:\n" ".section .fixup,\"ax\"\n"
>             "4: movl %3,%0\n"
>             "   xorl %%eax,%%eax\n"
>             "   xorl %%edx,%%edx\n"
>             "   jmp 3b\n" ".previous\n"
>             ".section __ex_table,\"a\"\n"
>             "   .align 4\n"
>             "   .long 1b,4b\n"
>             "   .long 2b,4b\n"
>             ".previous" :   "=r" (err),
>                             "=&A" (((a)))
>                         :   "r" (((pa))),
>                             "i"(-14),
>                             "0"(err));
> }
>
>
>   




From Micah.Villmow at amd.com  Thu Jan 15 17:26:03 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Thu, 15 Jan 2009 15:26:03 -0800
Subject: [LLVMdev] Hitting assertion, unsure why
In-Reply-To: <16e5fdf90901151426n4f4390c8rcabf516e00f95647@mail.gmail.com>
References: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2B@ssanexmb1.amd.com><16e5fdf90901151407k6c94e652y3c8620e38b5d7c6@mail.gmail.com><5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2E@ssanexmb1.amd.com>
	<16e5fdf90901151426n4f4390c8rcabf516e00f95647@mail.gmail.com>
Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF57@ssanexmb1.amd.com>

This did not seem to work, any other ideas?

Thanks,

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Bill Wendling
Sent: Thursday, January 15, 2009 2:26 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Hitting assertion, unsure why

Don't generate debug info at this time (you can use "opt
-strip-debug")? :-) Otherwise, I'm not sure.

-bw

On Thu, Jan 15, 2009 at 2:20 PM, Villmow, Micah <Micah.Villmow at amd.com>
wrote:
> Is there any known method/hack of bypassing this?
>
> Thanks,
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Bill Wendling
> Sent: Thursday, January 15, 2009 2:07 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Hitting assertion, unsure why
>
> On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah
<Micah.Villmow at amd.com>
> wrote:
>> I am hitting this assertion:
>>
>> assert(I != VRBaseMap.end() && "Node emitted out of order - late");
>>
>> I am not sure why this assertion is being triggered or what I changed
> that
>> is causing it.
>>
>> This is asserting when SDValue is FrameIndexSDNode 1.
>>
>> I don't have any code that modified frameindices until my overloaded
>> RegisterInfo function.
>>
>> I've attached the bc file. If I generate an unoptimized bc file then
> there
>> is no issue, only when I turn optimizations on do I hit this problem.
>>
> I got this too. It's related to debug information being in flux right
> now. I believe that Devang is working on a fix for this right now.
>
> -bw
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




From isanbard at gmail.com  Thu Jan 15 17:32:12 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Thu, 15 Jan 2009 15:32:12 -0800
Subject: [LLVMdev] Hitting assertion, unsure why
In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF57@ssanexmb1.amd.com>
References: <5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2B@ssanexmb1.amd.com>
	<16e5fdf90901151407k6c94e652y3c8620e38b5d7c6@mail.gmail.com>
	<5BA674C5FF7B384A92C2C95D8CC71E1C6DAF2E@ssanexmb1.amd.com>
	<16e5fdf90901151426n4f4390c8rcabf516e00f95647@mail.gmail.com>
	<5BA674C5FF7B384A92C2C95D8CC71E1C6DAF57@ssanexmb1.amd.com>
Message-ID: <16e5fdf90901151532y5a7f31a6w3c82a8eaf862651c@mail.gmail.com>

Other than not using debugging ('-g' and the like), not really. :-( I
think that Devang is actively working on fixing this, though. It might
not be too much longer.

-bw

On Thu, Jan 15, 2009 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> This did not seem to work, any other ideas?
>
> Thanks,
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Bill Wendling
> Sent: Thursday, January 15, 2009 2:26 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Hitting assertion, unsure why
>
> Don't generate debug info at this time (you can use "opt
> -strip-debug")? :-) Otherwise, I'm not sure.
>
> -bw
>
> On Thu, Jan 15, 2009 at 2:20 PM, Villmow, Micah <Micah.Villmow at amd.com>
> wrote:
>> Is there any known method/hack of bypassing this?
>>
>> Thanks,
>>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
>> On Behalf Of Bill Wendling
>> Sent: Thursday, January 15, 2009 2:07 PM
>> To: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] Hitting assertion, unsure why
>>
>> On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah
> <Micah.Villmow at amd.com>
>> wrote:
>>> I am hitting this assertion:
>>>
>>> assert(I != VRBaseMap.end() && "Node emitted out of order - late");
>>>
>>> I am not sure why this assertion is being triggered or what I changed
>> that
>>> is causing it.
>>>
>>> This is asserting when SDValue is FrameIndexSDNode 1.
>>>
>>> I don't have any code that modified frameindices until my overloaded
>>> RegisterInfo function.
>>>
>>> I've attached the bc file. If I generate an unoptimized bc file then
>> there
>>> is no issue, only when I turn optimizations on do I hit this problem.
>>>
>> I got this too. It's related to debug information being in flux right
>> now. I believe that Devang is working on a fix for this right now.
>>
>> -bw
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From snaroff at apple.com  Thu Jan 15 17:59:20 2009
From: snaroff at apple.com (steve naroff)
Date: Thu, 15 Jan 2009 15:59:20 -0800
Subject: [LLVMdev] [cfe-dev]  win32/llvm.sln, win32/clang.sln
In-Reply-To: <009c01c976f2$5d972700$18c57500$@net>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<009c01c976f2$5d972700$18c57500$@net>
Message-ID: <CE1595EB-4629-46A0-9E9B-3A07C8D5CB0F@apple.com>


On Jan 15, 2009, at 1:19 AM, Nicolas Capens wrote:

> Hi Steve,
>
> The Visual Studio solution and project files are quite handy. CMake  
> creates
> absolute paths instead of relative paths, making it cumbersome to move
> things around. Also, for newcomers (e.g. students) it's really great  
> to be
> able to download the package, open the solution and compile without  
> any
> complication.
>

Understood, however the (unfortunate) reality is the VS solution file  
is not being properly maintained. As a result, any newcomer/developer  
is faced with updating the VS solution file (or not building at all).

Over the past 6 months, I've had to personally fix many problems with  
the solution file. That said, I'm grateful that cmake works and the  
cmake.txt files are being updated/maintained. It does require an extra  
step, however the work is "constant time" (whereas fixing regressions  
without cmake could take an arbitrary amount of time).

Thanks for your response...

snaroff

> They haven't been updated in a while, but it would be nice to have  
> working
> ones in the 2.5 release...

> Cheers,
>
> Nicolas
>
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- 
> bounces at cs.uiuc.edu] On
> Behalf Of steve naroff
> Sent: donderdag 15 januari 2009 1:09
> To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
> Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln
>
> Folks,
>
> Is anyone still using the Visual Studio solution files in the win32
> directory?
>
> If they aren't being maintained, they should probably be removed (to
> avoid any confusion).
>
> Thanks for any feedback,
>
> snaroff
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From tonic at nondot.org  Thu Jan 15 19:19:03 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Thu, 15 Jan 2009 17:19:03 -0800 (PST)
Subject: [LLVMdev] Volunteers needed for LLVM Release Team
Message-ID: <Pine.LNX.4.62.0901151702380.22363@nondot.org>

LLVMers,

As LLVM grows and begins to support more targets and more frontends, its 
becoming a very large task to qualify a release. Therefore, I'm seeking a 
couple of active members of the community to volunteer to be a part of the 
LLVM release team (for 2.6+). This does not replace general user testing 
during the release process.

Members of this LLVM Release Team will need to be very meticulous in 
following instructions for release building and testing. They need to be 
consistent, reliable, and have an eye for detail. They will also need to 
be able to dedicate time to qualify a release every 3-4 months. 
Qualification can take as little as a day, but can also take 1-2 weeks. 
Each release has a minimum of 2 release candidates and takes a minimum of 
1 month to complete a release. I will provide instructions on how to 
qualify the releases initially, but this process can evolve over time with 
input from the release team.

Ideally, I'd like to have a volunteer for each target that we have 
traditionally supported and those in active use/development.  If you see a 
target that you would like to volunteer to qualify not listed here, please 
let me know.

1) Mac OS 10.5 x86 (I will qualify this target)
2) Mac OS 10.5 PPC
3) Linux x86
4) Mingw x86 (Anton do you want to continue this?)
5) Linux AMD64

If you are interested in being a part of this team, please send me an 
email with information about yourself, what target you want to own for 
releases, and why you want to be a part of the release team.

I hope to have this team in place for the 2.6 release (~Apr/May/Jun).

Thanks,
Tanya Lattner

From gohman at apple.com  Thu Jan 15 20:11:52 2009
From: gohman at apple.com (Dan Gohman)
Date: Thu, 15 Jan 2009 18:11:52 -0800
Subject: [LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)
In-Reply-To: <200901150950.31241.brandner@complang.tuwien.ac.at>
References: <4d77c5f20901140558v7332be81j8f7a90fb67183a39@mail.gmail.com>
	<496E27E7.2050203@complang.tuwien.ac.at>
	<200901150950.31241.brandner@complang.tuwien.ac.at>
Message-ID: <B9AB782D-F8EF-4D7D-BC35-2CD355DC69A5@apple.com>


On Jan 15, 2009, at 12:50 AM, Brandner wrote:

> On Wednesday 14 January 2009 18:59:03 Brandner Florian wrote:
>> I have a patch against llvm 2.4 that fixes this issue, but did not  
>> have
>> the time to post the patch here. I'll do so by tomorrow.
>
> here is the patch, still against llvm 2.4. I had a short look on  
> trunk, but it
> seems that there are several conflicts. Maybe a tablgen expert  
> should have a
> look at this - I also do not know if there are changes needed for the
> FastISelEmitter.
>
> I hope this is a starting point for you,
> florian
>
> ps: We have a working compiler here that relies on these changes, so  
> it does
> not seem to break anything, at least for our private backend.


Hi Florian,

Thanks for the patch! I applied the parts of the patch that rename the
CPTmp variables:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090112/072209.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090112/072210.html

However, I didn't apply this part:

-      if (InstPatNode && InstPatNode->getOperator()->getName() ==  
"set") {
+      if (InstPatNode && !InstPatNode->isLeaf() &&
+          InstPatNode->getOperator()->getName() == "set") {

because I'm unsure what it's for. When is a "set" node a leaf?

BTW, the FastISelEmitter should be ignoring any instructions that
have ComplexPatterns, so there shouldn't be a problem there. Also,
it's only enabled for x86 right now.

Dan


From ofv at wanadoo.es  Thu Jan 15 22:11:32 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Fri, 16 Jan 2009 05:11:32 +0100
Subject: [LLVMdev] [cfe-dev] Testing and CMake
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
	<m3ab9szfih.fsf@telefonica.net>
	<14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>
	<m31vv4zclh.fsf_-_@telefonica.net>
	<638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>
	<m3sknkxsqc.fsf@telefonica.net>
	<BBC04B4D-FC99-4605-945C-48BC75CA3485@apple.com>
Message-ID: <m3k58vyjnv.fsf@telefonica.net>

steve naroff <snaroff at apple.com> writes:

>> Can you describe on which scenario do you require to move around build
>> trees?
>
> Sure...

[explanation snipped]

> Thanks for any help with this,

If you require this for VS only, the

set(CMAKE_USE_RELATIVE_PATHS ON)

trick mentioned on this thread may work, as Windows in general and the
LLVM project files in particular doesn't use absolute paths as much as
the POSIX platforms do (for RPATH, executing external commands,
etc). Please give it a try.

If there are absolute paths remaining on the VS project files, they may
be the result of generating them in the LLVM CMake files with the
`abspath' operator, or could come from CMake built-in variables that
default to the absolute form. We could see if those could be replaced by
relative paths.

-- 
Oscar


From Sanjiv.Gupta at microchip.com  Thu Jan 15 22:35:12 2009
From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com)
Date: Thu, 15 Jan 2009 21:35:12 -0700
Subject: [LLVMdev] PIC16 backend for llvm 2.5
In-Reply-To: <200901091253.24536.baldrick@free.fr>
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
	<200901081611.02513.baldrick@free.fr>
	<F536B7C316F9474E9F7091239725AC9A4E900B@CHN-CL-MAIL01.mchp-main.com>
	<200901091253.24536.baldrick@free.fr>
Message-ID: <F536B7C316F9474E9F7091239725AC9A01D76884@CHN-CL-MAIL01.mchp-main.com>



> -----Original Message-----
> From: Duncan Sands [mailto:baldrick at free.fr]
> Sent: Friday, January 09, 2009 5:23 PM
> To: Sanjiv Kumar Gupta - I00171
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: PIC16 backend for llvm 2.5
> 
> Hi Sanjiv,
> 
> > Well, the first email is here.
> >
> > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-
> 20081013/068667.html
> 
> thanks, I remember now (more or less).  So would something like
> ReplaceNodeResults
> solve the problem?
> 

Well the magnitude of the task is not small.
ExpandIntegerOperand() calls LowerOperation() to allow targets to handle
illegal operands. So we will need to change the interface of
LowerOperation() to pass an extra argument called Results, which is an
array of SDValue. Targets will push the result values in this array and
then we can replace values in ExpandIntegerOperand(). Very much like
what CustomLowerResults() and ReplaceNodeResults() are doing currently.

The problem is that do we want to change calls to LowerOperation() in
LegalizeDAG as well? I think probably that is the right approach to go
in the longer term. But currently I suggest that "Results" be the last
argument to LowerOperation() which is defaulted to NULL. That way
LegalizeDAG and all targets will continue to work the current way, plus
targets like ours that want to use the last argument (i.e. "Results")
can use them in ExapndIntegerOperand().

Let me know if that sounds okay.

Regards,
Sanjiv

> Ciao,
> 
> Duncan.


From andrewl at lenharth.org  Thu Jan 15 23:18:33 2009
From: andrewl at lenharth.org (Andrew Lenharth)
Date: Thu, 15 Jan 2009 23:18:33 -0600
Subject: [LLVMdev] Testcase for OS kernel
In-Reply-To: <00cc01c97761$bd985560$38c90020$@edu>
References: <00cc01c97761$bd985560$38c90020$@edu>
Message-ID: <85dfcd7f0901152118j2e7f88a3offa7df61b22ca8c9@mail.gmail.com>

On Thu, Jan 15, 2009 at 4:36 PM, Keun Soo Yim <yim6 at illinois.edu> wrote:
>  The source attached at the bottom is a testcase which causes a back-end
> error in LLVM 2.4.
>
>  These types of assembly routines are mainly used in OS kernels.
>
>  I checked that GCC 4.3 works for this routine.
>
>
>
>  The error messsage is ...
>
>          Couldn't allocate output reg for constraint 'A'!

This has been fixed in 2.5.
http://llvm.org/bugs/show_bug.cgi?id=3045
http://llvm.org/bugs/show_bug.cgi?id=1779

Andrew

From brandner at complang.tuwien.ac.at  Fri Jan 16 01:34:09 2009
From: brandner at complang.tuwien.ac.at (Brandner)
Date: Fri, 16 Jan 2009 08:34:09 +0100
Subject: [LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)
In-Reply-To: <B9AB782D-F8EF-4D7D-BC35-2CD355DC69A5@apple.com>
References: <4d77c5f20901140558v7332be81j8f7a90fb67183a39@mail.gmail.com>
	<200901150950.31241.brandner@complang.tuwien.ac.at>
	<B9AB782D-F8EF-4D7D-BC35-2CD355DC69A5@apple.com>
Message-ID: <200901160834.10459.brandner@complang.tuwien.ac.at>

Hi Dan,

thank you for applying the patch.

> However, I didn't apply this part:
>
> -      if (InstPatNode && InstPatNode->getOperator()->getName() ==
> "set") {
> +      if (InstPatNode && !InstPatNode->isLeaf() &&
> +          InstPatNode->getOperator()->getName() == "set") {
>
> because I'm unsure what it's for. When is a "set" node a leaf?

exactly it never is, however InstPatNode may well be a leaf. in that case 
calling getOperator is not valid, because it asserts on !isLeaf:

Record *getOperator() const { assert(!isLeaf()); return Operator; }

so this check definitely should be there. but it is true, i should have split 
the patch into two pieces as it is not related to the ComplexPattern issue. 
sorry for that.

florian



From spellegrini at dps.uibk.ac.at  Fri Jan 16 02:36:55 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Fri, 16 Jan 2009 09:36:55 +0100
Subject: [LLVMdev] LLVM + OpenAnalysis
Message-ID: <49704727.9000204@dps.uibk.ac.at>

Hello everybody,
I am currently looking at the LLVM project to find if it is suitable for 
what I have in mind. My research consists in optimization of parallel 
applications (mainly MPI and OpenMP) via transformations. What I need is 
the possibility to analyze and optimize production programs written in 
C/C++ and Fortran.

So, I've been looking inside a lot of source-to-source compilers (like 
ROSE) but as far as it's a 100% research project, it is really not ready 
to be used with production code. :(  On the other hand another approach 
could be use LLVM... and apply the transformations directly at bytecode 
level. This second way  is quite interesting and gives me a lot of 
advantages (like the ability to take into account several languages)... 
but I need stronger program analysis.

It would nice if I could use LLVM bytecode with OpenAnalysis 
(http://openanalysis.berlios.de/). I know that some people worked on 
this aspect (LLVM - OA integration) but I cannot find anything on the 
internet about that. So I am asking to you... GURUs of the Low Level 
Virtual Machines... can you give me some pointers to this integration?

regards, Simone Pellegrini

From baldrick at free.fr  Fri Jan 16 03:03:34 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 16 Jan 2009 10:03:34 +0100
Subject: [LLVMdev] PIC16 backend for llvm 2.5
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A01D76884@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
	<200901091253.24536.baldrick@free.fr>
	<F536B7C316F9474E9F7091239725AC9A01D76884@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <200901161003.35470.baldrick@free.fr>

Hi Sanjiv,

> Well the magnitude of the task is not small.
> ExpandIntegerOperand() calls LowerOperation() to allow targets to handle
> illegal operands. So we will need to change the interface of
> LowerOperation() to pass an extra argument called Results, which is an
> array of SDValue. Targets will push the result values in this array and
> then we can replace values in ExpandIntegerOperand(). Very much like
> what CustomLowerResults() and ReplaceNodeResults() are doing currently.
> 
> The problem is that do we want to change calls to LowerOperation() in
> LegalizeDAG as well? I think probably that is the right approach to go
> in the longer term. But currently I suggest that "Results" be the last
> argument to LowerOperation() which is defaulted to NULL. That way
> LegalizeDAG and all targets will continue to work the current way, plus
> targets like ours that want to use the last argument (i.e. "Results")
> can use them in ExapndIntegerOperand().

do you need this for operation legalization (LegalizeDAG) as well as
type legalization?  If not, then you can introduce a new method like
ReplaceNodeResults for custom type legalization of operands (or just
use ReplaceNodeResults for this too - I don't immediately see any
reason why not), and have it call LowerOperation by default.  Actually,
if you also want this for LegalizeDAG too, you can introduce a new method
which is only called in places that need it; everywhere else can still
use LowerOperation (of course in the long term there should be just one
method, but this way you can do things incrementally).  I don't much
like the idea of having Results be NULL.  I'd rather the interface was
uniform, and have any tricks be in the body of the method.

Ciao,

Duncan.

From abh.spark at gmail.com  Fri Jan 16 04:32:47 2009
From: abh.spark at gmail.com (abhishek Singh)
Date: Fri, 16 Jan 2009 16:02:47 +0530
Subject: [LLVMdev] Problem using ilist container
Message-ID: <6ac719070901160232j5315ddbcsefc4fda0227764fa@mail.gmail.com>

Hi All,
I have just started using LLVM .
i am facing a issue while using ilist container.

Here is a struct with ilist container as its one element.

typedef ilist<Instruction *> InstListType;
              struct list_node {
                                    int Impact;
                                    InstListType  InstList;

                                   };
list_node *BB_list=new struct list_node[10];
Instruction *user= { pointing to some instruction object }

//trying to add instruction pointer to ilist.
// this is where i am getting error. ( please find error file attached).

BB_list[index].InstList.push_back(user);

Any thoughts on what's causing this error??


 Thanks,
Abhishek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090116/18390546/attachment.html 
-------------- next part --------------
/usr/local/llvm/src/include/llvm/ADT/ilist.h: In static member function 'static NodeTy* llvm::ilist_nextprev_traits<NodeTy>::getPrev(NodeTy*) [with NodeTy = llvm::Instruction*]':
/usr/local/llvm/src/include/llvm/ADT/ilist.h:268:   instantiated from 'NodeTy* llvm::iplist<NodeTy, Traits>::getTail() [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:306:   instantiated from 'llvm::iplist<NodeTy, Traits>::~iplist() [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:574:   instantiated from here
/usr/local/llvm/src/include/llvm/ADT/ilist.h:55: error: request for member 'getPrev' in '* N', which is of non-class type 'llvm::Instruction*'
/usr/local/llvm/src/include/llvm/ADT/ilist.h: In static member function 'static void llvm::ilist_nextprev_traits<NodeTy>::setNext(NodeTy*, NodeTy*) [with NodeTy = llvm::Instruction*]':
/usr/local/llvm/src/include/llvm/ADT/ilist.h:277:   instantiated from 'void llvm::iplist<NodeTy, Traits>::CreateLazySentinal() const [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:319:   instantiated from 'llvm::ilist_iterator<NodeTy> llvm::iplist<NodeTy, Traits>::end() [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:609:   instantiated from 'void llvm::ilist<NodeTy>::push_back(const NodeTy&) [with NodeTy = llvm::Instruction*]'
jImpact.cpp:75:   instantiated from here
/usr/local/llvm/src/include/llvm/ADT/ilist.h:61: error: request for member 'setNext' in '* N', which is of non-class type 'llvm::Instruction*'
/usr/local/llvm/src/include/llvm/ADT/ilist.h: In static member function 'static void llvm::ilist_nextprev_traits<NodeTy>::setPrev(NodeTy*, NodeTy*) [with NodeTy = llvm::Instruction*]':
/usr/local/llvm/src/include/llvm/ADT/ilist.h:270:   instantiated from 'void llvm::iplist<NodeTy, Traits>::setTail(NodeTy*) const [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:278:   instantiated from 'void llvm::iplist<NodeTy, Traits>::CreateLazySentinal() const [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:319:   instantiated from 'llvm::ilist_iterator<NodeTy> llvm::iplist<NodeTy, Traits>::end() [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:609:   instantiated from 'void llvm::ilist<NodeTy>::push_back(const NodeTy&) [with NodeTy = llvm::Instruction*]'
jImpact.cpp:75:   instantiated from here
/usr/local/llvm/src/include/llvm/ADT/ilist.h:60: error: request for member 'setPrev' in '* N', which is of non-class type 'llvm::Instruction*'
/usr/local/llvm/src/include/llvm/ADT/ilist.h: In static member function 'static NodeTy* llvm::ilist_nextprev_traits<NodeTy>::getNext(NodeTy*) [with NodeTy = llvm::Instruction*]':
/usr/local/llvm/src/include/llvm/ADT/ilist.h:379:   instantiated from 'NodeTy* llvm::iplist<NodeTy, Traits>::remove(llvm::ilist_iterator<NodeTy>&) [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:407:   instantiated from 'llvm::ilist_iterator<NodeTy> llvm::iplist<NodeTy, Traits>::erase(llvm::ilist_iterator<NodeTy>) [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:479:   instantiated from 'llvm::ilist_iterator<NodeTy> llvm::iplist<NodeTy, Traits>::erase(llvm::ilist_iterator<NodeTy>, llvm::ilist_iterator<NodeTy>) [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:483:   instantiated from 'void llvm::iplist<NodeTy, Traits>::clear() [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:305:   instantiated from 'llvm::iplist<NodeTy, Traits>::~iplist() [with NodeTy = llvm::Instruction*, Traits = llvm::ilist_traits<llvm::Instruction*>]'
/usr/local/llvm/src/include/llvm/ADT/ilist.h:574:   instantiated from here
/usr/local/llvm/src/include/llvm/ADT/ilist.h:56: error: request for member 'getNext' in '* N', which is of non-class type 'llvm::Instruction*'
gmake: *** [/usr/local/llvm/src/lib/jimp/Release/jImpact.lo] Error 1

From anton at korobeynikov.info  Fri Jan 16 05:07:40 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Fri, 16 Jan 2009 14:07:40 +0300
Subject: [LLVMdev] Problem using ilist container
In-Reply-To: <6ac719070901160232j5315ddbcsefc4fda0227764fa@mail.gmail.com>
References: <6ac719070901160232j5315ddbcsefc4fda0227764fa@mail.gmail.com>
Message-ID: <b087fca00901160307l393e9584r632f3bf5ddbe6436@mail.gmail.com>

Hello,

> i am facing a issue while using ilist container.
ilist is an internal container, you should not use it directly. Please
consider reading llvm documentation about how to add / modify
instructions.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From anton at korobeynikov.info  Fri Jan 16 05:15:03 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Fri, 16 Jan 2009 14:15:03 +0300
Subject: [LLVMdev] Volunteers needed for LLVM Release Team
In-Reply-To: <Pine.LNX.4.62.0901151702380.22363@nondot.org>
References: <Pine.LNX.4.62.0901151702380.22363@nondot.org>
Message-ID: <b087fca00901160315xcbc0e83k7e0769a84ddb6dea@mail.gmail.com>

Hello, Tanya

> 4) Mingw x86 (Anton do you want to continue this?)
Yes, I'm still going to prepare llvm-gcc mingw32 images. However, the
testing procedure for mingw is slightly different due to lack of
dejagnu stuff. However, I have plans to fix the main LLVM testsuite to
be more mingw32-friendly :)

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From lennart at augustsson.net  Fri Jan 16 05:37:28 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Fri, 16 Jan 2009 11:37:28 +0000
Subject: [LLVMdev] Volunteers needed for LLVM Release Team
In-Reply-To: <b087fca00901160315xcbc0e83k7e0769a84ddb6dea@mail.gmail.com>
References: <Pine.LNX.4.62.0901151702380.22363@nondot.org>
	<b087fca00901160315xcbc0e83k7e0769a84ddb6dea@mail.gmail.com>
Message-ID: <f4876cd70901160337w67b55414g31af80e31883ef75@mail.gmail.com>

I noticed that the mingw release only contains binaries and not
libraries nor header files.
I think it would be nice if the mingw release contained the same files
as the other releases.
This would mean that people who want to use LLVM with the Haskell
bindings on Windows don't have to build and install LLVM (first
installing mingw), but they could just download binaries and install
those.

  -- Lennart

On Fri, Jan 16, 2009 at 11:15 AM, Anton Korobeynikov
<anton at korobeynikov.info> wrote:
> Hello, Tanya
>
>> 4) Mingw x86 (Anton do you want to continue this?)
> Yes, I'm still going to prepare llvm-gcc mingw32 images. However, the
> testing procedure for mingw is slightly different due to lack of
> dejagnu stuff. However, I have plans to fix the main LLVM testsuite to
> be more mingw32-friendly :)
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From patrick.boettcher at desy.de  Fri Jan 16 07:14:09 2009
From: patrick.boettcher at desy.de (Patrick Boettcher)
Date: Fri, 16 Jan 2009 14:14:09 +0100 (CET)
Subject: [LLVMdev] [cfe-dev] Testing and CMake
In-Reply-To: <m3wscwxsub.fsf@telefonica.net>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl>
	<m3ab9szfih.fsf@telefonica.net>
	<14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com>
	<m31vv4zclh.fsf_-_@telefonica.net>
	<638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com>
	<alpine.LRH.1.10.0901151942330.28478@pub2.ifh.de>
	<m3wscwxsub.fsf@telefonica.net>
Message-ID: <alpine.LRH.1.10.0901161410140.28478@pub2.ifh.de>

Hi,

On Thu, 15 Jan 2009, ?scar Fuentes wrote:
> Hmmm...
>
>  CMAKE_USE_RELATIVE_PATHS
>       Use relative paths (May not work!).
>
>       If this is set to TRUE, then the CMake will use relative paths between
>       the source and binary tree.  This option does not work for more
>       complicated projects, and relative paths are used when possible.  In
>       general, it is not possible to move CMake generated makefiles to a
>       different location regardless of the value of this variable.

I have seen those warnings as well, but it works and it solves the problem 
of having portable vcprof-file which was generated. (that what I thought 
was one of the questions in that thread)

>> In addition we are setting
>>
>> set(CMAKE_SUPPRESS_REGENERATION ON)
>>
>> in order to not have a dependency on the CMakeLists when creating the
>> vcproj-file.
>
> This looks like asking for trouble. Why are you doing this?

To generate an independent vcproj-file from a CMakeFile. Here, we don't 
want/can't send the CMakeLists.txt to the other users and force them to 
use Cmake. They are expecting a vcproj-file. Using it this way simplifies 
my life of having only one build system for Linux/Windows...

Patrick.

From anton at korobeynikov.info  Fri Jan 16 07:21:19 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Fri, 16 Jan 2009 16:21:19 +0300
Subject: [LLVMdev] Volunteers needed for LLVM Release Team
In-Reply-To: <f4876cd70901160337w67b55414g31af80e31883ef75@mail.gmail.com>
References: <Pine.LNX.4.62.0901151702380.22363@nondot.org>
	<b087fca00901160315xcbc0e83k7e0769a84ddb6dea@mail.gmail.com>
	<f4876cd70901160337w67b55414g31af80e31883ef75@mail.gmail.com>
Message-ID: <b087fca00901160521r68f739f2g3c9f857308fc9019@mail.gmail.com>

Hello,

> I noticed that the mingw release only contains binaries and not
> libraries nor header files.
That's correct, because headers will contain, for example, absolute
paths from the box I've built the libraries on (mostly in config.h and
llvm-config script). I won't provide neither libraries nor headers,
since I don't know how to make them 'path-neutral' without much hand
work.

> This would mean that people who want to use LLVM with the Haskell
> bindings on Windows don't have to build and install LLVM (first
> installing mingw), but they could just download binaries and install
> those.
I don't understand. If you want to use libraries / headers - then you
will need a compiler anyway. Why not spent few dozens minutes to build
LLVM?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From lennart at augustsson.net  Fri Jan 16 07:59:10 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Fri, 16 Jan 2009 13:59:10 +0000
Subject: [LLVMdev] Volunteers needed for LLVM Release Team
In-Reply-To: <b087fca00901160521r68f739f2g3c9f857308fc9019@mail.gmail.com>
References: <Pine.LNX.4.62.0901151702380.22363@nondot.org>
	<b087fca00901160315xcbc0e83k7e0769a84ddb6dea@mail.gmail.com>
	<f4876cd70901160337w67b55414g31af80e31883ef75@mail.gmail.com>
	<b087fca00901160521r68f739f2g3c9f857308fc9019@mail.gmail.com>
Message-ID: <f4876cd70901160559n4bd2c298sc3ed8823d1c3549a@mail.gmail.com>

Hi,

You don't need to install a C compiler to use LLVM from Haskell.
The ghc Haskell compiler comes with all the necessary bits to build
binaries (which happens to include a (hidden) GNU tool chain).
The header files are barely needed at all, just the include/llvm-c/*.h
files to pick up some enum values.  config.h and llvm-config are not
used at all.
The .a files are needed to link everything together.

If llvm.org is not going to put up header and library files then I'll
put them somewhere myself so as to make installation smooth for
Haskell users on Windows.

  -- Lennart


On Fri, Jan 16, 2009 at 1:21 PM, Anton Korobeynikov
<anton at korobeynikov.info> wrote:
> Hello,
>
>> I noticed that the mingw release only contains binaries and not
>> libraries nor header files.
> That's correct, because headers will contain, for example, absolute
> paths from the box I've built the libraries on (mostly in config.h and
> llvm-config script). I won't provide neither libraries nor headers,
> since I don't know how to make them 'path-neutral' without much hand
> work.
>
>> This would mean that people who want to use LLVM with the Haskell
>> bindings on Windows don't have to build and install LLVM (first
>> installing mingw), but they could just download binaries and install
>> those.
> I don't understand. If you want to use libraries / headers - then you
> will need a compiler anyway. Why not spent few dozens minutes to build
> LLVM?
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From prakash.prabhu at gmail.com  Fri Jan 16 10:28:04 2009
From: prakash.prabhu at gmail.com (Prakash Prabhu)
Date: Fri, 16 Jan 2009 11:28:04 -0500
Subject: [LLVMdev] poolallocation error
In-Reply-To: <577C4E7D-1571-446B-9C3B-7B39308159E1@liacs.nl>
References: <577C4E7D-1571-446B-9C3B-7B39308159E1@liacs.nl>
Message-ID: <85a4cc050901160828q33b0d142yf8d17780bf167fc6@mail.gmail.com>

Hi all,

I too am getting this error for x86_64 when I am trying to use the
Data Structure Analysis ...I svn upped both the llvm main branch and
the poolalloc today in the morning and recompiled everything from
scratch :

$ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libpoolalloc.so
-ds-aa < o.bc

opt: /home/pprabhu/llvm/llvm/lib/VMCore/PassManager.cpp:1418: virtual
void llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
llvm::Pass*): Assertion `(P->getPotentialPassManagerType() <
RequiredPass->getPotentialPassManagerType()) && "Unable to handle Pass
that requires lower level Analysis pass"' failed.
0   opt       0x0000000000a3fcd0
1   opt       0x0000000000a40024
2   libc.so.6 0x00007f9fc318a100
3   libc.so.6 0x00007f9fc318a095 gsignal + 53
4   libc.so.6 0x00007f9fc318baf0 abort + 272
5   libc.so.6 0x00007f9fc31832df __assert_fail + 239
6   opt       0x00000000009caeac
llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
llvm::Pass*) + 252
7   opt       0x00000000009cbe53 llvm::PMDataManager::add(llvm::Pass*,
bool) + 899
8   opt       0x00000000009cc296
llvm::ModulePass::assignPassManager(llvm::PMStack&,
llvm::PassManagerType) + 132
9   opt       0x00000000009d5ff9
llvm::PassManagerImpl::addTopLevelPass(llvm::Pass*) + 227
10  opt       0x00000000009cad7e
llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 500
11  opt       0x00000000009d6118 llvm::PassManagerImpl::add(llvm::Pass*) + 36
12  opt       0x00000000009cada7 llvm::PassManager::add(llvm::Pass*) + 33
13  opt       0x00000000006e5cd3
14  opt       0x00000000006e7a6d main + 3237
15  libc.so.6 0x00007f9fc31761c4 __libc_start_main + 244
16  opt       0x00000000006d7c19 __gxx_personality_v0 + 721
Aborted


Is there something that I am missing on the command line ? Does anyone
use DSA actively now ?

Thanks for your time.

- Prakash

On Wed, Nov 19, 2008 at 8:59 AM, Mattias Holm <holm at liacs.nl> wrote:
> Hi,
>
> I am trying to use the poolallocator. More specific, I am trying to
> play around with the pointer compression pass. Though, I get assertion
> failures for the pass dependencies.
>
> This is when it in PointerCompress::getAnalysisUsage tries to register
> the the BU pass as required. I.e. when
> AU.addRequired<CompleteBUDataStructures>(); is called.
>
>
> $ opt -f -load ~/Projects/llvmstuff/opt/poolalloc/lib/
> libpoolalloc.dylib -raiseallocs -poolalloc-passing-all-pools -
> pointercompress llist-noopt.bc -o llist-dp.bc
>
> Assertion failed: ((P->getPotentialPassManagerType() < RequiredPass-
>  >getPotentialPassManagerType()) && "Unable to handle Pass that
> requires lower level Analysis pass"), function
> addLowerLevelRequiredPass, file ~/Projects/llvmstuff/llvm/lib/VMCore/
> PassManager.cpp, line 1418.
>
> Any ideas what is going wrong here?
>
>
> /Mattias
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From pcwalton at cs.ucla.edu  Fri Jan 16 11:22:18 2009
From: pcwalton at cs.ucla.edu (Patrick Walton)
Date: Fri, 16 Jan 2009 09:22:18 -0800
Subject: [LLVMdev] X86-64 exception issue
Message-ID: <4970C24A.4070206@cs.ucla.edu>

Hi,

I'd like to try tackling the x86-64 exception handling bug (#3214), 
since it's essentially the one thing preventing D from working on 
x86-64. I noticed that Anton among others have done some work on it, so 
I thought I would ask to see what information they or anyone else might 
have on the problem.

Thanks,
Patrick

From jay.foad at gmail.com  Fri Jan 16 11:55:23 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Fri, 16 Jan 2009 17:55:23 +0000
Subject: [LLVMdev] cygwin mmap problem
Message-ID: <ee2e06e90901160955g10e65ddfr625027f53fb81c9f@mail.gmail.com>

A "heads up": if you build LLVM on cygwin, the mmap problem discussed here:

http://www.cygwin.com/ml/cygwin/2009-01/msg00501.html

can crash llc:

$ dd bs=1080K count=1 if=/dev/random of=x.bc
1+0 records in
1+0 records out
1105920 bytes (1.1 MB) copied, 0.167 s, 6.6 MB/s
$ llc x.bc
  17418 [main] llc 3596 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)
Segmentation fault (core dumped)

The problem is that MemoryBuffer::getFile() uses getpagesize() to
determine whether it's OK to mmap() a file, but on cygwin mmap()
doesn't really obey the page size returned by getpagesize().

In my local LLVM tree I've worked around this in
sys::Process::getPageSize(), returning a hard-coded value of 4096
instead of calling getpagesize(). (Maybe it would be better to work
around it in MemoryBuffer::getFile() instead; I'm not sure.)

Jay.

From makslane at hotmail.com  Fri Jan 16 05:19:36 2009
From: makslane at hotmail.com (=?Windows-1252?Q?Makslane_Ara=FAjo_Rodrigues?=)
Date: Fri, 16 Jan 2009 14:19:36 +0300
Subject: [LLVMdev] [cfe-dev] win32/llvm.sln, win32/clang.sln
In-Reply-To: <m3ab9szfih.fsf@telefonica.net>
References: <AD4B6D98-C23A-4A25-A33B-0CE861AD81B1@apple.com>
	<COL106-W317196965D359213B5C8A1DDD70@phx.gbl> 
	<m3ab9szfih.fsf@telefonica.net>
Message-ID: <COL106-W199106BA4D9721336C607ADDD40@phx.gbl>


I didn't know about cmake and llvm! I will try it, thanks!

Regards,
Makslane

> To: cfe-dev at cs.uiuc.edu
> From: ofv at wanadoo.es
> Date: Thu, 15 Jan 2009 17:43:34 +0100
> CC: llvmdev at cs.uiuc.edu
> Subject: Re: [cfe-dev] win32/llvm.sln, win32/clang.sln
> 
> Makslane Ara?jo Rodrigues
> <makslane at hotmail.com> writes:
> 
> > Please, don't remove, I'm using!!!
> 
> What's preventing you from using CMake?
> 
> Is there some problem we can solve?
> 
> -- 
> Oscar
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_________________________________________________________________
Mais do que emails! Confira tudo o que Windows Live? pode oferecer.
http://www.microsoft.com/windows/windowslive/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090116/66b83f7f/attachment.html 

From npjohnso at cs.princeton.edu  Fri Jan 16 14:09:33 2009
From: npjohnso at cs.princeton.edu (Nick Johnson)
Date: Fri, 16 Jan 2009 15:09:33 -0500
Subject: [LLVMdev] The annotation intrinsic, floating point values,
	stores and branches
Message-ID: <d85094510901161209w3e11ea18k79959f3f62e01deb@mail.gmail.com>

Hello,

With respect to the llvm.annotation.* instrinsic.

(1) I see it has been overloaded against all integer widths.  Can it
also be overloaded against every llvm type (including label types,
function types, floating point types, pointer types, structure types,
etc)?  If not, why?  If so, how?

(2) Is there any way to use it to annotate instructions which produce
no value, such as stores and branch instructions?

Thank you,
-- 
Nick Johnson

From clattner at apple.com  Fri Jan 16 14:23:52 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 16 Jan 2009 12:23:52 -0800
Subject: [LLVMdev] Memory Dependence Analysis
In-Reply-To: <200901141137.30627.dag@cray.com>
References: <200901141137.30627.dag@cray.com>
Message-ID: <160572DD-B592-4970-A0D7-1005FD260C99@apple.com>


On Jan 14, 2009, at 9:37 AM, David Greene wrote:

> Back in August, several of us participated in a discussion about  
> getting a
> more robust memory dependence analysis framework into LLVM.  Wojtek
> Matyjewicz has done some work on this and he attached a patch to an  
> e-mail at
> the time that built against an older version of LLVM.
>
> Wojtek, what's the status of this patch?  Does it build against  
> HEAD?  Do you
> plan to check it in any time soon?

No idea here ;)

> We're in the middle of upgrading to 2.4 here and I see that
> MemoryDependenceAnalysis has changed a bit.  What are the major  
> changes here?

MemoryDependenceAnalysis does *memory* def/use analysis (what store  
does a load depend on), but does not do *loop dependence* analysis.  I  
assume you're interested in the dependence analysis, not really just  
def/use of memory.

-Chris

From clattner at apple.com  Fri Jan 16 14:24:57 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 16 Jan 2009 12:24:57 -0800
Subject: [LLVMdev] Loop elimination with floating point counter.
In-Reply-To: <1f06970b0901140511ufea2358u92f458c9d252282@mail.gmail.com>
References: <1f06970b0901080436t4223f990m1de1fac4cebb1696@mail.gmail.com>
	<C1C2905E-4BB8-4BD9-82EB-04EEAF83A3F3@apple.com>
	<1f06970b0901080922k1e80e4b6ree7239a9ff4c427e@mail.gmail.com>
	<5296F463-E937-4774-A4DE-26858DA14942@mac.com>
	<759EC041-923A-4F12-9833-26EE246DF42F@gmx.net>
	<92381DB0-F6B9-4AD8-8242-7F03B280C132@mac.com>
	<4aca3dc20901082011u74266dc2mf88e3490a6145e01@mail.gmail.com>
	<1f06970b0901140511ufea2358u92f458c9d252282@mail.gmail.com>
Message-ID: <F85659C3-B0F7-4526-91D0-859C9A5263B8@apple.com>


On Jan 14, 2009, at 5:11 AM, Syoyo Fujita wrote:

> Thanks for many comments.
>
> The loop with finite fp values(which could be representable in IEEE754
> fp format) such like,

Sure, LLVM could definitely do this.  If you're interested, I'd  
suggest starting by extending the existing code that we have to do  
this.  The existing code just handles increments by unit constants, so  
it doesn't trigger with 1.2.

-Chris


From clattner at apple.com  Fri Jan 16 14:27:08 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 16 Jan 2009 12:27:08 -0800
Subject: [LLVMdev] ParseError::getMessage() API.
In-Reply-To: <c8033d570901130930ia41bda4mc01eda49253903a9@mail.gmail.com>
References: <c8033d570901130930ia41bda4mc01eda49253903a9@mail.gmail.com>
Message-ID: <8559E9C2-C916-4DF7-856A-8B84EFA8F40A@apple.com>


On Jan 13, 2009, at 9:30 AM, Mahadevan R wrote:

> Hi,
>
> The method ParseError::getMessage() seems to have got deleted from
> lib/AsmParser/Parser.cpp during the parser rewrite. Right now it's
> there in the header (include/llvm/Assembly/Parser.h) but not in
> lib/AsmParser/Parser.cpp.

Fixed, sorry!

> Is this API still valid? Or is it PrintError() that's meant to be  
> used?

PrintError is preferred.  You can also use getRawMessage.

-Chris

From dag at cray.com  Fri Jan 16 15:08:36 2009
From: dag at cray.com (David Greene)
Date: Fri, 16 Jan 2009 15:08:36 -0600
Subject: [LLVMdev] Memory Dependence Analysis
In-Reply-To: <160572DD-B592-4970-A0D7-1005FD260C99@apple.com>
References: <200901141137.30627.dag@cray.com>
	<160572DD-B592-4970-A0D7-1005FD260C99@apple.com>
Message-ID: <200901161508.37188.dag@cray.com>

On Friday 16 January 2009 14:23, Chris Lattner wrote:

> > Wojtek, what's the status of this patch?  Does it build against
> > HEAD?  Do you
> > plan to check it in any time soon?
>
> No idea here ;)

Sure.  :)

IIRC Wojtek is working on loop dependence, which of course is different
from memory def/use information as you note below.  Sorry for mixing up terms.

> > We're in the middle of upgrading to 2.4 here and I see that
> > MemoryDependenceAnalysis has changed a bit.  What are the major
> > changes here?
>
> MemoryDependenceAnalysis does *memory* def/use analysis (what store
> does a load depend on), but does not do *loop dependence* analysis.  I
> assume you're interested in the dependence analysis, not really just
> def/use of memory.

Eventually we want both.  In the near-term, I just need memory dependence.
We're doing multiple different things and thus need different analyses.

                                            -Dave

From gohman at apple.com  Fri Jan 16 15:33:40 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 16 Jan 2009 13:33:40 -0800
Subject: [LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)
In-Reply-To: <200901160834.10459.brandner@complang.tuwien.ac.at>
References: <4d77c5f20901140558v7332be81j8f7a90fb67183a39@mail.gmail.com>
	<200901150950.31241.brandner@complang.tuwien.ac.at>
	<B9AB782D-F8EF-4D7D-BC35-2CD355DC69A5@apple.com>
	<200901160834.10459.brandner@complang.tuwien.ac.at>
Message-ID: <B4674704-E78A-4FE0-AB24-6C55F1AF3F73@apple.com>


On Jan 15, 2009, at 11:34 PM, Brandner wrote:

> Hi Dan,
>
> thank you for applying the patch.
>
>> However, I didn't apply this part:
>>
>> -      if (InstPatNode && InstPatNode->getOperator()->getName() ==
>> "set") {
>> +      if (InstPatNode && !InstPatNode->isLeaf() &&
>> +          InstPatNode->getOperator()->getName() == "set") {
>>
>> because I'm unsure what it's for. When is a "set" node a leaf?
>
> exactly it never is, however InstPatNode may well be a leaf. in that  
> case
> calling getOperator is not valid, because it asserts on !isLeaf:
>
> Record *getOperator() const { assert(!isLeaf()); return Operator; }
>
> so this check definitely should be there.

Ah, thanks. I applied this portion of the patch now.

Dan


From deeppatel1987 at gmail.com  Fri Jan 16 19:26:16 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Fri, 16 Jan 2009 17:26:16 -0800
Subject: [LLVMdev] Using CallingConvLower in ARM target
In-Reply-To: <F347CFB9-8B14-4BE9-8B57-856601D1E786@apple.com>
References: <305d6f60812270430xdf1ebb9gf6d99f94215ab66b@mail.gmail.com>
	<F347CFB9-8B14-4BE9-8B57-856601D1E786@apple.com>
Message-ID: <305d6f60901161726l5c93c9dag6f98ca06a420cb31@mail.gmail.com>

On Sat, Jan 3, 2009 at 11:46 AM, Dan Gohman <gohman at apple.com> wrote:
>
> One problem with this approach is that since i64 isn't legal, the
> bitcast would require custom C++ code in the ARM target to
> handle properly.  It might make sense to introduce something
> like
>
>    CCIfType<[f64], CCCustom>
>
> where CCCustom is a new entity that tells the calling convention
> code to to let the target do something not easily representable
> in the tablegen minilanguage.

I am thinking that this requires two changes: add a flag to
CCValAssign (take a bit from HTP) to indicate isCustom and a way to
author an arbitrary CCAction by including the source directly in the
TableGen mini-language. This latter change might want a generic change
to the TableGen language. For example, the syntax might be like:

class foo : CCCustomAction {
code <<< EOF
      ....multi-line C++ code goes here that allocates regs & mem and
sets CCValAssign::isCustom....
EOF
}

Does this seem reasonable? An alternative is for CCCustom to take a
string that names a function to be called:

CCIfType<[f64], CCCustom<"MyCustomLoweringFunc">>

the function signature for such functions will have to return two
results: if the CC processing is finished and if it the func succeeded
or failed:

typedef bool CCCustomFn(unsigned ValNo, MVT ValVT,
                        MVT LocVT, CCValAssign::LocInfo LocInfo,
                        ISD::ArgFlagsTy ArgFlags, CCState &State, bool &result);

From duncan at duncanpierce.org  Sat Jan 17 11:58:58 2009
From: duncan at duncanpierce.org (Duncan Pierce)
Date: Sat, 17 Jan 2009 17:58:58 +0000
Subject: [LLVMdev] Build problems on MinGW
In-Reply-To: <F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
	<F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
Message-ID: <a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>

2009/1/13 Anton Korobeynikov <anton at korobeynikov.info>:
> Hello, Duncan
>
> * LD (which I took to be representative of Binutils version) 2.17.50
> 20060824

> Why you're using such old binutils? 2.18.50-20080109 definitely worked for
> me (and release binaries were built so...).

Thank you for your reply Anton. I'm sorry it's taken a while to get
back to you. This binutils came with the MinGW installer. I have made
some progress by reinstalling according to these instructions, though
I took slightly more recent versions in some cases and also found I
needed Perl (thank you Anton and Ted):

http://blogs.tedneward.com/2008/02/24/Building+LLVM+On+Windows+Using+MinGW32.aspx

Now I can compile and install llvm-2.4 but the first step in the
tutorial fails for me with another missing symbol:

$ g++ -g tut1.cpp `llvm-config --cxxflags --ldflags --libs core` -o tut1
/mingw/lib/libLLVMSystem.a(Process.o):Process.cpp:(.text+0x8d):
undefined reference to `GetProcessMemoryInfo at 12'
collect2: ld returned 1 exit status

I'm using GNU ld (GNU Binutils) 2.18.50.20080109.

Thanks for any further help you can provide,

Duncan Pierce

From foldr at codedgers.com  Sat Jan 17 12:18:50 2009
From: foldr at codedgers.com (Mikhail Glushenkov)
Date: Sat, 17 Jan 2009 18:18:50 +0000 (UTC)
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
Message-ID: <loom.20090117T181238-366@post.gmane.org>

This may be of interest:

http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html

People implementing a new Haskell compiler explain why LLVM is an
unsuitable target for them.


From dberlin at dberlin.org  Sat Jan 17 12:52:44 2009
From: dberlin at dberlin.org (Daniel Berlin)
Date: Sat, 17 Jan 2009 13:52:44 -0500
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <loom.20090117T181238-366@post.gmane.org>
References: <loom.20090117T181238-366@post.gmane.org>
Message-ID: <4aca3dc20901171052w143978c9qc3b75dbd19c3816e@mail.gmail.com>

It's nice that he claims it's way too high overhead without any, you know, data.

Then again, he also thinks writing a good native code generator isn't
that difficult, so ....

On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at codedgers.com> wrote:
> This may be of interest:
>
> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>
> People implementing a new Haskell compiler explain why LLVM is an
> unsuitable target for them.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From clattner at apple.com  Sat Jan 17 13:02:47 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 17 Jan 2009 11:02:47 -0800
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <loom.20090117T181238-366@post.gmane.org>
References: <loom.20090117T181238-366@post.gmane.org>
Message-ID: <75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>


On Jan 17, 2009, at 10:18 AM, Mikhail Glushenkov wrote:

> This may be of interest:
>
> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>
> People implementing a new Haskell compiler explain why LLVM is an
> unsuitable target for them.

I find the article, and particularly the preceding one (http://lhc-compiler.blogspot.com/2009/01/what-is-lhc.html 
) to be quite amusing.  First, this article should be titled "the case  
against C / LLVM 2.5", not against LLVM in general.  There is nothing  
in the design that prevents holding GC roots in registers, it is just  
that noone has implemented support for it yet.  It would actually be a  
pretty simple hack to move the current GC implementation to use the  
address space support, and say that all pointers into address space 42  
are GC'd pointers (for example).  This would work fine for languages  
like haskell and java where the GC doesn't need static metadata  
associated with the pointers.

I assert that the time and cost to implement an entirely new x86  
backend (to start with?) is far more than would be required to add  
this feature to LLVM (also note that their non-existent code generator  
doesn't support this feature either).  Further, the skill set required  
to implement a very performant low-level code generator is very  
different than that required to produce a performant implementation of  
a high level language like Haskell.

In the end, I consider this to be a yet-another chapter in the  
"functional language people don't like LLVM" saga.  Whether it be  
small improvements in LLVM tail calls or the fact that LLVM currently  
pins GC roots to the stack, there is always a "good reason" to justify  
writing something new, rather than learning and extend an existing  
system.  I'm sure that LLVM being written in C++ (as opposed to, say,  
ocaml) is part of this as well.

In the end, I think that diversity is good in the compiler world, and  
wish them the best.  It's just not the approach I would take in  
2009. ;-)

-Chris

From jon at ffconsultancy.com  Sat Jan 17 13:54:07 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Sat, 17 Jan 2009 19:54:07 +0000
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>
References: <loom.20090117T181238-366@post.gmane.org>
	<75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>
Message-ID: <200901171954.07249.jon@ffconsultancy.com>

On Saturday 17 January 2009 19:02:47 Chris Lattner wrote:
> In the end, I consider this to be a yet-another chapter in the
> "functional language people don't like LLVM" saga.

The OCaml Journal has published around 40 articles now. The most popular and 
third most popular articles are both about LLVM. So I don't think it is 
correct to say that "functional language people don't like LLVM". Indeed, I 
thought I was a kook for trying to write a compiler for a functional language 
using LLVM until I mentioned it to the OCaml community and half a dozen 
people stepped forward with their own alternatives. :-)

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From lennart at augustsson.net  Sat Jan 17 13:59:15 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Sat, 17 Jan 2009 19:59:15 +0000
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>
References: <loom.20090117T181238-366@post.gmane.org>
	<75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>
Message-ID: <f4876cd70901171159n22c231f3g7791d7c4c15a093b@mail.gmail.com>

I just want to say that the "functional language people don't like
LLVM" saga is not complete.
I think the LLVM is very cool, and although I've not looked into
supporting GC yet, I'm sure it's possible.
I'd rather try that than duplicating the LLVM effort (I've written
enough code generators).

  -- Lennart

On Sat, Jan 17, 2009 at 7:02 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Jan 17, 2009, at 10:18 AM, Mikhail Glushenkov wrote:
>
>> This may be of interest:
>>
>> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>>
>> People implementing a new Haskell compiler explain why LLVM is an
>> unsuitable target for them.
>
> I find the article, and particularly the preceding one (http://lhc-compiler.blogspot.com/2009/01/what-is-lhc.html
> ) to be quite amusing.  First, this article should be titled "the case
> against C / LLVM 2.5", not against LLVM in general.  There is nothing
> in the design that prevents holding GC roots in registers, it is just
> that noone has implemented support for it yet.  It would actually be a
> pretty simple hack to move the current GC implementation to use the
> address space support, and say that all pointers into address space 42
> are GC'd pointers (for example).  This would work fine for languages
> like haskell and java where the GC doesn't need static metadata
> associated with the pointers.
>
> I assert that the time and cost to implement an entirely new x86
> backend (to start with?) is far more than would be required to add
> this feature to LLVM (also note that their non-existent code generator
> doesn't support this feature either).  Further, the skill set required
> to implement a very performant low-level code generator is very
> different than that required to produce a performant implementation of
> a high level language like Haskell.
>
> In the end, I consider this to be a yet-another chapter in the
> "functional language people don't like LLVM" saga.  Whether it be
> small improvements in LLVM tail calls or the fact that LLVM currently
> pins GC roots to the stack, there is always a "good reason" to justify
> writing something new, rather than learning and extend an existing
> system.  I'm sure that LLVM being written in C++ (as opposed to, say,
> ocaml) is part of this as well.
>
> In the end, I think that diversity is good in the compiler world, and
> wish them the best.  It's just not the approach I would take in
> 2009. ;-)
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From jon at ffconsultancy.com  Sat Jan 17 14:24:46 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Sat, 17 Jan 2009 20:24:46 +0000
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <loom.20090117T181238-366@post.gmane.org>
References: <loom.20090117T181238-366@post.gmane.org>
Message-ID: <200901172024.46718.jon@ffconsultancy.com>

On Saturday 17 January 2009 18:18:50 Mikhail Glushenkov wrote:
> This may be of interest:
>
> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>
> People implementing a new Haskell compiler explain why LLVM is an
> unsuitable target for them.

FWIW, I am a physicist with no formal training in compiler writing yet LLVM 
has allowed me to create a compiler for a statically-typed functional 
language in only one week that outperforms OCaml on a variety of numerical 
benchmarks, often by a substantial margin on x86.

Moreover, I took the simplest design choice at every stage in order to 
maximize the chances of actually ending up with a working compiler. In 
particular, I used a shadow stack based on the pessimistic assumption that 
LLVM is uncooperative and I found the performance degradation to be 
insignificant on all code except integer Fibonacci which is ~30% slower but 
only because I have not yet optimized away the shadow stack for functions 
that do not use reference types.

So if anyone is considering writing a compiler for a functional language, I 
strongly recommend building upon LLVM.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From anton at korobeynikov.info  Sat Jan 17 15:19:04 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Sun, 18 Jan 2009 00:19:04 +0300
Subject: [LLVMdev] Build problems on MinGW
In-Reply-To: <a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
	<F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
	<a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>
Message-ID: <b087fca00901171319l2e9f06b5udf4e25310ad61b32@mail.gmail.com>

Hello, Duncan

> $ g++ -g tut1.cpp `llvm-config --cxxflags --ldflags --libs core` -o tut1
> /mingw/lib/libLLVMSystem.a(Process.o):Process.cpp:(.text+0x8d):
> undefined reference to `GetProcessMemoryInfo at 12'
> collect2: ld returned 1 exit status
I believe you will need additional libraries like imagehlp and psapi.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From Dr.Graef at t-online.de  Sat Jan 17 15:25:48 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Sat, 17 Jan 2009 22:25:48 +0100
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>
References: <loom.20090117T181238-366@post.gmane.org>
	<75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>
Message-ID: <49724CDC.2010502@t-online.de>

Chris Lattner wrote:
> In the end, I consider this to be a yet-another chapter in the  
> "functional language people don't like LLVM" saga.

Yet another counterexample:

http://pure-lang.googlecode.com/

LLVM from the ground up, proper tail calls, interactive interpreter,
JIT, easy C interface. Works great. :) Without LLVM, I could have never
pulled that off in a couple of months.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

From duncan at duncanpierce.org  Sat Jan 17 16:04:08 2009
From: duncan at duncanpierce.org (Duncan Pierce)
Date: Sat, 17 Jan 2009 22:04:08 +0000
Subject: [LLVMdev] Build problems on MinGW
In-Reply-To: <b087fca00901171319l2e9f06b5udf4e25310ad61b32@mail.gmail.com>
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
	<F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
	<a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>
	<b087fca00901171319l2e9f06b5udf4e25310ad61b32@mail.gmail.com>
Message-ID: <a55ee3140901171404t41d0512fs9ed56ffd0ed990a6@mail.gmail.com>

Hi Anton

>> $ g++ -g tut1.cpp `llvm-config --cxxflags --ldflags --libs core` -o tut1
>> /mingw/lib/libLLVMSystem.a(Process.o):Process.cpp:(.text+0x8d):
>> undefined reference to `GetProcessMemoryInfo at 12'
>> collect2: ld returned 1 exit status
> I believe you will need additional libraries like imagehlp and psapi.

I have /lib/libimagehlp.a  and /lib/libpsapi.a

nm --defined-only /lib/libpsapi.a | grep "GetProcessMemoryInfo" -

returns:

00000000 T _GetProcessMemoryInfo at 12
00000000 I __imp__GetProcessMemoryInfo at 12

And llvm-config seems to be asking for them to be picked up:

-I//include  -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O2
-fomit-frame-pointer  -Woverloaded-virtual
-L//lib  -lpsapi -limagehlp -lm
-lLLVMCore -lLLVMSupport -lLLVMSystem

So I'm still mystified.

Best regards,
Duncan

From ofv at wanadoo.es  Sat Jan 17 16:45:45 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Sat, 17 Jan 2009 23:45:45 +0100
Subject: [LLVMdev] Build problems on MinGW
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
	<F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
	<a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>
	<b087fca00901171319l2e9f06b5udf4e25310ad61b32@mail.gmail.com>
	<a55ee3140901171404t41d0512fs9ed56ffd0ed990a6@mail.gmail.com>
Message-ID: <m3ab9py2jq.fsf@telefonica.net>

Duncan Pierce <duncan at duncanpierce.org> writes:

> I have /lib/libimagehlp.a  and /lib/libpsapi.a
>
> nm --defined-only /lib/libpsapi.a | grep "GetProcessMemoryInfo" -
>
> returns:
>
> 00000000 T _GetProcessMemoryInfo at 12
> 00000000 I __imp__GetProcessMemoryInfo at 12
>
> And llvm-config seems to be asking for them to be picked up:
>
> -I//include  -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O2
> -fomit-frame-pointer  -Woverloaded-virtual
> -L//lib  -lpsapi -limagehlp -lm
> -lLLVMCore -lLLVMSupport -lLLVMSystem
>
> So I'm still mystified.

Put them at the end of the library list:

-lLLVMCore -lLLVMSupport -lLLVMSystem -limagehlp -lpsapi -lm

Unless recently changed, mingw's ld resolves symbols sequentially on the
library list, it does not look on previously processed libraries, so
order is relevant.

If llvm-config puts psapi and imagehlp at the beginning of the list,
that probably is a bug on llvm-config. But llvm-config's source code
does not mention psapi and/or imagehlp at all.

Are you sure that -lpsapi and -limagehlp are on the output of
llvm-config? They are not on my mingw's LLVM, although it is several
weeks old.

-- 
Oscar


From clattner at apple.com  Sat Jan 17 18:27:46 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 17 Jan 2009 16:27:46 -0800
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <49724CDC.2010502@t-online.de>
References: <loom.20090117T181238-366@post.gmane.org>
	<75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>
	<49724CDC.2010502@t-online.de>
Message-ID: <F1443779-3DEC-49FA-A535-C4CB7BAED72A@apple.com>


On Jan 17, 2009, at 1:25 PM, Albert Graef wrote:

> Chris Lattner wrote:
>> In the end, I consider this to be a yet-another chapter in the
>> "functional language people don't like LLVM" saga.
>
> Yet another counterexample:
>
> http://pure-lang.googlecode.com/

Hey, this is incredibly cool. I had never heard of pure, nice work!   
Would you mind writing a blurb for this page?
http://llvm.org/ProjectsWithLLVM/

> LLVM from the ground up, proper tail calls, interactive interpreter,
> JIT, easy C interface. Works great. :) Without LLVM, I could have  
> never
> pulled that off in a couple of months.

That's very nice.  Do you (or anyone else out there that I don't know  
about :) want to be mentioned in the LLVM 2.5 release notes?  I am  
happy to have the LLVM 2.5 release notes and announcement mention and  
link to (active and well maintained) projects like this!

Incidentally, my comment about functional language people hating LLVM  
wasn't meant as a universal statement.  I'm thrilled that there are  
people using and liking it, please help spread the good word! :)

-Chris

From csaba.hruska at gmail.com  Sat Jan 17 18:35:06 2009
From: csaba.hruska at gmail.com (Csaba Hruska)
Date: Sun, 18 Jan 2009 01:35:06 +0100
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <F1443779-3DEC-49FA-A535-C4CB7BAED72A@apple.com>
References: <loom.20090117T181238-366@post.gmane.org>
	<75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>
	<49724CDC.2010502@t-online.de>
	<F1443779-3DEC-49FA-A535-C4CB7BAED72A@apple.com>
Message-ID: <8914b92d0901171635n705c16cfx2dd57c20cc4cbf0f@mail.gmail.com>

Hi!

Essential Haskell Compiler (EHC) also has llvm backend.

http://www.cs.uu.nl/wiki/bin/view/Ehc/WebHome
http://www.cs.uu.nl/wiki/bin/view/Stc/CompilingHaskellToLLVM

Cheers,
Csaba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090118/33489dd6/attachment.html 

From jon at ffconsultancy.com  Sat Jan 17 19:43:56 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Sun, 18 Jan 2009 01:43:56 +0000
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <8914b92d0901171635n705c16cfx2dd57c20cc4cbf0f@mail.gmail.com>
References: <loom.20090117T181238-366@post.gmane.org>
	<F1443779-3DEC-49FA-A535-C4CB7BAED72A@apple.com>
	<8914b92d0901171635n705c16cfx2dd57c20cc4cbf0f@mail.gmail.com>
Message-ID: <200901180143.56161.jon@ffconsultancy.com>

On Sunday 18 January 2009 00:35:06 Csaba Hruska wrote:
> Hi!
>
> Essential Haskell Compiler (EHC) also has llvm backend.
>
> http://www.cs.uu.nl/wiki/bin/view/Ehc/WebHome
> http://www.cs.uu.nl/wiki/bin/view/Stc/CompilingHaskellToLLVM

Interesting that John van Schie's slides show a similar result to my own: LLVM 
generates faster code than heavily-optimizing existing compilers on all but 
one benchmark.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From yim6 at illinois.edu  Sun Jan 18 00:27:05 2009
From: yim6 at illinois.edu (Keun Soo Yim)
Date: Sun, 18 Jan 2009 00:27:05 -0600
Subject: [LLVMdev] Qs on building LLVM passes
Message-ID: <010d01c97935$c876b460$59641d20$@edu>

 

 Hi,

 

 I have couple of questions that those who design unconventional passes
would be interested in.

 

1.       How to move a virtual register data to another new virtual
register?

It seems like that there is no LLVM instruction similar to mov machine
instruction.

Arithmetic or logical operators could be used for integer variables

but what about pointer variables?

 

2.       What is typically IR-level pass execution order? Especially when we
separately execute

the front-end, IR optimizer, and back-end, this information seems to be
needed.

 

3.       In code generator, how can we add new instruction in a way that
back-end consider

this added instruction for its instruction scheduling and register
allocation?

 

 Thanks in advance.

 

 - Keun Soo

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090118/6e539d74/attachment.html 

From resistor at mac.com  Sun Jan 18 01:27:07 2009
From: resistor at mac.com (Owen Anderson)
Date: Sat, 17 Jan 2009 23:27:07 -0800
Subject: [LLVMdev] Qs on building LLVM passes
In-Reply-To: <010d01c97935$c876b460$59641d20$@edu>
References: <010d01c97935$c876b460$59641d20$@edu>
Message-ID: <21C1774E-3C3C-47DD-8627-BBD51F915C49@mac.com>


On Jan 17, 2009, at 10:27 PM, Keun Soo Yim wrote:
> 1.       How to move a virtual register data to another new virtual  
> register?
> It seems like that there is no LLVM instruction similar to mov  
> machine instruction.
> Arithmetic or logical operators could be used for integer variables
> but what about pointer variables?

Why do you need to copy a value?  Virtual registers are immutable (SSA  
form), so you don't need to worry about the value getting overwritten.

> 2.       What is typically IR-level pass execution order? Especially  
> when we separately execute
> the front-end, IR optimizer, and back-end, this information seems to  
> be needed.

Take a look at tools/opt/opt.cpp.  You can see what the "-std-compile- 
opts" sequence does in there.  You can also look at tools/llvm-ld/ 
Optimize.cpp for a standard set of link-time optimizations.

--Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090117/a99c1a0f/attachment.html 

From nicholas at mxc.ca  Sun Jan 18 01:59:39 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 17 Jan 2009 23:59:39 -0800
Subject: [LLVMdev] Qs on building LLVM passes
In-Reply-To: <010d01c97935$c876b460$59641d20$@edu>
References: <010d01c97935$c876b460$59641d20$@edu>
Message-ID: <4972E16B.8090108@mxc.ca>

Keun Soo Yim wrote:
> 
> 
>  
> 
>  Hi,
> 
>  
> 
>  I have couple of questions that those who design unconventional passes 
> would be interested in.
> 
>  
> 
> 1.       How to move a virtual register data to another new virtual 
> register?
> 
> It seems like that there is no LLVM instruction similar to mov machine 
> instruction.
> 
> Arithmetic or logical operators could be used for integer variables
> 
> but what about pointer variables?

The trick to copying values is to use bitcast where the source and 
destination types are the same.

Of course, if you're doing this, you should understand that you're being 
very naughty indeed. :)

Nick

> 
>  
> 
> 2.       What is typically IR-level pass execution order? Especially 
> when we separately execute
> 
> the front-end, IR optimizer, and back-end, this information seems to be 
> needed.
> 
>  
> 
> 3.       In code generator, how can we add new instruction in a way that 
> back-end consider
> 
> this added instruction for its instruction scheduling and register 
> allocation?
> 
>  
> 
>  Thanks in advance.
> 
>  
> 
>  - Keun Soo
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From libors at gmail.com  Sun Jan 18 03:43:56 2009
From: libors at gmail.com (Libor Spacek)
Date: Sun, 18 Jan 2009 09:43:56 -0000
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <mailman.955.1232265599.945.llvmdev@cs.uiuc.edu>
References: <mailman.955.1232265599.945.llvmdev@cs.uiuc.edu>
Message-ID: <op.unx5bhjm6yy425@ubangu>

>Chris Lattner wrote:

>>http://pure-lang.googlecode.com/
 
>Hey, this is incredibly cool. I had never heard of pure, nice work!  Would you mind writing a blurb for this page?
>http://llvm.org/ProjectsWithLLVM/
 
>-Chris

It was the other way round for me. I have been introduced to LLVM by first seeing it employed effectively in Pure.
Libor 




From Dr.Graef at t-online.de  Sun Jan 18 04:47:36 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Sun, 18 Jan 2009 11:47:36 +0100
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <F1443779-3DEC-49FA-A535-C4CB7BAED72A@apple.com>
References: <loom.20090117T181238-366@post.gmane.org>	<75156828-5F28-4344-8D20-5497AC45DD0C@apple.com>	<49724CDC.2010502@t-online.de>
	<F1443779-3DEC-49FA-A535-C4CB7BAED72A@apple.com>
Message-ID: <497308C8.6060005@t-online.de>

Chris Lattner wrote:
> Hey, this is incredibly cool. I had never heard of pure, nice work!

Thanks. I only just started to write about it as we're getting close to
version 1.0 now, so you might hear more about it in the future. ;-)

> Would you mind writing a blurb for this page?
> http://llvm.org/ProjectsWithLLVM/

Here goes:

Pure (http://pure-lang.googlecode.com/) is an algebraic/functional
programming language based on term rewriting. Programs are collections
of equations which are used to evaluate expressions in a symbolic
fashion. Pure offers dynamic typing, eager and lazy evaluation, lexical
closures, a hygienic macro system (also based on term rewriting),
built-in list and matrix support (including list and matrix
comprehensions) and an easy-to-use C interface. The interpreter uses
LLVM as a backend to JIT-compile Pure programs to fast native code.

In addition to the usual algebraic data structures, Pure also has
MATLAB-style matrices in order to support numeric computations and
signal processing in an efficient way. Pure is mainly aimed at
mathematical applications right now, but it has been designed as a
general purpose language. The dynamic interpreter environment and the C
interface make it possible to use it as a kind of functional scripting
language for many application areas.

(Please feel free to edit for editorial purposes.)

> That's very nice.  Do you (or anyone else out there that I don't know  
> about :) want to be mentioned in the LLVM 2.5 release notes?

Sure, that would be nice!

> Incidentally, my comment about functional language people hating LLVM  
> wasn't meant as a universal statement.  I'm thrilled that there are  
> people using and liking it, please help spread the good word! :)

Will do. But I think that if there are any compiler writers who haven't
heard about LLVM yet then they must have been hiding under a rock. :)

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

From isanbard at gmail.com  Sun Jan 18 05:05:13 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sun, 18 Jan 2009 03:05:13 -0800
Subject: [LLVMdev] Qs on building LLVM passes
In-Reply-To: <010d01c97935$c876b460$59641d20$@edu>
References: <010d01c97935$c876b460$59641d20$@edu>
Message-ID: <376A3C96-200C-4122-8090-5C5649C36E4C@gmail.com>

On Jan 17, 2009, at 10:27 PM, Keun Soo Yim wrote:

> 3.       In code generator, how can we add new instruction in a way  
> that back-end consider
> this added instruction for its instruction scheduling and register  
> allocation?
>
You will want to add this in the appropriate .td file. The .td files  
are full of "recipes" which match nodes in the DAG. The appropriate  
instruction is selected from those recipes that match a pattern in the  
DAG.

-bw

From duncan at duncanpierce.org  Sun Jan 18 06:58:15 2009
From: duncan at duncanpierce.org (Duncan Pierce)
Date: Sun, 18 Jan 2009 12:58:15 +0000 (UTC)
Subject: [LLVMdev] Build problems on MinGW solved - possible llvm-config
	bug
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
	<F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
	<a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>
	<b087fca00901171319l2e9f06b5udf4e25310ad61b32@mail.gmail.com>
	<a55ee3140901171404t41d0512fs9ed56ffd0ed990a6@mail.gmail.com>
	<m3ab9py2jq.fsf@telefonica.net>
Message-ID: <loom.20090118T124307-115@post.gmane.org>

?scar Fuentes <ofv <at> wanadoo.es> writes:

> Duncan Pierce <duncan <at> duncanpierce.org> writes:
> 
> > I have /lib/libimagehlp.a  and /lib/libpsapi.a
> > And llvm-config seems to be asking for them to be picked up:
> >
> > -I//include  -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O2
> > -fomit-frame-pointer  -Woverloaded-virtual
> > -L//lib  -lpsapi -limagehlp -lm
> > -lLLVMCore -lLLVMSupport -lLLVMSystem
> >
> > So I'm still mystified.
> 
> Put them at the end of the library list:
> 
> -lLLVMCore -lLLVMSupport -lLLVMSystem -limagehlp -lpsapi -lm

This works. I had a look at changing the llvm-config.in.in but my Perl hacking
skills aren't up to getting --libnames and --libfiles to work as well as --libs.

I discovered one other thing that was causing me problems on MinGW: if I use the
msys.bat to open a terminal llvm-config inserts double slashes at the start of
any absolute path it generates (e.g. //lib/LLVMX86CodeGen.o) - this breaks g++.

If I do the same thing from a DOS prompt running bash, slashes don't get doubled
and everything works fine.

Thanks once again ?scar and Anton.

Duncan Pierce




From ofv at wanadoo.es  Sun Jan 18 07:20:40 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Sun, 18 Jan 2009 14:20:40 +0100
Subject: [LLVMdev] Build problems on MinGW solved - possible llvm-config
	bug
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
	<F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
	<a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>
	<b087fca00901171319l2e9f06b5udf4e25310ad61b32@mail.gmail.com>
	<a55ee3140901171404t41d0512fs9ed56ffd0ed990a6@mail.gmail.com>
	<m3ab9py2jq.fsf@telefonica.net>
	<loom.20090118T124307-115@post.gmane.org>
Message-ID: <m34ozwyclz.fsf@telefonica.net>

Duncan Pierce <duncan at duncanpierce.org> writes:

>> > I have /lib/libimagehlp.a  and /lib/libpsapi.a
>> > And llvm-config seems to be asking for them to be picked up:
>> >
>> > -I//include  -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O2
>> > -fomit-frame-pointer  -Woverloaded-virtual
>> > -L//lib  -lpsapi -limagehlp -lm
>> > -lLLVMCore -lLLVMSupport -lLLVMSystem
>> >
>> > So I'm still mystified.
>> 
>> Put them at the end of the library list:
>> 
>> -lLLVMCore -lLLVMSupport -lLLVMSystem -limagehlp -lpsapi -lm
>
> This works. I had a look at changing the llvm-config.in.in but my Perl hacking
> skills aren't up to getting --libnames and --libfiles to work as well as --libs.

Would you like to file a bug report? This is the way of getting it
fixed.

> I discovered one other thing that was causing me problems on MinGW: if I use the
> msys.bat to open a terminal llvm-config inserts double slashes at the start of
> any absolute path it generates (e.g. //lib/LLVMX86CodeGen.o) - this breaks g++.
>
> If I do the same thing from a DOS prompt running bash, slashes don't get doubled
> and everything works fine.

This one also deserves a bug report. My guess is that llvm-config is
throwing backslashes (\) which are escaped at some intermediate point
and finally translated to double slashes by MSYS.

> Thanks once again ?scar and Anton.

You're welcome.

-- 
Oscar


From anton at korobeynikov.info  Sun Jan 18 09:02:09 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Sun, 18 Jan 2009 18:02:09 +0300
Subject: [LLVMdev] Build problems on MinGW solved - possible llvm-config
	bug
In-Reply-To: <loom.20090118T124307-115@post.gmane.org>
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
	<F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
	<a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>
	<b087fca00901171319l2e9f06b5udf4e25310ad61b32@mail.gmail.com>
	<a55ee3140901171404t41d0512fs9ed56ffd0ed990a6@mail.gmail.com>
	<m3ab9py2jq.fsf@telefonica.net>
	<loom.20090118T124307-115@post.gmane.org>
Message-ID: <b087fca00901180702n945910bw8c751968179a4a16@mail.gmail.com>

Hello, Duncan

> I discovered one other thing that was causing me problems on MinGW: if I use the
> msys.bat to open a terminal llvm-config inserts double slashes at the start of
> any absolute path it generates (e.g. //lib/LLVMX86CodeGen.o) - this breaks g++.
That's strange, never seen this before. Do you have two different
version of perl installed? (for example, one msys DTK and another one
- standalone ActivePerl, etc.)

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From duncan at duncanpierce.org  Sun Jan 18 08:59:13 2009
From: duncan at duncanpierce.org (Duncan Pierce)
Date: Sun, 18 Jan 2009 14:59:13 +0000
Subject: [LLVMdev] Build problems on MinGW solved - possible llvm-config
	bug
In-Reply-To: <m34ozwyclz.fsf@telefonica.net>
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
	<F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
	<a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>
	<b087fca00901171319l2e9f06b5udf4e25310ad61b32@mail.gmail.com>
	<a55ee3140901171404t41d0512fs9ed56ffd0ed990a6@mail.gmail.com>
	<m3ab9py2jq.fsf@telefonica.net>
	<loom.20090118T124307-115@post.gmane.org>
	<m34ozwyclz.fsf@telefonica.net>
Message-ID: <a55ee3140901180659v709741e6ue8388b4d33ec61e6@mail.gmail.com>

>> This works. I had a look at changing the llvm-config.in.in but my Perl hacking
>> skills aren't up to getting --libnames and --libfiles to work as well as --libs.
>
> Would you like to file a bug report? This is the way of getting it
> fixed.

Done (3347)

> This one also deserves a bug report. My guess is that llvm-config is
> throwing backslashes (\) which are escaped at some intermediate point
> and finally translated to double slashes by MSYS.

3348 - I've taken the liberty of pasting your comment here into the report.

Duncan Pierce

From duncan at duncanpierce.org  Sun Jan 18 09:13:15 2009
From: duncan at duncanpierce.org (Duncan Pierce)
Date: Sun, 18 Jan 2009 15:13:15 +0000
Subject: [LLVMdev] Build problems on MinGW solved - possible llvm-config
	bug
In-Reply-To: <b087fca00901180702n945910bw8c751968179a4a16@mail.gmail.com>
References: <a55ee3140901131350y19394560hb517ec4904ded01f@mail.gmail.com>
	<F5B5098E-9E47-4BEF-ABA3-AACB5F5FB4F1@korobeynikov.info>
	<a55ee3140901170958l3206a256ke9a95612e4893515@mail.gmail.com>
	<b087fca00901171319l2e9f06b5udf4e25310ad61b32@mail.gmail.com>
	<a55ee3140901171404t41d0512fs9ed56ffd0ed990a6@mail.gmail.com>
	<m3ab9py2jq.fsf@telefonica.net>
	<loom.20090118T124307-115@post.gmane.org>
	<b087fca00901180702n945910bw8c751968179a4a16@mail.gmail.com>
Message-ID: <a55ee3140901180713u42c4e5abm6a6d482db75f902d@mail.gmail.com>

2009/1/18 Anton Korobeynikov <anton at korobeynikov.info>:
> Hello, Duncan
>
>> I discovered one other thing that was causing me problems on MinGW: if I use the
>> msys.bat to open a terminal llvm-config inserts double slashes at the start of
>> any absolute path it generates (e.g. //lib/LLVMX86CodeGen.o) - this breaks g++.

> That's strange, never seen this before. Do you have two different
> version of perl installed? (for example, one msys DTK and another one
> - standalone ActivePerl, etc.)

I have a /usr/bin/perl.exe (bash under DOS prompt finds this one) and
a /bin/perl.exe (msys.bat finds this one). But these are the same
according to diff --binary. I only installed one. In fact, I deleted
my entire first MinGW installation when I first found I couldn't llvm
working and reinstalled cleanly, using perl from msys.

Duncan

From sanjiv.gupta at microchip.com  Sun Jan 18 12:43:43 2009
From: sanjiv.gupta at microchip.com (sanjiv gupta)
Date: Mon, 19 Jan 2009 00:13:43 +0530
Subject: [LLVMdev] PIC16 backend for llvm 2.5
In-Reply-To: <200901161003.35470.baldrick@free.fr>
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
	<200901091253.24536.baldrick@free.fr>
	<F536B7C316F9474E9F7091239725AC9A01D76884@CHN-CL-MAIL01.mchp-main.com>
	<200901161003.35470.baldrick@free.fr>
Message-ID: <1232304223.3019.4.camel@idc-lt-i00171.microchip.com>

On Fri, 2009-01-16 at 10:03 +0100, Duncan Sands wrote:
> Hi Sanjiv,
> 
> > Well the magnitude of the task is not small.
> > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle
> > illegal operands. So we will need to change the interface of
> > LowerOperation() to pass an extra argument called Results, which is an
> > array of SDValue. Targets will push the result values in this array and
> > then we can replace values in ExpandIntegerOperand(). Very much like
> > what CustomLowerResults() and ReplaceNodeResults() are doing currently.
> > 
> > The problem is that do we want to change calls to LowerOperation() in
> > LegalizeDAG as well? I think probably that is the right approach to go
> > in the longer term. But currently I suggest that "Results" be the last
> > argument to LowerOperation() which is defaulted to NULL. That way
> > LegalizeDAG and all targets will continue to work the current way, plus
> > targets like ours that want to use the last argument (i.e. "Results")
> > can use them in ExapndIntegerOperand().
> 
> do you need this for operation legalization (LegalizeDAG) as well as
> type legalization?  If not, then you can introduce a new method like
> ReplaceNodeResults for custom type legalization of operands (or just
> use ReplaceNodeResults for this too - I don't immediately see any
> reason why not), and have it call LowerOperation by default.  Actually,
> if you also want this for LegalizeDAG too, you can introduce a new method
> which is only called in places that need it; everywhere else can still
> use LowerOperation (of course in the long term there should be just one
> method, but this way you can do things incrementally).  I don't much
> like the idea of having Results be NULL.  I'd rather the interface was
> uniform, and have any tricks be in the body of the method.
> 
> Ciao,
> 
> Duncan.
Thanks Duncan for your suggestions. We have worked out a patch
accordingly. The patch is attached, let me know if it looks okay to
commit.

Thanks,
Sanjiv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 10530 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/ecff7e12/attachment.bin 

From baldrick at free.fr  Sun Jan 18 13:28:14 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sun, 18 Jan 2009 20:28:14 +0100
Subject: [LLVMdev] PIC16 backend for llvm 2.5
In-Reply-To: <1232304223.3019.4.camel@idc-lt-i00171.microchip.com>
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
	<200901161003.35470.baldrick@free.fr>
	<1232304223.3019.4.camel@idc-lt-i00171.microchip.com>
Message-ID: <200901182028.15320.baldrick@free.fr>

Hi Sanjiv,

> +  /// CustomLowerOperation - This callback is invoked for operations that are
> +  /// unsupported by the target, which are registered to use 'custom' lowering,
> +  /// and whose defined values are all legal.

and whose defined values are all legal -> and whose return values all have legal types

> +  /// If the target has no operations that require custom lowering, it need not
> +  /// implement this.

This comment and the name seem too generic for me.  This method is for use when
an operand has an illegal type, right?  Yet the comment makes no mention of this.
There's also of no mention of the fact that you are allowed to not place anything
in Results, and what that means.

Also, is there any reason not to use ReplaceNodeResults rather than introducing
a new method for type legalization?

> +    case ISD::ANY_EXTEND:   
> +      Results.push_back(PromoteIntOp_ANY_EXTEND(N)); break;

This is wrong if PromoteIntOp_ANY_EXTEND returned a value with
no node.  Likewise for all the others.  Better I think to simply
handle the custom case immediately and return rather than trying
to share code with these other cases.

Also, you could just make DAGTypeLegalizer::CustomLowerResults
more general, and use that.

Ciao,

Duncan.

From fw at deneb.enyo.de  Sun Jan 18 15:27:37 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 18 Jan 2009 22:27:37 +0100
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <4aca3dc20901171052w143978c9qc3b75dbd19c3816e@mail.gmail.com>
	(Daniel Berlin's message of "Sat, 17 Jan 2009 13:52:44 -0500")
References: <loom.20090117T181238-366@post.gmane.org>
	<4aca3dc20901171052w143978c9qc3b75dbd19c3816e@mail.gmail.com>
Message-ID: <87k58s5mpi.fsf@mid.deneb.enyo.de>

* Daniel Berlin:

> It's nice that he claims it's way too high overhead without any, you
> know, data.

I was quite suprised by the performance of the conservative
Boehm-Demers-Weiser collector, even in cases where I thought it was
sub-par.  So benchmarking available solutions makes sense indeed. 8-)

(Lack of continuations is probably a better excuse if you don't want
to use LLVM, especially if you don't want to perform whole-program
analysis.)

From michael at schuerig.de  Sun Jan 18 19:07:45 2009
From: michael at schuerig.de (Michael Schuerig)
Date: Mon, 19 Jan 2009 02:07:45 +0100
Subject: [LLVMdev] PATCH: llvm-top git support and out-of-tree building for
	llvm
Message-ID: <200901190207.46108.michael@schuerig.de>


What: The original scripts in llvm-top assume that they're dealing with 
a subversion working copy. The patch adds support for a git repository 
cloned using git svn.

The other two patches make llvm (core) do an out-of-tree build, i.e., 
the source tree is kept clean, and tells llvm-gcc-4.2 to find llvm in 
the right (new) place.

Why: Using git it is possible to fiddle locally with the code, have the 
original as well as the changes in version control, and keep up with 
updates from the central SVN repository.

Out-of-tree builds make it easier to distinguish what files are changed, 
added, or generated.

Michael

-- 
Michael Schuerig
mailto:michael at schuerig.de
http://www.schuerig.de/michael/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-gcc-out-of-tree.diff
Type: text/x-diff
Size: 1212 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/ab2b868a/attachment-0003.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-out-of-tree.diff
Type: text/x-diff
Size: 1658 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/ab2b868a/attachment-0004.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-top-git.diff
Type: text/x-diff
Size: 2714 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/ab2b868a/attachment-0005.bin 

From howarth at bromo.med.uc.edu  Sun Jan 18 19:11:39 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Sun, 18 Jan 2009 20:11:39 -0500
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still produces
	-Wformat/-Wformat-security
Message-ID: <20090119011139.GA7602@bromo.med.uc.edu>

   The current llvm/llvm-gcc-4.2 svn when built on
i686-apple-darwin9 still produces the bogus warnings...

f951: warning: command line option "-Wformat" is valid for C/C++/ObjC/ObjC++ but not for Fortran
f951: warning: command line option "-Wformat-security" is valid for C/C++/ObjC/ObjC++ but not for Fortran

whenc compling any code with gfortran. This causes the gfortran testsuite
in gcc-4.2 to fail any test for compilation errors. Can we get this fixed
before the llvm 2.5 release?
           Jack


From isanbard at gmail.com  Sun Jan 18 20:07:32 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sun, 18 Jan 2009 18:07:32 -0800
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still produces
	-Wformat/-Wformat-security
In-Reply-To: <20090119011139.GA7602@bromo.med.uc.edu>
References: <20090119011139.GA7602@bromo.med.uc.edu>
Message-ID: <3DB4E054-0F8D-4F60-B9BA-C4C6575D654A@gmail.com>

On Jan 18, 2009, at 5:11 PM, Jack Howarth wrote:

>   The current llvm/llvm-gcc-4.2 svn when built on
> i686-apple-darwin9 still produces the bogus warnings...
>
> f951: warning: command line option "-Wformat" is valid for C/C++/ 
> ObjC/ObjC++ but not for Fortran
> f951: warning: command line option "-Wformat-security" is valid for  
> C/C++/ObjC/ObjC++ but not for Fortran
>
> whenc compling any code with gfortran. This causes the gfortran  
> testsuite
> in gcc-4.2 to fail any test for compilation errors. Can we get this  
> fixed
> before the llvm 2.5 release?

Hi Jack,

Could you craft a patch for this? Not many of us compile gfortran on  
our boxes.

-bw


From mierle at gmail.com  Sun Jan 18 22:29:23 2009
From: mierle at gmail.com (Keir Mierle)
Date: Sun, 18 Jan 2009 23:29:23 -0500
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <loom.20090117T181238-366@post.gmane.org>
References: <loom.20090117T181238-366@post.gmane.org>
Message-ID: <ef5675f30901182029x702c3632n638368e5a2105764@mail.gmail.com>

And the followup:

http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-wont-replace-c.html

On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at codedgers.com> wrote:
>
> This may be of interest:
>
> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>
> People implementing a new Haskell compiler explain why LLVM is an
> unsuitable target for them.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From nicholas at mxc.ca  Sun Jan 18 22:36:57 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sun, 18 Jan 2009 20:36:57 -0800
Subject: [LLVMdev] Criticism of garbage collection support in LLVM
In-Reply-To: <ef5675f30901182029x702c3632n638368e5a2105764@mail.gmail.com>
References: <loom.20090117T181238-366@post.gmane.org>
	<ef5675f30901182029x702c3632n638368e5a2105764@mail.gmail.com>
Message-ID: <49740369.6010209@mxc.ca>

Keir Mierle wrote:
> And the followup:
> 
> http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-wont-replace-c.html

And if you're pointing to that, you should probably also read the next 
followup:

http://lhc-compiler.blogspot.com/2009/01/llvm-is-great.html

Nick

> On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at codedgers.com> wrote:
>> This may be of interest:
>>
>> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>>
>> People implementing a new Haskell compiler explain why LLVM is an
>> unsuitable target for them.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


From anton at korobeynikov.info  Mon Jan 19 00:42:15 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 19 Jan 2009 09:42:15 +0300
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still produces
	-Wformat/-Wformat-security
In-Reply-To: <3DB4E054-0F8D-4F60-B9BA-C4C6575D654A@gmail.com>
References: <20090119011139.GA7602@bromo.med.uc.edu>
	<3DB4E054-0F8D-4F60-B9BA-C4C6575D654A@gmail.com>
Message-ID: <b087fca00901182242s51986ed1oc3f0f6617b5967c6@mail.gmail.com>

Hello, Bill

> Could you craft a patch for this? Not many of us compile gfortran on
> our boxes.
The intention is to have fortran frontend built by default for LLVM
2.5+ (on darwin). And this apple-local problem seems to be the only
show-stopper.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From isanbard at gmail.com  Mon Jan 19 01:51:09 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sun, 18 Jan 2009 23:51:09 -0800
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still produces
	-Wformat/-Wformat-security
In-Reply-To: <b087fca00901182242s51986ed1oc3f0f6617b5967c6@mail.gmail.com>
References: <20090119011139.GA7602@bromo.med.uc.edu>
	<3DB4E054-0F8D-4F60-B9BA-C4C6575D654A@gmail.com>
	<b087fca00901182242s51986ed1oc3f0f6617b5967c6@mail.gmail.com>
Message-ID: <5B787D75-F310-4F4E-A4E7-E41FF44D163B@gmail.com>

On Jan 18, 2009, at 10:42 PM, Anton Korobeynikov wrote:

> Hello, Bill
>
>> Could you craft a patch for this? Not many of us compile gfortran on
>> our boxes.
> The intention is to have fortran frontend built by default for LLVM
> 2.5+ (on darwin). And this apple-local problem seems to be the only
> show-stopper.
>
This whole "warning" thing is a huge pain in the b*tt. I just  
submitted a patch that would enable it by default only on Darwin  
machines. Please check it out and see if it helps you.

-bw


From baldrick at free.fr  Mon Jan 19 02:32:37 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 19 Jan 2009 09:32:37 +0100
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still produces
	-Wformat/-Wformat-security
In-Reply-To: <3DB4E054-0F8D-4F60-B9BA-C4C6575D654A@gmail.com>
References: <20090119011139.GA7602@bromo.med.uc.edu>
	<3DB4E054-0F8D-4F60-B9BA-C4C6575D654A@gmail.com>
Message-ID: <200901190932.37830.baldrick@free.fr>

> Could you craft a patch for this? Not many of us compile gfortran on  
> our boxes.

It's very easy to build (just add fortran to the list of languages), so...
why not?  This would help catch changes that break non-C languages (these
seem to happen at every sync with Apple...).

Ciao,

Duncan.

From baldrick at free.fr  Mon Jan 19 02:58:18 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 19 Jan 2009 09:58:18 +0100
Subject: [LLVMdev] PATCH: llvm-top git support and out-of-tree building
	for llvm
In-Reply-To: <200901190207.46108.michael@schuerig.de>
References: <200901190207.46108.michael@schuerig.de>
Message-ID: <200901190958.18259.baldrick@free.fr>

Hi Michael,

> What: The original scripts in llvm-top assume that they're dealing with 
> a subversion working copy. The patch adds support for a git repository 
> cloned using git svn.
> 
> The other two patches make llvm (core) do an out-of-tree build, i.e., 
> the source tree is kept clean, and tells llvm-gcc-4.2 to find llvm in 
> the right (new) place.
> 
> Why: Using git it is possible to fiddle locally with the code, have the 
> original as well as the changes in version control, and keep up with 
> updates from the central SVN repository.
> 
> Out-of-tree builds make it easier to distinguish what files are changed, 
> added, or generated.

these look good to me, but unfortunately I am unable to test them for
the moment, otherwise I would have applied them.

Ciao,

Duncan.

From michael at schuerig.de  Mon Jan 19 03:18:48 2009
From: michael at schuerig.de (Michael Schuerig)
Date: Mon, 19 Jan 2009 10:18:48 +0100
Subject: [LLVMdev] PATCH: llvm-top git support and out-of-tree building
	for llvm
In-Reply-To: <200901190958.18259.baldrick@free.fr>
References: <200901190207.46108.michael@schuerig.de>
	<200901190958.18259.baldrick@free.fr>
Message-ID: <200901191018.49080.michael@schuerig.de>

On Monday 19 January 2009, Duncan Sands wrote:
> these look good to me, but unfortunately I am unable to test them for
> the moment, otherwise I would have applied them.

Please don't skip the testing. I'm pretty new to LLVM and not a git 
expert either, so my changes may introduce subtle or not so subtle 
problems that I didn't think of.

Michael

-- 
Michael Schuerig
mailto:michael at schuerig.de
http://www.schuerig.de/michael/

From isanbard at gmail.com  Mon Jan 19 05:07:39 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 19 Jan 2009 03:07:39 -0800
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still produces
	-Wformat/-Wformat-security
In-Reply-To: <200901190932.37830.baldrick@free.fr>
References: <20090119011139.GA7602@bromo.med.uc.edu>
	<3DB4E054-0F8D-4F60-B9BA-C4C6575D654A@gmail.com>
	<200901190932.37830.baldrick@free.fr>
Message-ID: <B31B4C84-640D-4BDE-B181-B72B5DBAB1E4@gmail.com>

We've started cracking down on these types of errors. I actually did  
what you suggested. And fortran built (Yay). :-)

I may introduce it into our buildbot setup at some point. I also need  
to include the LLVM-gcc testsuite into buildbot as well, but that's  
trickier.

-bw

On Jan 19, 2009, at 12:32 AM, Duncan Sands <baldrick at free.fr> wrote:

>> Could you craft a patch for this? Not many of us compile gfortran on
>> our boxes.
>
> It's very easy to build (just add fortran to the list of languages),  
> so...
> why not?  This would help catch changes that break non-C languages  
> (these
> seem to happen at every sync with Apple...).
>
> Ciao,
>
> Duncan.

From baldrick at free.fr  Mon Jan 19 07:22:02 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 19 Jan 2009 14:22:02 +0100
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still produces
	-Wformat/-Wformat-security
In-Reply-To: <B31B4C84-640D-4BDE-B181-B72B5DBAB1E4@gmail.com>
References: <20090119011139.GA7602@bromo.med.uc.edu>
	<200901190932.37830.baldrick@free.fr>
	<B31B4C84-640D-4BDE-B181-B72B5DBAB1E4@gmail.com>
Message-ID: <200901191422.03052.baldrick@free.fr>

On Monday 19 January 2009 12:07:39 Bill Wendling wrote:
> We've started cracking down on these types of errors. I actually did  
> what you suggested. And fortran built (Yay). :-)
> 
> I may introduce it into our buildbot setup at some point. I also need  
> to include the LLVM-gcc testsuite into buildbot as well, but that's  
> trickier.

Yay!

Thanks for doing this,

Duncan.

From jay.foad at gmail.com  Mon Jan 19 09:44:01 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Mon, 19 Jan 2009 15:44:01 +0000
Subject: [LLVMdev] cygwin build patch
Message-ID: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>

LLVM doesn't build out of the box on Cygwin, because Cygwin defines
uint32_t as "unsigned long" rather than "unsigned int".

The attached patch allows me to build head of svn (rev 62510) on
Cygwin using GCC 4. Can this be committed please?

I realise that the DataTypes.h.in part might be controversial. Also,
there's probably a better place to put it, but I'm not sure where.

Thanks,
Jay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygwin.patch
Type: application/octet-stream
Size: 2938 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/7c7e21b7/attachment.obj 

From aph at redhat.com  Mon Jan 19 09:55:04 2009
From: aph at redhat.com (Andrew Haley)
Date: Mon, 19 Jan 2009 15:55:04 +0000
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
Message-ID: <4974A258.1040108@redhat.com>

This is x86_64.  I have a problem where an absolute memory load

define i32 @foo() {
entry:
        %0 = load i32* inttoptr (i64 12704196 to i32*)          ; <i32> [#uses=1]
        ret i32 %0
}

generates incorrect code on LLVM 2.4:

0x7ffff6d54010:	mov    0xc1d9c4(%rip),%eax        # 0x7ffff79719da
0x7ffff6d54016:	retq

should be

0x7ffff6d54010:	mov    0xc1d9c4, %eax
0x7ffff6d54016:	retq

i.e. the IP-relative addressing mode is incorrect.

The current LLVM trunk does not have this bug.  This seems quite a nasty
bug; is there any chance of a bug-fix release for LLVM 2.4, or should I
just use LLVM trunk until LLVM 2.5 ?

Andrew.


#include <llvm/Module.h>
#include <llvm/Function.h>
#include <llvm/PassManager.h>
#include <llvm/CallingConv.h>
#include <llvm/Analysis/Verifier.h>
#include <llvm/Assembly/PrintModulePass.h>
#include <llvm/Support/IRBuilder.h>
#include <llvm/Support/Debug.h>
#include <llvm/ExecutionEngine/ExecutionEngine.h>
#include <llvm/ModuleProvider.h>
#include <llvm/Assembly/PrintModulePass.h>
#include <llvm/Support/raw_ostream.h>
#include <stdio.h>



using namespace llvm;

Module *makeLLVMModule ();

Function *foo;

int
main (int argc, char **argv)
{
  Module *Mod = makeLLVMModule ();
  verifyModule (*Mod, PrintMessageAction);

  PassManager PM;
  PM.add (new PrintModulePass ());
  PM.run (*Mod);

  ExecutionEngine *engine = ExecutionEngine ::create(Mod);

//   DebugFlag = true;
//   CurrentDebugType = "x86-emitter";

  typedef int (*pf)();
  pf F = (pf)engine->getPointerToFunction(foo);
  int res = F();

  printf ("ret = %d\n", res);

  delete Mod;
  return 0;
}

int32_t p = 99;

Module *
makeLLVMModule ()
{
  // Module Construction
  Module *mod = new Module ("test");

  Constant *c
    = mod->getOrInsertFunction ("foo", IntegerType::get(32),
				NULL);

  foo = cast <Function> (c);

  BasicBlock *block = BasicBlock::Create ("entry", foo);
  IRBuilder<> builder (block);

  Value *tmp = ConstantInt::get(Type::Int64Ty, (long)&p);
  tmp = builder.CreateIntToPtr(tmp,
			       PointerType::getUnqual(IntegerType::get(32)));
  tmp = builder.CreateLoad(tmp);

  builder.CreateRet (tmp);

  return mod;
}

From ofv at wanadoo.es  Mon Jan 19 10:25:21 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Mon, 19 Jan 2009 17:25:21 +0100
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
References: <4974A258.1040108@redhat.com>
Message-ID: <m3bpu3w9e6.fsf@telefonica.net>

Andrew Haley <aph at redhat.com> writes:

> This is x86_64.  I have a problem where an absolute memory load
>
> define i32 @foo() {
> entry:
>         %0 = load i32* inttoptr (i64 12704196 to i32*)          ; <i32> [#uses=1]
>         ret i32 %0
> }
>
> generates incorrect code on LLVM 2.4:
>
> 0x7ffff6d54010:	mov    0xc1d9c4(%rip),%eax        # 0x7ffff79719da
> 0x7ffff6d54016:	retq
>
> should be
>
> 0x7ffff6d54010:	mov    0xc1d9c4, %eax
> 0x7ffff6d54016:	retq
>
> i.e. the IP-relative addressing mode is incorrect.

This seems the same as

http://www.llvm.org/bugs/show_bug.cgi?id=2920

which was fixed by an unknown change after the 2.4 release.

> The current LLVM trunk does not have this bug.  This seems quite a nasty
> bug; is there any chance of a bug-fix release for LLVM 2.4, or should I
> just use LLVM trunk until LLVM 2.5 ?

As there ar not 2.x.y releases, your only option is to use LLVM trunk.

-- 
Oscar


From ofv at wanadoo.es  Mon Jan 19 10:40:16 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Mon, 19 Jan 2009 17:40:16 +0100
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
References: <4974A258.1040108@redhat.com>
Message-ID: <m363kbw8pb.fsf@telefonica.net>

Andrew Haley <aph at redhat.com> writes:

> This is x86_64.  I have a problem where an absolute memory load
>
> define i32 @foo() {
> entry:
>         %0 = load i32* inttoptr (i64 12704196 to i32*)          ; <i32> [#uses=1]
>         ret i32 %0
> }
>
> generates incorrect code on LLVM 2.4:
>
> 0x7ffff6d54010:	mov    0xc1d9c4(%rip),%eax        # 0x7ffff79719da
> 0x7ffff6d54016:	retq

IIRC, one workaround is to use a GlobalValue instead of a IntToPtr on a
Constant.

-- 
Oscar


From patrick.boettcher at desy.de  Mon Jan 19 11:17:46 2009
From: patrick.boettcher at desy.de (Patrick Boettcher)
Date: Mon, 19 Jan 2009 18:17:46 +0100 (CET)
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
Message-ID: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>

Hi list,

in our LLVM-based-project we are writing a backend for our processor. The 
architecture is a quite straight-forward RISC, but it does not have 
hardware interlocks, i.e. data hazards involving memory access must be 
resolved by the compiler, either by scheduling unrelated instructions or 
by inserting NOOPs into the load delay slots:

----

For example, code which looks like that:

load 0x1234, reg1
noop
noop
add reg1, 1
load 0x1236, reg2

can be safely transformed to:

load 0x1234, reg1
load 0x1236, reg2
noop
add reg1, 1

----

It pleased us quite a lot when we found the HazardRecognizer-class.
Without much effort we could assist LLVM to transform code like shown
above (with simple (SDUse, delayCount)-map).

Unfortunately we found now out that the HazardRecognizer is used only
before register allocation, and the register allocator obviously may
reschedule instructions, but doesn't take hazard recognition into account.

Is there a switch/option we overlooked to bind the hazardRecognizer to the
register-allocator?

And more generally: Is the hazardRecognizer the right and only way to 
solve our NOOP-minimizing problem?

thanks for your help in advance,
Patrick and Christian

From criswell at ad.uiuc.edu  Mon Jan 19 11:27:59 2009
From: criswell at ad.uiuc.edu (Criswell, John T)
Date: Mon, 19 Jan 2009 11:27:59 -0600
Subject: [LLVMdev] poolallocation error
In-Reply-To: <85a4cc050901160828q33b0d142yf8d17780bf167fc6@mail.gmail.com>
References: <577C4E7D-1571-446B-9C3B-7B39308159E1@liacs.nl>,
	<85a4cc050901160828q33b0d142yf8d17780bf167fc6@mail.gmail.com>
Message-ID: <32AC7D48FD55284CB56FE956E7F9FCD218FD9E1F67@DSMAILBOX.ad.uiuc.edu>

Dear Prakash,

Yes, DSA is still in active use, although nobody else uses the -ds-aa pass as far as I know.

I tried the below sample (although ds-aa should be in libLLVMDataStructure.so and not libpoolalloc.so), and I get the same error.  I've seen similar problems with other passes in our work here.  My guess is that -ds-aa is requiring two passes that claim to invalidate each other; this causes a circular dependency that the pass manager cannot resolve.

I'm busy with another task this week, but if I find time, I might be able to investigate the problem and devise a solution.  If you want to try fixing it in the meantime, here's what I'd suggest doing:

1) Look at all the DSA passes required by -ds-aa.
2) Change those passes so that they clone the DSGraphs of the DSA passes upon which they depend.  To do this, look for calls to init() and change the second parameter from false to true.
3) Change the dependencies in the pass's getAnalysisUsage() method so that they preserve all passes (i.e. AU.setPreservedAll()).

Note that this will greatly increase memory usage, but it will allow each DSA pass to remain valid even when later DSA passes are run.

-- John T.

________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Prakash Prabhu [prakash.prabhu at gmail.com]
Sent: Friday, January 16, 2009 10:28 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] poolallocation error

Hi all,

I too am getting this error for x86_64 when I am trying to use the
Data Structure Analysis ...I svn upped both the llvm main branch and
the poolalloc today in the morning and recompiled everything from
scratch :

$ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libpoolalloc.so
-ds-aa < o.bc

opt: /home/pprabhu/llvm/llvm/lib/VMCore/PassManager.cpp:1418: virtual
void llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
llvm::Pass*): Assertion `(P->getPotentialPassManagerType() <
RequiredPass->getPotentialPassManagerType()) && "Unable to handle Pass
that requires lower level Analysis pass"' failed.
0   opt       0x0000000000a3fcd0
1   opt       0x0000000000a40024
2   libc.so.6 0x00007f9fc318a100
3   libc.so.6 0x00007f9fc318a095 gsignal + 53
4   libc.so.6 0x00007f9fc318baf0 abort + 272
5   libc.so.6 0x00007f9fc31832df __assert_fail + 239
6   opt       0x00000000009caeac
llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
llvm::Pass*) + 252
7   opt       0x00000000009cbe53 llvm::PMDataManager::add(llvm::Pass*,
bool) + 899
8   opt       0x00000000009cc296
llvm::ModulePass::assignPassManager(llvm::PMStack&,
llvm::PassManagerType) + 132
9   opt       0x00000000009d5ff9
llvm::PassManagerImpl::addTopLevelPass(llvm::Pass*) + 227
10  opt       0x00000000009cad7e
llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 500
11  opt       0x00000000009d6118 llvm::PassManagerImpl::add(llvm::Pass*) + 36
12  opt       0x00000000009cada7 llvm::PassManager::add(llvm::Pass*) + 33
13  opt       0x00000000006e5cd3
14  opt       0x00000000006e7a6d main + 3237
15  libc.so.6 0x00007f9fc31761c4 __libc_start_main + 244
16  opt       0x00000000006d7c19 __gxx_personality_v0 + 721
Aborted


Is there something that I am missing on the command line ? Does anyone
use DSA actively now ?

Thanks for your time.

- Prakash

On Wed, Nov 19, 2008 at 8:59 AM, Mattias Holm <holm at liacs.nl> wrote:
> Hi,
>
> I am trying to use the poolallocator. More specific, I am trying to
> play around with the pointer compression pass. Though, I get assertion
> failures for the pass dependencies.
>
> This is when it in PointerCompress::getAnalysisUsage tries to register
> the the BU pass as required. I.e. when
> AU.addRequired<CompleteBUDataStructures>(); is called.
>
>
> $ opt -f -load ~/Projects/llvmstuff/opt/poolalloc/lib/
> libpoolalloc.dylib -raiseallocs -poolalloc-passing-all-pools -
> pointercompress llist-noopt.bc -o llist-dp.bc
>
> Assertion failed: ((P->getPotentialPassManagerType() < RequiredPass-
>  >getPotentialPassManagerType()) && "Unable to handle Pass that
> requires lower level Analysis pass"), function
> addLowerLevelRequiredPass, file ~/Projects/llvmstuff/llvm/lib/VMCore/
> PassManager.cpp, line 1418.
>
> Any ideas what is going wrong here?
>
>
> /Mattias
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From mrs at apple.com  Mon Jan 19 12:02:42 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Jan 2009 10:02:42 -0800
Subject: [LLVMdev] avoid creating .dir files
Message-ID: <3B14683F-547E-49E9-8DFE-BB35FED0D124@apple.com>

There isn't a good reason to create files called .dir in the  
installation directory.  This patch fixes that.

Ok?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-1.patch
Type: application/octet-stream
Size: 495 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/2086e82a/attachment.obj 
-------------- next part --------------


From mrs at apple.com  Mon Jan 19 12:05:10 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Jan 2009 10:05:10 -0800
Subject: [LLVMdev] clang installation
Message-ID: <0800AFA2-64C2-4055-960F-043443337918@apple.com>

This patch adds targets to support the installation of clang in  
isolation.

Ok?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-2.patch
Type: application/octet-stream
Size: 952 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/39061b42/attachment.obj 
-------------- next part --------------


From mrs at apple.com  Mon Jan 19 12:08:29 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Jan 2009 10:08:29 -0800
Subject: [LLVMdev] building clang when present
Message-ID: <B7AEB01A-6D62-4C0E-B866-32BF92F24C23@apple.com>

This patch eases building clang when present in the source tree.   
Since clang is revlocked to llvm, one usually updates them together,  
and builds them together.

Ok?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-3.patch
Type: application/octet-stream
Size: 794 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/7af7ed8a/attachment.obj 
-------------- next part --------------


From evan.cheng at apple.com  Mon Jan 19 12:17:06 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 19 Jan 2009 10:17:06 -0800
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
Message-ID: <4E71A380-CB54-415F-822C-3285FEB44221@apple.com>


On Jan 19, 2009, at 9:17 AM, Patrick Boettcher wrote:

> Hi list,
>
> in our LLVM-based-project we are writing a backend for our  
> processor. The
> architecture is a quite straight-forward RISC, but it does not have
> hardware interlocks, i.e. data hazards involving memory access must be
> resolved by the compiler, either by scheduling unrelated  
> instructions or
> by inserting NOOPs into the load delay slots:
>
> ----
>
> For example, code which looks like that:
>
> load 0x1234, reg1
> noop
> noop
> add reg1, 1
> load 0x1236, reg2
>
> can be safely transformed to:
>
> load 0x1234, reg1
> load 0x1236, reg2
> noop
> add reg1, 1
>
> ----
>
> It pleased us quite a lot when we found the HazardRecognizer-class.
> Without much effort we could assist LLVM to transform code like shown
> above (with simple (SDUse, delayCount)-map).
>
> Unfortunately we found now out that the HazardRecognizer is used only
> before register allocation, and the register allocator obviously may
> reschedule instructions, but doesn't take hazard recognition into  
> account.

The register allocator doesn't reschedule code. It can coalesce  
copies, commute instructions, and do re-materialization, etc. It's not  
clear what kind of problems you are running it.

>
>
> Is there a switch/option we overlooked to bind the hazardRecognizer  
> to the
> register-allocator?
>
> And more generally: Is the hazardRecognizer the right and only way to
> solve our NOOP-minimizing problem?

Perhaps you want to do this after register allocation is done. Dan is  
developing the post-allocation scheduler. You can try it out.

Evan

>
>
> thanks for your help in advance,
> Patrick and Christian
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From ofv at wanadoo.es  Mon Jan 19 12:18:48 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Mon, 19 Jan 2009 19:18:48 +0100
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
In-Reply-To: <4974B86D.7000505@redhat.com> (Andrew Haley's message of "Mon, 19
	Jan 2009 17:29:17 +0000")
References: <4974A258.1040108@redhat.com> <m363kbw8pb.fsf@telefonica.net>
	<4974B86D.7000505@redhat.com>
Message-ID: <m3zlhnupkn.fsf@telefonica.net>

Andrew Haley <aph at redhat.com> writes:

> ?scar Fuentes wrote:
>> The following message is a courtesy copy of an article
>> that has been posted to gmane.comp.compilers.llvm.devel as well.
>> 
>> Andrew Haley <aph at redhat.com> writes:
>> 
>>> This is x86_64.  I have a problem where an absolute memory load
>>>
>>> define i32 @foo() {
>>> entry:
>>>         %0 = load i32* inttoptr (i64 12704196 to i32*)          ; <i32> [#uses=1]
>>>         ret i32 %0
>>> }
>>>
>>> generates incorrect code on LLVM 2.4:
>>>
>>> 0x7ffff6d54010:	mov    0xc1d9c4(%rip),%eax        # 0x7ffff79719da
>>> 0x7ffff6d54016:	retq
>> 
>> IIRC, one workaround is to use a GlobalValue instead of a IntToPtr on a
>> Constant.
>
> Err, how?  I can't figure out how to do it.  The only documentation for
> GlobalValue describes it as a superclass of GlobalVariables and Functions.

IIRC, the stuff I used was something like...

GlobalVariable *gv = new GlobalVariable( /* your pointer type */,
                         other required parameters...);
AddGlobalMapping(gv, your_pointer_value); // i.e. (void*)0x938742

then, where you use

  Constant* thp = ConstantExpr::getCast(Instruction::IntToPtr,
  your_pointer_value, /* i.e. 0x938742 */
  /* your pointer type */);

/* Now use thp */

change it to

/* Now just use gv */

GetGlobalValueAtAddress may be useful for housekeeping.

If something is wrong or not as effcient as it could be, I hope someone
on the mailing list will correct me.

-- 
Oscar


From evan.cheng at apple.com  Mon Jan 19 12:18:58 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 19 Jan 2009 10:18:58 -0800
Subject: [LLVMdev] Using CallingConvLower in ARM target
In-Reply-To: <305d6f60901161726l5c93c9dag6f98ca06a420cb31@mail.gmail.com>
References: <305d6f60812270430xdf1ebb9gf6d99f94215ab66b@mail.gmail.com>
	<F347CFB9-8B14-4BE9-8B57-856601D1E786@apple.com>
	<305d6f60901161726l5c93c9dag6f98ca06a420cb31@mail.gmail.com>
Message-ID: <9F8572A5-4F58-492D-A61B-638FC61D42B4@apple.com>


On Jan 16, 2009, at 5:26 PM, Sandeep Patel wrote:

> On Sat, Jan 3, 2009 at 11:46 AM, Dan Gohman <gohman at apple.com> wrote:
>>
>> One problem with this approach is that since i64 isn't legal, the
>> bitcast would require custom C++ code in the ARM target to
>> handle properly.  It might make sense to introduce something
>> like
>>
>>   CCIfType<[f64], CCCustom>
>>
>> where CCCustom is a new entity that tells the calling convention
>> code to to let the target do something not easily representable
>> in the tablegen minilanguage.
>
> I am thinking that this requires two changes: add a flag to
> CCValAssign (take a bit from HTP) to indicate isCustom and a way to
> author an arbitrary CCAction by including the source directly in the
> TableGen mini-language. This latter change might want a generic change
> to the TableGen language. For example, the syntax might be like:
>
> class foo : CCCustomAction {
> code <<< EOF
>      ....multi-line C++ code goes here that allocates regs & mem and
> sets CCValAssign::isCustom....
> EOF
> }
>
> Does this seem reasonable? An alternative is for CCCustom to take a
> string that names a function to be called:
>
> CCIfType<[f64], CCCustom<"MyCustomLoweringFunc">>
>
> the function signature for such functions will have to return two
> results: if the CC processing is finished and if it the func succeeded
> or failed:

I like the second solution better. It seems rather cumbersome to embed  
multi-line c++ code in td files.

Evan
>
>
> typedef bool CCCustomFn(unsigned ValNo, MVT ValVT,
>                        MVT LocVT, CCValAssign::LocInfo LocInfo,
>                        ISD::ArgFlagsTy ArgFlags, CCState &State,  
> bool &result);
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From sanjiv.gupta at microchip.com  Mon Jan 19 12:21:55 2009
From: sanjiv.gupta at microchip.com (sanjiv gupta)
Date: Mon, 19 Jan 2009 23:51:55 +0530
Subject: [LLVMdev] PIC16 backend for llvm 2.5
In-Reply-To: <200901182028.15320.baldrick@free.fr>
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com>
	<200901161003.35470.baldrick@free.fr>
	<1232304223.3019.4.camel@idc-lt-i00171.microchip.com>
	<200901182028.15320.baldrick@free.fr>
Message-ID: <1232389315.4265.4.camel@idc-lt-i00171.microchip.com>

On Sun, 2009-01-18 at 20:28 +0100, Duncan Sands wrote:
> Hi Sanjiv,
> 
> > +  /// CustomLowerOperation - This callback is invoked for operations that are
> > +  /// unsupported by the target, which are registered to use 'custom' lowering,
> > +  /// and whose defined values are all legal.
> 
> and whose defined values are all legal -> and whose return values all have legal types
> 
Taken care of.

> > +  /// If the target has no operations that require custom lowering, it need not
> > +  /// implement this.
> 
> This comment and the name seem too generic for me.  This method is for use when
> an operand has an illegal type, right?  Yet the comment makes no mention of this.
> There's also of no mention of the fact that you are allowed to not place anything
> in Results, and what that means.
> 
Taken care of.

> Also, is there any reason not to use ReplaceNodeResults rather than introducing
> a new method for type legalization?
> 
ReplaceNodeResults and LowerOperation have been used for different
purposes by different targets, and have been implemented differently.
The former is meant to legalize illegal value types and the latter is
meant to legalize operations with illegal operands. So they might need
different treatments.

> > +    case ISD::ANY_EXTEND:   
> > +      Results.push_back(PromoteIntOp_ANY_EXTEND(N)); break;
> 
> This is wrong if PromoteIntOp_ANY_EXTEND returned a value with
> no node.  Likewise for all the others.  Better I think to simply
> handle the custom case immediately and return rather than trying
> to share code with these other cases.
> 
Taken care of.

> Also, you could just make DAGTypeLegalizer::CustomLowerResults
> more general, and use that.
> 
Taken care of.

The revised patch is attached.

> Ciao,
> 
> Duncan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 12606 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/a2cc7156/attachment-0001.bin 

From clattner at apple.com  Mon Jan 19 12:46:46 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 19 Jan 2009 10:46:46 -0800
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
In-Reply-To: <4974A258.1040108@redhat.com>
References: <4974A258.1040108@redhat.com>
Message-ID: <99AFFD84-D5A8-4094-8FB9-DDAD8E2AE20E@apple.com>


On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote:

> This is x86_64.  I have a problem where an absolute memory load
> The current LLVM trunk does not have this bug.  This seems quite a  
> nasty
> bug; is there any chance of a bug-fix release for LLVM 2.4, or  
> should I
> just use LLVM trunk until LLVM 2.5 ?

Hi Andrew,

As others have pointed out, using a global and addglobalmapping is a  
great workaround for the problem.

We generally don't do "dot" releases, since we have a short release  
cycle anyway.  The 2.5 release process is slated to start this week.

-Chris

From nicholas at mxc.ca  Mon Jan 19 12:50:47 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 19 Jan 2009 10:50:47 -0800
Subject: [LLVMdev] ocaml build system
Message-ID: <4974CB87.3050106@mxc.ca>

I have an issue with the OCaml build system and the ExecutionEngine.

PR2128 has a patch to change the Interpreter to use libffi. This breaks 
test/Bindings/Ocaml/executionengine.ml because OCaml doesn't try to link 
with libffi, even though llvm-config knows that we should:

   $ Debug/bin/llvm-config --ldflags interpreter
   -L/home/nicholas/llvm-commit/Debug/lib  -lpthread -lffi -ldl -lm -lelf

If I run 'ocamlc' by hand and pass it '-cclib -lffi', the test succeeds, 
so this is the only remaining problem. Is anyone familiar with how Ocaml 
knows what libraries to link against? We can't just pass `llvm-config 
--ldflags interpreter` to ocamlc because it doesn't support the -L argument.

Does anyone have any ideas how this ought to work?

Nick

PS. why is it Bindings/Ocaml and not Bindings/OCaml?

From patrick.boettcher at desy.de  Mon Jan 19 13:01:06 2009
From: patrick.boettcher at desy.de (Patrick Boettcher)
Date: Mon, 19 Jan 2009 20:01:06 +0100 (CET)
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <4E71A380-CB54-415F-822C-3285FEB44221@apple.com>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<4E71A380-CB54-415F-822C-3285FEB44221@apple.com>
Message-ID: <alpine.LRH.1.10.0901191952420.20397@pub4.ifh.de>

Hi Evan,

thanks for your response.

On Mon, 19 Jan 2009, Evan Cheng wrote:
>> For example, code which looks like that:
>>
>> load 0x1234, reg1
>> noop
>> noop
>> add reg1, 1
>> load 0x1236, reg2
>>
>> can be safely transformed to:
>>
>> load 0x1234, reg1
>> load 0x1236, reg2
>> noop
>> add reg1, 1
>>

> The register allocator doesn't reschedule code. It can coalesce
> copies, commute instructions, and do re-materialization, etc.

Sorry for using the wrong vocabulary.

> It's not clear what kind of problems you are running it.

When we limited our target to have only 3 registers available the
code post-hazard-recognized looks like that:

load 0x1234, reg1024
load 0x1236, reg1025
load 0x1238, reg1026
load 0x1240, reg1027
add reg1024, 1
add reg1025, 2
add reg1026, 3
add reg1027, 4

after register allocation:

load 0x1234, reg1
load 0x1236, reg2
load 0x1238, reg3
add reg1, 1
add reg2, 2
add reg3, 3
store reg1, 0x1234
load 0x1240, reg1
add reg1, 4

Which won't work on our platform. It is missing 2 NOOPs after the last 
load. The DelaySlotFiller could add the two NOOPs, but that would be less 
optimal than doing the store-load before the add of reg2 and reg3 (no NOOP 
in that case).

>> And more generally: Is the hazardRecognizer the right and only way to
>> solve our NOOP-minimizing problem?
>
> Perhaps you want to do this after register allocation is done. Dan is
> developing the post-allocation scheduler. You can try it out.

Interesting. Can it already be found SVN? I will search the mail archive 
later, if not.

regards,
Patrick.

From isanbard at gmail.com  Mon Jan 19 13:18:13 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 19 Jan 2009 11:18:13 -0800
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still produces
	-Wformat/-Wformat-security
In-Reply-To: <20090119011139.GA7602@bromo.med.uc.edu>
References: <20090119011139.GA7602@bromo.med.uc.edu>
Message-ID: <16e5fdf90901191118s7e4ac60bx4717ac7275c7ff6d@mail.gmail.com>

Hi Jack,

Because of the new changes and the fact that we have only 2 days
before branching for 2.5, please retest the Fortran front end as soon
as you can to see if the problem has been resolved.

Thanks!
-bw

On Sun, Jan 18, 2009 at 5:11 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>   The current llvm/llvm-gcc-4.2 svn when built on
> i686-apple-darwin9 still produces the bogus warnings...
>
> f951: warning: command line option "-Wformat" is valid for C/C++/ObjC/ObjC++ but not for Fortran
> f951: warning: command line option "-Wformat-security" is valid for C/C++/ObjC/ObjC++ but not for Fortran
>
> whenc compling any code with gfortran. This causes the gfortran testsuite
> in gcc-4.2 to fail any test for compilation errors. Can we get this fixed
> before the llvm 2.5 release?
>           Jack
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From vilmer at eden.rutgers.edu  Mon Jan 19 11:37:28 2009
From: vilmer at eden.rutgers.edu (Veniamin Ilmer)
Date: Mon, 19 Jan 2009 12:37:28 -0500 (EST)
Subject: [LLVMdev] Trying to install gcc front end...
Message-ID: <16139615.29241232386647827.JavaMail.tomcat@aurora>

Hello all,
I'm trying to install LLVM with the gcc front end. (Using gcc release 4.2 with LLVM 2.4)
I tried installing it using the bash code here:
http://aur.archlinux.org/packages/llvm-gcc/llvm-gcc/PKGBUILD

Unfortunately after it built and compiled everything, I ran into a problem.
Apparently some gcc-libs 4.3.2 libraries conflict with the gcc 4.2 front end.

I got this log in this error:
llvm-gcc: /usr/lib/libgomp.a exists in filesystem
llvm-gcc: /usr/lib/libgomp.spec exists in filesystem
llvm-gcc: /usr/lib/libmudflap.a exists in filesystem
llvm-gcc: /usr/lib/libmudflapth.a exists in filesystem
llvm-gcc: /usr/lib/libssp.a exists in filesystem
llvm-gcc: /usr/lib/libssp_nonshared.a exists in filesystem

Do you know how to get around this problem? I cannot remove or downgrade gcc-libs because a lot of my applications require the latest version (gnutls, libsmbios, mesa, poppler, thunderbird, xulrunner).

What should I do?

Thank you,
Veniamin


From isanbard at gmail.com  Mon Jan 19 13:27:23 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 19 Jan 2009 11:27:23 -0800
Subject: [LLVMdev] clang installation
In-Reply-To: <0800AFA2-64C2-4055-960F-043443337918@apple.com>
References: <0800AFA2-64C2-4055-960F-043443337918@apple.com>
Message-ID: <16e5fdf90901191127v7b895abdrb8570df7cb71c849@mail.gmail.com>

On Mon, Jan 19, 2009 at 10:05 AM, Mike Stump <mrs at apple.com> wrote:
> This patch adds targets to support the installation of clang in isolation.
>
> Ok?
>

+ifeq ($(MAKECMDGOALS),install-clang)
+  DIRS := tools/clang/Driver tools/clang/lib/Headers tools/clang/tools/ccc

Is "tools/clang" the official name of the clang development directory?
I was still using "tools/cfe".

This is okay if the above question is "yes", and building and
installing LLVM without clang isn't affected.

-bw

From mrs at apple.com  Mon Jan 19 13:36:25 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Jan 2009 11:36:25 -0800
Subject: [LLVMdev] Trying to install gcc front end...
In-Reply-To: <16139615.29241232386647827.JavaMail.tomcat@aurora>
References: <16139615.29241232386647827.JavaMail.tomcat@aurora>
Message-ID: <CC87E255-D096-48D5-9C0D-5EA79F3158FE@apple.com>

On Jan 19, 2009, at 9:37 AM, Veniamin Ilmer wrote:
> I got this log in this error:
> llvm-gcc: /usr/lib/libgomp.a exists in filesystem

Did you configure with a unique --prefix?

From mrs at apple.com  Mon Jan 19 13:46:01 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Jan 2009 11:46:01 -0800
Subject: [LLVMdev] clang installation
In-Reply-To: <16e5fdf90901191127v7b895abdrb8570df7cb71c849@mail.gmail.com>
References: <0800AFA2-64C2-4055-960F-043443337918@apple.com>
	<16e5fdf90901191127v7b895abdrb8570df7cb71c849@mail.gmail.com>
Message-ID: <22E39DFC-6427-4F05-AA7A-FC0E08FFE485@apple.com>

On Jan 19, 2009, at 11:27 AM, Bill Wendling wrote:
> +ifeq ($(MAKECMDGOALS),install-clang)
> +  DIRS := tools/clang/Driver tools/clang/lib/Headers tools/clang/ 
> tools/ccc
>
> Is "tools/clang" the official name of the clang development directory?

According to step #2 in http://clang.llvm.org/get_started.html, it is  
the recommended place for it.

> This is okay if the above question is "yes", and building and  
> installing LLVM without clang isn't affected.

Yes, there should be no change otherwise.

From danchr at gmail.com  Mon Jan 19 13:55:49 2009
From: danchr at gmail.com (Dan Villiom Podlaski Christiansen)
Date: Mon, 19 Jan 2009 20:55:49 +0100
Subject: [LLVMdev] building clang when present
In-Reply-To: <B7AEB01A-6D62-4C0E-B866-32BF92F24C23@apple.com>
References: <B7AEB01A-6D62-4C0E-B866-32BF92F24C23@apple.com>
Message-ID: <E580CC6E-5559-4E6F-8BEF-30C8E35468AA@gmail.com>

On 19 Jan 2009, at 19:08, Mike Stump wrote:

> This patch eases building clang when present in the source tree.   
> Since clang is revlocked to llvm, one usually updates them together,  
> and builds them together.
>
> Ok?

In my humble opinion, using OPTIONAL_DIRS would be better and cleaner.  
It may require some changes to ?Makefile.rules? to work as  
intended, though. If there's interest in such a change, I can prepare  
a patch?

--

Dan Villiom Podlaski Christiansen, stud. scient.,
danchr at cs.au.dk, danchr at gmail.com



From gordonhenriksen at me.com  Mon Jan 19 13:55:42 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Mon, 19 Jan 2009 14:55:42 -0500
Subject: [LLVMdev] ocaml build system
In-Reply-To: <4974CB87.3050106@mxc.ca>
References: <4974CB87.3050106@mxc.ca>
Message-ID: <A89690D6-B1CA-4EE8-90A0-3AC23F483EE7@me.com>

On 2009-01-19, at 13:50, Nick Lewycky wrote:

> I have an issue with the OCaml build system and the ExecutionEngine.
>
> PR2128 has a patch to change the Interpreter to use libffi. This  
> breaks test/Bindings/Ocaml/executionengine.ml because OCaml doesn't  
> try to link with libffi, even though llvm-config knows that we should:
>
>  $ Debug/bin/llvm-config --ldflags interpreter
>  -L/home/nicholas/llvm-commit/Debug/lib  -lpthread -lffi -ldl -lm - 
> lelf
>
> If I run 'ocamlc' by hand and pass it '-cclib -lffi', the test  
> succeeds, so this is the only remaining problem. Is anyone familiar  
> with how Ocaml knows what libraries to link against? We can't just  
> pass `llvm-config --ldflags interpreter` to ocamlc because it  
> doesn't support the -L argument.
>
> Does anyone have any ideas how this ought to work?


The linker flags for each .cma (ocaml library) are baked in by ocaml.  
Here's the relevant section from Makefile.ocaml:

# Info from llvm-config and similar
ifdef UsedComponents
UsedLibs = $(shell $(LLVM_CONFIG) --libs $(UsedComponents))
UsedLibNames = $(shell $(LLVM_CONFIG) --libnames $(UsedComponents))
endif

# Tools
OCAMLCFLAGS += -I $(OcamlDir) -I $(ObjDir)
ifneq ($(ObjectsO),)
OCAMLAFLAGS += $(patsubst %,-cclib %, \
                  $(filter-out -L$(LibDir),-l$(LIBRARYNAME) \
                                           $(shell $(LLVM_CONFIG) -- 
ldflags)) \
                                           $(UsedLibs))
else
OCAMLAFLAGS += $(patsubst %,-cclib %, \
                  $(filter-out -L$(LibDir),$(shell $(LLVM_CONFIG) -- 
ldflags)) \
                                           $(UsedLibs))
endif

This transforms "x y z" from llvm-config into "-cclib x -cclib y - 
cclib z", which instructs ocaml to pass "x y z" down to the linker  
when creating an executable. The UsedComponents variable originates in  
this case from bindings/ocaml/executionengine/Makefile:

LEVEL := ../../..
LIBRARYNAME := llvm_executionengine
DONT_BUILD_RELINKED := 1
UsedComponents := executionengine jit interpreter native
UsedOcamlInterfaces := llvm llvm_target

include ../Makefile.ocaml

I don't see anything obviously wrong here; it seems that llvm-config - 
ldflags executionengine jit interpreter native should be invoked,  
which should give you the -cclib -lffi you seek. make VERBOSE=1 and/or  
TOO_VERBOSE=1 should show you the full ocaml command lines; maybe  
that'll show where -lffi is getting dropped on the floor.

? Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090119/34c3b03e/attachment-0001.html 

From nicholas at mxc.ca  Mon Jan 19 14:15:07 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 19 Jan 2009 12:15:07 -0800
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still
	produces	-Wformat/-Wformat-security
In-Reply-To: <16e5fdf90901191118s7e4ac60bx4717ac7275c7ff6d@mail.gmail.com>
References: <20090119011139.GA7602@bromo.med.uc.edu>
	<16e5fdf90901191118s7e4ac60bx4717ac7275c7ff6d@mail.gmail.com>
Message-ID: <4974DF4B.2060206@mxc.ca>

Bill Wendling wrote:
> Hi Jack,
> 
> Because of the new changes and the fact that we have only 2 days
> before branching for 2.5, please retest the Fortran front end as soon
> as you can to see if the problem has been resolved.

Hi Bill. Thanks for working on this!

Unfortunately, I'm getting this warning now:

   $ llvm-g++ helloworld.c
   cc1plus: warning: -Wformat-security ignored without -Wformat

I think you can fix it by applying the same #define trick to 
-Wformat-security that you did to -Wformat.

Nick

> Thanks!
> -bw
> 
> On Sun, Jan 18, 2009 at 5:11 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>>   The current llvm/llvm-gcc-4.2 svn when built on
>> i686-apple-darwin9 still produces the bogus warnings...
>>
>> f951: warning: command line option "-Wformat" is valid for C/C++/ObjC/ObjC++ but not for Fortran
>> f951: warning: command line option "-Wformat-security" is valid for C/C++/ObjC/ObjC++ but not for Fortran
>>
>> whenc compling any code with gfortran. This causes the gfortran testsuite
>> in gcc-4.2 to fail any test for compilation errors. Can we get this fixed
>> before the llvm 2.5 release?
>>           Jack
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


From nicholas at mxc.ca  Mon Jan 19 14:16:05 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 19 Jan 2009 12:16:05 -0800
Subject: [LLVMdev] ocaml build system
In-Reply-To: <A89690D6-B1CA-4EE8-90A0-3AC23F483EE7@me.com>
References: <4974CB87.3050106@mxc.ca>
	<A89690D6-B1CA-4EE8-90A0-3AC23F483EE7@me.com>
Message-ID: <4974DF85.8070209@mxc.ca>

Gordon Henriksen wrote:
> On 2009-01-19, at 13:50, Nick Lewycky wrote:
> 
>> I have an issue with the OCaml build system and the ExecutionEngine.
>>
>> PR2128 has a patch to change the Interpreter to use libffi. This 
>> breaks test/Bindings/Ocaml/executionengine.ml because OCaml doesn't 
>> try to link with libffi, even though llvm-config knows that we should:
>>
>>  $ Debug/bin/llvm-config --ldflags interpreter
>>  -L/home/nicholas/llvm-commit/Debug/lib  -lpthread -lffi -ldl -lm -lelf
>>
>> If I run 'ocamlc' by hand and pass it '-cclib -lffi', the test 
>> succeeds, so this is the only remaining problem. Is anyone familiar 
>> with how Ocaml knows what libraries to link against? We can't just 
>> pass `llvm-config --ldflags interpreter` to ocamlc because it doesn't 
>> support the -L argument.
>>
>> Does anyone have any ideas how this ought to work?
> 
> The linker flags for each .cma (ocaml library) are baked in by ocaml. 
> Here's the relevant section from Makefile.ocaml:
> 
>     # Info from llvm-config and similar
>     ifdef UsedComponents
>     UsedLibs = $(shell $(LLVM_CONFIG) --libs $(UsedComponents))
>     UsedLibNames = $(shell $(LLVM_CONFIG) --libnames $(UsedComponents))
>     endif
> 
>     # Tools
>     OCAMLCFLAGS += -I $(OcamlDir) -I $(ObjDir)
>     ifneq ($(ObjectsO),)
>     OCAMLAFLAGS += $(patsubst %,-cclib %, \
>                      $(filter-out -L$(LibDir),-l$(LIBRARYNAME) \
>                                               $(shell $(LLVM_CONFIG)
>     --ldflags)) \
>                                               $(UsedLibs))
>     else
>     OCAMLAFLAGS += $(patsubst %,-cclib %, \
>                      $(filter-out -L$(LibDir),$(shell $(LLVM_CONFIG)
>     --ldflags)) \
>                                               $(UsedLibs))
>     endif
> 
> 
> This transforms "x y z" from llvm-config into "-cclib x -cclib y -cclib 
> z", which instructs ocaml to pass "x y z" down to the linker when 
> creating an executable. The UsedComponents variable originates in this 
> case from bindings/ocaml/executionengine/Makefile:
> 
>     LEVEL := ../../..
>     LIBRARYNAME := llvm_executionengine
>     DONT_BUILD_RELINKED := 1
>     * UsedComponents := executionengine jit interpreter native *
>     UsedOcamlInterfaces := llvm llvm_target
> 
>     include ../Makefile.ocaml
> 
> 
> I don't see anything obviously wrong here; it seems that llvm-config 
> -ldflags executionengine jit interpreter native  should be invoked, 
> which should give you the -cclib -lffi you seek.  make VERBOSE=1  and/or 
> TOO_VERBOSE=1 should show you the full ocaml command lines; maybe 
> that'll show where -lffi is getting dropped on the floor.

Thanks for the explanation. It looks like what really happened is that 
the .cma files weren't regenerated when llvm-config changed. After 
refreshing bindings/ocaml and rebuilding LLVM, the test passes.

Nick

> ? Gordon
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From mrs at apple.com  Mon Jan 19 14:16:38 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Jan 2009 12:16:38 -0800
Subject: [LLVMdev] building clang when present
In-Reply-To: <E580CC6E-5559-4E6F-8BEF-30C8E35468AA@gmail.com>
References: <B7AEB01A-6D62-4C0E-B866-32BF92F24C23@apple.com>
	<E580CC6E-5559-4E6F-8BEF-30C8E35468AA@gmail.com>
Message-ID: <DE8B40B5-2CB1-4D59-87A3-DBB14BFB282A@apple.com>

On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen wrote:
> In my humble opinion, using OPTIONAL_DIRS would be better and cleaner.
> It may require some changes to ?Makefile.rules? to work as
> intended, though. If there's interest in such a change, I can prepare
> a patch?

Are OPTIONAL_DIRS parallel?  For some reason, I was assuming not.

From danchr at gmail.com  Mon Jan 19 14:35:47 2009
From: danchr at gmail.com (Dan Villiom Podlaski Christiansen)
Date: Mon, 19 Jan 2009 21:35:47 +0100
Subject: [LLVMdev] building clang when present
In-Reply-To: <DE8B40B5-2CB1-4D59-87A3-DBB14BFB282A@apple.com>
References: <B7AEB01A-6D62-4C0E-B866-32BF92F24C23@apple.com>
	<E580CC6E-5559-4E6F-8BEF-30C8E35468AA@gmail.com>
	<DE8B40B5-2CB1-4D59-87A3-DBB14BFB282A@apple.com>
Message-ID: <643B3B96-9751-4B19-B845-F0932EB829AD@gmail.com>

On 19 Jan 2009, at 21:16, Mike Stump wrote:

> On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen wrote:
>> In my humble opinion, using OPTIONAL_DIRS would be better and  
>> cleaner.
>> It may require some changes to ?Makefile.rules? to work as
>> intended, though. If there's interest in such a change, I can prepare
>> a patch?
>
> Are OPTIONAL_DIRS parallel?  For some reason, I was assuming not.

Well, from my recollection, PARALLEL_DIRS and the other *_DIRS don't  
interact terribly well with each other with the current LLVM build  
system. It may or may not actually be executed parallel with other  
directories, but I wouldn't consider that a problem, as Clang itself  
contains quite a lot of source files, libraries and directories.  
Parallelism within the Clang source should be Good Enough? ;)

--

Dan Villiom Podlaski Christiansen, stud. scient.,
danchr at cs.au.dk, danchr at gmail.com



From mrs at apple.com  Mon Jan 19 14:53:01 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Jan 2009 12:53:01 -0800
Subject: [LLVMdev] building clang when present
In-Reply-To: <643B3B96-9751-4B19-B845-F0932EB829AD@gmail.com>
References: <B7AEB01A-6D62-4C0E-B866-32BF92F24C23@apple.com>
	<E580CC6E-5559-4E6F-8BEF-30C8E35468AA@gmail.com>
	<DE8B40B5-2CB1-4D59-87A3-DBB14BFB282A@apple.com>
	<643B3B96-9751-4B19-B845-F0932EB829AD@gmail.com>
Message-ID: <7BD371DD-0C21-437F-A7CB-E190FE0A9AA4@apple.com>

On Jan 19, 2009, at 12:35 PM, Dan Villiom Podlaski Christiansen wrote:
> On 19 Jan 2009, at 21:16, Mike Stump wrote:
>
>> On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen  
>> wrote:
>>> In my humble opinion, using OPTIONAL_DIRS would be better and
>>> cleaner.
>>> It may require some changes to ?Makefile.rules? to work as
>>> intended, though. If there's interest in such a change, I can  
>>> prepare
>>> a patch?
>>
>> Are OPTIONAL_DIRS parallel?  For some reason, I was assuming not.
>
> Well, from my recollection, PARALLEL_DIRS and the other *_DIRS don't
> interact terribly well with each other with the current LLVM build
> system. It may or may not actually be executed parallel with other
> directories, but I wouldn't consider that a problem, as Clang itself
> contains quite a lot of source files, libraries and directories.
> Parallelism within the Clang source should be Good Enough? ;)

If there are bugs in the parallel aspects of llvm, I've never hit  
them.  I only ever build 8-way, and I expect it to just work; if it  
doesn't, I'd rather just fix it.  Avoiding parallel isn't the way to  
get a build system that just works in parallel.  Lastly, I'm more  
demanding than, good enough.

I'll add OPTIONAL_PARALLEL_DIRS, if people would rather it be done  
that way.  :-)

From isanbard at gmail.com  Mon Jan 19 14:59:38 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 19 Jan 2009 12:59:38 -0800
Subject: [LLVMdev] llvm/llvm-gcc-4.2 svn still produces
	-Wformat/-Wformat-security
In-Reply-To: <4974DF4B.2060206@mxc.ca>
References: <20090119011139.GA7602@bromo.med.uc.edu>
	<16e5fdf90901191118s7e4ac60bx4717ac7275c7ff6d@mail.gmail.com>
	<4974DF4B.2060206@mxc.ca>
Message-ID: <16e5fdf90901191259l180b8fabjce314ceb12353fd4@mail.gmail.com>

On Mon, Jan 19, 2009 at 12:15 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Bill Wendling wrote:
>> Hi Jack,
>>
>> Because of the new changes and the fact that we have only 2 days
>> before branching for 2.5, please retest the Fortran front end as soon
>> as you can to see if the problem has been resolved.
>
> Hi Bill. Thanks for working on this!
>
> Unfortunately, I'm getting this warning now:
>
>   $ llvm-g++ helloworld.c
>   cc1plus: warning: -Wformat-security ignored without -Wformat
>
> I think you can fix it by applying the same #define trick to
> -Wformat-security that you did to -Wformat.
>
*grump* I just submitted a hack. Please let me know if it helps.

-bw

From clattner at apple.com  Mon Jan 19 15:03:28 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 19 Jan 2009 13:03:28 -0800
Subject: [LLVMdev] clang installation
In-Reply-To: <0800AFA2-64C2-4055-960F-043443337918@apple.com>
References: <0800AFA2-64C2-4055-960F-043443337918@apple.com>
Message-ID: <C3014472-90BA-47F0-9D6A-E4D61AF08E2C@apple.com>


On Jan 19, 2009, at 10:05 AM, Mike Stump wrote:

> This patch adds targets to support the installation of clang in  
> isolation.

Looks good to me, plz apply!

-Chris

From ofv at wanadoo.es  Mon Jan 19 15:44:38 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Mon, 19 Jan 2009 22:44:38 +0100
Subject: [LLVMdev] building clang when present
References: <B7AEB01A-6D62-4C0E-B866-32BF92F24C23@apple.com>
	<E580CC6E-5559-4E6F-8BEF-30C8E35468AA@gmail.com>
	<DE8B40B5-2CB1-4D59-87A3-DBB14BFB282A@apple.com>
	<643B3B96-9751-4B19-B845-F0932EB829AD@gmail.com>
	<7BD371DD-0C21-437F-A7CB-E190FE0A9AA4@apple.com>
Message-ID: <m3vdsbug1l.fsf@telefonica.net>

Mike Stump <mrs at apple.com> writes:

> If there are bugs in the parallel aspects of llvm, I've never hit  
> them.  I only ever build 8-way, and I expect it to just work; if it  
> doesn't, I'd rather just fix it.  Avoiding parallel isn't the way to  
> get a build system that just works in parallel.  Lastly, I'm more  
> demanding than, good enough.
>
> I'll add OPTIONAL_PARALLEL_DIRS, if people would rather it be done  
> that way.  :-)

I see that a significant amount of work is devoted to enhancing/fixing
the current build framework, which is perfectly okay with me, but seeing
once and again how you guys work on the build instead of
enhancing/fixing LLVM itself makes me think "what a waste of talent" :-)

Adding CMake support for integrating clang into the LLVM build took me
about 15 minutes. The only change to the pre-existing LLVM CMake
specification was

if( EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/clang/CMakeLists.txt )
  add_subdirectory( ${CMAKE_CURRENT_SOURCE_DIR}/clang )
endif()

and just this gives a lot of benefit: parallel builds, multiplatform,
multicompiler, robustness, etc. With some work it is possible to support
building clang on an arbitrary directory, even putting LLVM as a
subdirectory of clang, which is more natural than the current
arrangement. This feature could be of benefit to those working on their
own compiler too: integrating LLVM on a external CMake build spec would
require three or four lines of code on the user's CMakeFiles.txt. I have
a prototype that does this, but I'm waiting for some extra free time to
polish it.

The only serious non-trivial thing the current LLVM CMake specification
lacks is "make check", and here I'm having some problems. First, because
it is not posible (AFAIK) to completely mimic "make check" (make check
itself is no problem, the options you can use are the tricky part, like
requiring certain test case or set of test cases). Second, because I
don't know what you would consider acceptable, as I have no personal
experience nor criteria about executing test cases. Third, because the
enhancements recently incorporated to the test framework (C++ unit
tests). Fourth and final, because of a severe lack of time.

Implementing the bells and whistles the cmake spec still lacks compared
to configure & make seems an easy work to me.

So if you are on the mood of devoting your time to enhancing the LLVM
build system, please consider working on the CMake spec, and
specifically on "make check" support.

-- 
Oscar


From clattner at apple.com  Mon Jan 19 15:58:12 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 19 Jan 2009 13:58:12 -0800
Subject: [LLVMdev] avoid creating .dir files
In-Reply-To: <3B14683F-547E-49E9-8DFE-BB35FED0D124@apple.com>
References: <3B14683F-547E-49E9-8DFE-BB35FED0D124@apple.com>
Message-ID: <50140231-8562-4610-A269-449C87B718DB@apple.com>


On Jan 19, 2009, at 10:02 AM, Mike Stump wrote:

> There isn't a good reason to create files called .dir in the  
> installation directory.  This patch fixes that.

If we don't have this line, every build with do the makedir.

-Chris

From clattner at apple.com  Mon Jan 19 16:01:10 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 19 Jan 2009 14:01:10 -0800
Subject: [LLVMdev] cygwin build patch
In-Reply-To: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>
References: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>
Message-ID: <5CE7EB46-16C0-42FC-9A12-13328B7053AD@apple.com>


On Jan 19, 2009, at 7:44 AM, Jay Foad wrote:

> LLVM doesn't build out of the box on Cygwin, because Cygwin defines
> uint32_t as "unsigned long" rather than "unsigned int".
>
> The attached patch allows me to build head of svn (rev 62510) on
> Cygwin using GCC 4. Can this be committed please?

Thanks applied:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090119/072367.html

> I realise that the DataTypes.h.in part might be controversial. Also,
> there's probably a better place to put it, but I'm not sure where.

I didn't apply this part.  What problems does it cause to not have  
this?  Can we fix uses of max and min?

-Chris

From howarth at bromo.med.uc.edu  Mon Jan 19 16:05:22 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Mon, 19 Jan 2009 17:05:22 -0500
Subject: [LLVMdev] llvm-gfortran test results
Message-ID: <20090119220521.GA14425@bromo.med.uc.edu>

  The current llvm/llvm-gcc4.2 svn is now fixed with
respect to the extra warnings that were being emitted
by the gfortran compiler. The gfortran testsuite results
under Intel Darwin9 are appended below.
              Jack

Native configuration is i686-apple-darwin9

		=== gfortran tests ===


Running target unix/-m32
FAIL: gfortran.dg/aint_anint_1.f90  -O  (internal compiler error)
FAIL: gfortran.dg/aint_anint_1.f90  -O  (test for excess errors)
FAIL: gfortran.dg/array_constructor_11.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/assumed_charlen_function_3.f90  -O  (internal compiler error)
FAIL: gfortran.dg/assumed_charlen_function_3.f90  -O  (test for excess errors)
FAIL: gfortran.dg/assumed_charlen_function_5.f90  -O  (internal compiler error)
FAIL: gfortran.dg/assumed_charlen_function_5.f90  -O  (test for excess errors)
FAIL: gfortran.dg/char_transpose_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/equiv_constraint_4.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/equiv_constraint_4.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/equiv_constraint_4.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/hollerith_legacy.f90  -O  (internal compiler error)
FAIL: gfortran.dg/hollerith_legacy.f90  -O  (test for excess errors)
FAIL: gfortran.dg/missing_optional_dummy_2.f90  -O  (internal compiler error)
FAIL: gfortran.dg/missing_optional_dummy_2.f90  -O  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O0  execution test
FAIL: gfortran.dg/namelist_14.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O1  execution test
FAIL: gfortran.dg/namelist_14.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O2  execution test
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/namelist_14.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O3 -g  execution test
FAIL: gfortran.dg/namelist_14.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -Os  execution test
FAIL: gfortran.dg/namelist_15.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O0  execution test
FAIL: gfortran.dg/namelist_15.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O1  execution test
FAIL: gfortran.dg/namelist_15.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O2  execution test
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/namelist_15.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O3 -g  execution test
FAIL: gfortran.dg/namelist_15.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -Os  execution test
FAIL: gfortran.dg/optional_assumed_charlen_1.f90  -O  (internal compiler error)
FAIL: gfortran.dg/optional_assumed_charlen_1.f90  -O  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O0  execution test
FAIL: gfortran.dg/pr18392.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O1  execution test
FAIL: gfortran.dg/pr18392.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O2  execution test
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/pr18392.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O3 -g  execution test
FAIL: gfortran.dg/pr18392.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -Os  execution test
FAIL: gfortran.dg/pr21177.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/g77/980628-10.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-10.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-2.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-3.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-9.f  -Os  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-bessel.f  -O0  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-bessel.f  -O1  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-bessel.f  -O2  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-bessel.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-bessel.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-bessel.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-bessel.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-bessel.f  -Os  execution test
FAIL: gfortran.dg/vect/pr19049.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/pr19049.f90  -O : error executing dg-final: no files matched glob pattern "pr19049.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/pr19049.f90  -O : error executing dg-final: no files matched glob pattern "pr19049.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-1.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/vect-1.f90  -O : error executing dg-final: no files matched glob pattern "vect-1.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-1.f90  -O : error executing dg-final: no files matched glob pattern "vect-1.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-2.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/vect-2.f90  -O : error executing dg-final: no files matched glob pattern "vect-2.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-2.f90  -O : error executing dg-final: no files matched glob pattern "vect-2.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-3.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/vect-3.f90  -O : error executing dg-final: no files matched glob pattern "vect-3.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-3.f90  -O : error executing dg-final: no files matched glob pattern "vect-3.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-4.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/vect-4.f90  -O : error executing dg-final: no files matched glob pattern "vect-4.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-4.f90  -O : error executing dg-final: no files matched glob pattern "vect-4.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-5.f90  -O  (test for excess errors)
WARNING: gfortran.dg/vect/vect-5.f90  -O  compilation failed to produce executable
ERROR: gfortran.dg/vect/vect-5.f90  -O : error executing dg-final: no files matched glob pattern "vect-5.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-5.f90  -O : error executing dg-final: no files matched glob pattern "vect-5.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O0 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O1 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O2 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O3 -fomit-frame-pointer 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O3 -fomit-frame-pointer -funroll-loops 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O3 -g 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -Os 
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O0  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O1  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O2  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O3 -g  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -Os  (internal compiler error)

		=== gfortran Summary for unix/-m32 ===

# of expected passes		15894
# of unexpected failures	260
# of expected failures		6
# of unresolved testcases	6
# of unsupported tests		38

Running target unix/-m64
FAIL: gfortran.dg/aint_anint_1.f90  -O  (internal compiler error)
FAIL: gfortran.dg/aint_anint_1.f90  -O  (test for excess errors)
FAIL: gfortran.dg/array_constructor_11.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_11.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/array_constructor_11.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/array_constructor_11.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/array_constructor_12.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/array_constructor_12.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/array_constructor_12.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/array_section_1.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/array_section_1.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/array_section_1.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/assumed_charlen_function_3.f90  -O  (internal compiler error)
FAIL: gfortran.dg/assumed_charlen_function_3.f90  -O  (test for excess errors)
FAIL: gfortran.dg/assumed_charlen_function_5.f90  -O  (internal compiler error)
FAIL: gfortran.dg/assumed_charlen_function_5.f90  -O  (test for excess errors)
FAIL: gfortran.dg/char_transpose_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/char_transpose_1.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/char_transpose_1.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/char_transpose_1.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/equiv_constraint_4.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/equiv_constraint_4.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/equiv_constraint_4.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/hollerith.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/hollerith.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/hollerith.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/hollerith4.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/hollerith4.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/hollerith4.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/hollerith_legacy.f90  -O  (internal compiler error)
FAIL: gfortran.dg/hollerith_legacy.f90  -O  (test for excess errors)
FAIL: gfortran.dg/large_integer_kind_1.f90  -O0  execution test
FAIL: gfortran.dg/large_integer_kind_1.f90  -O1  execution test
FAIL: gfortran.dg/large_integer_kind_1.f90  -O2  execution test
FAIL: gfortran.dg/large_integer_kind_1.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/large_integer_kind_1.f90  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/large_integer_kind_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/large_integer_kind_1.f90  -O3 -g  execution test
FAIL: gfortran.dg/large_integer_kind_1.f90  -Os  execution test
FAIL: gfortran.dg/missing_optional_dummy_2.f90  -O  (internal compiler error)
FAIL: gfortran.dg/missing_optional_dummy_2.f90  -O  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/namelist_13.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O0  execution test
FAIL: gfortran.dg/namelist_14.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O1  execution test
FAIL: gfortran.dg/namelist_14.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O2  execution test
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/namelist_14.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -O3 -g  execution test
FAIL: gfortran.dg/namelist_14.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90  -Os  execution test
FAIL: gfortran.dg/namelist_15.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O0  execution test
FAIL: gfortran.dg/namelist_15.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O1  execution test
FAIL: gfortran.dg/namelist_15.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O2  execution test
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/namelist_15.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -O3 -g  execution test
FAIL: gfortran.dg/namelist_15.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/namelist_15.f90  -Os  execution test
FAIL: gfortran.dg/optional_assumed_charlen_1.f90  -O  (internal compiler error)
FAIL: gfortran.dg/optional_assumed_charlen_1.f90  -O  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O0  execution test
FAIL: gfortran.dg/pr18392.f90  -O1  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O1  execution test
FAIL: gfortran.dg/pr18392.f90  -O2  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O2  execution test
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/pr18392.f90  -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -O3 -g  execution test
FAIL: gfortran.dg/pr18392.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/pr18392.f90  -Os  execution test
FAIL: gfortran.dg/pr21177.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/pr21177.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/pr21177.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/pr21177.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O1  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O1  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O1  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O2  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O2  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O2  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -O3 -g  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -O3 -g  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -O3 -g  compilation failed to produce executable
FAIL: gfortran.dg/specifics_1.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/specifics_1.f90  -Os  (test for excess errors)
WARNING: gfortran.dg/specifics_1.f90  -Os  compilation failed to produce executable
FAIL: gfortran.dg/g77/980628-0.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-0.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-0.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-0.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-0.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-0.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-0.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-0.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-1.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-1.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-1.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-1.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-1.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-1.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-1.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-1.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-10.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-2.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-2.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-3.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-3.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-7.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-8.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-9.f  -Os  execution test
FAIL: gfortran.dg/g77/980701-0.f  -O0  execution test
FAIL: gfortran.dg/g77/980701-0.f  -O1  execution test
FAIL: gfortran.dg/g77/980701-0.f  -O2  execution test
FAIL: gfortran.dg/g77/980701-0.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980701-0.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980701-0.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980701-0.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980701-0.f  -Os  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O0  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O1  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O2  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980701-1.f  -Os  execution test
FAIL: gfortran.dg/vect/pr19049.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/pr19049.f90  -O : error executing dg-final: no files matched glob pattern "pr19049.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/pr19049.f90  -O : error executing dg-final: no files matched glob pattern "pr19049.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-1.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/vect-1.f90  -O : error executing dg-final: no files matched glob pattern "vect-1.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-1.f90  -O : error executing dg-final: no files matched glob pattern "vect-1.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-2.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/vect-2.f90  -O : error executing dg-final: no files matched glob pattern "vect-2.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-2.f90  -O : error executing dg-final: no files matched glob pattern "vect-2.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-3.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/vect-3.f90  -O : error executing dg-final: no files matched glob pattern "vect-3.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-3.f90  -O : error executing dg-final: no files matched glob pattern "vect-3.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-4.f90  -O  (test for excess errors)
ERROR: gfortran.dg/vect/vect-4.f90  -O : error executing dg-final: no files matched glob pattern "vect-4.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-4.f90  -O : error executing dg-final: no files matched glob pattern "vect-4.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.dg/vect/vect-5.f90  -O  (test for excess errors)
WARNING: gfortran.dg/vect/vect-5.f90  -O  compilation failed to produce executable
ERROR: gfortran.dg/vect/vect-5.f90  -O : error executing dg-final: no files matched glob pattern "vect-5.f90.[0-9][0-9][0-9][ti].vect"
UNRESOLVED: gfortran.dg/vect/vect-5.f90  -O : error executing dg-final: no files matched glob pattern "vect-5.f90.[0-9][0-9][0-9][ti].vect"
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O0 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O1 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O2 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O3 -fomit-frame-pointer 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O3 -fomit-frame-pointer -funroll-loops 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -O3 -g 
FAIL: gfortran.fortran-torture/execute/equiv_init_1.f90 execution,  -Os 
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O0  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O1  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O2  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -O3 -g  (internal compiler error)
FAIL: gfortran.fortran-torture/execute/nullarg.f90,  -Os  (internal compiler error)

		=== gfortran Summary for unix/-m64 ===

# of expected passes		15845
# of unexpected failures	308
# of expected failures		6
# of unresolved testcases	6
# of unsupported tests		39

		=== gfortran Summary ===

# of expected passes		31739
# of unexpected failures	568
# of expected failures		12
# of unresolved testcases	12
# of unsupported tests		77
/sw/src/fink.build/llvm-gcc42-2.5-1/llvm_gcc42_objdir/gcc/testsuite/gfortran/../../gfortran  version 4.2.1 (Based on Apple Inc. build 5636) (LLVM build)


Compiler version: 4.2.1 (Based on Apple Inc. build 5636) (LLVM build) gfortran 
Platform: i686-apple-darwin9
configure flags: --prefix=/sw --prefix=/sw/lib/llvm-gcc-4.2 --mandir=/sw/share/man --infodir=/sw/share/info --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-as=/Developer/usr/bin/as --with-ld=/Developer/usr/bin/ld --with-nm=/Developer/usr/bin/nm --build=i686-apple-darwin9 --target=i686-apple-darwin9 --host=i686-apple-darwin9 --with-arch=nocona --with-tune=generic --with-gxx-include-dir=/usr/include/c++/4.0.0 --enable-llvm=/sw/src/fink.build/llvm-gcc42-2.5-1/llvm-2.5/../llvm_objdir --enable-languages=c,c++,fortran


From isanbard at gmail.com  Mon Jan 19 16:40:04 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 19 Jan 2009 14:40:04 -0800
Subject: [LLVMdev] llvm-gfortran test results
In-Reply-To: <20090119220521.GA14425@bromo.med.uc.edu>
References: <20090119220521.GA14425@bromo.med.uc.edu>
Message-ID: <16e5fdf90901191440y266a5111ie56be4cdd8d1e29f@mail.gmail.com>

On Mon, Jan 19, 2009 at 2:05 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>  The current llvm/llvm-gcc4.2 svn is now fixed with
> respect to the extra warnings that were being emitted
> by the gfortran compiler. The gfortran testsuite results
> under Intel Darwin9 are appended below.

Yay! Thanks for testing this out.

> Native configuration is i686-apple-darwin9
>
>                === gfortran tests ===
>
>                === gfortran Summary for unix/-m32 ===
>
> # of expected passes            15894
> # of unexpected failures        260
> # of expected failures          6
> # of unresolved testcases       6
> # of unsupported tests          38
>
> Running target unix/-m64
>                === gfortran Summary for unix/-m64 ===
>
> # of expected passes            15845
> # of unexpected failures        308
> # of expected failures          6
> # of unresolved testcases       6
> # of unsupported tests          39
>
>                === gfortran Summary ===
>
> # of expected passes            31739
> # of unexpected failures        568
> # of expected failures          12
> # of unresolved testcases       12
> # of unsupported tests          77

For a first swipe, this probably isn't *too* terrible. Could you start
filing bugs for the ICEs?

-bw

From gohman at apple.com  Mon Jan 19 16:42:56 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 19 Jan 2009 14:42:56 -0800
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <alpine.LRH.1.10.0901191952420.20397@pub4.ifh.de>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<4E71A380-CB54-415F-822C-3285FEB44221@apple.com>
	<alpine.LRH.1.10.0901191952420.20397@pub4.ifh.de>
Message-ID: <85181497-D132-446B-A5AA-A19840D5F7E0@apple.com>


On Jan 19, 2009, at 11:01 AM, Patrick Boettcher wrote:
>
>
>>> And more generally: Is the hazardRecognizer the right and only way  
>>> to
>>> solve our NOOP-minimizing problem?
>>
>> Perhaps you want to do this after register allocation is done. Dan is
>> developing the post-allocation scheduler. You can try it out.
>
> Interesting. Can it already be found SVN? I will search the mail  
> archive
> later, if not.

Yes, it is in SVN. It's new, and so far it's only being used in limited
ways, and not anything like your specific problem. We don't currently
have any targets in-tree that require no-ops, so it may not address all
your needs out of the box, but patches are welcome :-).

Dan


From clattner at apple.com  Mon Jan 19 16:53:22 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 19 Jan 2009 14:53:22 -0800
Subject: [LLVMdev] llvm-gfortran test results
In-Reply-To: <16e5fdf90901191440y266a5111ie56be4cdd8d1e29f@mail.gmail.com>
References: <20090119220521.GA14425@bromo.med.uc.edu>
	<16e5fdf90901191440y266a5111ie56be4cdd8d1e29f@mail.gmail.com>
Message-ID: <F08ECF0F-CEE5-4A6C-92B0-3DF536738DCF@apple.com>


On Jan 19, 2009, at 2:40 PM, Bill Wendling wrote:

>>               === gfortran Summary ===
>>
>> # of expected passes            31739
>> # of unexpected failures        568
>> # of expected failures          12
>> # of unresolved testcases       12
>> # of unsupported tests          77
>
> For a first swipe, this probably isn't *too* terrible. Could you start
> filing bugs for the ICEs?

For the 2.5 release, I think we're most interested in establishing a  
baseline.  2 days before the release branch isn't the time where we  
really want to fix all the bugs.  However, non-invasive bug fixes are  
always welcome of course. :)

-Chris

From mrs at apple.com  Mon Jan 19 16:55:24 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Jan 2009 14:55:24 -0800
Subject: [LLVMdev] building clang when present
In-Reply-To: <m3vdsbug1l.fsf@telefonica.net>
References: <B7AEB01A-6D62-4C0E-B866-32BF92F24C23@apple.com>
	<E580CC6E-5559-4E6F-8BEF-30C8E35468AA@gmail.com>
	<DE8B40B5-2CB1-4D59-87A3-DBB14BFB282A@apple.com>
	<643B3B96-9751-4B19-B845-F0932EB829AD@gmail.com>
	<7BD371DD-0C21-437F-A7CB-E190FE0A9AA4@apple.com>
	<m3vdsbug1l.fsf@telefonica.net>
Message-ID: <F49BD710-60BC-4093-868C-CC1759861ACE@apple.com>

On Jan 19, 2009, at 1:44 PM, ?scar Fuentes wrote:
> I see that a significant amount of work is devoted to enhancing/fixing
> the current build framework, which is perfectly okay with me, but  
> seeing
> once and again how you guys work on the build instead of
> enhancing/fixing LLVM itself makes me think "what a waste of  
> talent" :-)

Not my fault clang doesn't build when I type make.  :-)  I don't  
consider adding 2 lines to be all that time consuming.  As for what I  
work on, well, if someone else had it building before I got to it, I  
would not have had to do the work, therefore, it falls on me, if I  
want it to build.  Not my choice, that's just how it worked out.  :-)

> With some work it is possible to support building clang on an  
> arbitrary directory, even putting LLVM as a subdirectory of clang,  
> which is more natural than the current arrangement.

:-)  Hey, I'd endorse that!  I find that a more natural layout.   
Though, I don't want to do the work myself.

> So if you are on the mood of devoting your time to enhancing the LLVM
> build system, please consider working on the CMake spec, and
> specifically on "make check" support.

Presently that is outside the scope of what I'm working on.

From mrs at apple.com  Mon Jan 19 17:04:09 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Jan 2009 15:04:09 -0800
Subject: [LLVMdev] avoid creating .dir files
In-Reply-To: <50140231-8562-4610-A269-449C87B718DB@apple.com>
References: <3B14683F-547E-49E9-8DFE-BB35FED0D124@apple.com>
	<50140231-8562-4610-A269-449C87B718DB@apple.com>
Message-ID: <8A51D4F0-05E3-44DD-9620-27DE614D0D37@apple.com>

On Jan 19, 2009, at 1:58 PM, Chris Lattner wrote:
> On Jan 19, 2009, at 10:02 AM, Mike Stump wrote:
>
>> There isn't a good reason to create files called .dir in the
>> installation directory.  This patch fixes that.
>
> If we don't have this line, every build with do the makedir.

And?

$ time mkdir -p /bin

real	0m0.002s
user	0m0.000s
sys	0m0.002s

an extra mkdir takes around 2ms per build.  An up-to-date inc build  
takes 2231ms for me.  If you want some of the extra 2231ms back, I'd  
recommend avoiding recursion in the makefiles.  This will yield a  
larger benefit than worrying about the extra mkdir.

If we have it, then .dir files are created in the installation  
directories.

Trivially one can do:

/dir:
	mkdir /dir

/dir/prog: /dir
	gcc hi.c -o /dir/prog

and avoid the extra mkdir, if one wanted.  Any down side to doing that?

From isanbard at gmail.com  Mon Jan 19 17:12:13 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 19 Jan 2009 15:12:13 -0800
Subject: [LLVMdev] llvm-gfortran test results
In-Reply-To: <F08ECF0F-CEE5-4A6C-92B0-3DF536738DCF@apple.com>
References: <20090119220521.GA14425@bromo.med.uc.edu>
	<16e5fdf90901191440y266a5111ie56be4cdd8d1e29f@mail.gmail.com>
	<F08ECF0F-CEE5-4A6C-92B0-3DF536738DCF@apple.com>
Message-ID: <16e5fdf90901191512p1c91dc8as8a1f81766238a485@mail.gmail.com>

On Mon, Jan 19, 2009 at 2:53 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Jan 19, 2009, at 2:40 PM, Bill Wendling wrote:
>
>>>               === gfortran Summary ===
>>>
>>> # of expected passes            31739
>>> # of unexpected failures        568
>>> # of expected failures          12
>>> # of unresolved testcases       12
>>> # of unsupported tests          77
>>
>> For a first swipe, this probably isn't *too* terrible. Could you start
>> filing bugs for the ICEs?
>
> For the 2.5 release, I think we're most interested in establishing a
> baseline.  2 days before the release branch isn't the time where we
> really want to fix all the bugs.  However, non-invasive bug fixes are
> always welcome of course. :)
>
Quite true! I wasn't thinking of fixing all of the ICEs within the
next 2 days. ;-)

-bw

From anton at korobeynikov.info  Mon Jan 19 17:29:58 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 20 Jan 2009 02:29:58 +0300
Subject: [LLVMdev] llvm-gfortran test results
In-Reply-To: <F08ECF0F-CEE5-4A6C-92B0-3DF536738DCF@apple.com>
References: <20090119220521.GA14425@bromo.med.uc.edu>
	<16e5fdf90901191440y266a5111ie56be4cdd8d1e29f@mail.gmail.com>
	<F08ECF0F-CEE5-4A6C-92B0-3DF536738DCF@apple.com>
Message-ID: <b087fca00901191529n5618c91k1c7848d9be5e4657@mail.gmail.com>

> For the 2.5 release, I think we're most interested in establishing a
> baseline.  2 days before the release branch isn't the time where we
> really want to fix all the bugs.  However, non-invasive bug fixes are
> always welcome of course. :)
Most of all test fails are, unfortunately, due to weirdness of the
frontend, since it generates bogus decls (e.g. function decl without
any arguments, only with return type and later create the 'full'
definition). I introduced some workaround for this in the past, but it
seems, it's not enough for this purposes. The problem is not even
resolved in gcc mainline yet. See gcc PR33097 for more information.

There are surely other bugs, but the ones related to mentioned PR are
the majority.

I'd suggest also to run polyhedron & SPEC. They should be more or less
fine (at least, they were on linux at 2.4 times).

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From dag at cray.com  Mon Jan 19 17:38:11 2009
From: dag at cray.com (David Greene)
Date: Mon, 19 Jan 2009 17:38:11 -0600
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <85181497-D132-446B-A5AA-A19840D5F7E0@apple.com>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<alpine.LRH.1.10.0901191952420.20397@pub4.ifh.de>
	<85181497-D132-446B-A5AA-A19840D5F7E0@apple.com>
Message-ID: <200901191738.11536.dag@cray.com>

On Monday 19 January 2009 16:42, Dan Gohman wrote:

> >> Perhaps you want to do this after register allocation is done. Dan is
> >> developing the post-allocation scheduler. You can try it out.
> >
> > Interesting. Can it already be found SVN? I will search the mail
> > archive
> > later, if not.
>
> Yes, it is in SVN. It's new, and so far it's only being used in limited
> ways, and not anything like your specific problem. We don't currently
> have any targets in-tree that require no-ops, so it may not address all
> your needs out of the box, but patches are welcome :-).

Dan, how does the scheduler handle memory dependence?  I'm working on 
something that requires memory dependence information for 
MachineInstructions.

                                               -Dave

From nunoplopes at sapo.pt  Mon Jan 19 17:54:48 2009
From: nunoplopes at sapo.pt (Nuno Lopes)
Date: Mon, 19 Jan 2009 23:54:48 -0000
Subject: [LLVMdev] value tracking
Message-ID: <893084CE27BF4EA39A2A894E55BF1B73@pc07654>

Hi,

I've been thinking about a (potentially lazy) value tracking analysis that 
could be reused by several optimization passes. I don't know if it exists in 
llvm or not, but to my better knowledge it does not. ok there exists the 
ValueTracking class, but it does not provide a function like e.g. 
MayHaveTheValue(Value* v, APSInt x) to check if a given var v may ever have 
the value x

My proposal:
 - create a value tracking analysis interface that can provide extensive 
info about vars (e.g. the set of possible values for a given vars, etc..)
 - implement that interface in several ways with different tradeoffs of 
preciseness vs speed (e.g. range analysis, value set tracking, path 
sensitive or not, interprocedural, etc..)

I believe this could reuse some code from PredSimplify and hopefully make it 
a very simple pass (as much of the work would then be hidden in the value 
tracking analysis).
Having this sort of readily available analysis would allow us to build other 
optimization more easily. I've already a few ideas in mind (I've implemented 
one of them, but I had to unnecessarily implement too much of this value 
tracking logic).

Any ideas, opinions, etc..?

Regards,
Nuno 


From gohman at apple.com  Mon Jan 19 18:21:48 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 19 Jan 2009 16:21:48 -0800
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <200901191738.11536.dag@cray.com>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<alpine.LRH.1.10.0901191952420.20397@pub4.ifh.de>
	<85181497-D132-446B-A5AA-A19840D5F7E0@apple.com>
	<200901191738.11536.dag@cray.com>
Message-ID: <616D3219-103E-4CB0-BA07-D690F93687B9@apple.com>


On Jan 19, 2009, at 3:38 PM, David Greene wrote:

> On Monday 19 January 2009 16:42, Dan Gohman wrote:
>
>>>> Perhaps you want to do this after register allocation is done.  
>>>> Dan is
>>>> developing the post-allocation scheduler. You can try it out.
>>>
>>> Interesting. Can it already be found SVN? I will search the mail
>>> archive
>>> later, if not.
>>
>> Yes, it is in SVN. It's new, and so far it's only being used in  
>> limited
>> ways, and not anything like your specific problem. We don't currently
>> have any targets in-tree that require no-ops, so it may not address  
>> all
>> your needs out of the box, but patches are welcome :-).
>
> Dan, how does the scheduler handle memory dependence?  I'm working on
> something that requires memory dependence information for
> MachineInstructions.


At the moment, it knows simple things, like constant pool loads
don't have dependencies, and references to distinct stack slots are
independent, and so on.

I have a few ideas for how more precise memory dependencies might be
achieved.

We have MachineMemOperands, which can be used to make AliasAnalysis
or other LLVM-IR-level analysis queries. They need some work though;
the main issue is that there are some places in codegen that don't
preserve them.

Another possibility is to record dependence information from the
SelectionDAG in MachineInstrs somehow. We don't yet have precise
memory dependencies in the SelectionDAG, but it would be good to
fix that too :-). This would probably also involve AliasAnalysis
queries from codegen, possibly going though the
MemoryDependenceAnalysis interface.

Dan


From dag at cray.com  Mon Jan 19 19:06:06 2009
From: dag at cray.com (David Greene)
Date: Mon, 19 Jan 2009 19:06:06 -0600
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <616D3219-103E-4CB0-BA07-D690F93687B9@apple.com>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<200901191738.11536.dag@cray.com>
	<616D3219-103E-4CB0-BA07-D690F93687B9@apple.com>
Message-ID: <200901191906.06656.dag@cray.com>

On Monday 19 January 2009 18:21, Dan Gohman wrote:

> > Dan, how does the scheduler handle memory dependence?  I'm working on
> > something that requires memory dependence information for
> > MachineInstructions.
>
> At the moment, it knows simple things, like constant pool loads
> don't have dependencies, and references to distinct stack slots are
> independent, and so on.

Ok.

> I have a few ideas for how more precise memory dependencies might be
> achieved.
>
> We have MachineMemOperands, which can be used to make AliasAnalysis
> or other LLVM-IR-level analysis queries. They need some work though;
> the main issue is that there are some places in codegen that don't
> preserve them.

Where are those places?  Can they be used in conjunction with 
MemoryDependenceAnalysis?  e.g. can we write a MachineInstructions-based 
memory dependence analysis that uses MachineMemoryOperands?

> Another possibility is to record dependence information from the
> SelectionDAG in MachineInstrs somehow. We don't yet have precise
> memory dependencies in the SelectionDAG, but it would be good to
> fix that too :-). 

Agreed.

> This would probably also involve AliasAnalysis  queries from codegen, 
> possibly going though the   MemoryDependenceAnalysis interface.

Do you have a vision for how this might work?  Wouldn't we need a new 
MachineFunctionPass to essentially do the same thing as 
MemoryDependenceAnalysis?

I don't think it's sufficient to just preserve the information we had from 
Instructions.  Codegen might introduce new memory operations after lowering 
(spilling, for example).  Some of these might be easily analyzable (spills) 
but others might not be.

But maybe we don't need to worry about that right now.  As I think about the 
problem I'm working on, "merely" preserving dependence information from 
Instructions would help.  It seems like if we can preserve that information in 
SelectionDAG we ought to be able to record it in MachineInstructions (or 
MachineMemOperands?) when lowering.

Hmm...then again looking at the MachineMemOperand documentation, fixing the 
places that invalidate those might work well too.  I'm a little wary of having 
the same information in two different places.

                                           -Dave

From regehr at cs.utah.edu  Mon Jan 19 19:34:13 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Mon, 19 Jan 2009 18:34:13 -0700
Subject: [LLVMdev] linux build problem
Message-ID: <49752A15.3010305@cs.utah.edu>

Since yesterday I've been getting the error below when building llvm-gcc 
on Ubuntu Hardy on x86.   For some reason, several instances of autoconf 
are getting confused and failing to detect a stdlib.h.

John


/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc 
-B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/ 
-B/home/regehr/z/tmp/llvm-gcc-r62547-install/i686-pc-linux-gnu/bin/ -c 
-DHAVE_CONFIG_H -O2 -g -fomit-frame-pointer -I. 
-I../../libiberty/../include  -W -Wall -pedantic -Wwrite-strings 
-Wstrict-prototypes -Wc++-compat ../../libiberty/cplus-dem.c -o cplus-dem.o
no
checking for ldfcn.h... ../../libiberty/cplus-dem.c:55: warning: 
function declaration isn?t a prototype
../../libiberty/cplus-dem.c:55: error: conflicting types for ?malloc?

From gohman at apple.com  Mon Jan 19 19:47:30 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 19 Jan 2009 17:47:30 -0800
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <200901191906.06656.dag@cray.com>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<200901191738.11536.dag@cray.com>
	<616D3219-103E-4CB0-BA07-D690F93687B9@apple.com>
	<200901191906.06656.dag@cray.com>
Message-ID: <FA3EBC4E-5976-4677-8CC0-55AD2D625E1F@apple.com>


On Jan 19, 2009, at 5:06 PM, David Greene wrote:

> On Monday 19 January 2009 18:21, Dan Gohman wrote:
>
>>> Dan, how does the scheduler handle memory dependence?  I'm working  
>>> on
>>> something that requires memory dependence information for
>>> MachineInstructions.
>>
>> At the moment, it knows simple things, like constant pool loads
>> don't have dependencies, and references to distinct stack slots are
>> independent, and so on.
>
> Ok.
>
>> I have a few ideas for how more precise memory dependencies might be
>> achieved.
>>
>> We have MachineMemOperands, which can be used to make AliasAnalysis
>> or other LLVM-IR-level analysis queries. They need some work though;
>> the main issue is that there are some places in codegen that don't
>> preserve them.
>
> Where are those places?

We don't have a definite list. It's largely testable though; you
could add an assert like this:

   !(MI->mayLoad() || MI->mayStore()) || !MI->memoperands_empty()

to catch most cases. There may not be many places left at
this point.

>  Can they be used in conjunction with
> MemoryDependenceAnalysis?  e.g. can we write a MachineInstructions- 
> based
> memory dependence analysis that uses MachineMemoryOperands?

Right, the existing MemoryDependenceAnalysis works in terms of
LLVM-IR-level Instructions, but yes, it would be possible to
implement the same thing for MachineInstrs, using AliasAnalysis
queries from MachineMemOperands. As of this writing I'm not
prepared to guess whether this would be a good idea :-).

>
>
>> Another possibility is to record dependence information from the
>> SelectionDAG in MachineInstrs somehow. We don't yet have precise
>> memory dependencies in the SelectionDAG, but it would be good to
>> fix that too :-).
>
> Agreed.
>
>> This would probably also involve AliasAnalysis  queries from codegen,
>> possibly going though the   MemoryDependenceAnalysis interface.
>
> Do you have a vision for how this might work?  Wouldn't we need a new
> MachineFunctionPass to essentially do the same thing as
> MemoryDependenceAnalysis?

A possible vision is that SelectionDAGBuild could use
MemoryDependenceAnalysis when building the initial SelectionDAG.
It's walking the IR-level Instructions, so it can use any
IR-level analysis. I haven't yet looked into this in detail.
A significant question is whether non-local dependencies are
important; some day we may extend SelectionDAGs to handle
more than one block at a time.

>
>
> I don't think it's sufficient to just preserve the information we  
> had from
> Instructions.  Codegen might introduce new memory operations after  
> lowering
> (spilling, for example).  Some of these might be easily analyzable  
> (spills)
> but others might not be.

This is where PseudoSourceValues come in. There are pseudo-values
representing the stack, constants area, GOT, and other memory
locations that aren't represented at the LLVM-IR level.

>
>
> But maybe we don't need to worry about that right now.  As I think  
> about the
> problem I'm working on, "merely" preserving dependence information  
> from
> Instructions would help.  It seems like if we can preserve that  
> information in
> SelectionDAG we ought to be able to record it in MachineInstructions  
> (or
> MachineMemOperands?) when lowering.
>
> Hmm...then again looking at the MachineMemOperand documentation,  
> fixing the
> places that invalidate those might work well too.  I'm a little wary  
> of having
> the same information in two different places.

I think the biggest challenge here is finding a design that
is reasonably efficient in terms of compile time and space while
still providing useful information.

Dan


From aoeullvm at brinckerhoff.org  Mon Jan 19 20:18:56 2009
From: aoeullvm at brinckerhoff.org (John Clements)
Date: Mon, 19 Jan 2009 18:18:56 -0800
Subject: [LLVMdev] bitcast i32 ... to i32 "magically fixes" value?
Message-ID: <BBF46C73-4652-4B13-B2F4-B744ED06F206@brinckerhoff.org>

Here's a piece of code that behaves in a way that appears insane to  
me; I'm hoping that someone can either explain to me why this is the  
right behavior, or label it a bug.

target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- 
i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64- 
f80:128:128"
target triple = "i386-apple-darwin8"

define i32 @entry () {
	%result = invoke i32 @main_0() to label %Done unwind label %Exn
Done:
        %magically_fixed = bitcast i32 %result to i32
	ret i32 %result         ; change to %magically_fixed
;;;     ret i32 %magically_fixed

Exn:
	ret i32 16
}

define i32 @main_0() {
	ret i32 8
}

@.str = internal constant [7 x i8] c"0x%08x\00"		; <[7 x i8]*> [#uses=1]

define i32 @main(i32 %argc, i8** %argv) nounwind  {
entry:
	%tmp = call i32 @entry( ) nounwind 		; <i32> [#uses=1]
	%tmp2 = call i32 (i8*, ...)* @printf( i8* getelementptr ([7 x i8]*  
@.str, i32 0, i32 0), i32 %tmp ) nounwind 		; <i32> [#uses=0]
	ret i32 0
}

declare i32 @printf(i8*, ...) nounwind


I compile and run it like this:

lvm-as -f all.s
llvm-ld all.s.bc
./a.out


And the behavior I observe is that if I return "%magically_fixed"  
rather than "%result", I get the '0x00000008' I expect.  As is,  
though, the program prints out '0x00000001'.

Now, I'm guessing that I'm somehow misunderstanding the type system,  
and the result of the 'invoke' is not an i32... but then, why would  
the bitcast succeed?  I'm baffled.

Many thanks for any help; if I can't figure this out by Wednesday, my  
compilers class will be confused by this as well :).


John Clements

From scottm at aero.org  Mon Jan 19 20:36:32 2009
From: scottm at aero.org (Scott Michel)
Date: Mon, 19 Jan 2009 18:36:32 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
Message-ID: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>

I just ran across something interesting: DAGCombine inserts a 64-bit  
constant as the result of converting a (bitconvert (fabs val)) to a  
(and (bitconvert val), i64const).

The problem: i64 constants have to be legalized for the CellSPU  
platform. DAGCombine is doing the right thing but it's not doing the  
right thing for CellSPU and it's damed difficult to work around this  
"feature". Moreover, the way all of SelectionDAGLegalize and  
DAGCombne's code is written, it's particularly difficult to "re- 
legalize" nodes unless one more legalization pass is invoked after  
DAGCombine.

It's not like it's actually easy to load an i64 constant while  
maintaining the vector register uniformity that CellSPU expects. In  
fact, there're a lot of different ways to load a 64-bit constant  
depending on the constant's value. At worse case, it's a constant  
pool load on a memory-constrained machine (256K). But it can be a lot  
better than paying the 6-cycle penalty for memory loads.

OTOH, that's why I created all of that legalization code in the first  
place so the backend could get it right.

Suggestions apart from doing custom fabs legalization in CellSPU  
(sorta defeats the purpose of DAGCombine, no)?


-scooter



From scottm at aero.org  Mon Jan 19 20:39:45 2009
From: scottm at aero.org (Scott Michel)
Date: Mon, 19 Jan 2009 18:39:45 -0800
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <85181497-D132-446B-A5AA-A19840D5F7E0@apple.com>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<4E71A380-CB54-415F-822C-3285FEB44221@apple.com>
	<alpine.LRH.1.10.0901191952420.20397@pub4.ifh.de>
	<85181497-D132-446B-A5AA-A19840D5F7E0@apple.com>
Message-ID: <E04CD967-3A9A-450C-88BC-96FB13EF7B36@aero.org>

Dan:

CellSPU could clearly benefit from the post-RA scheduler. In fact, we  
were thinking about writing a machine pass of our own.

One thing that does "disturb" me is that both HazardRecognizer and  
post-RA sched assume there's only one kind of NOP. For Cell, there  
are two, depending upon the pipeline being filled. Pipe 0 takes  
"ENOP" whereas Pipe 1 take "LNOP" (depends on the low order PC bits.)


-scooter

On Jan 19, 2009, at 2:42 PM, Dan Gohman wrote:

>
> On Jan 19, 2009, at 11:01 AM, Patrick Boettcher wrote:
>>
>>
>>>> And more generally: Is the hazardRecognizer the right and only way
>>>> to
>>>> solve our NOOP-minimizing problem?
>>>
>>> Perhaps you want to do this after register allocation is done.  
>>> Dan is
>>> developing the post-allocation scheduler. You can try it out.
>>
>> Interesting. Can it already be found SVN? I will search the mail
>> archive
>> later, if not.
>
> Yes, it is in SVN. It's new, and so far it's only being used in  
> limited
> ways, and not anything like your specific problem. We don't currently
> have any targets in-tree that require no-ops, so it may not address  
> all
> your needs out of the box, but patches are welcome :-).
>
> Dan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From scottm at aero.org  Mon Jan 19 20:42:17 2009
From: scottm at aero.org (Scott Michel)
Date: Mon, 19 Jan 2009 18:42:17 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
Message-ID: <B8C5827E-8FE4-4BA0-8811-1DFC8C18AA00@aero.org>

Before anyone asks: yes using i64 on the Cell's SPUs is a really bad  
and stupid idea. But, I have to support the data type to make gcc happy.

Nonetheless, i64 constants have to be legalized.


-scooter

On Jan 19, 2009, at 6:36 PM, Scott Michel wrote:

> I just ran across something interesting: DAGCombine inserts a 64-bit
> constant as the result of converting a (bitconvert (fabs val)) to a
> (and (bitconvert val), i64const).
>
> The problem: i64 constants have to be legalized for the CellSPU
> platform. DAGCombine is doing the right thing but it's not doing the
> right thing for CellSPU and it's damed difficult to work around this
> "feature". Moreover, the way all of SelectionDAGLegalize and
> DAGCombne's code is written, it's particularly difficult to "re-
> legalize" nodes unless one more legalization pass is invoked after
> DAGCombine.
>
> It's not like it's actually easy to load an i64 constant while
> maintaining the vector register uniformity that CellSPU expects. In
> fact, there're a lot of different ways to load a 64-bit constant
> depending on the constant's value. At worse case, it's a constant
> pool load on a memory-constrained machine (256K). But it can be a lot
> better than paying the 6-cycle penalty for memory loads.
>
> OTOH, that's why I created all of that legalization code in the first
> place so the backend could get it right.
>
> Suggestions apart from doing custom fabs legalization in CellSPU
> (sorta defeats the purpose of DAGCombine, no)?
>
>
> -scooter
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From eli.friedman at gmail.com  Mon Jan 19 22:15:07 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 19 Jan 2009 20:15:07 -0800
Subject: [LLVMdev] bitcast i32 ... to i32 "magically fixes" value?
In-Reply-To: <BBF46C73-4652-4B13-B2F4-B744ED06F206@brinckerhoff.org>
References: <BBF46C73-4652-4B13-B2F4-B744ED06F206@brinckerhoff.org>
Message-ID: <f5aa3e9b0901192015l78ab6d0g4dc9c860441d5bb6@mail.gmail.com>

On Mon, Jan 19, 2009 at 6:18 PM, John Clements
<aoeullvm at brinckerhoff.org> wrote:
> Here's a piece of code that behaves in a way that appears insane to
> me; I'm hoping that someone can either explain to me why this is the
> right behavior, or label it a bug.

Probably a bug; I'm getting the expected behavior with r62473 on Linux.

-Eli

From eli.friedman at gmail.com  Mon Jan 19 22:17:34 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 19 Jan 2009 20:17:34 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
Message-ID: <f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>

On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> wrote:
> I just ran across something interesting: DAGCombine inserts a 64-bit
> constant as the result of converting a (bitconvert (fabs val)) to a
> (and (bitconvert val), i64const).
>
> The problem: i64 constants have to be legalized for the CellSPU
> platform. DAGCombine is doing the right thing but it's not doing the
> right thing for CellSPU and it's damed difficult to work around this
> "feature". Moreover, the way all of SelectionDAGLegalize and
> DAGCombne's code is written, it's particularly difficult to "re-
> legalize" nodes unless one more legalization pass is invoked after
> DAGCombine.

I don't think DAGCombine should be doing a transform like that
post-legalize; if it is, it's probably a bug.

-Eli

From isanbard at gmail.com  Tue Jan 20 00:01:39 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 19 Jan 2009 22:01:39 -0800
Subject: [LLVMdev] linux build problem
In-Reply-To: <49752A15.3010305@cs.utah.edu>
References: <49752A15.3010305@cs.utah.edu>
Message-ID: <A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>

On Jan 19, 2009, at 5:34 PM, John Regehr wrote:

> Since yesterday I've been getting the error below when building llvm- 
> gcc
> on Ubuntu Hardy on x86.   For some reason, several instances of  
> autoconf
> are getting confused and failing to detect a stdlib.h.
>
> John
>
>
> /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc
> -B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/
> -B/home/regehr/z/tmp/llvm-gcc-r62547-install/i686-pc-linux-gnu/bin/ -c
> -DHAVE_CONFIG_H -O2 -g -fomit-frame-pointer -I.
> -I../../libiberty/../include  -W -Wall -pedantic -Wwrite-strings
> -Wstrict-prototypes -Wc++-compat ../../libiberty/cplus-dem.c -o  
> cplus-dem.o
> no
> checking for ldfcn.h... ../../libiberty/cplus-dem.c:55: warning:
> function declaration isn?t a prototype
> ../../libiberty/cplus-dem.c:55: error: conflicting types for ?malloc?
> _______________________________________________

I'll need some more information than this. I don't have a Linux box,  
so I can't tell. Do you have a .i file? How is autoconf being  
confused? What does config.log say about it?

-bw



From echeng at apple.com  Tue Jan 20 00:52:37 2009
From: echeng at apple.com (Evan Cheng)
Date: Mon, 19 Jan 2009 22:52:37 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
	<f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>
Message-ID: <8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>

Right. DAGCombine will insert *illegal* nodes before legalize.

Evan

On Jan 19, 2009, at 8:17 PM, Eli Friedman wrote:

> On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> wrote:
>> I just ran across something interesting: DAGCombine inserts a 64-bit
>> constant as the result of converting a (bitconvert (fabs val)) to a
>> (and (bitconvert val), i64const).
>>
>> The problem: i64 constants have to be legalized for the CellSPU
>> platform. DAGCombine is doing the right thing but it's not doing the
>> right thing for CellSPU and it's damed difficult to work around this
>> "feature". Moreover, the way all of SelectionDAGLegalize and
>> DAGCombne's code is written, it's particularly difficult to "re-
>> legalize" nodes unless one more legalization pass is invoked after
>> DAGCombine.
>
> I don't think DAGCombine should be doing a transform like that
> post-legalize; if it is, it's probably a bug.
>
> -Eli
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From baldrick at free.fr  Tue Jan 20 02:24:13 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Jan 2009 09:24:13 +0100
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
	<f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>
	<8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>
Message-ID: <200901200924.13484.baldrick@free.fr>

On Tuesday 20 January 2009 07:52:37 Evan Cheng wrote:
> Right. DAGCombine will insert *illegal* nodes before legalize.

There are two stages of legalization: legalization of types,
followed by legalization of operations.  Before type legalization
DAGCombine is allowed to create nodes with illegal types and illegal
operations.  After type legalization but before operation legalization
it is allowed to create nodes with illegal operations, but all types
must be legal.  After operation legalization it is only allowed to
create fully legal nodes.

Inside DAGCombine this is specified by two flags:
  LegalTypes being true means that all nodes must have legal types.
  LegalOperations being true means that all nodes must have legal
operations (as well as types: LegalTypes will also be true).

So if LegalTypes is true and nonetheless a constant with an
illegal type is being created then that is a DAG combiner bug.

Ciao,

Duncan.

From edwintorok at gmail.com  Tue Jan 20 02:45:19 2009
From: edwintorok at gmail.com (=?windows-1252?Q?T=F6r=F6k_Edwin?=)
Date: Tue, 20 Jan 2009 10:45:19 +0200
Subject: [LLVMdev] linux build problem
In-Reply-To: <A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
Message-ID: <49758F1F.5070300@gmail.com>

On 2009-01-20 08:01, Bill Wendling wrote:
> On Jan 19, 2009, at 5:34 PM, John Regehr wrote:
>
>   
>> Since yesterday I've been getting the error below when building llvm- 
>> gcc
>> on Ubuntu Hardy on x86.   For some reason, several instances of  
>> autoconf
>> are getting confused and failing to detect a stdlib.h.
>>
>> John
>>
>>
>> /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc
>> -B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/
>> -B/home/regehr/z/tmp/llvm-gcc-r62547-install/i686-pc-linux-gnu/bin/ -c
>> -DHAVE_CONFIG_H -O2 -g -fomit-frame-pointer -I.
>> -I../../libiberty/../include  -W -Wall -pedantic -Wwrite-strings
>> -Wstrict-prototypes -Wc++-compat ../../libiberty/cplus-dem.c -o  
>> cplus-dem.o
>> no
>> checking for ldfcn.h... ../../libiberty/cplus-dem.c:55: warning:
>> function declaration isn?t a prototype
>> ../../libiberty/cplus-dem.c:55: error: conflicting types for ?malloc?
>> _______________________________________________
>>     
>
> I'll need some more information than this. I don't have a Linux box,  
> so I can't tell. Do you have a .i file? How is autoconf being  
> confused? What does config.log say about it?
>
>   

I've seen this failure on my nightly builder too (SVN r62521), it is
related to the -Wformat-security changes,
apparently libiberty's configure considers warnings as failures:

configure:3691: checking for stdlib.h
configure:3704:  /home/edwin/llvm-bootstrap/llvm-obj/./prev-gcc/xgcc
-B/home/edwin/llvm-bootstrap/llvm-obj/./prev-gcc/
-B/home/edwin/llvm-bootstrap/llvm-obj/../install/x86_64-unknown-linux-gnu/bin/
-E  conftest.c

cc1: warning: -Wformat-security ignored without -Wformat

configure:3710: $? = 0
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
| #include <stdlib.h>
configure:3731: result: no

Best regards,
--Edwin

From jay.foad at gmail.com  Tue Jan 20 03:22:08 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Tue, 20 Jan 2009 09:22:08 +0000
Subject: [LLVMdev] cygwin build patch
In-Reply-To: <5CE7EB46-16C0-42FC-9A12-13328B7053AD@apple.com>
References: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>
	<5CE7EB46-16C0-42FC-9A12-13328B7053AD@apple.com>
Message-ID: <ee2e06e90901200122y5257d042g91aecec43019d287@mail.gmail.com>

>> I realise that the DataTypes.h.in part might be controversial. Also,
>> there's probably a better place to put it, but I'm not sure where.
>
> I didn't apply this part.  What problems does it cause to not have
> this?  Can we fix uses of max and min?

I get these errors in lib:

.../lib/Analysis/ValueTracking.cpp:162: error: no matching function
for call to 'min(unsigned int&, uint32_t&)'
.../lib/Analysis/ValueTracking.cpp:163: error: no matching function
for call to 'min(unsigned int&, uint32_t&)'
.../lib/Analysis/ValueTracking.cpp:358: error: no matching function
for call to 'min(unsigned int&, uint32_t)'
.../lib/Analysis/ValueTracking.cpp:469: error: no matching function
for call to 'min(unsigned int&, long unsigned int)'
.../lib/Analysis/ValueTracking.cpp:708: error: no matching function
for call to 'min(unsigned int&, uint32_t)'
.../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1432: error: no matching
function for call to 'max(long unsigned int, unsigned int&)'
.../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1747: error: no matching
function for call to 'min(unsigned int&, uint32_t)'
.../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2033: error: no matching
function for call to 'min(unsigned int&, uint32_t)'

I could try to fix this by changing the code to consistently use
either unsigned or uint32_t (which?), rather than both. Or by adding
casts at the point of calling min/max. What would you prefer?

Thanks,
Jay.

From eli.friedman at gmail.com  Tue Jan 20 03:23:45 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 20 Jan 2009 01:23:45 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <200901200924.13484.baldrick@free.fr>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
	<f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>
	<8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>
	<200901200924.13484.baldrick@free.fr>
Message-ID: <f5aa3e9b0901200123k61d8c438hcf902868063c10b7@mail.gmail.com>

On Tue, Jan 20, 2009 at 12:24 AM, Duncan Sands <baldrick at free.fr> wrote:
> So if LegalTypes is true and nonetheless a constant with an
> illegal type is being created then that is a DAG combiner bug.

The issue here isn't that i64 is illegal, it's that constants of type
i64 are illegal.  I'm tempted to say that having legal constants
should be a requirement for marking an integer type legal...

-Eli

From patrick.boettcher at desy.de  Tue Jan 20 03:44:36 2009
From: patrick.boettcher at desy.de (Patrick Boettcher)
Date: Tue, 20 Jan 2009 10:44:36 +0100 (CET)
Subject: [LLVMdev] [PATCH] correct argument order of gv when viewgraph is
	called
Message-ID: <alpine.LRH.1.10.0901201042000.20397@pub4.ifh.de>

Hi list,

On my system I have gv 3.5.8 and it does not like to be called with 
--spartan before the <filename>.

The man-page is stating that the file name has to come before all 
arguments and the --spartan is actually -spartan. I don't know for newer 
versions of gv.

The attached patch fixes that for me.

Please apply if appropriate.

thanks,
Patrick.
-------------- next part --------------
Index: lib/Support/GraphWriter.cpp
===================================================================
--- lib/Support/GraphWriter.cpp	(revision 62576)
+++ lib/Support/GraphWriter.cpp	(working copy)
@@ -57,8 +57,8 @@
     sys::Path gv(LLVM_PATH_GV);
     args.clear();
     args.push_back(gv.c_str());
-    args.push_back("--spartan");
     args.push_back(PSFilename.c_str());
+    args.push_back("-spartan");
     args.push_back(0);
     
     ErrMsg.clear();

From aph at redhat.com  Tue Jan 20 04:10:32 2009
From: aph at redhat.com (Andrew Haley)
Date: Tue, 20 Jan 2009 10:10:32 +0000
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
In-Reply-To: <99AFFD84-D5A8-4094-8FB9-DDAD8E2AE20E@apple.com>
References: <4974A258.1040108@redhat.com>
	<99AFFD84-D5A8-4094-8FB9-DDAD8E2AE20E@apple.com>
Message-ID: <4975A318.2040208@redhat.com>

Chris Lattner wrote:
> On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote:
> 
>> This is x86_64.  I have a problem where an absolute memory load
>> The current LLVM trunk does not have this bug.  This seems quite a  
>> nasty
>> bug; is there any chance of a bug-fix release for LLVM 2.4, or  
>> should I
>> just use LLVM trunk until LLVM 2.5 ?
> 
> As others have pointed out, using a global and addglobalmapping is a  
> great workaround for the problem.

Thanks.

> We generally don't do "dot" releases, since we have a short release  
> cycle anyway.  The 2.5 release process is slated to start this week.

Mmm, but the problem is that interfaces keep changing, so simply
upgrading to the latest release isn't possible.  Even the tiny
test case I posted doesn't work with the latest version: there
were changes needed to get it to compile.  Also, I can no longer
figure out how to turn on debugging dumps in the JIT.  The simple

   DebugFlag = true;
   CurrentDebugType = "x86-emitter";

no longer works, and there seems to be no replacement for it.

Andrew.

From Chareos at gmx.de  Tue Jan 20 04:29:05 2009
From: Chareos at gmx.de (Ralf Karrenberg)
Date: Tue, 20 Jan 2009 11:29:05 +0100
Subject: [LLVMdev] if-conversion
Message-ID: <4975A771.7050701@gmx.de>

Hello everyone,

I'd like to know if there is an optimization in llvm doing something
like an if-conversion on the IR. I only found IfConversion.cpp which
appears to only provide the desired functionality on machine code during
code-generation.

I want to transform branches into serial code with select-instructions
as a pre-processing step for further transformations.

If there is no such pass, I will possibly write one and share it
(although I have no idea how to do so yet), so please let me know :).

Cheers,
Ralf

From isanbard at gmail.com  Tue Jan 20 04:38:14 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 20 Jan 2009 02:38:14 -0800
Subject: [LLVMdev] linux build problem
In-Reply-To: <49758F1F.5070300@gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
	<49758F1F.5070300@gmail.com>
Message-ID: <0DF271BD-B19B-4E8C-9F41-7BB149CAE2D5@gmail.com>

On Jan 20, 2009, at 12:45 AM, T?r?k Edwin wrote:
> On 2009-01-20 08:01, Bill Wendling wrote:
>> I'll need some more information than this. I don't have a Linux box,
>> so I can't tell. Do you have a .i file? How is autoconf being
>> confused? What does config.log say about it?
>>
>>
> I've seen this failure on my nightly builder too (SVN r62521), it is
> related to the -Wformat-security changes,
> apparently libiberty's configure considers warnings as failures:
>
> configure:3691: checking for stdlib.h
> configure:3704:  /home/edwin/llvm-bootstrap/llvm-obj/./prev-gcc/xgcc
> -B/home/edwin/llvm-bootstrap/llvm-obj/./prev-gcc/
> -B/home/edwin/llvm-bootstrap/llvm-obj/../install/x86_64-unknown- 
> linux-gnu/bin/
> -E  conftest.c
>
> cc1: warning: -Wformat-security ignored without -Wformat
>
I recently put in a "hack" that would default -Wformat-security to on  
when -Wformat is on, and off when off. Is it still breaking? If so,  
I'm going to hijack a coworker's Linux box and see if I can get to the  
bottom of this.

As always, I'm sorry for the breakage. These merges are annoying, but  
important for a variety of reasons. This merge, for instance, got the  
Fortran FE to compile and run the test suite. :-) I'll fix the build  
problems before the code freeze on the 21st.

-bw



From baldrick at free.fr  Tue Jan 20 05:03:04 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Jan 2009 12:03:04 +0100
Subject: [LLVMdev] linux build problem
In-Reply-To: <0DF271BD-B19B-4E8C-9F41-7BB149CAE2D5@gmail.com>
References: <49752A15.3010305@cs.utah.edu> <49758F1F.5070300@gmail.com>
	<0DF271BD-B19B-4E8C-9F41-7BB149CAE2D5@gmail.com>
Message-ID: <200901201203.04217.baldrick@free.fr>

Hi Bill,

> I recently put in a "hack" that would default -Wformat-security to on  
> when -Wformat is on, and off when off. Is it still breaking?

yes, I still see lots of
  "cc1: warning: -Wformat-security ignored without -Wformat"

> If so,  
> I'm going to hijack a coworker's Linux box and see if I can get to the  
> bottom of this.

Thanks!

Ciao,

Duncan.

From espindola at google.com  Tue Jan 20 05:06:41 2009
From: espindola at google.com (Rafael Espindola)
Date: Tue, 20 Jan 2009 11:06:41 +0000
Subject: [LLVMdev] linux build problem
In-Reply-To: <0DF271BD-B19B-4E8C-9F41-7BB149CAE2D5@gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
	<49758F1F.5070300@gmail.com>
	<0DF271BD-B19B-4E8C-9F41-7BB149CAE2D5@gmail.com>
Message-ID: <38a0d8450901200306i2df58ccfq56bb87b68f32eec9@mail.gmail.com>

> I recently put in a "hack" that would default -Wformat-security to on
> when -Wformat is on, and off when off. Is it still breaking? If so,
> I'm going to hijack a coworker's Linux box and see if I can get to the
> bottom of this.
>
> As always, I'm sorry for the breakage. These merges are annoying, but
> important for a variety of reasons. This merge, for instance, got the
> Fortran FE to compile and run the test suite. :-) I'll fix the build
> problems before the code freeze on the 21st.

I just got this failure :-(

Trying to investigate a bit.

> -bw

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

From danchr at gmail.com  Tue Jan 20 05:46:47 2009
From: danchr at gmail.com (Dan Villiom Podlaski Christiansen)
Date: Tue, 20 Jan 2009 12:46:47 +0100
Subject: [LLVMdev] avoid creating .dir files
In-Reply-To: <8A51D4F0-05E3-44DD-9620-27DE614D0D37@apple.com>
References: <3B14683F-547E-49E9-8DFE-BB35FED0D124@apple.com>
	<50140231-8562-4610-A269-449C87B718DB@apple.com>
	<8A51D4F0-05E3-44DD-9620-27DE614D0D37@apple.com>
Message-ID: <E16012CF-DFC2-449C-8DDC-4E5CCF81D511@gmail.com>

On 20 Jan 2009, at 00:04, Mike Stump wrote:

> On Jan 19, 2009, at 1:58 PM, Chris Lattner wrote:
>> On Jan 19, 2009, at 10:02 AM, Mike Stump wrote:
>>
>>> There isn't a good reason to create files called .dir in the
>>> installation directory.  This patch fixes that.
>>
>> If we don't have this line, every build with do the makedir.
>
> And?
>
> $ time mkdir -p /bin
>
> real	0m0.002s
> user	0m0.000s
> sys	0m0.002s
>
> an extra mkdir takes around 2ms per build.  An up-to-date inc build
> takes 2231ms for me.  If you want some of the extra 2231ms back, I'd
> recommend avoiding recursion in the makefiles.  This will yield a
> larger benefit than worrying about the extra mkdir.

Not that it really matters, but do note that the LLVM build system  
uses ?$(LLVM_SRC_ROOT)/autoconf/mkinstalldirs? for MKDIR, rather  
than just ?mkdir?.

> If we have it, then .dir files are created in the installation
> directories.
>
> Trivially one can do:
>
> /dir:
> 	mkdir /dir
>
> /dir/prog: /dir
> 	gcc hi.c -o /dir/prog
>
> and avoid the extra mkdir, if one wanted.  Any down side to doing  
> that?

Yes, ?prog? will be remade every time a file as added to or removed  
from the directory. (I haven't checked just now, but I'm fairly  
certain that's what will happen.) One way to solve this is by using an  
order-only dependancy:

/dir/prog: | /dir
	gcc hi.c -o /dir/prog

This will cause GNU Make to ensure that /dir is made _before_ /dir/ 
prog, but without invalidating the /dir/prog target when /dir is  
updated/invalidated.

Is it possible that I could get you to wait a bit with these changes?  
I just obtained commit access and set up a way to move over my changes  
from Mercurial to Subversion. I hope to have most of my changes to the  
build system integrated, and plan to post a proposal of how to get it  
done within the next few days or so.

Apart from a general overhaul of the Makefiles, I integrated Clang  
into much of the LLVM build system, for instance ?llvm-config?.

--

Dan Villiom Podlaski Christiansen, stud. scient.,
danchr at cs.au.dk, danchr at gmail.com



From jay.foad at gmail.com  Tue Jan 20 06:06:55 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Tue, 20 Jan 2009 12:06:55 +0000
Subject: [LLVMdev] build failure: gcc 3.x doesn't support new warning options
Message-ID: <ee2e06e90901200406l26e960cegf45d10f3ca01eb25@mail.gmail.com>

GCC 3.x doesn't support -Wno-missing-field-initializers or
-Wno-variadic-macros, so I get this build failure (with GCC 3.4.4 on
Cygwin):

make[3]: Entering directory
`/home/foad/llvm/objdir-svn/utils/unittest/googletest'
llvm[3]: Compiling gtest.cc for Debug build
cc1plus: error: unrecognized command line option
"-Wno-missing-field-initializers"
cc1plus: error: unrecognized command line option "-Wno-variadic-macros"

These flags are specified in utils/unittest/googletest/Makefile:

CPP.Flags += -Wno-missing-field-initializers -Wno-variadic-macros

Is there any way to make this conditional on the compiler version? Or something?

Thanks,
Jay.

From espindola at google.com  Tue Jan 20 07:49:12 2009
From: espindola at google.com (Rafael Espindola)
Date: Tue, 20 Jan 2009 13:49:12 +0000
Subject: [LLVMdev] linux build problem
In-Reply-To: <0DF271BD-B19B-4E8C-9F41-7BB149CAE2D5@gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
	<49758F1F.5070300@gmail.com>
	<0DF271BD-B19B-4E8C-9F41-7BB149CAE2D5@gmail.com>
Message-ID: <38a0d8450901200549p44d83e02v22cf3b4503005a51@mail.gmail.com>

> As always, I'm sorry for the breakage. These merges are annoying, but
> important for a variety of reasons. This merge, for instance, got the
> Fortran FE to compile and run the test suite. :-) I'll fix the build
> problems before the code freeze on the 21st.

np. Can you try the attached patch? The  idea is to have the driver
(gcc) handle the darwin/non-darwin issues and the compiler (cc1) just
uses the  arguments passed to it.

Fixes the build on linux.

> -bw
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047
-------------- next part --------------
A non-text attachment was scrubbed...
Name: format2.patch
Type: text/x-diff
Size: 4099 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090120/fb583414/attachment-0001.bin 

From Axel.Naumann at cern.ch  Tue Jan 20 07:56:44 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Tue, 20 Jan 2009 14:56:44 +0100
Subject: [LLVMdev] Supported JIT targets
Message-ID: <4975D81C.10007@cern.ch>

Hi,

I've been trying to find a list of the current JIT-supported targets. Not easy
:-) The sources seem to say that the architectures are X86, PowerPC, ARM,
Alpha. And then their obvious combination with Linux, FreeBSD / MacOSX, Win32 -
is that it?

Cheers, Axel.

From danchr at gmail.com  Tue Jan 20 08:56:03 2009
From: danchr at gmail.com (Dan Villiom Podlaski Christiansen)
Date: Tue, 20 Jan 2009 15:56:03 +0100
Subject: [LLVMdev] building clang when present
In-Reply-To: <7BD371DD-0C21-437F-A7CB-E190FE0A9AA4@apple.com>
References: <B7AEB01A-6D62-4C0E-B866-32BF92F24C23@apple.com>
	<E580CC6E-5559-4E6F-8BEF-30C8E35468AA@gmail.com>
	<DE8B40B5-2CB1-4D59-87A3-DBB14BFB282A@apple.com>
	<643B3B96-9751-4B19-B845-F0932EB829AD@gmail.com>
	<7BD371DD-0C21-437F-A7CB-E190FE0A9AA4@apple.com>
Message-ID: <71AE2DBA-1B1A-4C76-A3B8-316D8D771564@gmail.com>

On 19 Jan 2009, at 21:53, Mike Stump wrote:

> On Jan 19, 2009, at 12:35 PM, Dan Villiom Podlaski Christiansen wrote:
>> On 19 Jan 2009, at 21:16, Mike Stump wrote:
>>
>>> On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen
>>> wrote:
>>>> In my humble opinion, using OPTIONAL_DIRS would be better and
>>>> cleaner.
>>>> It may require some changes to ?Makefile.rules? to work as
>>>> intended, though. If there's interest in such a change, I can
>>>> prepare
>>>> a patch?
>>>
>>> Are OPTIONAL_DIRS parallel?  For some reason, I was assuming not.
>>
>> Well, from my recollection, PARALLEL_DIRS and the other *_DIRS don't
>> interact terribly well with each other with the current LLVM build
>> system. It may or may not actually be executed parallel with other
>> directories, but I wouldn't consider that a problem, as Clang itself
>> contains quite a lot of source files, libraries and directories.
>> Parallelism within the Clang source should be Good Enough? ;)
>
> If there are bugs in the parallel aspects of llvm, I've never hit
> them.  I only ever build 8-way, and I expect it to just work; if it
> doesn't, I'd rather just fix it.  Avoiding parallel isn't the way to
> get a build system that just works in parallel.  Lastly, I'm more
> demanding than, good enough.

I don't believe any Makefile currently defines both PARALLEL_DIRS and  
one of the other DIRS variables. So you wouldn't have run into such  
bugs, yet :)

> I'll add OPTIONAL_PARALLEL_DIRS, if people would rather it be done
> that way.  :-)

My point is that the Clang source base is sufficiently large that  
there's little benefit to running it in parallel with other  
directories; parallelism within the Clang sources should more than  
suffice. I haven't tried compiling LLVM on any more than a dual core  
machine, so this is a bit theoretical for me :)

Please try the attached patch and see if it suits your needs; it fixes  
OPTIONAL_DIRS so it works as intended for in-source builds too, and  
ensures that PARALLEL_DIRS are built *after* other targets; mainly for  
the purpose of consistency and reproducability. If ?llvm-config? were  
added to OPTIONAL_DIRS or DIRS, it would always be processed before  
the other directories.

--

Dan Villiom Podlaski Christiansen, stud. scient.,
danchr at cs.au.dk, danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-clang.diff
Type: application/octet-stream
Size: 955 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090120/0a0d5f19/attachment.obj 
-------------- next part --------------


From eli.friedman at gmail.com  Tue Jan 20 10:25:30 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 20 Jan 2009 08:25:30 -0800
Subject: [LLVMdev] if-conversion
In-Reply-To: <4975A771.7050701@gmx.de>
References: <4975A771.7050701@gmx.de>
Message-ID: <f5aa3e9b0901200825x2dae5e08wad150ff3a469733d@mail.gmail.com>

On Tue, Jan 20, 2009 at 2:29 AM, Ralf Karrenberg <Chareos at gmx.de> wrote:
> I want to transform branches into serial code with select-instructions
> as a pre-processing step for further transformations.

SimplifyCFG should be doing this transform in very simple cases.
Depending on what you're doing, though, its might not be aggressive
enough.

-Eli

From regehr at cs.utah.edu  Tue Jan 20 10:35:37 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Tue, 20 Jan 2009 09:35:37 -0700 (MST)
Subject: [LLVMdev] linux build problem
In-Reply-To: <A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
Message-ID: <alpine.DEB.1.00.0901200933260.4381@babel.cs.utah.edu>

I'm away from my Linux machines, if this hasn't been resolved by tonight 
I'll send more details.

THe problem in cplus-dem.c is that CPP is conditionally including code 
that comes when HAVE_STDLIB is not defined, including an alternate 
protptype for malloc() that conflicts with the existing one.  This is just 
what causes the error I sent-- no idea what the root cause is.

Thanks,

John



On Mon, 19 Jan 2009, Bill Wendling wrote:

> On Jan 19, 2009, at 5:34 PM, John Regehr wrote:
>
>> Since yesterday I've been getting the error below when building llvm-
>> gcc
>> on Ubuntu Hardy on x86.   For some reason, several instances of
>> autoconf
>> are getting confused and failing to detect a stdlib.h.
>>
>> John
>>
>>
>> /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc
>> -B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/
>> -B/home/regehr/z/tmp/llvm-gcc-r62547-install/i686-pc-linux-gnu/bin/ -c
>> -DHAVE_CONFIG_H -O2 -g -fomit-frame-pointer -I.
>> -I../../libiberty/../include  -W -Wall -pedantic -Wwrite-strings
>> -Wstrict-prototypes -Wc++-compat ../../libiberty/cplus-dem.c -o
>> cplus-dem.o
>> no
>> checking for ldfcn.h... ../../libiberty/cplus-dem.c:55: warning:
>> function declaration isn?t a prototype
>> ../../libiberty/cplus-dem.c:55: error: conflicting types for ?malloc?
>> _______________________________________________
>
> I'll need some more information than this. I don't have a Linux box,
> so I can't tell. Do you have a .i file? How is autoconf being
> confused? What does config.log say about it?
>
> -bw
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From espindola at google.com  Tue Jan 20 10:44:35 2009
From: espindola at google.com (Rafael Espindola)
Date: Tue, 20 Jan 2009 16:44:35 +0000
Subject: [LLVMdev] linux build problem
In-Reply-To: <alpine.DEB.1.00.0901200933260.4381@babel.cs.utah.edu>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
	<alpine.DEB.1.00.0901200933260.4381@babel.cs.utah.edu>
Message-ID: <38a0d8450901200844lbc20612n5675083bba964060@mail.gmail.com>

2009/1/20 John Regehr <regehr at cs.utah.edu>:
> I'm away from my Linux machines, if this hasn't been resolved by tonight
> I'll send more details.
>
> THe problem in cplus-dem.c is that CPP is conditionally including code that
> comes when HAVE_STDLIB is not defined, including an alternate protptype for
> malloc() that conflicts with the existing one.  This is just what causes the
> error I sent-- no idea what the root cause is.

I have posted a patch that fixes it for me. Waiting for someone to
test it on Darwin.

> Thanks,
>
> John


Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

From scottm at aero.org  Tue Jan 20 10:50:37 2009
From: scottm at aero.org (Scott Michel)
Date: Tue, 20 Jan 2009 08:50:37 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
	<f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>
	<8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>
Message-ID: <61C79FD4-81CD-426E-B411-87701521D2D5@aero.org>

Evan:

And after legalize too. DAGCombine gets run after legalization. :-)


-scooter

On Jan 19, 2009, at 10:52 PM, Evan Cheng wrote:

> Right. DAGCombine will insert *illegal* nodes before legalize.
>
> Evan
>
> On Jan 19, 2009, at 8:17 PM, Eli Friedman wrote:
>
>> On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org>  
>> wrote:
>>> I just ran across something interesting: DAGCombine inserts a 64-bit
>>> constant as the result of converting a (bitconvert (fabs val)) to a
>>> (and (bitconvert val), i64const).
>>>
>>> The problem: i64 constants have to be legalized for the CellSPU
>>> platform. DAGCombine is doing the right thing but it's not doing the
>>> right thing for CellSPU and it's damed difficult to work around this
>>> "feature". Moreover, the way all of SelectionDAGLegalize and
>>> DAGCombne's code is written, it's particularly difficult to "re-
>>> legalize" nodes unless one more legalization pass is invoked after
>>> DAGCombine.
>>
>> I don't think DAGCombine should be doing a transform like that
>> post-legalize; if it is, it's probably a bug.
>>
>> -Eli
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From scottm at aero.org  Tue Jan 20 10:53:13 2009
From: scottm at aero.org (Scott Michel)
Date: Tue, 20 Jan 2009 08:53:13 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <200901200924.13484.baldrick@free.fr>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
	<f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>
	<8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>
	<200901200924.13484.baldrick@free.fr>
Message-ID: <C234B413-FB41-4D7B-A11E-94BD9A6F8C64@aero.org>

Duncan:

DAGCombine is inserting an IllegalOperation after target-specific  
instruction legalization has occurred. I'm inserting the fabs and the  
bitconvert during instruction legalization; DAGCombine is converting  
the fabs/bitconvert to an 'and' on its second (third?) pass.


-scooter

On Jan 20, 2009, at 12:24 AM, Duncan Sands wrote:

> On Tuesday 20 January 2009 07:52:37 Evan Cheng wrote:
>> Right. DAGCombine will insert *illegal* nodes before legalize.
>
> There are two stages of legalization: legalization of types,
> followed by legalization of operations.  Before type legalization
> DAGCombine is allowed to create nodes with illegal types and illegal
> operations.  After type legalization but before operation legalization
> it is allowed to create nodes with illegal operations, but all types
> must be legal.  After operation legalization it is only allowed to
> create fully legal nodes.
>
> Inside DAGCombine this is specified by two flags:
>   LegalTypes being true means that all nodes must have legal types.
>   LegalOperations being true means that all nodes must have legal
> operations (as well as types: LegalTypes will also be true).
>
> So if LegalTypes is true and nonetheless a constant with an
> illegal type is being created then that is a DAG combiner bug.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From evan.cheng at apple.com  Tue Jan 20 11:39:39 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 20 Jan 2009 09:39:39 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <61C79FD4-81CD-426E-B411-87701521D2D5@aero.org>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
	<f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>
	<8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>
	<61C79FD4-81CD-426E-B411-87701521D2D5@aero.org>
Message-ID: <63B567A3-4166-4309-A3BB-67EDE9D82DBC@apple.com>


On Jan 20, 2009, at 8:50 AM, Scott Michel wrote:

> Evan:
>
> And after legalize too. DAGCombine gets run after legalization. :-)

Yes? It nows if it's run after legalization. Like Duncan said, if it's  
inserting illegal nodes after legalization, then it's a bug.

Evan

>
>
>
> -scooter
>
> On Jan 19, 2009, at 10:52 PM, Evan Cheng wrote:
>
>> Right. DAGCombine will insert *illegal* nodes before legalize.
>>
>> Evan
>>
>> On Jan 19, 2009, at 8:17 PM, Eli Friedman wrote:
>>
>>> On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org>
>>> wrote:
>>>> I just ran across something interesting: DAGCombine inserts a 64- 
>>>> bit
>>>> constant as the result of converting a (bitconvert (fabs val)) to a
>>>> (and (bitconvert val), i64const).
>>>>
>>>> The problem: i64 constants have to be legalized for the CellSPU
>>>> platform. DAGCombine is doing the right thing but it's not doing  
>>>> the
>>>> right thing for CellSPU and it's damed difficult to work around  
>>>> this
>>>> "feature". Moreover, the way all of SelectionDAGLegalize and
>>>> DAGCombne's code is written, it's particularly difficult to "re-
>>>> legalize" nodes unless one more legalization pass is invoked after
>>>> DAGCombine.
>>>
>>> I don't think DAGCombine should be doing a transform like that
>>> post-legalize; if it is, it's probably a bug.
>>>
>>> -Eli
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From criswell at cs.uiuc.edu  Tue Jan 20 12:09:13 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Tue, 20 Jan 2009 12:09:13 -0600
Subject: [LLVMdev] value tracking
In-Reply-To: <893084CE27BF4EA39A2A894E55BF1B73@pc07654>
References: <893084CE27BF4EA39A2A894E55BF1B73@pc07654>
Message-ID: <49761349.5000807@cs.uiuc.edu>

Nuno Lopes wrote:
> Hi,
>
> I've been thinking about a (potentially lazy) value tracking analysis that 
> could be reused by several optimization passes. I don't know if it exists in 
> llvm or not, but to my better knowledge it does not. ok there exists the 
> ValueTracking class, but it does not provide a function like e.g. 
> MayHaveTheValue(Value* v, APSInt x) to check if a given var v may ever have 
> the value x
>
> My proposal:
>  - create a value tracking analysis interface that can provide extensive 
> info about vars (e.g. the set of possible values for a given vars, etc..)
>  - implement that interface in several ways with different tradeoffs of 
> preciseness vs speed (e.g. range analysis, value set tracking, path 
> sensitive or not, interprocedural, etc..)
>   

I think the analysis group idea is a good idea.  A standardized
interface for querying this sort of information makes code reuse between
LLVM developers doing different projects easier.

As an example of another transform which requires such information, in
the memory safety work that we do, we have transforms that could benefit
from knowing the range of values that an integer value can take
(specifically, we're usually interested in the min and max values a GEP
index can have).  Having a standardized interface would allow us to
re-use analysis passes developed by other LLVM contributors for other
applications, and if we develop a pass that computes such information
more aggressively, it makes it easier for us to write that code in a way
that is usable by the LLVM community at large.

-- John T.

> I believe this could reuse some code from PredSimplify and hopefully make it 
> a very simple pass (as much of the work would then be hidden in the value 
> tracking analysis).
> Having this sort of readily available analysis would allow us to build other 
> optimization more easily. I've already a few ideas in mind (I've implemented 
> one of them, but I had to unnecessarily implement too much of this value 
> tracking logic).
>
> Any ideas, opinions, etc..?
>
> Regards,
> Nuno 
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From baldrick at free.fr  Tue Jan 20 12:11:41 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Jan 2009 19:11:41 +0100
Subject: [LLVMdev] linux build problem
In-Reply-To: <38a0d8450901200549p44d83e02v22cf3b4503005a51@mail.gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<0DF271BD-B19B-4E8C-9F41-7BB149CAE2D5@gmail.com>
	<38a0d8450901200549p44d83e02v22cf3b4503005a51@mail.gmail.com>
Message-ID: <200901201911.41780.baldrick@free.fr>

> Fixes the build on linux.

I can confirm that this fixes the build on
x86-64 linux.

Ciao,

Duncan.

From clattner at apple.com  Tue Jan 20 12:23:55 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Jan 2009 10:23:55 -0800
Subject: [LLVMdev] cygwin build patch
In-Reply-To: <ee2e06e90901200122y5257d042g91aecec43019d287@mail.gmail.com>
References: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>
	<5CE7EB46-16C0-42FC-9A12-13328B7053AD@apple.com>
	<ee2e06e90901200122y5257d042g91aecec43019d287@mail.gmail.com>
Message-ID: <DA7138AB-2671-4582-918A-A4D67F19E24D@apple.com>


On Jan 20, 2009, at 1:22 AM, Jay Foad wrote:

>>> I realise that the DataTypes.h.in part might be controversial. Also,
>>> there's probably a better place to put it, but I'm not sure where.
>>
>> I didn't apply this part.  What problems does it cause to not have
>> this?  Can we fix uses of max and min?
>
> I could try to fix this by changing the code to consistently use
> either unsigned or uint32_t (which?), rather than both. Or by adding
> casts at the point of calling min/max. What would you prefer?

I'd prefer to avoid uint32_t.  I committed a couple patches, can you  
try again and let me know if you see any other failures?

-Chris

From clattner at apple.com  Tue Jan 20 12:25:22 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Jan 2009 10:25:22 -0800
Subject: [LLVMdev] [PATCH] correct argument order of gv when viewgraph
	is	called
In-Reply-To: <alpine.LRH.1.10.0901201042000.20397@pub4.ifh.de>
References: <alpine.LRH.1.10.0901201042000.20397@pub4.ifh.de>
Message-ID: <282FDE4C-1AA4-435E-BF29-54230E1D8CEB@apple.com>


On Jan 20, 2009, at 1:44 AM, Patrick Boettcher wrote:

> Hi list,
>
> On my system I have gv 3.5.8 and it does not like to be called with  
> --spartan before the <filename>.
>
> The man-page is stating that the file name has to come before all  
> arguments and the --spartan is actually -spartan. I don't know for  
> newer versions of gv.

Applied, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090119/072408.html

-Chris

From tonic at nondot.org  Tue Jan 20 13:44:03 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Tue, 20 Jan 2009 11:44:03 -0800 (PST)
Subject: [LLVMdev] 2.5 Code Freeze Tomorrow!
Message-ID: <Pine.LNX.4.62.0901201141540.15150@nondot.org>


This is just a reminder that the 2.5 code freeze is tomorrow at 9PM PST. 
Please try to keep the tree stable :)

-Tanya

From dpatel at apple.com  Tue Jan 20 12:34:52 2009
From: dpatel at apple.com (Devang Patel)
Date: Tue, 20 Jan 2009 10:34:52 -0800
Subject: [LLVMdev] if-conversion
In-Reply-To: <4975A771.7050701@gmx.de>
References: <4975A771.7050701@gmx.de>
Message-ID: <D81B6A56-643A-43C3-BC98-0E92BD8D1E09@apple.com>


On Jan 20, 2009, at 2:29 AM, Ralf Karrenberg wrote:

> Hello everyone,
>
> I'd like to know if there is an optimization in llvm doing something
> like an if-conversion on the IR. I only found IfConversion.cpp which
> appears to only provide the desired functionality on machine code  
> during
> code-generation.
>
> I want to transform branches into serial code with select-instructions
> as a pre-processing step for further transformations.
>
> If there is no such pass, I will possibly write one and share it
> (although I have no idea how to do so yet), so please let me know :).

There is not any pass that can transform branches into serial code  
with select-instructions. Simplify CFG can handle simple cases of  
selecting one value based on a condition, but its goal is to simplify  
cfg. This may not be enough for your needs.

If you write a separate pass, we'd like to integrate it in mainline  
llvm sources.

-
Devang




From wendling at apple.com  Tue Jan 20 12:48:55 2009
From: wendling at apple.com (Bill Wendling)
Date: Tue, 20 Jan 2009 10:48:55 -0800
Subject: [LLVMdev] linux build problem
In-Reply-To: <200901201911.41780.baldrick@free.fr>
References: <49752A15.3010305@cs.utah.edu>
	<0DF271BD-B19B-4E8C-9F41-7BB149CAE2D5@gmail.com>
	<38a0d8450901200549p44d83e02v22cf3b4503005a51@mail.gmail.com>
	<200901201911.41780.baldrick@free.fr>
Message-ID: <E6CA9C72-A09E-46AA-AC42-C03C3F64C04C@apple.com>

On Jan 20, 2009, at 10:11 AM, Duncan Sands wrote:

>> Fixes the build on linux.
>
> I can confirm that this fixes the build on
> x86-64 linux.
>
I went ahead and applied this patch. Thanks, Rafael!

-bw


From isanbard at gmail.com  Tue Jan 20 13:10:29 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 20 Jan 2009 11:10:29 -0800
Subject: [LLVMdev] linux build problem
In-Reply-To: <38a0d8450901200844lbc20612n5675083bba964060@mail.gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
	<alpine.DEB.1.00.0901200933260.4381@babel.cs.utah.edu>
	<38a0d8450901200844lbc20612n5675083bba964060@mail.gmail.com>
Message-ID: <16e5fdf90901201110i3cfeb74dtb41c70f3337ae4cc@mail.gmail.com>

On Tue, Jan 20, 2009 at 8:44 AM, Rafael Espindola <espindola at google.com> wrote:
> 2009/1/20 John Regehr <regehr at cs.utah.edu>:
>> I'm away from my Linux machines, if this hasn't been resolved by tonight
>> I'll send more details.
>>
>> THe problem in cplus-dem.c is that CPP is conditionally including code that
>> comes when HAVE_STDLIB is not defined, including an alternate protptype for
>> malloc() that conflicts with the existing one.  This is just what causes the
>> error I sent-- no idea what the root cause is.
>
> I have posted a patch that fixes it for me. Waiting for someone to
> test it on Darwin.
>
I do have a concern that this might have regressed the Fortran FE.
Could you (or someone who runs it) test this?

-bw

From mrs at apple.com  Tue Jan 20 13:45:18 2009
From: mrs at apple.com (Mike Stump)
Date: Tue, 20 Jan 2009 11:45:18 -0800
Subject: [LLVMdev] new warning
Message-ID: <93D92FFF-9578-4CB7-A0A1-5A51A0EF8906@apple.com>

lib/CodeGen/PreAllocSplitting.cpp: In member function  
?bool<unnamed>::PreAllocSplitting::SplitRegLiveInterval 
(llvm::LiveInterval*)?:
lib/CodeGen/PreAllocSplitting.cpp:1230: warning: ?RestoreIndex? may be  
used uninitialized in this function

From jay.foad at gmail.com  Tue Jan 20 14:28:37 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Tue, 20 Jan 2009 20:28:37 +0000
Subject: [LLVMdev] cygwin build patch
In-Reply-To: <DA7138AB-2671-4582-918A-A4D67F19E24D@apple.com>
References: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>
	<5CE7EB46-16C0-42FC-9A12-13328B7053AD@apple.com>
	<ee2e06e90901200122y5257d042g91aecec43019d287@mail.gmail.com>
	<DA7138AB-2671-4582-918A-A4D67F19E24D@apple.com>
Message-ID: <ee2e06e90901201228j5fc10859kfd3a53b9529b8c7d@mail.gmail.com>

> I'd prefer to avoid uint32_t.  I committed a couple patches, can you
> try again and let me know if you see any other failures?

lib/Support/APInt.cpp:45: error: prototype for 'void
llvm::APInt::initSlowCase(uint32_t, uint64_t, bool)' does not match
any in class 'llvm::APInt'
lib/Support/APInt.cpp:59: error: prototype for
'llvm::APInt::APInt(uint32_t, uint32_t, const uint64_t*)' does not
match any in class 'llvm::APInt'
lib/Support/APInt.cpp:78: error: prototype for
'llvm::APInt::APInt(uint32_t, const char*, uint32_t, uint8_t)' does
not match any in class 'llvm::APInt'
lib/Support/APInt.cpp:458: error: prototype for 'bool
llvm::APInt::operator[](uint32_t) const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:559: error: prototype for 'llvm::APInt&
llvm::APInt::set(uint32_t)' does not match any in class 'llvm::APInt'
lib/Support/APInt.cpp:569: error: prototype for 'llvm::APInt&
llvm::APInt::clear(uint32_t)' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:582: error: prototype for 'llvm::APInt&
llvm::APInt::flip(uint32_t)' does not match any in class 'llvm::APInt'
lib/Support/APInt.cpp:589: error: prototype for 'uint32_t
llvm::APInt::getBitsNeeded(const char*, uint32_t, uint8_t)' does not
match any in class 'llvm::APInt'
lib/Support/APInt.cpp:640: error: prototype for 'llvm::APInt
llvm::APInt::getHiBits(uint32_t) const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:645: error: prototype for 'llvm::APInt
llvm::APInt::getLoBits(uint32_t) const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:654: error: prototype for 'uint32_t
llvm::APInt::countLeadingZerosSlowCase() const' does not match any in
class 'llvm::APInt'
lib/Support/APInt.cpp:681: error: prototype for 'uint32_t
llvm::APInt::countLeadingOnes() const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:702: error: prototype for 'uint32_t
llvm::APInt::countTrailingZeros() const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:714: error: prototype for 'uint32_t
llvm::APInt::countTrailingOnesSlowCase() const' does not match any in
class 'llvm::APInt'
lib/Support/APInt.cpp:724: error: prototype for 'uint32_t
llvm::APInt::countPopulationSlowCase() const' does not match any in
class 'llvm::APInt'
lib/Support/APInt.cpp:768: error: 'llvm::APInt
llvm::APIntOps::RoundDoubleToAPInt(double, uint32_t)' should have been
declared inside 'llvm::APIntOps'
lib/Support/APInt.cpp:871: error: prototype for 'llvm::APInt&
llvm::APInt::trunc(uint32_t)' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:894: error: prototype for 'llvm::APInt&
llvm::APInt::sext(uint32_t)' does not match any in class 'llvm::APInt'
lib/Support/APInt.cpp:941: error: prototype for 'llvm::APInt&
llvm::APInt::zext(uint32_t)' does not match any in class 'llvm::APInt'
lib/Support/APInt.cpp:960: error: prototype for 'llvm::APInt&
llvm::APInt::zextOrTrunc(uint32_t)' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:968: error: prototype for 'llvm::APInt&
llvm::APInt::sextOrTrunc(uint32_t)' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:984: error: prototype for 'llvm::APInt
llvm::APInt::ashr(uint32_t) const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:1073: error: prototype for 'llvm::APInt
llvm::APInt::lshr(uint32_t) const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:1140: error: prototype for 'llvm::APInt
llvm::APInt::shlSlowCase(uint32_t) const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:1194: error: prototype for 'llvm::APInt
llvm::APInt::rotl(uint32_t) const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:1209: error: prototype for 'llvm::APInt
llvm::APInt::rotr(uint32_t) const' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:1539: error: prototype for 'void
llvm::APInt::divide(llvm::APInt, uint32_t, const llvm::APInt&,
uint32_t, llvm::APInt*, llvm::APInt*)' does not match any in class
'llvm::APInt'
lib/Support/APInt.cpp:1828: error: prototype for 'void
llvm::APInt::fromString(uint32_t, const char*, uint32_t, uint8_t)'
does not match any in class 'llvm::APInt'
lib/Support/APInt.cpp:670: warning: 'uint32_t
countLeadingOnes_64(uint64_t, uint32_t)' defined but not used
lib/Support/APInt.cpp:1359: warning: 'void KnuthDiv(uint32_t*,
uint32_t*, uint32_t*, uint32_t*, uint32_t, uint32_t)' defined but not
used

:(

I can have a go at fixing this - it's probably gonna be hard to do it blind.

Thanks,
Jay.

From Chareos at gmx.de  Tue Jan 20 14:28:31 2009
From: Chareos at gmx.de (Ralf Karrenberg)
Date: Tue, 20 Jan 2009 21:28:31 +0100
Subject: [LLVMdev] if-conversion
In-Reply-To: <D81B6A56-643A-43C3-BC98-0E92BD8D1E09@apple.com>
References: <4975A771.7050701@gmx.de>
	<D81B6A56-643A-43C3-BC98-0E92BD8D1E09@apple.com>
Message-ID: <0AC90A4F48F14700B5B7E39701B2013A@Decado>

> If you write a separate pass, we'd like to integrate it in mainline
> llvm sources.

Thank you for your answers. I will do my best to develop something which 
could be useful for more people :).

Cheers,
Ralf 


From scottm at aero.org  Tue Jan 20 14:32:29 2009
From: scottm at aero.org (Scott Michel)
Date: Tue, 20 Jan 2009 12:32:29 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <f5aa3e9b0901200123k61d8c438hcf902868063c10b7@mail.gmail.com>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
	<f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>
	<8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>
	<200901200924.13484.baldrick@free.fr>
	<f5aa3e9b0901200123k61d8c438hcf902868063c10b7@mail.gmail.com>
Message-ID: <FD542597-8B7F-4DCA-9042-9DBEF25EA000@aero.org>

Eli:

Legal constants would be all well and good for most platforms. I  
don't think that CellSPU is alone in its support for i64 constants  
(in fact, the comment in DAGCombine says that the 64-bit constant is  
inserted to "avoid a constant pool spill").

In many respects, DAGCombine and operation Legalize are co-routines,  
not separate passes.


-scooter

On Jan 20, 2009, at 1:23 AM, Eli Friedman wrote:

> On Tue, Jan 20, 2009 at 12:24 AM, Duncan Sands <baldrick at free.fr>  
> wrote:
>> So if LegalTypes is true and nonetheless a constant with an
>> illegal type is being created then that is a DAG combiner bug.
>
> The issue here isn't that i64 is illegal, it's that constants of type
> i64 are illegal.  I'm tempted to say that having legal constants
> should be a requirement for marking an integer type legal...
>
> -Eli
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From gohman at apple.com  Tue Jan 20 14:46:11 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 20 Jan 2009 12:46:11 -0800
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <E04CD967-3A9A-450C-88BC-96FB13EF7B36@aero.org>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<4E71A380-CB54-415F-822C-3285FEB44221@apple.com>
	<alpine.LRH.1.10.0901191952420.20397@pub4.ifh.de>
	<85181497-D132-446B-A5AA-A19840D5F7E0@apple.com>
	<E04CD967-3A9A-450C-88BC-96FB13EF7B36@aero.org>
Message-ID: <3EF51A29-FBCF-44BD-8451-9E9FC3474B1B@apple.com>


On Jan 19, 2009, at 6:39 PM, Scott Michel wrote:

> Dan:
>
> CellSPU could clearly benefit from the post-RA scheduler. In fact, we
> were thinking about writing a machine pass of our own.
>
> One thing that does "disturb" me is that both HazardRecognizer and
> post-RA sched assume there's only one kind of NOP. For Cell, there
> are two, depending upon the pipeline being filled. Pipe 0 takes
> "ENOP" whereas Pipe 1 take "LNOP" (depends on the low order PC bits.)

I'm open to suggestions and patches for making the HazardRecognizer
interface more flexible. It may also be worthwhile to look at
whether the TargetInstrInfo::insertNoop hook could be extended to
be able to meet this need.

One potential problem to watch out for is that the post-RA scheduler
currently runs before BranchFolding, which may disturb things if
you're depending on lining up the code with even/odd PC addresses.
I would prefer to run the scheduler after BranchFolding, but
BranchFolding doesn't currently preserve liveness information on
which the scheduler currently depends.

Dan


From criswell at cs.uiuc.edu  Tue Jan 20 14:51:07 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Tue, 20 Jan 2009 14:51:07 -0600
Subject: [LLVMdev] if-conversion
In-Reply-To: <0AC90A4F48F14700B5B7E39701B2013A@Decado>
References: <4975A771.7050701@gmx.de>	<D81B6A56-643A-43C3-BC98-0E92BD8D1E09@apple.com>
	<0AC90A4F48F14700B5B7E39701B2013A@Decado>
Message-ID: <4976393B.5050302@cs.uiuc.edu>

Ralf Karrenberg wrote:
>> If you write a separate pass, we'd like to integrate it in mainline
>> llvm sources.
>>     
>
> Thank you for your answers. I will do my best to develop something which 
> could be useful for more people :).
>   
If you're looking for sources on how to do if-conversion, there's an
algorithm for it in the book "Optimizing Compilers for Modern
Architectures," Chapter 7.  That algorithm, in turn, relies upon
computing control dependence.  There's an algorithm for computing that
in the same chapter, and there's another algorithm for control
dependence in the following paper:

http://portal.acm.org/citation.cfm?id=115372.115320&coll=portal&dl=ACM&CFID=18980569&CFTOKEN=50678055

My recommendation is to write two passes: one that computes control
dependence and another that performs if-conversion.  A
control-dependence analysis pass is useful for other analysis and
transform passes.

-- John T.

> Cheers,
> Ralf 
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From tim.foley.is at gmail.com  Tue Jan 20 15:41:04 2009
From: tim.foley.is at gmail.com (Tim Foley)
Date: Tue, 20 Jan 2009 13:41:04 -0800
Subject: [LLVMdev] Interactions between LLVM and the Microsoft C++ runtime
Message-ID: <fdec3f880901201341n33c82a05seb64fdc8724a90cd@mail.gmail.com>

Hello! I am trying to use LLVM 2.4 in a project built with MS Visual Studio
2008. I've been building LLVM with the llvm/win32/llvm.sln solution
successfully for x86 and x64. I haven't yet tried to move to the CMake build
process, so I'd be interested to hear if the following issues have been
resolved on that path.

The problem that I've run into is that the LLVM codebase does certain
"idiomatic" things with STL containers that cause assertion failures in the
Microsoft runtime. Most notably:
- Taking the address of the "first element" of an emtpy vector (either &v[0]
or &*v.begin())
- Using an iterator into a collection (even if just for iterator comparison)
after an erase() or similar on that collection has invalidated all iterators
These assertions can occur in both debug and release configurations
(Microsoft includes certain assertions in the release runtime for
"security").

I do *not* want to start a flamewar on the subject of who is right in this
conflict. The Microsoft STL simply assert-fails on things that are
officially undefined in the spec for the STL (as a matter of policy), and
LLVM just relies on certain pieces of undefined behavior that are typically
benign in most implementations.

I'd be interested to hear if other LLVM users have seen these problems or if
any have solutions to propose. I have a few possible solutions in mind, but
will refrain from going into any of them until I've heard from the
community.

- Tim Foley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090120/c797ebe1/attachment.html 

From dag at cray.com  Tue Jan 20 16:22:12 2009
From: dag at cray.com (David Greene)
Date: Tue, 20 Jan 2009 16:22:12 -0600
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <FA3EBC4E-5976-4677-8CC0-55AD2D625E1F@apple.com>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<200901191906.06656.dag@cray.com>
	<FA3EBC4E-5976-4677-8CC0-55AD2D625E1F@apple.com>
Message-ID: <200901201622.12875.dag@cray.com>

On Monday 19 January 2009 19:47, Dan Gohman wrote:

> >  Can they be used in conjunction with
> > MemoryDependenceAnalysis?  e.g. can we write a MachineInstructions-
> > based
> > memory dependence analysis that uses MachineMemoryOperands?
>
> Right, the existing MemoryDependenceAnalysis works in terms of
> LLVM-IR-level Instructions, but yes, it would be possible to
> implement the same thing for MachineInstrs, using AliasAnalysis
> queries from MachineMemOperands. As of this writing I'm not
> prepared to guess whether this would be a good idea :-).

Sure.  It seems fairly straightforward though.  Heck, it might even be 
possible to take MemoryDependenceAnalysis and turn it into generic code that 
could operate on Instructions or MachineMemOperands.

> >> This would probably also involve AliasAnalysis  queries from codegen,
> >> possibly going though the   MemoryDependenceAnalysis interface.
> >
> > Do you have a vision for how this might work?  Wouldn't we need a new
> > MachineFunctionPass to essentially do the same thing as
> > MemoryDependenceAnalysis?
>
> A possible vision is that SelectionDAGBuild could use
> MemoryDependenceAnalysis when building the initial SelectionDAG.
> It's walking the IR-level Instructions, so it can use any
> IR-level analysis. I haven't yet looked into this in detail.
> A significant question is whether non-local dependencies are
> important; some day we may extend SelectionDAGs to handle
> more than one block at a time.

I should think non-local dependencies would be important.  We have a number of 
machine code passes that work globally.

> > I don't think it's sufficient to just preserve the information we
> > had from
> > Instructions.  Codegen might introduce new memory operations after
> > lowering
> > (spilling, for example).  Some of these might be easily analyzable
> > (spills)
> > but others might not be.
>
> This is where PseudoSourceValues come in. There are pseudo-values
> representing the stack, constants area, GOT, and other memory
> locations that aren't represented at the LLVM-IR level.

Ok, that's good.  But what happens if some codegen pass deletes a memory 
instruction (or a Value or whatever) and recreates it elsewhere.  Presumably 
the dependence information would be lost.  How would we re-generate it.

> I think the biggest challenge here is finding a design that
> is reasonably efficient in terms of compile time and space while
> still providing useful information.

Isn't that the definition of compiler development?  :)

                                       -Dave

From clattner at apple.com  Tue Jan 20 16:22:30 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Jan 2009 14:22:30 -0800
Subject: [LLVMdev] Shouldn't DAGCombine insert legal nodes?
In-Reply-To: <FD542597-8B7F-4DCA-9042-9DBEF25EA000@aero.org>
References: <F27E7795-2B3A-4CDB-BBCC-0BA4161FC299@aero.org>
	<f5aa3e9b0901192017h757633c9ne1c146466c25bdf3@mail.gmail.com>
	<8F2233FC-B6A3-4DE8-83A9-64602C5F210A@apple.com>
	<200901200924.13484.baldrick@free.fr>
	<f5aa3e9b0901200123k61d8c438hcf902868063c10b7@mail.gmail.com>
	<FD542597-8B7F-4DCA-9042-9DBEF25EA000@aero.org>
Message-ID: <CCAD7CF1-F0FC-4AFB-8CEA-5E5A3FB328CD@apple.com>


On Jan 20, 2009, at 12:32 PM, Scott Michel wrote:

> Eli:
>
> Legal constants would be all well and good for most platforms. I
> don't think that CellSPU is alone in its support for i64 constants
> (in fact, the comment in DAGCombine says that the 64-bit constant is
> inserted to "avoid a constant pool spill").
>
> In many respects, DAGCombine and operation Legalize are co-routines,
> not separate passes.

i32 immediates are not materializable in a single instruction on  
PowerPC or ARM.  They claims that they are legal and then matches them  
with the appropriate expansion.  Can you do a similar thing on Cell?

In any case, the bug fix is probably really simple: the dag combine  
xform for fabs probably just needs to check to see if ISD::CONSTANT is  
legal if post-legalize

-chris

From dag at cray.com  Tue Jan 20 16:25:24 2009
From: dag at cray.com (David Greene)
Date: Tue, 20 Jan 2009 16:25:24 -0600
Subject: [LLVMdev] value tracking
In-Reply-To: <49761349.5000807@cs.uiuc.edu>
References: <893084CE27BF4EA39A2A894E55BF1B73@pc07654>
	<49761349.5000807@cs.uiuc.edu>
Message-ID: <200901201625.25091.dag@cray.com>

On Tuesday 20 January 2009 12:09, John Criswell wrote:

> > My proposal:
> >  - create a value tracking analysis interface that can provide extensive
> > info about vars (e.g. the set of possible values for a given vars, etc..)
> >  - implement that interface in several ways with different tradeoffs of
> > preciseness vs speed (e.g. range analysis, value set tracking, path
> > sensitive or not, interprocedural, etc..)
>
> I think the analysis group idea is a good idea.  A standardized
> interface for querying this sort of information makes code reuse between
> LLVM developers doing different projects easier.
>
> As an example of another transform which requires such information, in
> the memory safety work that we do, we have transforms that could benefit
> from knowing the range of values that an integer value can take
> (specifically, we're usually interested in the min and max values a GEP
> index can have).  Having a standardized interface would allow us to
> re-use analysis passes developed by other LLVM contributors for other
> applications, and if we develop a pass that computes such information
> more aggressively, it makes it easier for us to write that code in a way
> that is usable by the LLVM community at large.

I  agree with this approach.  Just yesterday I ran into a situation where I 
really wanted value range information.  I really like the AliasAnalysis design 
where cheaper analyses try to give an answer before querying more expensive 
analyses.  This would fit in well with Nuno's plan to provide analyses with 
different time/completeness tradeoffs.

                                            -Dave

From clattner at apple.com  Tue Jan 20 16:27:25 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Jan 2009 14:27:25 -0800
Subject: [LLVMdev] Supported JIT targets
In-Reply-To: <4975D81C.10007@cern.ch>
References: <4975D81C.10007@cern.ch>
Message-ID: <9645B8D6-9993-46D3-852C-34655AEE57F4@apple.com>


On Jan 20, 2009, at 5:56 AM, Axel Naumann wrote:

> Hi,
>
> I've been trying to find a list of the current JIT-supported  
> targets. Not easy
> :-) The sources seem to say that the architectures are X86, PowerPC,  
> ARM,
> Alpha. And then their obvious combination with Linux, FreeBSD /  
> MacOSX, Win32 -
> is that it?

X86-64 and PPC64 also.  I don't know how stable the Alpha JIT is.

-Chris

From alenhar2 at uiuc.edu  Tue Jan 20 16:30:26 2009
From: alenhar2 at uiuc.edu (Andrew Lenharth)
Date: Tue, 20 Jan 2009 16:30:26 -0600
Subject: [LLVMdev] Supported JIT targets
In-Reply-To: <9645B8D6-9993-46D3-852C-34655AEE57F4@apple.com>
References: <4975D81C.10007@cern.ch>
	<9645B8D6-9993-46D3-852C-34655AEE57F4@apple.com>
Message-ID: <85dfcd7f0901201430g59ab64f7wb92073dbec6dd07f@mail.gmail.com>

On Tue, Jan 20, 2009 at 4:27 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Jan 20, 2009, at 5:56 AM, Axel Naumann wrote:
>
>> Hi,
>>
>> I've been trying to find a list of the current JIT-supported
>> targets. Not easy
>> :-) The sources seem to say that the architectures are X86, PowerPC,
>> ARM,
>> Alpha. And then their obvious combination with Linux, FreeBSD /
>> MacOSX, Win32 -
>> is that it?
>
> X86-64 and PPC64 also.  I don't know how stable the Alpha JIT is.

It can add numbers.  There is an assertion in some of the offset
calculating code so most stuff doesn't run.

Andrew

From clattner at apple.com  Tue Jan 20 16:38:18 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Jan 2009 14:38:18 -0800
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
In-Reply-To: <4975A318.2040208@redhat.com>
References: <4974A258.1040108@redhat.com>
	<99AFFD84-D5A8-4094-8FB9-DDAD8E2AE20E@apple.com>
	<4975A318.2040208@redhat.com>
Message-ID: <C9CEA12F-BC24-4995-89AF-80B9517AC0D2@apple.com>


On Jan 20, 2009, at 2:10 AM, Andrew Haley wrote:

> Chris Lattner wrote:
>> On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote:
>>
>>> This is x86_64.  I have a problem where an absolute memory load
>>> The current LLVM trunk does not have this bug.  This seems quite a
>>> nasty
>>> bug; is there any chance of a bug-fix release for LLVM 2.4, or
>>> should I
>>> just use LLVM trunk until LLVM 2.5 ?
>>
>> As others have pointed out, using a global and addglobalmapping is a
>> great workaround for the problem.
>
> Thanks.
>
>> We generally don't do "dot" releases, since we have a short release
>> cycle anyway.  The 2.5 release process is slated to start this week.
>
> Mmm, but the problem is that interfaces keep changing, so simply
> upgrading to the latest release isn't possible.  Even the tiny
> test case I posted doesn't work with the latest version: there
> were changes needed to get it to compile.  Also, I can no longer
> figure out how to turn on debugging dumps in the JIT.  The simple
>
>   DebugFlag = true;
>   CurrentDebugType = "x86-emitter";
>
> no longer works, and there seems to be no replacement for it.

That should work fine, just use "jit" instead of "x86-emitter" as the  
debug type.

-Chris

From rhamph at gmail.com  Tue Jan 20 17:12:33 2009
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 20 Jan 2009 16:12:33 -0700
Subject: [LLVMdev] value tracking
In-Reply-To: <893084CE27BF4EA39A2A894E55BF1B73@pc07654>
References: <893084CE27BF4EA39A2A894E55BF1B73@pc07654>
Message-ID: <aac2c7cb0901201512w3c029ae5gbeb43fac646a6b33@mail.gmail.com>

On Mon, Jan 19, 2009 at 4:54 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote:
> Hi,
>
> I've been thinking about a (potentially lazy) value tracking analysis that
> could be reused by several optimization passes. I don't know if it exists in
> llvm or not, but to my better knowledge it does not. ok there exists the
> ValueTracking class, but it does not provide a function like e.g.
> MayHaveTheValue(Value* v, APSInt x) to check if a given var v may ever have
> the value x
>
> My proposal:
>  - create a value tracking analysis interface that can provide extensive
> info about vars (e.g. the set of possible values for a given vars, etc..)
>  - implement that interface in several ways with different tradeoffs of
> preciseness vs speed (e.g. range analysis, value set tracking, path
> sensitive or not, interprocedural, etc..)
>
> I believe this could reuse some code from PredSimplify and hopefully make it
> a very simple pass (as much of the work would then be hidden in the value
> tracking analysis).
> Having this sort of readily available analysis would allow us to build other
> optimization more easily. I've already a few ideas in mind (I've implemented
> one of them, but I had to unnecessarily implement too much of this value
> tracking logic).
>
> Any ideas, opinions, etc..?

I'm experimenting with doing value tracking of Python code.  I likely
have to go a lot further than you do:

* variables don't have a type, so I treat the type as just another
value to track
* integers have no limit, so I break them down into many different
ranges and let it step up through them
* classes and methods are just more variables to track
* all variables start out undefined, so I need DSA (dynamic single
assignment) to eliminate that
* DSA at the global scope is likely to scale very badly, so I'll be
playing with various alternatives

Those familiar with Python will know there's various sources of
unbounded dynamism, such as exec().  To control that I'm adding a sort
of privates, except everybody in your own "compartment" is your
friend.  A compartment is a collection of code compiled as a single
unit, and usually (other than an interactive interpreter) is closed to
adding new code; you can create a new compartment to load a plugin
though.


-- 
Adam Olsen, aka Rhamphoryncus

From Sanjiv.Gupta at microchip.com  Tue Jan 20 21:36:50 2009
From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com)
Date: Tue, 20 Jan 2009 20:36:50 -0700
Subject: [LLVMdev] PIC16 backend for llvm 2.5
References: <F536B7C316F9474E9F7091239725AC9A4E9009@CHN-CL-MAIL01.mchp-main.com><200901161003.35470.baldrick@free.fr><1232304223.3019.4.camel@idc-lt-i00171.microchip.com><200901182028.15320.baldrick@free.fr>
	<1232389315.4265.4.camel@idc-lt-i00171.microchip.com>
Message-ID: <F536B7C316F9474E9F7091239725AC9A4E9025@CHN-CL-MAIL01.mchp-main.com>

Duncan,
We have code freeze approaching. Should I check-in this revised patch?
I ran make check and it passes.

- Sanjiv


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu on behalf of sanjiv gupta
Sent: Mon 1/19/2009 11:51 PM
To: Duncan Sands
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] PIC16 backend for llvm 2.5
 
On Sun, 2009-01-18 at 20:28 +0100, Duncan Sands wrote:
> Hi Sanjiv,
> 
> > +  /// CustomLowerOperation - This callback is invoked for operations that are
> > +  /// unsupported by the target, which are registered to use 'custom' lowering,
> > +  /// and whose defined values are all legal.
> 
> and whose defined values are all legal -> and whose return values all have legal types
> 
Taken care of.

> > +  /// If the target has no operations that require custom lowering, it need not
> > +  /// implement this.
> 
> This comment and the name seem too generic for me.  This method is for use when
> an operand has an illegal type, right?  Yet the comment makes no mention of this.
> There's also of no mention of the fact that you are allowed to not place anything
> in Results, and what that means.
> 
Taken care of.

> Also, is there any reason not to use ReplaceNodeResults rather than introducing
> a new method for type legalization?
> 
ReplaceNodeResults and LowerOperation have been used for different
purposes by different targets, and have been implemented differently.
The former is meant to legalize illegal value types and the latter is
meant to legalize operations with illegal operands. So they might need
different treatments.

> > +    case ISD::ANY_EXTEND:   
> > +      Results.push_back(PromoteIntOp_ANY_EXTEND(N)); break;
> 
> This is wrong if PromoteIntOp_ANY_EXTEND returned a value with
> no node.  Likewise for all the others.  Better I think to simply
> handle the custom case immediately and return rather than trying
> to share code with these other cases.
> 
Taken care of.

> Also, you could just make DAGTypeLegalizer::CustomLowerResults
> more general, and use that.
> 
Taken care of.

The revised patch is attached.

> Ciao,
> 
> Duncan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090120/26dd8d91/attachment.html 

From clattner at apple.com  Wed Jan 21 00:20:41 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Jan 2009 22:20:41 -0800
Subject: [LLVMdev] Interactions between LLVM and the Microsoft C++
	runtime
In-Reply-To: <fdec3f880901201341n33c82a05seb64fdc8724a90cd@mail.gmail.com>
References: <fdec3f880901201341n33c82a05seb64fdc8724a90cd@mail.gmail.com>
Message-ID: <508AEC31-3996-49A5-A4FC-E7683CE57930@apple.com>


On Jan 20, 2009, at 1:41 PM, Tim Foley wrote:

> Hello! I am trying to use LLVM 2.4 in a project built with MS Visual  
> Studio 2008. I've been building LLVM with the llvm/win32/llvm.sln  
> solution successfully for x86 and x64. I haven't yet tried to move  
> to the CMake build process, so I'd be interested to hear if the  
> following issues have been resolved on that path.
>
> The problem that I've run into is that the LLVM codebase does  
> certain "idiomatic" things with STL containers that cause assertion  
> failures in the Microsoft runtime. Most notably:
> - Taking the address of the "first element" of an emtpy vector  
> (either &v[0] or &*v.begin())
> - Using an iterator into a collection (even if just for iterator  
> comparison) after an erase() or similar on that collection has  
> invalidated all iterators
> These assertions can occur in both debug and release configurations  
> (Microsoft includes certain assertions in the release runtime for  
> "security").
>
> I do *not* want to start a flamewar on the subject of who is right  
> in this conflict. The Microsoft STL simply assert-fails on things  
> that are officially undefined in the spec for the STL (as a matter  
> of policy), and LLVM just relies on certain pieces of undefined  
> behavior that are typically benign in most implementations.
>
> I'd be interested to hear if other LLVM users have seen these  
> problems or if any have solutions to propose. I have a few possible  
> solutions in mind, but will refrain from going into any of them  
> until I've heard from the community.

hi Tim,

No flame war: llvm should not make non-portable assumptions about the  
STL and windows support is very important for us.  Fortunately, I  
believe all of these issues are fixed on mainline.  The LLVM 2.5  
release branch will be made very soon now, I'd appreciate it if you  
could test mainline and let us know if you hit any problems.

-Chris

From clattner at apple.com  Wed Jan 21 00:24:51 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Jan 2009 22:24:51 -0800
Subject: [LLVMdev] avoid creating .dir files
In-Reply-To: <8A51D4F0-05E3-44DD-9620-27DE614D0D37@apple.com>
References: <3B14683F-547E-49E9-8DFE-BB35FED0D124@apple.com>
	<50140231-8562-4610-A269-449C87B718DB@apple.com>
	<8A51D4F0-05E3-44DD-9620-27DE614D0D37@apple.com>
Message-ID: <AF8DC46D-8579-4F4F-86A5-C2824E57E9B4@apple.com>


On Jan 19, 2009, at 3:04 PM, Mike Stump wrote:

> On Jan 19, 2009, at 1:58 PM, Chris Lattner wrote:
>> On Jan 19, 2009, at 10:02 AM, Mike Stump wrote:
>>
>>> There isn't a good reason to create files called .dir in the
>>> installation directory.  This patch fixes that.
>>
>> If we don't have this line, every build with do the makedir.
>
> And?
>
> $ time mkdir -p /bin
>
> real	0m0.002s
> user	0m0.000s
> sys	0m0.002s

Ok! You win, :)

-Chris

>
>
> an extra mkdir takes around 2ms per build.  An up-to-date inc build
> takes 2231ms for me.  If you want some of the extra 2231ms back, I'd
> recommend avoiding recursion in the makefiles.  This will yield a
> larger benefit than worrying about the extra mkdir.
>
> If we have it, then .dir files are created in the installation
> directories.
>
> Trivially one can do:
>
> /dir:
> 	mkdir /dir
>
> /dir/prog: /dir
> 	gcc hi.c -o /dir/prog
>
> and avoid the extra mkdir, if one wanted.  Any down side to doing  
> that?
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From baldrick at free.fr  Wed Jan 21 01:54:21 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 21 Jan 2009 08:54:21 +0100
Subject: [LLVMdev] Interactions between LLVM and the Microsoft C++
	runtime
In-Reply-To: <508AEC31-3996-49A5-A4FC-E7683CE57930@apple.com>
References: <fdec3f880901201341n33c82a05seb64fdc8724a90cd@mail.gmail.com>
	<508AEC31-3996-49A5-A4FC-E7683CE57930@apple.com>
Message-ID: <200901210854.21879.baldrick@free.fr>

Hi,

> The problem that I've run into is that the LLVM codebase does  
> certain "idiomatic" things with STL containers that cause assertion  
> failures in the Microsoft runtime. Most notably:
> - Taking the address of the "first element" of an emtpy vector  
> (either &v[0] or &*v.begin())
> - Using an iterator into a collection (even if just for iterator  
> comparison) after an erase() or similar on that collection has  
> invalidated all iterators
> These assertions can occur in both debug and release configurations  
> (Microsoft includes certain assertions in the release runtime for  
> "security").

if you configure with --enable-expensive-checks on linux then I
think all of these are checked.  The upcoming 2.5 llvm build is
mostly clean but some issues did come up when building llvm-gcc.
They are being worked on (at least I hope they are!), PR3358.

Ciao,

Duncan.

From espindola at google.com  Wed Jan 21 03:55:30 2009
From: espindola at google.com (Rafael Espindola)
Date: Wed, 21 Jan 2009 09:55:30 +0000
Subject: [LLVMdev] linux build problem
In-Reply-To: <16e5fdf90901201110i3cfeb74dtb41c70f3337ae4cc@mail.gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
	<alpine.DEB.1.00.0901200933260.4381@babel.cs.utah.edu>
	<38a0d8450901200844lbc20612n5675083bba964060@mail.gmail.com>
	<16e5fdf90901201110i3cfeb74dtb41c70f3337ae4cc@mail.gmail.com>
Message-ID: <38a0d8450901210155w43854b3ft4fbaf8ac9f7dd09f@mail.gmail.com>

> I do have a concern that this might have regressed the Fortran FE.
> Could you (or someone who runs it) test this?

I noticed my patch was applied and then reverted. I am curious, why
was it a problem for the Fortran FE?

> -bw

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

From jay.foad at gmail.com  Wed Jan 21 04:02:34 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Wed, 21 Jan 2009 10:02:34 +0000
Subject: [LLVMdev] cygwin build patch
In-Reply-To: <DA7138AB-2671-4582-918A-A4D67F19E24D@apple.com>
References: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>
	<5CE7EB46-16C0-42FC-9A12-13328B7053AD@apple.com>
	<ee2e06e90901200122y5257d042g91aecec43019d287@mail.gmail.com>
	<DA7138AB-2671-4582-918A-A4D67F19E24D@apple.com>
Message-ID: <ee2e06e90901210202u3684a41bo4d0817d1b24f0273@mail.gmail.com>

> I'd prefer to avoid uint32_t.  I committed a couple patches, can you
> try again and let me know if you see any other failures?

With the attached patch I can build successfully on Cygwin.

The APInt.cpp part of the patch is just s/uint32_t/unsigned/g.

Thanks,
Jay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygwin.patch
Type: application/octet-stream
Size: 41439 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090121/36f8632d/attachment-0001.obj 

From aph at redhat.com  Wed Jan 21 06:15:53 2009
From: aph at redhat.com (Andrew Haley)
Date: Wed, 21 Jan 2009 12:15:53 +0000
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
In-Reply-To: <C9CEA12F-BC24-4995-89AF-80B9517AC0D2@apple.com>
References: <4974A258.1040108@redhat.com>	<99AFFD84-D5A8-4094-8FB9-DDAD8E2AE20E@apple.com>	<4975A318.2040208@redhat.com>
	<C9CEA12F-BC24-4995-89AF-80B9517AC0D2@apple.com>
Message-ID: <497711F9.2060904@redhat.com>

Chris Lattner wrote:
> On Jan 20, 2009, at 2:10 AM, Andrew Haley wrote:
> 
>> Chris Lattner wrote:
>>> On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote:
>>>
>>>> This is x86_64.  I have a problem where an absolute memory load
>>>> The current LLVM trunk does not have this bug.  This seems quite a
>>>> nasty
>>>> bug; is there any chance of a bug-fix release for LLVM 2.4, or
>>>> should I
>>>> just use LLVM trunk until LLVM 2.5 ?
>>> As others have pointed out, using a global and addglobalmapping is a
>>> great workaround for the problem.
>> Thanks.
>>
>>> We generally don't do "dot" releases, since we have a short release
>>> cycle anyway.  The 2.5 release process is slated to start this week.
>> Mmm, but the problem is that interfaces keep changing, so simply
>> upgrading to the latest release isn't possible.  Even the tiny
>> test case I posted doesn't work with the latest version: there
>> were changes needed to get it to compile.  Also, I can no longer
>> figure out how to turn on debugging dumps in the JIT.  The simple
>>
>>   DebugFlag = true;
>>   CurrentDebugType = "x86-emitter";
>>
>> no longer works, and there seems to be no replacement for it.
> 
> That should work fine, just use "jit" instead of "x86-emitter" as the  
> debug type.

That's impossible: CurrentDebugType is now private; it appears
nowhere in the installed headers.  I can't find any public interface
to allow a JIT to set it.

Andrew.

From criswell at cs.uiuc.edu  Wed Jan 21 10:04:55 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 21 Jan 2009 10:04:55 -0600
Subject: [LLVMdev] poolallocation error
In-Reply-To: <32AC7D48FD55284CB56FE956E7F9FCD218FD9E1F67@DSMAILBOX.ad.uiuc.edu>
References: <577C4E7D-1571-446B-9C3B-7B39308159E1@liacs.nl>,
	<85a4cc050901160828q33b0d142yf8d17780bf167fc6@mail.gmail.com>
	<32AC7D48FD55284CB56FE956E7F9FCD218FD9E1F67@DSMAILBOX.ad.uiuc.edu>
Message-ID: <497747A7.3040104@cs.uiuc.edu>

Dear Prakash,

I believe I've fixed the problem you were having with ds-aa.  Please
update your poolalloc tree, recompile, and let me know if it works.

-- John T.

Criswell, John T wrote:
> [snip]
>
> ________________________________________
> From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Prakash Prabhu [prakash.prabhu at gmail.com]
> Sent: Friday, January 16, 2009 10:28 AM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] poolallocation error
>
> Hi all,
>
> I too am getting this error for x86_64 when I am trying to use the
> Data Structure Analysis ...I svn upped both the llvm main branch and
> the poolalloc today in the morning and recompiled everything from
> scratch :
>
> $ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libpoolalloc.so
> -ds-aa < o.bc
>
> opt: /home/pprabhu/llvm/llvm/lib/VMCore/PassManager.cpp:1418: virtual
> void llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
> llvm::Pass*): Assertion `(P->getPotentialPassManagerType() <
> RequiredPass->getPotentialPassManagerType()) && "Unable to handle Pass
> that requires lower level Analysis pass"' failed.
> 0   opt       0x0000000000a3fcd0
> 1   opt       0x0000000000a40024
> 2   libc.so.6 0x00007f9fc318a100
> 3   libc.so.6 0x00007f9fc318a095 gsignal + 53
> 4   libc.so.6 0x00007f9fc318baf0 abort + 272
> 5   libc.so.6 0x00007f9fc31832df __assert_fail + 239
> 6   opt       0x00000000009caeac
> llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
> llvm::Pass*) + 252
> 7   opt       0x00000000009cbe53 llvm::PMDataManager::add(llvm::Pass*,
> bool) + 899
> 8   opt       0x00000000009cc296
> llvm::ModulePass::assignPassManager(llvm::PMStack&,
> llvm::PassManagerType) + 132
> 9   opt       0x00000000009d5ff9
> llvm::PassManagerImpl::addTopLevelPass(llvm::Pass*) + 227
> 10  opt       0x00000000009cad7e
> llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 500
> 11  opt       0x00000000009d6118 llvm::PassManagerImpl::add(llvm::Pass*) + 36
> 12  opt       0x00000000009cada7 llvm::PassManager::add(llvm::Pass*) + 33
> 13  opt       0x00000000006e5cd3
> 14  opt       0x00000000006e7a6d main + 3237
> 15  libc.so.6 0x00007f9fc31761c4 __libc_start_main + 244
> 16  opt       0x00000000006d7c19 __gxx_personality_v0 + 721
> Aborted
>
>
> Is there something that I am missing on the command line ? Does anyone
> use DSA actively now ?
>
> Thanks for your time.
>
> - Prakash
>
> On Wed, Nov 19, 2008 at 8:59 AM, Mattias Holm <holm at liacs.nl> wrote:
>   
>> Hi,
>>
>> I am trying to use the poolallocator. More specific, I am trying to
>> play around with the pointer compression pass. Though, I get assertion
>> failures for the pass dependencies.
>>
>> This is when it in PointerCompress::getAnalysisUsage tries to register
>> the the BU pass as required. I.e. when
>> AU.addRequired<CompleteBUDataStructures>(); is called.
>>
>>
>> $ opt -f -load ~/Projects/llvmstuff/opt/poolalloc/lib/
>> libpoolalloc.dylib -raiseallocs -poolalloc-passing-all-pools -
>> pointercompress llist-noopt.bc -o llist-dp.bc
>>
>> Assertion failed: ((P->getPotentialPassManagerType() < RequiredPass-
>>  >getPotentialPassManagerType()) && "Unable to handle Pass that
>> requires lower level Analysis pass"), function
>> addLowerLevelRequiredPass, file ~/Projects/llvmstuff/llvm/lib/VMCore/
>> PassManager.cpp, line 1418.
>>
>> Any ideas what is going wrong here?
>>
>>
>> /Mattias
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>     
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From aph at redhat.com  Wed Jan 21 11:13:25 2009
From: aph at redhat.com (Andrew Haley)
Date: Wed, 21 Jan 2009 17:13:25 +0000
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
In-Reply-To: <m3zlhnupkn.fsf@telefonica.net>
References: <4974A258.1040108@redhat.com>
	<m363kbw8pb.fsf@telefonica.net>	<4974B86D.7000505@redhat.com>
	<m3zlhnupkn.fsf@telefonica.net>
Message-ID: <497757B5.7020703@redhat.com>

?scar Fuentes wrote:
> Andrew Haley <aph at redhat.com> writes:
> 
>> ?scar Fuentes wrote:
>>> The following message is a courtesy copy of an article
>>> that has been posted to gmane.comp.compilers.llvm.devel as well.
>>>
>>> Andrew Haley <aph at redhat.com> writes:
>>>
>>>> This is x86_64.  I have a problem where an absolute memory load
>>>>
>>>> define i32 @foo() {
>>>> entry:
>>>>         %0 = load i32* inttoptr (i64 12704196 to i32*)          ; <i32> [#uses=1]
>>>>         ret i32 %0
>>>> }
>>>>
>>>> generates incorrect code on LLVM 2.4:
>>>>
>>>> 0x7ffff6d54010:	mov    0xc1d9c4(%rip),%eax        # 0x7ffff79719da
>>>> 0x7ffff6d54016:	retq
>>> IIRC, one workaround is to use a GlobalValue instead of a IntToPtr on a
>>> Constant.
>> Err, how?  I can't figure out how to do it.  The only documentation for
>> GlobalValue describes it as a superclass of GlobalVariables and Functions.
> 
> IIRC, the stuff I used was something like...
> 
> GlobalVariable *gv = new GlobalVariable( /* your pointer type */,
>                          other required parameters...);
> AddGlobalMapping(gv, your_pointer_value); // i.e. (void*)0x938742
> 
> then, where you use
> 
>   Constant* thp = ConstantExpr::getCast(Instruction::IntToPtr,
>   your_pointer_value, /* i.e. 0x938742 */
>   /* your pointer type */);
> 
> /* Now use thp */
> 
> change it to
> 
> /* Now just use gv */
> 
> GetGlobalValueAtAddress may be useful for housekeeping.

How does one use GetGlobalValueAtAddress?  It returns a const GlobalValue *,
but it seems that all the LLVM operations take a Value *.  Any attempt to do
anything with a const GlobalValue * is rejected by the C++ compiler.  Perhaps
I'm supposed to cast away the const?

    const GlobalValue *vv = engine->getGlobalValueAtAddress(&p);
    if (vv)
      {
	Value *tmp = builder.CreateLoad(vv);

results in

tut4.cpp:55: error: invalid conversion from 'const llvm::Value*' to 'llvm::Value*'
tut4.cpp:55: error:   initializing argument 1 of 'llvm::LoadInst* llvm::IRBuilder<preserveNames, T>::CreateLoad(llvm::Value*, const char*) [with bool preserveNames = true, T = llvm::ConstantFolder]'

Andrew.

From ofv at wanadoo.es  Wed Jan 21 11:36:39 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Wed, 21 Jan 2009 18:36:39 +0100
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
References: <4974A258.1040108@redhat.com> <m363kbw8pb.fsf@telefonica.net>
	<4974B86D.7000505@redhat.com> <m3zlhnupkn.fsf@telefonica.net>
	<497757B5.7020703@redhat.com>
Message-ID: <m3eiywv9w8.fsf@telefonica.net>

Andrew Haley <aph at redhat.com> writes:

>>>> IIRC, one workaround is to use a GlobalValue instead of a IntToPtr on a
>>>> Constant.
>>> Err, how?  I can't figure out how to do it.  The only documentation for
>>> GlobalValue describes it as a superclass of GlobalVariables and Functions.
>> 
>> IIRC, the stuff I used was something like...
>> 
>> GlobalVariable *gv = new GlobalVariable( /* your pointer type */,
>>                          other required parameters...);
>> AddGlobalMapping(gv, your_pointer_value); // i.e. (void*)0x938742
>> 
>> then, where you use
>> 
>>   Constant* thp = ConstantExpr::getCast(Instruction::IntToPtr,
>>   your_pointer_value, /* i.e. 0x938742 */
>>   /* your pointer type */);
>> 
>> /* Now use thp */
>> 
>> change it to
>> 
>> /* Now just use gv */
>> 
>> GetGlobalValueAtAddress may be useful for housekeeping.
>
> How does one use GetGlobalValueAtAddress?

Sorry, GetGlobalValueAtAddress is a helper function on my code, it is
not LLVM.

The getGlobalValueAtAddress method is not required for what you need. Go
ahead without it.

[snip]

-- 
Oscar


From sabbi.baburao at gmail.com  Wed Jan 21 04:46:10 2009
From: sabbi.baburao at gmail.com (Babu Rao Sabbi)
Date: Wed, 21 Jan 2009 16:16:10 +0530
Subject: [LLVMdev] Errors while building and installation of llvm-1.9
Message-ID: <db3ef26c0901210246i6f78736fgb737febf058ef0b4@mail.gmail.com>

I have downloaded the llvm-1.9 from the following link
http://llvm.org/releases/download.html#1.9

There are some header files missing and I am getting some compilation errors
of the source code  when I compiled the llvm-1.9.

Can you please send me the correct source code.

I am getting the following errors when I compiled the llvm-1.9 on
linux-ubuntu with the following command.

make -k | tee gnumake.out ENABLE_OPTIMIZED=1

/home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/FileLexer.l:33:24: error:
FileParser.h: No such file or directory

/home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/FileLexer.l:186: error:
'Filelval' was not declared in this scope
/home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/FileLexer.l:187: error:
'CODEFRAGMENT' was not declared in this scppe.

g++: /home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/FileParser.cpp: No
such file or directory
g++: no input files
make[2]: ***
[/home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/Release/FileParser.o]
Error 1

 Target `all' not remade because of errors.

it is showing some errors in the source code of the folder
/llvm-1.9/examples also.

When I tried to install llvm using "make install" command I got the
following error.

make[1]: *** No rule to make target
`/home/baburao/Desktop/LLVM/llvm-1.9/Release/bin/tblgen', needed by
`/home/baburao/Desktop/LLVM/llvm-1.9/lib/VMCore/Release/Intrinsics.gen.tmp'.
Stop.
**
my gcc version is 4.2.4 (Ubuntu 4.2.4-1ubuntu3)

                        Thanking you

regards
baburao.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090121/6ddfa8b9/attachment.html 

From gordonhenriksen at me.com  Wed Jan 21 11:55:06 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Wed, 21 Jan 2009 12:55:06 -0500
Subject: [LLVMdev] cygwin build patch
In-Reply-To: <ee2e06e90901200122y5257d042g91aecec43019d287@mail.gmail.com>
References: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>
	<5CE7EB46-16C0-42FC-9A12-13328B7053AD@apple.com>
	<ee2e06e90901200122y5257d042g91aecec43019d287@mail.gmail.com>
Message-ID: <728D7B6B-4D40-472F-B9B7-5004E02512AB@me.com>

Using an explicit instantiation, e.g. std::min<uint32_t>(), is  
sometimes a good fix and more succinct than an casting one of the  
arguments.

On 2009-01-20, at 04:22, Jay Foad wrote:

>>> I realise that the DataTypes.h.in part might be controversial. Also,
>>> there's probably a better place to put it, but I'm not sure where.
>>
>> I didn't apply this part.  What problems does it cause to not have
>> this?  Can we fix uses of max and min?
>
> I get these errors in lib:
>
> .../lib/Analysis/ValueTracking.cpp:162: error: no matching function
> for call to 'min(unsigned int&, uint32_t&)'
> .../lib/Analysis/ValueTracking.cpp:163: error: no matching function
> for call to 'min(unsigned int&, uint32_t&)'
> .../lib/Analysis/ValueTracking.cpp:358: error: no matching function
> for call to 'min(unsigned int&, uint32_t)'
> .../lib/Analysis/ValueTracking.cpp:469: error: no matching function
> for call to 'min(unsigned int&, long unsigned int)'
> .../lib/Analysis/ValueTracking.cpp:708: error: no matching function
> for call to 'min(unsigned int&, uint32_t)'
> .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1432: error: no matching
> function for call to 'max(long unsigned int, unsigned int&)'
> .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1747: error: no matching
> function for call to 'min(unsigned int&, uint32_t)'
> .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2033: error: no matching
> function for call to 'min(unsigned int&, uint32_t)'
>
> I could try to fix this by changing the code to consistently use
> either unsigned or uint32_t (which?), rather than both. Or by adding
> casts at the point of calling min/max. What would you prefer?
>
> Thanks,
> Jay.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



? Gordon



From clattner at apple.com  Wed Jan 21 12:07:39 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 21 Jan 2009 10:07:39 -0800
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
In-Reply-To: <497711F9.2060904@redhat.com>
References: <4974A258.1040108@redhat.com>
	<99AFFD84-D5A8-4094-8FB9-DDAD8E2AE20E@apple.com>
	<4975A318.2040208@redhat.com>
	<C9CEA12F-BC24-4995-89AF-80B9517AC0D2@apple.com>
	<497711F9.2060904@redhat.com>
Message-ID: <E6B62E1E-70E0-489C-9618-D89F359EAD15@apple.com>

On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote:
>> That should work fine, just use "jit" instead of "x86-emitter" as the
>> debug type.
>
> That's impossible: CurrentDebugType is now private; it appears
> nowhere in the installed headers.  I can't find any public interface
> to allow a JIT to set it.

Ah ok.  I'd suggest doing what llvm-gcc does here, it is a much more  
stable API:

   std::vector<const char*> Args;
   Args.push_back(""); // program name
   Args.push_back("-debug-only=jit");
   ...
   Args.push_back(0);  // Null terminator.
   cl::ParseCommandLineOptions(Args.size()-1, (char**)&Args[0]);

This also gives you control over optimizations and codegen options,

-Chris

From clattner at apple.com  Wed Jan 21 12:10:00 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 21 Jan 2009 10:10:00 -0800
Subject: [LLVMdev] cygwin build patch
In-Reply-To: <ee2e06e90901210202u3684a41bo4d0817d1b24f0273@mail.gmail.com>
References: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>
	<5CE7EB46-16C0-42FC-9A12-13328B7053AD@apple.com>
	<ee2e06e90901200122y5257d042g91aecec43019d287@mail.gmail.com>
	<DA7138AB-2671-4582-918A-A4D67F19E24D@apple.com>
	<ee2e06e90901210202u3684a41bo4d0817d1b24f0273@mail.gmail.com>
Message-ID: <60719C7E-8E1F-4740-AA4D-8F9CC3AB1B8C@apple.com>


On Jan 21, 2009, at 2:02 AM, Jay Foad wrote:

>> I'd prefer to avoid uint32_t.  I committed a couple patches, can you
>> try again and let me know if you see any other failures?
>
> With the attached patch I can build successfully on Cygwin.
>
> The APInt.cpp part of the patch is just s/uint32_t/unsigned/g.

Thanks Jay! You beat me to it :), applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090119/072479.html

-chris

From tonic at nondot.org  Wed Jan 21 13:48:09 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Wed, 21 Jan 2009 11:48:09 -0800 (PST)
Subject: [LLVMdev] Errors while building and installation of llvm-1.9
In-Reply-To: <db3ef26c0901210246i6f78736fgb737febf058ef0b4@mail.gmail.com>
References: <db3ef26c0901210246i6f78736fgb737febf058ef0b4@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0901211140400.25032@nondot.org>


Why 1.9? 1.9 is over 2 years old. You should use 2.4.
http://llvm.org/releases/download.html#2.4

-Tanya

On Wed, 21 Jan 2009, Babu Rao Sabbi wrote:

> I have downloaded the llvm-1.9 from the following link
> http://llvm.org/releases/download.html#1.9
>
> There are some header files missing and I am getting some compilation errors
> of the source code  when I compiled the llvm-1.9.
>
> Can you please send me the correct source code.
>
> I am getting the following errors when I compiled the llvm-1.9 on
> linux-ubuntu with the following command.
>
> make -k | tee gnumake.out ENABLE_OPTIMIZED=1
>
> /home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/FileLexer.l:33:24: error:
> FileParser.h: No such file or directory
>
> /home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/FileLexer.l:186: error:
> 'Filelval' was not declared in this scope
> /home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/FileLexer.l:187: error:
> 'CODEFRAGMENT' was not declared in this scppe.
>
> g++: /home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/FileParser.cpp: No
> such file or directory
> g++: no input files
> make[2]: ***
> [/home/baburao/Desktop/LLVM/llvm-1.9/utils/TableGen/Release/FileParser.o]
> Error 1
>
> Target `all' not remade because of errors.
>
> it is showing some errors in the source code of the folder
> /llvm-1.9/examples also.
>
> When I tried to install llvm using "make install" command I got the
> following error.
>
> make[1]: *** No rule to make target
> `/home/baburao/Desktop/LLVM/llvm-1.9/Release/bin/tblgen', needed by
> `/home/baburao/Desktop/LLVM/llvm-1.9/lib/VMCore/Release/Intrinsics.gen.tmp'.
> Stop.
> **
> my gcc version is 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
>
>                        Thanking you
>
> regards
> baburao.
>

From prakash.prabhu at gmail.com  Wed Jan 21 13:13:45 2009
From: prakash.prabhu at gmail.com (Prakash Prabhu)
Date: Wed, 21 Jan 2009 14:13:45 -0500
Subject: [LLVMdev] poolallocation error
In-Reply-To: <497747A7.3040104@cs.uiuc.edu>
References: <577C4E7D-1571-446B-9C3B-7B39308159E1@liacs.nl>
	<85a4cc050901160828q33b0d142yf8d17780bf167fc6@mail.gmail.com>
	<32AC7D48FD55284CB56FE956E7F9FCD218FD9E1F67@DSMAILBOX.ad.uiuc.edu>
	<497747A7.3040104@cs.uiuc.edu>
Message-ID: <85a4cc050901211113h5c40f73u4c24c43bf44ac4ba@mail.gmail.com>

Hi John,

Thanks for the fix! It is working properly now :) :

$ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libLLVMDataStructure.so
-stats -ds-aa -ipconstprop < prog.bc
WARNING: You're attempting to print out a bitcode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bitcode first-hand, you
can force output with the `-f' option.

===-------------------------------------------------------------------------===
                          ... Statistics Collected ...
===-------------------------------------------------------------------------===

  19        - Number of call nodes merged
  35        - Number of globals trivially removed
1040        - Number of nodes allocated
   2        - Number of nodes completely folded
 128        - Number of nodes removed by reachability
 128        - Number of nodes trivially removed
   1 dsa-bu - Maximum SCC Size in Call Graph
   1 dsa-bu - Number of 'actual' call edges
   1 dsa-bu - Number of graphs inlined
   1 td_dsa - Number of graphs inlined

thanks,
Prakash

On Wed, Jan 21, 2009 at 11:04 AM, John Criswell <criswell at cs.uiuc.edu> wrote:
> Dear Prakash,
>
> I believe I've fixed the problem you were having with ds-aa.  Please
> update your poolalloc tree, recompile, and let me know if it works.
>
> -- John T.
>
> Criswell, John T wrote:
>> [snip]
>>
>> ________________________________________
>> From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Prakash Prabhu [prakash.prabhu at gmail.com]
>> Sent: Friday, January 16, 2009 10:28 AM
>> To: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] poolallocation error
>>
>> Hi all,
>>
>> I too am getting this error for x86_64 when I am trying to use the
>> Data Structure Analysis ...I svn upped both the llvm main branch and
>> the poolalloc today in the morning and recompiled everything from
>> scratch :
>>
>> $ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libpoolalloc.so
>> -ds-aa < o.bc
>>
>> opt: /home/pprabhu/llvm/llvm/lib/VMCore/PassManager.cpp:1418: virtual
>> void llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
>> llvm::Pass*): Assertion `(P->getPotentialPassManagerType() <
>> RequiredPass->getPotentialPassManagerType()) && "Unable to handle Pass
>> that requires lower level Analysis pass"' failed.
>> 0   opt       0x0000000000a3fcd0
>> 1   opt       0x0000000000a40024
>> 2   libc.so.6 0x00007f9fc318a100
>> 3   libc.so.6 0x00007f9fc318a095 gsignal + 53
>> 4   libc.so.6 0x00007f9fc318baf0 abort + 272
>> 5   libc.so.6 0x00007f9fc31832df __assert_fail + 239
>> 6   opt       0x00000000009caeac
>> llvm::MPPassManager::addLowerLevelRequiredPass(llvm::Pass*,
>> llvm::Pass*) + 252
>> 7   opt       0x00000000009cbe53 llvm::PMDataManager::add(llvm::Pass*,
>> bool) + 899
>> 8   opt       0x00000000009cc296
>> llvm::ModulePass::assignPassManager(llvm::PMStack&,
>> llvm::PassManagerType) + 132
>> 9   opt       0x00000000009d5ff9
>> llvm::PassManagerImpl::addTopLevelPass(llvm::Pass*) + 227
>> 10  opt       0x00000000009cad7e
>> llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 500
>> 11  opt       0x00000000009d6118 llvm::PassManagerImpl::add(llvm::Pass*) + 36
>> 12  opt       0x00000000009cada7 llvm::PassManager::add(llvm::Pass*) + 33
>> 13  opt       0x00000000006e5cd3
>> 14  opt       0x00000000006e7a6d main + 3237
>> 15  libc.so.6 0x00007f9fc31761c4 __libc_start_main + 244
>> 16  opt       0x00000000006d7c19 __gxx_personality_v0 + 721
>> Aborted
>>
>>
>> Is there something that I am missing on the command line ? Does anyone
>> use DSA actively now ?
>>
>> Thanks for your time.
>>
>> - Prakash
>>
>> On Wed, Nov 19, 2008 at 8:59 AM, Mattias Holm <holm at liacs.nl> wrote:
>>
>>> Hi,
>>>
>>> I am trying to use the poolallocator. More specific, I am trying to
>>> play around with the pointer compression pass. Though, I get assertion
>>> failures for the pass dependencies.
>>>
>>> This is when it in PointerCompress::getAnalysisUsage tries to register
>>> the the BU pass as required. I.e. when
>>> AU.addRequired<CompleteBUDataStructures>(); is called.
>>>
>>>
>>> $ opt -f -load ~/Projects/llvmstuff/opt/poolalloc/lib/
>>> libpoolalloc.dylib -raiseallocs -poolalloc-passing-all-pools -
>>> pointercompress llist-noopt.bc -o llist-dp.bc
>>>
>>> Assertion failed: ((P->getPotentialPassManagerType() < RequiredPass-
>>>  >getPotentialPassManagerType()) && "Unable to handle Pass that
>>> requires lower level Analysis pass"), function
>>> addLowerLevelRequiredPass, file ~/Projects/llvmstuff/llvm/lib/VMCore/
>>> PassManager.cpp, line 1418.
>>>
>>> Any ideas what is going wrong here?
>>>
>>>
>>> /Mattias
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From tonic at nondot.org  Wed Jan 21 14:36:57 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Wed, 21 Jan 2009 12:36:57 -0800 (PST)
Subject: [LLVMdev] LLVM 2.5 Code Freeze Tonight!
Message-ID: <Pine.LNX.4.62.0901211234200.25191@nondot.org>


Please try to limit today's checkins to critical bug fixes. The code 
freeze/branch creation will happen at 9PM PST.

Thanks,
Tanya

From isanbard at gmail.com  Wed Jan 21 15:30:39 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 21 Jan 2009 13:30:39 -0800
Subject: [LLVMdev] linux build problem
In-Reply-To: <38a0d8450901210155w43854b3ft4fbaf8ac9f7dd09f@mail.gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
	<alpine.DEB.1.00.0901200933260.4381@babel.cs.utah.edu>
	<38a0d8450901200844lbc20612n5675083bba964060@mail.gmail.com>
	<16e5fdf90901201110i3cfeb74dtb41c70f3337ae4cc@mail.gmail.com>
	<38a0d8450901210155w43854b3ft4fbaf8ac9f7dd09f@mail.gmail.com>
Message-ID: <16e5fdf90901211330m313f8563tcd7154a8cb1ff320@mail.gmail.com>

On Wed, Jan 21, 2009 at 1:55 AM, Rafael Espindola <espindola at google.com> wrote:
>> I do have a concern that this might have regressed the Fortran FE.
>> Could you (or someone who runs it) test this?
>
> I noticed my patch was applied and then reverted. I am curious, why
> was it a problem for the Fortran FE?
>
Reverted, but with a better fix. :-) I wanted to keep it more in sync
with Apple's GCC. The Fortran FE has had a lot of troubles with these
warnings. Your patch reverted things back to how they were before the
merge, i.e. to the way that would cause the warnings to occur. I don't
know why, because the warning mechanism of GCC is opaque to me.

-bw

From regehr at cs.utah.edu  Wed Jan 21 16:16:24 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Wed, 21 Jan 2009 15:16:24 -0700 (MST)
Subject: [LLVMdev] linux build problem
In-Reply-To: <16e5fdf90901211330m313f8563tcd7154a8cb1ff320@mail.gmail.com>
References: <49752A15.3010305@cs.utah.edu>
	<A1C316B5-930D-46B6-B2D1-3A83D1FE8432@gmail.com>
	<alpine.DEB.1.00.0901200933260.4381@babel.cs.utah.edu>
	<38a0d8450901200844lbc20612n5675083bba964060@mail.gmail.com>
	<16e5fdf90901201110i3cfeb74dtb41c70f3337ae4cc@mail.gmail.com>
	<38a0d8450901210155w43854b3ft4fbaf8ac9f7dd09f@mail.gmail.com>
	<16e5fdf90901211330m313f8563tcd7154a8cb1ff320@mail.gmail.com>
Message-ID: <alpine.DEB.1.00.0901211516120.8592@babel.cs.utah.edu>

Works fine for me now BTW.

Thanks!

John


On Wed, 21 Jan 2009, Bill Wendling wrote:

> On Wed, Jan 21, 2009 at 1:55 AM, Rafael Espindola <espindola at google.com> wrote:
>>> I do have a concern that this might have regressed the Fortran FE.
>>> Could you (or someone who runs it) test this?
>>
>> I noticed my patch was applied and then reverted. I am curious, why
>> was it a problem for the Fortran FE?
>>
> Reverted, but with a better fix. :-) I wanted to keep it more in sync
> with Apple's GCC. The Fortran FE has had a lot of troubles with these
> warnings. Your patch reverted things back to how they were before the
> merge, i.e. to the way that would cause the warnings to occur. I don't
> know why, because the warning mechanism of GCC is opaque to me.
>
> -bw
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From tim.foley.is at gmail.com  Wed Jan 21 16:39:03 2009
From: tim.foley.is at gmail.com (Tim Foley)
Date: Wed, 21 Jan 2009 14:39:03 -0800
Subject: [LLVMdev] Interactions between LLVM and the Microsoft C++
	runtime
In-Reply-To: <200901210854.21879.baldrick@free.fr>
References: <fdec3f880901201341n33c82a05seb64fdc8724a90cd@mail.gmail.com>
	<508AEC31-3996-49A5-A4FC-E7683CE57930@apple.com>
	<200901210854.21879.baldrick@free.fr>
Message-ID: <fdec3f880901211439p4f503212gbfb1b3303d75240c@mail.gmail.com>

This is great news. I am pulling down the mainline and will see if this
clears things up.

- Tim

On Tue, Jan 20, 2009 at 11:54 PM, Duncan Sands <baldrick at free.fr> wrote:

> Hi,
>
> > The problem that I've run into is that the LLVM codebase does
> > certain "idiomatic" things with STL containers that cause assertion
> > failures in the Microsoft runtime. Most notably:
> > - Taking the address of the "first element" of an emtpy vector
> > (either &v[0] or &*v.begin())
> > - Using an iterator into a collection (even if just for iterator
> > comparison) after an erase() or similar on that collection has
> > invalidated all iterators
> > These assertions can occur in both debug and release configurations
> > (Microsoft includes certain assertions in the release runtime for
> > "security").
>
> if you configure with --enable-expensive-checks on linux then I
> think all of these are checked.  The upcoming 2.5 llvm build is
> mostly clean but some issues did come up when building llvm-gcc.
> They are being worked on (at least I hope they are!), PR3358.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090121/d6f738ca/attachment-0001.html 

From isanbard at gmail.com  Wed Jan 21 17:12:30 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 21 Jan 2009 15:12:30 -0800
Subject: [LLVMdev] RFA: Constant String c"\000"
Message-ID: <16e5fdf90901211512w56274546p7dbcc9e57e0320aa@mail.gmail.com>

The Constants.cpp file returns a ConstantAggregateZero object when you
pass it a c"\000" string. Here is the code:

Constant *ConstantArray::get(const ArrayType *Ty,
                             const std::vector<Constant*> &V) {
  // If this is an all-zero array, return a ConstantAggregateZero
object
  if (!V.empty()) {
    Constant *C = V[0];
    if (!C->isNullValue())
      return ArrayConstants->getOrCreate(Ty, V);
    for (unsigned i = 1, e = V.size(); i != e; ++i)
      if (V[i] != C)
        return ArrayConstants->getOrCreate(Ty, V);
  }
  return ConstantAggregateZero::get(Ty);
}

This seems wrong to me, and it's causing a problem in Objective-C,
which requires that an empty string be placed in the .cstring section.

Would it break everything or hurt performance to have a check in here
that if this is a [1 x i8] array where C->isNullValue(), we should
allow it to stay instead of creating the CAZ, which is translated into
a "zeroinitialier"?

-bw

From eli.friedman at gmail.com  Wed Jan 21 17:23:57 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 21 Jan 2009 15:23:57 -0800
Subject: [LLVMdev] RFA: Constant String c"\000"
In-Reply-To: <16e5fdf90901211512w56274546p7dbcc9e57e0320aa@mail.gmail.com>
References: <16e5fdf90901211512w56274546p7dbcc9e57e0320aa@mail.gmail.com>
Message-ID: <f5aa3e9b0901211523r3ba9f40ckb5d2bd65ababcf99@mail.gmail.com>

On Wed, Jan 21, 2009 at 3:12 PM, Bill Wendling <isanbard at gmail.com> wrote:
> This seems wrong to me, and it's causing a problem in Objective-C,
> which requires that an empty string be placed in the .cstring section.

What's wrong?  It is all zeros.  If some particular user requires it
to be in a special section, it should be marked as such; we shouldn't
be guaranteeing a different representation for two constructs which
fundamentally represent the same thing.

That said, I don't think allowing it would break anything...

-Eli

From Dave.Nadler at nadler.com  Wed Jan 21 17:40:19 2009
From: Dave.Nadler at nadler.com (Dave Nadler)
Date: Wed, 21 Jan 2009 18:40:19 -0500
Subject: [LLVMdev] Using LLVM as cross-compiler to C
Message-ID: <6.0.1.1.2.20090121184018.01d281f0@pop.nadler.com>

Hi All - Newbie warning... I am developing for a target that does not have 
a functioning C++ environment, and need to use C++. It was suggested that I 
could use LLVM to compile to C (using llc -march=c), then run the resulting 
C-code through the working C-cross-compilation tools. So, some newbie 
questions:

(1) Is this crazy ?
(2) What happens to all the C++ RTL ? Is it statically linked as LLVM code, 
then translated back into C ?
(3) Where does the LLVM RTL come from - newlib ? glibc ? other ?
(4) Is it manageable to create a small number of intrinsics to allow access 
to the C runtime functions on the target, or is this difficult ? In the 
mailing list archive I saw some unresolved question with warnings about 
type conversions for someone trying this...

Thanks in advance for your advice,
Best Regards, Dave

Dave Nadler, USA East Coast voice (978) 263-0097,  drn at nadler.com, Skype 
Dave.Nadler1  



From clattner at apple.com  Wed Jan 21 17:54:50 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 21 Jan 2009 15:54:50 -0800
Subject: [LLVMdev] RFA: Constant String c"\000"
In-Reply-To: <16e5fdf90901211512w56274546p7dbcc9e57e0320aa@mail.gmail.com>
References: <16e5fdf90901211512w56274546p7dbcc9e57e0320aa@mail.gmail.com>
Message-ID: <C7DE9012-D7E6-455B-81A1-D33A72BDB147@apple.com>


On Jan 21, 2009, at 3:12 PM, Bill Wendling wrote:

> The Constants.cpp file returns a ConstantAggregateZero object when you
> pass it a c"\000" string. Here is the code:
>
> Constant *ConstantArray::get(const ArrayType *Ty,
>                             const std::vector<Constant*> &V) {
>  // If this is an all-zero array, return a ConstantAggregateZero
> object
>  if (!V.empty()) {
>    Constant *C = V[0];
>    if (!C->isNullValue())
>      return ArrayConstants->getOrCreate(Ty, V);
>    for (unsigned i = 1, e = V.size(); i != e; ++i)
>      if (V[i] != C)
>        return ArrayConstants->getOrCreate(Ty, V);
>  }
>  return ConstantAggregateZero::get(Ty);
> }
>
> This seems wrong to me, and it's causing a problem in Objective-C,
> which requires that an empty string be placed in the .cstring section.
>
> Would it break everything or hurt performance to have a check in here
> that if this is a [1 x i8] array where C->isNullValue(), we should
> allow it to stay instead of creating the CAZ, which is translated into
> a "zeroinitialier"?

Bill and I spoke about this.  Using CAZ to represent an all-zeros  
array is a fine thing for the LLVM IR to do, and we should continue  
it.  If ObjC needs its string in a special place (not cstring) then  
the front-end should put the right section info on the globalvariable.

-Chris

From Dave.Nadler at nadler.com  Wed Jan 21 17:37:44 2009
From: Dave.Nadler at nadler.com (Dave Nadler)
Date: Wed, 21 Jan 2009 18:37:44 -0500
Subject: [LLVMdev] Using LLVM as cross-compiler to C
Message-ID: <6.0.1.1.2.20090121182719.01d29580@pop.nadler.com>

Hi All - Newbie warning... I am developing for a target that does not have 
a functioning C++ environment, and need to use C++. It was suggested that I 
could use LLVM to compile to C (using llc -march=c), then run the resulting 
C-code through the working C-cross-compilation tools. So, some newbie 
questions:

(1) Is this crazy ?
(2) What happens to all the C++ RTL ? Is it statically linked as LLVM code, 
then translated back into C ?
(3) Where does the LLVM RTL come from - newlib ? glibc ? other ?
(4) Is it manageable to create a small number of intrinsics to allow access 
to the C runtime functions on the target, or is this difficult ? In the 
mailing list archive I saw some unresolved question with warnings about 
type conversions for someone trying this...

Thanks in advance for your advice,
Best Regards, Dave

Dave Nadler, USA East Coast voice (978) 263-0097,  drn at nadler.com, Skype 
Dave.Nadler1 



From mai4 at uiuc.edu  Wed Jan 21 18:31:12 2009
From: mai4 at uiuc.edu (Haohui Mai)
Date: Wed, 21 Jan 2009 18:31:12 -0600
Subject: [LLVMdev] Implementing customized intrinsic
Message-ID: <344BB08B-6862-47C6-92F8-253462B05D4D@uiuc.edu>

Dear all,

Currently I'm working on a project that add various checks into the  
LLVM bitcode. For example,  I insert function calls before every  
load / store instructions to guarantee that these instructions are  
safe. I really want to implement them as LLVM intrinsics or ``special  
function calls'' so that I am able to leverage the power of things  
like InstVisitor. However, it seems it is difficult to do it without  
changing LLVM's source codes, cause

i) all constructors of CallInst are private
ii) There's no interfaces for implementing customized intrinsics  
(without changing intrinsics*.td)

It is very helpful to mark these checks as special calls (like  
intrinsics), it would ease the implementation of optimizations since  
they only work on these special calls, say, I could save some  
information in the subclass of CallInst.

I also notice that the access identifier of CallInst are changed after  
LLVM 2.0. I would be appreciated if you guys could explain the  
rationale behind the changes.

Thank you very much.

Best,

Haohui



From haohui.mai at gmail.com  Wed Jan 21 18:32:48 2009
From: haohui.mai at gmail.com (Haohui Mai)
Date: Wed, 21 Jan 2009 18:32:48 -0600
Subject: [LLVMdev] Implementing customized intrinsic
References: <344BB08B-6862-47C6-92F8-253462B05D4D@uiuc.edu>
Message-ID: <1B0F2B1F-CE62-434D-B0EC-86FAB38417E2@gmail.com>

Dear all,

Currently I'm working on a project that add various checks into the
LLVM bitcode. For example,  I insert function calls before every
load / store instructions to guarantee that these instructions are
safe. I really want to implement them as LLVM intrinsics or ``special
function calls'' so that I am able to leverage the power of things
like InstVisitor. However, it seems it is difficult to do it without
changing LLVM's source codes, cause

i) all constructors of CallInst are private
ii) There's no interfaces for implementing customized intrinsics
(without changing intrinsics*.td)

It is very helpful to mark these checks as special calls (like
intrinsics), it would ease the implementation of optimizations since
they only work on these special calls, say, I could save some
information in the subclass of CallInst.

I also notice that the access identifier of CallInst are changed after
LLVM 2.0. I would be appreciated if you guys could explain the
rationale behind the changes.

Thank you very much.

Best,

Haohui


From tonic at nondot.org  Wed Jan 21 20:01:29 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Wed, 21 Jan 2009 18:01:29 -0800 (PST)
Subject: [LLVMdev] Implementing customized intrinsic
In-Reply-To: <344BB08B-6862-47C6-92F8-253462B05D4D@uiuc.edu>
References: <344BB08B-6862-47C6-92F8-253462B05D4D@uiuc.edu>
Message-ID: <Pine.LNX.4.62.0901211800130.26012@nondot.org>


Does the llvm annotation intrinsic not work for what you are trying to do?

http://llvm.org/docs/LangRef.html#int_var_annotation
http://llvm.org/docs/LangRef.html#int_annotation

-Tanya

On Wed, 21 Jan 2009, Haohui Mai wrote:

> Dear all,
>
> Currently I'm working on a project that add various checks into the
> LLVM bitcode. For example,  I insert function calls before every
> load / store instructions to guarantee that these instructions are
> safe. I really want to implement them as LLVM intrinsics or ``special
> function calls'' so that I am able to leverage the power of things
> like InstVisitor. However, it seems it is difficult to do it without
> changing LLVM's source codes, cause
>
> i) all constructors of CallInst are private
> ii) There's no interfaces for implementing customized intrinsics
> (without changing intrinsics*.td)
>
> It is very helpful to mark these checks as special calls (like
> intrinsics), it would ease the implementation of optimizations since
> they only work on these special calls, say, I could save some
> information in the subclass of CallInst.
>
> I also notice that the access identifier of CallInst are changed after
> LLVM 2.0. I would be appreciated if you guys could explain the
> rationale behind the changes.
>
> Thank you very much.
>
> Best,
>
> Haohui
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From tim.foley.is at gmail.com  Wed Jan 21 18:48:22 2009
From: tim.foley.is at gmail.com (Tim Foley)
Date: Wed, 21 Jan 2009 16:48:22 -0800
Subject: [LLVMdev] CMake Win64 build status
Message-ID: <fdec3f880901211648g4da37d4g7db96f9832fe5647@mail.gmail.com>

I'm trying to build mainline LLVM (to fold in a fix) and I decided to try
the CMake build since that is seemingly going to be the new supported path
for Windows builds going forward.

The process of generating the Visual Studio files with CMake was relatively
straightforward, and I got a 32-bit x86 build to go through without errors
(although I haven't tested it with my application yet).

The 64-bit build gets caught up on a few errors. First, all of the
executables fail to link because of unresolved symbol errors for
"_X86TargetMachineModule" and "_X86AsmPrinterForceLink". I can see where
these get set up on the link line in llvm/cmake/modules/LLVMConfig.make
file, and I understand why these are required for this build platform.

Unfortunately, it looks like the VS 64-bit compiler assigns symbol names
differently from the 32-bit compiler, so where /INCLUDE:_foo was the right
thing for 32-bit you seem to need /INCLUDE:foo for 64-bit. Manually editing
the generated .vcproj file for llc got me past this error for now.

The next problem I ran into is that the CMake-generated X86.vcproj project
doesn't pull in the llvm/lib/Target/X86/X86CompilationCallback_Win64.asm
file. I tried manually adding that file to the project. I must have screwed
something up, though, because even though VS claimed to have found a custom
build rule for .asm files, it gives a bunch of errors when trying to run the
assembler. (Is it possible that it is applying the 32-bit assembler to a
64-bit assembly file?)

I may have to try out the old llvm.sln to see whether I can get a working
build out of it... I just wanted to bring these issues up before you close
out the 2.5 release! :)

- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090121/ec721ea9/attachment-0001.html 

From isanbard at gmail.com  Wed Jan 21 18:51:28 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 21 Jan 2009 16:51:28 -0800
Subject: [LLVMdev] Using LLVM as cross-compiler to C
In-Reply-To: <6.0.1.1.2.20090121184018.01d281f0@pop.nadler.com>
References: <6.0.1.1.2.20090121184018.01d281f0@pop.nadler.com>
Message-ID: <16e5fdf90901211651n3693c8e2g5cbbec086b2281f@mail.gmail.com>

On Wed, Jan 21, 2009 at 3:40 PM, Dave Nadler <Dave.Nadler at nadler.com> wrote:
> Hi All - Newbie warning... I am developing for a target that does not have
> a functioning C++ environment, and need to use C++. It was suggested that I
> could use LLVM to compile to C (using llc -march=c), then run the resulting
> C-code through the working C-cross-compilation tools. So, some newbie
> questions:
>
> (1) Is this crazy ?

It depends on you definition of "crazy". It will turn it into C code.
However, you'll still need to link in the libstdc++ library.

> (2) What happens to all the C++ RTL ? Is it statically linked as LLVM code,
> then translated back into C ?
> (3) Where does the LLVM RTL come from - newlib ? glibc ? other ?

LLVM doesn't use RTL. It has its own IR.

> (4) Is it manageable to create a small number of intrinsics to allow access
> to the C runtime functions on the target, or is this difficult ? In the
> mailing list archive I saw some unresolved question with warnings about
> type conversions for someone trying this...
>
I'm not sure I understand your question. The program will have a call
to the C runtime functions (like strtof), and those are compiled into
calls in the assembly language. (Of course, the libc library needs to
be linked in to get the executable.) There are a few C runtime calls
that LLVM handles specially -- like memset, memcpy, etc. But it's not
necessary to have *all* C runtime calls be builtins or intrinsics for
LLVM to handle them.

-bw

From ofv at wanadoo.es  Wed Jan 21 19:25:55 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 22 Jan 2009 02:25:55 +0100
Subject: [LLVMdev] CMake Win64 build status
References: <fdec3f880901211648g4da37d4g7db96f9832fe5647@mail.gmail.com>
Message-ID: <m363k8uo64.fsf@telefonica.net>

Tim Foley <tim.foley.is at gmail.com> writes:

[snip]

> Unfortunately, it looks like the VS 64-bit compiler assigns symbol names
> differently from the 32-bit compiler, so where /INCLUDE:_foo was the right
> thing for 32-bit you seem to need /INCLUDE:foo for 64-bit. Manually editing
> the generated .vcproj file for llc got me past this error for now.

I've committed a tentative fix for this.

> The next problem I ran into is that the CMake-generated X86.vcproj project
> doesn't pull in the llvm/lib/Target/X86/X86CompilationCallback_Win64.asm
> file.

This one requires a bit more work. I need to learn if CMake has some
sort of direct support for assembler. If not, a custom command will
do. But I have no much time for experimenting on my slow Windows
machine, so it may miss the 2.5 deadline.

Patches welcome! :-)

[snip]

> I may have to try out the old llvm.sln to see whether I can get a working
> build out of it... I just wanted to bring these issues up before you close
> out the 2.5 release! :)

Thanks for the feedback!

-- 
Oscar


From haohui.mai at gmail.com  Wed Jan 21 19:26:19 2009
From: haohui.mai at gmail.com (Haohui Mai)
Date: Wed, 21 Jan 2009 19:26:19 -0600
Subject: [LLVMdev] Implementing customized intrinsic
In-Reply-To: <Pine.LNX.4.62.0901211800130.26012@nondot.org>
References: <344BB08B-6862-47C6-92F8-253462B05D4D@uiuc.edu>
	<Pine.LNX.4.62.0901211800130.26012@nondot.org>
Message-ID: <43DE6B88-6D76-4C36-BE61-5F50B5D58792@gmail.com>

Thanks for your reply. Probably I did not explain clearly. Here is an  
example:

call @check(%foo)
%1 = load %foo

Now I want to write optimization only focus on the function call  
@check, and it might have some additional information which does not  
need to  appear at LLVM IR.

So it seems that the annotation intrinsic does not fit the scenario.

Haohui

On Jan 21, 2009, at 8:01 PM, Tanya M. Lattner wrote:

>
> Does the llvm annotation intrinsic not work for what you are trying  
> to do?
>
> http://llvm.org/docs/LangRef.html#int_var_annotation
> http://llvm.org/docs/LangRef.html#int_annotation
>
> -Tanya
>
> On Wed, 21 Jan 2009, Haohui Mai wrote:
>
>> Dear all,
>>
>> Currently I'm working on a project that add various checks into the
>> LLVM bitcode. For example,  I insert function calls before every
>> load / store instructions to guarantee that these instructions are
>> safe. I really want to implement them as LLVM intrinsics or ``special
>> function calls'' so that I am able to leverage the power of things
>> like InstVisitor. However, it seems it is difficult to do it without
>> changing LLVM's source codes, cause
>>
>> i) all constructors of CallInst are private
>> ii) There's no interfaces for implementing customized intrinsics
>> (without changing intrinsics*.td)
>>
>> It is very helpful to mark these checks as special calls (like
>> intrinsics), it would ease the implementation of optimizations since
>> they only work on these special calls, say, I could save some
>> information in the subclass of CallInst.
>>
>> I also notice that the access identifier of CallInst are changed  
>> after
>> LLVM 2.0. I would be appreciated if you guys could explain the
>> rationale behind the changes.
>>
>> Thank you very much.
>>
>> Best,
>>
>> Haohui
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From tonic at nondot.org  Wed Jan 21 19:38:47 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Wed, 21 Jan 2009 17:38:47 -0800 (PST)
Subject: [LLVMdev] Implementing customized intrinsic
In-Reply-To: <43DE6B88-6D76-4C36-BE61-5F50B5D58792@gmail.com>
References: <344BB08B-6862-47C6-92F8-253462B05D4D@uiuc.edu>
	<Pine.LNX.4.62.0901211800130.26012@nondot.org>
	<43DE6B88-6D76-4C36-BE61-5F50B5D58792@gmail.com>
Message-ID: <Pine.LNX.4.62.0901211735100.26277@nondot.org>


> call @check(%foo)
> %1 = load %foo
>
> Now I want to write optimization only focus on the function call
> @check, and it might have some additional information which does not
> need to  appear at LLVM IR.
>
> So it seems that the annotation intrinsic does not fit the scenario.

I still don't understand.

Why not just replace the call to check with a call to the llvm var 
annotation intrinsic and then you can pass anything you want to it. Such 
as your "check" string. Then you write a pass that looks for these. Why 
would that not work? The var annotation is specifically designed to 
annotate local variables with arbitrary strings.

-Tanya



>
> Haohui
>
> On Jan 21, 2009, at 8:01 PM, Tanya M. Lattner wrote:
>
>>
>> Does the llvm annotation intrinsic not work for what you are trying
>> to do?
>>
>> http://llvm.org/docs/LangRef.html#int_var_annotation
>> http://llvm.org/docs/LangRef.html#int_annotation
>>
>> -Tanya
>>
>> On Wed, 21 Jan 2009, Haohui Mai wrote:
>>
>>> Dear all,
>>>
>>> Currently I'm working on a project that add various checks into the
>>> LLVM bitcode. For example,  I insert function calls before every
>>> load / store instructions to guarantee that these instructions are
>>> safe. I really want to implement them as LLVM intrinsics or ``special
>>> function calls'' so that I am able to leverage the power of things
>>> like InstVisitor. However, it seems it is difficult to do it without
>>> changing LLVM's source codes, cause
>>>
>>> i) all constructors of CallInst are private
>>> ii) There's no interfaces for implementing customized intrinsics
>>> (without changing intrinsics*.td)
>>>
>>> It is very helpful to mark these checks as special calls (like
>>> intrinsics), it would ease the implementation of optimizations since
>>> they only work on these special calls, say, I could save some
>>> information in the subclass of CallInst.
>>>
>>> I also notice that the access identifier of CallInst are changed
>>> after
>>> LLVM 2.0. I would be appreciated if you guys could explain the
>>> rationale behind the changes.
>>>
>>> Thank you very much.
>>>
>>> Best,
>>>
>>> Haohui
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From criswell at cs.uiuc.edu  Wed Jan 21 19:54:03 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 21 Jan 2009 19:54:03 -0600
Subject: [LLVMdev] Implementing customized intrinsic
In-Reply-To: <43DE6B88-6D76-4C36-BE61-5F50B5D58792@gmail.com>
References: <344BB08B-6862-47C6-92F8-253462B05D4D@uiuc.edu>	<Pine.LNX.4.62.0901211800130.26012@nondot.org>
	<43DE6B88-6D76-4C36-BE61-5F50B5D58792@gmail.com>
Message-ID: <4977D1BB.8010604@cs.uiuc.edu>

Haohui Mai wrote:
> Thanks for your reply. Probably I did not explain clearly. Here is an  
> example:
>
> call @check(%foo)
> %1 = load %foo
>
> Now I want to write optimization only focus on the function call  
> @check, and it might have some additional information which does not  
> need to  appear at LLVM IR.
>   
Are these the SAFECode run-time checks, or are these some other
instrumentation?  What are the limitations you're running into with
these function calls?  Are other optimization passes not able to
optimize the call instructions because they make conservative
assumptions about the functions being called in the call instruction? 
Is there information that you'd like to associate with the calls that
currently cannot be done in the IR?  Is there information that should be
passed between LLVM passes that you think shouldn't be represented in
the IR?  Or is there some other limitation that you're encountering?

-- John T.

> So it seems that the annotation intrinsic does not fit the scenario.
>
> Haohui
>
> On Jan 21, 2009, at 8:01 PM, Tanya M. Lattner wrote:
>
>   
>> Does the llvm annotation intrinsic not work for what you are trying  
>> to do?
>>
>> http://llvm.org/docs/LangRef.html#int_var_annotation
>> http://llvm.org/docs/LangRef.html#int_annotation
>>
>> -Tanya
>>
>> On Wed, 21 Jan 2009, Haohui Mai wrote:
>>
>>     
>>> Dear all,
>>>
>>> Currently I'm working on a project that add various checks into the
>>> LLVM bitcode. For example,  I insert function calls before every
>>> load / store instructions to guarantee that these instructions are
>>> safe. I really want to implement them as LLVM intrinsics or ``special
>>> function calls'' so that I am able to leverage the power of things
>>> like InstVisitor. However, it seems it is difficult to do it without
>>> changing LLVM's source codes, cause
>>>
>>> i) all constructors of CallInst are private
>>> ii) There's no interfaces for implementing customized intrinsics
>>> (without changing intrinsics*.td)
>>>
>>> It is very helpful to mark these checks as special calls (like
>>> intrinsics), it would ease the implementation of optimizations since
>>> they only work on these special calls, say, I could save some
>>> information in the subclass of CallInst.
>>>
>>> I also notice that the access identifier of CallInst are changed  
>>> after
>>> LLVM 2.0. I would be appreciated if you guys could explain the
>>> rationale behind the changes.
>>>
>>> Thank you very much.
>>>
>>> Best,
>>>
>>> Haohui
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>       
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>     
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From criswell at cs.uiuc.edu  Wed Jan 21 20:03:53 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 21 Jan 2009 20:03:53 -0600
Subject: [LLVMdev] Using LLVM as cross-compiler to C
In-Reply-To: <16e5fdf90901211651n3693c8e2g5cbbec086b2281f@mail.gmail.com>
References: <6.0.1.1.2.20090121184018.01d281f0@pop.nadler.com>
	<16e5fdf90901211651n3693c8e2g5cbbec086b2281f@mail.gmail.com>
Message-ID: <4977D409.9010904@cs.uiuc.edu>

Bill Wendling wrote:
> On Wed, Jan 21, 2009 at 3:40 PM, Dave Nadler <Dave.Nadler at nadler.com> wrote:
>   
>> Hi All - Newbie warning... I am developing for a target that does not have
>> a functioning C++ environment, and need to use C++. It was suggested that I
>> could use LLVM to compile to C (using llc -march=c), then run the resulting
>> C-code through the working C-cross-compilation tools. So, some newbie
>> questions:
>>
>> (1) Is this crazy ?
>>     
>
> It depends on you definition of "crazy". It will turn it into C code.
> However, you'll still need to link in the libstdc++ library.
>   
One additional problem you may have a C header files.  Different
operating systems and C library implementations will implement the same
functions differently, so when cross-compiling, you need to make sure
your compiling against header files that work on your target platform.

>   
>> (2) What happens to all the C++ RTL ? Is it statically linked as LLVM code,
>> then translated back into C ?
>> (3) Where does the LLVM RTL come from - newlib ? glibc ? other ?
>>     
>
> LLVM doesn't use RTL. It has its own IR.
>   
I believe he means the C++ Run-Time Library and not GCC's RTL
Intermediate Representation.

Older versions of llvm-gcc compiled libstdc++ to LLVM bitcode and linked
it statically into the LLVM bitcode for your program.  I am not sure
what newer versions of llvm-gcc do.

I do know that libc functions and other system functions are not
compiled into LLVM bitcode.  They are (as Bill described below) either
converted into LLVM intrinsics (like memcpy) or become calls to external
functions (like printf).  After generation to native code, the program
is linked against the system libraries.

-- John T.

>   
>> (4) Is it manageable to create a small number of intrinsics to allow access
>> to the C runtime functions on the target, or is this difficult ? In the
>> mailing list archive I saw some unresolved question with warnings about
>> type conversions for someone trying this...
>>
>>     
> I'm not sure I understand your question. The program will have a call
> to the C runtime functions (like strtof), and those are compiled into
> calls in the assembly language. (Of course, the libc library needs to
> be linked in to get the executable.) There are a few C runtime calls
> that LLVM handles specially -- like memset, memcpy, etc. But it's not
> necessary to have *all* C runtime calls be builtins or intrinsics for
> LLVM to handle them.
>
> -bw
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From robert.a.zeh at gmail.com  Wed Jan 21 20:46:21 2009
From: robert.a.zeh at gmail.com (Robert Zeh)
Date: Wed, 21 Jan 2009 20:46:21 -0600
Subject: [LLVMdev] Patch to get llvm compiling with the Intel 11.0.066
	compiler
Message-ID: <59A25010-A0BB-4C09-A2A9-E8B8ECE6A45E@gmail.com>

I've been trying to get llvm to compile under windows with the Intel C+ 
+ 11.0.066 compiler without killing the compiler.

I filed a bug report with Intel, and Intel says that their compiler  
has a problem with RecTy and Init being declared with "class" in utils 
\TableGen\TGParser.h but defined with "struct" in utils\TableGen 
\Record.h.

The attached patch changes TGParser.h to use struct.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: intel-patch.diff
Type: application/octet-stream
Size: 386 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090121/f7cdba39/attachment-0001.obj 
-------------- next part --------------


Robert Zeh


From mrs at apple.com  Wed Jan 21 21:29:28 2009
From: mrs at apple.com (Mike Stump)
Date: Wed, 21 Jan 2009 19:29:28 -0800
Subject: [LLVMdev] avoid creating .dir files
In-Reply-To: <E16012CF-DFC2-449C-8DDC-4E5CCF81D511@gmail.com>
References: <3B14683F-547E-49E9-8DFE-BB35FED0D124@apple.com>
	<50140231-8562-4610-A269-449C87B718DB@apple.com>
	<8A51D4F0-05E3-44DD-9620-27DE614D0D37@apple.com>
	<E16012CF-DFC2-449C-8DDC-4E5CCF81D511@gmail.com>
Message-ID: <1CF3788B-AE1A-4F74-B232-00B72D8AB3FF@apple.com>

On Jan 20, 2009, at 12:46 PM, Dan Villiom Podlaski Christiansen wrote:
> One way to solve this is by using an order-only dependancy:

Cool.  That's a good solution, with this, we can avoid the mkdir as  
well.

> Is it possible that I could get you to wait a bit with these changes?

No time like the present.  I've used that incantation, feel free to  
suggest/make improvements.  Also, I only did this for the installation  
directories, as those were the critical ones.

From clattner at apple.com  Wed Jan 21 23:10:44 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 21 Jan 2009 21:10:44 -0800
Subject: [LLVMdev] Patch to get llvm compiling with the Intel
	11.0.066	compiler
In-Reply-To: <59A25010-A0BB-4C09-A2A9-E8B8ECE6A45E@gmail.com>
References: <59A25010-A0BB-4C09-A2A9-E8B8ECE6A45E@gmail.com>
Message-ID: <448748E0-E401-482D-84EF-F35FAEADBE6B@apple.com>


On Jan 21, 2009, at 6:46 PM, Robert Zeh wrote:

> I've been trying to get llvm to compile under windows with the Intel  
> C++ 11.0.066 compiler without killing the compiler.
>
> I filed a bug report with Intel, and Intel says that their compiler  
> has a problem with RecTy and Init being declared with "class" in  
> utils\TableGen\TGParser.h but defined with "struct" in utils\TableGen 
> \Record.h.
>
> The attached patch changes TGParser.h to use struct.

Applied, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090119/072516.html

-Chris

From tonic at nondot.org  Wed Jan 21 23:49:47 2009
From: tonic at nondot.org (Tanya Lattner)
Date: Wed, 21 Jan 2009 21:49:47 -0800
Subject: [LLVMdev] LLVM 2.5 release branch created
Message-ID: <77359581-DB2B-4672-BEBA-88A0F525076B@nondot.org>

LLVMers,

The 2.5 release branch has been created. You may check it out with the  
following commands:
svn co https://llvm.org/svn/llvm-project/llvm/branches/release_25
svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_25
svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_25
Please do not commit anything to the release branch. If you have a  
patch that needs to be merged in, you must get it approved by a code  
owner and forward me the link to the llvm-commits message for your  
patch.
I'll be sending out details for testing the release when the pre- 
release candidate 1 is released (1/25/2009).
Thanks,
Tanya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090121/9f6a1fce/attachment.html 

From matthijs at stdin.nl  Thu Jan 22 02:28:54 2009
From: matthijs at stdin.nl (Matthijs Kooijman)
Date: Thu, 22 Jan 2009 09:28:54 +0100
Subject: [LLVMdev] Leaving LLVM
Message-ID: <20090122082854.GU13463@katherina.student.utwente.nl>

Hi all,

about a month ago, I've started working on my master's thesis. Since I want to
focus on just that work, I've stopped my LLVM work for now. It is unclear
whether I will continue my work after graduation, but it seems unlikely.

I'll still keep track of LLVM from a personal interest (mostly watching the
IRC channel), but I won't have the time to track any mailing lists.

Thanks to all involved for the great product and community that LLVM is and
for the experiences gained during my work!

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090122/d37abac8/attachment.bin 

From baldrick at free.fr  Thu Jan 22 03:13:15 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 22 Jan 2009 10:13:15 +0100
Subject: [LLVMdev] Leaving LLVM
In-Reply-To: <20090122082854.GU13463@katherina.student.utwente.nl>
References: <20090122082854.GU13463@katherina.student.utwente.nl>
Message-ID: <200901221013.16056.baldrick@free.fr>

Hey Matthijs, it was good having you around - happy masters!

Best wishes,

Duncan.

From jay.foad at gmail.com  Thu Jan 22 04:45:15 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Thu, 22 Jan 2009 10:45:15 +0000
Subject: [LLVMdev] cygwin build patch
In-Reply-To: <60719C7E-8E1F-4740-AA4D-8F9CC3AB1B8C@apple.com>
References: <ee2e06e90901190744j47f3b36au5724d9f925d8433a@mail.gmail.com>
	<5CE7EB46-16C0-42FC-9A12-13328B7053AD@apple.com>
	<ee2e06e90901200122y5257d042g91aecec43019d287@mail.gmail.com>
	<DA7138AB-2671-4582-918A-A4D67F19E24D@apple.com>
	<ee2e06e90901210202u3684a41bo4d0817d1b24f0273@mail.gmail.com>
	<60719C7E-8E1F-4740-AA4D-8F9CC3AB1B8C@apple.com>
Message-ID: <ee2e06e90901220245q600a3e91u20965d999b7feca6@mail.gmail.com>

> Thanks Jay! You beat me to it :), applied here:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090119/072479.html

Thanks. Just to confirm, I can now build head of svn (rev 62762)
cleanly on Cygwin with GCC 4.

With GCC 3.4.4 (Cygwin's default) I still have this problem:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-January/019563.html

Thanks,
Jay.

From aph at redhat.com  Thu Jan 22 05:13:47 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 22 Jan 2009 11:13:47 +0000
Subject: [LLVMdev] JIT debug dumps [Was Re: Load from abs address generated
 bad code on LLVM 2.4]
In-Reply-To: <E6B62E1E-70E0-489C-9618-D89F359EAD15@apple.com>
References: <4974A258.1040108@redhat.com>	<99AFFD84-D5A8-4094-8FB9-DDAD8E2AE20E@apple.com>	<4975A318.2040208@redhat.com>	<C9CEA12F-BC24-4995-89AF-80B9517AC0D2@apple.com>	<497711F9.2060904@redhat.com>
	<E6B62E1E-70E0-489C-9618-D89F359EAD15@apple.com>
Message-ID: <497854EB.408@redhat.com>

Chris Lattner wrote:
> On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote:
>>> That should work fine, just use "jit" instead of "x86-emitter" as the
>>> debug type.
>> That's impossible: CurrentDebugType is now private; it appears
>> nowhere in the installed headers.  I can't find any public interface
>> to allow a JIT to set it.
> 
> Ah ok.  I'd suggest doing what llvm-gcc does here, it is a much more  
> stable API:
> 
>    std::vector<const char*> Args;
>    Args.push_back(""); // program name
>    Args.push_back("-debug-only=jit");
>    ...
>    Args.push_back(0);  // Null terminator.
>    cl::ParseCommandLineOptions(Args.size()-1, (char**)&Args[0]);
> 
> This also gives you control over optimizations and codegen options,

Yes, thanks.  It's a slightly weird hack, but it works perfectly.  :-)

"-debug-only=jit" generates just a binary dump, like this:

JIT: Binary code:
JIT: 00000000: 4a04b848 000000ca 048b0000 c320

whereas "-debug-only=x86-emitter" generates this:

%RAX<def> = MOV64ri <ga:poo1>
%EAX<def> = MOV32rm %RAX<kill>, 1, %reg0, 0, Mem:LD(4,4) [poo1 + 0]
RET %EAX<imp-use,kill>

which may be more useful.

Can I put in a request some machine-independent names for the debug
dumps?  It's "x86-emitter", "alpha-emitter", "x86-codegen", and so on.
We'd have to put a big target-dependent switch statement in our code to
enable asm dumps.

Andrew.

From marks at dcs.gla.ac.uk  Thu Jan 22 05:45:43 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Thu, 22 Jan 2009 11:45:43 -0000
Subject: [LLVMdev] Getting address of label in jitted code.
References: <mailman.582.1232027472.945.llvmdev@cs.uiuc.edu>
Message-ID: <58577CAC1C0FB34DAA24FA9DC76613F1029622EA@ex1.ad.dcs.gla.ac.uk>

Hi,

I need to get the address of a label in jitted code.
(This is so that I can insert a jump into the machine code to resume interpretation from compiled code)

I've tried using gcc's address of labels, but llvm just gives meaningless integers, not real addresses.
I've had a look at llvm.dbg.stoppoint, but I don't see where the address actually get stored and the docs are really out of date.

Any guidance on this?

Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2609 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090122/6a8d7485/attachment-0001.bin 

From howarth at bromo.med.uc.edu  Thu Jan 22 07:07:33 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Thu, 22 Jan 2009 08:07:33 -0500
Subject: [LLVMdev] llvm/llvm-gcc4.2 and polyhedron 2005
Message-ID: <20090122130733.GA4742@bromo.med.uc.edu>

  FYI, I can confirm that the llvm/llvm-gcc4.2 2.5
release currently builds the Polyhedron 2005 benchmarks
on i686-apple-darwin9 and the resulting code executes
without errors. Nice.
         Jack

From Ralf.Karrenberg at gmx.de  Thu Jan 22 09:02:12 2009
From: Ralf.Karrenberg at gmx.de (Ralf Karrenberg)
Date: Thu, 22 Jan 2009 16:02:12 +0100
Subject: [LLVMdev] replacing instructions
Message-ID: <49788A74.50406@gmx.de>

Hello everyone,

is there any way to replace an instruction inside LLVM that is more
elegant than creating a new one, replacing uses and deleting the old one
if I only want to modify the type? It is generally not a big deal, but
the issue gets really messy if I am in the middle of iterating over uses
and start deleting some of them...

I hope I could describe my problem well enough ;)

Regards,
Ralf

From criswell at cs.uiuc.edu  Thu Jan 22 09:25:56 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 22 Jan 2009 09:25:56 -0600
Subject: [LLVMdev] replacing instructions
In-Reply-To: <49788A74.50406@gmx.de>
References: <49788A74.50406@gmx.de>
Message-ID: <49789004.6070607@cs.uiuc.edu>

Ralf Karrenberg wrote:
> Hello everyone,
>
> is there any way to replace an instruction inside LLVM that is more
> elegant than creating a new one, replacing uses and deleting the old one
> if I only want to modify the type? It is generally not a big deal, but
> the issue gets really messy if I am in the middle of iterating over uses
> and start deleting some of them...
>   
Yes, the Instruction class has a method for doing this (the method is
technically inherited from the Value class).

Calling the replaceAllUsesWith() method on an Instruction will replace
every use of the old instruction with the new instruction.  As long as
the type generated by the old and new instructions is identical (or
maybe even similar), you shouldn't have any problems.  For example,
replacing an add instruction that adds two i32's with a call instruction
that returns an i32 should be as simple as:

Instruction * OldInst = ... ;
Instruction * NewInst = CallInst::Create (...);
OldInst->replaceAllUsesWith (NewInst);

This sort of code may not work if OldInst and NewInst are not SSA
virtual registers of the same type (for example, if OldInst is a pointer
to an array of i32 and NewInst is a pointer to a structure).  In that
case, not only must the defining instruction be changed, but the
instructions using it must be changed as well.  In that case, you will
need to iterate over the uses of the old instruction and create a new
instruction for each use, making whatever changes to each use are
necessary for your transform to work.

See http://llvm.org/doxygen/classllvm_1_1Value.html for more information
on replaceAllUsesWith().

-- John T.

> I hope I could describe my problem well enough ;)
>
> Regards,
> Ralf
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From gordonhenriksen at me.com  Thu Jan 22 09:28:54 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Thu, 22 Jan 2009 10:28:54 -0500
Subject: [LLVMdev] replacing instructions
In-Reply-To: <49788A74.50406@gmx.de>
References: <49788A74.50406@gmx.de>
Message-ID: <9A55EF8D-1E03-43DA-9305-83C8BC0772B2@me.com>

On 2009-01-22, at 10:02, Ralf Karrenberg wrote:

> is there any way to replace an instruction inside LLVM that is more  
> elegant than creating a new one, replacing uses and deleting the old  
> one if I only want to modify the type? It is generally not a big  
> deal, but the issue gets really messy if I am in the middle of  
> iterating over uses and start deleting some of them...


Hi Ralf,

There is not. LLVM Values are of immutable type. There is a method,  
Value::replaceAllUsesWith(), to do the replacement for you, however.

http://llvm.org/doxygen/classllvm_1_1Value.html#3ab5fc45117b450e8bb04e564cb6e5f2

? Gordon



From Chareos at gmx.de  Thu Jan 22 11:33:22 2009
From: Chareos at gmx.de (Ralf Karrenberg)
Date: Thu, 22 Jan 2009 18:33:22 +0100
Subject: [LLVMdev] replacing instructions
In-Reply-To: <49789004.6070607@cs.uiuc.edu>
References: <49788A74.50406@gmx.de> <49789004.6070607@cs.uiuc.edu>
Message-ID: <4978ADE2.7010908@gmx.de>

John Criswell wrote:
> Yes, the Instruction class has a method for doing this (the method is
> technically inherited from the Value class).
>
> Calling the replaceAllUsesWith() method on an Instruction will replace
> every use of the old instruction with the new instruction.  As long as
> the type generated by the old and new instructions is identical (or
> maybe even similar), you shouldn't have any problems.  For example,
> replacing an add instruction that adds two i32's with a call instruction
> that returns an i32 should be as simple as:
>
> Instruction * OldInst = ... ;
> Instruction * NewInst = CallInst::Create (...);
> OldInst->replaceAllUsesWith (NewInst);
>
> This sort of code may not work if OldInst and NewInst are not SSA
> virtual registers of the same type (for example, if OldInst is a pointer
> to an array of i32 and NewInst is a pointer to a structure).  In that
> case, not only must the defining instruction be changed, but the
> instructions using it must be changed as well.  In that case, you will
> need to iterate over the uses of the old instruction and create a new
> instruction for each use, making whatever changes to each use are
> necessary for your transform to work.
>
>   
My problem is exactly that I replace instructions by others of different
type.
I currently do this the following way (in short):

Instruction* X;
for (Instruction::use_iterator U = X->use_begin(); U != X->use_end(); ) {
replaceInstruction(cast<Instruction>(I++));
}

void replaceInstruction(Instruction* I) {
Instruction* newI = generateNewInstructionOfDifferentType(I);
insertNewInstructionBeforeOld(newI, I);
I->uncheckedReplaceAllUsesWith(newInstr);
I->eraseFromParent();
}

that works, but it brings a lot of headache if replaceInstruction() is
recursive or does other nasty things on other instructions that might
also be uses - this can be as easy as a "%Y = mul <type> %X, %X" where I
already have to insert quite some ugly code to prevent the iteration
from segfaulting because Y is referenced twice in the use-list of X.
Modifying the old instruction itself would be much easier...

Cheers,
Ralf

From isanbard at gmail.com  Thu Jan 22 13:29:18 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Thu, 22 Jan 2009 11:29:18 -0800
Subject: [LLVMdev] Leaving LLVM
In-Reply-To: <20090122082854.GU13463@katherina.student.utwente.nl>
References: <20090122082854.GU13463@katherina.student.utwente.nl>
Message-ID: <16e5fdf90901221129i39d6c528o3289a91bd454dcd7@mail.gmail.com>

Hi Matthijs,

Thanks for your work on LLVM! It was very valuable. Good luck on you
masters thesis and your future endeavors. You're welcome back at any
time. :-)

-bw

On Thu, Jan 22, 2009 at 12:28 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote:
> Hi all,
>
> about a month ago, I've started working on my master's thesis. Since I want to
> focus on just that work, I've stopped my LLVM work for now. It is unclear
> whether I will continue my work after graduation, but it seems unlikely.
>
> I'll still keep track of LLVM from a personal interest (mostly watching the
> IRC channel), but I won't have the time to track any mailing lists.
>
> Thanks to all involved for the great product and community that LLVM is and
> for the experiences gained during my work!
>
> Gr.
>
> Matthijs
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJeC5Gz0nQ5oovr7wRAu/UAKCDj/eDHztmwzcnnxR630RBbse1CgCeLQ3n
> xtSel223V+fmJStY3N/Z4/A=
> =GjEY
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

From mburke at ea.com  Thu Jan 22 17:30:39 2009
From: mburke at ea.com (Burke, Max)
Date: Thu, 22 Jan 2009 15:30:39 -0800
Subject: [LLVMdev] Minor AsmPrinter bug fix
Message-ID: <B89209C560BCAD438740FD20E3EF4D901A0C5372@eac-mail1.eac.ad.ea.com>

The Microsoft CRT's implementation of isprint() has an internal assert
that the unsigned value passed in is in [0,256) but unprintable chars
passed in are sign extended to values that falsely trigger this assert.

--- c:\usr\src\llvm-svn\lib\CodeGen\AsmPrinter\AsmPrinter.cpp  Tue Jan
20 10:30:42 2009
+++ c:\usr\src\llvm-integrate\lib\CodeGen\AsmPrinter\AsmPrinter.cpp
Thu Jan 22 15:19:47 2009

@@ -681,7 +681,7 @@
     O << "\\\"";
   } else if (C == '\\') {
     O << "\\\\";
-  } else if (isprint(C)) {
+  } else if (isprint((unsigned char)C)) {
     O << C;
   } else {
     switch(C) {



From clattner at apple.com  Thu Jan 22 17:39:30 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 22 Jan 2009 15:39:30 -0800
Subject: [LLVMdev] Minor AsmPrinter bug fix
In-Reply-To: <B89209C560BCAD438740FD20E3EF4D901A0C5372@eac-mail1.eac.ad.ea.com>
References: <B89209C560BCAD438740FD20E3EF4D901A0C5372@eac-mail1.eac.ad.ea.com>
Message-ID: <4FFD787E-B641-475D-A38D-E722CC354213@apple.com>


On Jan 22, 2009, at 3:30 PM, Burke, Max wrote:

> The Microsoft CRT's implementation of isprint() has an internal assert
> that the unsigned value passed in is in [0,256) but unprintable chars
> passed in are sign extended to values that falsely trigger this  
> assert.
>
> --- c:\usr\src\llvm-svn\lib\CodeGen\AsmPrinter\AsmPrinter.cpp  Tue Jan
> 20 10:30:42 2009
> +++ c:\usr\src\llvm-integrate\lib\CodeGen\AsmPrinter\AsmPrinter.cpp
> Thu Jan 22 15:19:47 2009
>
> @@ -681,7 +681,7 @@
>     O << "\\\"";
>   } else if (C == '\\') {
>     O << "\\\\";
> -  } else if (isprint(C)) {
> +  } else if (isprint((unsigned char)C)) {
>     O << C;
>   } else {

Applied, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090119/072562.html

-Chris


From gohman at apple.com  Thu Jan 22 18:10:56 2009
From: gohman at apple.com (Dan Gohman)
Date: Thu, 22 Jan 2009 16:10:56 -0800
Subject: [LLVMdev] HazardRecognizer and RegisterAllocation
In-Reply-To: <200901201622.12875.dag@cray.com>
References: <alpine.LRH.1.10.0901191705110.15327@pub6.ifh.de>
	<200901191906.06656.dag@cray.com>
	<FA3EBC4E-5976-4677-8CC0-55AD2D625E1F@apple.com>
	<200901201622.12875.dag@cray.com>
Message-ID: <1FD7BEB3-7FA7-41CE-80C0-414EB2ABEF39@apple.com>


On Jan 20, 2009, at 2:22 PM, David Greene wrote:
>
>>> I don't think it's sufficient to just preserve the information we
>>> had from
>>> Instructions.  Codegen might introduce new memory operations after
>>> lowering
>>> (spilling, for example).  Some of these might be easily analyzable
>>> (spills)
>>> but others might not be.
>>
>> This is where PseudoSourceValues come in. There are pseudo-values
>> representing the stack, constants area, GOT, and other memory
>> locations that aren't represented at the LLVM-IR level.
>
> Ok, that's good.  But what happens if some codegen pass deletes a  
> memory
> instruction (or a Value or whatever) and recreates it elsewhere.   
> Presumably
> the dependence information would be lost.  How would we re-generate  
> it.


If a pass must re-generate an instruction, it's going to have to
be responsible for keeping track of the MachineMemOperand(s) that
the re-generated instruction will need.

Also, the PseudoSourceValue objects are singletons, so if the
code generating the memory reference knows what memory it's
talking about, it can easily look up the appropriate
PseudoSourceValue for it.

Dan


From gohman at apple.com  Thu Jan 22 18:13:19 2009
From: gohman at apple.com (Dan Gohman)
Date: Thu, 22 Jan 2009 16:13:19 -0800
Subject: [LLVMdev] Getting address of label in jitted code.
In-Reply-To: <58577CAC1C0FB34DAA24FA9DC76613F1029622EA@ex1.ad.dcs.gla.ac.uk>
References: <mailman.582.1232027472.945.llvmdev@cs.uiuc.edu>
	<58577CAC1C0FB34DAA24FA9DC76613F1029622EA@ex1.ad.dcs.gla.ac.uk>
Message-ID: <06EC28D7-412E-44C7-8E60-EA0CBF6C956F@apple.com>


On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote:

> Hi,
>
> I need to get the address of a label in jitted code.
> (This is so that I can insert a jump into the machine code to resume  
> interpretation from compiled code)

Hello,

What's your plan for restoring register and memory state?

Dan


From howarth at bromo.med.uc.edu  Thu Jan 22 19:06:38 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Thu, 22 Jan 2009 20:06:38 -0500
Subject: [LLVMdev] llvm/llvm-gcc-4.2 and xplor-nih
Message-ID: <20090123010638.GA10825@bromo.med.uc.edu>

   I am happy to report that current llvm/llvm-gcc-4.2 svn
builds all of xplor-nih (a complex mix of c, c++ and fortran)
with  -O3 -fPIC -msse4 -ffast-math. A single fortran file
exposes PR3376 which is triggered by -O3 -ffinite-math-only.
The resulting build of xplor-nih completely passes its testsuite
and compares very well to the same build against gcc trunk for
gcc 4.4 in terms of execution time.

                     gcc 4.4            llvm-gcc-4.2 svn
xplo                68.5205s            64.7649s
xplor-python       152.9726s           154.7344s
xplor-tcl           10.5005s            10.7039s

FYI.
           Jack

From npjohnso at cs.princeton.edu  Thu Jan 22 19:15:20 2009
From: npjohnso at cs.princeton.edu (Nick Johnson)
Date: Thu, 22 Jan 2009 20:15:20 -0500
Subject: [LLVMdev] Possible bug in PassManager - Higher pass requires lower
	pass
Message-ID: <d85094510901221715l74e4fd9fh8ddbe8b5580ec959@mail.gmail.com>

Hello all,

I've noticed that whenever a ``higher'' pass requires a ``lower''
pass, an assert *always* fails in the pass manager.  I believe the
correct behavior is to not schedule the lower pass, but instead run it
when the higher pass calls getAnalysis<>().  Consider, for instance,
this test case:

#include "llvm/Pass.h"
#include "llvm/Analysis/LoopPass.h"
using namespace llvm;
namespace bugs {
  // First, the ``lower pass''
  class LowerPass : public LoopPass {
    public:
      static char       ID;
      LowerPass() : LoopPass(&ID) {}
      virtual ~LowerPass() {}
      virtual void getAnalysisUsage(AnalysisUsage &use) const {
        use.setPreservesAll();
      }
      virtual bool runOnLoop(Loop *l, LPPassManager &lpm) {
        return false;
      }
  };
  char LowerPass::ID = 0;
  RegisterPass<LowerPass> x("lower", "Lower Pass");

  // Next, the ``higher pass''
  class HigherPass : public FunctionPass {
    public:
      static char ID;
      HigherPass() : FunctionPass(&ID) {}
      virtual ~HigherPass() {}
      virtual void getAnalysisUsage(AnalysisUsage &use) const {
        use.addRequired<LowerPass>();
      }
      virtual bool runOnFunction(Function &fcn) {
        return false;
      }
  };
  char HigherPass::ID = 0;
  RegisterPass<HigherPass> y("higher", "Higher Pass");
}


I compile this to a shared object, and then run it:

$ opt foo.bc -o bar.bc -load libBug.so -higher
Unable to schedule 'Lower Pass' required by 'Higher Pass'
opt: /media/secure/home/nick/classes/liberty/llvm/llvm/lib/VMCore/PassManager.cpp:1077:
virtual void llvm::PMDataManager::addLowerLevelRequiredPass(llvm::Pass*,
llvm::Pass*): Assertion `0 && "Unable to schedule pass"' failed.
0   opt       0x08721883
1   opt       0x08721be0
2   opt       0xb7f7e420
3   libc.so.6 0xb7d3bfb9 abort + 265
4   libc.so.6 0xb7d33fbf __assert_fail + 271
5   opt       0x086ab6a0
llvm::PMDataManager::preserveHigherLevelAnalysis(llvm::Pass*) + 0
6   opt       0x086acfeb llvm::PMDataManager::add(llvm::Pass*, bool) + 815
7   opt       0x086ad39f
llvm::FunctionPass::assignPassManager(llvm::PMStack&,
llvm::PassManagerType) + 461
8   opt       0x086b6f83
llvm::PassManagerImpl::addTopLevelPass(llvm::Pass*) + 237
9   opt       0x086abfc5
llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 499
10  opt       0x086b70a6 llvm::PassManagerImpl::add(llvm::Pass*) + 30
11  opt       0x086abfe7 llvm::PassManager::add(llvm::Pass*) + 27
12  opt       0x083c9b0e (anonymous
namespace)::addPass(llvm::PassManager&, llvm::Pass*) + 32
13  opt       0x083c16ce main + 3236
14  libc.so.6 0xb7d26ea8 __libc_start_main + 200
15  opt       0x083b1f51 __gxx_personality_v0 + 353
Aborted


I observe this bug on the head revision of llvm.  Your input would be
appreciated,
-- 
Nick Johnson

From Sanjiv.Gupta at microchip.com  Thu Jan 22 20:24:21 2009
From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com)
Date: Thu, 22 Jan 2009 19:24:21 -0700
Subject: [LLVMdev] Leaving LLVM
In-Reply-To: <20090122082854.GU13463@katherina.student.utwente.nl>
References: <20090122082854.GU13463@katherina.student.utwente.nl>
Message-ID: <F536B7C316F9474E9F7091239725AC9A01D77299@CHN-CL-MAIL01.mchp-main.com>

Hey Matthijs,
Have a happy time doing masters and all the best for your future
endeavors.

Good luck,
Sanjiv

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On
> Behalf Of Matthijs Kooijman
> Sent: Thursday, January 22, 2009 1:59 PM
> To: LLVM Developers Mailing List
> Subject: [LLVMdev] Leaving LLVM
> 
> Hi all,
> 
> about a month ago, I've started working on my master's thesis. Since I
> want to
> focus on just that work, I've stopped my LLVM work for now. It is
unclear
> whether I will continue my work after graduation, but it seems
unlikely.
> 
> I'll still keep track of LLVM from a personal interest (mostly
watching
> the
> IRC channel), but I won't have the time to track any mailing lists.
> 
> Thanks to all involved for the great product and community that LLVM
is
> and
> for the experiences gained during my work!
> 
> Gr.
> 
> Matthijs


From techvd at gmail.com  Thu Jan 22 20:43:20 2009
From: techvd at gmail.com (Vijay D)
Date: Thu, 22 Jan 2009 18:43:20 -0800
Subject: [LLVMdev] Problem invoking win32 api calls
Message-ID: <5617ccb50901221843u64f0404fq579fa4dbdf4b3d1f@mail.gmail.com>

Hi,

I use the kaliedoscope tutorial to do some experiments. I'm trying to define
a few win32 functions as extern and execute them from the toy language.
Functions that take no arguments execute fine (for example, GetLastError()).
However, calling functions that do take arguments (for example,
SetLastError(unsigned int)) always crash the application due to some kind of
stack corruption (Unhandled exception at 0x00000000: 0xC0000005: Access
violation reading location 0x00000000.)

I'm actually using the CallingConv::X86_StdCall calling convention for these
external functions (F->setCallingConv(CallingConv::X86_StdCall);) and that
doesn't resolve the issue.

Any insight is appreciated. Please let me know if you need more details.

Thanks,
Vijay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090122/58e9de40/attachment-0001.html 

From eli.friedman at gmail.com  Thu Jan 22 20:52:22 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 22 Jan 2009 18:52:22 -0800
Subject: [LLVMdev] Problem invoking win32 api calls
In-Reply-To: <5617ccb50901221843u64f0404fq579fa4dbdf4b3d1f@mail.gmail.com>
References: <5617ccb50901221843u64f0404fq579fa4dbdf4b3d1f@mail.gmail.com>
Message-ID: <f5aa3e9b0901221852j6c04b055x12522243b905aa1d@mail.gmail.com>

On Thu, Jan 22, 2009 at 6:43 PM, Vijay D <techvd at gmail.com> wrote:
> Hi,
>
> I use the kaliedoscope tutorial to do some experiments. I'm trying to define
> a few win32 functions as extern and execute them from the toy language.
> Functions that take no arguments execute fine (for example, GetLastError()).
> However, calling functions that do take arguments (for example,
> SetLastError(unsigned int)) always crash the application due to some kind of
> stack corruption (Unhandled exception at 0x00000000: 0xC0000005: Access
> violation reading location 0x00000000.)

Sounds like a calling convention issue.

> I'm actually using the CallingConv::X86_StdCall calling convention for these
> external functions (F->setCallingConv(CallingConv::X86_StdCall);) and that
> doesn't resolve the issue.

Note that you have to set the calling convention on the call.

-Eli

From howarth at bromo.med.uc.edu  Thu Jan 22 23:48:51 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 23 Jan 2009 00:48:51 -0500
Subject: [LLVMdev] llvm-gcc-4.2 vs gcc 4.4
Message-ID: <20090123054851.GA11847@bromo.med.uc.edu>

In order to see how llvm-gcc-4.2 svn performs in code generation
compared to the upcoming gcc 4.4, I ran the Polyhedron 2005
benchmarks on a MacPro with the -ffast-math -funroll-loops -msse3 -O3
optimization flags for both compilers. The results are summarized
below.

              Ave Run (secs)      Ave Run (secs)     llvm-gcc-4.2/
Benchmark     llvm-gcc-4.2 svn    gcc trunk          gcc trunk
ac            15.01               12.65              1.187
aermod        15.96               25.52              0.625
air           8.25                7.10               1.162
capaccita     51.41               49.56              1.037
channel       3.32                1.81               1.834  
doduc         34.06               35.28              0.965
fatigue       12.80               10.13              1.264 
gas_dyn       16.45               7.63               2.156
induct        26.70               14.88              1.794
linpk         15.40               15.50              0.994
mdbx          14.19               12.36              1.148
nf            29.01               25.50              1.138
protein       45.03               39.12              1.151 
rnflow        39.67               30.68              1.293
test_fpu      14.03               10.50              1.336
tfft          2.19                2.08               1.053



From evan.cheng at apple.com  Fri Jan 23 00:15:33 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Thu, 22 Jan 2009 22:15:33 -0800
Subject: [LLVMdev] JIT debug dumps [Was Re: Load from abs address
 generated bad code on LLVM 2.4]
In-Reply-To: <497854EB.408@redhat.com>
References: <4974A258.1040108@redhat.com>
	<99AFFD84-D5A8-4094-8FB9-DDAD8E2AE20E@apple.com>
	<4975A318.2040208@redhat.com>
	<C9CEA12F-BC24-4995-89AF-80B9517AC0D2@apple.com>
	<497711F9.2060904@redhat.com>
	<E6B62E1E-70E0-489C-9618-D89F359EAD15@apple.com>
	<497854EB.408@redhat.com>
Message-ID: <264E128E-2927-4C1E-87E2-00C91DBF309F@apple.com>



On Jan 22, 2009, at 3:13 AM, Andrew Haley <aph at redhat.com> wrote:

> Chris Lattner wrote:
>> On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote:
>>>> That should work fine, just use "jit" instead of "x86-emitter" as  
>>>> the
>>>> debug type.
>>> That's impossible: CurrentDebugType is now private; it appears
>>> nowhere in the installed headers.  I can't find any public interface
>>> to allow a JIT to set it.
>>
>> Ah ok.  I'd suggest doing what llvm-gcc does here, it is a much more
>> stable API:
>>
>>   std::vector<const char*> Args;
>>   Args.push_back(""); // program name
>>   Args.push_back("-debug-only=jit");
>>   ...
>>   Args.push_back(0);  // Null terminator.
>>   cl::ParseCommandLineOptions(Args.size()-1, (char**)&Args[0]);
>>
>> This also gives you control over optimizations and codegen options,
>
> Yes, thanks.  It's a slightly weird hack, but it works perfectly.  :-)
>
> "-debug-only=jit" generates just a binary dump, like this:
>
> JIT: Binary code:
> JIT: 00000000: 4a04b848 000000ca 048b0000 c320
>
> whereas "-debug-only=x86-emitter" generates this:

This has been changed in tot. -debug-only=jit will dump both target  
independent and target specific debug info.

Evan
>
>
> %RAX<def> = MOV64ri <ga:poo1>
> %EAX<def> = MOV32rm %RAX<kill>, 1, %reg0, 0, Mem:LD(4,4) [poo1 + 0]
> RET %EAX<imp-use,kill>
>
> which may be more useful.
>
> Can I put in a request some machine-independent names for the debug
> dumps?  It's "x86-emitter", "alpha-emitter", "x86-codegen", and so on.
> We'd have to put a big target-dependent switch statement in our code  
> to
> enable asm dumps.
>
> Andrew.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From clattner at apple.com  Fri Jan 23 00:25:17 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 22 Jan 2009 22:25:17 -0800
Subject: [LLVMdev] llvm-gcc-4.2 vs gcc 4.4
In-Reply-To: <20090123054851.GA11847@bromo.med.uc.edu>
References: <20090123054851.GA11847@bromo.med.uc.edu>
Message-ID: <144A1B46-8D78-4537-8745-2357574DF434@apple.com>


On Jan 22, 2009, at 9:48 PM, Jack Howarth wrote:

> In order to see how llvm-gcc-4.2 svn performs in code generation
> compared to the upcoming gcc 4.4, I ran the Polyhedron 2005
> benchmarks on a MacPro with the -ffast-math -funroll-loops -msse3 -O3
> optimization flags for both compilers. The results are summarized
> below.

Hi Jack,

Out of curiousity, how does llvm-gcc 4.2 compare against gcc 4.2?  I  
know that a lot of improvement went into the fortran frontend and  
runtime library between 4.2 -> 4.4, and it would be nice to isolate  
effects of just the optimizer/backend.

-Chris

>
>
>              Ave Run (secs)      Ave Run (secs)     llvm-gcc-4.2/
> Benchmark     llvm-gcc-4.2 svn    gcc trunk          gcc trunk
> ac            15.01               12.65              1.187
> aermod        15.96               25.52              0.625
> air           8.25                7.10               1.162
> capaccita     51.41               49.56              1.037
> channel       3.32                1.81               1.834
> doduc         34.06               35.28              0.965
> fatigue       12.80               10.13              1.264
> gas_dyn       16.45               7.63               2.156
> induct        26.70               14.88              1.794
> linpk         15.40               15.50              0.994
> mdbx          14.19               12.36              1.148
> nf            29.01               25.50              1.138
> protein       45.03               39.12              1.151
> rnflow        39.67               30.68              1.293
> test_fpu      14.03               10.50              1.336
> tfft          2.19                2.08               1.053
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From baldrick at free.fr  Fri Jan 23 03:14:20 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 23 Jan 2009 10:14:20 +0100
Subject: [LLVMdev] PATCH: llvm-top git support and out-of-tree building
	for llvm
In-Reply-To: <200901190207.46108.michael@schuerig.de>
References: <200901190207.46108.michael@schuerig.de>
Message-ID: <200901231014.20321.baldrick@free.fr>

Hi Michael, I've applied these (with some tweaks).
Thanks for working on this!

Ciao,

Duncan.

From michael at schuerig.de  Fri Jan 23 04:51:53 2009
From: michael at schuerig.de (Michael Schuerig)
Date: Fri, 23 Jan 2009 11:51:53 +0100
Subject: [LLVMdev] Reading recommendations?
Message-ID: <200901231151.53411.michael@schuerig.de>

[I sent this already two days ago, but apparently the message didn't get 
through. It is not in the archive either.]

I've read through the Programmer's Manual, Language Reference, and 
Kaleidoscope Tutorial, still I'm struggling to get started hands-on 
with LLVM. This may just be a passing phase and I'm in no hurry, so I'd 
like to take the time to read up some more on the use and inner 
workings of LLVM.

My interest is mainly in using LLVM as the code generator for dynamic 
and/or functional languages. Are any of the LLVM-related[1] 
publications or other papers/books particularly recommended for this 
purpose?

Incidentally, the recent "Criticism of garbage collection [...]" thread 
brought Pure[2] to my attention and I'll surely have a look at the 
code.

Michael

[1] http://llvm.org/pubs/
[2] http://pure-lang.googlecode.com/
-- 
Michael Schuerig
mailto:michael at schuerig.de
http://www.schuerig.de/michael/

From marks at dcs.gla.ac.uk  Fri Jan 23 05:23:07 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Fri, 23 Jan 2009 11:23:07 +0000
Subject: [LLVMdev] Getting address of label in jitted code
In-Reply-To: <mailman.648.1232678602.20833.llvmdev@cs.uiuc.edu>
References: <mailman.648.1232678602.20833.llvmdev@cs.uiuc.edu>
Message-ID: <4979A89B.9000301@dcs.gla.ac.uk>

Dan,

> 
> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote:
> 
>> Hi,
>>
>> I need to get the address of a label in jitted code.
>> (This is so that I can insert a jump into the machine code to resume  
>> interpretation from compiled code)
> 
> Hello,
> 
> What's your plan for restoring register and memory state?

Put everything in memory at the yield point,
(its for x86 only at the moment).
Not super efficient, but should work.

So how do I get the address? ;)

Cheers,
Mark.

From g.mondada at etel.ch  Fri Jan 23 05:28:55 2009
From: g.mondada at etel.ch (Mondada Gabriele)
Date: Fri, 23 Jan 2009 12:28:55 +0100
Subject: [LLVMdev] Can TargetInstrInfo::storeRegToStackSlot use temp/virtual
	regs?
In-Reply-To: <200901231014.20321.baldrick@free.fr>
References: <200901190207.46108.michael@schuerig.de>
	<200901231014.20321.baldrick@free.fr>
Message-ID: <4EA20108F62E0346A80AFB03445370F205D798DD@de01ex08.GLOBAL.JHCN.NET>

Hi,
I'm implementing storeRegToStackSlot() and, in order to store some specific registers (floating point regs and address regs) I've to copy them to more standard regs and copy these last ones to the slot.
I tried to generate instructions that use physical registers, but by doing that I overwrote registers already assigned by the register allocator.
Is it possible to use virtual registers in the instructions generated by storeRegToStackSlot()? 
This function is called by the register allocator. So, if it needs to store regs on a slot, this means that there is no more registers available. So, I cannot believe that it is able to allocate new virtual registers generated by storeRegToStackSlot().
What is the good way to implement this ?
Thanks a lot
Gab



From aph at redhat.com  Fri Jan 23 06:43:51 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 23 Jan 2009 12:43:51 +0000
Subject: [LLVMdev] Load from abs address generated bad code on LLVM 2.4
In-Reply-To: <E6B62E1E-70E0-489C-9618-D89F359EAD15@apple.com>
References: <4974A258.1040108@redhat.com>	<99AFFD84-D5A8-4094-8FB9-DDAD8E2AE20E@apple.com>	<4975A318.2040208@redhat.com>	<C9CEA12F-BC24-4995-89AF-80B9517AC0D2@apple.com>	<497711F9.2060904@redhat.com>
	<E6B62E1E-70E0-489C-9618-D89F359EAD15@apple.com>
Message-ID: <4979BB87.9080305@redhat.com>

Chris Lattner wrote:
> On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote:
>>> That should work fine, just use "jit" instead of "x86-emitter" as the
>>> debug type.
>> That's impossible: CurrentDebugType is now private; it appears
>> nowhere in the installed headers.  I can't find any public interface
>> to allow a JIT to set it.
> 
> Ah ok.  I'd suggest doing what llvm-gcc does here, it is a much more  
> stable API:
> 
>    std::vector<const char*> Args;
>    Args.push_back(""); // program name
>    Args.push_back("-debug-only=jit");
>    ...
>    Args.push_back(0);  // Null terminator.
>    cl::ParseCommandLineOptions(Args.size()-1, (char**)&Args[0]);
> 
> This also gives you control over optimizations and codegen options,

Sadly, that doesn't work either.  Well, it works once, but then you
can't change it back.  We need something more like

--- ./lib/Support/Debug.cpp~    2009-01-23 12:15:27.000000000 +0000
+++ lib/Support/Debug.cpp       2009-01-23 12:15:53.000000000 +0000
@@ -48,7 +48,7 @@
   static cl::opt<DebugOnlyOpt, true, cl::parser<std::string> >
   DebugOnly("debug-only", cl::desc("Enable a specific type of debug output"),
             cl::Hidden, cl::value_desc("debug string"),
-            cl::location(DebugOnlyOptLoc), cl::ValueRequired);
+            cl::location(DebugOnlyOptLoc), cl::ValueRequired, cl::ZeroOrMore);
 #endif
 }


to allow it to be dynamically used by a JIT.  Of course, with a large program
being JITted it's really important to be able just to use debugging exactly
where you need it.

Andrew.

From romix.llvm at googlemail.com  Fri Jan 23 06:51:38 2009
From: romix.llvm at googlemail.com (Roman Levenstein)
Date: Fri, 23 Jan 2009 13:51:38 +0100
Subject: [LLVMdev] Small problem in BitVector.h
Message-ID: <e50173bd0901230451o7dcc7b39o6174e4ae7ab1900@mail.gmail.com>

Hi,

Doing some profiling of llc, I noticed that some bitvector operations
took longer than usual. Then I noticed that too many copies of
BitVector obejcts are created, even when such operations like &=, ^=,
|= are performed on those bit vectors.

I looked at the BitVector ADT implementation in BitVector.h and
figured out that all assignment operations (except the usual
assignment operator) return a copy of the bit vector, instead of a
reference!
I guess it was just overlooked.

Below is the patch to fix it. Is it OK to commit?

- Roman


Index: BitVector.h
===================================================================
--- BitVector.h (revision 62258)
+++ BitVector.h (working copy)
@@ -286,7 +286,7 @@
   }

   // Intersection, union, disjoint union.
-  BitVector operator&=(const BitVector &RHS) {
+  BitVector &operator&=(const BitVector &RHS) {
     unsigned ThisWords = NumBitWords(size());
     unsigned RHSWords  = NumBitWords(RHS.size());
     unsigned i;
@@ -302,14 +302,14 @@
     return *this;
   }

-  BitVector operator|=(const BitVector &RHS) {
+  BitVector &operator|=(const BitVector &RHS) {
     assert(Size == RHS.Size && "Illegal operation!");
     for (unsigned i = 0; i < NumBitWords(size()); ++i)
       Bits[i] |= RHS.Bits[i];
     return *this;
   }

-  BitVector operator^=(const BitVector &RHS) {
+  BitVector &operator^=(const BitVector &RHS) {
     assert(Size == RHS.Size && "Illegal operation!");
     for (unsigned i = 0; i < NumBitWords(size()); ++i)
       Bits[i] ^= RHS.Bits[i];

From ggreif at gmail.com  Fri Jan 23 08:43:10 2009
From: ggreif at gmail.com (heisenbug)
Date: Fri, 23 Jan 2009 06:43:10 -0800 (PST)
Subject: [LLVMdev] Small problem in BitVector.h
In-Reply-To: <e50173bd0901230451o7dcc7b39o6174e4ae7ab1900@mail.gmail.com>
References: <e50173bd0901230451o7dcc7b39o6174e4ae7ab1900@mail.gmail.com>
Message-ID: <bcf95b5c-b2f6-4623-b588-dc2127cb99ef@l33g2000pri.googlegroups.com>

On Jan 23, 1:51?pm, Roman Levenstein <romix.l... at googlemail.com>
wrote:
> Hi,
>
> Doing some profiling of llc, I noticed that some bitvector operations
> took longer than usual. Then I noticed that too many copies of
> BitVector obejcts are created, even when such operations like &=, ^=,
> |= are performed on those bit vectors.
>
> I looked at the BitVector ADT implementation in BitVector.h and
> figured out that all assignment operations (except the usual
> assignment operator) return a copy of the bit vector, instead of a
> reference!
> I guess it was just overlooked.
>
> Below is the patch to fix it. Is it OK to commit?

Yes. Please note in the commit message that the old
semantics probably did not meet the expectations.
With your patch, chained assignments happen to the right
object.

A very good catch, and a nice demonstration of how
C++'s performance characteristics can be spoiled
by small bugs like these.

Cheers,

    Gabor


>
> - Roman
>
> Index: BitVector.h
> ===================================================================
> --- BitVector.h (revision 62258)
> +++ BitVector.h (working copy)
> @@ -286,7 +286,7 @@
> ? ?}
>
> ? ?// Intersection, union, disjoint union.
> - ?BitVector operator&=(const BitVector &RHS) {
> + ?BitVector &operator&=(const BitVector &RHS) {
> ? ? ?unsigned ThisWords = NumBitWords(size());
> ? ? ?unsigned RHSWords ?= NumBitWords(RHS.size());
> ? ? ?unsigned i;
> @@ -302,14 +302,14 @@
> ? ? ?return *this;
> ? ?}
>
> - ?BitVector operator|=(const BitVector &RHS) {
> + ?BitVector &operator|=(const BitVector &RHS) {
> ? ? ?assert(Size == RHS.Size && "Illegal operation!");
> ? ? ?for (unsigned i = 0; i < NumBitWords(size()); ++i)
> ? ? ? ?Bits[i] |= RHS.Bits[i];
> ? ? ?return *this;
> ? ?}
>
> - ?BitVector operator^=(const BitVector &RHS) {
> + ?BitVector &operator^=(const BitVector &RHS) {
> ? ? ?assert(Size == RHS.Size && "Illegal operation!");
> ? ? ?for (unsigned i = 0; i < NumBitWords(size()); ++i)
> ? ? ? ?Bits[i] ^= RHS.Bits[i];
> _______________________________________________
> LLVM Developers mailing list
> LLVM... at cs.uiuc.edu ? ? ? ?http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From Dave.Nadler at nadler.com  Fri Jan 23 09:37:02 2009
From: Dave.Nadler at nadler.com (Dave Nadler)
Date: Fri, 23 Jan 2009 10:37:02 -0500
Subject: [LLVMdev] Using LLVM as cross-compiler to C
In-Reply-To: <4977D409.9010904@cs.uiuc.edu>
References: <6.0.1.1.2.20090121184018.01d281f0@pop.nadler.com>
	<16e5fdf90901211651n3693c8e2g5cbbec086b2281f@mail.gmail.com>
	<4977D409.9010904@cs.uiuc.edu>
Message-ID: <6.0.1.1.2.20090123095328.01d6bdb0@pop.nadler.com>

Thanks John and Bill for your feedback.
A bit more detail below...
Thanks again,
Best Regards, Dave

At 09:03 PM 1/21/2009, John Criswell wrote:
>Bill Wendling wrote:
> > On Wed, Jan 21, 2009 at 3:40 PM, Dave Nadler <Dave.Nadler at nadler.com> 
> wrote:
> >
> >> Hi All - Newbie warning... I am developing for a target that does not have
> >> a functioning C++ environment, and need to use C++. It was suggested 
> that I
> >> could use LLVM to compile to C (using llc -march=c), then run the 
> resulting
> >> C-code through the working C-cross-compilation tools. So, some newbie
> >> questions:
> >>
> >> (1) Is this crazy ?
> >>
> >
> > It depends on you definition of "crazy". It will turn it into C code.
> > However, you'll still need to link in the libstdc++ library.
> >
>One additional problem you may have a C header files.  Different
>operating systems and C library implementations will implement the same
>functions differently, so when cross-compiling, you need to make sure
>your compiling against header files that work on your target platform.

Its an bare-metal embedded target, so there is no use of any headers
other than the C and C++ library functions. As long as the versions
with LLVM are standards-compliant, no problem, right ?

> >> (2) What happens to all the C++ RTL ? Is it statically linked as LLVM 
> code,
> >> then translated back into C ?
> >> (3) Where does the LLVM RTL come from - newlib ? glibc ? other ?
> >>
> > LLVM doesn't use RTL. It has its own IR.
> >
>I believe he means the C++ Run-Time Library and not GCC's RTL
>Intermediate Representation.

Sorry I wasn't clear, yes I meant the C++ runtime library.
Its a two-part question:
- the compiler internals library (for example, exception handling), and
- the "standard" library (for example printf)

>Older versions of llvm-gcc compiled libstdc++ to LLVM bitcode and linked
>it statically into the LLVM bitcode for your program.  I am not sure
>what newer versions of llvm-gcc do.
>
>I do know that libc functions and other system functions are not
>compiled into LLVM bitcode.  They are (as Bill described below) either
>converted into LLVM intrinsics (like memcpy) or become calls to external
>functions (like printf).  After generation to native code, the program
>is linked against the system libraries.
>
>-- John T.
>
> >> (4) Is it manageable to create a small number of intrinsics to allow 
> access
> >> to the C runtime functions on the target, or is this difficult ? In the
> >> mailing list archive I saw some unresolved question with warnings about
> >> type conversions for someone trying this...
> >>
> > I'm not sure I understand your question. The program will have a call
> > to the C runtime functions (like strtof), and those are compiled into
> > calls in the assembly language. (Of course, the libc library needs to
> > be linked in to get the executable.) There are a few C runtime calls
> > that LLVM handles specially -- like memset, memcpy, etc. But it's not
> > necessary to have *all* C runtime calls be builtins or intrinsics for
> > LLVM to handle them.
> >
> > -bw

Do I understand correctly from above: LLVM provides a version of
the runtime library, of which some routines are converted to "external"
calls already ? So, there's already a printf binding to an external ?
For the standard-C library, my question is:
- how much of this has already been implemented (mapping to external),
- how hard will it be to add additional bindings ?

newlib makes it relatively easy by using common IO routines that
you replace with platform-specific implementations; is there something
analogous in the LLVM library implementation ? Hope I was more
clear this time...

Thanks again for your advice,
Best Regards, Dave

Dave Nadler, USA East Coast voice (978) 263-0097,  drn at nadler.com, Skype 
Dave.Nadler1 



From clattner at apple.com  Fri Jan 23 10:17:45 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 23 Jan 2009 08:17:45 -0800
Subject: [LLVMdev] Small problem in BitVector.h
In-Reply-To: <bcf95b5c-b2f6-4623-b588-dc2127cb99ef@l33g2000pri.googlegroups.com>
References: <e50173bd0901230451o7dcc7b39o6174e4ae7ab1900@mail.gmail.com>
	<bcf95b5c-b2f6-4623-b588-dc2127cb99ef@l33g2000pri.googlegroups.com>
Message-ID: <5C8B5F27-09A4-4E5D-B302-4DE7D3B3E44B@apple.com>


On Jan 23, 2009, at 6:43 AM, heisenbug wrote:

> On Jan 23, 1:51 pm, Roman Levenstein <romix.l... at googlemail.com>
> wrote:
>> Hi,
>>
>> Doing some profiling of llc, I noticed that some bitvector operations
>> took longer than usual. Then I noticed that too many copies of
>> BitVector obejcts are created, even when such operations like &=, ^=,
>> |= are performed on those bit vectors.
>>
>> I looked at the BitVector ADT implementation in BitVector.h and
>> figured out that all assignment operations (except the usual
>> assignment operator) return a copy of the bit vector, instead of a
>> reference!
>> I guess it was just overlooked.
>>
>> Below is the patch to fix it. Is it OK to commit?
>
> Yes. Please note in the commit message that the old
> semantics probably did not meet the expectations.
> With your patch, chained assignments happen to the right
> object.

Yes, please apply!

> A very good catch, and a nice demonstration of how
> C++'s performance characteristics can be spoiled
> by small bugs like these.

Too much subtlety :(

-Chris

From gordonhenriksen at me.com  Fri Jan 23 11:00:14 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Fri, 23 Jan 2009 12:00:14 -0500
Subject: [LLVMdev] Getting address of label in jitted code
In-Reply-To: <4979A89B.9000301@dcs.gla.ac.uk>
References: <mailman.648.1232678602.20833.llvmdev@cs.uiuc.edu>
	<4979A89B.9000301@dcs.gla.ac.uk>
Message-ID: <ECE0B702-D308-4E8A-8030-342EEF36BCEC@me.com>

On Jan 23, 2009, at 06:23, Mark Shannon wrote:

>> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote:
>>
>>> I need to get the address of a label in jitted code. (This is so  
>>> that I can insert a jump into the machine code to resume   
>>> interpretation from compiled code)
>>
>> What's your plan for restoring register and memory state?
>
> Put everything in memory at the yield point, (its for x86 only at  
> the moment). Not super efficient, but should work.
>
> So how do I get the address? ;)


Hi Mark,

Dan was asking a loaded question. The answer is that LLVM doesn't  
support taking the address of a label because of the question he asked.

? Gordon



From marks at dcs.gla.ac.uk  Fri Jan 23 11:19:47 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Fri, 23 Jan 2009 17:19:47 +0000
Subject: [LLVMdev] Getting address of label in jitted code[MESSAGE NOT
	SCANNED]
In-Reply-To: <ECE0B702-D308-4E8A-8030-342EEF36BCEC@me.com>
References: <mailman.648.1232678602.20833.llvmdev@cs.uiuc.edu><4979A89B.9000301@dcs.gla.ac.uk>
	<ECE0B702-D308-4E8A-8030-342EEF36BCEC@me.com>
Message-ID: <4979FC33.1020308@dcs.gla.ac.uk>

Gordon Henriksen wrote:
> On Jan 23, 2009, at 06:23, Mark Shannon wrote:
> 
>>> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote:
>>>
>>>> I need to get the address of a label in jitted code. (This is so  
>>>> that I can insert a jump into the machine code to resume   
>>>> interpretation from compiled code)
>>> What's your plan for restoring register and memory state?
>> Put everything in memory at the yield point, (its for x86 only at  
>> the moment). Not super efficient, but should work.
>>
>> So how do I get the address? ;)
> 
> 
> Hi Mark,
> 
> Dan was asking a loaded question. The answer is that LLVM doesn't  
> support taking the address of a label because of the question he asked.

So how does llvm.dbg.stoppoint work?
Or does it? I can't seem to get anywhere with it.
And how do the VMKit people support line number info for the JVM?

I really need to get the machine addresses of particular points in the 
code, and I don't want to have to hack the x86 machine code emitter
or introduce my own intrinsics.

Mark

From gohman at apple.com  Fri Jan 23 11:50:53 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 23 Jan 2009 09:50:53 -0800
Subject: [LLVMdev] Getting address of label in jitted code
In-Reply-To: <4979A89B.9000301@dcs.gla.ac.uk>
References: <mailman.648.1232678602.20833.llvmdev@cs.uiuc.edu>
	<4979A89B.9000301@dcs.gla.ac.uk>
Message-ID: <6EBC0175-7A6F-45D0-87BB-85362054179A@apple.com>


On Jan 23, 2009, at 3:23 AM, Mark Shannon wrote:

> Dan,
>
>>
>> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote:
>>
>>> Hi,
>>>
>>> I need to get the address of a label in jitted code.
>>> (This is so that I can insert a jump into the machine code to resume
>>> interpretation from compiled code)
>>
>> Hello,
>>
>> What's your plan for restoring register and memory state?
>
> Put everything in memory at the yield point,
> (its for x86 only at the moment).
> Not super efficient, but should work.


Is your interpreter stackless? If it's stackless, you can put
your entrypoint at the beginning of a Function, and then just
call it.

LLVM doesn't support taking the real address of a label. It may
some day, but that won't by itself make it safe to jump into
compiled code from separately-compiled code. To do that, you'd
need to arrange some stable set of assumptions about the state
of the machine at the time of the jump, and a way to tell the
code generator where and how to stay within the assumptions.
And that's essentially what function calling conventions
already are.

Dan


From marks at dcs.gla.ac.uk  Fri Jan 23 12:06:47 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Fri, 23 Jan 2009 18:06:47 +0000
Subject: [LLVMdev] Getting address of label in jitted code[MESSAGE NOT
	SCANNED]
In-Reply-To: <6EBC0175-7A6F-45D0-87BB-85362054179A@apple.com>
References: <mailman.648.1232678602.20833.llvmdev@cs.uiuc.edu>	<4979A89B.9000301@dcs.gla.ac.uk>
	<6EBC0175-7A6F-45D0-87BB-85362054179A@apple.com>
Message-ID: <497A0737.20503@dcs.gla.ac.uk>

Dan Gohman wrote:
> On Jan 23, 2009, at 3:23 AM, Mark Shannon wrote:
> 
>> Dan,
>>
>>> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote:
>>>
>>>> Hi,
>>>>
>>>> I need to get the address of a label in jitted code.
>>>> (This is so that I can insert a jump into the machine code to resume
>>>> interpretation from compiled code)
>>> Hello,
>>>
>>> What's your plan for restoring register and memory state?
>> Put everything in memory at the yield point,
>> (its for x86 only at the moment).
>> Not super efficient, but should work.
> 
> 
> Is your interpreter stackless? If it's stackless, you can put
> your entrypoint at the beginning of a Function, and then just
> call it.

No it has a stack, but I can guarantee that the ENTIRE state of the VM 
is recoverable. (I force all variables into memory at the yield point).
And I need to insert the jump at runtime, but only under certain 
conditions, so I don't want to split the code into sub-functions.
> 
> LLVM doesn't support taking the real address of a label. It may
> some day, but that won't by itself make it safe to jump into
> compiled code from separately-compiled code. To do that, you'd
> need to arrange some stable set of assumptions about the state
> of the machine at the time of the jump, and a way to tell the
> code generator where and how to stay within the assumptions.
> And that's essentially what function calling conventions
> already are.

I can guarantee correctness, I just need  to be able to get that address!

Please answer the question, I answered yours ;)

Mark.

From edwintorok at gmail.com  Fri Jan 23 12:52:37 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Fri, 23 Jan 2009 20:52:37 +0200
Subject: [LLVMdev] inline asm semantics: output constraint width smaller
	than input
In-Reply-To: <20090123183019.GA5984@elte.hu>
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu>
	<497A0C0A.7080207@gmail.com> <20090123183019.GA5984@elte.hu>
Message-ID: <497A11F5.9090005@gmail.com>

On 2009-01-23 20:30, Ingo Molnar wrote:
> * T?r?k Edwin <edwintorok at gmail.com> wrote:
>
>   
>> Having said that, llvm-gcc is not yet able to compile the full Linux 
>> kernel on its own [for example the boot code, due to asm(".code16gcc")], 
>> but with LLVM 2.4 it was possible to build "arch=UM", and "arch=X86" (by 
>> using gcc to build the bootcode). I'd like LLVM 2.5 to be able to build 
>> the kernel, so I'll file bugs for llvm/kernel depending on where the 
>> problem is.
>>     
>
> Could we get LLVM folks on the Cc: and see how difficult it would be to 
> fix this on the LLVM side? Asm constraints are used all around the place 
> and different input/output types are very common.

I've added LLVMDev to Cc.
Your first post to the list may take a little longer to reach it (first
post is moderated by listmaster, no subscription required).

[For those who missed the initial conversation, see:
http://llvm.org/bugs/show_bug.cgi?id=3373#c9]

Best regards,
--Edwin

From gohman at apple.com  Fri Jan 23 13:45:05 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 23 Jan 2009 11:45:05 -0800
Subject: [LLVMdev] Getting address of label in jitted code[MESSAGE NOT
	SCANNED]
In-Reply-To: <497A0737.20503@dcs.gla.ac.uk>
References: <mailman.648.1232678602.20833.llvmdev@cs.uiuc.edu>
	<4979A89B.9000301@dcs.gla.ac.uk>
	<6EBC0175-7A6F-45D0-87BB-85362054179A@apple.com>
	<497A0737.20503@dcs.gla.ac.uk>
Message-ID: <50179974-3868-4649-8DC9-2C3935BF01F9@apple.com>


On Jan 23, 2009, at 10:06 AM, Mark Shannon wrote:

> Dan Gohman wrote:
>>
>> LLVM doesn't support taking the real address of a label. It may
>> some day, but that won't by itself make it safe to jump into
>> compiled code from separately-compiled code. To do that, you'd
>> need to arrange some stable set of assumptions about the state
>> of the machine at the time of the jump, and a way to tell the
>> code generator where and how to stay within the assumptions.
>> And that's essentially what function calling conventions
>> already are.
>
> I can guarantee correctness, I just need  to be able to get that  
> address!
>
> Please answer the question, I answered yours ;)

I did. The answer is LLVM doesn't support it.

The other answer is that patches to add support for this would
be welcome, even if we remain unconvinced about the specific
use case you're proposing. From LLVM's perspective, it would be
valuable as a way to generate more efficient code for GCC's
labels-as-values extension.

Dan


From sanj_soman at yahoo.com  Fri Jan 23 13:55:31 2009
From: sanj_soman at yahoo.com (Sanjay Soman)
Date: Fri, 23 Jan 2009 11:55:31 -0800 (PST)
Subject: [LLVMdev] How to determine Immediate Type in MachineOperand class?
Message-ID: <72366.28846.qm@web82107.mail.mud.yahoo.com>

Hi,
?? I would like to get the type of immediate value (integer) from MachineOperand Class. Currently the immediate value is being represented as int64_t.
int64_t ImmVal; // For MO_Immediate.
?
Is it possible to find out whether the immediate value is int8, 16, 32 etc? 
?
Note: My target has a virtual Instruction set.
?
Thanks in advance,
-Sanjay


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090123/9071a954/attachment.html 

From edwintorok at gmail.com  Fri Jan 23 14:42:47 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Fri, 23 Jan 2009 22:42:47 +0200
Subject: [LLVMdev] inline asm semantics: output constraint width smaller
	than input
In-Reply-To: <497A11F5.9090005@gmail.com>
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu>
	<497A0C0A.7080207@gmail.com> <20090123183019.GA5984@elte.hu>
	<497A11F5.9090005@gmail.com>
Message-ID: <497A2BC7.5030107@gmail.com>

On 2009-01-23 20:52, T?r?k Edwin wrote:
> On 2009-01-23 20:30, Ingo Molnar wrote:
>   
>> * T?r?k Edwin <edwintorok at gmail.com> wrote:
>>
>>   
>>     
>>> Having said that, llvm-gcc is not yet able to compile the full Linux 
>>> kernel on its own [for example the boot code, due to asm(".code16gcc")], 
>>> but with LLVM 2.4 it was possible to build "arch=UM", and "arch=X86" (by 
>>> using gcc to build the bootcode). I'd like LLVM 2.5 to be able to build 
>>> the kernel, so I'll file bugs for llvm/kernel depending on where the 
>>> problem is.
>>>     
>>>       
>> Could we get LLVM folks on the Cc: and see how difficult it would be to 
>> fix this on the LLVM side? Asm constraints are used all around the place 
>> and different input/output types are very common.
>>     
>
>   

Hi Ingo,

Could you describe what are the semantics you need for inline asm
constraints in the kernel?
GCC doesn't document all the corner cases, and defining inline asm =
"whatever gcc accepts" is not very useful for LLVM.

So far we've encountered the problem with input/output operand tied to
same register, but having different widths:
- output wider than input, both integers: do you need this case?
- output narrower than input, both integers: this is the common case, right?
- can it also happen that input is pointer, output is integer of
different width?
- .. any other mismatches?

Could you also describe why put_user/the example from pcbios needs the
different widths?

Best regards,
--Edwin

From isanbard at gmail.com  Fri Jan 23 15:04:35 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Fri, 23 Jan 2009 13:04:35 -0800
Subject: [LLVMdev] Using LLVM as cross-compiler to C
In-Reply-To: <6.0.1.1.2.20090123095328.01d6bdb0@pop.nadler.com>
References: <6.0.1.1.2.20090121184018.01d281f0@pop.nadler.com>
	<16e5fdf90901211651n3693c8e2g5cbbec086b2281f@mail.gmail.com>
	<4977D409.9010904@cs.uiuc.edu>
	<6.0.1.1.2.20090123095328.01d6bdb0@pop.nadler.com>
Message-ID: <16e5fdf90901231304p490ca557uee3c0b843d581ca3@mail.gmail.com>

On Fri, Jan 23, 2009 at 7:37 AM, Dave Nadler <Dave.Nadler at nadler.com> wrote:
> At 09:03 PM 1/21/2009, John Criswell wrote:
>>One additional problem you may have a C header files.  Different
>>operating systems and C library implementations will implement the same
>>functions differently, so when cross-compiling, you need to make sure
>>your compiling against header files that work on your target platform.
>
> Its an bare-metal embedded target, so there is no use of any headers
> other than the C and C++ library functions. As long as the versions
> with LLVM are standards-compliant, no problem, right ?
>
Yes.

>> >> (2) What happens to all the C++ RTL ? Is it statically linked as LLVM
>> code,
>> >> then translated back into C ?
>> >> (3) Where does the LLVM RTL come from - newlib ? glibc ? other ?
>> >>
>> > LLVM doesn't use RTL. It has its own IR.
>> >
>>I believe he means the C++ Run-Time Library and not GCC's RTL
>>Intermediate Representation.
>
> Sorry I wasn't clear, yes I meant the C++ runtime library.
> Its a two-part question:
> - the compiler internals library (for example, exception handling), and
> - the "standard" library (for example printf)
>
We don't convert libstdc++ or libc into LLVM code. It's linked in
as-is from the system. For exception handling, we create ABI-compliant
code. So it's usable by the normal C++ RTL.

>> >> (4) Is it manageable to create a small number of intrinsics to allow
>> access
>> >> to the C runtime functions on the target, or is this difficult ? In the
>> >> mailing list archive I saw some unresolved question with warnings about
>> >> type conversions for someone trying this...
>> >>
>> > I'm not sure I understand your question. The program will have a call
>> > to the C runtime functions (like strtof), and those are compiled into
>> > calls in the assembly language. (Of course, the libc library needs to
>> > be linked in to get the executable.) There are a few C runtime calls
>> > that LLVM handles specially -- like memset, memcpy, etc. But it's not
>> > necessary to have *all* C runtime calls be builtins or intrinsics for
>> > LLVM to handle them.
>
> Do I understand correctly from above: LLVM provides a version of
> the runtime library, of which some routines are converted to "external"
> calls already ? So, there's already a printf binding to an external ?
> For the standard-C library, my question is:
> - how much of this has already been implemented (mapping to external),
> - how hard will it be to add additional bindings ?
>
> newlib makes it relatively easy by using common IO routines that
> you replace with platform-specific implementations; is there something
> analogous in the LLVM library implementation ? Hope I was more
> clear this time...
>
Not really. LLVM doesn't provide the libc or libstdc++ libraries.
Those are expected to be on your system already. There are some C
calls that LLVM recognizes as standard C functions, and that LLVM can
generate efficient code for. It generates assembly code in these
cases, not a call to an external library. I don't know about "newlib",
but if it's a replacement for the normal libc library, there shouldn't
be a problem with using it.

-bw

From evan.cheng at apple.com  Fri Jan 23 16:01:10 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 23 Jan 2009 14:01:10 -0800
Subject: [LLVMdev] How to determine Immediate Type in MachineOperand
	class?
In-Reply-To: <72366.28846.qm@web82107.mail.mud.yahoo.com>
References: <72366.28846.qm@web82107.mail.mud.yahoo.com>
Message-ID: <9E973B6D-F35B-4DEC-9DAC-011259AF8FE7@apple.com>


On Jan 23, 2009, at 11:55 AM, Sanjay Soman wrote:

> Hi,
>    I would like to get the type of immediate value (integer) from  
> MachineOperand Class. Currently the immediate value is being  
> represented as int64_t.
> int64_t ImmVal; // For MO_Immediate.
>
> Is it possible to find out whether the immediate value is int8, 16,  
> 32 etc?
>
> Note: My target has a virtual Instruction set.
>
> Thanks in advance,
> -Sanjay
>

It's not possible. MachineOperand and TargetOperandInfo do not carry  
type information.

Evan

> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090123/7ff5104d/attachment-0001.html 

From howarth at bromo.med.uc.edu  Fri Jan 23 17:45:45 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 23 Jan 2009 18:45:45 -0500
Subject: [LLVMdev] llvm-gcc-4.2 vs gcc 4.2.4
Message-ID: <20090123234545.GA19093@bromo.med.uc.edu>

Here are the results from current llvm/llvm-gcc-4.2 svn and
gcc 4.2.4 for the Polyhedron 2005 benchmarks under MacOS X
10.5.6 on a MacPro.


              Ave Run (secs)      Ave Run (secs)     llvm-gcc-4.2/
Benchmark     llvm-gcc-4.2 svn    gcc 4.2.4          gcc 4.2.4
ac            15.01               15.32              0.980 
aermod        15.96               22.96              0.695  
air           8.25                8.15               1.012 
capaccita     51.41               52.16              0.986 
channel       3.32                5.17               0.642 
doduc         34.06               34.43              0.989 
fatigue       12.80               12.57              1.018 
gas_dyn       16.45               13.59              1.210
induct        26.70               28.61              0.933 
linpk         15.40               15.46              0.996 
mdbx          14.19               12.41              1.143 
nf            29.01               27.08              1.071 
protein       45.03               41.61              1.082
rnflow        39.67               35.37              1.122 
test_fpu      14.03               11.94              1.172 
tfft          2.19                2.13               1.028 

From mrs at apple.com  Fri Jan 23 18:09:10 2009
From: mrs at apple.com (Mike Stump)
Date: Fri, 23 Jan 2009 16:09:10 -0800
Subject: [LLVMdev] new warnings
Message-ID: <60624B69-8078-43E7-B7BD-41C51D491B33@apple.com>

A new warning:

/Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member  
function 'bool llvm::LLParser::ParseGlobal(const std::string&, const  
char*, unsigned int, bool, unsigned int)':
/Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:448: warning:  
'IsConstant' may be used uninitialized in this function

From techvd at gmail.com  Fri Jan 23 19:26:53 2009
From: techvd at gmail.com (Vijay D)
Date: Fri, 23 Jan 2009 17:26:53 -0800
Subject: [LLVMdev] Problem invoking win32 api calls (Eli Friedman)
Message-ID: <5617ccb50901231726y528942a3g6c724f5705379a5@mail.gmail.com>

That worked perfectly! Thanks!

---------- Forwarded message ----------
From: Eli Friedman <eli.friedman at gmail.com>
To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Date: Thu, 22 Jan 2009 18:52:22 -0800
Subject: Re: [LLVMdev] Problem invoking win32 api calls
On Thu, Jan 22, 2009 at 6:43 PM, Vijay D <techvd at gmail.com> wrote:
> Hi,
>
> I use the kaliedoscope tutorial to do some experiments. I'm trying to
define
> a few win32 functions as extern and execute them from the toy language.
> Functions that take no arguments execute fine (for example,
GetLastError()).
> However, calling functions that do take arguments (for example,
> SetLastError(unsigned int)) always crash the application due to some kind
of
> stack corruption (Unhandled exception at 0x00000000: 0xC0000005: Access
> violation reading location 0x00000000.)

Sounds like a calling convention issue.

> I'm actually using the CallingConv::X86_StdCall calling convention for
these
> external functions (F->setCallingConv(CallingConv::X86_StdCall);) and that
> doesn't resolve the issue.

Note that you have to set the calling convention on the call.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090123/35945845/attachment.html 

From howarth at bromo.med.uc.edu  Fri Jan 23 20:39:56 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 23 Jan 2009 21:39:56 -0500
Subject: [LLVMdev] -O4 limitations in llvm/llvm-gcc-4.2 2.5?
Message-ID: <20090124023956.GA20019@bromo.med.uc.edu>

   What exactly are the current limitations for using -O4 to create shared
libraries with llvm/llvm-gcc-4.2 2.5? I tried a build of xplor-nih at -O4
with llvm-gcc, llvm-g++ and llvm-gfortran. The build fails to link shared
libraries with errors such as...

Building xplor-nih for platform: Darwin_9_x86

[ -d /Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ ] || mkdir /Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/
touch /Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ 
for lib in libfft pppack specfun lapack blas; do \
	 (cd $lib; make XPLORNIH_ROOT=/Users/howarth/xplor-nih-2.21 \
                               ARCH=Darwin_9_x86 lib);\
	done
[ -d bin.Darwin_9_x86 ] || mkdir bin.Darwin_9_x86
cd bin.Darwin_9_x86; make -f /Users/howarth/xplor-nih-2.21/fortlib/libfft/Makefile \
		ARCH=Darwin_9_x86 SRCDIR=/Users/howarth/xplor-nih-2.21/fortlib/libfft/ ARCHDEP=TRUE lib
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/dsint.f
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/dsinti.f
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/dcfftf.f
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/dcfftb.f
/Users/howarth/xplor-nih-2.21/fortlib/libfft/dcfftb.f:16.16:

      nf = ifac(2)                                                             
               1
Warning: Array reference at (1) is out of bounds
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/dcffti.f
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/drffti.f
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/drfftf.f
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/drfftb.f
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/c_ffti.F -o zffti.o
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/c_fftf.F -o zfftf.o
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/c_fftb.F -o zfftb.o
llvm-gcc-4 -c /Users/howarth/xplor-nih-2.21/fortlib/libfft/ctrans.c  -O4 -fPIC -ffast-math -msse4  -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG  -I/Users/howarth/xplor-nih-2.21/fortlib/libfft/ -I/Users/howarth/xplor-nih-2.21/arch/Darwin_9_x86/include -DZOMPLEX -I/usr/include/sys 
llvm-gcc-4 -c -O4 -fPIC -ffast-math -msse4  -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG  -I/Users/howarth/xplor-nih-2.21/fortlib/libfft/ -I/Users/howarth/xplor-nih-2.21/arch/Darwin_9_x86/include -DZOMPLEX -I/usr/include/sys /Users/howarth/xplor-nih-2.21/fortlib/libfft/c_fft1d.c -o zfft1d.o
llvm-gcc-4 -c -O4 -fPIC -ffast-math -msse4  -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG  -I/Users/howarth/xplor-nih-2.21/fortlib/libfft/ -I/Users/howarth/xplor-nih-2.21/arch/Darwin_9_x86/include -DZOMPLEX -I/usr/include/sys /Users/howarth/xplor-nih-2.21/fortlib/libfft/c_fft2d.c -o zfft2d.o
llvm-gcc-4 -c -O4 -fPIC -ffast-math -msse4  -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG  -I/Users/howarth/xplor-nih-2.21/fortlib/libfft/ -I/Users/howarth/xplor-nih-2.21/arch/Darwin_9_x86/include -DZOMPLEX -I/usr/include/sys /Users/howarth/xplor-nih-2.21/fortlib/libfft/c_fft3d.c -o zfft3d.o
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/ftrans.F
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/c_mp_fft.F -o zmp_fft.o
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/c_scal_fft.F -o zscal_fft.o
llvm-gfortran -c -O4 -fPIC   -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore   -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/c_prod_fft.F -o zprod_fft.o
llvm-gcc-4 -c /Users/howarth/xplor-nih-2.21/fortlib/libfft/fft_ftn.c  -O4 -fPIC -ffast-math -msse4  -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG  -I/Users/howarth/xplor-nih-2.21/fortlib/libfft/ -I/Users/howarth/xplor-nih-2.21/arch/Darwin_9_x86/include -DZOMPLEX -I/usr/include/sys 
llvm-gcc-4 -O4 -dynamiclib -o libfft.dylib dsint.o dsinti.o dcfftf.o dcfftb.o dcffti.o drffti.o drfftf.o drfftb.o zffti.o zfftf.o zfftb.o ctrans.o zfft1d.o zfft2d.o zfft3d.o ftrans.o zmp_fft.o zscal_fft.o zprod_fft.o fft_ftn.o -flat_namespace -undefined suppress -single_module    -lcrypto  -v -noall_load
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../llvm-gcc4.2-2.5.source/configure --prefix=/sw --prefix=/sw/lib/llvm-gcc-4.2 --mandir=/sw/share/man --infodir=/sw/share/info --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-as=/Developer/usr/bin/as --with-ld=/Developer/usr/bin/ld --with-nm=/Developer/usr/bin/nm --build=i686-apple-darwin9 --target=i686-apple-darwin9 --host=i686-apple-darwin9 --with-arch=nocona --with-tune=generic --with-gxx-include-dir=/usr/include/c++/4.0.0 --enable-llvm=/sw/src/fink.build/llvm-gcc42-2.5-1/llvm-2.5/../llvm_objdir --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5636) (LLVM build)
 /sw/lib/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin9/4.2.1/collect2 -dynamic -dylib -arch i386 -flat_namespace -macosx_version_min 10.5.6 -single_module -undefined suppress -weak_reference_mismatches non-weak -undefined suppress -o libfft.dylib -ldylib1.10.5.o -L/usr/lib/i686-apple-darwin9/4.2.1 -L/sw/lib/llvm-gcc-4.2/lib/gcc/i686-apple-darwin9/4.2.1 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1 -L/sw/lib/llvm-gcc-4.2/lib/gcc/i686-apple-darwin9/4.2.1/../../.. dsint.o dsinti.o dcfftf.o dcfftb.o dcffti.o drffti.o drfftf.o drfftb.o zffti.o zfftf.o zfftb.o ctrans.o zfft1d.o zfft2d.o zfft3d.o ftrans.o zmp_fft.o zscal_fft.o zprod_fft.o fft_ftn.o -lcrypto -lgcc_s.10.5 -lgcc -lSystem
ld: in dsint.o, could not parse object file dsint.o: Unknown instruction
collect2: ld returned 1 exit status
make[3]: *** [libfft.dylib] Error 1
make[2]: *** [lib] Error 2

Is there a wiki on the state of the LTO support somewhere?
                Jack

From nicolas.geoffray at lip6.fr  Sat Jan 24 04:05:54 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Sat, 24 Jan 2009 11:05:54 +0100
Subject: [LLVMdev] Getting address of label in jitted code[MESSAGE NOT
 SCANNED]
In-Reply-To: <4979FC33.1020308@dcs.gla.ac.uk>
References: <mailman.648.1232678602.20833.llvmdev@cs.uiuc.edu><4979A89B.9000301@dcs.gla.ac.uk>	<ECE0B702-D308-4E8A-8030-342EEF36BCEC@me.com>
	<4979FC33.1020308@dcs.gla.ac.uk>
Message-ID: <497AE802.6000209@lip6.fr>

Mark Shannon wrote:
> So how does llvm.dbg.stoppoint work?
> Or does it? I can't seem to get anywhere with it.
> And how do the VMKit people support line number info for the JVM?
>
>   

We don't support it. The complexity of implementing it in LLVM does not 
worth the ability to print a line number (for now).

> I really need to get the machine addresses of particular points in the 
> code, 

So, really, you *can't* right now. I definitely hope that one day LLVM 
will be able to do that, just for your simple case, or getting line 
numbers or doing dynamic on stack replacement.


Nicolas

From lennart at augustsson.net  Sat Jan 24 06:34:10 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Sat, 24 Jan 2009 12:34:10 +0000
Subject: [LLVMdev] Unimplemented documentation
Message-ID: <f4876cd70901240434r451eb01dl783e527371edcd21@mail.gmail.com>

Hi,

Is there some documentation about what has not been implemented yet?

I'm trying to use vectors and I just run into one thing after another
that seem to be missing.
(I.e., fcmp on vectors doesn't work; trying to do the same thing with
expanded instructions doesn't work; select on a vector doesn't work)

  -- Lennart

From ggreif at gmail.com  Sat Jan 24 06:59:36 2009
From: ggreif at gmail.com (heisenbug)
Date: Sat, 24 Jan 2009 04:59:36 -0800 (PST)
Subject: [LLVMdev] Unimplemented documentation
In-Reply-To: <f4876cd70901240434r451eb01dl783e527371edcd21@mail.gmail.com>
References: <f4876cd70901240434r451eb01dl783e527371edcd21@mail.gmail.com>
Message-ID: <4f38770d-eb91-456f-b1b2-01ac2baf6e83@a12g2000pro.googlegroups.com>

On 24 Jan., 13:34, Lennart Augustsson <lenn... at augustsson.net> wrote:
> Hi,
>
> Is there some documentation about what has not been implemented yet?
>
> I'm trying to use vectors and I just run into one thing after another
> that seem to be missing.
> (I.e., fcmp on vectors doesn't work; trying to do the same thing with
> expanded instructions doesn't work; select on a vector doesn't work)

Hi Lennart,

I am pretty clueless about the vector instruction set, but this might
be a hint:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090119/072524.html

Cheers,

    Gabor

>
> ? -- Lennart
> _______________________________________________
> LLVM Developers mailing list
> LLVM... at cs.uiuc.edu ? ? ? ?http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From edwintorok at gmail.com  Sat Jan 24 10:23:40 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Sat, 24 Jan 2009 18:23:40 +0200
Subject: [LLVMdev] inline asm semantics: output constraint width smaller
	than input
In-Reply-To: <497A0C0A.7080207@gmail.com>
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu>
	<497A0C0A.7080207@gmail.com>
Message-ID: <497B408C.20802@gmail.com>

On 2009-01-23 20:27, T?r?k Edwin wrote:
>>>    
>>>       
>> i'd not mind it at all if the kernel could be built with other open-source 
>> compilers too.
>>
>> Now in this case the patch you suggest might end up hurting the end result 
>> so it's not an unconditional 'yes'. But ... how much it actually matters 
>> depends on the circumstances.
>>
>> So could you please send a sample patch for some of most common inline 
>> assembly statements that are affected by this, so that we can see:
>>
>>    1) how ugly the LLVM workarounds are
>>   
>>     
>
> Ok, I will prepare a patch for both cases.
>
>   
>>    2) how they affect the generated kernel image in practice
>>
>> My gut feeling is that it's going to be acceptable with a bit of thinking 
>> (we might even do some wrappers to do this cleanly) - but i'd really like 
>> to see it before giving you that judgement.
>>     

The below patch is to build the kernel for x86_64, with the attached
.config,
using llvm-gcc (trunk, with patch from
http://llvm.org/bugs/show_bug.cgi?id=2989#c2).

The .config has KVM turned off, because I didn't know how to change
x86_emulate.c so that LLVM builds it
(http://llvm.org/bugs/show_bug.cgi?id=3373#c10)
For 32-bit some more changes are required.

The resulting kernel image are of the same size
$ ls -l vmlinux.patched
-rwxr-xr-x 1 edwin edwin 11277206 2009-01-24 17:58 vmlinux.patched
$ ls -l vmlinux
-rwxr-xr-x 1 edwin edwin 11277206 2009-01-24 18:01 vmlinux

They aren't identical though, a disassembly shows that the address of
most of functions changed,
also some register assignments changed (r14 instead of r15, and so on).

Are these changes correct, and are they acceptable?

Best regards,
--Edwin

---
 arch/x86/include/asm/uaccess.h |   10 ++++++----
 arch/x86/lib/delay.c           |    2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 69d2757..28280de 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -154,7 +154,7 @@ extern int __get_user_bad(void);
 
 #define get_user(x, ptr)                        \
 ({                                    \
-    int __ret_gu;                            \
+    unsigned long __ret_gu;                        \
     unsigned long __val_gu;                        \
     __chk_user_ptr(ptr);                        \
     might_fault();                            \
@@ -176,7 +176,7 @@ extern int __get_user_bad(void);
         break;                            \
     }                                \
     (x) = (__typeof__(*(ptr)))__val_gu;                \
-    __ret_gu;                            \
+    (int)__ret_gu;                            \
 })
 
 #define __put_user_x(size, x, ptr, __ret_pu)            \
@@ -239,11 +239,13 @@ extern void __put_user_8(void);
  */
 #define put_user(x, ptr)                    \
 ({                                \
-    int __ret_pu;                        \
+    __typeof__(*(ptr)) __ret_pu;                \
     __typeof__(*(ptr)) __pu_val;                \
     __chk_user_ptr(ptr);                    \
     might_fault();                        \
     __pu_val = x;                        \
+       /* return value is 0 or -EFAULT, both fit in 1 byte, and \
+    * are sign-extendable to int */                \
     switch (sizeof(*(ptr))) {                \
     case 1:                            \
         __put_user_x(1, __pu_val, ptr, __ret_pu);    \
@@ -261,7 +263,7 @@ extern void __put_user_8(void);
         __put_user_x(X, __pu_val, ptr, __ret_pu);    \
         break;                        \
     }                            \
-    __ret_pu;                        \
+    (int)__ret_pu;                        \
 })
 
 #define __put_user_size(x, ptr, size, retval, errret)            \
diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c
index f456860..12d27f8 100644
--- a/arch/x86/lib/delay.c
+++ b/arch/x86/lib/delay.c
@@ -112,7 +112,7 @@ EXPORT_SYMBOL(__delay);
 
 inline void __const_udelay(unsigned long xloops)
 {
-    int d0;
+    unsigned long d0;
 
     xloops *= 4;
     asm("mull %%edx"
-- 
1.5.6.5

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: .config-llvm-64
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090124/e5b987c5/attachment-0001.pl 

From gohman at apple.com  Sat Jan 24 11:01:01 2009
From: gohman at apple.com (Dan Gohman)
Date: Sat, 24 Jan 2009 09:01:01 -0800
Subject: [LLVMdev] Unimplemented documentation
In-Reply-To: <f4876cd70901240434r451eb01dl783e527371edcd21@mail.gmail.com>
References: <f4876cd70901240434r451eb01dl783e527371edcd21@mail.gmail.com>
Message-ID: <B7E2DBA2-89EF-4278-A4E0-6DC69BAE71BA@apple.com>

On Jan 24, 2009, at 4:34 AM, Lennart Augustsson  
<lennart at augustsson.net> wrote:

> Hi,
>
> Is there some documentation about what has not been implemented yet?

I've started adding notes to
docs/LangRef.html

Historically this document has been used to describe just the LLVM IR,  
and not what specific consumers of it do or don't support, but codegen  
is a very important consumer, so I've started adding notes about its  
limitations.

>
> I'm trying to use vectors and I just run into one thing after another
> that seem to be missing.
> (I.e., fcmp on vectors doesn't work; trying to do the same thing with
> expanded instructions doesn't work; select on a vector doesn't work)

A common thread here is that the code generator doesn't support  
vectors of booleans very well yet. Comparisons and selects are very  
useful (and are also the first step towards more advanced conditional  
vector support), so we'd really like to see this fixed, though it will  
depend on  someone stepping forward to do the work.

What do you mean by "expanded instructions"?

Dan

From mingo at elte.hu  Sat Jan 24 11:27:58 2009
From: mingo at elte.hu (Ingo Molnar)
Date: Sat, 24 Jan 2009 18:27:58 +0100
Subject: [LLVMdev] inline asm semantics: output constraint width smaller
	than	input
In-Reply-To: <497B408C.20802@gmail.com>
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu>
	<497A0C0A.7080207@gmail.com> <497B408C.20802@gmail.com>
Message-ID: <20090124172758.GA31699@elte.hu>


* T?r?k Edwin <edwintorok at gmail.com> wrote:

> On 2009-01-23 20:27, T?r?k Edwin wrote:
> >>>    
> >>>       
> >> i'd not mind it at all if the kernel could be built with other open-source 
> >> compilers too.
> >>
> >> Now in this case the patch you suggest might end up hurting the end result 
> >> so it's not an unconditional 'yes'. But ... how much it actually matters 
> >> depends on the circumstances.
> >>
> >> So could you please send a sample patch for some of most common inline 
> >> assembly statements that are affected by this, so that we can see:
> >>
> >>    1) how ugly the LLVM workarounds are
> >>   
> >>     
> >
> > Ok, I will prepare a patch for both cases.
> >
> >   
> >>    2) how they affect the generated kernel image in practice
> >>
> >> My gut feeling is that it's going to be acceptable with a bit of thinking 
> >> (we might even do some wrappers to do this cleanly) - but i'd really like 
> >> to see it before giving you that judgement.
> >>     
> 
> The below patch is to build the kernel for x86_64, with the attached
> .config,
> using llvm-gcc (trunk, with patch from
> http://llvm.org/bugs/show_bug.cgi?id=2989#c2).
> 
> The .config has KVM turned off, because I didn't know how to change
> x86_emulate.c so that LLVM builds it
> (http://llvm.org/bugs/show_bug.cgi?id=3373#c10)
> For 32-bit some more changes are required.
> 
> The resulting kernel image are of the same size
> $ ls -l vmlinux.patched
> -rwxr-xr-x 1 edwin edwin 11277206 2009-01-24 17:58 vmlinux.patched
> $ ls -l vmlinux
> -rwxr-xr-x 1 edwin edwin 11277206 2009-01-24 18:01 vmlinux
> 
> They aren't identical though, a disassembly shows that the address of
> most of functions changed,
> also some register assignments changed (r14 instead of r15, and so on).
> 
> Are these changes correct, and are they acceptable?
> 
> Best regards,
> --Edwin
> 
> ---
>  arch/x86/include/asm/uaccess.h |   10 ++++++----
>  arch/x86/lib/delay.c           |    2 +-
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index 69d2757..28280de 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -154,7 +154,7 @@ extern int __get_user_bad(void);
>  
>  #define get_user(x, ptr)                        \
>  ({                                    \
> -    int __ret_gu;                            \
> +    unsigned long __ret_gu;                        \
>      unsigned long __val_gu;                        \
>      __chk_user_ptr(ptr);                        \
>      might_fault();                            \
> @@ -176,7 +176,7 @@ extern int __get_user_bad(void);
>          break;                            \
>      }                                \
>      (x) = (__typeof__(*(ptr)))__val_gu;                \
> -    __ret_gu;                            \
> +    (int)__ret_gu;                            \
>  })
>  
>  #define __put_user_x(size, x, ptr, __ret_pu)            \
> @@ -239,11 +239,13 @@ extern void __put_user_8(void);
>   */
>  #define put_user(x, ptr)                    \
>  ({                                \
> -    int __ret_pu;                        \
> +    __typeof__(*(ptr)) __ret_pu;                \

This does not look right. We can sometimes have put_user() of non-integer 
types (say structures). How does the (int)__ret_pu cast work in that case? 
We'll fall into this branch in that case:

        default:                                                \
                __put_user_x(X, __pu_val, ptr, __ret_pu);       \
                break;                                          \

and __ret_pu has a nonsensical type in that case.

>      __typeof__(*(ptr)) __pu_val;                \
>      __chk_user_ptr(ptr);                    \
>      might_fault();                        \
>      __pu_val = x;                        \
> +       /* return value is 0 or -EFAULT, both fit in 1 byte, and \
> +    * are sign-extendable to int */                \
>      switch (sizeof(*(ptr))) {                \
>      case 1:                            \
>          __put_user_x(1, __pu_val, ptr, __ret_pu);    \
> @@ -261,7 +263,7 @@ extern void __put_user_8(void);
>          __put_user_x(X, __pu_val, ptr, __ret_pu);    \
>          break;                        \
>      }                            \
> -    __ret_pu;                        \
> +    (int)__ret_pu;                        \
>  })
>  
>  #define __put_user_size(x, ptr, size, retval, errret)            \
> diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c
> index f456860..12d27f8 100644
> --- a/arch/x86/lib/delay.c
> +++ b/arch/x86/lib/delay.c
> @@ -112,7 +112,7 @@ EXPORT_SYMBOL(__delay);
>  
>  inline void __const_udelay(unsigned long xloops)
>  {
> -    int d0;
> +    unsigned long d0;
>  
>      xloops *= 4;
>      asm("mull %%edx"

Is this all that you need (plus the 16-bit setup code tweaks) to get LLVM 
to successfully build a 64-bit kernel image?

If yes then this doesnt look all that bad or invasive at first sight (if 
the put_user() workaround can be expressed in a cleaner way), but in any 
case it would be nice to hear an LLVM person's opinion about roughly when 
this is going to be solved in LLVM itself.

	Ingo

From edwintorok at gmail.com  Sat Jan 24 12:57:18 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Sat, 24 Jan 2009 20:57:18 +0200
Subject: [LLVMdev] inline asm semantics: output constraint width smaller
	than input
In-Reply-To: <20090124172758.GA31699@elte.hu>
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu>
	<497A0C0A.7080207@gmail.com> <497B408C.20802@gmail.com>
	<20090124172758.GA31699@elte.hu>
Message-ID: <497B648E.7020805@gmail.com>

On 2009-01-24 19:27, Ingo Molnar wrote:
> * T?r?k Edwin <edwintorok at gmail.com> wrote:
>   
>>  #define put_user(x, ptr)                    \
>>  ({                                \
>> -    int __ret_pu;                        \
>> +    __typeof__(*(ptr)) __ret_pu;                \
>>     
>
> This does not look right. We can sometimes have put_user() of non-integer 
> types (say structures). 

I didn't encounter it with my .config, but it is certainly possible.
I think using __builtin_choose_expr would be better than the switch

See a new patch at the end of this mail, using __builtin_choose_expr.
[vmlinux size still same]
It also includes some 32-bit stuff, but that is not complete yet.

> How does the (int)__ret_pu cast work in that case? 
>   

It would fail at compile time, with an error message that you can't cast
aggregates to ints, so my patch is not good.

> We'll fall into this branch in that case:
>
>         default:                                                \
>                 __put_user_x(X, __pu_val, ptr, __ret_pu);       \
>                 break;                                          \
>
> and __ret_pu has a nonsensical type in that case.
>   

That branch is a call to a non-existent function __put_user_X, and
should give error at link time, right?
In the new patch below I used (void)-EFAULT so that you would get an
error at compile time (as suggested
in __builtin_choose_expr in gcc's manual), if that branch would ever get
expanded. Does that sound right?

>   
>>      __typeof__(*(ptr)) __pu_val;                \
>>      __chk_user_ptr(ptr);                    \
>>      might_fault();                        \
>>      __pu_val = x;                        \
>> +       /* return value is 0 or -EFAULT, both fit in 1 byte, and \
>> +    * are sign-extendable to int */                \
>>      switch (sizeof(*(ptr))) {                \
>>      case 1:                            \
>>          __put_user_x(1, __pu_val, ptr, __ret_pu);    \
>> @@ -261,7 +263,7 @@ extern void __put_user_8(void);
>>          __put_user_x(X, __pu_val, ptr, __ret_pu);    \
>>          break;                        \
>>      }                            \
>> -    __ret_pu;                        \
>> +    (int)__ret_pu;                        \
>>  })
>>  
>>  #define __put_user_size(x, ptr, size, retval, errret)            \
>> diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c
>> index f456860..12d27f8 100644
>> --- a/arch/x86/lib/delay.c
>> +++ b/arch/x86/lib/delay.c
>> @@ -112,7 +112,7 @@ EXPORT_SYMBOL(__delay);
>>  
>>  inline void __const_udelay(unsigned long xloops)
>>  {
>> -    int d0;
>> +    unsigned long d0;
>>  
>>      xloops *= 4;
>>      asm("mull %%edx"
>>     
>
> Is this all that you need (plus the 16-bit setup code tweaks)

The 16-bit setup code is compiled, but obviously doesn't work.
I think the best approach would be for LLVM to give a warning/error, when
-fno-unit-at-a-time is used, since it doesn't support that.

>  to get LLVM 
> to successfully build a 64-bit kernel image?
>   

With the .config I sent previously, yes. With some other .config most
likely more changes are needed,
for example the SMP code, KVM code, but as I said in my previous email I
don't know how to "fix" the inline asm in that case.

There's something wrong with building some modules also, I keep getting
an "idr_init" undefined error, but the symbol is present in my vmlinux.
If I turn make those modules built into the kernel it works then (sctp,
w1, thermalsysfs).

It looks like I'll also have to submit some patches for ARCH=um, because
I get undefined references to __bad_size, __guard, and

__stack_smash_handler. __bad_size is probably because LLVM didn't inline expand + DCE something GCC did.


With an unpatched LLVM I would also need weak attributes to be on the
function type, instead of the return type,
but I think thats an LLVM bug, and a one-line patch corrects it.

> If yes then this doesnt look all that bad or invasive at first sight (if 
> the put_user() workaround can be expressed in a cleaner way), but in any 
> case it would be nice to hear an LLVM person's opinion about roughly when 
> this is going to be solved in LLVM itself.
>   

Yes, that is why LLVMDev is on Cc:, somebody will eventually reply ;)


Not-Signed-off-by: T?r?k Edwin <edwintorok at gmail.com>
---

 arch/x86/include/asm/uaccess.h |   41
+++++++++++++++++++--------------------
 arch/x86/lib/delay.c           |    2 +-
 arch/x86/pci/pcbios.c          |    4 ++-
 3 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 69d2757..46d00a8 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -154,7 +154,7 @@ extern int __get_user_bad(void);
 
 #define get_user(x, ptr)                        \
 ({                                    \
-    int __ret_gu;                            \
+    unsigned long __ret_gu;                        \
     unsigned long __val_gu;                        \
     __chk_user_ptr(ptr);                        \
     might_fault();                            \
@@ -176,7 +176,7 @@ extern int __get_user_bad(void);
         break;                            \
     }                                \
     (x) = (__typeof__(*(ptr)))__val_gu;                \
-    __ret_gu;                            \
+    (int)__ret_gu;                            \
 })
 
 #define __put_user_x(size, x, ptr, __ret_pu)            \
@@ -200,12 +200,15 @@ extern int __get_user_bad(void);
              : "A" (x), "r" (addr), "i" (-EFAULT), "0" (err))
 
 #define __put_user_x8(x, ptr, __ret_pu)                \
-    asm volatile("call __put_user_8" : "=a" (__ret_pu)    \
-             : "A" ((typeof(*(ptr)))(x)), "c" (ptr) : "ebx")
+    ({ u32 __ret_pu;\
+     asm volatile("call __put_user_8" : "=a" (__ret_pu)    \
+             : "A" ((typeof(*(ptr)))(x)), "c" (ptr) : "ebx");\
+     (int)__ret_pu;})
 #else
 #define __put_user_asm_u64(x, ptr, retval) \
     __put_user_asm(x, ptr, retval, "q", "", "Zr", -EFAULT)
-#define __put_user_x8(x, ptr, __ret_pu) __put_user_x(8, x, ptr, __ret_pu)
+#define __put_user_x8(x, ptr, __ret_pu) \
+    ({ u64 __ret_pu; __put_user_x(8, x, ptr, __ret_pu); (int)__ret_pu; })
 #endif
 
 extern void __put_user_bad(void);
@@ -239,29 +242,25 @@ extern void __put_user_8(void);
  */
 #define put_user(x, ptr)                    \
 ({                                \
-    int __ret_pu;                        \
     __typeof__(*(ptr)) __pu_val;                \
     __chk_user_ptr(ptr);                    \
     might_fault();                        \
     __pu_val = x;                        \
-    switch (sizeof(*(ptr))) {                \
-    case 1:                            \
+    __builtin_choose_expr(sizeof(*(ptr)) == 1,        \
+        ({  u8 __ret_pu;                    \
         __put_user_x(1, __pu_val, ptr, __ret_pu);    \
-        break;                        \
-    case 2:                            \
+            (int)__ret_pu;}),                \
+    __builtin_choose_expr(sizeof(*(ptr)) == 2,        \
+            ({  u16 __ret_pu;                    \
         __put_user_x(2, __pu_val, ptr, __ret_pu);    \
-        break;                        \
-    case 4:                            \
+            (int)__ret_pu;}),                \
+    __builtin_choose_expr(sizeof(*(ptr)) == 4,        \
+        ({  u32 __ret_pu;                    \
         __put_user_x(4, __pu_val, ptr, __ret_pu);    \
-        break;                        \
-    case 8:                            \
-        __put_user_x8(__pu_val, ptr, __ret_pu);        \
-        break;                        \
-    default:                        \
-        __put_user_x(X, __pu_val, ptr, __ret_pu);    \
-        break;                        \
-    }                            \
-    __ret_pu;                        \
+        (int)__ret_pu;}),                \
+    __builtin_choose_expr(sizeof(*(ptr)) == 8,        \
+        __put_user_x8(__pu_val, ptr, __ret_pu),        \
+            (void)-EFAULT))));                \
 })
 
 #define __put_user_size(x, ptr, size, retval, errret)            \
diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c
index f456860..12d27f8 100644
--- a/arch/x86/lib/delay.c
+++ b/arch/x86/lib/delay.c
@@ -112,7 +112,7 @@ EXPORT_SYMBOL(__delay);
 
 inline void __const_udelay(unsigned long xloops)
 {
-    int d0;
+    unsigned long d0;
 
     xloops *= 4;
     asm("mull %%edx"
diff --git a/arch/x86/pci/pcbios.c b/arch/x86/pci/pcbios.c
index b82cae9..dfff175 100644
--- a/arch/x86/pci/pcbios.c
+++ b/arch/x86/pci/pcbios.c
@@ -65,6 +65,7 @@ static struct {
 static unsigned long bios32_service(unsigned long service)
 {
     unsigned char return_code;    /* %al */
+    unsigned long return_code_compat; /* %eax */
     unsigned long address;        /* %ebx */
     unsigned long length;        /* %ecx */
     unsigned long entry;        /* %edx */
@@ -72,13 +73,14 @@ static unsigned long bios32_service(unsigned long
service)
 
     local_irq_save(flags);
     __asm__("lcall *(%%edi); cld"
-        : "=a" (return_code),
+        : "=a" (return_code_compat),
           "=b" (address),
           "=c" (length),
           "=d" (entry)
         : "0" (service),
           "1" (0),
           "D" (&bios32_indirect));
+    return_code = return_code_compat;
     local_irq_restore(flags);
 
     switch (return_code) {
-- 
1.5.6.5


From clattner at apple.com  Sat Jan 24 13:16:21 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 24 Jan 2009 11:16:21 -0800
Subject: [LLVMdev] -O4 limitations in llvm/llvm-gcc-4.2 2.5?
In-Reply-To: <20090124023956.GA20019@bromo.med.uc.edu>
References: <20090124023956.GA20019@bromo.med.uc.edu>
Message-ID: <7A17EDE7-2D05-45EB-8BD4-81C4760071ED@apple.com>


On Jan 23, 2009, at 6:39 PM, Jack Howarth wrote:

>   What exactly are the current limitations for using -O4 to create  
> shared
> libraries with llvm/llvm-gcc-4.2 2.5? I tried a build of xplor-nih  
> at -O4
> with llvm-gcc, llvm-g++ and llvm-gfortran. The build fails to link  
> shared
> libraries with errors such as...
>
> Building xplor-nih for platform: Darwin_9_x86

Hi Jack,

If you have Xcode 3.1.1+, the linker in /Developer/usr/bin will at / 
Developer/usr/lib/libLTO.dylib if you try to build LLVM files.  I'd  
suggest replacing /Developer/usr/lib/libLTO.dylib  with libLTO from  
LLVM 2.5 and then things should work.  It may also work to drop in  
LLVM 2.5's liblto into /usr/lib and then use /usr/bin/ld, but I've  
never tested that.

-Chris


From clattner at apple.com  Sat Jan 24 13:17:08 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 24 Jan 2009 11:17:08 -0800
Subject: [LLVMdev] new warnings
In-Reply-To: <60624B69-8078-43E7-B7BD-41C51D491B33@apple.com>
References: <60624B69-8078-43E7-B7BD-41C51D491B33@apple.com>
Message-ID: <AF33636C-83E8-4FE6-BC66-8C30E1B45C6F@apple.com>


On Jan 23, 2009, at 4:09 PM, Mike Stump wrote:

> A new warning:
>
> /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member
> function 'bool llvm::LLParser::ParseGlobal(const std::string&, const
> char*, unsigned int, bool, unsigned int)':
> /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:448: warning:
> 'IsConstant' may be used uninitialized in this function

The warning is bogus.

-Chris


From clattner at apple.com  Sat Jan 24 13:23:18 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 24 Jan 2009 11:23:18 -0800
Subject: [LLVMdev] inline asm semantics: output constraint width smaller
	than	input
In-Reply-To: <20090124172758.GA31699@elte.hu>
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu>
	<497A0C0A.7080207@gmail.com> <497B408C.20802@gmail.com>
	<20090124172758.GA31699@elte.hu>
Message-ID: <9A54B928-B0FA-46E9-B963-E24C642F09DA@apple.com>


On Jan 24, 2009, at 9:27 AM, Ingo Molnar wrote:

>> #define __put_user_size(x, ptr, size, retval, errret)            \
>> diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c
>> index f456860..12d27f8 100644
>> --- a/arch/x86/lib/delay.c
>> +++ b/arch/x86/lib/delay.c
>> @@ -112,7 +112,7 @@ EXPORT_SYMBOL(__delay);
>>
>> inline void __const_udelay(unsigned long xloops)
>> {
>> -    int d0;
>> +    unsigned long d0;
>>
>>     xloops *= 4;
>>     asm("mull %%edx"
>
> Is this all that you need (plus the 16-bit setup code tweaks) to get  
> LLVM
> to successfully build a 64-bit kernel image?
>
> If yes then this doesnt look all that bad or invasive at first sight  
> (if
> the put_user() workaround can be expressed in a cleaner way), but in  
> any
> case it would be nice to hear an LLVM person's opinion about roughly  
> when
> this is going to be solved in LLVM itself.

Hi Ingo,

We would like to support some more specific cases (e.g. when tying a  
pointer/int to a different size pointer/int) but we currently don't  
intend to support all cases (e.g. tying a FP value to int).  We are in  
this position because the semantics are very vague and hard to reason  
about (and change based on target endianness) and we had many subtle  
bugs in the corner cases.

Instead of having silent miscompiles, we decided to just reject all  
the "hard" cases and add them back one by one as there is demand.   
That way users could choose to modify their asms instead of having  
them be potentially silently miscompiled.

LLVM 2.5 is in its release process right now, so it will not have  
improvements in this area, but LLVM 2.6 certainly could.  If there is  
interest in building the kernel with 2.5, I think taking the patches  
would be worthwhile.  If that is hopeless anyway, waiting for the LLVM- 
side fixes should be fine.

-Chris

From schwab at suse.de  Sat Jan 24 14:07:02 2009
From: schwab at suse.de (Andreas Schwab)
Date: Sat, 24 Jan 2009 21:07:02 +0100
Subject: [LLVMdev] inline asm semantics: output constraint width smaller
	than input
In-Reply-To: <497B408C.20802@gmail.com> (=?iso-8859-1?Q?=22T=F6r=F6k?=
	Edwin"'s message of "Sat, 24 Jan 2009 18:23:40 +0200")
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu>
	<497A0C0A.7080207@gmail.com> <497B408C.20802@gmail.com>
Message-ID: <jebptw4gex.fsf@sykes.suse.de>

T?r?k Edwin <edwintorok at gmail.com> writes:

> @@ -239,11 +239,13 @@ extern void __put_user_8(void);
>   */
>  #define put_user(x, ptr)                    \
>  ({                                \
> -    int __ret_pu;                        \
> +    __typeof__(*(ptr)) __ret_pu;                \
>      __typeof__(*(ptr)) __pu_val;                \
>      __chk_user_ptr(ptr);                    \
>      might_fault();                        \
>      __pu_val = x;                        \
> +       /* return value is 0 or -EFAULT, both fit in 1 byte, and \
> +    * are sign-extendable to int */                \

That does not work when *ptr is unsigned (char or short).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab at suse.de
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From hpa at zytor.com  Sat Jan 24 15:10:04 2009
From: hpa at zytor.com (H. Peter Anvin)
Date: Sat, 24 Jan 2009 13:10:04 -0800
Subject: [LLVMdev] inline asm semantics: output constraint width smaller
 than	input
In-Reply-To: <9A54B928-B0FA-46E9-B963-E24C642F09DA@apple.com>
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu>
	<497A0C0A.7080207@gmail.com> <497B408C.20802@gmail.com>
	<20090124172758.GA31699@elte.hu>
	<9A54B928-B0FA-46E9-B963-E24C642F09DA@apple.com>
Message-ID: <497B83AC.5060801@zytor.com>

Chris Lattner wrote:
> 
> We would like to support some more specific cases (e.g. when tying a
> pointer/int to a different size pointer/int) but we currently don't
> intend to support all cases (e.g. tying a FP value to int).  We are in
> this position because the semantics are very vague and hard to reason
> about (and change based on target endianness) and we had many subtle
> bugs in the corner cases.
> 
> Instead of having silent miscompiles, we decided to just reject all the
> "hard" cases and add them back one by one as there is demand.  That way
> users could choose to modify their asms instead of having them be
> potentially silently miscompiled.
> 

The case that matters for the kernel is integer to integer, when a
register is re-used from input to output.

> LLVM 2.5 is in its release process right now, so it will not have
> improvements in this area, but LLVM 2.6 certainly could.  If there is
> interest in building the kernel with 2.5, I think taking the patches
> would be worthwhile.  If that is hopeless anyway, waiting for the
> LLVM-side fixes should be fine.

The patches don't look all that bad to me, but I really want to make
sure we don't keep littering the kernel with workarounds for N different
compilers without getting a track to have them cleaned up.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


From mrs at apple.com  Sat Jan 24 15:25:52 2009
From: mrs at apple.com (Mike Stump)
Date: Sat, 24 Jan 2009 13:25:52 -0800
Subject: [LLVMdev] inline asm semantics: output constraint width smaller
	than input
In-Reply-To: <497B648E.7020805@gmail.com>
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu>
	<497A0C0A.7080207@gmail.com> <497B408C.20802@gmail.com>
	<20090124172758.GA31699@elte.hu> <497B648E.7020805@gmail.com>
Message-ID: <F9975969-B497-4BBB-BAB9-A3112A12D1D0@apple.com>

On Jan 24, 2009, at 10:57 AM, T?r?k Edwin wrote:
> With an unpatched LLVM I would also need weak attributes to be on the
> function type, instead of the return type,
> but I think thats an LLVM bug, and a one-line patch corrects it.

This is indeed a bug in llvm.  We'll find a way to get it fixed.

From lennart at augustsson.net  Sat Jan 24 15:41:07 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Sat, 24 Jan 2009 21:41:07 +0000
Subject: [LLVMdev] Unimplemented documentation
In-Reply-To: <B7E2DBA2-89EF-4278-A4E0-6DC69BAE71BA@apple.com>
References: <f4876cd70901240434r451eb01dl783e527371edcd21@mail.gmail.com>
	<B7E2DBA2-89EF-4278-A4E0-6DC69BAE71BA@apple.com>
Message-ID: <f4876cd70901241341h1a37cab2je79dc3a749d92300@mail.gmail.com>

By expanded instructions I meant trying to do what fcmp on a vector
would do, but with scalar comparisons and building a bit vector.  It's
bug report 3383.

  -- Lennart

On Sat, Jan 24, 2009 at 5:01 PM, Dan Gohman <gohman at apple.com> wrote:
> On Jan 24, 2009, at 4:34 AM, Lennart Augustsson
> <lennart at augustsson.net> wrote:
>
>> Hi,
>>
>> Is there some documentation about what has not been implemented yet?
>
> I've started adding notes to
> docs/LangRef.html
>
> Historically this document has been used to describe just the LLVM IR,
> and not what specific consumers of it do or don't support, but codegen
> is a very important consumer, so I've started adding notes about its
> limitations.
>
>>
>> I'm trying to use vectors and I just run into one thing after another
>> that seem to be missing.
>> (I.e., fcmp on vectors doesn't work; trying to do the same thing with
>> expanded instructions doesn't work; select on a vector doesn't work)
>
> A common thread here is that the code generator doesn't support
> vectors of booleans very well yet. Comparisons and selects are very
> useful (and are also the first step towards more advanced conditional
> vector support), so we'd really like to see this fixed, though it will
> depend on  someone stepping forward to do the work.
>
> What do you mean by "expanded instructions"?
>
> Dan
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

From howarth at bromo.med.uc.edu  Sat Jan 24 16:25:39 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Sat, 24 Jan 2009 17:25:39 -0500
Subject: [LLVMdev]  -O4 limitations in llvm/llvm-gcc-4.2 2.5?
Message-ID: <20090124222539.GA27913@bromo.med.uc.edu>

Chris,
   Thanks for the hint. Moving over the libLTO.dylib
from llvm 2.5 solved all of the linkage errors. I was
able to completely build xplor-nih at -O4 now. The
core xplor and xplor-tcl testsuite show no regressions.
I do get 7 testcases in the xplor-python testsuite
failing with bus errors now. The xplor-tcl and xplor-python
tests are all run by tcl and python respectively loading
their xplor-nih modules. I would assume that the shared
libraries created at -O4 should look like just any other
shared library to MacOS X and that shared modules built
at -O4 should be loadable from programs like python and
tcl that aren't built with -O4, right?
                Jack
ps Interestingly PR3376 goes latent at -O4.

From howarth at bromo.med.uc.edu  Sat Jan 24 18:46:40 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Sat, 24 Jan 2009 19:46:40 -0500
Subject: [LLVMdev]  -O4 limitations in llvm/llvm-gcc-4.2 2.5?
Message-ID: <20090125004640.GA29046@bromo.med.uc.edu>

   I've had better luck compiling all of pymol 1.1r2 with
-O4 on darwin9. Everythink links and there appears to be
no regressions in the resulting code. I take it that LTO
in llvm 2.5 is still limited to dead code elimination,
correct? Will LTO ever be extended to inlining across
files as well as constant-folding and global data
allocation optimizations? Or does the reliance on gcc-4.2
as the front end prevent those sort of things from being
implemented outside of clang?
            Jack
ps Hopefully Snow Leopard will end up with llvm 2.5
for its llvm-gcc.

From nicholas at mxc.ca  Sat Jan 24 19:43:34 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 24 Jan 2009 17:43:34 -0800
Subject: [LLVMdev] -O4 limitations in llvm/llvm-gcc-4.2 2.5?
In-Reply-To: <20090125004640.GA29046@bromo.med.uc.edu>
References: <20090125004640.GA29046@bromo.med.uc.edu>
Message-ID: <497BC3C6.4040007@mxc.ca>

Jack Howarth wrote:
>    I've had better luck compiling all of pymol 1.1r2 with
> -O4 on darwin9. Everythink links and there appears to be
> no regressions in the resulting code. I take it that LTO
> in llvm 2.5 is still limited to dead code elimination,
> correct?

No.

libLTO does the equivalent to opt -internalize -ipsccp -globalopt 
-constmerge -deadargelim -instcombine -inline -prune-eh -globaldce 
-argpromotion -instcombine -jump-threading -scalarrepl -globalsmodref-aa 
-licm -gvn -memcpyopt -dse -instcombine -jump-threading -mem2reg 
-simplifycfg -globaldce

  Will LTO ever be extended to inlining across
> files as well as constant-folding and global data
> allocation optimizations?

Our optimization passes know nothing of file boundaries. That includes 
the inliner, which blissfully inlines across file boundaries.

You can read a description of these passes in our documentation at 
http://llvm.org/docs/Passes.html . Ones that make particular use of 
whole program information include ipsccp, globalopt, deadargelim, 
inline, prune-eh, argpromotion and globaldce.

Nick

  Or does the reliance on gcc-4.2
> as the front end prevent those sort of things from being
> implemented outside of clang?
>             Jack
> ps Hopefully Snow Leopard will end up with llvm 2.5
> for its llvm-gcc.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


From clattner at apple.com  Sat Jan 24 20:01:06 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 24 Jan 2009 18:01:06 -0800
Subject: [LLVMdev] -O4 limitations in llvm/llvm-gcc-4.2 2.5?
In-Reply-To: <497BC3C6.4040007@mxc.ca>
References: <20090125004640.GA29046@bromo.med.uc.edu> <497BC3C6.4040007@mxc.ca>
Message-ID: <384BFD3F-EE2F-4DDD-B38D-A7C0D963A760@apple.com>

On Jan 24, 2009, at 5:43 PM, Nick Lewycky wrote:
> Jack Howarth wrote:
>>   I've had better luck compiling all of pymol 1.1r2 with
>> -O4 on darwin9. Everythink links and there appears to be
>> no regressions in the resulting code. I take it that LTO
>> in llvm 2.5 is still limited to dead code elimination,
>> correct?
>
> No.
>
> libLTO does the equivalent to opt -internalize -ipsccp -globalopt
> -constmerge -deadargelim -instcombine -inline -prune-eh -globaldce
> -argpromotion -instcombine -jump-threading -scalarrepl - 
> globalsmodref-aa
> -licm -gvn -memcpyopt -dse -instcombine -jump-threading -mem2reg
> -simplifycfg -globaldce

Right.  Note however that LTO is significantly crippled if you don't  
use export controls.  I'd strongly recommend building the code with - 
fvisibility-hidden or using an export map at the final link stage to  
avoid exporting all symbols.  If the optimizer knows a symbol is  
private to the linked image, it can be significantly more aggressive  
with it.

-Chris

From howarth at bromo.med.uc.edu  Sat Jan 24 21:35:28 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Sat, 24 Jan 2009 22:35:28 -0500
Subject: [LLVMdev] gfortran benchmarks
Message-ID: <20090125033528.GA29704@bromo.med.uc.edu>

   Since the fact that gfortran performance has improved
over the major releases, I decided to benchmark the current
releases on a MacPro with the Polyhedron 2005 benchmarks
using -ffast-math -funroll-loops -msse3 -O3. The results
are...

                    gcc release
            gcc 4.2.4      gcc 4.3.3    gcc 4.4-pre   gcc 4.3.3/   gcc 4.4-pre/
                                                      gcc 4.2.4    gcc 4.2.4
ac          15.32          13.04        12.65         0.851        0.826
aermod      22.96          26.65        25.52         1.161        1.111
air         8.15           7.58         7.10          0.930        0.871
capacita    52.16          52.45        49.56         1.006        0.950
channel     5.17           3.39         1.81          0.656        0.350
doduc       34.43          34.89        35.28         1.013        1.025
fatigue     12.57          10.92        10.13         0.869        0.806
gas_dyn     13.59          7.68         7.63          0.565        0.561
induct      28.61          48.46        14.88         1.694        0.520
linpk       15.46          15.48        15.50         1.001        1.003
mdbx        12.41          12.94        12.36         1.043        0.996
nf          27.08          27.25        25.50         1.006        0.942
protein     41.61          41.18        39.12         0.990        0.940
rnflow      35.37          32.58        30.68         0.921        0.867
test_fpu    11.94          10.79        10.50         0.904        0.879
tfft        2.13           2.11         2.08          0.991        0.977

Certainly it would be nice eventually resync llvm-gcc against something
newer.
             Jack

From howarth at bromo.med.uc.edu  Sat Jan 24 23:01:06 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Sun, 25 Jan 2009 00:01:06 -0500
Subject: [LLVMdev] -O4 -fvisibility=hidden
Message-ID: <20090125050106.GA30107@bromo.med.uc.edu>

   After trying the recommended use of -O4 -fvisibility=hidden to
compile xplor-nih with full LTO optimizations, I discovered three
symbols become undefined...

llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o  \
	   \
	  -L. -lxplorCmd -lxplor -L/Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ -lfft -lintVar -lvmd -lpy -lswigpy-xplor -ltclXplor -lswigtcl8-xplor -lnmrPot -lcommon -lmarvin  \
	     -lcrypto  -L/sw/lib/llvm-gcc-4.2/lib -lgfortran -llapack -lblas   -L/Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ \
	   
Undefined symbols:
  "_xplorwrapproc_slave_", referenced from:
      llvm bitcode in xplor.o
  "_python_interp_", referenced from:
      llvm bitcode in xplor.o
  "_tcl_interp_", referenced from:
      llvm bitcode in xplor.o
ld: symbol(s) not found

These are all defined as extern as follows...

extern "C" void
FORTRAN(tcl_interp)   (const long&          canReturn,
                             long&          qterm,
                             long&          fd)

extern "C" void
FORTRAN(python_init)(const long&         argc,
                           char**        argv)

extern "C" void FORTRAN(xplorwrapproc_slave)();

The only symbols that become undefined are those extern
symbols which calling fortran routines from c++ code.
I'll look into creating a testcase and opening a PR for
this issue.
               Jack

From jon at ffconsultancy.com  Sun Jan 25 02:21:19 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Sun, 25 Jan 2009 08:21:19 +0000
Subject: [LLVMdev] Hoisting constant arguments from recursive functions
Message-ID: <200901250821.19927.jon@ffconsultancy.com>


I am just considering various different designs for the code emitted by a HLVM 
and one alluring approach is to make all local variables immutable and 
replace loops with (tail) recursive functions. This makes it much easier to 
reason about injected code such as GC checks. However, I am concerned about 
the performance of the generated code.

Specifically, this is likely to result in small recursive functions that 
accept a large number of arguments, many of which have values that remain the 
same from one application/iteration to the next.

For example, a function to fill an array might become:

  let rec fill a i x =
    if i < length a then
      a.(i) <- x
      fill a (i + 1) x

where "a" and "x" have the same value from one call to the next and only the 
loop variable "i" changes.

My question is: will LLVM optimize this back into a function containing a loop 
that runs inside a single stack frame that contains the constants "a" and "x" 
or should my compiler perform this rewrite itself?

Also, would any simple rearrangements help LLVM, such as putting the constant 
function arguments to the back of the argument list?

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From isanbard at gmail.com  Sun Jan 25 02:32:35 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sun, 25 Jan 2009 00:32:35 -0800
Subject: [LLVMdev] gfortran benchmarks
In-Reply-To: <20090125033528.GA29704@bromo.med.uc.edu>
References: <20090125033528.GA29704@bromo.med.uc.edu>
Message-ID: <A8F43A86-EA3D-4071-8DB4-CF2BF70F9F9D@gmail.com>

On Jan 24, 2009, at 7:35 PM, Jack Howarth wrote:

>   Since the fact that gfortran performance has improved
> over the major releases, I decided to benchmark the current
> releases on a MacPro with the Polyhedron 2005 benchmarks
> using -ffast-math -funroll-loops -msse3 -O3. The results
> are...
>
>                    gcc release
>            gcc 4.2.4      gcc 4.3.3    gcc 4.4-pre   gcc 4.3.3/    
> gcc 4.4-pre/
>                                                      gcc 4.2.4     
> gcc 4.2.4
> ac          15.32          13.04        12.65         0.851         
> 0.826
> aermod      22.96          26.65        25.52         1.161         
> 1.111
> air         8.15           7.58         7.10          0.930         
> 0.871
> capacita    52.16          52.45        49.56         1.006         
> 0.950
> channel     5.17           3.39         1.81          0.656         
> 0.350
> doduc       34.43          34.89        35.28         1.013         
> 1.025
> fatigue     12.57          10.92        10.13         0.869         
> 0.806
> gas_dyn     13.59          7.68         7.63          0.565         
> 0.561
> induct      28.61          48.46        14.88         1.694         
> 0.520
> linpk       15.46          15.48        15.50         1.001         
> 1.003
> mdbx        12.41          12.94        12.36         1.043         
> 0.996
> nf          27.08          27.25        25.50         1.006         
> 0.942
> protein     41.61          41.18        39.12         0.990         
> 0.940
> rnflow      35.37          32.58        30.68         0.921         
> 0.867
> test_fpu    11.94          10.79        10.50         0.904         
> 0.879
> tfft        2.13           2.11         2.08          0.991         
> 0.977
>
> Certainly it would be nice eventually resync llvm-gcc against  
> something
> newer.

There are some heavy licensing issues involved in this (which I won't  
go into here) that make this difficult. I don't think that the problem  
is the version of GCC we're using as a front-end, but rather how our  
optimizations perform compared with GCC's optimizations. We don't  
really use any of GCC's optimizations for the code we generate.

-bw


From devlists at shadowlab.org  Sun Jan 25 04:38:48 2009
From: devlists at shadowlab.org (Jean-Daniel Dupas)
Date: Sun, 25 Jan 2009 11:38:48 +0100
Subject: [LLVMdev] -O4 -fvisibility=hidden
In-Reply-To: <20090125050106.GA30107@bromo.med.uc.edu>
References: <20090125050106.GA30107@bromo.med.uc.edu>
Message-ID: <90056C77-B086-4B84-823E-389C34898984@shadowlab.org>


Le 25 janv. 09 ? 06:01, Jack Howarth a ?crit :

>   After trying the recommended use of -O4 -fvisibility=hidden to
> compile xplor-nih with full LTO optimizations, I discovered three
> symbols become undefined...
>
> llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o  \
> 	   \
> 	  -L. -lxplorCmd -lxplor -L/Users/howarth/xplor-nih-2.21/ 
> bin.Darwin_9_x86/ -lfft -lintVar -lvmd -lpy -lswigpy-xplor - 
> ltclXplor -lswigtcl8-xplor -lnmrPot -lcommon -lmarvin  \
> 	     -lcrypto  -L/sw/lib/llvm-gcc-4.2/lib -lgfortran -llapack - 
> lblas   -L/Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ \
> 	
> Undefined symbols:
>  "_xplorwrapproc_slave_", referenced from:
>      llvm bitcode in xplor.o
>  "_python_interp_", referenced from:
>      llvm bitcode in xplor.o
>  "_tcl_interp_", referenced from:
>      llvm bitcode in xplor.o
> ld: symbol(s) not found
>
> These are all defined as extern as follows...
>
> extern "C" void
> FORTRAN(tcl_interp)   (const long&          canReturn,
>                             long&          qterm,
>                             long&          fd)
>
> extern "C" void
> FORTRAN(python_init)(const long&         argc,
>                           char**        argv)
>
> extern "C" void FORTRAN(xplorwrapproc_slave)();
>

defining them as extern is not enough to mark them as "exported".

You should use the visibility attribute.

extern "C" void FORTRAN(xplorwrapproc_slave)()  
__attribute__((visibility("default")));

> The only symbols that become undefined are those extern
> symbols which calling fortran routines from c++ code.
> I'll look into creating a testcase and opening a PR for
> this issue.
>               Jack





From marks at dcs.gla.ac.uk  Sun Jan 25 05:41:21 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Sun, 25 Jan 2009 11:41:21 +0000
Subject: [LLVMdev] Getting address of label in jitted code
In-Reply-To: <50179974-3868-4649-8DC9-2C3935BF01F9@apple.com>
References: <mailman.648.1232678602.20833.llvmdev@cs.uiuc.edu><4979A89B.9000301@dcs.gla.ac.uk><6EBC0175-7A6F-45D0-87BB-85362054179A@apple.com><497A0737.20503@dcs.gla.ac.uk>
	<50179974-3868-464