From viridia at gmail.com  Tue Sep  1 00:03:18 2009
From: viridia at gmail.com (Talin)
Date: Mon, 31 Aug 2009 22:03:18 -0700
Subject: [LLVMdev] Perfect forwarding?
In-Reply-To: <3f49a9f40908301543o4eb88d95idc38237d9ab90160@mail.gmail.com>
References: <4A9ADF1B.8010403@gmail.com>	<3f49a9f40908301539g2993e48bv24772efa578f259c@mail.gmail.com>
	<3f49a9f40908301543o4eb88d95idc38237d9ab90160@mail.gmail.com>
Message-ID: <4A9CAB16.20602@gmail.com>

OvermindDL1 wrote:
> BLAST!  LLVM mailing list headers are still royally screwed up...
> My message is below...
>
> On Sun, Aug 30, 2009 at 2:20 PM, Talin<viridia at gmail.com> wrote:
>   
>> Hey all, it's been a while since I have posted on this list, but I've
>> been continuing my work with LLVM and getting lots done :)
>>
>> One question I wanted to ask is whether anyone had any advice on how to
>> implement "perfect forwarding" in a runtime (as opposed to compile-time)
>> context with LLVM. The general idea is that you have a bunch of methods
>> that have different call signatures, and you want to have some generic
>> handler function that can intercept these calls and then forward each
>> call to another method that has the same signature as the original call.
>>
>> A typical example of how this would be used is something like Mockito or
>> EasyMock - you have some interface, and you dynamically create an
>> implementation of that interface which is able to intercept all of the
>> method calls and record the order in which they are called and the value
>> of the arguments. The unit test code then performs some validation on
>> the recording to ensure that the invocations match what was expected.
>>
>> The key point is that the handler method doesn't know at compile-time
>> the call signature of the various methods that are going to be
>> intercepted. In the case of Java and C#, the VM is able to box all of
>> the arguments that are primitive types, and pass to the handler method
>> an array of type Object[]. Similarly, one can call method.invoke() on a
>> method, passing in that same array of objects, and the VM will unbox the
>> primitive types and then call the actual method with the right argument
>> types.
>>
>> One obvious way to do this is to generate two stub functions for every
>> function emitted by the compiler, one that takes the original argument
>> signature and creates a list of boxed objects, and one that takes a list
>> of boxed objects, unboxes them and then calls the function. However,
>> that's a lot of extra code to generate, and I am concerned about the
>> amount of code bloat that would create.
>>
>> What would be better is if there was some way for the generic handler
>> function to be able to dynamically get a picture of the layout of the
>> call frame. On the receiving end, this would be something similar to a
>> varargs call, where the called function unpacks the argument list based
>> on a runtime-provided schema. One problem with the varargs approach is
>> that I wouldn't want every method call to have to use the varargs
>> calling convention.
>>
>> On the calling side, I'm not sure that any language has a means to
>> dynamically construct an argument list for a call. If such a thing did
>> exist, what I suppose it would do is given a description of a function's
>> calling signature, figure out which arguments should be put in which
>> registers and which should be pushed on the stack. In other words, to do
>> at runtime what LLVM currently does at compile time.
>>     
>
> Actually many languages have such means to do that, Python is probably
> the most easy.  You can even do so for C++ using Boost.Fusion
> (Boost.Fusion has an invoke method that can call any arbitrary
> function/functor with a vector of parameters, it also has a lot more
> stuff, Boost.Fusion also has thing that allow C++ get the closest to
> perfect forwarding then C++ has ever got before).  Although
> Boost.Fusion is not usable in the LLVM world, the way it works is.  I
> have even used it to implement a C++ network RPC system that
> serializes up the arguments, handles pointers/references/const'ness
> correctly, handles sync of network objects, and is used like any
> normal C++ function.  It let me create this syntax:
>   
I should have been more specific - I'm aware of Python's abilities in 
this regard, and I've used it a number of times before. What I should 
have said was that I wasn't aware of any statically compiled language 
that can dynamically construct a call frame.

What C++ does is something different - it pre-generates at compile time 
a stub function for each permutation of statically typed arguments. 
These stub functions box/unbox the arguments. That is a powerful 
feature, but I don't think it is as powerful as, say, Java's "Proxy" 
capability which can operate on whole classes rather than individual 
methods. C++ templates have no way to iterate over all of the members of 
a class, however if the stub function generator was built into the 
compiler to begin with then you wouldn't need to - once you have the 
ability to intercept any method call generically, you can do at runtime 
what you would normally use templates to do at compile time. (I've 
noticed that metaprogramming and reflection tend to get used for similar 
things.) Which approach (runtime or compile time) is better is really 
just a time vs. space tradeoff.

One approach that I have been considering is rather than generating a 
pair of stub functions for each normal function, instead generate a pair 
of stub functions for each unique type signature - the idea being that 
two methods that have the same calling signature can use the same 
argument boxing/unboxing logic. The number of permutations could be 
reduced further by weakening the type signature - i.e. convert all 
pointer arguments to void* and so on.

Each stub function would have a function name which is generated from 
the type signature of the arguments, and then these functions would be 
given "linkonce" linkage, so that duplicates would get coalesced at link 
time.

What's missing from this picture is a scheme for encoding a set of LLVM 
argument types as a string function name. In particular, I'd need some 
way to accomodate "structs as first class data types" arguments.

> // example used code
> class someClass : public NetworkIDObject {
> public:
>    void someMethod(float f) {
>        // do other stuff
>    }
> }
>
> // If someClass did not have NetworkIDObject as a child anywhere in
> its multibase hierarchy, then the class itself is serialized up as if
> by value, then passed to the remote function by pointer when
> deserialized (on the stack, eh, eh?, has to be default constructable
> to support that, or the registerRPCCall below will not even compile,
> yes this is completely typesafe in every way)
> void _testFunc(int i, someClass *ptr) {
>    // do something
> }
>
> // example syntax
> networkWorld::RPCCaller testFunc =
> networkWorld->registerRPCCall("testFunc",&testFunc,enumCallOnClientOnly);
> networkWorld::RPCCaller someMethod =
> networkWorld->registerRPCCall("someMethod",&someClass::someMethod,enumCallOnServerOnly);
>
> // then use it as a normal function, it uses near perfect forwarding
> (more perfect the anything else in C++) if it will be called on the
> local machine, or serialized up if called remotely:
> someClass s;
>
> testFunc(42, &s);
>
> someMethod(&s, 3.14);
>
> No macros, no pre-processing, all pure C++ thanks to Boost.Fusion.
>
> The way it works is that the creater, the registerRPCCall, builds up a
> recursive function (which every modern C++ compiler levels to a single
> call in assembly I have noticed), one for each and every argument the
> function takes, then Boost.Phoenix.Bind binds the method to the
> networkWorld instance and returns it in a struct that only has two
> members, the built-up call, and the original function pointer.
>
> At call time (like calling testFunc above) the struct recursively
> builds up another function list (that the compiler levels to a single
> call), one for each passed in type.  If the call will be locally then
> it passes the function pointer to that struct and invokes that
> function with the passed in params (near perfectly forwarded, try
> getting it this perfect in C++ other way I dare you).  If the call is
> remote then it calls the built up function with the bitstream of the
> network lib I wrote this for (RakNet, the 'new' RPC functionality in
> it is what I wrote, download the code and take a look), the built up
> function then serializes the types into the bitstream, and sends it
> out across the network.
>
> So, as you can see it calls handling function that are built up based
> on the parameters, you can do that same thing in LLVM (heck, used
> Boost.Fusion to build an example and compile it using llvm-gcc and see
> what LLVM code it creates).  :)
>
> Then there are things like Python where all non-keyword arguments are
> in an array and all keyword arguments are in a dictionary, it just
> hides it all behind a normal function call syntax, but you can still
> do things like this:
>
> def testFunc(a, b, c):
>    pass # do stuff
>
> testFunc(1,2,3)
> testFunc(1,c=3,b=2) # = testFunc(1,2,3)
> arr = [1,2,3]
> testFunc(*arr) # = testFunc(1,2,3)
> arr = [1]
> kw = {b:2,c:3}
> testFunc(*arr,**kw) # testFunc(1,2,3)
> ks = {a:1,b:2,c:3}
> testFunc(**kw) # testFunc(1,2,3)
>
>  and so forth.  Slower dispatching, but very powerful.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>   


From overminddl1 at gmail.com  Tue Sep  1 00:57:38 2009
From: overminddl1 at gmail.com (OvermindDL1)
Date: Mon, 31 Aug 2009 23:57:38 -0600
Subject: [LLVMdev] Perfect forwarding?
In-Reply-To: <3f49a9f40908312253g35f9b48ai1a673ef3c8c2622f@mail.gmail.com>
References: <4A9ADF1B.8010403@gmail.com>
	<3f49a9f40908301539g2993e48bv24772efa578f259c@mail.gmail.com>
	<3f49a9f40908301543o4eb88d95idc38237d9ab90160@mail.gmail.com>
	<4A9CAB16.20602@gmail.com>
	<3f49a9f40908312253g35f9b48ai1a673ef3c8c2622f@mail.gmail.com>
Message-ID: <3f49a9f40908312257r4c7cb66t18f4d067b1d78399@mail.gmail.com>

Blast!  LLVM mailing server *still* has the headers broken...

On Mon, Aug 31, 2009 at 11:03 PM, Talin<viridia at gmail.com> wrote:
> OvermindDL1 wrote:
>>
>> BLAST!  LLVM mailing list headers are still royally screwed up...
>> My message is below...
>>
>> On Sun, Aug 30, 2009 at 2:20 PM, Talin<viridia at gmail.com> wrote:
>>
>>>
>>> Hey all, it's been a while since I have posted on this list, but I've
>>> been continuing my work with LLVM and getting lots done :)
>>>
>>> One question I wanted to ask is whether anyone had any advice on how to
>>> implement "perfect forwarding" in a runtime (as opposed to compile-time)
>>> context with LLVM. The general idea is that you have a bunch of methods
>>> that have different call signatures, and you want to have some generic
>>> handler function that can intercept these calls and then forward each
>>> call to another method that has the same signature as the original call.
>>>
>>> A typical example of how this would be used is something like Mockito or
>>> EasyMock - you have some interface, and you dynamically create an
>>> implementation of that interface which is able to intercept all of the
>>> method calls and record the order in which they are called and the value
>>> of the arguments. The unit test code then performs some validation on
>>> the recording to ensure that the invocations match what was expected.
>>>
>>> The key point is that the handler method doesn't know at compile-time
>>> the call signature of the various methods that are going to be
>>> intercepted. In the case of Java and C#, the VM is able to box all of
>>> the arguments that are primitive types, and pass to the handler method
>>> an array of type Object[]. Similarly, one can call method.invoke() on a
>>> method, passing in that same array of objects, and the VM will unbox the
>>> primitive types and then call the actual method with the right argument
>>> types.
>>>
>>> One obvious way to do this is to generate two stub functions for every
>>> function emitted by the compiler, one that takes the original argument
>>> signature and creates a list of boxed objects, and one that takes a list
>>> of boxed objects, unboxes them and then calls the function. However,
>>> that's a lot of extra code to generate, and I am concerned about the
>>> amount of code bloat that would create.
>>>
>>> What would be better is if there was some way for the generic handler
>>> function to be able to dynamically get a picture of the layout of the
>>> call frame. On the receiving end, this would be something similar to a
>>> varargs call, where the called function unpacks the argument list based
>>> on a runtime-provided schema. One problem with the varargs approach is
>>> that I wouldn't want every method call to have to use the varargs
>>> calling convention.
>>>
>>> On the calling side, I'm not sure that any language has a means to
>>> dynamically construct an argument list for a call. If such a thing did
>>> exist, what I suppose it would do is given a description of a function's
>>> calling signature, figure out which arguments should be put in which
>>> registers and which should be pushed on the stack. In other words, to do
>>> at runtime what LLVM currently does at compile time.
>>>
>>
>> Actually many languages have such means to do that, Python is probably
>> the most easy.  You can even do so for C++ using Boost.Fusion
>> (Boost.Fusion has an invoke method that can call any arbitrary
>> function/functor with a vector of parameters, it also has a lot more
>> stuff, Boost.Fusion also has thing that allow C++ get the closest to
>> perfect forwarding then C++ has ever got before).  Although
>> Boost.Fusion is not usable in the LLVM world, the way it works is.  I
>> have even used it to implement a C++ network RPC system that
>> serializes up the arguments, handles pointers/references/const'ness
>> correctly, handles sync of network objects, and is used like any
>> normal C++ function.  It let me create this syntax:
>>
>
> I should have been more specific - I'm aware of Python's abilities in this
> regard, and I've used it a number of times before. What I should have said
> was that I wasn't aware of any statically compiled language that can
> dynamically construct a call frame.
>
> What C++ does is something different - it pre-generates at compile time a
> stub function for each permutation of statically typed arguments. These stub
> functions box/unbox the arguments. That is a powerful feature, but I don't
> think it is as powerful as, say, Java's "Proxy" capability which can operate
> on whole classes rather than individual methods. C++ templates have no way
> to iterate over all of the members of a class, however if the stub function
> generator was built into the compiler to begin with then you wouldn't need
> to - once you have the ability to intercept any method call generically, you
> can do at runtime what you would normally use templates to do at compile
> time. (I've noticed that metaprogramming and reflection tend to get used for
> similar things.) Which approach (runtime or compile time) is better is
> really just a time vs. space tradeoff.
>
> One approach that I have been considering is rather than generating a pair
> of stub functions for each normal function, instead generate a pair of stub
> functions for each unique type signature - the idea being that two methods
> that have the same calling signature can use the same argument
> boxing/unboxing logic. The number of permutations could be reduced further
> by weakening the type signature - i.e. convert all pointer arguments to
> void* and so on.
>
> Each stub function would have a function name which is generated from the
> type signature of the arguments, and then these functions would be given
> "linkonce" linkage, so that duplicates would get coalesced at link time.
>
> What's missing from this picture is a scheme for encoding a set of LLVM
> argument types as a string function name. In particular, I'd need some way
> to accomodate "structs as first class data types" arguments.

Boost.Fusion has adapters to convert structs/classes into
tuples/kwtuples.  You have to write the short and simple adapter for
your classes, but it would allow you to iterate over
everything/anything in it.  I have done this exact thing.  Not quite
fully what you want, but Boost.Fusion and other bits of other boost
metalibraries seem to do most of what you want.  Might be interesting
to look at?

From sanjiv.gupta at microchip.com  Tue Sep  1 02:02:41 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 01 Sep 2009 12:32:41 +0530
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <4A9C10D6.703@microchip.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
	<4A9C10D6.703@microchip.com>
Message-ID: <4A9CC711.2060503@microchip.com>

Here are the results for clang testing.

****************************************************
Macine details:
Linux 2.6.28-11-server #42-Ubuntu SMP i686 GNU/Linux.
****************************************************

****************************************************
Configured as srcdir != objdir  with clang.
****************************************************

*****************************************************
Results of make check on top level objs directory.
*****************************************************

# of expected passes            4126
# of expected failures          26
make[1]: Leaving directory `/home/i00171/2.6/objs/test'

*****************************************************
Results of make -C tools/clang test VERBOSE=1
*****************************************************
Running 1461 tests, 2 threads.

Failing Tests (2):
        
/home/i00171/2.6/llvm-2.6/tools/clang/test/CodeGen/flexible-array-init.c
        
/home/i00171/2.6/llvm-2.6/tools/clang/test/CodeGenObjC/debug-info-linkagename.m

Failures: 2
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/i00171/2.6/objs/tools/clang/test'
make: *** [test] Error 2
make: Leaving directory `/home/i00171/2.6/objs/tools/clang'







Sanjiv Gupta wrote:
> Tanya Lattner wrote:
>   
>> LLVMers,
>>
>> 2.6 pre-release1 is ready to be tested by the community. 
>> http://llvm.org/prereleases/2.6/
>>
>> You will notice that we have quite a few pre-compiled binaries (of 
>> both clang and llvm-gcc). We have identified several bugs that will be 
>> fixed in pre-release2, so please search the bug database before filing 
>> a new bug.
>>
>> If you have time, I'd appreciate anyone who can help test the release.
>>
>> To test llvm-gcc:
>>
>> 1) Compile llvm from source and untar the llvm-test in the projects 
>> directory (name it llvm-test or test-suite). Choose to use a 
>> pre-compiled llvm-gcc or re-compile it yourself.
>> 2) Run make check, report any failures (FAIL or unexpected pass). Note 
>> that you need to reconfigure llvm with llvm-gcc in your path or with 
>> --with-llvmgccdir
>> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>>
>>
>> To test clang:
>> 1) Compile llvm and clang from source.
>> 2) Run make check for llvm.
>> 3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or 
>> unexpected passes)
>>
>> When reporting your results, please provide details on what platform 
>> you compiled on, and how
>> you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.
>>
>> Please COMPLETE ALL TESTING BY end of the day on Sept. 5th!
>>
>> Thanks,
>> Tanya Lattner
>>
>>   
>>     
> Tanya,
> I can take up the clang part of testing.
>
>
> - Sanjiv
>
>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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 rengolin at systemcall.org  Tue Sep  1 03:40:07 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Tue, 1 Sep 2009 09:40:07 +0100
Subject: [LLVMdev] C++ Interpreter
In-Reply-To: <B7E97C1D-2A7A-4DC6-A4E6-C839885DE4AD@apple.com>
References: <4A9C1F4D.2080108@cern.ch>
	<d9b9d95f0908311319l4d412334p5c8a230d89e66f87@mail.gmail.com>
	<B7E97C1D-2A7A-4DC6-A4E6-C839885DE4AD@apple.com>
Message-ID: <d9b9d95f0909010140q1cdc2803x5e3d07a0c0a25146@mail.gmail.com>

2009/8/31 Douglas Gregor <dgregor at apple.com>:
> Clang is meant to be flexible enough to be used as the basis for a C++
> interpreter. However, there will probably be a bit of work to do in Clang to
> make this happen, e.g., by providing clean APIs for an interpreter to call
> into Clang's parser to parse a new expression/statement/function.

Ok, my bad, language barrier. ;)

Speaking of those APIs, I guess if you do have something of the sort,
it may be easy to evaluate expressions and understanding the structure
of a program on a debugger.

If you manage to parse dwarf information on the same structure as
clang (or the interpreter) does with code, one can later list the
members of a class, print their values etc.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From Axel.Naumann at cern.ch  Tue Sep  1 04:00:23 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Tue, 1 Sep 2009 11:00:23 +0200
Subject: [LLVMdev] C++ Interpreter
In-Reply-To: <d9b9d95f0909010140q1cdc2803x5e3d07a0c0a25146@mail.gmail.com>
References: <4A9C1F4D.2080108@cern.ch>	
	<d9b9d95f0908311319l4d412334p5c8a230d89e66f87@mail.gmail.com>	
	<B7E97C1D-2A7A-4DC6-A4E6-C839885DE4AD@apple.com>
	<d9b9d95f0909010140q1cdc2803x5e3d07a0c0a25146@mail.gmail.com>
Message-ID: <4A9CE2A7.9060506@cern.ch>

Hi Renato,

Renato Golin wrote on 09/01/2009 10:40 AM:
> 2009/8/31 Douglas Gregor <dgregor at apple.com>:
>> Clang is meant to be flexible enough to be used as the basis for a C++
>> interpreter. However, there will probably be a bit of work to do in Clang to
>> make this happen, e.g., by providing clean APIs for an interpreter to call
>> into Clang's parser to parse a new expression/statement/function.
> 
> Speaking of those APIs, I guess if you do have something of the sort,
> it may be easy to evaluate expressions and understanding the structure
> of a program on a debugger.

Correct. As a matter of fact we use the current interpreter's knowledge 
also for introspection and serialization.

> If you manage to parse dwarf information on the same structure as
> clang (or the interpreter) does with code, one can later list the
> members of a class, print their values etc.

Right, having a working interactive C++ interpreter would also help for 
a debugger, as you said assuming that the symbols "are there". Function 
calls will be possible, too; you could also create objects in the 
interpreter stack and evaluate them.

So - are you interested? :-)

Cheers, Axel.

From samuraileumas at yahoo.com  Tue Sep  1 07:12:35 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Tue, 1 Sep 2009 05:12:35 -0700 (PDT)
Subject: [LLVMdev] accessing a bitcode library exported from C++ using
	the JIT
In-Reply-To: <3f49a9f40908311847i2589162fted3b7ac59a976c18@mail.gmail.com>
References: <232756.2319.qm@web62005.mail.re1.yahoo.com>
	<f5aa3e9b0908311349r51fa4caevf056dd71ed23932d@mail.gmail.com>
	<848807.62604.qm@web62003.mail.re1.yahoo.com>
	<3f49a9f40908311847i2589162fted3b7ac59a976c18@mail.gmail.com>
Message-ID: <653555.4667.qm@web62007.mail.re1.yahoo.com>

Hello OvermindDL1,

We are implementing an extensible language.  That's one where you can add commands and constructs to the language without having to recompile the parser.  We want compilation of the parser in order to "freeze" it but only as an option.  One goal is to eventually get the macro functions of our language to the point where they are equivalent to the template functions of C++ so we can make a self-hosting langauge.

Also, all of the action nodes in our example PEG parser are written in LLVM Assembly rather than only C++ (although they call functions from a C++ library) so I doubt it would work in Spirit2.1 without writing a syntax converter.  The syntax converter may come in time but it's only optional.  If you're really interested in a partially finished example parser, it is at http://mattathias.cvs.sourceforge.net/viewvc/mattathias/mattathias/modules/front_ends/Amos/ .  It contains a PEG parser file and the source to a C++ library included in that PEG file.


Thanks for your interest,

--Sam


----- Original Message ----
> From: OvermindDL1 <overminddl1 at gmail.com>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Monday, August 31, 2009 8:47:05 PM
> Subject: Re: [LLVMdev] accessing a bitcode library exported from C++ using the JIT
> 
> On Mon, Aug 31, 2009 at 6:23 PM, Samuel Crowwrote:
> > If you're wondering why we're doing an interpreted PEG parser generator rather 
> than Boost Spirit 2.x, it's because we need it to be easier to debug the parser. 
>  Once the parser is debugged it can be fed into a compiled parser generator and 
> "frozen" into stand-alone parser code.
> 
> You do know that Spirit2.1 has very nice debugging facilities,
> everything from error handlers so you can handle parsing failures to
> getting detailed info reports on the entire processing process (of
> which you can do something like dump it to cout or something and you
> get this nice tree of everything that is tried, what passes, what
> fails, etc...).  It is exceedingly detailed, so I am not sure what
> your homegrown one would have over it, if you have an example then I
> could add that functionality to Boost.Spirit2.1.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



      

From andrelct at dcc.ufmg.br  Tue Sep  1 07:25:55 2009
From: andrelct at dcc.ufmg.br (Andre Tavares)
Date: Tue, 01 Sep 2009 09:25:55 -0300
Subject: [LLVMdev] [llvm-commits] SSI Patch
In-Reply-To: <4A97E668.9060807@dcc.ufmg.br>
References: <4A97E668.9060807@dcc.ufmg.br>
Message-ID: <4A9D12D3.1040704@dcc.ufmg.br>

I tried to make 5 separate patches, but as they are constructive, they 
had information from the last one. So I will post one by one as it gets 
on the tree.

1. We had a function isUsedInTerminator that tested if a comparator was 
used in the terminator of its parent BasicBlock. This is wrong because a 
comparator can be created in a BasicBlock and used in the terminator of 
other BasicBlock, and can be used in more than one.

Patch attached

Andre Tavares wrote:
> I did a bunch of modifications on SSI. Most of them to make it faster, 
> and a few inconsistencies I found. I will list what I did.
>
> 1. We had a function isUsedInTerminator that tested if a comparator 
> was used in the terminator of its parent BasicBlock. This is wrong 
> because a comparator can be created in a BasicBlock and used in the 
> terminator of other BasicBlock, and can be used in more than one.
>
> 2. There was that list of all variables converted to SSI. I decided to 
> remove it as you guys didn't like to have list holding memory. Now 
> insertSigma tests if a sigma is already there before it inserts any.
>
> 3. InsertSSIphi had the test if (DF_BB == DF->end()) twice, one with 
> break and the other with continue.  I kept the continue, which is the 
> correct one.
>
> 4.  I changed the order in which we rename variables, and now fixphis 
> will only need to get the case where a predecessor of a phi is 
> missing, it will not have to change value for any phi anymore, because 
> I insert the right information on the first time.
>
> 5.  SSI is not pruned anymore. To have it pruned we needed to test if 
> a PHI or SIGMA dominated any use of the original variable. This costs 
> time, and a pruned SSI is not under SSI rules. This was not a problem 
> for ABCD, but could be for any other optimization that used it. So all 
> PHIS and SIGMAS related to branch instructions are inserted. Those 
> other optimization passes can remove them later if necessary.
>
> Regards,
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-- 
Andre Tavares
Master Student in Computer Science - UFMG - Brasil
http://dcc.ufmg.br/~andrelct

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssi1.patch
Type: text/x-diff
Size: 3546 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090901/8ee25868/attachment.bin 

From luoyonggang at gmail.com  Tue Sep  1 09:26:55 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Tue, 1 Sep 2009 22:26:55 +0800
Subject: [LLVMdev] I have ever found MSVC building is failing ,
	but now it's working 	fine, I want to know why
Message-ID: <806065d90909010726g783e5de5of3bf0a6e9f01fac2@mail.gmail.com>

The buildbot ever showed that cmake generating the msvc sln file
failure, but few days later, it's fixed.
How it's fixed, I doesn't see the information.
Is it downgrade the msvc or other solutions?

-- 
         ??
?
???
Yours
    sincerely,
Yonggang Luo


From luoyonggang at gmail.com  Tue Sep  1 09:28:28 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Tue, 1 Sep 2009 22:28:28 +0800
Subject: [LLVMdev] By the way, the information that i faced is
Message-ID: <806065d90909010728y1e7a4a42q71fe9023179cfa45@mail.gmail.com>

Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 9.0/VC/bin/cl.exe -- broken
CMake Error at D:/Tools/Building/cmake/share/cmake-2.7/Modules/CMakeTestCCompiler.cmake:37
(MESSAGE):
  The C compiler "C:/Program Files (x86)/Microsoft Visual Studio
  9.0/VC/bin/cl.exe" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: D:/objs/llvm/msvc/ide/CMakeFiles/CMakeTmp



  Run Build Command:C:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com
  CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec



  Microsoft (R) Visual Studio Version 9.0.30729.1.

  Copyright (C) Microsoft Corp.  All rights reserved.

  1>------ Build started: Project: cmTryCompileExec, Configuration: Debug
  Win32 ------

  1>Embedding manifest...

  1>.\cmTryCompileExec.dir\Debug\cmTryCompileExec.exe.intermediate.manifest :
  general error c1010070: Failed to load and parse the manifest.  {_~0    v

  1>Build log was saved at
  "file://d:\objs\llvm\msvc\ide\CMakeFiles\CMakeTmp\cmTryCompileExec.dir\Debug\BuildLog.htm"


  1>cmTryCompileExec - 1 error(s), 0 warning(s)

  ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
  ==========





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:3 (project)



How to deal with such a problem:(
-- 
         ??
?
???
Yours
    sincerely,
Yonggang Luo


From overminddl1 at gmail.com  Tue Sep  1 10:59:51 2009
From: overminddl1 at gmail.com (OvermindDL1)
Date: Tue, 1 Sep 2009 09:59:51 -0600
Subject: [LLVMdev] accessing a bitcode library exported from C++ using
	the JIT
In-Reply-To: <653555.4667.qm@web62007.mail.re1.yahoo.com>
References: <232756.2319.qm@web62005.mail.re1.yahoo.com>
	<f5aa3e9b0908311349r51fa4caevf056dd71ed23932d@mail.gmail.com>
	<848807.62604.qm@web62003.mail.re1.yahoo.com>
	<3f49a9f40908311847i2589162fted3b7ac59a976c18@mail.gmail.com>
	<653555.4667.qm@web62007.mail.re1.yahoo.com>
Message-ID: <3f49a9f40909010859w7e5fc680u6b55d072837fd729@mail.gmail.com>

On Tue, Sep 1, 2009 at 6:12 AM, Samuel Crow<samuraileumas at yahoo.com> wrote:
> We are implementing an extensible language. ?That's one where you can add commands and constructs to the language without having to recompile the parser. ?We want compilation of the parser in order to "freeze" it but only as an option. ?One goal is to eventually get the macro functions of our language to the point where they are equivalent to the template functions of C++ so we can make a self-hosting langauge.

Ah, I have been doing the same thing, letting read-macro's and macro's
(ala lisp/scheme style), but I created a new terminal in Spirit that
can do the callbacks, but yea, I intend to re-implement the PEG parser
as read-macro's in my language and re-implement the whole spirit
parser in there, intending for the whole thing to become self-hosting
in LLVM by the end.  :)


On Tue, Sep 1, 2009 at 6:12 AM, Samuel Crow<samuraileumas at yahoo.com> wrote:
> Also, all of the action nodes in our example PEG parser are written in LLVM Assembly rather than only C++ (although they call functions from a C++ library) so I doubt it would work in Spirit2.1 without writing a syntax converter. ?The syntax converter may come in time but it's only optional. ?If you're really interested in a partially finished example parser, it is at http://mattathias.cvs.sourceforge.net/viewvc/mattathias/mattathias/modules/front_ends/Amos/ . ?It contains a PEG parser file and the source to a C++ library included in that PEG file.

Actually, creating a new terminal (as I did) in Spirit 2.1 is
extremely easy now (compared to previous spirit's, 2.0, 1.x), that is
how I handled it, but yea, as stated, I intend to eventually move to
to completely self-hosted LLVM code, have the interpreter interpret
itself.

I will take a look at your link later though, curious as to what you
are making.  :)


From tema13tema at yahoo.de  Tue Sep  1 11:12:56 2009
From: tema13tema at yahoo.de (Rudskyy)
Date: Tue, 1 Sep 2009 18:12:56 +0200
Subject: [LLVMdev] llc - generation of native machine code
Message-ID: <0FD2F7B861744D799C1C0549D8FBD66A@MOIPC7>

----- Original Message ----
> From aaronngray.lists at googlemail.com  Mon Jul 27 15:14:40 2009
> From: aaronngray.lists at googlemail.com (Aaron Gray)
> Date: Mon, 27 Jul 2009 21:14:40 +0100
> Subject: [LLVMdev] llc - generation of native machine code
> 
> > On Mon, Jul 27, 2009 at 8:25 AM, Rudskyy<tema13tema at yahoo.de> wrote:
> > > But now I am looking for generation of machine code for my target. I
have
> > > seen, that ?llc? has option "-filetype".
> > >
> > > It has default value "-filetype=asm", but has more values, as
> > > "-filetype=obj" and "-filetype=dynlib".
> > >
> > > ?obj? is very interesting, but it till not supported L
> >
> > There's work in progress to make this work properly, but it's still a
> > while off.  See http://wiki.llvm.org/Direct_Object_Code_Emission .
> >
> Hi,
> 
> We are "short circuiting" alot of this work in order to hopefully get
basic
> working ELF and COFF writers into the next release of LLVM. Alot of the
DOCE
> work is toward a longer goal of providing linkers for LLVM.
> It is best to talk to Chris Lattner and Bruno Cardoso about the ELF
writer.
> You would need to add support for you target CPU such as relocation
> information and debugging information.
> 
> Bruno is working on his GSoC project and will be doing both ELF and DWARF
> support, the DWARF support probably wont be ready until the end of
September
> though.
> 
> There is very basic functioning ELF for X86 on SVN now. Patches for other
> target archetectures are most welcome

 

Hi Aaron!

 

I have seen on SVN a last version. Yes! It supports now ELF for X86,
perfect! But debug information ( .debug - sections) not implemented. I am
looking for a possibility to use a LLVM with a debugger GDB. And GDB works
with DWARF debug information. 

Will be continue a work with ELF-Writer for support of a debug? Or is there
any other ideas for debug? 

I will add an ELF-Writer to my project (xPEC - processor from chip NetX)!

 

Sank you!

 

--Tema

 

Best regards,

Artem Rudskyy

 <http://www.uni-magdeburg.de/ieat/robotslab/>
http://www..uni-magdeburg.de/ieat/robotslab/

 <http://www.uni-magdeburg.de/> http://www.uni-magdeburg.de/

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090901/39f0037c/attachment-0001.html 

From bruno.cardoso at gmail.com  Tue Sep  1 12:11:46 2009
From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes)
Date: Tue, 1 Sep 2009 14:11:46 -0300
Subject: [LLVMdev] llc - generation of native machine code
In-Reply-To: <0FD2F7B861744D799C1C0549D8FBD66A@MOIPC7>
References: <0FD2F7B861744D799C1C0549D8FBD66A@MOIPC7>
Message-ID: <275e64e40909011011s170d5959oa8587f5a4c61eaed@mail.gmail.com>

Hi Rudskyy,

> I have seen on SVN a last version. Yes! It supports now ELF for X86,
> perfect! But debug information ( .debug ? sections) not implemented. I am
> looking for a possibility to use a LLVM with a debugger GDB. And GDB works
> with DWARF debug information.
>
> Will be continue a work with ELF-Writer for support of a debug? Or is there
> any other ideas for debug?

The support for debug and EH will come when the x86 code emitter is
integrated with llvm-mc stuff, don't know how much long that will take.

Cheers,

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc


From astifter-llvm at gmx.at  Tue Sep  1 12:53:57 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Tue, 01 Sep 2009 19:53:57 +0200
Subject: [LLVMdev] Problem building libprofile.
Message-ID: <4A9D5FB5.5090307@gmx.at>

Hi,

when I try to build libprofile with r80670 (both llvm and llvm-gcc) I
get this error:

make[1]: Entering directory `.../llvm-svn-debug-obj/runtime/libprofile'
llvm[1]: Building Debug Bytecode Archive libprofile_rt.bca (internalize)
llvm[1]: Installing Debug Shared Library
/nfs/a5/astifter/astifter/llvm/llvm-svn-debug-obj/../llvm-svn-debug-install/lib/libprofile_rt.so
0   llvm-ld         0x0000000000981568
1   llvm-ld         0x0000000000981ac7
2   libpthread.so.0 0x00002aaaaacd6a80
3   llvm-ld         0x00000000006c036c llvm::Value::getValueID() const + 12
4   llvm-ld         0x00000000006c038a bool
llvm::isa_impl<llvm::Constant, llvm::Value>(llvm::Value const&) + 21
5   llvm-ld         0x00000000006c40a0
llvm::isa_impl_wrap<llvm::Constant, llvm::Value const, llvm::Value
const>::doit(llvm::Value const&) + 21
6   llvm-ld         0x00000000006c40b7 bool
llvm::isa_impl_cl<llvm::Value>::isa<llvm::Constant>(llvm::Value const&) + 21
7   llvm-ld         0x00000000006c40ce bool
llvm::isa_impl_cl<llvm::Value const>::isa<llvm::Constant>(llvm::Value
const&) + 21
8   llvm-ld         0x00000000006c40e5 bool
llvm::isa_impl_cl<llvm::Value const*>::isa<llvm::Constant>(llvm::Value
const*) + 21
9   llvm-ld         0x00000000006c40ff bool llvm::isa<llvm::Constant,
llvm::Value const*>(llvm::Value const* const&) + 24
10  llvm-ld         0x00000000006d4e27 llvm::cast_retty<llvm::Constant,
llvm::Value const*>::ret_type llvm::dyn_cast<llvm::Constant, llvm::Value
const*>(llvm::Value const* const&) + 21
11  llvm-ld         0x00000000006da102
12  llvm-ld         0x00000000006da65d
13  llvm-ld         0x00000000006da65d
14  llvm-ld         0x00000000006daade
15  llvm-ld         0x00000000006dac98
16  llvm-ld         0x00000000006de6d9
llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::string*) + 1897
17  llvm-ld         0x00000000006d8a7d
llvm::Linker::LinkInModule(llvm::Module*, std::string*) + 41
18  llvm-ld         0x00000000006d7ff3
llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&) + 1431
19  llvm-ld         0x00000000006d867e
llvm::Linker::LinkInItems(std::vector<std::pair<std::string, bool>,
std::allocator<std::pair<std::string, bool> > > const&,
std::vector<std::pair<std::string, bool>,
std::allocator<std::pair<std::string, bool> > >&) + 258
20  llvm-ld         0x00000000006b3050 main + 1349
21  libc.so.6       0x00002aaaabaaf1a6 __libc_start_main + 230
22  llvm-ld         0x00000000006aa039 __gxx_personality_v0 + 689
Stack dump:
0.      Program arguments: .../llvm-svn-debug-obj/Debug/bin/llvm-ld
-L.../llvm-van-install/bin/../lib
-internalize-public-api-file=.../llvm-svn/runtime/libprofile/exported_symbols.lst
-o
.../llvm-svn-debug-obj/runtime/libprofile/Debug/profile_rt.internalize
.../llvm-svn-debug-obj/runtime/libprofile/Debug/BasicBlockTracing.bc
.../llvm-svn-debug-obj/runtime/libprofile/Debug/BlockProfiling.bc
.../llvm-svn-debug-obj/runtime/libprofile/Debug/CommonProfiling.bc
.../llvm-svn-debug-obj/runtime/libprofile/Debug/EdgeProfiling.bc
.../llvm-svn-debug-obj/runtime/libprofile/Debug/FunctionProfiling.bc
.../llvm-svn-debug-obj/runtime/libprofile/Debug/OptimalEdgeProfiling.bc
make[1]: *** [.../llvm-svn-debug-obj/Debug/lib/libprofile_rt.bca]
Segmentation fault
make[1]: Leaving directory `.../llvm-svn-debug-obj/runtime/libprofile'
make: *** [libprofile/.makeinstall] Error 2

Any toughts? (I attach the build log, so it does not get garbled.)

Andi

-- 
==========================================================================
This email is signed, for more information see
http://web.student.tuwien.ac.at/~e0325716/gpg.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-svn-debug-obj.build.log
Type: text/x-log
Size: 49301 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090901/0ac0a2f3/attachment.bin 

From dag at cray.com  Tue Sep  1 14:07:45 2009
From: dag at cray.com (David Greene)
Date: Tue, 1 Sep 2009 14:07:45 -0500
Subject: [LLVMdev] Turning Off Backend Passes
Message-ID: <200909011407.46468.dag@cray.com>

So LLVMTargetMachine.cpp adds lots of transformation passes in the
various addPasses* routines.  We'd prefer not to run all of these
things (LSR, for example).  We've sort of dealt with it for now but
we'd really like to be able to turn some of these things off in a
convenient way.

We could just comment stuff out but we'd like to remain as close to
upstream as possible.  Can anyone think of a good way to provide the
needed flexibility here?  Maybe a flags that says "just do the bare 
minimum to generate code?"  Would anyone object to that?

                            -Dave

From evan.cheng at apple.com  Tue Sep  1 14:27:35 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 1 Sep 2009 12:27:35 -0700
Subject: [LLVMdev] Turning Off Backend Passes
In-Reply-To: <200909011407.46468.dag@cray.com>
References: <200909011407.46468.dag@cray.com>
Message-ID: <5DE49093-55F1-42EC-BA21-F5BAF1CBF7A0@apple.com>


On Sep 1, 2009, at 12:07 PM, David Greene wrote:

> So LLVMTargetMachine.cpp adds lots of transformation passes in the
> various addPasses* routines.  We'd prefer not to run all of these
> things (LSR, for example).  We've sort of dealt with it for now but
> we'd really like to be able to turn some of these things off in a
> convenient way.
>
> We could just comment stuff out but we'd like to remain as close to
> upstream as possible.  Can anyone think of a good way to provide the
> needed flexibility here?  Maybe a flags that says "just do the bare
> minimum to generate code?"  Would anyone object to that?

If you have a custom compiler, why not have llvm-gcc (or whatever  
frontend you use) create its own pass manager? That way, it can  
control the exactly what passes it wants.

Evan

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


From dag at cray.com  Tue Sep  1 14:36:45 2009
From: dag at cray.com (David Greene)
Date: Tue, 1 Sep 2009 14:36:45 -0500
Subject: [LLVMdev] Turning Off Backend Passes
In-Reply-To: <5DE49093-55F1-42EC-BA21-F5BAF1CBF7A0@apple.com>
References: <200909011407.46468.dag@cray.com>
	<5DE49093-55F1-42EC-BA21-F5BAF1CBF7A0@apple.com>
Message-ID: <200909011436.45638.dag@cray.com>

On Tuesday 01 September 2009 14:27, Evan Cheng wrote:

> If you have a custom compiler, why not have llvm-gcc (or whatever
> frontend you use) create its own pass manager? That way, it can
> control the exactly what passes it wants.

Because addPasses* do a lot of useful stuff.  There's already a "Fast"
flag but it's overloaded.  What if we replaced it with a bitvector of
flags?

                                -Dave

From david_goodwin at apple.com  Tue Sep  1 14:39:11 2009
From: david_goodwin at apple.com (David Goodwin)
Date: Tue, 1 Sep 2009 12:39:11 -0700
Subject: [LLVMdev] spec tests + PWD=
In-Reply-To: <9CFECF04-D707-4B61-B5B2-E17A50EF8564@apple.com>
References: <9CFECF04-D707-4B61-B5B2-E17A50EF8564@apple.com>
Message-ID: <090B435C-CAC0-4F3F-8E64-A03484978DB8@apple.com>

I did make that change to support the following code in  
ToolRunner.cpp. I found that if I did not explicitly set PWD when  
invoking bugpoint, then it would not be in the environment. I'm not  
sure why PWD is not being inherited... perhaps some make weirdness...  
or bash??? and I don't know how it ever worked before my change.

     // Full path to the binary. We need to cd to the exec directory  
because
     // there is a dylib there that the exec expects to find in the CWD
     char* env_pwd = getenv("PWD");
     std::string Exec = "cd ";
     Exec += env_pwd;


Perhaps I shouldn't have added it to Makefile.spec? At the least it  
seems like it should probably move to the beginning of the command,  
like this:

	PWD=$(CURDIR)  $(SPEC_SANDBOX) bugpoint-$(RUN_TYPE) $@ $(REF_IN_DIR) \
	    $(LBUGPOINT) -llc-safe ../$*.noopt-llvm.bc -std-compile-opts $ 
(OPTPASSES) \

David


On Aug 30, 2009, at 8:25 PM, Chris Lattner wrote:

> Hi David,
>
> It looks like you added the PWD= magic to Makefile.spec.  It is  
> preventing me from running bugpoint on the desktop, with errors like  
> this:
>
> /Users/sabre/llvm/projects/llvm-test/External/SPEC/Sandbox.sh  
> bugpoint-train Output/176.gcc.bugpoint-opt /Users/sabre/cvs/ 
> benchmarks/speccpu2000/benchspec/CINT2000/176.gcc/data/train/input/ \
> 	    PWD=/Volumes/Data/Users/sabre/llvm/projects/llvm-test/External/ 
> SPEC/CINT2000/176.gcc /Users/sabre/llvm/Debug/bin/bugpoint -llc- 
> safe ../176.gcc.noopt-llvm.bc -std-compile-opts  \
> 	    -append-exit-code   -Xlinker=-lm  -input=/dev/null -output=../ 
> 176.gcc.out-nat -timeout=500 --tool-args -asm-verbose=false -O3 -- 
> args -- cp-decl.i -o - -quiet
> Running: PWD=/Volumes/Data/Users/sabre/llvm/projects/llvm-test/ 
> External/SPEC/CINT2000/176.gcc /Users/sabre/llvm/Debug/bin/bugpoint - 
> llc-safe ../176.gcc.noopt-llvm.bc -std-compile-opts -append-exit- 
> code -Xlinker=-lm -input=/dev/null -output=../176.gcc.out-nat - 
> timeout=500 --tool-args -asm-verbose=false -O3 --args -- cp-decl.i - 
> o - -quiet
> /Users/sabre/llvm/projects/llvm-test/External/SPEC/Sandbox.sh: line  
> 36: /Volumes/Data/Users/sabre/llvm/projects/llvm-test/External/SPEC/ 
> CINT2000/176.gcc/Output/bugpoint-train/PWD=/Volumes/Data/Users/sabre/ 
> llvm/projects/llvm-test/External/SPEC/CINT2000/176.gcc: No such file  
> or directory
> /Users/sabre/llvm/projects/llvm-test/External/SPEC/Sandbox.sh: line  
> 36: exec: /Volumes/Data/Users/sabre/llvm/projects/llvm-test/External/ 
> SPEC/CINT2000/176.gcc/Output/bugpoint-train/PWD=/Volumes/Data/Users/ 
> sabre/llvm/projects/llvm-test/External/SPEC/CINT2000/176.gcc: cannot  
> execute: No such file or directory
>
> I think this comes down to SPEC/Sandbox.sh turning around and  
> exec'ing its arguments, which include the PWD= line.  This is  
> failing, but I'm not sure why (maybe it's because I'm using tcsh as  
> my shell, not bash).  Is there a way to fix this without reverting  
> the patch?
>
> -Chris


From clattner at apple.com  Tue Sep  1 15:08:51 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 1 Sep 2009 13:08:51 -0700
Subject: [LLVMdev] spec tests + PWD=
In-Reply-To: <090B435C-CAC0-4F3F-8E64-A03484978DB8@apple.com>
References: <9CFECF04-D707-4B61-B5B2-E17A50EF8564@apple.com>
	<090B435C-CAC0-4F3F-8E64-A03484978DB8@apple.com>
Message-ID: <695453A5-C969-435A-8EBD-CF1F301CA9F9@apple.com>


On Sep 1, 2009, at 12:39 PM, David Goodwin wrote:

> I did make that change to support the following code in  
> ToolRunner.cpp. I found that if I did not explicitly set PWD when  
> invoking bugpoint, then it would not be in the environment. I'm not  
> sure why PWD is not being inherited... perhaps some make  
> weirdness... or bash??? and I don't know how it ever worked before  
> my change.
>
>    // Full path to the binary. We need to cd to the exec directory  
> because
>    // there is a dylib there that the exec expects to find in the CWD
>    char* env_pwd = getenv("PWD");
>    std::string Exec = "cd ";
>    Exec += env_pwd;
>
>
> Perhaps I shouldn't have added it to Makefile.spec? At the least it  
> seems like it should probably move to the beginning of the command,  
> like this:
>
> 	PWD=$(CURDIR)  $(SPEC_SANDBOX) bugpoint-$(RUN_TYPE) $@ $ 
> (REF_IN_DIR) \
> 	    $(LBUGPOINT) -llc-safe ../$*.noopt-llvm.bc -std-compile-opts $ 
> (OPTPASSES) \

I changed Makefile.spec to use 'env' at Shantonu's suggestion and it  
works for me. :)

Thanks David,

-Chris


From evan.cheng at apple.com  Tue Sep  1 15:14:04 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 1 Sep 2009 13:14:04 -0700
Subject: [LLVMdev] Turning Off Backend Passes
In-Reply-To: <200909011436.45638.dag@cray.com>
References: <200909011407.46468.dag@cray.com>
	<5DE49093-55F1-42EC-BA21-F5BAF1CBF7A0@apple.com>
	<200909011436.45638.dag@cray.com>
Message-ID: <DFA4DBCA-1C63-4358-B9E7-C3055F51FBE4@apple.com>


On Sep 1, 2009, at 12:36 PM, David Greene wrote:

> On Tuesday 01 September 2009 14:27, Evan Cheng wrote:
>
>> If you have a custom compiler, why not have llvm-gcc (or whatever
>> frontend you use) create its own pass manager? That way, it can
>> control the exactly what passes it wants.
>
> Because addPasses* do a lot of useful stuff.  There's already a "Fast"
> flag but it's overloaded.  What if we replaced it with a bitvector of
> flags?

Fast has been replaced with optimization level. I am not opposed to  
enhancing it but I'd prefer to keep it simple.

addPasses* just add a bunch of passes to PM. It's really not a lot to  
replicate if want your own custom llc / llvm-gcc.

Evan

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


From nickchilders at umail.ucsb.edu  Tue Sep  1 15:25:44 2009
From: nickchilders at umail.ucsb.edu (Nicholas S. Childers)
Date: Tue, 01 Sep 2009 13:25:44 -0700
Subject: [LLVMdev] LLVM based project idea in computer security
Message-ID: <20090901132544.206924k705xewksg@webaccess.umail.ucsb.edu>

Hello,

First, I apologize if this is the wrong list for my inquiry. I am a  
student at UCSB working in Computer Security and I had an idea that  
would make heavy use of llvm. The idea is to use llvm as an IR /  
compiler for dynamic binary instrumentation, along the lines of the  
VEX IR in the valgrind tool. I was wondering if this idea had been  
previously discussed or if someone is currently working on it?

My hope is that llvm, given its highly portable nature, will be more  
conducive to cross platform support. My dream is to have a highly  
portable tool similar to valgrind, although I am aware that much of  
the difficulty in porting valgrind does not stem from it's IR  
representation but rather dealing with system calls specific to the OS  
(which on windows will probably make writing any type of dynamic  
binary instrumentation tool the closest thing to working in hades).

Anyway, I am in the process of doing my due diligence, checking for  
previous work and related topics. I would very much appreciate input  
on this subject and I thank you for your time :)

-- 
Nicholas Childers
nickchilders at umail.ucsb.edu



From stuart at apple.com  Tue Sep  1 15:54:20 2009
From: stuart at apple.com (Stuart Hastings)
Date: Tue, 1 Sep 2009 13:54:20 -0700
Subject: [LLVMdev] TOT broken
Message-ID: <FFC7B582-FA04-4146-B32E-C6792548E9BF@apple.com>

The buildbots are unhappy again.  :-(

Specifically, the "llvm-gcc-i386-darwin9" buildbot here at Apple last  
compiled TOT successfully yesterday morning (31aug); that was revision  
80586.  By revision 80589, the bootstrap failed due to a miscompare,  
and by revision 80610, it's aborting while compiling little pieces of  
libgcc.

80586	built O.K. (about 8AM, Pacific Standard Time, on Monday 31aug)
...
80589	bootstrap miscompare (about one hour after 80586)
...
80610	abort()s while compiling libgcc (about two hours after 80589)
...
80717	(current as I write this, on Tuesday 01sep) still broken

I realize that everyone is busy, but I think TOT has been broken long  
enough.  Would everyone that committed any patches yesterday please  
check your work with a clean make of TOT?

Thank you in advance,

stuart

From daniel at zuster.org  Tue Sep  1 16:27:46 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Tue, 1 Sep 2009 14:27:46 -0700
Subject: [LLVMdev] TOT broken
In-Reply-To: <FFC7B582-FA04-4146-B32E-C6792548E9BF@apple.com>
References: <FFC7B582-FA04-4146-B32E-C6792548E9BF@apple.com>
Message-ID: <6a8523d60909011427i4d7e42c1i284c04722d47f827@mail.gmail.com>

Yes, this is pretty unacceptable IMHO.

I would go revert crazy if I knew what to hit, unfortunately I don't.

Currently I believe there are two problems, a CallGraphSCC assert
which is firing everywhere (including the clang test suite, *cough*).
This started with 80698. Chris is working on this (if it isn't already
fixed).

The bootstrap comparison failures are being looked at by Devang.

 - Daniel

On Tue, Sep 1, 2009 at 1:54 PM, Stuart Hastings<stuart at apple.com> wrote:
> The buildbots are unhappy again. ?:-(
>
> Specifically, the "llvm-gcc-i386-darwin9" buildbot here at Apple last
> compiled TOT successfully yesterday morning (31aug); that was revision
> 80586. ?By revision 80589, the bootstrap failed due to a miscompare,
> and by revision 80610, it's aborting while compiling little pieces of
> libgcc.
>
> 80586 ? built O.K. (about 8AM, Pacific Standard Time, on Monday 31aug)
> ...
> 80589 ? bootstrap miscompare (about one hour after 80586)
> ...
> 80610 ? abort()s while compiling libgcc (about two hours after 80589)
> ...
> 80717 ? (current as I write this, on Tuesday 01sep) still broken
>
> I realize that everyone is busy, but I think TOT has been broken long
> enough. ?Would everyone that committed any patches yesterday please
> check your work with a clean make of TOT?
>
> Thank you in advance,
>
> stuart
> _______________________________________________
> 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  Tue Sep  1 16:32:21 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 1 Sep 2009 14:32:21 -0700
Subject: [LLVMdev] TOT broken
In-Reply-To: <FFC7B582-FA04-4146-B32E-C6792548E9BF@apple.com>
References: <FFC7B582-FA04-4146-B32E-C6792548E9BF@apple.com>
Message-ID: <16e5fdf90909011432y35f2a18ci55977461527f5e6@mail.gmail.com>

For those not seeing the failures on the Google build bots. That's
because they're not building llvm-gcc with bootstrap (or, indeed, at
all).

-bw

On Tue, Sep 1, 2009 at 1:54 PM, Stuart Hastings<stuart at apple.com> wrote:
> The buildbots are unhappy again. ?:-(
>
> Specifically, the "llvm-gcc-i386-darwin9" buildbot here at Apple last
> compiled TOT successfully yesterday morning (31aug); that was revision
> 80586. ?By revision 80589, the bootstrap failed due to a miscompare,
> and by revision 80610, it's aborting while compiling little pieces of
> libgcc.
>
> 80586 ? built O.K. (about 8AM, Pacific Standard Time, on Monday 31aug)
> ...
> 80589 ? bootstrap miscompare (about one hour after 80586)
> ...
> 80610 ? abort()s while compiling libgcc (about two hours after 80589)
> ...
> 80717 ? (current as I write this, on Tuesday 01sep) still broken
>
> I realize that everyone is busy, but I think TOT has been broken long
> enough. ?Would everyone that committed any patches yesterday please
> check your work with a clean make of TOT?
>
> Thank you in advance,
>
> stuart
> _______________________________________________
> 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  Tue Sep  1 16:38:21 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 1 Sep 2009 14:38:21 -0700
Subject: [LLVMdev] TOT broken
In-Reply-To: <6a8523d60909011427i4d7e42c1i284c04722d47f827@mail.gmail.com>
References: <FFC7B582-FA04-4146-B32E-C6792548E9BF@apple.com>
	<6a8523d60909011427i4d7e42c1i284c04722d47f827@mail.gmail.com>
Message-ID: <D0402ACE-DAC0-42CD-B485-41C9FEC90619@apple.com>


On Sep 1, 2009, at 2:27 PM, Daniel Dunbar wrote:

> Yes, this is pretty unacceptable IMHO.
>
> I would go revert crazy if I knew what to hit, unfortunately I don't.
>
> Currently I believe there are two problems, a CallGraphSCC assert
> which is firing everywhere (including the clang test suite, *cough*).
> This started with 80698. Chris is working on this (if it isn't already
> fixed).

Fixed in r80724.

-Chris


From juanc.martinez.santos at gmail.com  Tue Sep  1 16:42:16 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Tue, 1 Sep 2009 17:42:16 -0400
Subject: [LLVMdev] A simulation tool
Message-ID: <d17b77a40909011442l5d689f9r5f7724b4b6c9443d@mail.gmail.com>

Hello everybody,

I am looking for a tool (in Linux or Windows) that allow me to get
performance measures like cycle execution, cache accesses, etc. for an x86
architecture. I want to estimate the performance overhead due to the
modification that I do using LLVM.

Any suggestion is welcome.

Thanks in advance,

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090901/2d327a1c/attachment-0001.html 

From devang.patel at gmail.com  Tue Sep  1 16:52:00 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Tue, 1 Sep 2009 14:52:00 -0700
Subject: [LLVMdev] TOT broken
In-Reply-To: <6a8523d60909011427i4d7e42c1i284c04722d47f827@mail.gmail.com>
References: <FFC7B582-FA04-4146-B32E-C6792548E9BF@apple.com>
	<6a8523d60909011427i4d7e42c1i284c04722d47f827@mail.gmail.com>
Message-ID: <352a1fb20909011452o4f572bbcye6f913fda96db04@mail.gmail.com>

Stuart,

On Tue, Sep 1, 2009 at 2:27 PM, Daniel Dunbar<daniel at zuster.org> wrote:
> Yes, this is pretty unacceptable IMHO.
>
> I would go revert crazy if I knew what to hit, unfortunately I don't.
>
> Currently I believe there are two problems, a CallGraphSCC assert
> which is firing everywhere (including the clang test suite, *cough*).
> This started with 80698. Chris is working on this (if it isn't already
> fixed).
>
> The bootstrap comparison failures are being looked at by Devang.

Yes, I am investigating this. As you say, the buildbots were happy
Monday morning, but investigation leads me to combination of patches
committed last week and first week of August. The bug was hiding until
Monday. So... stay tuned.

-
Devang

From daniel at zuster.org  Tue Sep  1 17:13:22 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Tue, 1 Sep 2009 15:13:22 -0700
Subject: [LLVMdev] A simulation tool
In-Reply-To: <d17b77a40909011442l5d689f9r5f7724b4b6c9443d@mail.gmail.com>
References: <d17b77a40909011442l5d689f9r5f7724b4b6c9443d@mail.gmail.com>
Message-ID: <6a8523d60909011513j7d9958deta573e83c09fecdbb@mail.gmail.com>

You mean 'cachegrind'?
  http://valgrind.org/info/tools.html#cachegrind

I don't know any public tool better than this (but someone please tell
me if I am misinformed).

 - Daniel

On Tue, Sep 1, 2009 at 2:42 PM, Juan Carlos Martinez
Santos<juanc.martinez.santos at gmail.com> wrote:
> Hello everybody,
>
> I am looking for a tool (in Linux or Windows) that allow me to get
> performance measures like cycle execution, cache accesses, etc. for an x86
> architecture. I want to estimate the performance overhead due to the
> modification that I do using LLVM.
>
> Any suggestion is welcome.
>
> Thanks in advance,
>
> --
> Juan Carlos
>
> _______________________________________________
> 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 Sep  1 17:23:58 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Tue, 1 Sep 2009 17:23:58 -0500
Subject: [LLVMdev] [Fwd: Re:  A simulation tool]
Message-ID: <4A9D9EFE.4070604@cs.uiuc.edu>


-------------- next part --------------
An embedded message was scrubbed...
From: John Criswell <criswell at cs.uiuc.edu>
Subject: Re: [LLVMdev] A simulation tool
Date: Tue, 1 Sep 2009 17:23:34 -0500
Size: 2903
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090901/c1e167ca/attachment.eml 

From thisisgiri at gmail.com  Tue Sep  1 18:33:09 2009
From: thisisgiri at gmail.com (Giridhar S)
Date: Tue, 1 Sep 2009 19:33:09 -0400
Subject: [LLVMdev] A simulation tool
In-Reply-To: <6a8523d60909011513j7d9958deta573e83c09fecdbb@mail.gmail.com>
References: <d17b77a40909011442l5d689f9r5f7724b4b6c9443d@mail.gmail.com>
	<6a8523d60909011513j7d9958deta573e83c09fecdbb@mail.gmail.com>
Message-ID: <2d2f7b920909011633y6fa6fa28kf400e1c03bea3c54@mail.gmail.com>

Oprofile for Linux is a pretty good alternative.
(http://oprofile.sourceforge.net/about/)

It uses hardware performance counters to collect profiling information
and therefore has very low overhead, whereas Valgrind performs dynamic
binary instrumentation and can be significantly slow (20-50x slower).
In addition, Cachegrind 'simulates' cache behavior through it's own
cache model, whereas Oprofile (or other counter based profilers)
report real cache events.

Depending on what your needs are (ease of use, runtime overhead, etc)
you could pick either.

On Tue, Sep 1, 2009 at 6:13 PM, Daniel Dunbar<daniel at zuster.org> wrote:
> You mean 'cachegrind'?
>  http://valgrind.org/info/tools.html#cachegrind
>
> I don't know any public tool better than this (but someone please tell
> me if I am misinformed).
>
>  - Daniel
>
> On Tue, Sep 1, 2009 at 2:42 PM, Juan Carlos Martinez
> Santos<juanc.martinez.santos at gmail.com> wrote:
>> Hello everybody,
>>
>> I am looking for a tool (in Linux or Windows) that allow me to get
>> performance measures like cycle execution, cache accesses, etc. for an x86
>> architecture. I want to estimate the performance overhead due to the
>> modification that I do using LLVM.
>>
>> Any suggestion is welcome.
>>
>> Thanks in advance,
>>
>> --
>> Juan Carlos
>>
>> _______________________________________________
>> 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
>



-- 
Giri

From suhabe at stanford.edu  Tue Sep  1 19:13:44 2009
From: suhabe at stanford.edu (Suhabe Bugrara)
Date: Tue, 1 Sep 2009 17:13:44 -0700
Subject: [LLVMdev] data structure analysis
Message-ID: <5166c2f30909011713n9d77068n2e7fc8e40f360444@mail.gmail.com>

Hello,

In the poolalloc module, the
DSAA::getModRefInfo(CallSite,Value*,unsigned) function in
DataStructureAA.cpp uses the top-down graph of the caller, but the the
bottom-up graph of the callee to compute the caller-callee node
mapping which it uses to answer mod/ref queries. There is a comment in
the code that says:

	"// Get the graphs for the callee and caller.  Note that we want the BU graph
	// for the callee because we don't want all caller's effects incorporated!"

Why is it that we don't want the caller's effects to be incorporated?

Thanks.

Suhabe

From overminddl1 at gmail.com  Tue Sep  1 21:32:30 2009
From: overminddl1 at gmail.com (OvermindDL1)
Date: Tue, 1 Sep 2009 20:32:30 -0600
Subject: [LLVMdev] A simulation tool
In-Reply-To: <3f49a9f40909011932v1cf4e88eub94e32149579bfba@mail.gmail.com>
References: <d17b77a40909011442l5d689f9r5f7724b4b6c9443d@mail.gmail.com>
	<6a8523d60909011513j7d9958deta573e83c09fecdbb@mail.gmail.com>
	<2d2f7b920909011633y6fa6fa28kf400e1c03bea3c54@mail.gmail.com>
	<3f49a9f40909011932v1cf4e88eub94e32149579bfba@mail.gmail.com>
Message-ID: <3f49a9f40909011932q1a4a39ddyeae8641a3df3e41@mail.gmail.com>

Helps if I send it to the list....

On Tue, Sep 1, 2009 at 5:33 PM, Giridhar S<thisisgiri at gmail.com> wrote:
> Oprofile for Linux is a pretty good alternative.
> (http://oprofile.sourceforge.net/about/)
>
> It uses hardware performance counters to collect profiling information
> and therefore has very low overhead, whereas Valgrind performs dynamic
> binary instrumentation and can be significantly slow (20-50x slower).
> In addition, Cachegrind 'simulates' cache behavior through it's own
> cache model, whereas Oprofile (or other counter based profilers)
> report real cache events.
>
> Depending on what your needs are (ease of use, runtime overhead, etc)
> you could pick either.

I am curious, how do you think AMD CodeAnalyst works in regards to
performance counting?  It seems to be quite fast to me, only causing a
slow-down of between 2x to 6x depending on the program.

From baldrick at free.fr  Tue Sep  1 22:02:40 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 02 Sep 2009 05:02:40 +0200
Subject: [LLVMdev] [Fwd: Re:  A simulation tool]
In-Reply-To: <4A9D9EFE.4070604@cs.uiuc.edu>
References: <4A9D9EFE.4070604@cs.uiuc.edu>
Message-ID: <4A9DE050.1060504@free.fr>

Hi John,

> The perfctr Linux kernel patch virtualizes the CPU's performance
> counters (so that each thread saves/restores the performance counter
> registers when it is taken off/put on the CPU).  This, combined with the
> perfex command line tool, allows you to find the number of cache misses,
> cycles executed, etc. for a program at native execution speed.
> 
> Perfctr's advantage is speed; however, I don't believe it has been
> incorporated into a tool that gives the detailed report information that
> cachegrind seems to provide; perfex will only report the number of
> events between program start and program termination.  One could write
> an LLVM pass that instruments a program with calls to a profiling
> runtime; that runtime could use the perfctr driver to collect the
> performance counter information on a
> per-function/per-basic-block/per-whatever basis.
> 
> So, perfctr is faster.  Cachegrind is probably much easier to
> install/use and looks like it will provide more detailed information. 
> Both are open-source and publicly available.

oprofile will annotate your source code with all kinds of information
obtained from the CPU performance counters, for example showing the
percentage of time / cache misses in a particular function.

Ciao,

Duncan.

From thisisgiri at gmail.com  Tue Sep  1 22:07:01 2009
From: thisisgiri at gmail.com (Giridhar S)
Date: Tue, 1 Sep 2009 23:07:01 -0400
Subject: [LLVMdev] A simulation tool
In-Reply-To: <3f49a9f40909011932q1a4a39ddyeae8641a3df3e41@mail.gmail.com>
References: <d17b77a40909011442l5d689f9r5f7724b4b6c9443d@mail.gmail.com>
	<6a8523d60909011513j7d9958deta573e83c09fecdbb@mail.gmail.com>
	<2d2f7b920909011633y6fa6fa28kf400e1c03bea3c54@mail.gmail.com>
	<3f49a9f40909011932v1cf4e88eub94e32149579bfba@mail.gmail.com>
	<3f49a9f40909011932q1a4a39ddyeae8641a3df3e41@mail.gmail.com>
Message-ID: <2d2f7b920909012007x1c4b9530jd292759990c1b7b0@mail.gmail.com>

I have never used CodeAnalyst first-hand, but the slow-down figures
that you quote lead me to believe that it must use hardware
performance counters. Instrumentation based profilers rarely, if ever,
display such low overhead. Also, instrumentation based profilers
cannot profile kernel routines, unless there is explicit support from
within the kernel (such as in Sun Solaris 10 and DTrace).

Taking a quick look at AMD's website seems to confirm this theory:
http://developer.amd.com/Assets/Basic_Performance_Measurements.pdf

If this topic is getting out-of-scope for the LLVM Dev list, we can
take it offline.

On Tue, Sep 1, 2009 at 10:32 PM, OvermindDL1<overminddl1 at gmail.com> wrote:
> Helps if I send it to the list....
>
> On Tue, Sep 1, 2009 at 5:33 PM, Giridhar S<thisisgiri at gmail.com> wrote:
>> Oprofile for Linux is a pretty good alternative.
>> (http://oprofile.sourceforge.net/about/)
>>
>> It uses hardware performance counters to collect profiling information
>> and therefore has very low overhead, whereas Valgrind performs dynamic
>> binary instrumentation and can be significantly slow (20-50x slower).
>> In addition, Cachegrind 'simulates' cache behavior through it's own
>> cache model, whereas Oprofile (or other counter based profilers)
>> report real cache events.
>>
>> Depending on what your needs are (ease of use, runtime overhead, etc)
>> you could pick either.
>
> I am curious, how do you think AMD CodeAnalyst works in regards to
> performance counting? ?It seems to be quite fast to me, only causing a
> slow-down of between 2x to 6x depending on the program.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Giri


From nicholas at mxc.ca  Tue Sep  1 22:55:50 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 01 Sep 2009 20:55:50 -0700
Subject: [LLVMdev] [llvm-commits] SSI Patch
In-Reply-To: <4A9D12D3.1040704@dcc.ufmg.br>
References: <4A97E668.9060807@dcc.ufmg.br> <4A9D12D3.1040704@dcc.ufmg.br>
Message-ID: <4A9DECC6.9050904@mxc.ca>

Andre Tavares wrote:
> I tried to make 5 separate patches, but as they are constructive, they 
> had information from the last one. So I will post one by one as it gets 
> on the tree.
> 
> 1. We had a function isUsedInTerminator that tested if a comparator was 
> used in the terminator of its parent BasicBlock. This is wrong because a 
> comparator can be created in a BasicBlock and used in the terminator of 
> other BasicBlock, and can be used in more than one.

+            for (unsigned j = 0, e = TI->getNumSuccessors(); j < e; ++j) {
+              // Next Basic Block
+              BasicBlock *BB_next = TI->getSuccessor(j);
+              if (BB_next != BB &&
+                  BB_next->getSinglePredecessor() != NULL &&
+                  dominateAny(BB_next, value[i])) {
+                PHINode *PN = PHINode::Create(
+                    value[i]->getType(), SSI_SIG, BB_next->begin());
+                PN->addIncoming(value[i], BB);
+                sigmas.insert(std::make_pair(PN, i));
+                created.insert(PN);
+                need = true;
+                defsites[i].push_back(BB_next);
+                ++NumSigmaInserted;
+              }
+            }

Please break this out into its own method. Otherwise, this looks fine to me.

Nick

From xuzhongxing at gmail.com  Wed Sep  2 00:59:23 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Wed, 2 Sep 2009 13:59:23 +0800
Subject: [LLVMdev] I have ever found MSVC building is failing ,
	but now 	it's working fine, I want to know why
In-Reply-To: <806065d90909010726g783e5de5of3bf0a6e9f01fac2@mail.gmail.com>
References: <806065d90909010726g783e5de5of3bf0a6e9f01fac2@mail.gmail.com>
Message-ID: <5400aeb80909012259j6045067and3e688047e766ee5@mail.gmail.com>

You can subscribe to llvm-commit and clang-commit to receive an email
on every commit made by developers.
Or you can run 'svn log file' to see change log of a file.

On Tue, Sep 1, 2009 at 10:26 PM, ???(Yonggang Luo)<luoyonggang at gmail.com> wrote:
> The buildbot ever showed that cmake generating the msvc sln file
> failure, but few days later, it's fixed.
> How it's fixed, I doesn't see the information.
> Is it downgrade the msvc or other solutions?
>
> --
> ? ? ? ? ??
> ?
> ???
> Yours
> ? ?sincerely,
> Yonggang Luo
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From gausszhch at gmail.com  Wed Sep  2 01:06:04 2009
From: gausszhch at gmail.com (gauss)
Date: Tue, 1 Sep 2009 23:06:04 -0700 (PDT)
Subject: [LLVMdev]  link-error: different visibilities
Message-ID: <25252124.post@talk.nabble.com>


When I use llvm-2.5 to compile gnash which is a GNU flash movie player, some
errors appeared as follow:

llvm-ld: error: Cannot link in module
'../libcore/.libs/libgnashcore.a(movie_root.o)': Linking globals named
'_ZNKSt6vectorIN5gnash8geometry7Range2dIfEESaIS3_EE4sizeEv': symbols have
different visibilities!

Because the name is mangled, I can't find the exact position of this
function in the original source code, so I can't give more information about
it.

Any one will help me? 

Thanks!

Gauss, 09-02
-- 
View this message in context: http://www.nabble.com/link-error%3A-different-visibilities-tp25252124p25252124.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From nicholas at mxc.ca  Wed Sep  2 01:09:31 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 01 Sep 2009 23:09:31 -0700
Subject: [LLVMdev] link-error: different visibilities
In-Reply-To: <25252124.post@talk.nabble.com>
References: <25252124.post@talk.nabble.com>
Message-ID: <4A9E0C1B.7080708@mxc.ca>

gauss wrote:
> When I use llvm-2.5 to compile gnash which is a GNU flash movie player, some
> errors appeared as follow:
> 
> llvm-ld: error: Cannot link in module
> '../libcore/.libs/libgnashcore.a(movie_root.o)': Linking globals named
> '_ZNKSt6vectorIN5gnash8geometry7Range2dIfEESaIS3_EE4sizeEv': symbols have
> different visibilities!
> 
> Because the name is mangled, I can't find the exact position of this
> function in the original source code, so I can't give more information about
> it.

You probably have c++filt installed:

$ c++filt _ZNKSt6vectorIN5gnash8geometry7Range2dIfEESaIS3_EE4sizeEv
std::vector<gnash::geometry::Range2d<float>, 
std::allocator<gnash::geometry::Range2d<float> > >::size() const

Hope that helps!

Nick

From gausszhch at gmail.com  Wed Sep  2 01:31:05 2009
From: gausszhch at gmail.com (gauss)
Date: Tue, 1 Sep 2009 23:31:05 -0700 (PDT)
Subject: [LLVMdev] link-error: different visibilities
In-Reply-To: <4A9E0C1B.7080708@mxc.ca>
References: <25252124.post@talk.nabble.com> <4A9E0C1B.7080708@mxc.ca>
Message-ID: <25252320.post@talk.nabble.com>


Thanks. It helps me a lot. However, you see, it uses c++ template and
'typedef' and so on, so I still can't find the exact position in the source
code. 

And why the llvm-ld fail to link those *.o (compiled from llvm-g++) file? Is
there some mistake in the llvm? I am using llvm-2.5 now. 


Nick Lewycky wrote:
> 
> You probably have c++filt installed:
> 
> $ c++filt _ZNKSt6vectorIN5gnash8geometry7Range2dIfEESaIS3_EE4sizeEv
> std::vector<gnash::geometry::Range2d<float>, 
> std::allocator<gnash::geometry::Range2d<float> > >::size() const
> 
> Hope that helps!
> 
> Nick
> _______________________________________________
> 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/link-error%3A-different-visibilities-tp25252124p25252320.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From sebastian.redl at getdesigned.at  Wed Sep  2 02:02:52 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Wed, 02 Sep 2009 09:02:52 +0200
Subject: [LLVMdev] link-error: different visibilities
In-Reply-To: <25252124.post@talk.nabble.com>
References: <25252124.post@talk.nabble.com>
Message-ID: <4A9E189C.503@getdesigned.at>

gauss wrote:
> When I use llvm-2.5 to compile gnash which is a GNU flash movie player, some
> errors appeared as follow:
>
> llvm-ld: error: Cannot link in module
> '../libcore/.libs/libgnashcore.a(movie_root.o)': Linking globals named
> '_ZNKSt6vectorIN5gnash8geometry7Range2dIfEESaIS3_EE4sizeEv': symbols have
> different visibilities!
>
> Because the name is mangled, I can't find the exact position of this
> function in the original source code, so I can't give more information about
> it.
>   
Use the c++filt program (part of GNU binutils) to demangle the name. The
function in question is
std::vector<gnash::geometry::Range2d<float>,
std::allocator<gnash::geometry::Range2d<float> > >::size() const

Sebastian

From kuba at gcc.gnu.org  Wed Sep  2 03:07:09 2009
From: kuba at gcc.gnu.org (Jakub Staszak)
Date: Wed, 2 Sep 2009 06:07:09 -0200
Subject: [LLVMdev] [PATCH] PR2218
In-Reply-To: <8A739C24-C4C9-407E-BAF6-8A98C1FE86DE@apple.com>
References: <FC0F12B2-3BB4-40EA-8599-69B9B2DE1B2D@gcc.gnu.org>
	<2E8440DC-3C3A-49B7-AD48-DB4A2B20B890@apple.com>
	<1BB852EF-07C5-4BC8-9E27-942B6F2AF8B2@gcc.gnu.org>
	<8A739C24-C4C9-407E-BAF6-8A98C1FE86DE@apple.com>
Message-ID: <3C9C4560-89C0-409E-8263-6AD0C9B63556@gcc.gnu.org>

Hello,

I fixed my patch as you asked. Sorry for the delay, I'd been working  
on my SSU patch (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025347.html 
)

I hope that everything is fine now.

-Jakub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr2218-3.patch
Type: application/octet-stream
Size: 7511 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090902/954ace6e/attachment.obj 
-------------- next part --------------

On Aug 7, 2009, at 7:40 PM, Chris Lattner wrote:

>
> On Jul 25, 2009, at 4:48 PM, Jakub Staszak wrote:
>
>> Hello,
>>
>> Sorry for my stupid mistakes. I hope that everything is fine now.  
>> This patch fixes PR2218. There are no loads in example, however  
>> "instcombine" changes memcpy() into store/load.
>
> Hi Jakub,
>
> Sorry for the delay, I'm way behind on code review.  Generally if  
> you respond quickly, I'll remember enough about the previous email  
> that I can respond quickly too.  If it gets out of my brain then it  
> takes me a while to get back to it.  I'll try to be better in the  
> future :(
>
> This patch is looking like a great improvement.  Some comments on  
> formatting:
>
> Please pull this out to a helper function:
> +    CallSite CS = CallSite::get(C);
> +
> +    // Pointer must be a parameter (case 1)
> +    for (argI = 0; argI < CS.arg_size(); ++argI)
> +      if (CS.getArgument(argI)->stripPointerCasts() == pointer)
> +	break;
> +
> +    if (argI == CS.arg_size())
> +      return false;
>
> per http://llvm.org/docs/CodingStandards.html#hl_predicateloops
>
>
> +    // Store cannot be volatile (case 2) and must-alias with our  
> pointer.
> +    if (S->isVolatile()) {
> +      return false;
> +    } else {
>
> no need for the 'else after return': http://llvm.org/docs/CodingStandards.html#hl_else_after_return
>
> +      AliasAnalysis& AA = getAnalysis<AliasAnalysis>();
> +      if (AA.alias(S->getPointerOperand(), 1, pointer, 1) !=
> +	  AliasAnalysis::MustAlias)
> +	return false;
>
> Knowing that the loaded and stored pointer must alias is important,  
> but you also need to check that the loaded and stored sizes equal  
> each other.
>
> +  // Look for a replacement for our pointer. If more than one  
> found, exit.
> +  for (User::use_iterator I = L->use_begin(), E = L->use_end(); I ! 
> = E; ++I) {
> +    Instruction *User = cast<Instruction>(*I);
> +
> +    if (StoreInst *SI = dyn_cast<StoreInst>(User)) {
> +      if (SI->isVolatile())
> +	return false;
> +
> +      if (!Repl)
> +	Repl = SI->getPointerOperand();
> +      else if (Repl != SI->getPointerOperand())
> +	return false;
> +
> +    } else
> +      return false;
> +  }
>
> Please do something like this:
>
> if (!L->hasOneUse()) return false;
> StoreInst *StoreOfLoad = dyn_cast<StoreInst>(L->use_back());
> if (StoreOfLoad == 0 || ...)
> ...
>
>
> Actually, I see now that the code actually allows multiple stores as  
> long as they are to the same pointer.  That also seems reasonable to  
> me, but please update the comment above the loop to make it really  
> clear what it is doing.  It is probably also reasonable to factor  
> this out to a static helper function.
>
> I'm still not sure that this transformation is safe (it seems like  
> we need another dependence query).  In particular, given something  
> like:
>
>    %temporary = alloca i8
>    call void @initialize(i8* noalias sret %temporary)
>    %tmp = load i8* %temporary
>    store 42 -> %result
>    store i8 %tmp, i8* %result
>
>
> It is not safe to transform this into:
>
>    call void @initialize(i8* noalias sret %result)
>    store 42 -> %result
>
>
> I think this can be fixed by doing a dependence query from the  
> store, though I'm not sure what we'd expect.  Another option is to  
> see if the result is only used by the store.  In this case, the loop  
> above that allows multiple stores to the same pointer seems unneeded  
> because we'd only be able to support one store.
>
> Thanks for working on this!
>
> -Chris
>
>
>


From isanbard at gmail.com  Wed Sep  2 03:48:29 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 2 Sep 2009 01:48:29 -0700
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
Message-ID: <B752FA4F-2F02-4FB9-9618-52C5AEA6A8A1@gmail.com>

On Aug 30, 2009, at 10:50 PM, Tanya Lattner wrote:

> LLVMers,
>
> 2.6 pre-release1 is ready to be tested by the community.
> http://llvm.org/prereleases/2.6/
>
> You will notice that we have quite a few pre-compiled binaries (of  
> both clang and llvm-gcc). We have identified several bugs that will  
> be fixed in pre-release2, so please search the bug database before  
> filing a new bug.
>
> If you have time, I'd appreciate anyone who can help test the release.
>
>
I'm running the G5 PPC tests right now. Results will be slow for  
sure. :)

-bw


From cprasenj at in.ibm.com  Wed Sep  2 08:16:16 2009
From: cprasenj at in.ibm.com (Prasenjit Chakraborty)
Date: Wed, 2 Sep 2009 18:46:16 +0530
Subject: [LLVMdev] Listing all loops in a function
Message-ID: <OFAFF43350.F6CD0B8E-ON65257625.00488988-65257625.0049168C@in.ibm.com>


Hi,
      I am new to LLVM. I want to go through all loops in a function. I see
that there is a LoopPass manager that I can use. But that is not much of
help, as I want to get the order of loops in CallGraphSCC order, hence I
visit each function and then just want to go over the loops.

Regards,

Prasenjit Chakraborty
Performance Modeling and Analysis
IBM Systems & Technology Lab


From llvm at assumetheposition.nl  Wed Sep  2 09:31:19 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Wed, 2 Sep 2009 16:31:19 +0200 (CEST)
Subject: [LLVMdev] LangRef description of 'add nsw' doesn't match reality
Message-ID: <38210.145.100.6.164.1251901879.squirrel@www.assumetheposition.nl>

The langref says for the 'add' instruction:

Syntax:

  <result> = add <ty> <op1>, <op2>          ; yields {ty}:result
  <result> = nuw add <ty> <op1>, <op2>      ; yields {ty}:result
  <result> = nsw add <ty> <op1>, <op2>      ; yields {ty}:result
  <result> = nuw nsw add <ty> <op1>, <op2>  ; yields {ty}:result

But llvm-as does not accept that sequence, only ... = add nsw ... (which
is also what llvm-gcc generates). E.g.

16:29|melis at juggle2:~> cat add.ll | grep nsw
  %2 = nsw add i32 %1, 1                          ; <i32> [#uses=1]
16:29|melis at juggle2:~> llvm-as add.ll
llvm-as: add.ll:14:8: error: expected instruction opcode
  %2 = nsw add i32 %1, 1                          ; <i32> [#uses=1]
       ^
16:29|melis at juggle2:~> cat add2.ll | grep nsw
  %2 = add nsw i32 %1, 1                          ; <i32> [#uses=1]
16:29|melis at juggle2:~> llvm-as add2.ll
16:29|melis at juggle2:~>

It seems the other variants of add (and sub) described also should list
the opcode first, followed by the wrap flag.

Paul


From wansheg at qq.com  Wed Sep  2 12:09:42 2009
From: wansheg at qq.com (=?gbk?B?zfTKpA==?=)
Date: Thu, 3 Sep 2009 01:09:42 +0800
Subject: [LLVMdev] about the autoconf version
Message-ID: <tencent_35BD976E638337E610B9B63D@qq.com>

Hi, 
     I'm new for llvm .  when I build the llvm sample project , find the autoconf version 2.5  is required . 
Is that  necessary ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/661de771/attachment.html 

From clattner at apple.com  Wed Sep  2 12:15:09 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 2 Sep 2009 10:15:09 -0700
Subject: [LLVMdev] [PATCH] PR2218
In-Reply-To: <3C9C4560-89C0-409E-8263-6AD0C9B63556@gcc.gnu.org>
References: <FC0F12B2-3BB4-40EA-8599-69B9B2DE1B2D@gcc.gnu.org>
	<2E8440DC-3C3A-49B7-AD48-DB4A2B20B890@apple.com>
	<1BB852EF-07C5-4BC8-9E27-942B6F2AF8B2@gcc.gnu.org>
	<8A739C24-C4C9-407E-BAF6-8A98C1FE86DE@apple.com>
	<3C9C4560-89C0-409E-8263-6AD0C9B63556@gcc.gnu.org>
Message-ID: <D590A047-D03E-492B-AF44-2A5188304E91@apple.com>


On Sep 2, 2009, at 1:07 AM, Jakub Staszak wrote:

> Hello,
>
> I fixed my patch as you asked. Sorry for the delay, I'd been working  
> on my SSU patch (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025347.html 
> )
>
> I hope that everything is fine now.

Hey Jakub,

Thanks for working on this again, one more round :)

Please merge the three testcases into one file.  We added a new  
FileCheck tool which allows you to check for the exact sequence of  
instructions expected, which also allows the tests to be merged into  
one file.

+/// MemCpyOpt::pointerIsParameter - returns true iff pointer is a  
parameter of
+/// C call instruction.
+bool MemCpyOpt::pointerIsParameter(Value *pointer, CallInst *C,  
unsigned &argI)
+{
+    CallSite CS = CallSite::get(C);
+    for (argI = 0; argI < CS.arg_size(); ++argI)

Please make this a static function, it doesn't need "this".  Also,  
please do something like this in the for loop:

+    for (argI = 0, CS.arg_size(); argI != argE; ++argI)


pointerIsParameter returning a bool and the argument # byref is  
somewhat awkward.  I think it would be better if it returned an int,  
which was -1 if not found.



+  MemoryDependenceAnalysis& MD =  
getAnalysis<MemoryDependenceAnalysis>();

You can sink this link to right before the call to MD.getDependency.



+  // Require pointer to have local dependency.
+  if (!dep.getInst() || dep.isNonLocal())
+    return false;

Random thought: after this patch goes in, it would be interesting to  
see how many queries get rejected because they are non-local: handling  
non-local would be pretty easy.  Please add a TODO that mentions this.

In any case, the check for dep.isNonLocal() can be removed.  Nonlocal  
queries have a null instruction.




+  } else if (StoreInst *S = dyn_cast<StoreInst>(dep.getInst())) {
...
+    uint64_t ptrSize = AA.getTypeStoreSize(pointer->getType());
...
+    uint64_t memSize = AA.getTypeStoreSize(memPtr->getType());
...
+    if (AA.alias(pointer, ptrSize, memPtr, memSize) !=  
AliasAnalysis::MustAlias)

This is passing in the size of the pointer, not the pointee.  However,  
since you only care about must alias, you don't care about the size of  
the object, you can just pass in 1 for both sizes.

Please put a comment above the call to AA.alias explaining why you  
require mustalias here.



+  // Look for a replacement for our pointer.  If more than one found,  
exit.
+  if (!L->hasOneUse())
+    return false;
+  StoreInst *StoreOfLoad = dyn_cast<StoreInst>(L->use_back());
+  if (!StoreOfLoad)
+    return false;

Please do these check before the MemDep query, they are very cheap and  
will make the optimization run faster (by avoiding queries).



I'm pretty sure that there is still a legality check missing here.   
Your code will transform this:

    %temporary = alloca i8
    call void @initialize(i8* noalias sret %temporary)
    %tmp = load i8* %temporary
    store i8 42, i8* %result
    store i8 %tmp, i8* %result

to:

    %temporary = alloca i8
    call void @initialize(i8* noalias sret %result)
    store i8 42, i8* %result

which is a miscompilation.  To fix this, I'd do a memdep query of  
"result" from StoreOfLoad and from L.  If they both have the same  
dependence, then the transform is ok.




+  if (CallInst *C = dyn_cast<CallInst>(dep.getInst())) {
+    CallSite CS = CallSite::get(C);
+    CS.setArgument(argI, Repl);

pointerIsParameter strips bitcasts.  Because of that, the type of the  
call argument may not be the same as the type of "repl", which could  
cause an assertion failure.  We need to either make pointerIsParameter  
not strip bitcasts, or have this code insert a bitcast when the types  
don't line up.

-Chris

From gohman at apple.com  Wed Sep  2 12:32:26 2009
From: gohman at apple.com (Dan Gohman)
Date: Wed, 2 Sep 2009 10:32:26 -0700
Subject: [LLVMdev] LangRef description of 'add nsw' doesn't match reality
In-Reply-To: <38210.145.100.6.164.1251901879.squirrel@www.assumetheposition.nl>
References: <38210.145.100.6.164.1251901879.squirrel@www.assumetheposition.nl>
Message-ID: <0142E141-F232-44B0-97F4-F4C8299FC1E9@apple.com>


On Sep 2, 2009, at 7:31 AM, Paul Melis wrote:


> The langref says for the 'add' instruction:
>
> Syntax:
>
>  <result> = add <ty> <op1>, <op2>          ; yields {ty}:result
>  <result> = nuw add <ty> <op1>, <op2>      ; yields {ty}:result
>  <result> = nsw add <ty> <op1>, <op2>      ; yields {ty}:result
>  <result> = nuw nsw add <ty> <op1>, <op2>  ; yields {ty}:result
>
> But llvm-as does not accept that sequence, only ... = add nsw ...  
> (which
> is also what llvm-gcc generates). E.g.
>
> 16:29|melis at juggle2:~> cat add.ll | grep nsw
>  %2 = nsw add i32 %1, 1                          ; <i32> [#uses=1]
> 16:29|melis at juggle2:~> llvm-as add.ll
> llvm-as: add.ll:14:8: error: expected instruction opcode
>  %2 = nsw add i32 %1, 1                          ; <i32> [#uses=1]
>       ^
> 16:29|melis at juggle2:~> cat add2.ll | grep nsw
>  %2 = add nsw i32 %1, 1                          ; <i32> [#uses=1]
> 16:29|melis at juggle2:~> llvm-as add2.ll
> 16:29|melis at juggle2:~>
>
> It seems the other variants of add (and sub) described also should  
> list
> the opcode first, followed by the wrap flag.

Thanks for spotting this; I just committed a documentation fix for this.

Thanks,

Dan


From Vasudev.Negi at microchip.com  Wed Sep  2 12:48:01 2009
From: Vasudev.Negi at microchip.com (Vasudev.Negi at microchip.com)
Date: Wed, 2 Sep 2009 10:48:01 -0700
Subject: [LLVMdev] writing an llvm pass
Message-ID: <F536B7C316F9474E9F7091239725AC9A030785B8@CHN-CL-MAIL01.mchp-main.com>

  I need to write a pass where I need to find all the predecessors of
each leaf node. I think the  options that I have is create a sub class
of ModulePass or CallGraphSCCPass. 

 I will need to traverse the call graph bottom up and by the description
of CallGraphSCCPass, it seems the Pass to use.  The problem that I am
facing is from a CallGraphNode, I don't see any way to get it's callers.


 

 So I think it will be better to use ModulePass. I start from the root.
For each function called  from root, I add root to its predecessor list.
Then I follow the same using BFS, and for each callee add the caller as
well as the predecessors of caller to callee's predecessor list.

 Any views or suggestions on this will be highly appreciated. 

 

Thanks

Vasudev

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

From kotha.aparna at gmail.com  Wed Sep  2 13:42:39 2009
From: kotha.aparna at gmail.com (aparna kotha)
Date: Wed, 2 Sep 2009 14:42:39 -0400
Subject: [LLVMdev] Listing all loops in a function
In-Reply-To: <OFAFF43350.F6CD0B8E-ON65257625.00488988-65257625.0049168C@in.ibm.com>
References: <OFAFF43350.F6CD0B8E-ON65257625.00488988-65257625.0049168C@in.ibm.com>
Message-ID: <326a2f490909021142x235f211ev46dd3927903c061c@mail.gmail.com>

Hi Prasenjit,

In a limited scope that we needed this kind of a method, we added dummy
functions to the header of every loop and then generated the call graph for
the module and we then traverse the call graph. I m not really sure if this
will work for u , but it did do the limited job we were interested in.



--Aparna

Graduate Student
University of Maryland, College Park


On Wed, Sep 2, 2009 at 9:16 AM, Prasenjit Chakraborty
<cprasenj at in.ibm.com>wrote:

>
> Hi,
>      I am new to LLVM. I want to go through all loops in a function. I see
> that there is a LoopPass manager that I can use. But that is not much of
> help, as I want to get the order of loops in CallGraphSCC order, hence I
> visit each function and then just want to go over the loops.
>
> Regards,
>
> Prasenjit Chakraborty
> Performance Modeling and Analysis
> IBM Systems & Technology Lab
>
> _______________________________________________
> 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/20090902/58be67bc/attachment.html 

From isanbard at gmail.com  Wed Sep  2 15:19:04 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 2 Sep 2009 13:19:04 -0700
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
Message-ID: <16e5fdf90909021319p20b83068p29a396f45fbd45b7@mail.gmail.com>

Hi Tanya,

The sources weren't updated for this pre-release testing. So I had the
same problems on PPC.

-bw

On Sun, Aug 30, 2009 at 10:50 PM, Tanya Lattner<lattner at apple.com> wrote:
> LLVMers,
> 2.6 pre-release1 is ready to be tested by the community.
> http://llvm.org/prereleases/2.6/
> You will notice that we have quite a few pre-compiled binaries (of both
> clang and llvm-gcc). We have identified several bugs that will be fixed in
> pre-release2, so please search the bug database before filing a new bug.
> If you have time, I'd appreciate anyone who can help test the release.
> To test llvm-gcc:
> 1) Compile llvm from source and untar the llvm-test in the projects
> directory (name it llvm-test or test-suite). Choose to use a pre-compiled
> llvm-gcc or re-compile it yourself.
> 2) Run make check, report any failures (FAIL or unexpected pass). Note that
> you need to reconfigure llvm with llvm-gcc in your path or with
> --with-llvmgccdir
> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>
> To test clang:
> 1) Compile llvm and clang from source.
> 2) Run make check for llvm.
> 3) Run make? -C tools/clang-2.6 test VERBOSE=1 (report any failures or
> unexpected passes)
> When reporting your results, please provide details on what platform you
> compiled on, and how
> you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.
> Please COMPLETE ALL TESTING BY end of the day on Sept. 5th!
> Thanks, Tanya Lattner
>
> _______________________________________________
> 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 Sep  2 15:30:14 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 2 Sep 2009 13:30:14 -0700
Subject: [LLVMdev] about the autoconf version
In-Reply-To: <tencent_35BD976E638337E610B9B63D@qq.com>
References: <tencent_35BD976E638337E610B9B63D@qq.com>
Message-ID: <16e5fdf90909021330x2e605cdfse443d54cc2d1a4f@mail.gmail.com>

2009/9/2 ?? <wansheg at qq.com>:
> Hi,
> ???? I'm new for llvm .? when I build the llvm sample project , find the
> autoconf version 2.5? is required .
> Is that? necessary ?
>
Yes and no:

Yes if you are using the AutoGen.sh script.

No, because there's nothing special about autoconf 2.5 that LLVM relies upon.

If you check the current SVN top-of-tree, the requirement of 2.5 has
been relaxed to include 2.6.

-bw


From jrk at csail.mit.edu  Wed Sep  2 15:49:50 2009
From: jrk at csail.mit.edu (Jonathan Ragan-Kelley)
Date: Wed, 2 Sep 2009 13:49:50 -0700 (PDT)
Subject: [LLVMdev] select with vector condition
Message-ID: <b57a2a39-35ea-44ee-a8e0-3a1110ccf2c9@m3g2000pri.googlegroups.com>

> If the condition is a vector of i1, then the value arguments must be vectors of the same size, and the selection is done element by element.
> ...
> Note that the code generator does not yet support conditions with vector type.

This issue seems to persist in the 2.6 prerelease. (It barfs in
instruction selection when there is a select with a vector condition.)
Is there any plan to support (or intention of supporting) vector
selects, now that they are representable in the IR?

It is a useful construct, and is useful to abstract across platforms
(e.g. SSE2/3 and SSE4.2 generally necessitate different strategies, as
do Cell SPU and AltiVec, and as will AVX, LRBni, ...), and at the very
least can be emulated by having a default lowering to the obvious per-
element extract-select-insert pattern.

For the time being, the workaround of using link-time selection of a
platform-specific intrinsic or library function is usable, but it
would be great to see it actually supported in the more common
backends, given that it was already deemed useful enough for inclusion
in the IR.

From kuba at gcc.gnu.org  Wed Sep  2 16:04:05 2009
From: kuba at gcc.gnu.org (Jakub Staszak)
Date: Wed, 2 Sep 2009 19:04:05 -0200
Subject: [LLVMdev] [PATCH] PR2218
In-Reply-To: <D590A047-D03E-492B-AF44-2A5188304E91@apple.com>
References: <FC0F12B2-3BB4-40EA-8599-69B9B2DE1B2D@gcc.gnu.org>
	<2E8440DC-3C3A-49B7-AD48-DB4A2B20B890@apple.com>
	<1BB852EF-07C5-4BC8-9E27-942B6F2AF8B2@gcc.gnu.org>
	<8A739C24-C4C9-407E-BAF6-8A98C1FE86DE@apple.com>
	<3C9C4560-89C0-409E-8263-6AD0C9B63556@gcc.gnu.org>
	<D590A047-D03E-492B-AF44-2A5188304E91@apple.com>
Message-ID: <4D0455A6-C2CC-4A32-B11D-5899CBA5E2C6@gcc.gnu.org>

On Sep 2, 2009, at 3:15 PM, Chris Lattner wrote:

> Please merge the three testcases into one file.  We added a new  
> FileCheck tool which allows you to check for the exact sequence of  
> instructions expected, which also allows the tests to be merged into  
> one file.
>
> +/// MemCpyOpt::pointerIsParameter - returns true iff pointer is a  
> parameter of
> +/// C call instruction.
> +bool MemCpyOpt::pointerIsParameter(Value *pointer, CallInst *C,  
> unsigned &argI)
> +{
> +    CallSite CS = CallSite::get(C);
> +    for (argI = 0; argI < CS.arg_size(); ++argI)
>
> Please make this a static function, it doesn't need "this".  Also,  
> please do something like this in the for loop:
>
> +    for (argI = 0, CS.arg_size(); argI != argE; ++argI)
>
>
> pointerIsParameter returning a bool and the argument # byref is  
> somewhat awkward.  I think it would be better if it returned an int,  
> which was -1 if not found.

The problem is that CS.arg_size() is "unsigned int". Of course, I can  
cast int -> unsigned int but it wouldn't look good I think.


>
> +  MemoryDependenceAnalysis& MD =  
> getAnalysis<MemoryDependenceAnalysis>();
>
> You can sink this link to right before the call to MD.getDependency.
>
>
>
> +  // Require pointer to have local dependency.
> +  if (!dep.getInst() || dep.isNonLocal())
> +    return false;
>
> Random thought: after this patch goes in, it would be interesting to  
> see how many queries get rejected because they are non-local:  
> handling non-local would be pretty easy.  Please add a TODO that  
> mentions this.
>
> In any case, the check for dep.isNonLocal() can be removed.   
> Nonlocal queries have a null instruction.

OK, i'll work on it.

>
> +  } else if (StoreInst *S = dyn_cast<StoreInst>(dep.getInst())) {
> ...
> +    uint64_t ptrSize = AA.getTypeStoreSize(pointer->getType());
> ...
> +    uint64_t memSize = AA.getTypeStoreSize(memPtr->getType());
> ...
> +    if (AA.alias(pointer, ptrSize, memPtr, memSize) !=  
> AliasAnalysis::MustAlias)
>
> This is passing in the size of the pointer, not the pointee.   
> However, since you only care about must alias, you don't care about  
> the size of the object, you can just pass in 1 for both sizes.

Ahh, last time you said I had to check sizes. You said:
"Knowing that the loaded and stored pointer must alias is important,  
but you also need to check that the loaded and stored sizes equal each  
other." :-)



> Please put a comment above the call to AA.alias explaining why you  
> require mustalias here.
>
>
>
> +  // Look for a replacement for our pointer.  If more than one  
> found, exit.
> +  if (!L->hasOneUse())
> +    return false;
> +  StoreInst *StoreOfLoad = dyn_cast<StoreInst>(L->use_back());
> +  if (!StoreOfLoad)
> +    return false;
>
> Please do these check before the MemDep query, they are very cheap  
> and will make the optimization run faster (by avoiding queries).
>
>
>
> I'm pretty sure that there is still a legality check missing here.   
> Your code will transform this:
>
>   %temporary = alloca i8
>   call void @initialize(i8* noalias sret %temporary)
>   %tmp = load i8* %temporary
>   store i8 42, i8* %result
>   store i8 %tmp, i8* %result
>
> to:
>
>   %temporary = alloca i8
>   call void @initialize(i8* noalias sret %result)
>   store i8 42, i8* %result
>
> which is a miscompilation.  To fix this, I'd do a memdep query of  
> "result" from StoreOfLoad and from L.  If they both have the same  
> dependence, then the transform is ok.

See PR2218-dont.ll test.


-Jakub

From ssen at apple.com  Wed Sep  2 16:18:14 2009
From: ssen at apple.com (Shantonu Sen)
Date: Wed, 2 Sep 2009 14:18:14 -0700
Subject: [LLVMdev] XPASS forAsmBlocksComplexJumpTarget.c (-fasm-blocks)
Message-ID: <53F16F98-94B2-4D23-90F1-A116983AB1F0@apple.com>

Building r80796 of the "release_26" branch on Ubuntu 9.04, I'm getting  
an XPASS on:

ssen at ssen:~/llvm/build$ make TESTONE=FrontendC/2009-08-11- 
AsmBlocksComplexJumpTarget.c check-one
make[1]: Entering directory `/home/ssen/llvm/build/test'
Making a new site.exp file...
XPASS: /home/ssen/llvm/test/FrontendC/2009-08-11- 
AsmBlocksComplexJumpTarget.c
make[1]: Leaving directory `/home/ssen/llvm/build/test'
ssen at ssen:~/llvm/build$ /usr/local//llvm/bin/gcc ../test/FrontendC/ 
2009-08-11-AsmBlocksComplexJumpTarget.c -fasm-blocks -S -o - | grep 1192
	jmp *1192(%eax)


Should -fasm-blocks really be supported on non-Darwin targets?


Shantonu Sen
ssen at apple.com

Sent from my Mac Pro


From dalej at apple.com  Wed Sep  2 17:01:10 2009
From: dalej at apple.com (Dale Johannesen)
Date: Wed, 2 Sep 2009 15:01:10 -0700
Subject: [LLVMdev] XPASS forAsmBlocksComplexJumpTarget.c (-fasm-blocks)
In-Reply-To: <53F16F98-94B2-4D23-90F1-A116983AB1F0@apple.com>
References: <53F16F98-94B2-4D23-90F1-A116983AB1F0@apple.com>
Message-ID: <60D96C9D-CB39-4A29-9542-8904FC566859@apple.com>


On Sep 2, 2009, at 2:18 PMPDT, Shantonu Sen wrote:

> Building r80796 of the "release_26" branch on Ubuntu 9.04, I'm getting
> an XPASS on:
>
> ssen at ssen:~/llvm/build$ make TESTONE=FrontendC/2009-08-11-
> AsmBlocksComplexJumpTarget.c check-one
> make[1]: Entering directory `/home/ssen/llvm/build/test'
> Making a new site.exp file...
> XPASS: /home/ssen/llvm/test/FrontendC/2009-08-11-
> AsmBlocksComplexJumpTarget.c
> make[1]: Leaving directory `/home/ssen/llvm/build/test'
> ssen at ssen:~/llvm/build$ /usr/local//llvm/bin/gcc ../test/FrontendC/
> 2009-08-11-AsmBlocksComplexJumpTarget.c -fasm-blocks -S -o - | grep  
> 1192
> 	jmp *1192(%eax)
>
>
> Should -fasm-blocks really be supported on non-Darwin targets?

It's not exactly supported, but it will mostly work on x86 Linux at  
this point.  I saw no reason to disable it; if somebody on Linux wants  
to make it fully usable, they can.  If the Linux guys prefer to  
disable it (to prevent being polluted by this horrible misfeature, I  
suppose), they can do that too.

I fixed this test in TOT, btw.


From gausszhch at gmail.com  Wed Sep  2 21:32:28 2009
From: gausszhch at gmail.com (gauss)
Date: Wed, 2 Sep 2009 19:32:28 -0700 (PDT)
Subject: [LLVMdev] link-error: different visibilities
In-Reply-To: <4A9E189C.503@getdesigned.at>
References: <25252124.post@talk.nabble.com> <4A9E189C.503@getdesigned.at>
Message-ID: <25268900.post@talk.nabble.com>


Thanks. It helps me a lot. The mangled name is a template method
"Vector<>::size()" inserted by llvm-g++ at compile time. 
Why did llvm-ld fail to link those *.o files as long as llvm-g++ compiled
all the *.cpp file correctly? Is there some wrong with LLVM-g++? How to deal
with it? 

Any ideas about it?

Thanks!

Gauss, 09-03


Sebastian Redl wrote:
> 
> Use the c++filt program (part of GNU binutils) to demangle the name. The
> function in question is
> std::vector<gnash::geometry::Range2d<float>,
> std::allocator<gnash::geometry::Range2d<float> > >::size() const
> 
> Sebastian
> _______________________________________________
> 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/link-error%3A-different-visibilities-tp25252124p25268900.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From daniel at zuster.org  Wed Sep  2 21:55:18 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Wed, 2 Sep 2009 19:55:18 -0700
Subject: [LLVMdev] Problem building libprofile.
In-Reply-To: <4A9D5FB5.5090307@gmx.at>
References: <4A9D5FB5.5090307@gmx.at>
Message-ID: <6a8523d60909021955p37c58999ned84790548a4aef1@mail.gmail.com>

Hi Andreas,

Did you resolve this? If not please file a bug with the input .bc
files and the llvm-ld command line that crashes.

 - Daniel

On Tue, Sep 1, 2009 at 10:53 AM, Andreas Neustifter<astifter-llvm at gmx.at> wrote:
> Hi,
>
> when I try to build libprofile with r80670 (both llvm and llvm-gcc) I
> get this error:
>
> make[1]: Entering directory `.../llvm-svn-debug-obj/runtime/libprofile'
> llvm[1]: Building Debug Bytecode Archive libprofile_rt.bca (internalize)
> llvm[1]: Installing Debug Shared Library
> /nfs/a5/astifter/astifter/llvm/llvm-svn-debug-obj/../llvm-svn-debug-install/lib/libprofile_rt.so
> 0 ? llvm-ld ? ? ? ? 0x0000000000981568
> 1 ? llvm-ld ? ? ? ? 0x0000000000981ac7
> 2 ? libpthread.so.0 0x00002aaaaacd6a80
> 3 ? llvm-ld ? ? ? ? 0x00000000006c036c llvm::Value::getValueID() const + 12
> 4 ? llvm-ld ? ? ? ? 0x00000000006c038a bool
> llvm::isa_impl<llvm::Constant, llvm::Value>(llvm::Value const&) + 21
> 5 ? llvm-ld ? ? ? ? 0x00000000006c40a0
> llvm::isa_impl_wrap<llvm::Constant, llvm::Value const, llvm::Value
> const>::doit(llvm::Value const&) + 21
> 6 ? llvm-ld ? ? ? ? 0x00000000006c40b7 bool
> llvm::isa_impl_cl<llvm::Value>::isa<llvm::Constant>(llvm::Value const&) + 21
> 7 ? llvm-ld ? ? ? ? 0x00000000006c40ce bool
> llvm::isa_impl_cl<llvm::Value const>::isa<llvm::Constant>(llvm::Value
> const&) + 21
> 8 ? llvm-ld ? ? ? ? 0x00000000006c40e5 bool
> llvm::isa_impl_cl<llvm::Value const*>::isa<llvm::Constant>(llvm::Value
> const*) + 21
> 9 ? llvm-ld ? ? ? ? 0x00000000006c40ff bool llvm::isa<llvm::Constant,
> llvm::Value const*>(llvm::Value const* const&) + 24
> 10 ?llvm-ld ? ? ? ? 0x00000000006d4e27 llvm::cast_retty<llvm::Constant,
> llvm::Value const*>::ret_type llvm::dyn_cast<llvm::Constant, llvm::Value
> const*>(llvm::Value const* const&) + 21
> 11 ?llvm-ld ? ? ? ? 0x00000000006da102
> 12 ?llvm-ld ? ? ? ? 0x00000000006da65d
> 13 ?llvm-ld ? ? ? ? 0x00000000006da65d
> 14 ?llvm-ld ? ? ? ? 0x00000000006daade
> 15 ?llvm-ld ? ? ? ? 0x00000000006dac98
> 16 ?llvm-ld ? ? ? ? 0x00000000006de6d9
> llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::string*) + 1897
> 17 ?llvm-ld ? ? ? ? 0x00000000006d8a7d
> llvm::Linker::LinkInModule(llvm::Module*, std::string*) + 41
> 18 ?llvm-ld ? ? ? ? 0x00000000006d7ff3
> llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&) + 1431
> 19 ?llvm-ld ? ? ? ? 0x00000000006d867e
> llvm::Linker::LinkInItems(std::vector<std::pair<std::string, bool>,
> std::allocator<std::pair<std::string, bool> > > const&,
> std::vector<std::pair<std::string, bool>,
> std::allocator<std::pair<std::string, bool> > >&) + 258
> 20 ?llvm-ld ? ? ? ? 0x00000000006b3050 main + 1349
> 21 ?libc.so.6 ? ? ? 0x00002aaaabaaf1a6 __libc_start_main + 230
> 22 ?llvm-ld ? ? ? ? 0x00000000006aa039 __gxx_personality_v0 + 689
> Stack dump:
> 0. ? ? ?Program arguments: .../llvm-svn-debug-obj/Debug/bin/llvm-ld
> -L.../llvm-van-install/bin/../lib
> -internalize-public-api-file=.../llvm-svn/runtime/libprofile/exported_symbols.lst
> -o
> .../llvm-svn-debug-obj/runtime/libprofile/Debug/profile_rt.internalize
> .../llvm-svn-debug-obj/runtime/libprofile/Debug/BasicBlockTracing.bc
> .../llvm-svn-debug-obj/runtime/libprofile/Debug/BlockProfiling.bc
> .../llvm-svn-debug-obj/runtime/libprofile/Debug/CommonProfiling.bc
> .../llvm-svn-debug-obj/runtime/libprofile/Debug/EdgeProfiling.bc
> .../llvm-svn-debug-obj/runtime/libprofile/Debug/FunctionProfiling.bc
> .../llvm-svn-debug-obj/runtime/libprofile/Debug/OptimalEdgeProfiling.bc
> make[1]: *** [.../llvm-svn-debug-obj/Debug/lib/libprofile_rt.bca]
> Segmentation fault
> make[1]: Leaving directory `.../llvm-svn-debug-obj/runtime/libprofile'
> make: *** [libprofile/.makeinstall] Error 2
>
> Any toughts? (I attach the build log, so it does not get garbled.)
>
> Andi
>
> --
> ==========================================================================
> This email is signed, for more information see
> http://web.student.tuwien.ac.at/~e0325716/gpg.html
>
>
> _______________________________________________
> 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  Wed Sep  2 22:04:48 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 2 Sep 2009 20:04:48 -0700
Subject: [LLVMdev] [PATCH] PR2218
In-Reply-To: <4D0455A6-C2CC-4A32-B11D-5899CBA5E2C6@gcc.gnu.org>
References: <FC0F12B2-3BB4-40EA-8599-69B9B2DE1B2D@gcc.gnu.org>
	<2E8440DC-3C3A-49B7-AD48-DB4A2B20B890@apple.com>
	<1BB852EF-07C5-4BC8-9E27-942B6F2AF8B2@gcc.gnu.org>
	<8A739C24-C4C9-407E-BAF6-8A98C1FE86DE@apple.com>
	<3C9C4560-89C0-409E-8263-6AD0C9B63556@gcc.gnu.org>
	<D590A047-D03E-492B-AF44-2A5188304E91@apple.com>
	<4D0455A6-C2CC-4A32-B11D-5899CBA5E2C6@gcc.gnu.org>
Message-ID: <882838C4-342C-4775-B1D6-41168F2B325A@apple.com>

On Sep 2, 2009, at 2:04 PM, Jakub Staszak wrote:
>> Please make this a static function, it doesn't need "this".  Also,  
>> please do something like this in the for loop:
>>
>> +    for (argI = 0, CS.arg_size(); argI != argE; ++argI)
>>
>>
>> pointerIsParameter returning a bool and the argument # byref is  
>> somewhat awkward.  I think it would be better if it returned an  
>> int, which was -1 if not found.
>
> The problem is that CS.arg_size() is "unsigned int". Of course, I  
> can cast int -> unsigned int but it wouldn't look good I think.

The typical way to do this is to return it as int, then at the call  
site do something like:


int V = foo();
if (V == -1) handle error

unsigned RealVal = (unsigned)V;

That way, it is very explicit what is going on.

>> +  } else if (StoreInst *S = dyn_cast<StoreInst>(dep.getInst())) {
>> ...
>> +    uint64_t ptrSize = AA.getTypeStoreSize(pointer->getType());
>> ...
>> +    uint64_t memSize = AA.getTypeStoreSize(memPtr->getType());
>> ...
>> +    if (AA.alias(pointer, ptrSize, memPtr, memSize) !=  
>> AliasAnalysis::MustAlias)
>>
>> This is passing in the size of the pointer, not the pointee.   
>> However, since you only care about must alias, you don't care about  
>> the size of the object, you can just pass in 1 for both sizes.
>
> Ahh, last time you said I had to check sizes. You said:
> "Knowing that the loaded and stored pointer must alias is important,  
> but you also need to check that the loaded and stored sizes equal  
> each other." :-)

This is a different issue.  Previously you would trigger when the load  
and store were of a pointer that could have been bitcast.  You need to  
check that the load and store have the same size, but that doesn't  
impact the alias query.

>> I'm pretty sure that there is still a legality check missing here.   
>> Your code will transform this:
>>
>>  %temporary = alloca i8
>>  call void @initialize(i8* noalias sret %temporary)
>>  %tmp = load i8* %temporary
>>  store i8 42, i8* %result
>>  store i8 %tmp, i8* %result
>>
>> to:
>>
>>  %temporary = alloca i8
>>  call void @initialize(i8* noalias sret %result)
>>  store i8 42, i8* %result
>>
>> which is a miscompilation.  To fix this, I'd do a memdep query of  
>> "result" from StoreOfLoad and from L.  If they both have the same  
>> dependence, then the transform is ok.
>
> See PR2218-dont.ll test.

What do you mean?

-Chris

From viridia at gmail.com  Thu Sep  3 03:45:25 2009
From: viridia at gmail.com (Talin)
Date: Thu, 03 Sep 2009 01:45:25 -0700
Subject: [LLVMdev] Perfect forwarding?
In-Reply-To: <3f49a9f40908312257r4c7cb66t18f4d067b1d78399@mail.gmail.com>
References: <4A9ADF1B.8010403@gmail.com>	<3f49a9f40908301539g2993e48bv24772efa578f259c@mail.gmail.com>	<3f49a9f40908301543o4eb88d95idc38237d9ab90160@mail.gmail.com>	<4A9CAB16.20602@gmail.com>	<3f49a9f40908312253g35f9b48ai1a673ef3c8c2622f@mail.gmail.com>
	<3f49a9f40908312257r4c7cb66t18f4d067b1d78399@mail.gmail.com>
Message-ID: <4A9F8225.1010309@gmail.com>

OvermindDL1 wrote:
> Boost.Fusion has adapters to convert structs/classes into
> tuples/kwtuples.  You have to write the short and simple adapter for
> your classes, but it would allow you to iterate over
> everything/anything in it.  I have done this exact thing.  Not quite
> fully what you want, but Boost.Fusion and other bits of other boost
> metalibraries seem to do most of what you want.  Might be interesting
> to look at?
>   
Possibly. Bear in mind that part of my goal is to make something like 
Boost obsolete - because my language's type inference engine is more 
powerful than C++'s template resolution algorithms, it will allow many 
of the same things that Boost does, but without requiring the complex 
metaprogramming techniques that Boost uses to implement them. At least, 
that's the plan.
> _______________________________________________
> 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  Thu Sep  3 04:05:56 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 03 Sep 2009 11:05:56 +0200
Subject: [LLVMdev] Non-local DSE optimization
In-Reply-To: <830819AC-2A14-435D-86FE-CB09F73F31F6@gcc.gnu.org>
References: <830819AC-2A14-435D-86FE-CB09F73F31F6@gcc.gnu.org>
Message-ID: <4A9F86F4.3070609@free.fr>

Hi Jakub, interesting patch.  I ran it over the Ada testsuite and this
picked up some problems even without enabling dse-ssu.  For example,
"opt -inline -dse -domtree" crashes on the attached testcase.

Ciao,

Duncan.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dom_crash.ll
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/92388d09/attachment.pl 

From astifter-llvm at gmx.at  Thu Sep  3 05:37:27 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Thu, 03 Sep 2009 12:37:27 +0200
Subject: [LLVMdev] Trouble with rewriting MaximumSpanningTree as template.
Message-ID: <4A9F9C67.8090007@gmx.at>

Hi,

since the MaximumSpanningTree-Algorithm is useful in may ways it would
be great to have this available as generic algorithm.
(See
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090824/085454.html)

Problem is: I can't get it to work. The attached patch (which depends on
lib/Transforms/Instrumentation/MaximumSpanningTree.* being removed
before application) does not compile with

$> .../lib/Transforms/Instrumentation/MaximumSpanningTree.cpp:38: error:
'stable_sort' is not a member of 'std'

which I find kind of curious since std::stable_sort didn't make a
problem in the specific implementation.

This problem aside I get the error

$> llvm[2]: Linking Debug executable opt
$>
.../llvm-svn-debug-obj/Debug/lib/libLLVMInstrumentation.a(OptimalEdgeProfiling.o):
In function `(anonymous
namespace)::OptimalEdgeProfiler::runOnModule(llvm::Module&)':
$>
.../llvm/llvm-svn/lib/Transforms/Instrumentation/OptimalEdgeProfiling.cpp:135:
undefined reference to `llvm::MaximumSpanningTree<llvm::BasicBlock
const*>::MaximumSpanningTree(std::vector<std::pair<std::pair<llvm::BasicBlock
const*, llvm::BasicBlock const*>, double>,
std::allocator<std::pair<std::pair<llvm::BasicBlock const*,
llvm::BasicBlock const*>, double> > >&)'
$> collect2: ld returned 1 exit status

when linking this stuff together.

Any hints?

Andi

-- 
==========================================================================
This email is signed, for more information see
http://web.student.tuwien.ac.at/~e0325716/gpg.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-r80913.maxspanntree.as.template.patch
Type: text/x-patch
Size: 5257 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/664fef7b/attachment.bin 

From mikael.lepisto at tut.fi  Thu Sep  3 05:40:47 2009
From: mikael.lepisto at tut.fi (=?ISO-8859-1?Q?Mikael_Lepist=F6?=)
Date: Thu, 03 Sep 2009 13:40:47 +0300
Subject: [LLVMdev] Problem with generating Machine function analysis pass
Message-ID: <4A9F9D2F.3060708@tut.fi>

Hi,

I've been encountering a problem with function pass manager with 
llvm-2.6. Somehow system does not know how to create analysis pass if 
it's required by some other pass.

I got following after adding various debug prints to PassManager.cpp I 
got following results for my reduced test program which just loads 
module and then tries to make a function pass manager.

elhigu at mr-lenovo:~/temp$ g++ `llvm-config --cxxflags` -g -o test test.cc 
`llvm-config --ldflags --libs`
elhigu at mr-lenovo:~/temp$ ./test
------------------- finding usage Target Data Layout
------------------- found usage
------------------- check analysis
--------Required set ----------
--------     end     ----------
------------------- analysis checked if it was there
------------------- finding usage If Converter
------------------- found usage
------------------- check analysis
--------Required set ----------
Machine Function Analysis
--------     end     ----------
---------- finding... Machine Function Analysis
-------------------------------- Oh no no analysis pass
test: 
/home/elhigu/stow_sources/llvm-2.6-svn/include/llvm/PassSupport.h:111: 
llvm::Pass* llvm::PassInfo::createPass() const: Assertion `NormalCtor && 
"Cannot call createPass on PassInfo without default ctor!"' failed.
Aborted

When I tried to compile the same file with llc Machine Function Analysis 
pass was created with out problems. Am I missing some pass registration 
initialisation or something like that? Any ideas what I'm doing wrong?

For many other passes (*I)->createPass() does worked correctly.

I attached modified PassManager.cpp which shows, where the debug strings 
are coming from and source code of test.cc program.

Thanks, Mikael Lepist? ( for instant helping I'm hanging around on #llvm 
with elhigu nick )


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cc
Type: text/x-c++src
Size: 1287 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/e749bd92/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PassManager.cpp
Type: text/x-c++src
Size: 58381 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/e749bd92/attachment-0003.bin 

From overminddl1 at gmail.com  Thu Sep  3 06:12:17 2009
From: overminddl1 at gmail.com (OvermindDL1)
Date: Thu, 3 Sep 2009 05:12:17 -0600
Subject: [LLVMdev] Perfect forwarding?
In-Reply-To: <3f49a9f40909030410k346a878ar826a606fcf073372@mail.gmail.com>
References: <4A9ADF1B.8010403@gmail.com>
	<3f49a9f40908301539g2993e48bv24772efa578f259c@mail.gmail.com>
	<3f49a9f40908301543o4eb88d95idc38237d9ab90160@mail.gmail.com>
	<4A9CAB16.20602@gmail.com>
	<3f49a9f40908312253g35f9b48ai1a673ef3c8c2622f@mail.gmail.com>
	<3f49a9f40908312257r4c7cb66t18f4d067b1d78399@mail.gmail.com>
	<4A9F8225.1010309@gmail.com>
	<3f49a9f40909030410k346a878ar826a606fcf073372@mail.gmail.com>
Message-ID: <3f49a9f40909030412l1fff27cen9b69f12ff141188f@mail.gmail.com>

Gah, headers not set appropriately, message I sent is forwarded below
(it still takes a good extra 45-90 seconds to change the "To" line on
this device...):

On Thu, Sep 3, 2009 at 2:45 AM, Talin<viridia at gmail.com> wrote:
> OvermindDL1 wrote:
>>
>> Boost.Fusion has adapters to convert structs/classes into
>> tuples/kwtuples.  You have to write the short and simple adapter for
>> your classes, but it would allow you to iterate over
>> everything/anything in it.  I have done this exact thing.  Not quite
>> fully what you want, but Boost.Fusion and other bits of other boost
>> metalibraries seem to do most of what you want.  Might be interesting
>> to look at?
>>
>
> Possibly. Bear in mind that part of my goal is to make something like Boost
> obsolete - because my language's type inference engine is more powerful than
> C++'s template resolution algorithms, it will allow many of the same things
> that Boost does, but without requiring the complex metaprogramming
> techniques that Boost uses to implement them. At least, that's the plan.

Heh, I am doing the same thing.  I am basically creating a strongly
typed, static-typed LISP.  Yes, I know, you can add types in LISP, but
having it be fully strongly and statically typed lets me compile it
that much easier, and I prefer strongly and statically typed anyway.
:)

From hvdieren at elis.UGent.be  Thu Sep  3 06:15:47 2009
From: hvdieren at elis.UGent.be (Hans Vandierendonck)
Date: Thu, 03 Sep 2009 13:15:47 +0200
Subject: [LLVMdev] SCCIterator and unconnected graphs
Message-ID: <4A9FA563.1030602@elis.UGent.be>

Hi,

I am using the scc_iterator class in my code on a CallGraph, where some 
functions are not called from within the module. It seems that 
scc_iterator does not list all SCCs if the graph is not connected; only 
those nodes connected to the node pointed to by 
GraphTraits<...>::getEntryNode() are returned.

Can someone verify this behavior?
Any tips on how I should go about extending the class in order to visit 
all SCCs?
Is it desirable to augment the scc_iterator class itself, or should I 
construct another one? The change in behavior may impact things such as 
CallGraphSCCPass, GlobalsModRef, etc. and I don't know if it is 
desirable to have that change there.

Many thanks,
Hans.

-- 
-------------------------------------------------------------------------------
 Hans Vandierendonck, PhD, Ghent University, Electronics & Information Systems
 E-mail: hans.vandierendonck at UGent.be      http://www.elis.UGent.be/~hvdieren/
-------------------------------------------------------------------------------


From sebastian.redl at getdesigned.at  Thu Sep  3 06:43:28 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Thu, 03 Sep 2009 13:43:28 +0200
Subject: [LLVMdev] Trouble with rewriting MaximumSpanningTree as
	template.
In-Reply-To: <4A9F9C67.8090007@gmx.at>
References: <4A9F9C67.8090007@gmx.at>
Message-ID: <4A9FABE0.1080001@getdesigned.at>

Andreas Neustifter wrote:
> $> .../lib/Transforms/Instrumentation/MaximumSpanningTree.cpp:38: error:
> 'stable_sort' is not a member of 'std'
>
> which I find kind of curious since std::stable_sort didn't make a
> problem in the specific implementation.
>   
I don't see anything that definitely pulls <algorithm> in, so it may be
a case of one implementation happening to do it, and the other not.
> This problem aside I get the error
>
> $> llvm[2]: Linking Debug executable opt
> $>
> .../llvm-svn-debug-obj/Debug/lib/libLLVMInstrumentation.a(OptimalEdgeProfiling.o):
> In function `(anonymous
> namespace)::OptimalEdgeProfiler::runOnModule(llvm::Module&)':
> $>
> .../llvm/llvm-svn/lib/Transforms/Instrumentation/OptimalEdgeProfiling.cpp:135:
> undefined reference to `llvm::MaximumSpanningTree<llvm::BasicBlock
> const*>::MaximumSpanningTree(std::vector<std::pair<std::pair<llvm::BasicBlock
> const*, llvm::BasicBlock const*>, double>,
> std::allocator<std::pair<std::pair<llvm::BasicBlock const*,
> llvm::BasicBlock const*>, double> > >&)'
> $> collect2: ld returned 1 exit status
>
> when linking this stuff together.
>   
You can't define templates in .cpp files; they must be available for
instantiation in each source file.

Sebastian

From torvald at se.inf.tu-dresden.de  Thu Sep  3 07:49:51 2009
From: torvald at se.inf.tu-dresden.de (Torvald Riegel)
Date: Thu, 3 Sep 2009 14:49:51 +0200
Subject: [LLVMdev] llvm-gcc ignores function attributes of template
	functions?
Message-ID: <200909031449.51261.torvald@se.inf.tu-dresden.de>

Hi,

llvm-gcc of LLVM 2.5 seems to ignore function attributes of template 
functions. For example, it doesn't set the noinline attribute, and it doesn't 
warn on unknown attribute names. Is this known / intended behavior?

Thanks,
Torvald

From fedor.sakharov at gmail.com  Thu Sep  3 08:00:55 2009
From: fedor.sakharov at gmail.com (Fedor Sakharov)
Date: Thu, 3 Sep 2009 13:00:55 +0000
Subject: [LLVMdev] Solaris SPARC llvm-gcc front-end
Message-ID: <ee796e3a0909030600j7dcbc7c0xc88dfa7797d81f24@mail.gmail.com>

Hello.

How are the things going with the llvm-gcc for SPARC and Solaris OS? I have
discovered recently the fact, that the code is still in the "patches
welcome" stage and is far even from being successfully built on SPARC. I
would like to know, if anyone maintaining this code, what is the current
to-do list, etc. I would like to offer my help for gcc front-end on SPARC
project.

-- 
Best regards,
Fedor Sakharov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/29de9f1c/attachment.html 

From meurant.olivier at gmail.com  Thu Sep  3 08:24:53 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Thu, 3 Sep 2009 15:24:53 +0200
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <16e5fdf90909021319p20b83068p29a396f45fbd45b7@mail.gmail.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
	<16e5fdf90909021319p20b83068p29a396f45fbd45b7@mail.gmail.com>
Message-ID: <549cee610909030624y73d398c5oc12837ea0e50a84b@mail.gmail.com>

Hi Tanya,

I have tried the 2.6 pre-release on the following host :

Windows XP pro SP2 with mingw/msys :

uname -a
MINGW32_NT-5.1 OLIVE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown

gcc -v
Reading specs from d:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld
--with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
--enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java
--disable-win32-registry --disable-shared --enable-sjlj-exceptions
--enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter --enable-hash-synchronization
--enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw special)


- srcDir != objDir
- The build went fine. (configure and make)
- llvm make check : not possible under mingw (dejagnu...)
- clang make check fails :

Every call to clang binary ends like this :
./Release/bin/clang foo.c
Stack dump:
0.      Program arguments: d:/llvm/llvm-2.6/build/Release/bin/clang-cc.exe
-triple i386-pc-mingw32 -S -disable-free -main-file-name foo.c
--relocation-model static --disable-fp-elim --unwind-tables=0
--mcpu=pentium4 --fmath-errno=1 -fdiagnostics-show-option -o
C:/Temp/cc-000000.s -x c foo.c
77C42A16 (0x0022F958 0x0167C757 0x0022F988 0x0167CBE8), wscanf()+1872
bytes(s)
77C3F962 (0x0022F9B0 0x0167C757 0x0167CBE8 0xFFFFFFFF), sprintf()+0049
bytes(s)
0046DA0C (0x10202000 0x20101010 0x20202020 0x60404020)
01AED7D4 (0x015B9F80 0x015B8590 0x015B9070 0x0081BC20) <unknown module>
01107940 (0x95340800 0x24048901 0x71ECFBE8 0x0CC483FF)
C7102444 (0x00000000 0x00000000 0x00000000 0x00000000) <unknown module>
clang: error: compiler command failed due to signal 1073741819 (use -v to
see invocation)


A debug build fails on the same problem :
./Debug/bin/clang foo.c
Stack dump:
0.      Program arguments:
d:/llvm/llvm-2.6/build_debug/Debug/bin/clang-cc.exe -triple i386-pc-mingw32
-S -disable-free -main-file-name foo.c --relocation-model static
--disable-fp-elim --unwind-tables=0 --mcpu=pentium4 --fmath-errno=1
-fdiagnostics-show-option -o C:/Temp/cc-000000.s -x c foo.c
77C42A16 (0x0022F948 0x01354530 0x0022F978 0x121CC7A8), wscanf()+1872
bytes(s)
77C3F962 (0x0022F9A0 0x01354530 0x013548FD 0xFFFFFFFF), sprintf()+0049
bytes(s)
0043EC6D (0x013548FD 0x00000040 0x01354896 0x00000001)
0043F2C5 (0x003D4068 0x121CC1F4 0x0022FAD0 0x01354BC9)
0043F90C (0x121CC1F0 0x0022FB20 0x0022FD00 0x003D4068)
010C2752 (0x0022FC50 0x0022FE10 0x0022FD00 0x003D4068)
00406086 (0x00000013 0x003D3F90 0x003D3028 0x015CF000)
0040124B (0x00000001 0x00000009 0x0022FFF0 0x7C816FE7)
00401298 (0x002420A8 0x0022F1E8 0x7FFD7000 0xC0000005)
7C816FE7 (0x00401280 0x00000000 0x78746341 0x00000020),
RegisterWaitForInputIdle()+0073 bytes(s)
clang: error: compiler command failed due to signal 1073741819 (use -v to
see invocation)


Here is the stack trace, I try to re-build :
___mingw_CRTStartup
_main
(anonymous namespace)::DriverPreprocessorFactory::CreatePreprocessor()
clang::InitializePreprocessor(clang::Preprocessor&,
clang::PreprocessorInitOptions const&)
clang::InitializePredefinedMacros(clang::TargetInfo const&,
clang::LangOptions const&, std::vector<char, std::allocator<char> >&)
clang::DefineTypeSize(char const*, unsigned int, char const*, bool,
std::vector<char, std::allocator<char> >&)
_sprintf


The "faulty" call to DefineTypeSize is the 5th. The one which used a "long
long" type.
In the method DefineTypeSize, the call to sprintf is as follow :
sprintf(MacroBuf, "%s=%llu%s", MacroName, MaxVal, ValSuffix);
and should be transformed to :
sprintf(MacroBuf, "%s=%I64u%s", MacroName, MaxVal, ValSuffix);
as mingw toolchain don't support "%llu" marker.

With this correction, clang seems to work on this platform.

I wanted to provide a patch but I'm not able to find something like
"LLVM_ON_MINGW" macro definition. Sorry. :(
.
Thanks for your work !

Cheers,
Olivier.


On Wed, Sep 2, 2009 at 10:19 PM, Bill Wendling <isanbard at gmail.com> wrote:

> Hi Tanya,
>
> The sources weren't updated for this pre-release testing. So I had the
> same problems on PPC.
>
> -bw
>
> On Sun, Aug 30, 2009 at 10:50 PM, Tanya Lattner<lattner at apple.com> wrote:
> > LLVMers,
> > 2.6 pre-release1 is ready to be tested by the community.
> > http://llvm.org/prereleases/2.6/
> > You will notice that we have quite a few pre-compiled binaries (of both
> > clang and llvm-gcc). We have identified several bugs that will be fixed
> in
> > pre-release2, so please search the bug database before filing a new bug.
> > If you have time, I'd appreciate anyone who can help test the release.
> > To test llvm-gcc:
> > 1) Compile llvm from source and untar the llvm-test in the projects
> > directory (name it llvm-test or test-suite). Choose to use a pre-compiled
> > llvm-gcc or re-compile it yourself.
> > 2) Run make check, report any failures (FAIL or unexpected pass). Note
> that
> > you need to reconfigure llvm with llvm-gcc in your path or with
> > --with-llvmgccdir
> > 3) Run "make TEST=nightly report" and send me the report.nightly.txt
> >
> > To test clang:
> > 1) Compile llvm and clang from source.
> > 2) Run make check for llvm.
> > 3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or
> > unexpected passes)
> > When reporting your results, please provide details on what platform you
> > compiled on, and how
> > you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.
> > Please COMPLETE ALL TESTING BY end of the day on Sept. 5th!
> > Thanks, Tanya Lattner
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/b0b90af6/attachment.html 

From astifter-llvm at gmx.at  Thu Sep  3 08:30:36 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Thu, 03 Sep 2009 15:30:36 +0200
Subject: [LLVMdev] Trouble with rewriting MaximumSpanningTree as
	template.
In-Reply-To: <4A9FABE0.1080001@getdesigned.at>
References: <4A9F9C67.8090007@gmx.at> <4A9FABE0.1080001@getdesigned.at>
Message-ID: <4A9FC4FC.7070809@gmx.at>

Thanks a lot, that did the trick!

Andi

Sebastian Redl wrote:
> Andreas Neustifter wrote:
>> $> .../lib/Transforms/Instrumentation/MaximumSpanningTree.cpp:38: error:
>> 'stable_sort' is not a member of 'std'
>>
>> which I find kind of curious since std::stable_sort didn't make a
>> problem in the specific implementation.
>>   
> I don't see anything that definitely pulls <algorithm> in, so it may be
> a case of one implementation happening to do it, and the other not.
>> This problem aside I get the error
>>
>> $> llvm[2]: Linking Debug executable opt
>> $>
>> .../llvm-svn-debug-obj/Debug/lib/libLLVMInstrumentation.a(OptimalEdgeProfiling.o):
>> In function `(anonymous
>> namespace)::OptimalEdgeProfiler::runOnModule(llvm::Module&)':
>> $>
>> .../llvm/llvm-svn/lib/Transforms/Instrumentation/OptimalEdgeProfiling.cpp:135:
>> undefined reference to `llvm::MaximumSpanningTree<llvm::BasicBlock
>> const*>::MaximumSpanningTree(std::vector<std::pair<std::pair<llvm::BasicBlock
>> const*, llvm::BasicBlock const*>, double>,
>> std::allocator<std::pair<std::pair<llvm::BasicBlock const*,
>> llvm::BasicBlock const*>, double> > >&)'
>> $> collect2: ld returned 1 exit status
>>
>> when linking this stuff together.
>>   
> You can't define templates in .cpp files; they must be available for
> instantiation in each source file.
> 
> Sebastian
> 

From aaronngray.lists at googlemail.com  Thu Sep  3 09:57:52 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Thu, 3 Sep 2009 15:57:52 +0100
Subject: [LLVMdev] LLVM 2.6 Cygwin Release
Message-ID: <9719867c0909030757m722d8dfh1e2b72b0bb8298e6@mail.gmail.com>

Tanya,

This patch at the end of this message is needed for Cygwin and GCC 4.2.x
series.

I also had to disable 'runtime/libprofile' by including the following in
'runtime/makefile' :-

    ifeq ($(OS), Cygwin)
    PARALLEL_DIRS := $(filter-out libprofile, $(PARALLEL_DIRS))
    endif

There maybe a better fix to make it work.

Aaron



---------- Forwarded message ----------
From: Nick Lewycky <nicholas at mxc.ca>
Date: 2009/8/29
Subject: [llvm-commits] [llvm-gcc-4.2] r80424 -
/llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
To: llvm-commits at cs.uiuc.edu


Author: nicholas
Date: Sat Aug 29 02:23:49 2009
New Revision: 80424

URL: http://llvm.org/viewvc/llvm-project?rev=80424&view=rev
Log:
Fix invalid conversion. Patch by Aaron Gray!

Modified:
   llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

Modified: llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp?rev=80424&r1=80423&r2=80424&view=diff

==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp Sat Aug 29 02:23:49 2009
@@ -7124,7 +7124,7 @@
  } else if (ElTy == Type::getInt32Ty(Context)) {
    assert((Len&3) == 0 &&
           "Length in bytes should be a multiple of element size");
-    const uint32_t *InStr = (const unsigned *)TREE_STRING_POINTER(exp);
+    const uint32_t *InStr = (const uint32_t *)TREE_STRING_POINTER(exp);
    for (unsigned i = 0; i != Len/4; ++i) {
      // gcc has constructed the initializer elements in the target
endianness,
      // but we're going to treat them as ordinary ints from here, with


_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/66ba5144/attachment.html 

From dag at cray.com  Thu Sep  3 11:48:03 2009
From: dag at cray.com (David Greene)
Date: Thu, 3 Sep 2009 11:48:03 -0500
Subject: [LLVMdev] ScheduleDAG Question
Message-ID: <200909031148.04144.dag@cray.com>

I'm debugging a ScheduleDAG problem.  Somehow a load appearing
before a call in the source gets scheduled after the call.
Since the callee modifies the location loaded from, wrong answers result.

Looking at the dag with -view-sched-dags, I don't see an edge from the
load to depend on the call.

How is this supposed to be handled by ScheduleDAG?

                                   -Dave

From dag at cray.com  Thu Sep  3 11:59:51 2009
From: dag at cray.com (David Greene)
Date: Thu, 3 Sep 2009 11:59:51 -0500
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <200909031148.04144.dag@cray.com>
References: <200909031148.04144.dag@cray.com>
Message-ID: <200909031159.51387.dag@cray.com>

On Thursday 03 September 2009 11:48, David Greene wrote:
> I'm debugging a ScheduleDAG problem.  Somehow a load appearing
> before a call in the source gets scheduled after the call.
> Since the callee modifies the location loaded from, wrong answers result.
>
> Looking at the dag with -view-sched-dags, I don't see an edge from the
> load to depend on the call.

-view-sunit-dags seems to indicate such an edge does exist.  Any
pointers on how to efficiently debug this?

                                   -Dave

From kuba at gcc.gnu.org  Thu Sep  3 12:51:21 2009
From: kuba at gcc.gnu.org (Jakub Staszak)
Date: Thu, 3 Sep 2009 15:51:21 -0200
Subject: [LLVMdev] Non-local DSE optimization
In-Reply-To: <4A9F86F4.3070609@free.fr>
References: <830819AC-2A14-435D-86FE-CB09F73F31F6@gcc.gnu.org>
	<4A9F86F4.3070609@free.fr>
Message-ID: <273A970E-E76D-4BC0-8EF0-64E9C391DA6F@gcc.gnu.org>

Hi,

It looks like PDT.getRootNode() returns NULL for:

define fastcc void @c974001__lengthy_calculation. 
1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn {
entry:
   br label %bb

bb:
   br label %bb
}


Isn't it a bug in PostDominatorTree?

Please note that this crashes:
opt -postdomtree -debug dom_crash.bc

I think this should be reported as a bug,

-Jakub



On Sep 3, 2009, at 7:05 AM, Duncan Sands wrote:

> Hi Jakub, interesting patch.  I ran it over the Ada testsuite and this
> picked up some problems even without enabling dse-ssu.  For example,
> "opt -inline -dse -domtree" crashes on the attached testcase.
>
> Ciao,
>
> Duncan.
> ; ModuleID = 'dom_crash.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"
>
> %struct.FRAME.c974001 = type { i32, i8, void  
> (%struct.c974001__timed_calculation*)* }
> %struct.FRAME.c974001__timed_calculationB = type  
> { %struct.FRAME.c974001*, i32 }
> %struct.FRAME.c974001__timed_calculation__calculationA = type  
> { %struct.system__tasking__async_delays__delay_block }
> %struct.RETURN = type { i32, i32 }
> %struct.ada__exceptions__exception_occurrence = type  
> { %struct.system__standard_library__exception_data*, i32, [200 x  
> i8], i8, i8, i32, i32, [50 x i32], i32 }
> %struct.c974001__timed_calculation = type  
> { %struct.system__tasking__ada_task_control_block* }
> %struct.system__os_interface__pthread_mutex_t = type { i32, i32,  
> i32, i32, %struct.RETURN }
> %struct.system__soft_links__tsd = type  
> { %struct.system__stack_checking__stack_info, i32, i32,  
> %struct.ada__exceptions__exception_occurrence }
> %struct.system__stack_checking__stack_info = type { i32, i32, i32 }
> %struct.system__stack_usage__stack_analyzer = type { [32 x i8], i32,  
> i32, i32, i32, i32, i32, i32, i8, i32 }
> %struct.system__standard_library__exception_data = type { i8, i8,  
> i32, i32, %struct.system__standard_library__exception_data*, i32,  
> void ()* }
> %struct.system__task_primitives__private_data = type { i32, i32, [48  
> x i8], %struct.system__os_interface__pthread_mutex_t }
> %struct.system__tasking__accept_alternative = type { i8, i32 }
> %struct.system__tasking__accept_list_access = type { [0 x  
> %struct.system__tasking__accept_alternative]*, %struct.RETURN* }
> %struct.system__tasking__ada_task_control_block = type { i32,  
> %struct.system__tasking__common_atcb, [19 x  
> %struct.system__tasking__entry_call_record], i32,  
> %struct.system__tasking__accept_list_access, i32, i32, i32, i32,  
> i32, i8, i8, i8, i8, i8, i8, i8, i8, i32, i32, i32, i64, i32, i32,  
> [4 x i32], i8, i32*, [0 x %struct.system__tasking__entry_queue] }
> %struct.system__tasking__async_delays__delay_block = type  
> { %struct.system__tasking__ada_task_control_block*, i32, i64, i8,  
> %struct.system__tasking__async_delays__delay_block*,  
> %struct.system__tasking__async_delays__delay_block* }
> %struct.system__tasking__common_atcb = type { i8,  
> %struct.system__tasking__ada_task_control_block*, i32, i32, i32, [32  
> x i8], i32, %struct.system__tasking__entry_call_record*,  
> %struct.system__task_primitives__private_data, i32, void (i32)*,  
> %struct.system__soft_links__tsd,  
> %struct.system__tasking__ada_task_control_block*,  
> %struct.system__tasking__ada_task_control_block*,  
> %struct.system__tasking__ada_task_control_block*, i32, i8*, i8, i8,  
> %struct.system__stack_usage__stack_analyzer, i32,  
> %struct.system__tasking__termination_handler,  
> %struct.system__tasking__termination_handler }
> %struct.system__tasking__entry_call_record = type  
> { %struct.system__tasking__ada_task_control_block*, i8, i8, i32,  
> %struct.system__standard_library__exception_data*,  
> %struct.system__tasking__entry_call_record*,  
> %struct.system__tasking__entry_call_record*, i32, i32, i32,  
> %struct.system__tasking__ada_task_control_block*, i32,  
> %struct.system__tasking__entry_call_record*, i32, i8, i8, i8 }
> %struct.system__tasking__entry_queue = type  
> { %struct.system__tasking__entry_call_record*,  
> %struct.system__tasking__entry_call_record* }
> %struct.system__tasking__termination_handler = type { i32, void  
> (i32, i8, %struct.system__tasking__ada_task_control_block*,  
> %struct.ada__exceptions__exception_occurrence*)* }
>
> @C.168.1967 = external constant %struct.RETURN    ; < 
> %struct.RETURN*> [#uses=1]
>
> define void  
> @system__tasking__activation_chainIP 
> (%struct.c974001__timed_calculation* nocapture %_init) nounwind {
> entry:
>  ret void
> }
>
> define void @_ada_c974001() {
> entry:
>  %tramp = call i8* @llvm.init.trampoline(i8* undef, i8* bitcast  
> (void (%struct.FRAME.c974001*, %struct.c974001__timed_calculation*)*  
> @c974001__timed_calculationB.1770 to i8*), i8* undef) ; <i8*>  
> [#uses=0]
>  unreachable
> }
>
> declare i8* @llvm.init.trampoline(i8*, i8*, i8*) nounwind
>
> define fastcc void @c974001__lengthy_calculation. 
> 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn {
> entry:
>  br label %bb
>
> bb:                                               ; preds = %bb,  
> %entry
>  br label %bb
> }
>
> define fastcc void  
> @c974001__timed_calculation__calculation__B19b__B21b__A17b___clean. 
> 1830(%struct.FRAME.c974001__timed_calculation__calculationA* %CHAIN. 
> 188) {
> entry:
>  ret void
> }
>
> define fastcc void @c974001__timed_calculation__calculationA. 
> 1820(%struct.FRAME.c974001__timed_calculationB* nocapture %CHAIN. 
> 190) {
> entry:
>  br i1 undef, label %bb, label %bb3
>
> bb:                                               ; preds = %entry
>  unreachable
>
> bb3:                                              ; preds = %entry
>  br i1 undef, label %bb4, label %bb5
>
> bb4:                                              ; preds = %bb3
>  unreachable
>
> bb5:                                              ; preds = %bb3
>  invoke void undef()
>          to label %invcont unwind label %lpad
>
> invcont:                                          ; preds = %bb5
>  %0 = invoke i8 @system__tasking__async_delays__enqueue_duration(i64  
> undef, %struct.system__tasking__async_delays__delay_block* undef)
>          to label %bb8 unwind label %lpad        ; <i8> [#uses=0]
>
> bb8:                                              ; preds = %invcont
>  invoke void undef()
>          to label %invcont9 unwind label %lpad75
>
> invcont9:                                         ; preds = %bb8
>  invoke fastcc void @c974001__lengthy_calculation. 
> 1736(%struct.FRAME.c974001* undef)
>          to label %invcont10 unwind label %lpad75
>
> invcont10:                                        ; preds = %invcont9
>  invoke void @report__failed([0 x i8]* undef, %struct.RETURN* @C. 
> 168.1967)
>          to label %bb16 unwind label %lpad75
>
> bb16:                                             ; preds = %invcont10
>  invoke fastcc void  
> @c974001__timed_calculation__calculation__B19b__B21b__A17b___clean. 
> 1830(%struct.FRAME.c974001__timed_calculation__calculationA* undef)
>          to label %bb27 unwind label %lpad71
>
> bb27:                                             ; preds = %bb16
>  unreachable
>
> lpad:                                             ; preds =  
> %invcont, %bb5
>  unreachable
>
> lpad71:                                           ; preds = %bb16
>  unreachable
>
> lpad75:                                           ; preds =  
> %invcont10, %invcont9, %bb8
>  unreachable
> }
>
> declare i8 @system__tasking__async_delays__enqueue_duration(i64,  
> %struct.system__tasking__async_delays__delay_block*)
>
> declare void @report__failed([0 x i8]*, %struct.RETURN*)
>
> define void @c974001__timed_calculationB.1770(%struct.FRAME.c974001*  
> nest %CHAIN.191, %struct.c974001__timed_calculation* nocapture  
> %_task) {
> entry:
>  invoke void undef()
>          to label %invcont unwind label %lpad
>
> invcont:                                          ; preds = %entry
>  invoke void @system__tasking__stages__complete_activation()
>          to label %bb unwind label %lpad
>
> bb:                                               ; preds = %bb5,  
> %invcont4, %invcont
>  invoke void  
> @system__tasking__rendezvous__selective_wait(%struct.RETURN* noalias  
> sret undef, [0 x %struct.system__tasking__accept_alternative]*  
> undef, %struct.RETURN* undef, i8 2)
>          to label %invcont4 unwind label %lpad25
>
> invcont4:                                         ; preds = %bb
>  br i1 undef, label %bb5, label %bb
>
> bb5:                                              ; preds = %invcont4
>  invoke fastcc void @c974001__timed_calculation__calculationA. 
> 1820(%struct.FRAME.c974001__timed_calculationB* undef)
>          to label %bb unwind label %lpad25
>
> bb7:                                              ; preds = %lpad25
>  unreachable
>
> lpad:                                             ; preds =  
> %invcont, %entry
>  unreachable
>
> lpad25:                                           ; preds = %bb5, %bb
>  br i1 undef, label %bb7, label %ppad
>
> ppad:                                             ; preds = %lpad25
>  unreachable
> }
>
> declare void @system__tasking__stages__complete_activation()
>
> declare void  
> @system__tasking__rendezvous__selective_wait(%struct.RETURN* noalias  
> sret, [0 x %struct.system__tasking__accept_alternative]*,  
> %struct.RETURN*, i8)


From daniel at zuster.org  Thu Sep  3 14:26:10 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Thu, 3 Sep 2009 12:26:10 -0700
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <549cee610909030624y73d398c5oc12837ea0e50a84b@mail.gmail.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
	<16e5fdf90909021319p20b83068p29a396f45fbd45b7@mail.gmail.com>
	<549cee610909030624y73d398c5oc12837ea0e50a84b@mail.gmail.com>
Message-ID: <6a8523d60909031226x7f7f79c2rfc7dc7a8b14ddaa1@mail.gmail.com>

On Thu, Sep 3, 2009 at 6:24 AM, Olivier
Meurant<meurant.olivier at gmail.com> wrote:
> Hi Tanya,
>
> I have tried the 2.6 pre-release on the following host :
>
> Windows XP pro SP2 with mingw/msys :
>
> uname -a
> MINGW32_NT-5.1 OLIVE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown
>
> gcc -v
> Reading specs from d:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs
> Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld
> --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
> --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java
> --disable-win32-registry --disable-shared --enable-sjlj-exceptions
> --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
> --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization
> --enable-libstdcxx-debug
> Thread model: win32
> gcc version 3.4.5 (mingw special)
>
>
> - srcDir != objDir
> - The build went fine. (configure and make)
> - llvm make check : not possible under mingw (dejagnu...)
> - clang make check fails :

Note that we don't really expect clang to work on MinGW yet, as far as I know.

> In the method DefineTypeSize, the call to sprintf is as follow :
> sprintf(MacroBuf, "%s=%llu%s", MacroName, MaxVal, ValSuffix);
> and should be transformed to :
> sprintf(MacroBuf, "%s=%I64u%s", MacroName, MaxVal, ValSuffix);
> as mingw toolchain don't support "%llu" marker.

Fixed in SVN r80933.

I don't know the status of clang on MinGW, so its hard for me to say
whether its worth trying to take this for 2.6.

 - Daniel

From mikael at lyngvig.org  Thu Sep  3 14:26:40 2009
From: mikael at lyngvig.org (Mikael Lyngvig)
Date: Thu, 3 Sep 2009 21:26:40 +0200 (CEST)
Subject: [LLVMdev] An alternate implementation of exceptions
Message-ID: <80d317280aad14174bfe694d545b4659.squirrel@squirrel-webmail.surftown.com>

Hi,

The guys on the Tiny C mailing list referred me to this list because I
suggested adding a simple exception handling mechanism to Tiny C.

I have written a small article on a proposal to add try/catch and throw
statements to C, knowing very well that this is a non-standard extention,
but there are so many of those in the C world that another one shouldn't
be a big issue.  The Tiny C guys weren't interested in adding this
extension to Tiny C, but said that you guys might be interested in the
innovative way that I suggest implementing exceptions.

The reason I am posting a link to my article to this mailing list is that
the guys on the Tiny C mailing list said that you guys MIGHT be interested
in the new way I propose to implement exceptions.  My method is very, very
fast, very, very small, and also has the added advantage that it does NOT
require run-time library support to implement.

Please ignore the fact that the paper is titled "A Proposal for Exception
Handling in C" and look only on it as proposing a new way of implementing
exception handling in pretty much all contemporary imperative languages.

The link is:

   http://www.lyngvig.org/doc/A%20Proposal%20for%20Exception%20Handling%20in%20C%20(ENU).pdf

Please let me know your comments, critique, and suggestions!


Sincerely,

Mikael Lyngvig


From simmon12 at illinois.edu  Thu Sep  3 14:36:57 2009
From: simmon12 at illinois.edu (Patrick Simmons)
Date: Thu, 03 Sep 2009 13:36:57 -0600
Subject: [LLVMdev] version 2.3 of poolalloc
In-Reply-To: <4A95A7B6.1050706@cs.uiuc.edu>
References: <31397.53220.qm@web59906.mail.ac4.yahoo.com>	<4365A6F8-4DB6-4306-9F3F-0E6F7AC54D3A@apple.com>	<4A936CEB.8030404@uiuc.edu>
	<4A95A562.60400@cs.uiuc.edu> <4A95A7B6.1050706@cs.uiuc.edu>
Message-ID: <4AA01AD9.2070102@illinois.edu>

John Criswell wrote:
> John Criswell wrote:
>   
>> Dear All,
>>
>> I have finished updating the DSA and Poolalloc source code so that it
>> compiles with the LLVM 2.6 API.  If you check out the LLVM 2.6 branch
>> (directions are in the llvmdev archives; look for the email by Tanya
>> Lattner about the LLVM 2.6 branch), you should be able to build mainline
>> DSA and Pool Allocation against it.
>>
>> If you have trouble building DSA/Pool Allocation, please email llvmdev.
>>   
>>     
>
> To aid in checking out LLVM 2.6, I went and looked up the command.  It is:
>
> svn co https://llvm.org/svn/llvm-project/llvm/branches/release_26 llvm
>
> -- John T.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   
Does this mean poolalloc isn't meant to build with the LLVM trunk 
anymore?  I recently updated both poolalloc and my LLVM checkout to the 
latest revision, and poolalloc isn't building (something about "Ostream" 
being undefined).  Should I switch my checkout to the "release_26" branch?

--Patrick

-- 
If I'm not here, I've gone out to find myself.  If I get back before I return, please keep me here.


From criswell at cs.uiuc.edu  Thu Sep  3 14:51:04 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 3 Sep 2009 14:51:04 -0500
Subject: [LLVMdev] version 2.3 of poolalloc
In-Reply-To: <4AA01AD9.2070102@illinois.edu>
References: <31397.53220.qm@web59906.mail.ac4.yahoo.com>	<4365A6F8-4DB6-4306-9F3F-0E6F7AC54D3A@apple.com>	<4A936CEB.8030404@uiuc.edu>	<4A95A562.60400@cs.uiuc.edu>
	<4A95A7B6.1050706@cs.uiuc.edu> <4AA01AD9.2070102@illinois.edu>
Message-ID: <4AA01E28.5050907@cs.uiuc.edu>

Patrick Simmons wrote:
> [snip]
>>
>>   
>>     
> Does this mean poolalloc isn't meant to build with the LLVM trunk 
> anymore?  I recently updated both poolalloc and my LLVM checkout to the 
> latest revision, and poolalloc isn't building (something about "Ostream" 
> being undefined).  Should I switch my checkout to the "release_26" branch?
>
> --Patrick
>
>   

That is correct.  Mainline poolalloc will compile with the LLVM 2.6
branch instead of LLVM mainline for the foreseeable future.  This is
because 1) we want to make a "release" of poolalloc that works with LLVM
2.6 so that there is a poolalloc/SAFECode version that works with an
LLVM release; and 2) I believe the LLVM API is changing again in
mainline, and LLVM 2.6 seems like a good point at which to synchronize
and stop.

I think we'll create a release_26 branch for poolalloc in the future,
but I'm not sure when.  That is something we can discuss in the next few
weeks.

-- John T.




From astifter at gmx.at  Thu Sep  3 14:58:23 2009
From: astifter at gmx.at (Andreas Neustifter)
Date: Thu, 03 Sep 2009 21:58:23 +0200
Subject: [LLVMdev] [PATCH] MaximumSpanningTree goes generic.
Message-ID: <4AA01FDF.5000506@gmx.at>

Hi,

I succeeded in converting the MaximumSpanningTree module to a generic
one that is able to hold any kind of data.

There was talk about puting this into llvm/ADT, is this implementation
ready for that?

Any complaints if I put this in?

Thanks, Andi

-- 
==========================================================================
This email is signed, for more information see
http://web.student.tuwien.ac.at/~e0325716/gpg.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-convert.mst.to.generic.patch
Type: text/x-patch
Size: 12014 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/6d35a9eb/attachment.bin 

From astifter-llvm at gmx.at  Thu Sep  3 15:00:58 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Thu, 03 Sep 2009 22:00:58 +0200
Subject: [LLVMdev] [PATCH] MaximumSpanningTree goes generic.
Message-ID: <4AA0207A.1000900@gmx.at>

Hi,

I succeeded in converting the MaximumSpanningTree module to a generic
one that is able to hold any kind of data.

There was talk about puting this into llvm/ADT, is this implementation
ready for that?

Any complaints if I put this in?

Thanks, Andi

-- 
==========================================================================
This email is signed, for more information see
http://web.student.tuwien.ac.at/~e0325716/gpg.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-convert.mst.to.generic.patch
Type: text/x-patch
Size: 12015 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/ce283736/attachment.bin 

From eli.friedman at gmail.com  Thu Sep  3 15:58:55 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 3 Sep 2009 13:58:55 -0700
Subject: [LLVMdev] llvm-gcc ignores function attributes of template
	functions?
In-Reply-To: <200909031449.51261.torvald@se.inf.tu-dresden.de>
References: <200909031449.51261.torvald@se.inf.tu-dresden.de>
Message-ID: <f5aa3e9b0909031358g63dc2b2dv4b774db95856c5c0@mail.gmail.com>

On Thu, Sep 3, 2009 at 5:49 AM, Torvald
Riegel<torvald at se.inf.tu-dresden.de> wrote:
> Hi,
>
> llvm-gcc of LLVM 2.5 seems to ignore function attributes of template
> functions. For example, it doesn't set the noinline attribute, and it doesn't
> warn on unknown attribute names. Is this known / intended behavior?

Testcase?  Seems to work fine with trunk; you might want to try with
that or the 2.6 prerelease.

-Eli

From eli.friedman at gmail.com  Thu Sep  3 16:04:54 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 3 Sep 2009 14:04:54 -0700
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <200909031148.04144.dag@cray.com>
References: <200909031148.04144.dag@cray.com>
Message-ID: <f5aa3e9b0909031404o5069f322wa8c27acbf465eddd@mail.gmail.com>

On Thu, Sep 3, 2009 at 9:48 AM, David Greene<dag at cray.com> wrote:
> I'm debugging a ScheduleDAG problem. ?Somehow a load appearing
> before a call in the source gets scheduled after the call.
> Since the callee modifies the location loaded from, wrong answers result.
>
> Looking at the dag with -view-sched-dags, I don't see an edge from the
> load to depend on the call.
>
> How is this supposed to be handled by ScheduleDAG?

My first step would be to make sure there's an appropriate edge in the
selection DAG... there's a possibility something could get messed up
by legalization or the dagcombiner.

Since scheduling and selection is mostly within a block, hopefully it
wouldn't be too hard to come up with a testcase?

-Eli


From eocallaghan at auroraux.org  Thu Sep  3 17:10:37 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Thu, 3 Sep 2009 23:10:37 +0100
Subject: [LLVMdev] Solaris SPARC llvm-gcc front-end
In-Reply-To: <ee796e3a0909030600j7dcbc7c0xc88dfa7797d81f24@mail.gmail.com>
References: <ee796e3a0909030600j7dcbc7c0xc88dfa7797d81f24@mail.gmail.com>
Message-ID: <521640720909031510i5db4c4b5s5564ee2e5bd73282@mail.gmail.com>

Good day,

Which lang support do you want from the fronend, as, we, the AuroraUX
team, maintain the solaris port of clang^[1] (which supports C family)
now and are attempting at looking at porting GNAT directly to llvm for
Ada support also.

Cheers,
Edward O'Callaghan.

[1] - http://clang.llvm.org/

2009/9/3 Fedor Sakharov <fedor.sakharov at gmail.com>:
> Hello.
>
> How are the things going with the llvm-gcc for SPARC and Solaris OS? I have
> discovered recently the fact, that the code is still in the "patches
> welcome" stage and is far even from being successfully built on SPARC. I
> would like to know, if anyone maintaining this code, what is the current
> to-do list, etc. I would like to offer my help for gcc front-end on SPARC
> project.
>
> --
> Best regards,
> Fedor Sakharov
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From isanbard at gmail.com  Thu Sep  3 18:00:46 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Thu, 3 Sep 2009 16:00:46 -0700
Subject: [LLVMdev] Things are Broken ... Again *shock*
Message-ID: <16e5fdf90909031600o4752c15bn8a8eec4bf9fc2200@mail.gmail.com>

Not that anyone actually cares, but things are broken again. Probably
want to fix it.

Then again, probably not.

Cheers!
-bw

From dag at cray.com  Thu Sep  3 18:22:46 2009
From: dag at cray.com (David Greene)
Date: Thu, 3 Sep 2009 18:22:46 -0500
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <f5aa3e9b0909031404o5069f322wa8c27acbf465eddd@mail.gmail.com>
References: <200909031148.04144.dag@cray.com>
	<f5aa3e9b0909031404o5069f322wa8c27acbf465eddd@mail.gmail.com>
Message-ID: <200909031822.46759.dag@cray.com>

On Thursday 03 September 2009 16:04, Eli Friedman wrote:

> My first step would be to make sure there's an appropriate edge in the
> selection DAG... there's a possibility something could get messed up
> by legalization or the dagcombiner.

I turned off dagcombine and it didn't help.

> Since scheduling and selection is mostly within a block, hopefully it
> wouldn't be too hard to come up with a testcase?

Yep, I've got a much reduced testcase now (and converted from Fortran
to C which makes things much easier to work with).  I'm going to test
against TOT and see if I see the same problem.

                                   -Dave

From scallanan at apple.com  Thu Sep  3 19:25:48 2009
From: scallanan at apple.com (Sean Callanan)
Date: Thu, 3 Sep 2009 17:25:48 -0700
Subject: [LLVMdev] X86 Disassembler
In-Reply-To: <F49ADA4A-FF00-4823-A50F-01975E3C87F0@apple.com>
References: <5CAC0029-31A2-4490-9232-E6098907AEC9@apple.com>
	<DDEDF415-4B49-4DC5-A743-8A81B8DA9DE8@gmail.com>
	<F909DDB3-DD12-4901-9662-DCF7B0FA8801@apple.com>
	<F49ADA4A-FF00-4823-A50F-01975E3C87F0@apple.com>
Message-ID: <23D8260F-BA48-4A4A-9CA6-7F831A602EBC@apple.com>

I was away doing other things for a while, but I have an API patch  
separated out, which (in addition to being much smaller than past  
megapatches) corrects two issues Chris identified in his most recent  
set of patches:

- First, it makes the API a good deal simpler.  Now, you can  
instantiate a single MCDisassembler and, each time you want an  
instruction disassembled, you can simply pass it a MemoryRegion, an  
offset, and an MCInst to populate.

- Second, it adds MCDisassembler to the list of things you can get  
from a TargetMachine, so you don't have to #include something from lib/ 
Target/X86 just to use the X86 disassembler.

Please let me know what you think of this API.  Thanks for your time.

Sean



I have included Chris's previous comments below.

On Aug 22, 2009, at 4:31 PM, Chris Lattner wrote:
> The MCDisassembler API is also somewhat strange to me.  Right now it  
> is designed to analyze a memory region when constructed and contain  
> them.  It seems that there is a more useful low level API which  
> would look something like this:
>
> class MCDisassembler {
> public:
>
>  virtual ~MCDisassembler();
>
>  /// DisassembleInstruction - Disassemble the first instruction in  
> the specified region, printing the disassembled instruction to the  
> specified raw_ostream, and returning the size of the instruction in  
> bytes.  On error, this returns zero and fills in ErrorInfo with a  
> human readable description of the error.
>  virtual unsigned DisassembleInstruction(MemoryObject &region,  
> raw_ostream &OS, std::string &ErrorInfo) = 0;
>
> }
>
> Having this sort of stateless API means that higher level clients  
> (which are stateful) can be built on top of them without adding  
> overhead to clients who don't care about the state.

> Instead of doing something like this, the X86 disassembler should  
> register itself as part of the "Target" API the same way that  
> asmprinters, MCAsmInfo, targets, etc do.  The X86 specific  
> disassembler should go in lib/Target/X86/Disassembler.  Take a look  
> at how the Target/X86/AsmParser stuff registers itself for a good  
> example.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/16292849/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-disassembler-api.diff
Type: application/octet-stream
Size: 10632 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/16292849/attachment.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/16292849/attachment-0001.html 

From dag at cray.com  Thu Sep  3 19:55:18 2009
From: dag at cray.com (David Greene)
Date: Thu, 3 Sep 2009 19:55:18 -0500
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <200909031822.46759.dag@cray.com>
References: <200909031148.04144.dag@cray.com>
	<f5aa3e9b0909031404o5069f322wa8c27acbf465eddd@mail.gmail.com>
	<200909031822.46759.dag@cray.com>
Message-ID: <200909031955.18968.dag@cray.com>

On Thursday 03 September 2009 18:22, David Greene wrote:

> > Since scheduling and selection is mostly within a block, hopefully it
> > wouldn't be too hard to come up with a testcase?
>
> Yep, I've got a much reduced testcase now (and converted from Fortran
> to C which makes things much easier to work with).  I'm going to test
> against TOT and see if I see the same problem.

TOT is bug-free.  I'm about to try 2.5.

My little testcase definitely has missing edges in the sched dag and sunit 
dag.  Where do edges from loads of globals to calls get added?  That's what's
missing here.

                            -Dave


From shreyas76 at gmail.com  Thu Sep  3 20:21:47 2009
From: shreyas76 at gmail.com (shreyas krishnan)
Date: Thu, 3 Sep 2009 18:21:47 -0700
Subject: [LLVMdev] viewing dags
Message-ID: <24389fb30909031821u753aa507me853c7c9d44a6ca@mail.gmail.com>

Hi
  I would like to view the various dags being output during codegen.
Unfortunately, I am not seeing the files being dumped. I will really
appreciate if someone can help me here

llc switch.bc -f  -view-dag-combine1-dags  ( i tried -view-isel-dags,
-view-sched-dags as well)
Writing '/tmp/llvm_zbbAKM/dag.main.dot'...  done.
Writing '/tmp/llvm_G4rLKf/dag.main.dot'...  done.
Writing '/tmp/llvm_mv0TMI/dag.main.dot'...  done.
Writing '/tmp/llvm_adT8Ob/dag.main.dot'...  done.
Writing '/tmp/llvm_RcYsRE/dag.main.dot'...  done.
Writing '/tmp/llvm_wvfTT7/dag.main.dot'...  done.
Writing '/tmp/llvm_IskqWA/dag.main.dot'...  done.
Writing '/tmp/llvm_ZvQ1Y3/dag.main.dot'...  done.
Writing '/tmp/llvm_IDaJ1w/dag.main.dot'...  done.
Writing '/tmp/llvm_iU7v4Z/dag.main.dot'...  done.
Writing '/tmp/llvm_td7n7s/dag.main.dot'...  done.
Writing '/tmp/llvm_OinkaW/dag.main.dot'...  done.
Writing '/tmp/llvm_BiZmdp/dag.main.dot'...  done.



I find none of the files - dag.main.dot created but the llvm*
directories do get created. I do have permissions to the directory.

I do have dotty in my path but that I would imagine should only cause
issues with viewing the graph.

thanks for your help!
shrey

From eli.friedman at gmail.com  Thu Sep  3 20:41:28 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 3 Sep 2009 18:41:28 -0700
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <200909031955.18968.dag@cray.com>
References: <200909031148.04144.dag@cray.com>
	<f5aa3e9b0909031404o5069f322wa8c27acbf465eddd@mail.gmail.com>
	<200909031822.46759.dag@cray.com> <200909031955.18968.dag@cray.com>
Message-ID: <f5aa3e9b0909031841h252b0964j59d7bb7d7c753b1@mail.gmail.com>

On Thu, Sep 3, 2009 at 5:55 PM, David Greene<dag at cray.com> wrote:
> On Thursday 03 September 2009 18:22, David Greene wrote:
>
>> > Since scheduling and selection is mostly within a block, hopefully it
>> > wouldn't be too hard to come up with a testcase?
>>
>> Yep, I've got a much reduced testcase now (and converted from Fortran
>> to C which makes things much easier to work with). ?I'm going to test
>> against TOT and see if I see the same problem.
>
> TOT is bug-free. ?I'm about to try 2.5.
>
> My little testcase definitely has missing edges in the sched dag and sunit
> dag. ?Where do edges from loads of globals to calls get added? ?That's what's
> missing here.

They should be there from the very beginning, when the selection dag is built.

-Eli


From dag at cray.com  Thu Sep  3 20:51:05 2009
From: dag at cray.com (David Greene)
Date: Thu, 3 Sep 2009 20:51:05 -0500
Subject: [LLVMdev] viewing dags
In-Reply-To: <24389fb30909031821u753aa507me853c7c9d44a6ca@mail.gmail.com>
References: <24389fb30909031821u753aa507me853c7c9d44a6ca@mail.gmail.com>
Message-ID: <200909032051.06086.dag@cray.com>

On Thursday 03 September 2009 20:21, shreyas krishnan wrote:

> I find none of the files - dag.main.dot created but the llvm*
> directories do get created. I do have permissions to the directory.
>
> I do have dotty in my path but that I would imagine should only cause
> issues with viewing the graph.

Do you have 'dot' in your path?  What does configure say when it runs?
I see this when configure doesn't find the graphviz tools.  Note that
they need to be in your path when you configure, not just when you build.

                            -Dave

From dag at cray.com  Thu Sep  3 21:13:24 2009
From: dag at cray.com (David Greene)
Date: Thu, 3 Sep 2009 21:13:24 -0500
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <f5aa3e9b0909031841h252b0964j59d7bb7d7c753b1@mail.gmail.com>
References: <200909031148.04144.dag@cray.com> <200909031955.18968.dag@cray.com>
	<f5aa3e9b0909031841h252b0964j59d7bb7d7c753b1@mail.gmail.com>
Message-ID: <200909032113.24759.dag@cray.com>

On Thursday 03 September 2009 20:41, Eli Friedman wrote:

> > My little testcase definitely has missing edges in the sched dag and
> > sunit dag. ?Where do edges from loads of globals to calls get added?
> > ?That's what's missing here.
>
> They should be there from the very beginning, when the selection dag is
> built.

Nope, not there.  I've attached the dot output.  The call of killcombine
looks completely divorced from the load feeding the two extract_vector_elt 
nodes.  Am I reading the graph correctly?

Hmm...except there's a little dashed blue line from the call to the chain (I 
think) field of the load.  Is that the dependence I want?  I don't know how
to read these graphs.

Is the code that's supposed to do this in ScheduleDAGBuild.cpp?

Thanks for your help.

                                   -Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reset.builddag.ps
Type: application/postscript
Size: 40025 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090903/d233c1c3/attachment.ps 

From dag at cray.com  Thu Sep  3 21:24:56 2009
From: dag at cray.com (David Greene)
Date: Thu, 3 Sep 2009 21:24:56 -0500
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <200909032113.24759.dag@cray.com>
References: <200909031148.04144.dag@cray.com>
	<f5aa3e9b0909031841h252b0964j59d7bb7d7c753b1@mail.gmail.com>
	<200909032113.24759.dag@cray.com>
Message-ID: <200909032124.56872.dag@cray.com>

On Thursday 03 September 2009 21:13, David Greene wrote:

> Hmm...except there's a little dashed blue line from the call to the chain
> (I think) field of the load.  Is that the dependence I want?  I don't know
> how to read these graphs.

Interesting.  So with -view-legalize-dags, that little dashed blue line has
moved from the load to the store that feeds the load.  That's wrong.

But it's still there with -view-legalize-types-dags, so legalize types must
be buggy.  But -disable-legalize-types doesn't fix the problem.  So the 
general legalize code seems to have the same issue.

LLVM 2.5 compiles this fine, so it's something we've altered in the codebase.
I did a diff of all of our changes to lib/CodeGen and include/llvm/CodeGen
but nothing jumpoed out as obviously wrong.  I suppose it's possible we
present slightly different code to the legalize passes than the unmodified
LLVM.

Fun times, indeed.

                                -Dave

From eli.friedman at gmail.com  Thu Sep  3 21:39:37 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 3 Sep 2009 19:39:37 -0700
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <200909032124.56872.dag@cray.com>
References: <200909031148.04144.dag@cray.com>
	<f5aa3e9b0909031841h252b0964j59d7bb7d7c753b1@mail.gmail.com>
	<200909032113.24759.dag@cray.com> <200909032124.56872.dag@cray.com>
Message-ID: <f5aa3e9b0909031939p37139d0cy972e3eda21f12659@mail.gmail.com>

On Thu, Sep 3, 2009 at 7:24 PM, David Greene<dag at cray.com> wrote:
> On Thursday 03 September 2009 21:13, David Greene wrote:
>
>> Hmm...except there's a little dashed blue line from the call to the chain
>> (I think) field of the load. ?Is that the dependence I want? ?I don't know
>> how to read these graphs.
>
> Interesting. ?So with -view-legalize-dags, that little dashed blue line has
> moved from the load to the store that feeds the load. ?That's wrong.
>
> But it's still there with -view-legalize-types-dags, so legalize types must
> be buggy. ?But -disable-legalize-types doesn't fix the problem. ?So the
> general legalize code seems to have the same issue.
>
> LLVM 2.5 compiles this fine, so it's something we've altered in the codebase.
> I did a diff of all of our changes to lib/CodeGen and include/llvm/CodeGen
> but nothing jumpoed out as obviously wrong. ?I suppose it's possible we
> present slightly different code to the legalize passes than the unmodified
> LLVM.
>
> Fun times, indeed.

You might want to try the -debug dumps; it might be a bit easier to follow.

-Eli


From greened at obbligato.org  Thu Sep  3 23:51:12 2009
From: greened at obbligato.org (David Greene)
Date: Thu, 03 Sep 2009 23:51:12 -0500
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <f5aa3e9b0909031939p37139d0cy972e3eda21f12659@mail.gmail.com>
References: <200909031148.04144.dag@cray.com>	<f5aa3e9b0909031841h252b0964j59d7bb7d7c753b1@mail.gmail.com>	<200909032113.24759.dag@cray.com>
	<200909032124.56872.dag@cray.com>
	<f5aa3e9b0909031939p37139d0cy972e3eda21f12659@mail.gmail.com>
Message-ID: <4AA09CC0.8050406@obbligato.org>

Eli Friedman wrote:

> You might want to try the -debug dumps; it might be a bit easier to follow.

I find the -debug DAG dumps completely incomprehensible.  Addresses are
not fun to look at.  :)  But I have been looking at them as well.  More
analysis tomorrow.

                             -Dave


From wansheg at gmail.com  Fri Sep  4 02:23:22 2009
From: wansheg at gmail.com (=?gbk?B?U2hlbmcgV2FuZw==?=)
Date: Fri, 4 Sep 2009 15:23:22 +0800
Subject: [LLVMdev] Dose I need to build llvm-gcc front-end from source
	resolve this error?
Message-ID: <tencent_2BEE7A7F79AC86377E114951@qq.com>

/*
     mm.cpp
*/
#include<iostream>
using namespace std;
struct  xx{
int x;
        int mm()const;
        int mm();
};

int xx::mm() const
{
        return const_cast<xx*>(this)->mm();
}

int xx::mm()
{
        cout<<"ok"<<endl;
        return x;
}

int main()
{
        xx x;
        x.mm();
        return 0;
}

/*********************************************************************************************************************/

[ws at localhost dev]$ llvm-c++ --emit-llvm mm.cpp 
In file included from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/cstring:52,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/i686-pc-linux-gnu/bits/c++locale.h:47,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/iosfwd:45,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/ios:43,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/ostream:45,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/iostream:45,
                 from mm.cpp:1:
/usr/include/string.h:546: error: ??__locale_t?? has not been declared
/usr/include/string.h:547: error: nonnull argument references non-pointer operand (argument 1, operand 3)
/usr/include/string.h:550: error: ??__locale_t?? has not been declared
/usr/include/string.h:551: error: nonnull argument references non-pointer operand (argument 1, operand 4)

In my system , gcc-3.4.6 is used as default gcc tool;

thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090904/84a353e1/attachment.html 

From baldrick at free.fr  Fri Sep  4 02:39:50 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 04 Sep 2009 09:39:50 +0200
Subject: [LLVMdev] An alternate implementation of exceptions
In-Reply-To: <80d317280aad14174bfe694d545b4659.squirrel@squirrel-webmail.surftown.com>
References: <80d317280aad14174bfe694d545b4659.squirrel@squirrel-webmail.surftown.com>
Message-ID: <4AA0C446.4080800@free.fr>

Hi Mikael, the idea of modifying functions so they return two parameters
(the usual one and an exception pointer or some kind of exception flag)
is well known.  The LLVM vmkit project actually uses a variant of this:
rather than returning the exception pointer in a register, it sticks it
in a global thread local variable.

I only took a quick look at your paper, but it seems to me that it has
a serious problem: you can't link C code using your exception handling
mechanism with C code compiled using another compiler, since the carry
flag may not be cleared on function return by the code compiled by the
other compiler.  Perhaps you addressed this issue in your paper, as I
mentioned I only glanced at it.  Vmkit doesn't suffer from this problem,
since only code that is aware of vmkit exceptions will store in the
global.

Also, I don't see the point of the carry flag.  Why don't you just
return the exception pointer in another register?  If it is non-null
then an exception was raised.  Are you trying to avoid register
pressure or save a cycle or two?

Finally, you could implement this (or something close to it) pretty
easily in LLVM.  Suppose you have a function "int f(params) {...}".
Rather than outputting this to LLVM IR as
   define i32 @f(params) { ... }
you output it as
   define {i32, i8*} @f(params) { ... }
The additional return value is the exception pointer, which callers
can then inspect to see whether an exception was raised.  On x86-64
codegen will return the i32 in RAX and the exception pointer in RDX.

Ciao,

Duncan.

From wansheg at gmail.com  Fri Sep  4 02:51:10 2009
From: wansheg at gmail.com (=?gbk?B?U2hlbmcgV2FuZw==?=)
Date: Fri, 4 Sep 2009 15:51:10 +0800
Subject: [LLVMdev] =?gbk?B?u9i4tKO6W0xMVk1kZXZdIERvc2UgSSBuZWVkIHRv?=
 =?gbk?B?IGJ1aWxkIGxsdm0tZ2NjIGZyb250LWVuZCBmcm9t?=
 =?gbk?B?IHNvdXJjZSB0byByZXNvbHZlIHRoaXMgZXJyb3I/?=
Message-ID: <tencent_4EC6B1F369DEE14A4BA64A29@qq.com>

sorry ! I have re-corrected the title.
 
------------------ ???????? ------------------
??????: "Sheng Wang"<wansheg at gmail.com>;
????????: 2009??9??4??(??????) ????3:23
??????: "LLVMdev"<LLVMdev at cs.uiuc.edu>; 

????: [LLVMdev] Dose I need to build llvm-gcc front-end from sourceresolve this error?

 
 /*
     mm.cpp
*/
#include<iostream>
using namespace std;
struct  xx{
int x;
        int mm()const;
        int mm();
};

int xx::mm() const
{
        return const_cast<xx*>(this)->mm();
}

int xx::mm()
{
        cout<<"ok"<<endl;
        return x;
}

int main()
{
        xx x;
        x.mm();
        return 0;
}

/*********************************************************************************************************************/

[ws at localhost dev]$ llvm-c++ --emit-llvm mm.cpp 
In file included from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/cstring:52,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/i686-pc-linux-gnu/bits/c++locale.h:47,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/iosfwd:45,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/ios:43,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/ostream:45,
                 from /home/ws/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/iostream:45,
                 from mm.cpp:1:
/usr/include/string.h:546: error: ??__locale_t?? has not been declared
/usr/include/string.h:547: error: nonnull argument references non-pointer operand (argument 1, operand 3)
/usr/include/string.h:550: error: ??__locale_t?? has not been declared
/usr/include/string.h:551: error: nonnull argument references non-pointer operand (argument 1, operand 4)

In my system , gcc-3.4.6 is used as default gcc tool;

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

From meurant.olivier at gmail.com  Fri Sep  4 02:58:23 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Fri, 4 Sep 2009 09:58:23 +0200
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <6a8523d60909031226x7f7f79c2rfc7dc7a8b14ddaa1@mail.gmail.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
	<16e5fdf90909021319p20b83068p29a396f45fbd45b7@mail.gmail.com>
	<549cee610909030624y73d398c5oc12837ea0e50a84b@mail.gmail.com>
	<6a8523d60909031226x7f7f79c2rfc7dc7a8b14ddaa1@mail.gmail.com>
Message-ID: <549cee610909040058q2b07e9bfp1b301a98f2aec815@mail.gmail.com>

Thank for the fix !

I am not able to run a "make check" -> dejagnu problem, but as far as I can
tell clang is able to correctly generate IR files from c source. (at least
on my little tests)

Olivier.

On Thu, Sep 3, 2009 at 9:26 PM, Daniel Dunbar <daniel at zuster.org> wrote:

> On Thu, Sep 3, 2009 at 6:24 AM, Olivier
> Meurant<meurant.olivier at gmail.com> wrote:
> > Hi Tanya,
> >
> > I have tried the 2.6 pre-release on the following host :
> >
> > Windows XP pro SP2 with mingw/msys :
> >
> > uname -a
> > MINGW32_NT-5.1 OLIVE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown
> >
> > gcc -v
> > Reading specs from d:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs
> > Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld
> > --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
> > --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java
> > --disable-win32-registry --disable-shared --enable-sjlj-exceptions
> > --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
> > --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization
> > --enable-libstdcxx-debug
> > Thread model: win32
> > gcc version 3.4.5 (mingw special)
> >
> >
> > - srcDir != objDir
> > - The build went fine. (configure and make)
> > - llvm make check : not possible under mingw (dejagnu...)
> > - clang make check fails :
>
> Note that we don't really expect clang to work on MinGW yet, as far as I
> know.
>
> > In the method DefineTypeSize, the call to sprintf is as follow :
> > sprintf(MacroBuf, "%s=%llu%s", MacroName, MaxVal, ValSuffix);
> > and should be transformed to :
> > sprintf(MacroBuf, "%s=%I64u%s", MacroName, MaxVal, ValSuffix);
> > as mingw toolchain don't support "%llu" marker.
>
> Fixed in SVN r80933.
>
> I don't know the status of clang on MinGW, so its hard for me to say
> whether its worth trying to take this for 2.6.
>
>  - Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090904/644ca531/attachment.html 

From baldrick at free.fr  Fri Sep  4 03:00:38 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 04 Sep 2009 10:00:38 +0200
Subject: [LLVMdev] Things are Broken ... Again *shock*
In-Reply-To: <16e5fdf90909031600o4752c15bn8a8eec4bf9fc2200@mail.gmail.com>
References: <16e5fdf90909031600o4752c15bn8a8eec4bf9fc2200@mail.gmail.com>
Message-ID: <4AA0C926.7070002@free.fr>

> Not that anyone actually cares, but things are broken again. Probably
> want to fix it.
> 
> Then again, probably not.

It's all an evil plan to try you insane!

Ciao,

Duncan.

From baldrick at free.fr  Fri Sep  4 03:10:44 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 04 Sep 2009 10:10:44 +0200
Subject: [LLVMdev] Dose I need to build llvm-gcc front-end from source
 resolve this error?
In-Reply-To: <tencent_2BEE7A7F79AC86377E114951@qq.com>
References: <tencent_2BEE7A7F79AC86377E114951@qq.com>
Message-ID: <4AA0CB84.1080407@free.fr>

Hi Sheng Wang, llvm-g++ comes with it's own copy of
libstdc++.  Using this rather than the ancient system
version you have installed may help.

Ciao,

Duncan.

From torvald at se.inf.tu-dresden.de  Fri Sep  4 04:10:24 2009
From: torvald at se.inf.tu-dresden.de (Torvald Riegel)
Date: Fri, 4 Sep 2009 11:10:24 +0200
Subject: [LLVMdev] version 2.3 of poolalloc
In-Reply-To: <4AA01E28.5050907@cs.uiuc.edu>
References: <31397.53220.qm@web59906.mail.ac4.yahoo.com>
	<4AA01AD9.2070102@illinois.edu> <4AA01E28.5050907@cs.uiuc.edu>
Message-ID: <200909041110.24541.torvald@se.inf.tu-dresden.de>

On Thursday 03 September 2009 21:51:04 John Criswell wrote:
> That is correct.  Mainline poolalloc will compile with the LLVM 2.6
> branch instead of LLVM mainline for the foreseeable future.  This is
> because 1) we want to make a "release" of poolalloc that works with LLVM
> 2.6 so that there is a poolalloc/SAFECode version that works with an
> LLVM release; and 2) I believe the LLVM API is changing again in
> mainline, and LLVM 2.6 seems like a good point at which to synchronize
> and stop.

A stable poolalloc release would definitely be a good thing.

Torvald

From overminddl1 at gmail.com  Fri Sep  4 04:29:20 2009
From: overminddl1 at gmail.com (OvermindDL1)
Date: Fri, 4 Sep 2009 03:29:20 -0600
Subject: [LLVMdev] version 2.3 of poolalloc
In-Reply-To: <200909041110.24541.torvald@se.inf.tu-dresden.de>
References: <31397.53220.qm@web59906.mail.ac4.yahoo.com>
	<4AA01AD9.2070102@illinois.edu> <4AA01E28.5050907@cs.uiuc.edu>
	<200909041110.24541.torvald@se.inf.tu-dresden.de>
Message-ID: <3f49a9f40909040229g1b39dd71o57f9da4591faf3aa@mail.gmail.com>

/* snip topic */

What exactly does poolalloc do?  I did a quick look through the svn
code and readme and it looks like it hooks functions that llvm
compiles in some-way...

From baldrick at free.fr  Fri Sep  4 06:15:27 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 04 Sep 2009 13:15:27 +0200
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
Message-ID: <4AA0F6CF.3060408@free.fr>

Hi Tanya, building llvm-2.6 on x86-64 linux with gcc-4.4 I see
the following warnings (also present on mainline):

llvm-2.6/runtime/libprofile/CommonProfiling.c: In function
?write_profiling_data?:
llvm-2.6/runtime/libprofile/CommonProfiling.c:103: warning: ignoring
return value of ?write?, declared with attribute warn_unused_result
llvm-2.6/runtime/libprofile/CommonProfiling.c:104: warning: ignoring
return value of ?write?, declared with attribute warn_unused_result
llvm-2.6/runtime/libprofile/CommonProfiling.c:105: warning: ignoring
return value of ?write?, declared with attribute warn_unused_result
llvm-2.6/runtime/libprofile/CommonProfiling.c:108: warning: ignoring
return value of ?write?, declared with attribute warn_unused_result
llvm-2.6/runtime/libprofile/CommonProfiling.c:114: warning: ignoring
return value of ?write?, declared with attribute warn_unused_result
llvm-2.6/runtime/libprofile/CommonProfiling.c:115: warning: ignoring
return value of ?write?, declared with attribute warn_unused_result
llvm-2.6/runtime/libprofile/CommonProfiling.c:116: warning: ignoring
return value of ?write?, declared with attribute warn_unused_result

Results (llvm-gcc built from source):

"make check" -> 1 unexpected success
(FrontendC/2009-08-11-AsmBlocksComplexJumpTarget.c)

I think Dale fixed this on mainline.

> To test llvm-gcc:
> 1) Compile llvm from source and untar the llvm-test in the projects 
> directory (name it llvm-test or test-suite). Choose to use a 
> pre-compiled llvm-gcc or re-compile it yourself.
> 2) Run make check, report any failures (FAIL or unexpected pass). Note 
> that you need to reconfigure llvm with llvm-gcc in your path or with 
> --with-llvmgccdir
> 3) Run "make TEST=nightly report" and send me the report.nightly.txt

I've attached report.nightly.txt.

> To test clang:
> 1) Compile llvm and clang from source.
> 2) Run make check for llvm.
> 3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or 
> unexpected passes)

No failures or unexpected passes.  Many warnings about aliasing problems
during the build (see PR4061).

> When reporting your results, please provide details on what platform you 
> compiled on,

x86-64 ubuntu (karmic) linux

and how
> you built LLVM (src == obj, or src != obj),clang, and/or llvm-gcc.

src != obj for all,
llvm-gcc configured with: --enable-languages=c,c++,fortran

> 
> Please COMPLETE ALL TESTING BY end of the day on Sept. 5th!

Thanks for taking care of the release!

Best wishes,

Duncan.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.nightly.txt
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090904/e181b403/attachment-0001.txt 

From mikael at lyngvig.org  Fri Sep  4 06:52:18 2009
From: mikael at lyngvig.org (Mikael Lyngvig)
Date: Fri, 4 Sep 2009 13:52:18 +0200 (CEST)
Subject: [LLVMdev] An alternate implementation of exceptions
In-Reply-To: <4AA0C446.4080800@free.fr>
References: <80d317280aad14174bfe694d545b4659.squirrel@squirrel-webmail.surftown.com>
	<4AA0C446.4080800@free.fr>
Message-ID: <b27970ae10b2dcfad74ccc6e60002979.squirrel@squirrel-webmail.surftown.com>

Hi Duncan,

I agree on the problem about linking with code - I actually do mention
this in the paper.  I propose adding a new calling convention called
"excall".

The central point of my paper is that only one parameter is needed as the
return value (because of the use of the flag): the EAX register can safely
be used for both the exception instance and the return value as these
never appear simultaneously.  That's the primary reason I use the Carry
flag: To avoid allocating a global variable, a thread variable or an
entire register solely for communicating exception conditions.  Especially
on register scarce architectures (vink, vink, Intel), it is important to
avoid allocating an entire register for the purpose of signaling a single
bit of information: 1 = an exception has occurred, 0 = no exception has
occurred.  Also, when you use a register, instead of a flag, to indicate
the exception condition, the caller must explicitly check if the register
is non-zero - this adds some overhead compared to the simple
"jump-if-carry" instruction.

Thanks for looking at my stuff and I can only say that I am HAPPY that
this method is already known.  I have not seen it implemented in any of
the compilers I use, but the most important thing for me is just that the
method is so great -- about four to five times faster than the traditional
stack unwind method (try expands to setjmp, throw expands to longjmp) --
that I wanted to make sure that somebody somewhere knew about the method.

I think I'll take my ideas to the OpenWatcom C++ mailing list as the
OpenWatcom compiler uses setjmp()/longjmp() in its exception handling
implementation (despite being one of the best compilers on the Intel
platform).

Cheers,
Mikael Lyngvig

> Hi Mikael, the idea of modifying functions so they return two parameters
> (the usual one and an exception pointer or some kind of exception flag)
> is well known.  The LLVM vmkit project actually uses a variant of this:
> rather than returning the exception pointer in a register, it sticks it
> in a global thread local variable.
>
> I only took a quick look at your paper, but it seems to me that it has
> a serious problem: you can't link C code using your exception handling
> mechanism with C code compiled using another compiler, since the carry
> flag may not be cleared on function return by the code compiled by the
> other compiler.  Perhaps you addressed this issue in your paper, as I
> mentioned I only glanced at it.  Vmkit doesn't suffer from this problem,
> since only code that is aware of vmkit exceptions will store in the
> global.
>
> Also, I don't see the point of the carry flag.  Why don't you just
> return the exception pointer in another register?  If it is non-null
> then an exception was raised.  Are you trying to avoid register
> pressure or save a cycle or two?
>
> Finally, you could implement this (or something close to it) pretty
> easily in LLVM.  Suppose you have a function "int f(params) {...}".
> Rather than outputting this to LLVM IR as
>    define i32 @f(params) { ... }
> you output it as
>    define {i32, i8*} @f(params) { ... }
> The additional return value is the exception pointer, which callers
> can then inspect to see whether an exception was raised.  On x86-64
> codegen will return the i32 in RAX and the exception pointer in RDX.
>
> Ciao,
>
> Duncan.
>



From torvald at se.inf.tu-dresden.de  Fri Sep  4 07:38:41 2009
From: torvald at se.inf.tu-dresden.de (Torvald Riegel)
Date: Fri, 4 Sep 2009 14:38:41 +0200
Subject: [LLVMdev] llvm-gcc ignores function attributes of template
	functions?
In-Reply-To: <200909031449.51261.torvald@se.inf.tu-dresden.de>
References: <200909031449.51261.torvald@se.inf.tu-dresden.de>
Message-ID: <200909041438.41426.torvald@se.inf.tu-dresden.de>

On Thursday 03 September 2009 14:49:51 Torvald Riegel wrote:
> llvm-gcc of LLVM 2.5 seems to ignore function attributes of template
> functions. For example, it doesn't set the noinline attribute, and it
>  doesn't warn on unknown attribute names. Is this known / intended
>  behavior?

Actually, this happens just for template methods of template classes (with the 
2.6 branch of llvm-gcc). I opened bug 4884 for this.

Torvald

From cedric.venet at laposte.net  Fri Sep  4 08:44:48 2009
From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=)
Date: Fri, 04 Sep 2009 15:44:48 +0200
Subject: [LLVMdev] An alternate implementation of exceptions
In-Reply-To: <b27970ae10b2dcfad74ccc6e60002979.squirrel@squirrel-webmail.surftown.com>
References: <80d317280aad14174bfe694d545b4659.squirrel@squirrel-webmail.surftown.com>	<4AA0C446.4080800@free.fr>
	<b27970ae10b2dcfad74ccc6e60002979.squirrel@squirrel-webmail.surftown.com>
Message-ID: <4AA119D0.6070708@laposte.net>


> Thanks for looking at my stuff and I can only say that I am HAPPY that
> this method is already known.  I have not seen it implemented in any of
> the compilers I use, but the most important thing for me is just that the
> method is so great -- about four to five times faster than the traditional
> stack unwind method (try expands to setjmp, throw expands to longjmp) --
> that I wanted to make sure that somebody somewhere knew about the method.
>   

C++ exception implementation are optimized for the case where no 
exception is throw (opposite to what is done in python or maybe in 
java). Because in C++ exception are exceptionnal and should not be 
thrown during a normal execution of a program (use return code in this 
case). At least this is what all the C++ guru preach (that I know of).
I don't think your implementation can be faster than current zero cost 
exception model used currently (where metainformation is added somewhere 
for unwinding, but no other code is needed) in the case of no exception 
throw. And like I said, in the other case we don't care much about 
speed, since it is an exceptional occurrence.

This is just the way I see it, but at least for C++, the current 
solution seems more appropriate. obviously, for language like python 
which use exception to exit loop, this isn't the same thinks at all.

just my 2cents

C?dric

From andrewl at lenharth.org  Fri Sep  4 09:01:18 2009
From: andrewl at lenharth.org (Andrew Lenharth)
Date: Fri, 4 Sep 2009 09:01:18 -0500
Subject: [LLVMdev] version 2.3 of poolalloc
In-Reply-To: <3f49a9f40909040229g1b39dd71o57f9da4591faf3aa@mail.gmail.com>
References: <31397.53220.qm@web59906.mail.ac4.yahoo.com>
	<4AA01AD9.2070102@illinois.edu> <4AA01E28.5050907@cs.uiuc.edu>
	<200909041110.24541.torvald@se.inf.tu-dresden.de>
	<3f49a9f40909040229g1b39dd71o57f9da4591faf3aa@mail.gmail.com>
Message-ID: <85dfcd7f0909040701i6bf442bfqf1ad152ea7149dce@mail.gmail.com>

On Fri, Sep 4, 2009 at 4:29 AM, OvermindDL1<overminddl1 at gmail.com> wrote:
> /* snip topic */
>
> What exactly does poolalloc do? ?I did a quick look through the svn
> code and readme and it looks like it hooks functions that llvm
> compiles in some-way...

http://llvm.org/pubs/2005-05-21-PLDI-PoolAlloc.html

See also:
http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html
http://llvm.org/pubs/2007-06-10-PLDI-DSA.html

Andrew

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


From wansheg at gmail.com  Fri Sep  4 09:12:15 2009
From: wansheg at gmail.com (=?gbk?B?U2hlbmcgV2FuZw==?=)
Date: Fri, 4 Sep 2009 22:12:15 +0800
Subject: [LLVMdev] build the llvm-gcc from source,  error  occur.
Message-ID: <tencent_467BD36627A54A87796D44C6@qq.com>

I first install the gcc-4.2.4 .
then I set CC and CXX 
     export CC= "path of my gcc-4.2.4"
     export CXX="path of my g++-4.2.4"

after that  , I config and make .
error occur like this :
/home/ws/software/gcc-4-2/bin/gcc -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute    -DHAVE_CONFIG_H -I. -Ijava -I../../llvm-gcc4.2-2.5.source/gcc -I../../llvm-gcc4.2-2.5.source/gcc/java -I../../llvm-gcc4.2-2.5.source/gcc/../include -I../../llvm-gcc4.2-2.5.source/gcc/../libcpp/include  -I../../llvm-gcc4.2-2.5.source/gcc/../libdecnumber -I../libdecnumber -I/home/ws/software/build-llvm-gcc/../build-llvm//include -I/home/ws/software/llvm-2.5/include -DENABLE_LLVM -I/home/ws/software/build-llvm/../llvm-2.5/include  -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS   ../../llvm-gcc4.2-2.5.source/gcc/java/lang.c -o java/lang.o
../../llvm-gcc4.2-2.5.source/gcc/java/lang.c: In function??java_init??????
../../llvm-gcc4.2-2.5.source/gcc/java/lang.c:378: error????force_align_functions_log??not declare ( occur first in the function)
.............

what matter I only enable-language c, c++, ada tube java  ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090904/efe8f74d/attachment.html 

From brukman at gmail.com  Fri Sep  4 09:42:07 2009
From: brukman at gmail.com (Misha Brukman)
Date: Fri, 4 Sep 2009 10:42:07 -0400
Subject: [LLVMdev] build the llvm-gcc from source, error occur.
In-Reply-To: <tencent_467BD36627A54A87796D44C6@qq.com>
References: <tencent_467BD36627A54A87796D44C6@qq.com>
Message-ID: <f88b89a50909040742v232e5b7ck72902aad3758c385@mail.gmail.com>

2009/9/4 Sheng Wang <wansheg at gmail.com>

> ../../llvm-gcc4.2-2.5.source/gcc/java/lang.c: In function?java_init???
> ../../llvm-gcc4.2-2.5.source/gcc/java/lang.c:378:
> error??force_align_functions_log?not declare ( occur first in the function)
> .............
>
> what matter I only enable-language c, c++, ada tube java  ?
>

I don't think Java is supported in llvm-gcc.  Here is the information for
building llvm-gcc with C, C++ and/or Ada support:
http://llvm.org/docs/GCCFEBuildInstrs.html .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090904/1dfacc2d/attachment.html 

From sebastian.redl at getdesigned.at  Fri Sep  4 10:06:34 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Fri, 04 Sep 2009 17:06:34 +0200
Subject: [LLVMdev] An alternate implementation of exceptions
In-Reply-To: <b27970ae10b2dcfad74ccc6e60002979.squirrel@squirrel-webmail.surftown.com>
References: <80d317280aad14174bfe694d545b4659.squirrel@squirrel-webmail.surftown.com>	<4AA0C446.4080800@free.fr>
	<b27970ae10b2dcfad74ccc6e60002979.squirrel@squirrel-webmail.surftown.com>
Message-ID: <4AA12CFA.4020008@getdesigned.at>

Mikael Lyngvig wrote:
> Hi Duncan,
>
> I agree on the problem about linking with code - I actually do mention
> this in the paper.  I propose adding a new calling convention called
> "excall".
>   
The problem is that you can't automatically determine from a function
declaration whether it comes from "inside" (is exception-aware) or not.
This means that you'd have to make the user explicitly declare one of
them. This is either a nightmare for using libraries (modify all
headers, or introduce an extern "C"-block-like feature as C++ has it, to
wrap the header includes), or a nightmare for writing new code (every
new function needs to have it, explicitly).

Sebastian

From felipe.lessa at gmail.com  Fri Sep  4 10:25:35 2009
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Fri, 4 Sep 2009 12:25:35 -0300
Subject: [LLVMdev] An alternate implementation of exceptions
In-Reply-To: <4AA12CFA.4020008@getdesigned.at>
References: <80d317280aad14174bfe694d545b4659.squirrel@squirrel-webmail.surftown.com>
	<4AA0C446.4080800@free.fr>
	<b27970ae10b2dcfad74ccc6e60002979.squirrel@squirrel-webmail.surftown.com>
	<4AA12CFA.4020008@getdesigned.at>
Message-ID: <20090904152535.GA26019@kira.casa>

On Fri, Sep 04, 2009 at 05:06:34PM +0200, Sebastian Redl wrote:
> Mikael Lyngvig wrote:
> The problem is that you can't automatically determine from a function
> declaration whether it comes from "inside" (is exception-aware) or not.

Just throwing the idea in the air: link time optimization of
exception handling? :)

--
Felipe.

From lattner at apple.com  Fri Sep  4 11:14:34 2009
From: lattner at apple.com (Tanya Lattner)
Date: Fri, 4 Sep 2009 09:14:34 -0700
Subject: [LLVMdev] build the llvm-gcc from source,  error  occur.
In-Reply-To: <tencent_467BD36627A54A87796D44C6@qq.com>
References: <tencent_467BD36627A54A87796D44C6@qq.com>
Message-ID: <41D6655F-35A4-4374-83AB-1CB9EAF0A5B2@apple.com>


On Sep 4, 2009, at 7:12 AM, Sheng Wang wrote:

> I first install the gcc-4.2.4 .
> then I set CC and CXX
>      export CC= "path of my gcc-4.2.4"
>      export CXX="path of my g++-4.2.4"
>
> after that  , I config and make .
> error occur like this :
> /home/ws/software/gcc-4-2/bin/gcc -c   -g -O2 -DIN_GCC   -W -Wall - 
> Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic - 
> Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold- 
> style-definition -Wmissing-format-attribute    -DHAVE_CONFIG_H -I. - 
> Ijava -I../../llvm-gcc4.2-2.5.source/gcc -I../../llvm- 
> gcc4.2-2.5.source/gcc/java -I../../llvm-gcc4.2-2.5.source/gcc/../ 
> include -I../../llvm-gcc4.2-2.5.source/gcc/../libcpp/include  - 
> I../../llvm-gcc4.2-2.5.source/gcc/../libdecnumber -I../libdecnumber - 
> I/home/ws/software/build-llvm-gcc/../build-llvm//include -I/home/ws/ 
> software/llvm-2.5/include -DENABLE_LLVM -I/home/ws/software/build- 
> llvm/../llvm-2.5/include  -D_DEBUG  -D_GNU_SOURCE - 
> D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS   ../../llvm- 
> gcc4.2-2.5.source/gcc/java/lang.c -o java/lang.o
> ../../llvm-gcc4.2-2.5.source/gcc/java/lang.c: In  
> function??java_init??????
> ../../llvm-gcc4.2-2.5.source/gcc/java/lang.c:378:  
> error????force_align_functions_log??not declare ( occur first in the  
> function)
> .............
>
> what matter I only enable-language c, c++, ada tube java  ?
>

Please follow the directions in the README.LLVM file (in llvm-gcc src)  
exactly. It will tell you what languages to enable (never java). If  
you do not follow it exactly, you will most likely run into problems.

-Tanya

>
>
>
>
> _______________________________________________
> 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  Fri Sep  4 11:14:35 2009
From: richard at xmos.com (Richard Osborne)
Date: Fri, 4 Sep 2009 17:14:35 +0100
Subject: [LLVMdev] An alternate implementation of exceptions
In-Reply-To: <4AA12CFA.4020008@getdesigned.at>
References: <80d317280aad14174bfe694d545b4659.squirrel@squirrel-webmail.surftown.com>	<4AA0C446.4080800@free.fr>	<b27970ae10b2dcfad74ccc6e60002979.squirrel@squirrel-webmail.surftown.com>
	<4AA12CFA.4020008@getdesigned.at>
Message-ID: <4AA13CEB.1040701@xmos.com>

Sebastian Redl wrote:
> Mikael Lyngvig wrote:
>   
>> Hi Duncan,
>>
>> I agree on the problem about linking with code - I actually do mention
>> this in the paper.  I propose adding a new calling convention called
>> "excall".
>>   
>>     
> The problem is that you can't automatically determine from a function
> declaration whether it comes from "inside" (is exception-aware) or not.
> This means that you'd have to make the user explicitly declare one of
> them. This is either a nightmare for using libraries (modify all
> headers, or introduce an extern "C"-block-like feature as C++ has it, to
> wrap the header includes), or a nightmare for writing new code (every
> new function needs to have it, explicitly).
>   
You could use some form name mangling on all symbols which are exception 
aware. When there is a mismatch between callee and caller you will get a 
undefined symbol. You would then add thunks for these symbols (by having 
a tool which parse error messages from the linker or by modifying the 
linker to add them).

When an exception aware function calls a non exception aware one the 
thunk should call the function, clear the flags and then return. When an 
non exception aware function calls a function which might throw the 
thunk should check for an exception. If there is a pending exception it 
should abort, otherwise it would just return.

-- 
Richard Osborne | XMOS
http://www.xmos.com


From Benedict.Gaster at amd.com  Fri Sep  4 11:37:52 2009
From: Benedict.Gaster at amd.com (Gaster, Benedict)
Date: Fri, 4 Sep 2009 18:37:52 +0200
Subject: [LLVMdev] TOT opt does not terminate!
Message-ID: <14DD0B1CD80F5C46841ED44E4CC2CAA330494C@seurexmb2.amd.com>

The following code causes opt to not terminate!

 

With TOT this morning, and of a week ago:

 

clang foo.c and clang -O1 foo.c

 

work fine.

 

clang -O2 foo.c and clang -O3 foo.c

 

do not terminate. (At least after 10 minutes)

 

If I generate the bit code (clang-cc -emit-llvmbc) and then run:

 

opt -O3 foo.bc

 

it does not terminate.

 

//foo.c

int get_id(int);

 

typedef short short2 __attribute__ ((vector_size (2)));

 

union _X {

    short2 s;

    int i;

};

 

typedef union _X X;

 

inline short2 as_short2(int x)

{

    X result;

 

    result.i = x;

    return result.s;

}

 

inline int as_int(short2 x)

{

    X result;

 

    result.s = x;

    return result.i;

}

 

void short2_int_swap(

  short2* b, 

  int* c)

{

    int gidx = get_id(0);

    short2 bval = b[gidx];

    int cval = c[gidx];

 

    b[gidx] = as_short2(cval);

    c[gidx] = as_int(bval);

}

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

From komurav1 at illinois.edu  Fri Sep  4 12:29:22 2009
From: komurav1 at illinois.edu (Rakesh Komuravelli)
Date: Fri, 4 Sep 2009 12:29:22 -0500
Subject: [LLVMdev] Error in Hello World Pass
Message-ID: <bf0e41fc0909041029q3d9cdefnfa35a91635a49739@mail.gmail.com>

Hi,
I am trying to compile the Hello World pass (described at
http://llvm.org/docs/WritingAnLLVMPass.html#basiccode) in an LLVM Project
and I get an error, 'no match for ?operator<<? at line

llvm::cerr << "*Hello: *" << F.getName() << "\n";

But when I looked up in the LLVM API Documentation, I think "<<"
operator is not overloaded for the StringRef class returned by
getName() of the Function class. If I replace the above line with

llvm::cerr << "*Hello: *" << F.getName().str() << "\n";

it compiles fine. I was just wondering if its a bug in the document
describing the Hello World pass or am I referring it incorrectly?

Thanks,

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

From baldrick at free.fr  Fri Sep  4 12:38:18 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 04 Sep 2009 19:38:18 +0200
Subject: [LLVMdev] SCCIterator and unconnected graphs
In-Reply-To: <4A9FA563.1030602@elis.UGent.be>
References: <4A9FA563.1030602@elis.UGent.be>
Message-ID: <4AA1508A.1060609@free.fr>

Hi Hans,

> I am using the scc_iterator class in my code on a CallGraph, where some 
> functions are not called from within the module. It seems that 
> scc_iterator does not list all SCCs if the graph is not connected; only 
> those nodes connected to the node pointed to by 
> GraphTraits<...>::getEntryNode() are returned.

is the callgraph itself complete?  I.e. is the problem in the iterator
or in the callgraph construction?  Also, can you please post a testcase.

Ciao,

Duncan.

From lattner at apple.com  Fri Sep  4 12:44:23 2009
From: lattner at apple.com (Tanya Lattner)
Date: Fri, 4 Sep 2009 10:44:23 -0700
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
Message-ID: <B4778B39-73AF-44B4-8243-0DDFB66ACC89@apple.com>

Just a reminder that this should be wrapping up by end of day tomorrow.

There are several 2.6 bugs, so we might be pushing the release out a  
week to get those all fixed. I'll update once I know more.

-Tanya

On Aug 30, 2009, at 10:50 PM, Tanya Lattner wrote:

> LLVMers,
>
> 2.6 pre-release1 is ready to be tested by the community.
> http://llvm.org/prereleases/2.6/
>
> You will notice that we have quite a few pre-compiled binaries (of  
> both clang and llvm-gcc). We have identified several bugs that will  
> be fixed in pre-release2, so please search the bug database before  
> filing a new bug.
>
> If you have time, I'd appreciate anyone who can help test the release.
> To test llvm-gcc:
> 1) Compile llvm from source and untar the llvm-test in the projects  
> directory (name it llvm-test or test-suite). Choose to use a pre- 
> compiled llvm-gcc or re-compile it yourself.
> 2) Run make check, report any failures (FAIL or unexpected pass).  
> Note that you need to reconfigure llvm with llvm-gcc in your path or  
> with --with-llvmgccdir
> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>
> To test clang:
> 1) Compile llvm and clang from source.
> 2) Run make check for llvm.
> 3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures  
> or unexpected passes)
>
> When reporting your results, please provide details on what platform  
> you compiled on, and how
> you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.
>
> Please COMPLETE ALL TESTING BY end of the day on Sept. 5th!
> Thanks, Tanya Lattner
>

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

From simmon12 at cs.uiuc.edu  Fri Sep  4 14:26:17 2009
From: simmon12 at cs.uiuc.edu (Patrick Alexander Simmons)
Date: Fri, 04 Sep 2009 13:26:17 -0600
Subject: [LLVMdev] Error in Hello World Pass
In-Reply-To: <bf0e41fc0909041029q3d9cdefnfa35a91635a49739@mail.gmail.com>
References: <bf0e41fc0909041029q3d9cdefnfa35a91635a49739@mail.gmail.com>
Message-ID: <4AA169D9.4060006@cs.uiuc.edu>

Yeah, I just had to make a similar change to some of the code in my 
pass.  I think the API changed and no one bothered to update the docs.

--Patrick

Rakesh Komuravelli wrote:
> Hi,
>
> I am trying to compile the Hello World pass (described 
> at http://llvm.org/docs/WritingAnLLVMPass.html#basiccode) in an LLVM 
> Project and I get an error, 'no match for ?operator<<? at line 
> llvm::cerr << "/Hello: /" << F.getName() << "\n";
>   
> But when I looked up in the LLVM API Documentation, I think "<<" operator is not overloaded for the StringRef class returned by getName() of the Function class. If I replace the above line with 
> llvm::cerr << "/Hello: /" << F.getName().str() << "\n";
> it compiles fine. I was just wondering if its a bug in the document describing the Hello World pass or am I referring it incorrectly?
>
> Thanks,
> Rakesh
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From Benedict.Gaster at amd.com  Fri Sep  4 15:53:04 2009
From: Benedict.Gaster at amd.com (Gaster, Benedict)
Date: Fri, 4 Sep 2009 22:53:04 +0200
Subject: [LLVMdev] ScheduleDAG Question
In-Reply-To: <200909032124.56872.dag@cray.com>
References: <200909031148.04144.dag@cray.com><f5aa3e9b0909031841h252b0964j59d7bb7d7c753b1@mail.gmail.com><200909032113.24759.dag@cray.com>
	<200909032124.56872.dag@cray.com>
Message-ID: <14DD0B1CD80F5C46841ED44E4CC2CAA33049AC@seurexmb2.amd.com>

Hi David,

Interesting... I have come across a problem that looks like edge is
being removed and I'm wondering if it may be related. The problem is
described in http://llvm.org/bugs/show_bug.cgi?id=4891.

Regards,

Ben

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of David Greene
Sent: Thursday, September 03, 2009 7:25 PM
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] ScheduleDAG Question

On Thursday 03 September 2009 21:13, David Greene wrote:

> Hmm...except there's a little dashed blue line from the call to the
chain
> (I think) field of the load.  Is that the dependence I want?  I don't
know
> how to read these graphs.

Interesting.  So with -view-legalize-dags, that little dashed blue line
has
moved from the load to the store that feeds the load.  That's wrong.

But it's still there with -view-legalize-types-dags, so legalize types
must
be buggy.  But -disable-legalize-types doesn't fix the problem.  So the 
general legalize code seems to have the same issue.

LLVM 2.5 compiles this fine, so it's something we've altered in the
codebase.
I did a diff of all of our changes to lib/CodeGen and
include/llvm/CodeGen
but nothing jumpoed out as obviously wrong.  I suppose it's possible we
present slightly different code to the legalize passes than the
unmodified
LLVM.

Fun times, indeed.

                                -Dave
_______________________________________________
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 Sep  4 16:28:01 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 4 Sep 2009 14:28:01 -0700
Subject: [LLVMdev] Things are Broken ... Again *shock*
In-Reply-To: <4AA0C926.7070002@free.fr>
References: <16e5fdf90909031600o4752c15bn8a8eec4bf9fc2200@mail.gmail.com>
	<4AA0C926.7070002@free.fr>
Message-ID: <791C2E65-D4B4-4A12-9958-A5EAD1B96939@apple.com>


On Sep 4, 2009, at 1:00 AM, Duncan Sands wrote:

>> Not that anyone actually cares, but things are broken again. Probably
>> want to fix it.
>>
>> Then again, probably not.
>
> It's all an evil plan to try you insane!

It's already accomplished. We can stop it now. :-)

Evan

>
> 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 Benedict.Gaster at amd.com  Fri Sep  4 16:33:13 2009
From: Benedict.Gaster at amd.com (Gaster, Benedict)
Date: Fri, 4 Sep 2009 23:33:13 +0200
Subject: [LLVMdev] Using -view-legalize-dags
Message-ID: <14DD0B1CD80F5C46841ED44E4CC2CAA33049B5@seurexmb2.amd.com>

I'm trying to debug an issue in codegen but when using:

 

llc -view-legalize-dags -O1 -march=x86-64 -o c-01.s c-opt.bc

 

I get a .dot file and while it has the DAG the nodes do not have any
text. I'm probably doing something very stupid but I cannot figure what
it is can anyone point out what I'm doing wrong?

 

Thanks,

 

Ben

 

I'm on Unbunto 9.3:

 

dotty version 96c (09-24-96)

lefty version 10 Mar 2005

graphviz version 2.20.2 (Mon Mar 30 10:11:53 UTC 2009)

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

From stoklund at 2pi.dk  Fri Sep  4 20:54:36 2009
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Sat, 05 Sep 2009 08:54:36 +0700
Subject: [LLVMdev] Problems with DAG Combiner
In-Reply-To: <041DD5ACCD9F824BB2273B9421CA13D2011A32DA@RZ-EX-06.rz.uni-karlsruhe.de>
References: <041DD5ACCD9F824BB2273B9421CA13D2011A2F7E@RZ-EX-06.rz.uni-karlsruhe.de>
	<4417854A-5C5E-442B-8EEE-4BFCEA2E278E@2pi.dk>
	<041DD5ACCD9F824BB2273B9421CA13D2011A2F83@RZ-EX-06.rz.uni-karlsruhe.de>
	<D66EC51D-1B90-4345-A41C-F30AD81D8EF2@2pi.dk>
	<041DD5ACCD9F824BB2273B9421CA13D2011A32DA@RZ-EX-06.rz.uni-karlsruhe.de>
Message-ID: <4AA1C4DC.9000402@2pi.dk>

Stripf, Timo wrote:
> I converted now my back-end with legal i1 lowering to the 2.6 branch
> and my original problem with the DAG combiner didn't occur any more
> and seems to be fixed. setOperationAction(ISD::OR, MVT::i1, Promote)
> also works fine for logical operations.

Excellent.

>> What is your SetCCResultType now?
> 
> I changed SetCCResultType to return MVT::i1 type.
> 
>> Can you compile the CodeGen/Blackfin/basic-i1.ll test case? I never
>>  got that one working with legal i1. The IA64 back-end couldn't
>> compile it either.
> 
> No, I was not able to compile your basic-i1.ll test case but I think
> it is no big deal to add the missing Promote or Expand code for these
> operations. "add i1" / "sub i1" can be changed to "xor i1", "mul i1"
> to "and i1". I think div/rem operations must be promoted.

Yeah. div/rem can probably just return the first argument since division
by zero is undefined.

>> I hate to scope-creep your research, but I would be very interested
>> in an analysis of native i1 operations versus promotions. Are you
>>  planning an ISA version with built-in i1 AND/OR/XOR?
> 
> I've generated a back-end with built-in i1 AND/OR/XOR operations and
> compared the results against a back-end without these operations. Atm
> I don't have many applications I can test. I've one application that
> runs only the CABAC part of H.264 and thereby i1 AND/OR/XOR
> operations decrease the number of executed operations by 0.2% on a
> behavioural instruction-set simulator. I used gcc front-end, maybe
> clang uses more i1 instructions.

Great, thanks for doing this.

Since C arithmetic is always promoted to at least int, I wouldn't expect
a C frontend to produce any i1 arithmetic. It could appear as a result
of optimizations and in the DAG combiner, though.

It looks like i1 operations are not that useful, but I can think of a
few cases where they vcould help performance. For instance "if (a<b &&
b<c)" would benefit from using only one conditional branch on a platform
with weak branch prediction.

> Another problem came up when I tried to promote constant i1 values to
> i32. It required a custom legalization but later the instruction
> selector found i1 constants. So I suspect that DAG combiner
> reintroduced i1 constants. I gave up and added a related instruction
> to the architecture.

Hey, that's cheating! The rest of us don't get to do that, you know. :-)

/jakob


From edwintorok at gmail.com  Sat Sep  5 03:56:48 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Sat, 05 Sep 2009 11:56:48 +0300
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
Message-ID: <4AA227D0.8060907@gmail.com>

On 2009-08-31 08:50, Tanya Lattner wrote:
> LLVMers,
>
> 2.6 pre-release1 is ready to be tested by the community. 
> http://llvm.org/prereleases/2.6/
>

Hi Tanya,

Here are the results for x86_64 Linux (Debian unstable):

> You will notice that we have quite a few pre-compiled binaries (of
> both clang and llvm-gcc). We have identified several bugs that will be
> fixed in pre-release2, so please search the bug database before filing
> a new bug.
>
> If you have time, I'd appreciate anyone who can help test the release.
> To test llvm-gcc:
> 1) Compile llvm from source and untar the llvm-test in the projects
> directory (name it llvm-test or test-suite). Choose to use a
> pre-compiled llvm-gcc or re-compile it yourself.
> 2) Run make check, report any failures (FAIL or unexpected pass). Note
> that you need to reconfigure llvm with llvm-gcc in your path or with
> --with-llvmgccdir
> 3) Run "make TEST=nightly report" and send me the report.nightly.txt

Built from source, objdir != srcdir
../llvm-gcc4.2-2.6.source/configure   --program-prefix=llvm-
--enable-llvm=/home/edwin/llvm2.6/obj/ --enable-languages=c,c++,fortran

XPASS:
/home/edwin/llvm2.6/llvm-2.6/test/FrontendC/2009-08-11-AsmBlocksComplexJumpTarget.c


>
> To test clang:
> 1) Compile llvm and clang from source.
> 2) Run make check for llvm.
> 3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or
> unexpected passes)

Tests OK.

Some further testing I did (not all PRs here are regressions):

ClamAV (latest git): clang OK, llvm-gcc OK

Linux 2.6.31-rc8 (patched) build fails for both:
     ARCH=x86: clang: PR4689, llvm-gcc/clang: PR4628
     ARCH=um: clang: PR4096, PR4689, llvm-gcc: PR4898
(note that at some point LLVM was able to compile these, not sure if it
was 2.5, or after 2.5)

Perl 5.10:
      clang: build OK, 1 test fails PR4897
      llvm-gcc: OK
valgrind 3.4.1:
       clang: build fails PR2461, PR4899;
       llvm-gcc build OK, test build fails PR4434
ACE_wrappers: llvm-gcc OK
blender 2.49b:
         llvm-gcc build OK, render matches gcc where render is
deterministic, and mean-square-error is about the same where not
         clang build OK (building only C sources), renders some blend
files differently, particularly around shaded regions:  PR4900

Best regards,
--Edwin

From edwintorok at gmail.com  Sat Sep  5 03:58:34 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Sat, 05 Sep 2009 11:58:34 +0300
Subject: [LLVMdev] 2.6 pre-release1 ready for testing
In-Reply-To: <4AA227D0.8060907@gmail.com>
References: <2D7844DA-CC6B-43F6-8610-0D4D74365B66@apple.com>
	<4AA227D0.8060907@gmail.com>
Message-ID: <4AA2283A.4090509@gmail.com>

On 2009-09-05 11:56, T?r?k Edwin wrote:
> On 2009-08-31 08:50, Tanya Lattner wrote:
>   
>> LLVMers,
>>
>> 2.6 pre-release1 is ready to be tested by the community. 
>> http://llvm.org/prereleases/2.6/
>>
>>     
>
> Hi Tanya,
>
> Here are the results for x86_64 Linux (Debian unstable):
>
>   
>> You will notice that we have quite a few pre-compiled binaries (of
>> both clang and llvm-gcc). We have identified several bugs that will be
>> fixed in pre-release2, so please search the bug database before filing
>> a new bug.
>>
>> If you have time, I'd appreciate anyone who can help test the release.
>> To test llvm-gcc:
>> 1) Compile llvm from source and untar the llvm-test in the projects
>> directory (name it llvm-test or test-suite). Choose to use a
>> pre-compiled llvm-gcc or re-compile it yourself.
>> 2) Run make check, report any failures (FAIL or unexpected pass). Note
>> that you need to reconfigure llvm with llvm-gcc in your path or with
>> --with-llvmgccdir
>> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>>     
>
>   

Attached report.nightly.txt.

> Built from source, objdir != srcdir
> ../llvm-gcc4.2-2.6.source/configure   --program-prefix=llvm-
> --enable-llvm=/home/edwin/llvm2.6/obj/ --enable-languages=c,c++,fortran
>
> XPASS:
> /home/edwin/llvm2.6/llvm-2.6/test/FrontendC/2009-08-11-AsmBlocksComplexJumpTarget.c
>
>
>   
>> To test clang:
>> 1) Compile llvm and clang from source.
>> 2) Run make check for llvm.
>> 3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or
>> unexpected passes)
>>     
>
> Tests OK.
>
> Some further testing I did (not all PRs here are regressions):
>
> ClamAV (latest git): clang OK, llvm-gcc OK
>
> Linux 2.6.31-rc8 (patched) build fails for both:
>      ARCH=x86: clang: PR4689, llvm-gcc/clang: PR4628
>      ARCH=um: clang: PR4096, PR4689, llvm-gcc: PR4898
> (note that at some point LLVM was able to compile these, not sure if it
> was 2.5, or after 2.5)
>
> Perl 5.10:
>       clang: build OK, 1 test fails PR4897
>       llvm-gcc: OK
> valgrind 3.4.1:
>        clang: build fails PR2461, PR4899;
>        llvm-gcc build OK, test build fails PR4434
> ACE_wrappers: llvm-gcc OK
> blender 2.49b:
>          llvm-gcc build OK, render matches gcc where render is
> deterministic, and mean-square-error is about the same where not
>          clang build OK (building only C sources), renders some blend
> files differently, particularly around shaded regions:  PR4900
>
> Best regards,
> --Edwin
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.nightly.txt
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090905/2360eb3a/attachment-0001.txt 

From eli.friedman at gmail.com  Sat Sep  5 04:26:12 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sat, 5 Sep 2009 02:26:12 -0700
Subject: [LLVMdev] TOT opt does not terminate!
In-Reply-To: <14DD0B1CD80F5C46841ED44E4CC2CAA330494C@seurexmb2.amd.com>
References: <14DD0B1CD80F5C46841ED44E4CC2CAA330494C@seurexmb2.amd.com>
Message-ID: <f5aa3e9b0909050226m2d6de935pa9be2789e25adb3c@mail.gmail.com>

On Fri, Sep 4, 2009 at 9:37 AM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote:
> The following code causes opt to not terminate!

Please flle in bugzilla with a bitcode testcase; it would help to
reduce the testcase using bugpoint.

-Eli

From nicolas.geoffray at lip6.fr  Sat Sep  5 09:02:07 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Sat, 05 Sep 2009 16:02:07 +0200
Subject: [LLVMdev] Issues with HelloWorld on VMKit
In-Reply-To: <BB0A9371-E095-4958-A2B6-A37CBD0BA661@doc.ic.ac.uk>
References: <89125AB9-D125-4535-9C40-DDDC44097B83@doc.ic.ac.uk>
	<4A8D5D85.9010900@lip6.fr>
	<BB0A9371-E095-4958-A2B6-A37CBD0BA661@doc.ic.ac.uk>
Message-ID: <4AA26F5F.7080605@lip6.fr>

Hi Matteo,

Matteo Migliavacca wrote:

>> Have you done the links from procedure no 2 on the "get started" page?
>
> Ops, that was it, thanks! (Sometimes I wish humans could have  
> instruction pointers....)

Great, I should definitely print an error message for that.

> I was wondering the easiest way to play a bit with  Isolation  
> features, but I am still missing a great deal of understanding of the  
> whole project. Is Isolation tied to the OSGi framework? I see three  
> compile options single/isolate/isolate-sharing/service what these do?  
> Is I-JVM supposed to run off-the shelf Felix or Equinox?
>

Yes, there are multiple ways to build vmkit. The usual one is for having 
a JVM similar to other JVMs. The isolate one is to run multiple Java 
applications inside a single instance of vmkit. The isolate-sharing 
enables sharing code between all the applications. Finally, service is 
for I-JVM. For I-JVM, I'll take that offline, it's off-topic for this 
mailing list.

Cheers,
Nicolas


From andrii.vasyliev at gmail.com  Sat Sep  5 09:40:09 2009
From: andrii.vasyliev at gmail.com (Andrii Vasyliev)
Date: Sat, 5 Sep 2009 17:40:09 +0300
Subject: [LLVMdev] Cross-module optimization
Message-ID: <dc7e00e30909050740v481082fcnd4aecbb5e89f9a3a@mail.gmail.com>

Hi!

I want to load several modules with BitcodeReader and build a module
with IRBuilder and then optimize them alltogether. Actually I want
functions from loaded modules to be inlined in functions that I've built.
Is it possible with LLVM? As I understood PassManager runs upon only
one module at once.

May be is there some workaround? Like joining all the modules in one
and then optimize it. Unfortunately I couldn't find a way to join modules.

Thanks,
Andrii

From baldrick at free.fr  Sat Sep  5 10:23:20 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 05 Sep 2009 17:23:20 +0200
Subject: [LLVMdev] Cross-module optimization
In-Reply-To: <dc7e00e30909050740v481082fcnd4aecbb5e89f9a3a@mail.gmail.com>
References: <dc7e00e30909050740v481082fcnd4aecbb5e89f9a3a@mail.gmail.com>
Message-ID: <4AA28268.90208@free.fr>

Hi Andrii,

> May be is there some workaround? Like joining all the modules in one
> and then optimize it. Unfortunately I couldn't find a way to join modules.

llvm-link does this.

Ciao,

Duncan.

From andrii.vasyliev at gmail.com  Sat Sep  5 10:49:15 2009
From: andrii.vasyliev at gmail.com (Andrii Vasyliev)
Date: Sat, 5 Sep 2009 18:49:15 +0300
Subject: [LLVMdev] Cross-module optimization
In-Reply-To: <4AA28268.90208@free.fr>
References: <dc7e00e30909050740v481082fcnd4aecbb5e89f9a3a@mail.gmail.com>
	<4AA28268.90208@free.fr>
Message-ID: <dc7e00e30909050849mb38f0e1gd0936ac9532a99e7@mail.gmail.com>

>> May be is there some workaround? Like joining all the modules in one
>> and then optimize it. Unfortunately I couldn't find a way to join modules.
> llvm-link does this.

Thanks for answer, Duncan!
But I want to do it in my program and then run it with ExecutionEngine...

Hey, but I took a look inside of llvm-link and found a Linker class
which does modules linking! :)

So, is this the right answer? To optimize modules altogether link them before?

Andrii

From baldrick at free.fr  Sat Sep  5 11:08:03 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 05 Sep 2009 18:08:03 +0200
Subject: [LLVMdev] Cross-module optimization
In-Reply-To: <dc7e00e30909050849mb38f0e1gd0936ac9532a99e7@mail.gmail.com>
References: <dc7e00e30909050740v481082fcnd4aecbb5e89f9a3a@mail.gmail.com>	
	<4AA28268.90208@free.fr>
	<dc7e00e30909050849mb38f0e1gd0936ac9532a99e7@mail.gmail.com>
Message-ID: <4AA28CE3.2060900@free.fr>

> So, is this the right answer? To optimize modules altogether link them before?

Yes.

Ciao,

Duncan.

From isanbard at gmail.com  Sat Sep  5 12:57:09 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sat, 5 Sep 2009 12:57:09 -0500
Subject: [LLVMdev]
 =?utf-8?b?5Zue5aSN77yaIERvc2UgSSBuZWVkIHRvIGJ1aWxkIGxs?=
 =?utf-8?q?vm-gcc_front-end_from_source_to_resolve_this_error=3F?=
In-Reply-To: <tencent_4EC6B1F369DEE14A4BA64A29@qq.com>
References: <tencent_4EC6B1F369DEE14A4BA64A29@qq.com>
Message-ID: <14446F5B-BCCB-4C4E-8CD9-17DDBEC08112@gmail.com>

Hi Sheng Wang,

I don't think so. This looks like it's not finding the correct  
headers, which isn't a problem in the llvm-gcc code itself. To  
determine what's going on, use the -v flag to see where it's trying to  
find the hearders. You may have to specify additional search  
directories on the command line. Especially if llvm-c++ isn't  
installed in /usr/bin.

-bw

On Sep 4, 2009, at 2:51 AM, "Sheng Wang" <wansheg at gmail.com> wrote:

> sorry ! I have re-corrected the title.
>
> ------------------ ???? ------------------
> ???: "Sheng Wang"<wansheg at gmail.com>;
> ????: 2009?9?4?(???) ??3:23
> ???: "LLVMdev"<LLVMdev at cs.uiuc.edu>;
> ??: [LLVMdev] Dose I need to build llvm-gcc front-end from  
> sourceresolve this error?
>
> /*
>      mm.cpp
> */
> #include<iostream>
> using namespace std;
> struct  xx{
> int x;
>         int mm()const;
>         int mm();
> };
>
> int xx::mm() const
> {
>         return const_cast<xx*>(this)->mm();
> }
>
> int xx::mm()
> {
>         cout<<"ok"<<endl;
>         return x;
> }
>
> int main()
> {
>         xx x;
>         x.mm();
>         return 0;
> }
>
> / 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *** 
> *********************************************************************/
>
> [ws at localhost dev]$ llvm-c++ --emit-llvm mm.cpp
> In file included from /home/ws/software/llvm-gcc4.2-2.5-x86-linux- 
> RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/ 
> 4.2.1/cstring:52,
>                  from /home/ws/software/llvm-gcc4.2-2.5-x86-linux- 
> RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/ 
> 4.2.1/i686-pc-linux-gnu/bits/c++locale.h:47,
>                  from /home/ws/software/llvm-gcc4.2-2.5-x86-linux- 
> RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/ 
> 4.2.1/iosfwd:45,
>                  from /home/ws/software/llvm-gcc4.2-2.5-x86-linux- 
> RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/ 
> 4.2.1/ios:43,
>                  from /home/ws/software/llvm-gcc4.2-2.5-x86-linux- 
> RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/ 
> 4.2.1/ostream:45,
>                  from /home/ws/software/llvm-gcc4.2-2.5-x86-linux- 
> RHEL4/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/ 
> 4.2.1/iostream:45,
>                  from mm.cpp:1:
> /usr/include/string.h:546: error: ?__locale_t? has not been declar 
> ed
> /usr/include/string.h:547: error: nonnull argument references non- 
> pointer operand (argument 1, operand 3)
> /usr/include/string.h:550: error: ?__locale_t? has not been declar 
> ed
> /usr/include/string.h:551: error: nonnull argument references non- 
> pointer operand (argument 1, operand 4)
>
> In my system , gcc-3.4.6 is used as default gcc tool;
>
> thanks.
>
>
>
>
> _______________________________________________
> 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/20090905/02f1d92d/attachment.html 

From bkorb at gnu.org  Sat Sep  5 13:37:50 2009
From: bkorb at gnu.org (Bruce Korb)
Date: Sat, 5 Sep 2009 11:37:50 -0700
Subject: [LLVMdev] Fwd: omission: clang-cc -MD -MF -c -fPIC
In-Reply-To: <668c430c0909051136y1627b0b8r5504854af057e7ec@mail.gmail.com>
References: <668c430c0909051136y1627b0b8r5504854af057e7ec@mail.gmail.com>
Message-ID: <668c430c0909051137o4fada9e0se7b47b80fd9704ab@mail.gmail.com>

[retrying send with different email source]

Hi,

I do not really have much direct control over the compile lines any more.
I guess I could code up a wrapper for your wrapper so that the libtool wrapper
would be happy, but could you all consider libtool built projects and
embed the necessary option stripping in your clang-cc thing?
Thank you.
Regards, Bruce

make[2]: Entering directory `/home/bkorb/ag/ag/snprintfv'
/bin/sh ../libtool --tag=CC ? --mode=compile clang-cc -DHAVE_CONFIG_H
-I. -I.. -I.. ? ?-g -MT snv.lo -MD -MP -MF .deps/snv.Tpo -c -o snv.lo
snv.c
libtool: compile: ?clang-cc -DHAVE_CONFIG_H -I. -I.. -I.. -g -MT
snv.lo -MD -MP -MF .deps/snv.Tpo -c snv.c ?-fPIC -DPIC -o .libs/snv.o
clang-cc: Unknown command line argument '-MD'. ?Try: 'clang-cc --help'
clang-cc: Unknown command line argument '-MF'. ?Try: 'clang-cc --help'
clang-cc: Unknown command line argument '-c'. ?Try: 'clang-cc --help'
clang-cc: Unknown command line argument '-fPIC'. ?Try: 'clang-cc --help'

On Sat, Sep 5, 2009 at 10:48 AM, Bruce Korb <bruce.korb at gmail.com> wrote:
> make[2]: Entering directory `/home/bkorb/ag/ag/snprintfv'
> /bin/sh ../libtool --tag=CC ? --mode=compile /home/bkorb/tools/clang/llvm/Debug/bin/clang-cc -DHAVE_CONFIG_H -I. -I.. -I.. ? ?-g -Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -fno-strict-aliasing -MT snv.lo -MD -MP -MF .deps/snv.Tpo -c -o snv.lo snv.c
> libtool: compile: ?/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc -DHAVE_CONFIG_H -I. -I.. -I.. -g -Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -fno-strict-aliasing -MT snv.lo -MD -MP -MF .deps/snv.Tpo -c snv.c ?-fPIC -DPIC -o .libs/snv.o
> clang-cc: Unknown command line argument '-fno-strict-aliasing'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> clang-cc: Unknown command line argument '-MD'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> clang-cc: Unknown command line argument '-MF'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> clang-cc: Unknown command line argument '-c'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> clang-cc: Unknown command line argument '-fPIC'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> make[2]: *** [snv.lo] Error 1
> make[2]: Leaving directory `/home/bkorb/ag/ag/snprintfv'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/bkorb/ag/ag'
> make: *** [all] Error 2
>


From sanjiv.gupta at microchip.com  Sat Sep  5 13:46:35 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Sun, 06 Sep 2009 00:16:35 +0530
Subject: [LLVMdev] tblgen bug in handling case , switch_on
Message-ID: <4AA2B20B.1030903@microchip.com>

Hi Mikhail,

What is mentioned in the reference manual is this:

    // Evaluates to "cmdline1" if the option "-A" is provided on the
    // command line; to "cmdline2" if "-B" is provided;
    // otherwise to "cmdline3".
  
   (case
        (switch_on "A"), "cmdline1",
        (switch_on "B"), "cmdline2",
        (default), "cmdline3")
 

What is generated is this:

     if (A) {
       ...
     }
   
     if (B) {
       ....
     } else {
       ....
     }

   
IMO, What should be generated is below:

     if (A) {
       ...
     } else if (B) {
       ....
     } else {
       ....
     }

BTW, to give you more details, I am using append_cmd on each switch_on.


- Sanjiv


From sanjiv.gupta at microchip.com  Sat Sep  5 14:12:42 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Sun, 06 Sep 2009 00:42:42 +0530
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <4AA2B20B.1030903@microchip.com>
References: <4AA2B20B.1030903@microchip.com>
Message-ID: <4AA2B82A.3070105@microchip.com>

Sanjiv Gupta wrote:
> Hi Mikhail,
>
> What is mentioned in the reference manual is this:
>
>     // Evaluates to "cmdline1" if the option "-A" is provided on the
>     // command line; to "cmdline2" if "-B" is provided;
>     // otherwise to "cmdline3".
>   
>    (case
>         (switch_on "A"), "cmdline1",
>         (switch_on "B"), "cmdline2",
>         (default), "cmdline3")
>  
>
> What is generated is this:
>
>      if (A) {
>        ...
>      }
>    
>      if (B) {
>        ....
>      } else {
>        ....
>      }
>
>    
> IMO, What should be generated is below:
>
>      if (A) {
>        ...
>      } else if (B) {
>        ....
>      } else {
>        ....
>      }
>
> BTW, to give you more details, I am using append_cmd on each switch_on.
>
>
> - Sanjiv
>
> _______________________________________________
>   
Is the patch below ok?

Index: LLVMCConfigurationEmitter.cpp
===================================================================
--- LLVMCConfigurationEmitter.cpp    (revision 80668)
+++ LLVMCConfigurationEmitter.cpp    (working copy)
@@ -1141,6 +1141,7 @@
                                Callback, EmitElseIf, OptDescs, O);
     }
     else {
+      EmitElseIf = true;
       Callback(arg, (std::string(IndentLevel) + Indent1).c_str(), O);
     }
     O << IndentLevel << "}\n";

- Sanjiv

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


From bkorb at gnu.org  Sat Sep  5 14:19:07 2009
From: bkorb at gnu.org (Bruce Korb)
Date: Sat, 5 Sep 2009 12:19:07 -0700
Subject: [LLVMdev] code analysis bug
Message-ID: <668c430c0909051219u27fb44abxaaa357bcafd01a10@mail.gmail.com>

In file included from libopts.c:23:
./makeshell.c:138:26: warning: more '%' conversions than data
arguments
"unset OPT_ARG_VAL || :\n%2$s";

This is not correct.  The format below uses the first argument twice and the
second argument once.  The "clang" analysis does not properly recognize
the "1$" and "2$" modifiers.  This is POSIX for a while, intended for I18N,
but perfectly usable for other purposes.  Like generating shell code.

static char const zLoopEnd[] =
"    if [ -n \"${OPT_ARG_VAL}\" ]\n"
"    then\n"
"        eval %1$s_${OPT_NAME}${OPT_ELEMENT}=\"'${OPT_ARG_VAL}'\"\n"
"        export %1$s_${OPT_NAME}${OPT_ELEMENT}\n"
"    fi\n"
"done\n\n"
"unset OPT_PROCESS || :\n"
"unset OPT_ELEMENT || :\n"
"unset OPT_ARG || :\n"
"unset OPT_ARG_NEEDED || :\n"
"unset OPT_NAME || :\n"
"unset OPT_CODE || :\n"
"unset OPT_ARG_VAL || :\n%2$s";

From vargaz at gmail.com  Sat Sep  5 14:19:23 2009
From: vargaz at gmail.com (Zoltan Varga)
Date: Sat, 5 Sep 2009 21:19:23 +0200
Subject: [LLVMdev] loads from a null address and optimizations
Message-ID: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>

                Hi,

  Currently, llvm treats the loads from a null address as unreachable code,
i.e.:
     load i32* null
is transformed by some optimization pass into
    unreachable

This presents problems in JIT compilers like mono which implement null
pointer checks by trapping SIGSEGV signals. It also
looks incorrect since it changes program behavior, which might be undefined
in general, but it is quite well defined on unix.
Is there a way to prevent llvm from doing this besides marking all loads as
volatile ?

                          thanks

                              Zoltan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090905/3cb32915/attachment.html 

From bkorb at gnu.org  Sat Sep  5 14:24:11 2009
From: bkorb at gnu.org (Bruce Korb)
Date: Sat, 5 Sep 2009 12:24:11 -0700
Subject: [LLVMdev] code analysis bug
In-Reply-To: <668c430c0909051219u27fb44abxaaa357bcafd01a10@mail.gmail.com>
References: <668c430c0909051219u27fb44abxaaa357bcafd01a10@mail.gmail.com>
Message-ID: <668c430c0909051224r619e30b3ra5a85fcaa3c85030@mail.gmail.com>

In file included from ag.c:34:
./tpProcess.c:117:31: warning: format string is not a string literal
      (potentially insecure)
            fprintf( pfTrace, zBadR+2 );

This is another analytical bug.  "zBadR" is, in fact, a string literal.
I am writing from the second byte.  I ought to have used fputs()
instead, and will, but meanwhile, this is a bug.  Here is the usage
and the two bytes skipped happen to be "%s":

        if (*pzOopsPrefix != NUL) {
            fprintf( stdout, zBadR, pzOopsPrefix );
            pzOopsPrefix = zNil;
        } else {
            fprintf( pfTrace, zBadR+2 );
        }

on second thought, I'll replace all that with just the first fprintf.
There's still an analysis bug.  Thank you!  Regards, Bruce

From nicholas at mxc.ca  Sat Sep  5 14:30:37 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 05 Sep 2009 12:30:37 -0700
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
Message-ID: <4AA2BC5D.7090402@mxc.ca>

Zoltan Varga wrote:
> 
>                 Hi,
> 
>   Currently, llvm treats the loads from a null address as unreachable 
> code, i.e.:
>      load i32* null
> is transformed by some optimization pass into
>     unreachable
> 
> This presents problems in JIT compilers like mono which implement null 
> pointer checks by trapping SIGSEGV signals. It also
> looks incorrect since it changes program behavior, which might be 
> undefined in general, but it is quite well defined on unix.
> Is there a way to prevent llvm from doing this besides marking all loads 
> as volatile ?

The other way is to use a custom (ie., non-zero) address space for your 
pointers. I'm not sure what the backend will do with these, but the 
optimizers know not to treat load/store from null as special in 
alternate address spaces. You may have to teach the backend to ignore 
your addrspace though.

Nick

From the.dead.shall.rise at gmail.com  Sat Sep  5 15:32:12 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sat, 5 Sep 2009 22:32:12 +0200
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <4AA2B82A.3070105@microchip.com>
References: <4AA2B20B.1030903@microchip.com> <4AA2B82A.3070105@microchip.com>
Message-ID: <3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>

Hi,

On Sat, Sep 5, 2009 at 9:12 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote:
> Is the patch below ok?
>
> Index: LLVMCConfigurationEmitter.cpp
> ===================================================================
> --- LLVMCConfigurationEmitter.cpp ? ?(revision 80668)
> +++ LLVMCConfigurationEmitter.cpp ? ?(working copy)
> @@ -1141,6 +1141,7 @@
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Callback, EmitElseIf, OptDescs, O);
> ? ?}
> ? ?else {
> + ? ? ?EmitElseIf = true;
> ? ? ?Callback(arg, (std::string(IndentLevel) + Indent1).c_str(), O);
> ? ?}
> ? ?O << IndentLevel << "}\n";

No, this is not OK - EmitCaseConstructHandler is supposed to be able
to generate both 'if (...) ... if (...) ... if (...) ...' and 'if
(...) ... else if (...) ... else ...' forms. That's what the
EmitElseIf argument controls.

BTW, the example in the documentation generates the 'if (...) ... else
if (...) ... else ...'  form since the 'case' there is assumed to be
inside the 'cmd_line' property.

Can you provide a small TableGen code example of what you're trying to
do which is not working?

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


From eli.friedman at gmail.com  Sat Sep  5 15:34:02 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sat, 5 Sep 2009 13:34:02 -0700
Subject: [LLVMdev] Fwd: omission: clang-cc -MD -MF -c -fPIC
In-Reply-To: <668c430c0909051137o4fada9e0se7b47b80fd9704ab@mail.gmail.com>
References: <668c430c0909051136y1627b0b8r5504854af057e7ec@mail.gmail.com>
	<668c430c0909051137o4fada9e0se7b47b80fd9704ab@mail.gmail.com>
Message-ID: <f5aa3e9b0909051334y342efc7aq6fe3215526807fd7@mail.gmail.com>

On Sat, Sep 5, 2009 at 11:37 AM, Bruce Korb<bkorb at gnu.org> wrote:
> [retrying send with different email source]
>
> Hi,
>
> I do not really have much direct control over the compile lines any more.
> I guess I could code up a wrapper for your wrapper so that the libtool wrapper
> would be happy, but could you all consider libtool built projects and
> embed the necessary option stripping in your clang-cc thing?
> Thank you.
> Regards, Bruce
>
> make[2]: Entering directory `/home/bkorb/ag/ag/snprintfv'
> /bin/sh ../libtool --tag=CC ? --mode=compile clang-cc -DHAVE_CONFIG_H
> -I. -I.. -I.. ? ?-g -MT snv.lo -MD -MP -MF .deps/snv.Tpo -c -o snv.lo
> snv.c

I'm not sure how this conversation started, but you should probably be
using "clang" rather than "clang-cc" directly.

If you have more questions, it would probably be better to discuss on cfe-dev.

-Eli


From eli.friedman at gmail.com  Sat Sep  5 15:36:19 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sat, 5 Sep 2009 13:36:19 -0700
Subject: [LLVMdev] code analysis bug
In-Reply-To: <668c430c0909051219u27fb44abxaaa357bcafd01a10@mail.gmail.com>
References: <668c430c0909051219u27fb44abxaaa357bcafd01a10@mail.gmail.com>
Message-ID: <f5aa3e9b0909051336v7ec95fd5o4dc21ca0de38c0f6@mail.gmail.com>

On Sat, Sep 5, 2009 at 12:19 PM, Bruce Korb<bkorb at gnu.org> wrote:
> In file included from libopts.c:23:
> ./makeshell.c:138:26: warning: more '%' conversions than data
> arguments
> "unset OPT_ARG_VAL || :\n%2$s";
>
> This is not correct. ?The format below uses the first argument twice and the
> second argument once. ?The "clang" analysis does not properly recognize
> the "1$" and "2$" modifiers. ?This is POSIX for a while, intended for I18N,
> but perfectly usable for other purposes. ?Like generating shell code.

Please file at llvm.org/bugs/ in the clang component with a simple testcase.

-Eli


From nicholas at mxc.ca  Sat Sep  5 15:53:52 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 05 Sep 2009 13:53:52 -0700
Subject: [LLVMdev] should we stop using llvm-as/llvm-dis in tests?
Message-ID: <4AA2CFE0.3050009@mxc.ca>

A recent commit added the ability to opt and llc to read .ll files 
directly. Should we go through and update the existing tests?

   llvm-as < %s | opt ... | llvm-dis

would become:

   opt %s ... -print-module

and

   llvm-as < %s | llc

would become:

   llc < %s

The pro of this is that it would remove the bitcode write and read from 
the tests, making them faster. The con of this is that it would remove 
the bitcode write and read from the tests, making them less well tested.

Should we not make this change at all? Should we create some sort of 
'exhaustive bitcode tests' first, and require that new language features 
are added there? Or should we just do it and create "llvm-as < %s | 
llvm-dis" tests under test/Bitcode as problems are found?

Also, has anyone else already started doing this?

Nick

From isanbard at gmail.com  Sat Sep  5 16:39:17 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sat, 5 Sep 2009 16:39:17 -0500
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
Message-ID: <272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>

Hi Zoltan,

We've come across this before where people meant to induce a trap by  
dereferencing a null. It doesn't work for LLVM (as you found out).  
Essentially, it's a valid transformation to turn this into  
unreachable. The better solution is to use something like  
__builtin_trap.

-bw

On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote:

>
>                 Hi,
>
>   Currently, llvm treats the loads from a null address as  
> unreachable code, i.e.:
>      load i32* null
> is transformed by some optimization pass into
>     unreachable
>
> This presents problems in JIT compilers like mono which implement  
> null pointer checks by trapping SIGSEGV signals. It also
> looks incorrect since it changes program behavior, which might be  
> undefined in general, but it is quite well defined on unix.
> Is there a way to prevent llvm from doing this besides marking all  
> loads as volatile ?
>
>                           thanks
>
>                               Zoltan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From vargaz at gmail.com  Sat Sep  5 16:59:33 2009
From: vargaz at gmail.com (Zoltan Varga)
Date: Sat, 5 Sep 2009 23:59:33 +0200
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
Message-ID: <295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>

Hi,

  I don't intentionally want to induce a tramp, the load null is created by
an llvm optimization
pass from code like:
   v = null;
   .....
   v.Call ();

            Zoltan

On Sat, Sep 5, 2009 at 11:39 PM, Bill Wendling <isanbard at gmail.com> wrote:

> Hi Zoltan,
>
> We've come across this before where people meant to induce a trap by
> dereferencing a null. It doesn't work for LLVM (as you found out).
> Essentially, it's a valid transformation to turn this into unreachable. The
> better solution is to use something like __builtin_trap.
>
> -bw
>
>
> On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>
>
>>                Hi,
>>
>>  Currently, llvm treats the loads from a null address as unreachable code,
>> i.e.:
>>     load i32* null
>> is transformed by some optimization pass into
>>    unreachable
>>
>> This presents problems in JIT compilers like mono which implement null
>> pointer checks by trapping SIGSEGV signals. It also
>> looks incorrect since it changes program behavior, which might be
>> undefined in general, but it is quite well defined on unix.
>> Is there a way to prevent llvm from doing this besides marking all loads
>> as volatile ?
>>
>>                          thanks
>>
>>                              Zoltan
>>
>> _______________________________________________
>> 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/20090905/31ae64a0/attachment.html 

From rjmccall at apple.com  Sat Sep  5 17:48:46 2009
From: rjmccall at apple.com (John McCall)
Date: Sat, 05 Sep 2009 15:48:46 -0700
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
Message-ID: <4AA2EACE.4010406@apple.com>

Zoltan Varga wrote:
> Hi,
>
>   I don't intentionally want to induce a tramp, the load null is 
> created by an llvm optimization
> pass from code like:
>    v = null;
>    .....
>    v.Call ();

This is more of a workaround than a solution, but have you tried 
emitting null as inttoptr(0) instead of a ConstantPointerNull?  That 
should disable optimizations relying on C-like undefined behavior 
semantics, at least as long as there isn't some pass which recognizes 
that pattern and turns it back into null.

John.

From isanbard at gmail.com  Sat Sep  5 19:26:02 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sat, 5 Sep 2009 19:26:02 -0500
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
Message-ID: <C9B778DF-3C5F-45D2-A4DC-A035A1DD0B5D@gmail.com>

It's essentially the sane thing. :-) I don't quite understand the  
code. Is 'v' ever assigned a value before 'v.Call()'?

Two options remain, from what I can see. Either mark v as volatile, or  
compile without optimizations. The second is more drastic.

If you *really* want it to perform a call on null. Then you could  
place a function in another module that only returns null, then do the  
call:

// module A
typedef void (*func)();

func Foo() { return 0; }

// module B

Foo().Call();

And then make sure you don't perform LTO.

-bw

On Sep 5, 2009, at 4:59 PM, Zoltan Varga <vargaz at gmail.com> wrote:

> Hi,
>
>   I don't intentionally want to induce a tramp, the load null is  
> created by an llvm optimization
> pass from code like:
>    v = null;
>    .....
>    v.Call ();
>
>             Zoltan
>
> On Sat, Sep 5, 2009 at 11:39 PM, Bill Wendling <isanbard at gmail.com>  
> wrote:
> Hi Zoltan,
>
> We've come across this before where people meant to induce a trap by  
> dereferencing a null. It doesn't work for LLVM (as you found out).  
> Essentially, it's a valid transformation to turn this into  
> unreachable. The better solution is to use something like  
> __builtin_trap.
>
> -bw
>
>
> On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>
>
>                Hi,
>
>  Currently, llvm treats the loads from a null address as unreachable  
> code, i.e.:
>     load i32* null
> is transformed by some optimization pass into
>    unreachable
>
> This presents problems in JIT compilers like mono which implement  
> null pointer checks by trapping SIGSEGV signals. It also
> looks incorrect since it changes program behavior, which might be  
> undefined in general, but it is quite well defined on unix.
> Is there a way to prevent llvm from doing this besides marking all  
> loads as volatile ?
>
>                          thanks
>
>                              Zoltan
>
> _______________________________________________
> 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/20090905/91978212/attachment.html 

From bruce.korb at gmail.com  Sat Sep  5 13:36:11 2009
From: bruce.korb at gmail.com (Bruce Korb)
Date: Sat, 5 Sep 2009 11:36:11 -0700
Subject: [LLVMdev] omission: clang-cc -MD -MF -c -fPIC
Message-ID: <668c430c0909051136y1627b0b8r5504854af057e7ec@mail.gmail.com>

Hi,

I do not really have much direct control over the compile lines any more.
I guess I could code up a wrapper for your wrapper so that the libtool wrapper
would be happy, but could you all consider libtool built projects and
embed the necessary option stripping in your clang-cc thing?
Thank you.
Regards, Bruce

make[2]: Entering directory `/home/bkorb/ag/ag/snprintfv'
/bin/sh ../libtool --tag=CC   --mode=compile clang-cc -DHAVE_CONFIG_H
-I. -I.. -I..    -g -MT snv.lo -MD -MP -MF .deps/snv.Tpo -c -o snv.lo
snv.c
libtool: compile:  clang-cc -DHAVE_CONFIG_H -I. -I.. -I.. -g -MT
snv.lo -MD -MP -MF .deps/snv.Tpo -c snv.c  -fPIC -DPIC -o .libs/snv.o
clang-cc: Unknown command line argument '-MD'.  Try: 'clang-cc --help'
clang-cc: Unknown command line argument '-MF'.  Try: 'clang-cc --help'
clang-cc: Unknown command line argument '-c'.  Try: 'clang-cc --help'
clang-cc: Unknown command line argument '-fPIC'.  Try: 'clang-cc --help'

On Sat, Sep 5, 2009 at 10:48 AM, Bruce Korb <bruce.korb at gmail.com> wrote:
> make[2]: Entering directory `/home/bkorb/ag/ag/snprintfv'
> /bin/sh ../libtool --tag=CC ? --mode=compile /home/bkorb/tools/clang/llvm/Debug/bin/clang-cc -DHAVE_CONFIG_H -I. -I.. -I.. ? ?-g -Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -fno-strict-aliasing -MT snv.lo -MD -MP -MF .deps/snv.Tpo -c -o snv.lo snv.c
> libtool: compile: ?/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc -DHAVE_CONFIG_H -I. -I.. -I.. -g -Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -fno-strict-aliasing -MT snv.lo -MD -MP -MF .deps/snv.Tpo -c snv.c ?-fPIC -DPIC -o .libs/snv.o
> clang-cc: Unknown command line argument '-fno-strict-aliasing'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> clang-cc: Unknown command line argument '-MD'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> clang-cc: Unknown command line argument '-MF'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> clang-cc: Unknown command line argument '-c'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> clang-cc: Unknown command line argument '-fPIC'. ?Try: '/home/bkorb/tools/clang/llvm/Debug/bin/clang-cc --help'
> make[2]: *** [snv.lo] Error 1
> make[2]: Leaving directory `/home/bkorb/ag/ag/snprintfv'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/bkorb/ag/ag'
> make: *** [all] Error 2
>


From clattner at apple.com  Sat Sep  5 19:51:00 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 5 Sep 2009 17:51:00 -0700
Subject: [LLVMdev] should we stop using llvm-as/llvm-dis in tests?
In-Reply-To: <4AA2CFE0.3050009@mxc.ca>
References: <4AA2CFE0.3050009@mxc.ca>
Message-ID: <6CECD6A3-C8BC-48C0-9E81-F6360EE5690C@apple.com>


On Sep 5, 2009, at 1:53 PM, Nick Lewycky wrote:

> A recent commit added the ability to opt and llc to read .ll files
> directly. Should we go through and update the existing tests?

Yes, I think that Dan is planning to do this.

-Chris

>
>   llvm-as < %s | opt ... | llvm-dis
>
> would become:
>
>   opt %s ... -print-module
>
> and
>
>   llvm-as < %s | llc
>
> would become:
>
>   llc < %s
>
> The pro of this is that it would remove the bitcode write and read  
> from
> the tests, making them faster. The con of this is that it would remove
> the bitcode write and read from the tests, making them less well  
> tested.
>
> Should we not make this change at all? Should we create some sort of
> 'exhaustive bitcode tests' first, and require that new language  
> features
> are added there? Or should we just do it and create "llvm-as < %s |
> llvm-dis" tests under test/Bitcode as problems are found?
>
> Also, has anyone else already started doing this?
>
> Nick
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From daniel at zuster.org  Sat Sep  5 20:40:44 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 5 Sep 2009 18:40:44 -0700
Subject: [LLVMdev] should we stop using llvm-as/llvm-dis in tests?
In-Reply-To: <6CECD6A3-C8BC-48C0-9E81-F6360EE5690C@apple.com>
References: <4AA2CFE0.3050009@mxc.ca>
	<6CECD6A3-C8BC-48C0-9E81-F6360EE5690C@apple.com>
Message-ID: <6a8523d60909051840t7da5e2c4ua2cac6c59f56f2ed@mail.gmail.com>

On Sat, Sep 5, 2009 at 5:51 PM, Chris Lattner<clattner at apple.com> wrote:
>
> On Sep 5, 2009, at 1:53 PM, Nick Lewycky wrote:
>
>> A recent commit added the ability to opt and llc to read .ll files
>> directly. Should we go through and update the existing tests?
>
> Yes, I think that Dan is planning to do this.

... and it is definitely worth doing. On my system a 'time' of make
check reports that about 50% of the real time running make check is
spent in the OS. This probably also limits the efficacy of attempts to
parallelize the test suite, if someone was crazy enough to do that.

Using opt -S for tests that end up going to llvm-dis would also be nice.

 - Daniel

From ofv at wanadoo.es  Sat Sep  5 21:05:33 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Sun, 06 Sep 2009 04:05:33 +0200
Subject: [LLVMdev] should we stop using llvm-as/llvm-dis in tests?
References: <4AA2CFE0.3050009@mxc.ca>
	<6CECD6A3-C8BC-48C0-9E81-F6360EE5690C@apple.com>
	<6a8523d60909051840t7da5e2c4ua2cac6c59f56f2ed@mail.gmail.com>
Message-ID: <87d464akuq.fsf@telefonica.net>

Daniel Dunbar <daniel at zuster.org> writes:

>>> A recent commit added the ability to opt and llc to read .ll files
>>> directly. Should we go through and update the existing tests?
>>
>> Yes, I think that Dan is planning to do this.
>
> ... and it is definitely worth doing. On my system a 'time' of make
> check reports that about 50% of the real time running make check is
> spent in the OS. This probably also limits the efficacy of attempts to
> parallelize the test suite, if someone was crazy enough to do that.

Why would be crazy to run the test suite on parallel? Because DejaGNU
limitations?

My compiler's test suite is driven by a poor-man's version of DejaGNU
(also written on Tcl, but not requiring Expect) that supports parallel
runs (with a -j command-line parameter, ? la make) and works on Linux
and Windows.

Since long time ago I'm thinking on expanding its functionality for
accepting DejaGNU test cases and add it to the cmake build, but I'm
afraid of corner cases. You know, the 99% of the complexity on the 1% of
the instances.

Would you consider parallel runs and Windows support enough motivation
for rewriting those (hypothetical) corner cases as equivalent but
simpler ones?

-- 
?scar


From daniel at zuster.org  Sat Sep  5 21:19:14 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 5 Sep 2009 19:19:14 -0700
Subject: [LLVMdev] TOT opt does not terminate!
In-Reply-To: <f5aa3e9b0909050226m2d6de935pa9be2789e25adb3c@mail.gmail.com>
References: <14DD0B1CD80F5C46841ED44E4CC2CAA330494C@seurexmb2.amd.com>
	<f5aa3e9b0909050226m2d6de935pa9be2789e25adb3c@mail.gmail.com>
Message-ID: <6a8523d60909051919t3d24bab8m902eb7fff2abe86d@mail.gmail.com>

I minimized and filed as http://llvm.org/bugs/show_bug.cgi?id=4908

 - Daniel

On Sat, Sep 5, 2009 at 2:26 AM, Eli Friedman<eli.friedman at gmail.com> wrote:
> On Fri, Sep 4, 2009 at 9:37 AM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote:
>> The following code causes opt to not terminate!
>
> Please flle in bugzilla with a bitcode testcase; it would help to
> reduce the testcase using bugpoint.
>
> -Eli
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From daniel at zuster.org  Sat Sep  5 21:24:10 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 5 Sep 2009 19:24:10 -0700
Subject: [LLVMdev] should we stop using llvm-as/llvm-dis in tests?
In-Reply-To: <87d464akuq.fsf@telefonica.net>
References: <4AA2CFE0.3050009@mxc.ca>
	<6CECD6A3-C8BC-48C0-9E81-F6360EE5690C@apple.com>
	<6a8523d60909051840t7da5e2c4ua2cac6c59f56f2ed@mail.gmail.com>
	<87d464akuq.fsf@telefonica.net>
Message-ID: <6a8523d60909051924u6b385ffcq91f8081fffb415f3@mail.gmail.com>

On Sat, Sep 5, 2009 at 7:05 PM, ?scar Fuentes<ofv at wanadoo.es> wrote:
> Daniel Dunbar <daniel at zuster.org> writes:
>> ... and it is definitely worth doing. On my system a 'time' of make
>> check reports that about 50% of the real time running make check is
>> spent in the OS. This probably also limits the efficacy of attempts to
>> parallelize the test suite, if someone was crazy enough to do that.
>
> Why would be crazy to run the test suite on parallel? Because DejaGNU
> limitations?

It was a joke, I'm actively working on this. Stay tuned. :)

 - Daniel


From kennethuil at gmail.com  Sat Sep  5 21:34:59 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sat, 5 Sep 2009 21:34:59 -0500
Subject: [LLVMdev] llc crash when a const struct includes a zero-length
	member
Message-ID: <400d33ea0909051934k73077770jd3a9da5fcf054c94@mail.gmail.com>

When I run llc on the (assembled version of) the following code on Linux x86:

%testType = type {i32, [0 x i32], i32}

define i32 @main() {
  %1 = alloca %testType

  store %testType {i32 1, [0 x i32] zeroinitializer, i32 2}, %testType* %1
  ret i32 0
}

llc crashes with a segmentation fault.  It happens in the 2.5 release
version and in the version I pulled from svn trunk about two hours
ago.

The trouble starts in SelectionDAGLowering::getValue(const Value* V),
within the if (isa<ConstantStruct>(C) || isa<ConstantArray>(C)) check,
where the zero-length member (which can be either a zero-length array
or an empty struct) causes getValue(*OI).getNode() to return NULL.
The segfault occurs when this null pointer is used as the instance
pointer for SDNode::getNumValues().  It doesn't matter whether the
zero-length member appears at the beginning, the end, or somewhere in
the middle.

A simple null check on the result of getValue(*OI).getNode() clears up
the segfault and makes my larger test program run properly after
llc'ing and assembling (not surprising, since leaving out the
zero-length member leaves the result of the store unchanged).  The
attached patch applied to the svn trunk snapshot should do the trick.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mypatch
Type: application/octet-stream
Size: 843 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090905/ed1a0333/attachment.obj 

From nicholas at mxc.ca  Sun Sep  6 03:09:32 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sun, 06 Sep 2009 01:09:32 -0700
Subject: [LLVMdev] Non-local DSE optimization
In-Reply-To: <273A970E-E76D-4BC0-8EF0-64E9C391DA6F@gcc.gnu.org>
References: <830819AC-2A14-435D-86FE-CB09F73F31F6@gcc.gnu.org>	<4A9F86F4.3070609@free.fr>
	<273A970E-E76D-4BC0-8EF0-64E9C391DA6F@gcc.gnu.org>
Message-ID: <4AA36E3C.7070507@mxc.ca>

Jakub Staszak wrote:
> Hi,
> 
> It looks like PDT.getRootNode() returns NULL for:
> 
> define fastcc void @c974001__lengthy_calculation. 
> 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn {
> entry:
>    br label %bb
> 
> bb:
>    br label %bb
> }
> 
> 
> Isn't it a bug in PostDominatorTree?
> 
> Please note that this crashes:
> opt -postdomtree -debug dom_crash.bc
> 
> I think this should be reported as a bug,

Yes, that's a bug. Please file it.

The PDT root calculation is looking for all BBs with no successors, this 
won't work in the face of loops. Either we need to teach PDT users that 
there can be zero roots, or we need to synthesize a fake root.

The latter is already supported (to handle multiple exits) so that's 
probably the easiest fix.

Nick

> -Jakub
> 
> 
> 
> On Sep 3, 2009, at 7:05 AM, Duncan Sands wrote:
> 
>> Hi Jakub, interesting patch.  I ran it over the Ada testsuite and this
>> picked up some problems even without enabling dse-ssu.  For example,
>> "opt -inline -dse -domtree" crashes on the attached testcase.
>>
>> Ciao,
>>
>> Duncan.
>> ; ModuleID = 'dom_crash.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"
>>
>> %struct.FRAME.c974001 = type { i32, i8, void  
>> (%struct.c974001__timed_calculation*)* }
>> %struct.FRAME.c974001__timed_calculationB = type  
>> { %struct.FRAME.c974001*, i32 }
>> %struct.FRAME.c974001__timed_calculation__calculationA = type  
>> { %struct.system__tasking__async_delays__delay_block }
>> %struct.RETURN = type { i32, i32 }
>> %struct.ada__exceptions__exception_occurrence = type  
>> { %struct.system__standard_library__exception_data*, i32, [200 x  
>> i8], i8, i8, i32, i32, [50 x i32], i32 }
>> %struct.c974001__timed_calculation = type  
>> { %struct.system__tasking__ada_task_control_block* }
>> %struct.system__os_interface__pthread_mutex_t = type { i32, i32,  
>> i32, i32, %struct.RETURN }
>> %struct.system__soft_links__tsd = type  
>> { %struct.system__stack_checking__stack_info, i32, i32,  
>> %struct.ada__exceptions__exception_occurrence }
>> %struct.system__stack_checking__stack_info = type { i32, i32, i32 }
>> %struct.system__stack_usage__stack_analyzer = type { [32 x i8], i32,  
>> i32, i32, i32, i32, i32, i32, i8, i32 }
>> %struct.system__standard_library__exception_data = type { i8, i8,  
>> i32, i32, %struct.system__standard_library__exception_data*, i32,  
>> void ()* }
>> %struct.system__task_primitives__private_data = type { i32, i32, [48  
>> x i8], %struct.system__os_interface__pthread_mutex_t }
>> %struct.system__tasking__accept_alternative = type { i8, i32 }
>> %struct.system__tasking__accept_list_access = type { [0 x  
>> %struct.system__tasking__accept_alternative]*, %struct.RETURN* }
>> %struct.system__tasking__ada_task_control_block = type { i32,  
>> %struct.system__tasking__common_atcb, [19 x  
>> %struct.system__tasking__entry_call_record], i32,  
>> %struct.system__tasking__accept_list_access, i32, i32, i32, i32,  
>> i32, i8, i8, i8, i8, i8, i8, i8, i8, i32, i32, i32, i64, i32, i32,  
>> [4 x i32], i8, i32*, [0 x %struct.system__tasking__entry_queue] }
>> %struct.system__tasking__async_delays__delay_block = type  
>> { %struct.system__tasking__ada_task_control_block*, i32, i64, i8,  
>> %struct.system__tasking__async_delays__delay_block*,  
>> %struct.system__tasking__async_delays__delay_block* }
>> %struct.system__tasking__common_atcb = type { i8,  
>> %struct.system__tasking__ada_task_control_block*, i32, i32, i32, [32  
>> x i8], i32, %struct.system__tasking__entry_call_record*,  
>> %struct.system__task_primitives__private_data, i32, void (i32)*,  
>> %struct.system__soft_links__tsd,  
>> %struct.system__tasking__ada_task_control_block*,  
>> %struct.system__tasking__ada_task_control_block*,  
>> %struct.system__tasking__ada_task_control_block*, i32, i8*, i8, i8,  
>> %struct.system__stack_usage__stack_analyzer, i32,  
>> %struct.system__tasking__termination_handler,  
>> %struct.system__tasking__termination_handler }
>> %struct.system__tasking__entry_call_record = type  
>> { %struct.system__tasking__ada_task_control_block*, i8, i8, i32,  
>> %struct.system__standard_library__exception_data*,  
>> %struct.system__tasking__entry_call_record*,  
>> %struct.system__tasking__entry_call_record*, i32, i32, i32,  
>> %struct.system__tasking__ada_task_control_block*, i32,  
>> %struct.system__tasking__entry_call_record*, i32, i8, i8, i8 }
>> %struct.system__tasking__entry_queue = type  
>> { %struct.system__tasking__entry_call_record*,  
>> %struct.system__tasking__entry_call_record* }
>> %struct.system__tasking__termination_handler = type { i32, void  
>> (i32, i8, %struct.system__tasking__ada_task_control_block*,  
>> %struct.ada__exceptions__exception_occurrence*)* }
>>
>> @C.168.1967 = external constant %struct.RETURN    ; < 
>> %struct.RETURN*> [#uses=1]
>>
>> define void  
>> @system__tasking__activation_chainIP 
>> (%struct.c974001__timed_calculation* nocapture %_init) nounwind {
>> entry:
>>  ret void
>> }
>>
>> define void @_ada_c974001() {
>> entry:
>>  %tramp = call i8* @llvm.init.trampoline(i8* undef, i8* bitcast  
>> (void (%struct.FRAME.c974001*, %struct.c974001__timed_calculation*)*  
>> @c974001__timed_calculationB.1770 to i8*), i8* undef) ; <i8*>  
>> [#uses=0]
>>  unreachable
>> }
>>
>> declare i8* @llvm.init.trampoline(i8*, i8*, i8*) nounwind
>>
>> define fastcc void @c974001__lengthy_calculation. 
>> 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn {
>> entry:
>>  br label %bb
>>
>> bb:                                               ; preds = %bb,  
>> %entry
>>  br label %bb
>> }
>>
>> define fastcc void  
>> @c974001__timed_calculation__calculation__B19b__B21b__A17b___clean. 
>> 1830(%struct.FRAME.c974001__timed_calculation__calculationA* %CHAIN. 
>> 188) {
>> entry:
>>  ret void
>> }
>>
>> define fastcc void @c974001__timed_calculation__calculationA. 
>> 1820(%struct.FRAME.c974001__timed_calculationB* nocapture %CHAIN. 
>> 190) {
>> entry:
>>  br i1 undef, label %bb, label %bb3
>>
>> bb:                                               ; preds = %entry
>>  unreachable
>>
>> bb3:                                              ; preds = %entry
>>  br i1 undef, label %bb4, label %bb5
>>
>> bb4:                                              ; preds = %bb3
>>  unreachable
>>
>> bb5:                                              ; preds = %bb3
>>  invoke void undef()
>>          to label %invcont unwind label %lpad
>>
>> invcont:                                          ; preds = %bb5
>>  %0 = invoke i8 @system__tasking__async_delays__enqueue_duration(i64  
>> undef, %struct.system__tasking__async_delays__delay_block* undef)
>>          to label %bb8 unwind label %lpad        ; <i8> [#uses=0]
>>
>> bb8:                                              ; preds = %invcont
>>  invoke void undef()
>>          to label %invcont9 unwind label %lpad75
>>
>> invcont9:                                         ; preds = %bb8
>>  invoke fastcc void @c974001__lengthy_calculation. 
>> 1736(%struct.FRAME.c974001* undef)
>>          to label %invcont10 unwind label %lpad75
>>
>> invcont10:                                        ; preds = %invcont9
>>  invoke void @report__failed([0 x i8]* undef, %struct.RETURN* @C. 
>> 168.1967)
>>          to label %bb16 unwind label %lpad75
>>
>> bb16:                                             ; preds = %invcont10
>>  invoke fastcc void  
>> @c974001__timed_calculation__calculation__B19b__B21b__A17b___clean. 
>> 1830(%struct.FRAME.c974001__timed_calculation__calculationA* undef)
>>          to label %bb27 unwind label %lpad71
>>
>> bb27:                                             ; preds = %bb16
>>  unreachable
>>
>> lpad:                                             ; preds =  
>> %invcont, %bb5
>>  unreachable
>>
>> lpad71:                                           ; preds = %bb16
>>  unreachable
>>
>> lpad75:                                           ; preds =  
>> %invcont10, %invcont9, %bb8
>>  unreachable
>> }
>>
>> declare i8 @system__tasking__async_delays__enqueue_duration(i64,  
>> %struct.system__tasking__async_delays__delay_block*)
>>
>> declare void @report__failed([0 x i8]*, %struct.RETURN*)
>>
>> define void @c974001__timed_calculationB.1770(%struct.FRAME.c974001*  
>> nest %CHAIN.191, %struct.c974001__timed_calculation* nocapture  
>> %_task) {
>> entry:
>>  invoke void undef()
>>          to label %invcont unwind label %lpad
>>
>> invcont:                                          ; preds = %entry
>>  invoke void @system__tasking__stages__complete_activation()
>>          to label %bb unwind label %lpad
>>
>> bb:                                               ; preds = %bb5,  
>> %invcont4, %invcont
>>  invoke void  
>> @system__tasking__rendezvous__selective_wait(%struct.RETURN* noalias  
>> sret undef, [0 x %struct.system__tasking__accept_alternative]*  
>> undef, %struct.RETURN* undef, i8 2)
>>          to label %invcont4 unwind label %lpad25
>>
>> invcont4:                                         ; preds = %bb
>>  br i1 undef, label %bb5, label %bb
>>
>> bb5:                                              ; preds = %invcont4
>>  invoke fastcc void @c974001__timed_calculation__calculationA. 
>> 1820(%struct.FRAME.c974001__timed_calculationB* undef)
>>          to label %bb unwind label %lpad25
>>
>> bb7:                                              ; preds = %lpad25
>>  unreachable
>>
>> lpad:                                             ; preds =  
>> %invcont, %entry
>>  unreachable
>>
>> lpad25:                                           ; preds = %bb5, %bb
>>  br i1 undef, label %bb7, label %ppad
>>
>> ppad:                                             ; preds = %lpad25
>>  unreachable
>> }
>>
>> declare void @system__tasking__stages__complete_activation()
>>
>> declare void  
>> @system__tasking__rendezvous__selective_wait(%struct.RETURN* noalias  
>> sret, [0 x %struct.system__tasking__accept_alternative]*,  
>> %struct.RETURN*, i8)
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


From cedric.venet at laposte.net  Sun Sep  6 04:37:39 2009
From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=)
Date: Sun, 06 Sep 2009 11:37:39 +0200
Subject: [LLVMdev] [Fwd: Re:  An alternate implementation of exceptions]
Message-ID: <4AA382E3.1050301@laposte.net>


-------------- next part --------------
An embedded message was scrubbed...
From: "Mikael Lyngvig" <mikael at lyngvig.org>
Subject: Re: [LLVMdev] An alternate implementation of exceptions
Date: Sun, 6 Sep 2009 09:53:29 +0200 (CEST)
Size: 6388
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090906/ca20be9e/attachment.eml 

From edwintorok at gmail.com  Sun Sep  6 05:30:07 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Sun, 06 Sep 2009 13:30:07 +0300
Subject: [LLVMdev] [Fwd: Re: An alternate implementation of exceptions]
In-Reply-To: <4AA382E3.1050301@laposte.net>
References: <4AA382E3.1050301@laposte.net>
Message-ID: <4AA38F2F.8010206@gmail.com>

On 2009-09-06 12:37, C?dric Venet wrote:
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [LLVMdev] An alternate implementation of exceptions
> From:
> "Mikael Lyngvig" <mikael at lyngvig.org>
> Date:
> Sun, 6 Sep 2009 09:53:29 +0200 (CEST)
> To:
> C?dric Venet <cedric.venet at laposte.net>
>
> To:
> C?dric Venet <cedric.venet at laposte.net>
>
>
> Hi C?dric,
>
> Do you mind forwarding this email to the list?  I can't seem to find the
> list address anywhere.
>
> Thanks in advance (even if you don't forward it :-).
>
> Cheers,
> Mikael
>
>
>   
>> The last few mail didn't go to the mailing list it seems, it is not the
>> reply to by default...
>>
>> Mikael Lyngvig a ?crit :
>>     
>>> Hi,
>>>
>>> I've been playing around myself for the past few hours.  I got something
>>> like this:
>>>
>>>    1. OpenWatcom C++ v1.8: three times speedup.
>>>    2. Microsoft Visual C++ v9.0: 10 PERCENT speedup.
>>>
>>> I am having trouble linking with GCC - it complains about unresolved
>>> symbols (__cxa_allocate_exception, etc.).
>>>
>>> But it seems that my initial findings, of four to five times speedup,
>>> were
>>> only caused by the fact that I only tried out the OpenWatcom compiler.
>>> Apparently this compiler's exception handling is very slow, which could
>>> probably be guessed from the fact that it explicitly calls setjmp() in
>>> try
>>> blocks and longjmp() in throw statements.
>>>
>>> But, still, this is testing the standard C method of explicitly checking
>>> the return code.  As no compiler generates the stc/ret and jc
>>> instruction
>>>       

Could LLVM codegen use the carry flag for a return of i1?
Actually for a multiple return instruction where one of the returned
values is an i1?

Best regards,
--Edwin

From artjom.kochtchi at googlemail.com  Sun Sep  6 05:51:51 2009
From: artjom.kochtchi at googlemail.com (Artjom Kochtchi)
Date: Sun, 6 Sep 2009 03:51:51 -0700 (PDT)
Subject: [LLVMdev] How to differentiate between external and internal calls
 in llc?
Message-ID: <25316545.post@talk.nabble.com>



I have a MachineFunctionPass plugged into llc during
LLVMTargetMachine::addPreRegAlloc. In this Pass I need to extend calls (i.
e. CALL32m, CALL32r) iff they call function within the program.



CALL32m has, I think, ten different possibilities for the four operands
giving the target address. At the moment I have excluded calls that give the
displacement as GlobalAddress or JumpTableIndex (although I am not sure
whether this is actually right or whether I exclude to many calls this way).



But there appear to be CALL32r instructions that also call locations outside
the program.

Is there any way to determine the location of the call target more
precisely? I tried



for (MachineBasicBlock::succ_iterator SI = BB->succ_begin(), SE =
BB->succ_end(); SI != SE; ++SI) {
	MachineBasicBlock *SBB = *SI;
	if (SBB->getParent()->getFunction()->isDeclaration())
		skip = true;
}


but it seems not to do what I intended.
-- 
View this message in context: http://www.nabble.com/How-to-differentiate-between-external-and-internal-calls-in-llc--tp25316545p25316545.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090906/469a974b/attachment.html 

From kennethuil at gmail.com  Sun Sep  6 06:52:26 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 6 Sep 2009 06:52:26 -0500
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
Message-ID: <400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>

How about this:

1. A custom pass run at the beginning that inserts a null check before
every load/store:

if ( ptr == null )
  trap;

Then if any pointers get optimized to null, the if condition becomes a
constant true,and the trap call should become unconditional.

2. A custom pass at the end that takes out every remaining null check
that your first pass inserted.  It should first check whether the
condition is in fact a constant true (since that reduction might not
have been run after ptr became a constant null) and turn it into an
unconditional trap.

On Sat, Sep 5, 2009 at 4:59 PM, Zoltan Varga<vargaz at gmail.com> wrote:
> Hi,
>
> ? I don't intentionally want to induce a tramp, the load null is created by
> an llvm optimization
> pass from code like:
> ?? v = null;
> ?? .....
> ?? v.Call ();
>
> ??????????? Zoltan
>
> On Sat, Sep 5, 2009 at 11:39 PM, Bill Wendling <isanbard at gmail.com> wrote:
>>
>> Hi Zoltan,
>>
>> We've come across this before where people meant to induce a trap by
>> dereferencing a null. It doesn't work for LLVM (as you found out).
>> Essentially, it's a valid transformation to turn this into unreachable. The
>> better solution is to use something like __builtin_trap.
>>
>> -bw
>>
>> On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>>
>>>
>>> ? ? ? ? ? ? ? ?Hi,
>>>
>>> ?Currently, llvm treats the loads from a null address as unreachable
>>> code, i.e.:
>>> ? ? load i32* null
>>> is transformed by some optimization pass into
>>> ? ?unreachable
>>>
>>> This presents problems in JIT compilers like mono which implement null
>>> pointer checks by trapping SIGSEGV signals. It also
>>> looks incorrect since it changes program behavior, which might be
>>> undefined in general, but it is quite well defined on unix.
>>> Is there a way to prevent llvm from doing this besides marking all loads
>>> as volatile ?
>>>
>>> ? ? ? ? ? ? ? ? ? ? ? ? ?thanks
>>>
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Zoltan
>>>
>>> _______________________________________________
>>> 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 ioannis.nousias at googlemail.com  Sun Sep  6 09:30:36 2009
From: ioannis.nousias at googlemail.com (Ioannis Nousias)
Date: Sun, 06 Sep 2009 15:30:36 +0100
Subject: [LLVMdev] Graphviz and LLVM-TV
In-Reply-To: <1250194639.11328.270.camel@localhost>
References: <4A8437A8.4040606@googlemail.com>	
	<58FA02CE-B68E-466C-9E84-CCF378489A45@apple.com>	
	<25381_1250181387_4A84410B_25381_341_1_4A843C90.4030307@googlemail.com>	
	<1250183964.11328.63.camel@localhost>	
	<25381_1250188295_4A845C07_25381_974_1_4A845C03.3090804@googlemail.com>
	<1250194639.11328.270.camel@localhost>
Message-ID: <4AA3C78C.6010200@googlemail.com>

I've tried to write a DFGPrinter based on the CFGPrinter, as you 
suggested, but encountered problems.

The GraphWriter expects 
GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is 
implemented in CFG.h, a function is a graph of basic blocks. A 
GraphTraits<Function*>  inherits from GraphTraits<BasicBlock*>, and 
implements those nodes_begin()/nodes_end() wrapper functions. Should I 
modify CFG.h and make now BasicBlock a graph of Instruction(s) ?

The DataFlow.h deals with Value and User. Now BasicBlock is derived from 
Value and Instruction from User, but I don't understand how that helps.

It's a bit confusing to be honest. Can you help?

thanks,
Ioannis


Tobias Grosser wrote:
> Hi Ioannis,
>
> On Thu, 2009-08-13 at 19:31 +0100, Ioannis Nousias wrote: 
>   
>> Thanks Tobi for the tip.
>>
>> however I also need the Data-Flow-Graph of each basic block/functions. 
>> As I said, I need a view of how the instructions 'link' to each other 
>> (via registers or memory aliasing or whatnot)
>>     
>
>
> I believe that there is not yet a DOT printer for this kind of
> information.
>
> grep DOTGraphTraits -R *
>
> should give you all data types, for which dot printing is implemented,
> and the data flow does not seem to exist. However there is already a
> graph representation of the data flow information in
> "include/llvm/Support/DataFlow.h":
>
> -------------------------------------------------------------------------
> This file defines specializations of GraphTraits that allows Use-Def and
> Def-Use relations to be treated as proper graphs for generic algorithms.
> -------------------------------------------------------------------------
>
> It should be easy to write the DOTPrinter for this data type. You can
> take the CFGPrinter as reference.
>
> Tobi
>
>
>   


From kennethuil at gmail.com  Sun Sep  6 10:22:33 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 6 Sep 2009 10:22:33 -0500
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
Message-ID: <400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>

On Sun, Sep 6, 2009 at 6:52 AM, Kenneth Uildriks<kennethuil at gmail.com> wrote:
> How about this:
>
> 1. A custom pass run at the beginning that inserts a null check before
> every load/store:
>
> if ( ptr == null )
> ?trap;
>
> Then if any pointers get optimized to null, the if condition becomes a
> constant true,and the trap call should become unconditional.
>
> 2. A custom pass at the end that takes out every remaining null check
> that your first pass inserted. ?It should first check whether the
> condition is in fact a constant true (since that reduction might not
> have been run after ptr became a constant null) and turn it into an
> unconditional trap.

On second thought...

You'd like the program to behave correctly (whatever you mean by that)
whether any optimization passes are run or not.  So have your
front-end emit the null-pointer checks with the explicit trap call,
and then you'll only need the pass at the end to take them out; but
leaving them in will still have your program behaving correctly,
although running a bit slower.


From edwintorok at gmail.com  Sun Sep  6 10:41:40 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Sun, 06 Sep 2009 18:41:40 +0300
Subject: [LLVMdev] Graphviz and LLVM-TV
In-Reply-To: <4AA3C78C.6010200@googlemail.com>
References: <4A8437A8.4040606@googlemail.com>		<58FA02CE-B68E-466C-9E84-CCF378489A45@apple.com>		<25381_1250181387_4A84410B_25381_341_1_4A843C90.4030307@googlemail.com>		<1250183964.11328.63.camel@localhost>		<25381_1250188295_4A845C07_25381_974_1_4A845C03.3090804@googlemail.com>	<1250194639.11328.270.camel@localhost>
	<4AA3C78C.6010200@googlemail.com>
Message-ID: <4AA3D834.6050605@gmail.com>

On 2009-09-06 17:30, Ioannis Nousias wrote:
> I've tried to write a DFGPrinter based on the CFGPrinter, as you 
> suggested, but encountered problems.
>
> The GraphWriter expects 
> GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is 
> implemented in CFG.h, a function is a graph of basic blocks. A 
> GraphTraits<Function*>  inherits from GraphTraits<BasicBlock*>, and 
> implements those nodes_begin()/nodes_end() wrapper functions. Should I 
> modify CFG.h and make now BasicBlock a graph of Instruction(s) ?
>
> The DataFlow.h deals with Value and User. Now BasicBlock is derived from 
> Value and Instruction from User, but I don't understand how that helps.
>
> It's a bit confusing to be honest. Can you help?
>   

Here are some examples on how to use the dataflow graphs:

Value *V = ...
for(df_iterator<Value*> UI = df_begin(V), UE = df_end(V); UI != UE; ++UI) {
...
}


typedef SmallPtrSet<const Value*, 16> SmallValueSet;
SmallValueSet DFSet;
const User* U = ...;
for (idf_ext_iterator<const User*, SmallValueSet> I=idf_ext_begin(U,
DFSet), E=idf_ext_end(U, DFSet); I != E; ++I) {
..
}


There is no common root for the dataflow graph from which you can
enumerate all dataflows, but you could take
each instruction in a function that you're interested in, and output a
dataflow graph rooted at that instruction,
unless that instruction was part of some other dataflow graph already.

Perhaps something like:

SmallValueSet PrintedSet;
for (Function::arg_iterator I=F.arg_begin(), E=F.arg_end(); I != E; ++I) {
       if (!PrintedSet.count(*I)) {
             ... print graph rooted at V, add each node printed to
PrintedSet
      }   
}
for (inst_iterator I=inst_begin(F), E=inst_end(F); I != E; ++I) {
       if (!PrintedSet.count(*I)) {
             ... print graph rooted at V, add each node printed to
PrintedSet
      }   
}

Best regards,
--Edwin

From fadi at noto.ms  Sun Sep  6 07:39:50 2009
From: fadi at noto.ms (Fadi Abboud)
Date: Sun, 6 Sep 2009 15:39:50 +0300
Subject: [LLVMdev] identifying live in and live out variables in a basic
	block pass
Message-ID: <2f69c7180909060539i4719f9a6m4f1a9f5b59371a4c@mail.gmail.com>

Hello,
I need to identify the live in (but mostly the live out) variables in a
basic block (pass)
I went over the documentation but couldn't find a way to do it.
can anyone help and if possible point me to some code snippets ...

thanks
- fadi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090906/a066d275/attachment.html 

From ioannis.nousias at googlemail.com  Sun Sep  6 11:57:28 2009
From: ioannis.nousias at googlemail.com (Ioannis Nousias)
Date: Sun, 06 Sep 2009 17:57:28 +0100
Subject: [LLVMdev] Graphviz and LLVM-TV
In-Reply-To: <4AA3D834.6050605@gmail.com>
References: <4A8437A8.4040606@googlemail.com>		<58FA02CE-B68E-466C-9E84-CCF378489A45@apple.com>		<25381_1250181387_4A84410B_25381_341_1_4A843C90.4030307@googlemail.com>		<1250183964.11328.63.camel@localhost>		<25381_1250188295_4A845C07_25381_974_1_4A845C03.3090804@googlemail.com>	<1250194639.11328.270.camel@localhost>
	<4AA3C78C.6010200@googlemail.com> <4AA3D834.6050605@gmail.com>
Message-ID: <4AA3E9F8.7030106@googlemail.com>

Edwin,

thank you for your effort, but I'm not sure I understand.
Are you describing a graph traversal problem? Is the data model stored 
in a predecessor/successor fashion, which requires you to 'walk' the 
graph in order to visit all nodes? (and what happens when you have 
disjointed DFGs?).

inline comments follow...

T?r?k Edwin wrote:
> On 2009-09-06 17:30, Ioannis Nousias wrote:
>   
>> I've tried to write a DFGPrinter based on the CFGPrinter, as you 
>> suggested, but encountered problems.
>>
>> The GraphWriter expects 
>> GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is 
>> implemented in CFG.h, a function is a graph of basic blocks. A 
>> GraphTraits<Function*>  inherits from GraphTraits<BasicBlock*>, and 
>> implements those nodes_begin()/nodes_end() wrapper functions. Should I 
>> modify CFG.h and make now BasicBlock a graph of Instruction(s) ?
>>
>> The DataFlow.h deals with Value and User. Now BasicBlock is derived from 
>> Value and Instruction from User, but I don't understand how that helps.
>>
>> It's a bit confusing to be honest. Can you help?
>>   
>>     
>
> Here are some examples on how to use the dataflow graphs:
>
> Value *V = ...
> for(df_iterator<Value*> UI = df_begin(V), UE = df_end(V); UI != UE; ++UI) {
> ...
> }
>
>
> typedef SmallPtrSet<const Value*, 16> SmallValueSet;
> SmallValueSet DFSet;
> const User* U = ...;
> for (idf_ext_iterator<const User*, SmallValueSet> I=idf_ext_begin(U,
> DFSet), E=idf_ext_end(U, DFSet); I != E; ++I) {
> ..
> }
>
>
>   
I don't understand why I'd need a depth-first iterator.


> There is no common root for the dataflow graph from which you can
> enumerate all dataflows, but you could take
> each instruction in a function that you're interested in, and output a
> dataflow graph rooted at that instruction,
> unless that instruction was part of some other dataflow graph already.
>
>   
from this I'm getting that you suggest finding all "root" instructions 
and traverse each chain of instruction (data-flow) separately. 
Considering that most dataflows are not simple expanding trees, and are 
instead merging and spliting at several points, I'm not sure what good 
that would do.

> Perhaps something like:
>
> SmallValueSet PrintedSet;
> for (Function::arg_iterator I=F.arg_begin(), E=F.arg_end(); I != E; ++I) {
>        if (!PrintedSet.count(*I)) {
>              ... print graph rooted at V, add each node printed to
> PrintedSet
>       }   
> }
> for (inst_iterator I=inst_begin(F), E=inst_end(F); I != E; ++I) {
>        if (!PrintedSet.count(*I)) {
>              ... print graph rooted at V, add each node printed to
> PrintedSet
>       }   
> }
>
> Best regards,
> --Edwin
>   
Most likely I'm missing some information here. There's probably some 
internal structure, probably how the data-model is build, that requires 
this sort of traversal. Can you elaborate please.

What I'm looking for, to start with, is something rather simple (or at 
least it should be). A per BasicBlock view of their DFGs. I'm not 
interested in the inter-BasicBlock connections, for now. I'm tempted to 
just iterate through the instructions container of each BasicBlock and 
output the graphviz manually. However, I'd prefer using any facilities 
present. The way I see it, all I need to do is iterate through the 
instructions of the BasicBlock, enumerate them to the graphviz data 
model, then iterate through them once more, checking their 
predecessor/successor instructions (inputs/outputs), to register their 
connectivity (edges). Right?


thanks,
Ioannis



PS: By the way. How come and you guys are not using Graphviz's library 
API? Avoiding the dependency?


From lattner at apple.com  Sun Sep  6 12:46:31 2009
From: lattner at apple.com (Tanya Lattner)
Date: Sun, 6 Sep 2009 10:46:31 -0700
Subject: [LLVMdev] 2.6 pre-release1 testing ends
Message-ID: <AEB0B118-3DA9-421A-8E93-D2ABACD8FC41@apple.com>

LLVMers,

The 2.6 pre-release community testing period has ended. We are now  
going to focus on fixing the bugs found which are required before pre- 
release2 can be sent out.

If anyone is able to help fix 2.6 bugs, please see the master 2.6 bug  
to find all bugs that need to be fixed:
http://llvm.org/PR4886

Because of the number of bugs outstanding, we will be pushing back the  
release schedule by a week.

Thanks,
Tanya Lattner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090906/efbb55f6/attachment.html 

From sanjiv.gupta at microchip.com  Sun Sep  6 12:48:02 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Sun, 06 Sep 2009 23:18:02 +0530
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>
References: <4AA2B20B.1030903@microchip.com> <4AA2B82A.3070105@microchip.com>
	<3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>
Message-ID: <4AA3F5D2.1040402@microchip.com>

Mikhail Glushenkov wrote:
> Hi,
>
> On Sat, Sep 5, 2009 at 9:12 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote:
>   
>> Is the patch below ok?
>>
>> Index: LLVMCConfigurationEmitter.cpp
>> ===================================================================
>> --- LLVMCConfigurationEmitter.cpp    (revision 80668)
>> +++ LLVMCConfigurationEmitter.cpp    (working copy)
>> @@ -1141,6 +1141,7 @@
>>                               Callback, EmitElseIf, OptDescs, O);
>>    }
>>    else {
>> +      EmitElseIf = true;
>>      Callback(arg, (std::string(IndentLevel) + Indent1).c_str(), O);
>>    }
>>    O << IndentLevel << "}\n";
>>     
>
> No, this is not OK - EmitCaseConstructHandler is supposed to be able
> to generate both 'if (...) ... if (...) ... if (...) ...' and 'if
> (...) ... else if (...) ... else ...' forms. That's what the
> EmitElseIf argument controls.
>
> BTW, the example in the documentation generates the 'if (...) ... else
> if (...) ... else ...'  form since the 'case' there is assumed to be
> inside the 'cmd_line' property.
>
> Can you provide a small TableGen code example of what you're trying to
> do which is not working?
>   
I wanted to be able to specify -O0, -O1, -O2 on the mcc16 command line.
And -O2 should be default(if none of -O0 or -O1 is specified). So I made 
following changes to PIC16Base.td, but that didn't work.


def optimizer : Tool<[
 (in_language "llvm-bitcode"),
 (out_language "llvm-bitcode"),
 (output_suffix "bc"),
 (cmd_line "$CALL(GetBinDir)opt $INFILE -o $OUTFILE"),
 (actions (case
          (switch_on "O0"), (append_cmd "-disable-opt"),
          (switch_on "O1"), (append_cmd "-constmerge -globaldce 
-globalopt -ipsccp -jump-threading -simplifycfg -gvn -scalarrepl"),
          (switch_on "O2"), (append_cmd "-constmerge -globaldce 
-globalopt -ipsccp -jump-threading -simplifycfg -gvn -instcombine 
-scalarrepl"),
          (default), (append_cmd "-constmerge -globaldce -globalopt 
-ipsccp -jump-threading -simplifycfg -gvn -instcombine -scalarrepl")))
]>;


From isanbard at gmail.com  Sun Sep  6 12:52:07 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sun, 6 Sep 2009 12:52:07 -0500
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
Message-ID: <EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>

The problem he's facing here isn't necessarily one of correctness.  
He's dealing with undefined behavior (at least in C code). There are  
no guarantees that the compiler will retain a certain semantic  
interpretation of an undefined construct between different versions of  
the compiler, let alone different optimization levels.

 From what I understand, he wants a particular behavior from the OS (a  
signal). The compiler shouldn't have to worry about OS semantics in  
the face of undefined language constructs. That being said, if he  
wants to implement a couple of passes to change his code, then sure. :-)

-bw

On Sep 6, 2009, at 10:22 AM, Kenneth Uildriks <kennethuil at gmail.com>  
wrote:

> On Sun, Sep 6, 2009 at 6:52 AM, Kenneth  
> Uildriks<kennethuil at gmail.com> wrote:
>> How about this:
>>
>> 1. A custom pass run at the beginning that inserts a null check  
>> before
>> every load/store:
>>
>> if ( ptr == null )
>>  trap;
>>
>> Then if any pointers get optimized to null, the if condition  
>> becomes a
>> constant true,and the trap call should become unconditional.
>>
>> 2. A custom pass at the end that takes out every remaining null check
>> that your first pass inserted.  It should first check whether the
>> condition is in fact a constant true (since that reduction might not
>> have been run after ptr became a constant null) and turn it into an
>> unconditional trap.
>
> On second thought...
>
> You'd like the program to behave correctly (whatever you mean by that)
> whether any optimization passes are run or not.  So have your
> front-end emit the null-pointer checks with the explicit trap call,
> and then you'll only need the pass at the end to take them out; but
> leaving them in will still have your program behaving correctly,
> although running a bit slower.

From kremenek at apple.com  Sun Sep  6 12:57:40 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Sun, 6 Sep 2009 10:57:40 -0700
Subject: [LLVMdev] omission: clang-cc -MD -MF -c -fPIC
In-Reply-To: <668c430c0909051136y1627b0b8r5504854af057e7ec@mail.gmail.com>
References: <668c430c0909051136y1627b0b8r5504854af057e7ec@mail.gmail.com>
Message-ID: <13BE3393-2C0F-48D9-986E-01DE38D68FCC@apple.com>

On Sep 5, 2009, at 11:36 AM, Bruce Korb wrote:

> Hi,
>
> I do not really have much direct control over the compile lines any  
> more.
> I guess I could code up a wrapper for your wrapper so that the  
> libtool wrapper
> would be happy, but could you all consider libtool built projects and
> embed the necessary option stripping in your clang-cc thing?
> Thank you.
> Regards, Bruce

Hi Bruce,

clang-cc is similar to cc1.  It is a low-level compiler driver not  
meant to be directly called by most clients.  You should use 'clang'  
instead, which acts as a drop-in replacement to gcc.  Please also send  
Clang-related emails to cfe-dev, which is the list for Clang  
development.

From bruce.korb at gmail.com  Sun Sep  6 13:02:59 2009
From: bruce.korb at gmail.com (Bruce Korb)
Date: Sun, 6 Sep 2009 11:02:59 -0700
Subject: [LLVMdev] omission: clang-cc -MD -MF -c -fPIC
In-Reply-To: <13BE3393-2C0F-48D9-986E-01DE38D68FCC@apple.com>
References: <668c430c0909051136y1627b0b8r5504854af057e7ec@mail.gmail.com>
	<13BE3393-2C0F-48D9-986E-01DE38D68FCC@apple.com>
Message-ID: <668c430c0909061102n474fd263sa97daa4c9e201e12@mail.gmail.com>

On Sun, Sep 6, 2009 at 10:57 AM, Ted Kremenek <kremenek at apple.com> wrote:
> On Sep 5, 2009, at 11:36 AM, Bruce Korb wrote:
>
>> Hi,
>>
>> I do not really have much direct control over the compile lines any more.
>> I guess I could code up a wrapper for your wrapper so that...
>
> Hi Bruce,
>
> clang-cc is similar to cc1. ?It is a low-level compiler driver not meant to
> be directly called by most clients. ?You should use 'clang' instead, which
> acts as a drop-in replacement to gcc. ?Please also send Clang-related emails
> to cfe-dev, which is the list for Clang development.

Hi Ted,

Thank you!  I read all three "RTFM" admonishments as well as the "FM" and
came away with using the cc1 replacement and the llvmdev list.  Sorry.
Thank you for the pointers.  Regards, Bruce


From the.dead.shall.rise at gmail.com  Sun Sep  6 13:13:58 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sun, 6 Sep 2009 20:13:58 +0200
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>
References: <4AA2B20B.1030903@microchip.com> <4AA2B82A.3070105@microchip.com>
	<3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>
	<4AA3F5D2.1040402@microchip.com>
	<3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>
Message-ID: <3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>

Hi Sanjiv,

On Sun, Sep 6, 2009 at 8:07 PM, Mikhail
Glushenkov<the.dead.shall.rise at gmail.com> wrote:
> [...]

[Sorry, the formatting was a bit off]

> The following snippet gives the expected behaviour (not tested, but
> you should get the idea):

(case
    (switch_on "O0"),
        (append_cmd "-disable-opt"),

    (or (and (switch_on "O1")
             (not (switch_on "O0"))),
        (not (switch_on "O0"))),
    (append_cmd "-constmerge -globaldce -globalopt -ipsccp
-jump-threading -simplifycfg -gvn -scalarrepl"),

    (or (and (switch_on "O2"),
             (not (switch_on "O0"))),
        (not (switch_on "O0"))),
    (append_cmd "-instcombine"))


> -O2 is the default, but -O0 overrides both -O2 and -O1; -O2 overrides -O1.


-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

From edwintorok at gmail.com  Sun Sep  6 15:18:28 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Sun, 06 Sep 2009 23:18:28 +0300
Subject: [LLVMdev] Graphviz and LLVM-TV
In-Reply-To: <4AA3E9F8.7030106@googlemail.com>
References: <4A8437A8.4040606@googlemail.com>		<58FA02CE-B68E-466C-9E84-CCF378489A45@apple.com>		<25381_1250181387_4A84410B_25381_341_1_4A843C90.4030307@googlemail.com>		<1250183964.11328.63.camel@localhost>		<25381_1250188295_4A845C07_25381_974_1_4A845C03.3090804@googlemail.com>	<1250194639.11328.270.camel@localhost>
	<4AA3C78C.6010200@googlemail.com> <4AA3D834.6050605@gmail.com>
	<4AA3E9F8.7030106@googlemail.com>
Message-ID: <4AA41914.50805@gmail.com>

On 2009-09-06 19:57, Ioannis Nousias wrote:
> Edwin,
>
> thank you for your effort, but I'm not sure I understand.
> Are you describing a graph traversal problem? Is the data model stored
> in a predecessor/successor fashion, which requires you to 'walk' the
> graph in order to visit all nodes? (and what happens when you have
> disjointed DFGs?).

Sorry for the confusion, it was only an example on how to use the
dataflow graphs from DataFlow.h, you don't need depth-first iteration to
implement dot graphs for DFGs.

Disjoint DFGs are the reason I mentioned the need to walk all
instructions/arguments in order to get all DFGs.
If you are only interested in a DFG starting from a particular Value*,
then forget about the iteration I mentioned.

I think your fundamental problem was that there is already a Graph for
Function*, the CFG, and you want a DFG Graph.

I think you could do something like this:
template <typename T>
class DFG {
private:
  T p;
public:
  DFG(T t) : p(t) {}
  T operator*() { return p; }
};
template <> struct GraphTraits<DFG<Function*> > : public
GraphTraits<Value*> {
  typedef inst_iterator nodes_iterator;
  static nodes_iterator nodes_begin(DFG<Function *> F) {
    return inst_begin(*F);
  }
  static nodes_iterator nodes_end(DFG<Function *> F) {
    return inst_end(*F);
  }
};

...
  ViewGraph(DFG<Function*>(F), "test");

Then you could implement a DOTGraphTraits for DFG<Function*>.

>
> inline comments follow...
>
> T?r?k Edwin wrote:
>> On 2009-09-06 17:30, Ioannis Nousias wrote:
>>  
>>> I've tried to write a DFGPrinter based on the CFGPrinter, as you
>>> suggested, but encountered problems.
>>>
>>> The GraphWriter expects
>>> GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is
>>> implemented in CFG.h, a function is a graph of basic blocks. A
>>> GraphTraits<Function*>  inherits from GraphTraits<BasicBlock*>, and
>>> implements those nodes_begin()/nodes_end() wrapper functions. Should
>>> I modify CFG.h and make now BasicBlock a graph of Instruction(s) ?
>>>
>>> The DataFlow.h deals with Value and User. Now BasicBlock is derived
>>> from Value and Instruction from User, but I don't understand how
>>> that helps.
>>>
>>> It's a bit confusing to be honest. Can you help?
>>>       
>>
>> Here are some examples on how to use the dataflow graphs:
>>
>> Value *V = ...
>> for(df_iterator<Value*> UI = df_begin(V), UE = df_end(V); UI != UE;
>> ++UI) {
>> ...
>> }
>>
>>
>> typedef SmallPtrSet<const Value*, 16> SmallValueSet;
>> SmallValueSet DFSet;
>> const User* U = ...;
>> for (idf_ext_iterator<const User*, SmallValueSet> I=idf_ext_begin(U,
>> DFSet), E=idf_ext_end(U, DFSet); I != E; ++I) {
>> ..
>> }
>>
>>
>>   
> I don't understand why I'd need a depth-first iterator.

It was just an example to show something that uses the GraphTraits from
DataFlow.h.

>
>
>> There is no common root for the dataflow graph from which you can
>> enumerate all dataflows, but you could take
>> each instruction in a function that you're interested in, and output a
>> dataflow graph rooted at that instruction,
>> unless that instruction was part of some other dataflow graph already.
>>
>>   
> from this I'm getting that you suggest finding all "root" instructions
> and traverse each chain of instruction (data-flow) separately.
> Considering that most dataflows are not simple expanding trees, and
> are instead merging and spliting at several points, I'm not sure what
> good that would do.

int foo(int b, int c)
{
int a = b+4;
int z = a+c;
int y = c+1;
..
}

If you start writing out the dataflow for 'b', then the graph contains
only 'a' and 'z'. If you start at 'c' the graph will contain only 'z'
and 'y'.
This is unlike CFG graphs where the entrypoint in a function is the root
of the CFG for that function, the DFG graphs are disjoint in this case.

>
>> Perhaps something like:
>>
>> SmallValueSet PrintedSet;
>> for (Function::arg_iterator I=F.arg_begin(), E=F.arg_end(); I != E;
>> ++I) {
>>        if (!PrintedSet.count(*I)) {
>>              ... print graph rooted at V, add each node printed to
>> PrintedSet
>>       }   }
>> for (inst_iterator I=inst_begin(F), E=inst_end(F); I != E; ++I) {
>>        if (!PrintedSet.count(*I)) {
>>              ... print graph rooted at V, add each node printed to
>> PrintedSet
>>       }   }
>>
>> Best regards,
>> --Edwin
>>   
> Most likely I'm missing some information here. There's probably some
> internal structure, probably how the data-model is build, that
> requires this sort of traversal. Can you elaborate please.
>
> What I'm looking for, to start with, is something rather simple (or at
> least it should be). A per BasicBlock view of their DFGs. I'm not
> interested in the inter-BasicBlock connections, for now. I'm tempted
> to just iterate through the instructions container of each BasicBlock
> and output the graphviz manually. However, I'd prefer using any
> facilities present. The way I see it, all I need to do is iterate
> through the instructions of the BasicBlock, enumerate them to the
> graphviz data model, then iterate through them once more, checking
> their predecessor/successor instructions (inputs/outputs), to register
> their connectivity (edges). Right?


Well the GraphTraits in DataFlow.h are really simple, LLVM's graph
algorithms expect
a child_begin()/child_end(), so DataFlow.h only maps
child_begin/child_end to use_begin/use_end, and op_begin/op_end for the
Def-Use, and Use-Def graphs respectively.
That however doesn't know of any basicblock boundaries, it enumerates
*all* uses of a value, so I think that writing out a full DFG is easier
than writing out a partial one.

>
>
> thanks,
> Ioannis
>
>
>
> PS: By the way. How come and you guys are not using Graphviz's library
> API? Avoiding the dependency?
>

Writing out a graph for dot is easy enough to do ;)

Best regards,
--Edwin

From clattner at apple.com  Sun Sep  6 15:22:16 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 6 Sep 2009 13:22:16 -0700
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
Message-ID: <F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>


On Sep 6, 2009, at 10:52 AM, Bill Wendling wrote:

> The problem he's facing here isn't necessarily one of correctness.
> He's dealing with undefined behavior (at least in C code). There are
> no guarantees that the compiler will retain a certain semantic
> interpretation of an undefined construct between different versions of
> the compiler, let alone different optimization levels.
>
> From what I understand, he wants a particular behavior from the OS (a
> signal). The compiler shouldn't have to worry about OS semantics in
> the face of undefined language constructs. That being said, if he
> wants to implement a couple of passes to change his code, then  
> sure. :-)

This is something that LLVM isn't currently good at, but that we're  
actively interested in improving.  Here is some related stuff:
http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt

I don't know of anyone working on this, or planning to work on it in  
the short term though.

-Chris

From rich at pennware.com  Sun Sep  6 15:34:58 2009
From: rich at pennware.com (Richard Pennington)
Date: Sun, 06 Sep 2009 15:34:58 -0500
Subject: [LLVMdev] Sparc debug info patch
Message-ID: <4AA41CF2.3050007@pennware.com>

Please review the enclosed patch for Sparc debug info.
I have been able to view source files, set breakpoints, and single step 
source lines after applying this patch. I can't view variables because I 
haven't implemented Dwarf type data, yet.

-Rich
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sparcdebug.patch
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090906/e2d04387/attachment.pl 

From edwintorok at gmail.com  Sun Sep  6 16:01:55 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Mon, 07 Sep 2009 00:01:55 +0300
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
Message-ID: <4AA42343.8090308@gmail.com>

On 2009-09-06 20:52, Bill Wendling wrote:
> The problem he's facing here isn't necessarily one of correctness.  
> He's dealing with undefined behavior (at least in C code). There are  
> no guarantees that the compiler will retain a certain semantic  
> interpretation of an undefined construct between different versions of  
> the compiler, let alone different optimization levels.
>   

Should LLVM IR inherit all that is undefined behavior in C?
That makes it harder to support other languages, or new languages that
want different semantics
for things that the C standard defines as undefined.

BTW even for C gcc has -fno-delete-null-pointer-checks, and the Linux
kernel started using that recently
by default after all the exploits that mapped NULL to valid memory, and
took advantage of
gcc optimizing away the NULL checks.


On 2009-09-06 23:22, Chris Lattner wrote:
> On Sep 6, 2009, at 10:52 AM, Bill Wendling wrote:
>
>   
>> The problem he's facing here isn't necessarily one of correctness.
>> He's dealing with undefined behavior (at least in C code). There are
>> no guarantees that the compiler will retain a certain semantic
>> interpretation of an undefined construct between different versions of
>> the compiler, let alone different optimization levels.
>>
>> From what I understand, he wants a particular behavior from the OS (a
>> signal). The compiler shouldn't have to worry about OS semantics in
>> the face of undefined language constructs. That being said, if he
>> wants to implement a couple of passes to change his code, then  
>> sure. :-)
>>     
>
> This is something that LLVM isn't currently good at, but that we're  
> actively interested in improving.  Here is some related stuff:
> http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt
>   

Looks interesting, but it also looks like a lot of work to implement.
Could instructions have a flag that says whether their semantics is
C-like (i.e. undefined behavior when you load from null etc.), or
something else? (throw exception, etc.).
Optimizations that assume the behavior is undefined should be updated to
check that flag, and perform the optimization only if the flag is set to
C-like.

What do you think?

> I don't know of anyone working on this, or planning to work on it in  
> the short term though.
>   


Although this is something I'd be interested in having, I lack the time
to implement it.

Best regards,
--Edwin

From the.dead.shall.rise at gmail.com  Sun Sep  6 16:49:50 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sun, 6 Sep 2009 23:49:50 +0200
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>
References: <4AA2B20B.1030903@microchip.com> <4AA2B82A.3070105@microchip.com>
	<3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>
	<4AA3F5D2.1040402@microchip.com>
	<3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>
	<3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>
Message-ID: <3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>

Hi Sanjiv,

On Sun, Sep 6, 2009 at 8:13 PM, Mikhail
Glushenkov<the.dead.shall.rise at gmail.com> wrote:
> Hi Sanjiv,
>
> On Sun, Sep 6, 2009 at 8:07 PM, Mikhail
> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>> [...]
>
> [Sorry, the formatting was a bit off]
>
>> The following snippet gives the expected behaviour (not tested, but
>> you should get the idea):

BTW, your mail has got me thinking about the semantics of 'case',
which is currently somewhat ambiguous (since it depends on context).
Probably 'case' should be modified to always mean 'if ... else if ...
else if ... [...] else ...' and the 'if (...) ... if (...) ... if
(...) ... [...]' form should be called something like 'match'. That
would be backwards-incompatible, though.

What do you think?

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

From max.stonebraker at gmail.com  Sun Sep  6 16:49:54 2009
From: max.stonebraker at gmail.com (Max Stonebraker)
Date: Sun, 6 Sep 2009 14:49:54 -0700
Subject: [LLVMdev] disable insertion of unreachables
Message-ID: <808cbd330909061449w4abe76a6kce710bd1bb9deeb3@mail.gmail.com>

Hello all,

LLVM inserts unreachable instructions after every call to a terminating
function. Is there a way to disable this feature so that it treats
terminating function calls like any other function call, so the unreachable
instruction would not be inserted? Unfortunately, simply removing the
unreachable instructions after the fact would not suffice for my needs
because I need to preserve the original control flow of the program. That
is, I need to know the instruction that would have been executed if the call
to the terminating function didn't actually terminate the program.

Thanks!

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090906/732465f1/attachment.html 

From kennethuil at gmail.com  Sun Sep  6 16:55:22 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 6 Sep 2009 16:55:22 -0500
Subject: [LLVMdev] disable insertion of unreachables
In-Reply-To: <808cbd330909061449w4abe76a6kce710bd1bb9deeb3@mail.gmail.com>
References: <808cbd330909061449w4abe76a6kce710bd1bb9deeb3@mail.gmail.com>
Message-ID: <400d33ea0909061455l6837b7b7j6768454214f3f4a5@mail.gmail.com>

What do you mean by "terminating function call"?  Is it one with the
"noreturn" attribute?  if so, the assembly language docs say that
program behavior is undefined if such a function ever returns.  If
your function could possibly return, it needs to not have that
attribute.

On Sun, Sep 6, 2009 at 4:49 PM, Max
Stonebraker<max.stonebraker at gmail.com> wrote:
> Hello all,
>
> LLVM inserts unreachable instructions after every call to a terminating
> function. Is there a way to disable this feature so that it treats
> terminating function calls like any other function call, so the unreachable
> instruction would not be inserted? Unfortunately, simply removing the
> unreachable instructions after the fact would not suffice for my needs
> because I need to preserve the original control flow of the program. That
> is, I need to know the instruction that would have been executed if the call
> to the terminating function didn't actually terminate the program.
>
> Thanks!
>
> Max
>
> _______________________________________________
> 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  Sun Sep  6 17:12:27 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sun, 6 Sep 2009 17:12:27 -0500
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <4AA42343.8090308@gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
	<4AA42343.8090308@gmail.com>
Message-ID: <8D2E1016-6CE6-4B91-8BDE-959AC8D907EC@gmail.com>

On Sep 6, 2009, at 4:01 PM, T?r?k Edwin <edwintorok at gmail.com> wrote:

> On 2009-09-06 20:52, Bill Wendling wrote:
>> The problem he's facing here isn't necessarily one of correctness.
>> He's dealing with undefined behavior (at least in C code). There are
>> no guarantees that the compiler will retain a certain semantic
>> interpretation of an undefined construct between different versions  
>> of
>> the compiler, let alone different optimization levels.
>>
>
> Should LLVM IR inherit all that is undefined behavior in C?

For better or worse, it already inherits some of them. No, I don't  
think the idea is to make LLVM dependent on C's way of doing things.  
But one must assume some base-level of what to do with a particular  
construct.

Apparently, at this time at least, it's considered good to turn a  
dereference of null into unreachable. But like chris mentioned, it's  
something that we should improve.

> That makes it harder to support other languages, or new languages that
> want different semantics
> for things that the C standard defines as undefined.

Yup.

> BTW even for C gcc has -fno-delete-null-pointer-checks, and the Linux
> kernel started using that recently
> by default after all the exploits that mapped NULL to valid memory,  
> and
> took advantage of
> gcc optimizing away the NULL checks.
>
What's the affect of this flag? I've never seen it before. :-) If  
we're doing something that violates the semantics of this flag, then  
it's something we need to fix, of course.

-bw

> On 2009-09-06 23:22, Chris Lattner wrote:
>> On Sep 6, 2009, at 10:52 AM, Bill Wendling wrote:
>>
>>
>>> The problem he's facing here isn't necessarily one of correctness.
>>> He's dealing with undefined behavior (at least in C code). There are
>>> no guarantees that the compiler will retain a certain semantic
>>> interpretation of an undefined construct between different  
>>> versions of
>>> the compiler, let alone different optimization levels.
>>>
>>> From what I understand, he wants a particular behavior from the OS  
>>> (a
>>> signal). The compiler shouldn't have to worry about OS semantics in
>>> the face of undefined language constructs. That being said, if he
>>> wants to implement a couple of passes to change his code, then
>>> sure. :-)
>>>
>>
>> This is something that LLVM isn't currently good at, but that we're
>> actively interested in improving.  Here is some related stuff:
>> http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt
>>
>
> Looks interesting, but it also looks like a lot of work to implement.
> Could instructions have a flag that says whether their semantics is
> C-like (i.e. undefined behavior when you load from null etc.), or
> something else? (throw exception, etc.).
> Optimizations that assume the behavior is undefined should be  
> updated to
> check that flag, and perform the optimization only if the flag is  
> set to
> C-like.
>
> What do you think?
>
>> I don't know of anyone working on this, or planning to work on it in
>> the short term though.
>>
>
>
> Although this is something I'd be interested in having, I lack the  
> time
> to implement it.
>
> Best regards,
> --Edwin


From kennethuil at gmail.com  Sun Sep  6 17:19:50 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 6 Sep 2009 17:19:50 -0500
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
	<F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>
Message-ID: <400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>

On Sun, Sep 6, 2009 at 3:22 PM, Chris Lattner<clattner at apple.com> wrote:
>
> On Sep 6, 2009, at 10:52 AM, Bill Wendling wrote:
>
>> The problem he's facing here isn't necessarily one of correctness.
>> He's dealing with undefined behavior (at least in C code). There are
>> no guarantees that the compiler will retain a certain semantic
>> interpretation of an undefined construct between different versions of
>> the compiler, let alone different optimization levels.
>>
>> From what I understand, he wants a particular behavior from the OS (a
>> signal). The compiler shouldn't have to worry about OS semantics in
>> the face of undefined language constructs. That being said, if he
>> wants to implement a couple of passes to change his code, then sure. :-)
>
> This is something that LLVM isn't currently good at, but that we're actively
> interested in improving. ?Here is some related stuff:
> http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt

Interesting.  What advantage do we get from the restriction that
terminators (including invokes) can only appear at the end of a basic
block?  We'd lose that advantage, but in one sense that advantage is
already lost since loads, stores, calls, and whatnot *can* throw the
path of execution out of the middle of a basic block, we just have no
standard way to control or determine where it goes.

It would be unfortunate in a way if "this instruction can trap and go
there" is taken to mean "if this instruction has no effect other than
a possible trap, the instruction and the trapping behavior *must* be
preserved".


From eli.friedman at gmail.com  Sun Sep  6 17:24:23 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sun, 6 Sep 2009 15:24:23 -0700
Subject: [LLVMdev] identifying live in and live out variables in a basic
	block pass
In-Reply-To: <2f69c7180909060539i4719f9a6m4f1a9f5b59371a4c@mail.gmail.com>
References: <2f69c7180909060539i4719f9a6m4f1a9f5b59371a4c@mail.gmail.com>
Message-ID: <f5aa3e9b0909061524h6963483ag4c07d35ee3b31f2e@mail.gmail.com>

On Sun, Sep 6, 2009 at 5:39 AM, Fadi Abboud<fadi at noto.ms> wrote:
> Hello,
> I need to identify the live in (but mostly the live out) variables in a
> basic block (pass)
> I went over the documentation but couldn't find a way to do it.
> can anyone help and if possible point me to some code snippets ...

By "variables", do you mean SSA values?  You can do that simply by
iterating over the uses and checking if any are outside of the current
block.

-Eli

From eli.friedman at gmail.com  Sun Sep  6 17:32:28 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sun, 6 Sep 2009 15:32:28 -0700
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
	<F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>
	<400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>
Message-ID: <f5aa3e9b0909061532i1d88deecma93583b28a49991c@mail.gmail.com>

On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote:
> It would be unfortunate in a way if "this instruction can trap and go
> there" is taken to mean "if this instruction has no effect other than
> a possible trap, the instruction and the trapping behavior *must* be
> preserved".

What exactly would the semantics be if the instruction *might* trap?
I somehow can't imagine it being useful.

-Eli

From kennethuil at gmail.com  Sun Sep  6 17:53:48 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 6 Sep 2009 17:53:48 -0500
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <f5aa3e9b0909061532i1d88deecma93583b28a49991c@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
	<F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>
	<400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>
	<f5aa3e9b0909061532i1d88deecma93583b28a49991c@mail.gmail.com>
Message-ID: <400d33ea0909061553i62fca66an73f72cd18ef0ca37@mail.gmail.com>

On Sun, Sep 6, 2009 at 5:32 PM, Eli Friedman<eli.friedman at gmail.com> wrote:
> On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote:
>> It would be unfortunate in a way if "this instruction can trap and go
>> there" is taken to mean "if this instruction has no effect other than
>> a possible trap, the instruction and the trapping behavior *must* be
>> preserved".
>
> What exactly would the semantics be if the instruction *might* trap?
> I somehow can't imagine it being useful.
>
> -Eli
>
I'm not sure I understand the question.  Instructions that are
guaranteed to trap can be optimized into unconditional traps.  So
we're talking about instructions that *might* trap in any case.

I was saying that if the only possible effect of an instruction is a
trap, do we really want optimizers to preserve it in every case?

From eli.friedman at gmail.com  Sun Sep  6 18:08:32 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sun, 6 Sep 2009 16:08:32 -0700
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <400d33ea0909061553i62fca66an73f72cd18ef0ca37@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
	<F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>
	<400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>
	<f5aa3e9b0909061532i1d88deecma93583b28a49991c@mail.gmail.com>
	<400d33ea0909061553i62fca66an73f72cd18ef0ca37@mail.gmail.com>
Message-ID: <f5aa3e9b0909061608l3d3105b1u7ee5d4915d6ff10d@mail.gmail.com>

On Sun, Sep 6, 2009 at 3:53 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote:
> On Sun, Sep 6, 2009 at 5:32 PM, Eli Friedman<eli.friedman at gmail.com> wrote:
>> On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote:
>>> It would be unfortunate in a way if "this instruction can trap and go
>>> there" is taken to mean "if this instruction has no effect other than
>>> a possible trap, the instruction and the trapping behavior *must* be
>>> preserved".
>>
>> What exactly would the semantics be if the instruction *might* trap?
>> I somehow can't imagine it being useful.
>>
>> -Eli
>>
> I'm not sure I understand the question. ?Instructions that are
> guaranteed to trap can be optimized into unconditional traps. ?So
> we're talking about instructions that *might* trap in any case.
>
> I was saying that if the only possible effect of an instruction is a
> trap, do we really want optimizers to preserve it in every case?

Right... the question is, is there any language that actually has such
semantics?

-Eli


From andrii.vasyliev at gmail.com  Sun Sep  6 18:32:44 2009
From: andrii.vasyliev at gmail.com (Andrii Vasyliev)
Date: Mon, 7 Sep 2009 02:32:44 +0300
Subject: [LLVMdev] Equivalent types
Message-ID: <dc7e00e30909061632v7f15d9adq9141fbaf6cd59820@mail.gmail.com>

Hi!

I have this error while building my code:
Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)
== Params[i]->getType()) && "Calling a function with a bad
signature!")
Actually I'm trying to load functions from .bc file and use them in
the code that I'm building with IRBuilder.

I found that function parameter type is %struct.reValue* and
the type of the value that I'm passing to the function is {i32,i64}*

But these types are quite equivalent, because of the definition:
        %struct.reValue = type { %"struct.reValue::$_44",
%"struct.reValue::$_46" }
        %"struct.reValue::$_44" = type { i32 }
        %"struct.reValue::$_46" = type { i64 }

What is the easiest way to solve this problem?

Thanks,
Andrii

From arplynn at gmail.com  Sun Sep  6 18:49:15 2009
From: arplynn at gmail.com (Alastair Lynn)
Date: Mon, 7 Sep 2009 00:49:15 +0100
Subject: [LLVMdev] Equivalent types
In-Reply-To: <dc7e00e30909061632v7f15d9adq9141fbaf6cd59820@mail.gmail.com>
References: <dc7e00e30909061632v7f15d9adq9141fbaf6cd59820@mail.gmail.com>
Message-ID: <436BEDA0-A99D-4DF8-A396-644FFE7896E2@gmail.com>

Hi Andrii--

They're not equivalent as far as LLVM is concerned - the parameter  
type is { { i32 }. { i64 } }* whereas the function is being given a  
{ i32, i64 }*. Probably the easiest way to work around this is a  
simple bitcast.

Alastair

On 7 Sep 2009, at 00:32, Andrii Vasyliev wrote:

> Hi!
>
> I have this error while building my code:
> Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)
> == Params[i]->getType()) && "Calling a function with a bad
> signature!")
> Actually I'm trying to load functions from .bc file and use them in
> the code that I'm building with IRBuilder.
>
> I found that function parameter type is %struct.reValue* and
> the type of the value that I'm passing to the function is {i32,i64}*
>
> But these types are quite equivalent, because of the definition:
>        %struct.reValue = type { %"struct.reValue::$_44",
> %"struct.reValue::$_46" }
>        %"struct.reValue::$_44" = type { i32 }
>        %"struct.reValue::$_46" = type { i64 }
>
> What is the easiest way to solve this problem?
>
> Thanks,
> Andrii
> _______________________________________________
> 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: smime.p7s
Type: application/pkcs7-signature
Size: 3912 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090907/c035cfb0/attachment.bin 

From nicholas at mxc.ca  Sun Sep  6 18:49:18 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sun, 06 Sep 2009 16:49:18 -0700
Subject: [LLVMdev] Equivalent types
In-Reply-To: <dc7e00e30909061632v7f15d9adq9141fbaf6cd59820@mail.gmail.com>
References: <dc7e00e30909061632v7f15d9adq9141fbaf6cd59820@mail.gmail.com>
Message-ID: <4AA44A7E.8060808@mxc.ca>

Andrii Vasyliev wrote:
> Hi!
> 
> I have this error while building my code:
> Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)
> == Params[i]->getType()) && "Calling a function with a bad
> signature!")
> Actually I'm trying to load functions from .bc file and use them in
> the code that I'm building with IRBuilder.
> 
> I found that function parameter type is %struct.reValue* and
> the type of the value that I'm passing to the function is {i32,i64}*
> 
> But these types are quite equivalent, because of the definition:
>         %struct.reValue = type { %"struct.reValue::$_44",
> %"struct.reValue::$_46" }
>         %"struct.reValue::$_44" = type { i32 }
>         %"struct.reValue::$_46" = type { i64 }

Not quite. %struct.reValue = type { { i32 }, { i64 } } not { i32, i64 }.

Nick

From andrii.vasyliev at gmail.com  Sun Sep  6 19:16:39 2009
From: andrii.vasyliev at gmail.com (Andrii Vasyliev)
Date: Mon, 7 Sep 2009 03:16:39 +0300
Subject: [LLVMdev] Equivalent types
In-Reply-To: <436BEDA0-A99D-4DF8-A396-644FFE7896E2@gmail.com>
References: <dc7e00e30909061632v7f15d9adq9141fbaf6cd59820@mail.gmail.com>
	<436BEDA0-A99D-4DF8-A396-644FFE7896E2@gmail.com>
Message-ID: <dc7e00e30909061716y1327463dq8e58c38ded3ba623@mail.gmail.com>

2009/9/7 Alastair Lynn <arplynn at gmail.com>:
> They're not equivalent as far as LLVM is concerned - the parameter type is {
> { i32 }. { i64 } }* whereas the function is being given a { i32, i64 }*.

Thanks! That's it!

From baldrick at free.fr  Mon Sep  7 00:04:22 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 07 Sep 2009 07:04:22 +0200
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <f5aa3e9b0909061608l3d3105b1u7ee5d4915d6ff10d@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>	<F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>	<400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>	<f5aa3e9b0909061532i1d88deecma93583b28a49991c@mail.gmail.com>	<400d33ea0909061553i62fca66an73f72cd18ef0ca37@mail.gmail.com>
	<f5aa3e9b0909061608l3d3105b1u7ee5d4915d6ff10d@mail.gmail.com>
Message-ID: <4AA49456.4000603@free.fr>

Hi Eli,

>>> What exactly would the semantics be if the instruction *might* trap?
>>> I somehow can't imagine it being useful.
>>>
>>> -Eli
>>>
>> I'm not sure I understand the question.  Instructions that are
>> guaranteed to trap can be optimized into unconditional traps.  So
>> we're talking about instructions that *might* trap in any case.
>>
>> I was saying that if the only possible effect of an instruction is a
>> trap, do we really want optimizers to preserve it in every case?
> 
> Right... the question is, is there any language that actually has such
> semantics?

before every operation, the Ada front-end generates code that checks
for out-of-bound array accesses, null pointer dereference, integer
overflow etc (whatever is appropriate for the operation) and throws
an exception if the error occurs.  It would be nice if the compiler
could turn these explicit checks into more efficient implicit checks.
For example, on a platform on which load/store to a null pointer will
send a signal to the program, the explicit null checks could be
removed since the Ada runtime knows how to magically convert the signal
into an exception thrown at the right place.  That said, the compiler
mustn't move around the load/store in a way that it wouldn't have done
if the explicit checks were present.

Ciao,

Duncan.

From sanjiv.gupta at microchip.com  Mon Sep  7 01:22:33 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 07 Sep 2009 11:52:33 +0530
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>
References: <4AA2B20B.1030903@microchip.com> <4AA2B82A.3070105@microchip.com>	
	<3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>	
	<4AA3F5D2.1040402@microchip.com>	
	<3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>	
	<3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>
	<3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>
Message-ID: <4AA4A6A9.5050608@microchip.com>

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> On Sun, Sep 6, 2009 at 8:13 PM, Mikhail
> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>   
>> Hi Sanjiv,
>>
>> On Sun, Sep 6, 2009 at 8:07 PM, Mikhail
>> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>>     
>>> [...]
>>>       
>> [Sorry, the formatting was a bit off]
>>
>>     
>>> The following snippet gives the expected behaviour (not tested, but
>>> you should get the idea):
>>>       
>
> BTW, your mail has got me thinking about the semantics of 'case',
> which is currently somewhat ambiguous (since it depends on context).
> Probably 'case' should be modified to always mean 'if ... else if ...
> else if ... [...] else ...' 
IMO, we shouldn't think in terms of what code the user wants to 
generate; The syntax should rather specify what can you do with it. What 
code we generate  for that syntax is rather immaterial as long as it works.
Having said that, a "tblgen case ..... switch_on" is more like a "C 
switch....case" for me, and a if ... elseif...elseif...else is a valid 
way to handle it.
Now if we allow nesting, that should work as well.
> and the 'if (...) ... if (...) ... if
> (...) ... [...]' form should be called something like 'match'. That
> would be backwards-incompatible, though.
>
> What do you think?
>   
Again, if an user wants to check for multiple conditions to be true 
before taking some action , we can devise a new construct for doing that.
A   match (this)...and ...match(this) ...and match(this)...    makes 
sense to me.

- Sanjiv


From edwintorok at gmail.com  Mon Sep  7 03:37:45 2009
From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=)
Date: Mon, 07 Sep 2009 11:37:45 +0300
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <8D2E1016-6CE6-4B91-8BDE-959AC8D907EC@gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
	<4AA42343.8090308@gmail.com>
	<8D2E1016-6CE6-4B91-8BDE-959AC8D907EC@gmail.com>
Message-ID: <4AA4C659.5040606@gmail.com>

On 2009-09-07 01:12, Bill Wendling wrote:
> On Sep 6, 2009, at 4:01 PM, T?r?k Edwin <edwintorok at gmail.com> wrote:
>
>> On 2009-09-06 20:52, Bill Wendling wrote:
>>> The problem he's facing here isn't necessarily one of correctness.
>>> He's dealing with undefined behavior (at least in C code). There are
>>> no guarantees that the compiler will retain a certain semantic
>>> interpretation of an undefined construct between different versions of
>>> the compiler, let alone different optimization levels.
>>>
>>
>> Should LLVM IR inherit all that is undefined behavior in C?
>
> For better or worse, it already inherits some of them. No, I don't
> think the idea is to make LLVM dependent on C's way of doing things.
> But one must assume some base-level of what to do with a particular
> construct.
>
> Apparently, at this time at least, it's considered good to turn a
> dereference of null into unreachable. But like chris mentioned, it's
> something that we should improve.

Ok.

>
>> That makes it harder to support other languages, or new languages that
>> want different semantics
>> for things that the C standard defines as undefined.
>
> Yup.
>
>> BTW even for C gcc has -fno-delete-null-pointer-checks, and the Linux
>> kernel started using that recently
>> by default after all the exploits that mapped NULL to valid memory, and
>> took advantage of
>> gcc optimizing away the NULL checks.
>>
> What's the affect of this flag? I've never seen it before. :-) If
> we're doing something that violates the semantics of this flag, then
> it's something we need to fix, of course.

At -O2 and higher gcc deletes if (p == NULL) checks after p has been
dereferenced, assuming that a deref of null halts the program.
-fno-delete-null-pointer-checks disables that optimization.
I haven't seen LLVM do this optimization currently, but maybe I just
haven't seen it yet.

>From the gcc manpage:
   `-fdelete-null-pointer-checks'
     Use global dataflow analysis to identify and eliminate useless
     checks for null pointers.  The compiler assumes that dereferencing
     a null pointer would have halted the program.  If a pointer is
     checked after it has already been dereferenced, it cannot be null.

     In some environments, this assumption is not true, and programs can
     safely dereference null pointers.  Use
     `-fno-delete-null-pointer-checks' to disable this optimization for
     programs which depend on that behavior.

     Enabled at levels `-O2', `-O3', `-Os'.


Best regards,
--Edwin

From aph at redhat.com  Mon Sep  7 04:38:54 2009
From: aph at redhat.com (Andrew Haley)
Date: Mon, 07 Sep 2009 10:38:54 +0100
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <f5aa3e9b0909061608l3d3105b1u7ee5d4915d6ff10d@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>	<F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>	<400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>	<f5aa3e9b0909061532i1d88deecma93583b28a49991c@mail.gmail.com>	<400d33ea0909061553i62fca66an73f72cd18ef0ca37@mail.gmail.com>
	<f5aa3e9b0909061608l3d3105b1u7ee5d4915d6ff10d@mail.gmail.com>
Message-ID: <4AA4D4AE.1070104@redhat.com>

Eli Friedman wrote:
> On Sun, Sep 6, 2009 at 3:53 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote:
>> On Sun, Sep 6, 2009 at 5:32 PM, Eli Friedman<eli.friedman at gmail.com> wrote:
>>> On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote:
>>>> It would be unfortunate in a way if "this instruction can trap and go
>>>> there" is taken to mean "if this instruction has no effect other than
>>>> a possible trap, the instruction and the trapping behavior *must* be
>>>> preserved".
>>> What exactly would the semantics be if the instruction *might* trap?
>>> I somehow can't imagine it being useful.
>>>
>>> -Eli
>>>
>> I'm not sure I understand the question.  Instructions that are
>> guaranteed to trap can be optimized into unconditional traps.  So
>> we're talking about instructions that *might* trap in any case.
>>
>> I was saying that if the only possible effect of an instruction is a
>> trap, do we really want optimizers to preserve it in every case?
> 
> Right... the question is, is there any language that actually has such
> semantics?

We faced this problem in gcc, and unfortunately Java and Ada have different
properties when it comes to trapping instructions: Java must throw a
NullPointerException at the appropriate place, but AIUI Ada may or may not.

Andrew.

From baldrick at free.fr  Mon Sep  7 05:24:42 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 07 Sep 2009 12:24:42 +0200
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <4AA4D4AE.1070104@redhat.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>	<F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>	<400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>	<f5aa3e9b0909061532i1d88deecma93583b28a49991c@mail.gmail.com>	<400d33ea0909061553i62fca66an73f72cd18ef0ca37@mail.gmail.com>	<f5aa3e9b0909061608l3d3105b1u7ee5d4915d6ff10d@mail.gmail.com>
	<4AA4D4AE.1070104@redhat.com>
Message-ID: <4AA4DF6A.70500@free.fr>

Hi Andrew,

> We faced this problem in gcc, and unfortunately Java and Ada have different
> properties when it comes to trapping instructions: Java must throw a
> NullPointerException at the appropriate place, but AIUI Ada may or may not.

in the case of Ada, throwing an exception at the appropriate place is
always fine.  The language standard does allow the compiler to perform
some optimizations which may result in the exception being thrown
somewhere else, but of course the compiler isn't obliged to perform
these optimizations.  In summary: it is always right to throw the
exception at the obvious place, but it is not necessarily wrong if it is
thrown somewhere else.

Ciao,

Duncan.

From clattner at apple.com  Mon Sep  7 10:24:05 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 7 Sep 2009 08:24:05 -0700
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
	<F03F1487-0162-4CD0-869D-683EF6A08097@apple.com>
	<400d33ea0909061519y19ebee63n2b276f1ac308ba65@mail.gmail.com>
Message-ID: <622761D7-1E39-4DD5-A790-121DB2F0197C@apple.com>

On Sep 6, 2009, at 3:19 PM, Kenneth Uildriks wrote:
> On Sun, Sep 6, 2009 at 3:22 PM, Chris Lattner<clattner at apple.com>  
> wrote:
>>
>> On Sep 6, 2009, at 10:52 AM, Bill Wendling wrote:
>>
>>> The problem he's facing here isn't necessarily one of correctness.
>>> He's dealing with undefined behavior (at least in C code). There are
>>> no guarantees that the compiler will retain a certain semantic
>>> interpretation of an undefined construct between different  
>>> versions of
>>> the compiler, let alone different optimization levels.
>>>
>>> From what I understand, he wants a particular behavior from the OS  
>>> (a
>>> signal). The compiler shouldn't have to worry about OS semantics in
>>> the face of undefined language constructs. That being said, if he
>>> wants to implement a couple of passes to change his code, then  
>>> sure. :-)
>>
>> This is something that LLVM isn't currently good at, but that we're  
>> actively
>> interested in improving.  Here is some related stuff:
>> http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt
>
> Interesting.  What advantage do we get from the restriction that
> terminators (including invokes) can only appear at the end of a basic
> block?

The big advantage right now is that is how the CFG is constructed:  
pred_begin/succ_begin are based on the use/def chains of BasicBlocks,  
and they expect to have terminators.

However, while this is a nice and elegant solution, it will have to  
change in the future anyway.  Modeling the GCC "address of label and  
indirect goto" extension right requires breaking this as well.

>  We'd lose that advantage, but in one sense that advantage is
> already lost since loads, stores, calls, and whatnot *can* throw the
> path of execution out of the middle of a basic block, we just have no
> standard way to control or determine where it goes.

Well right now, we just claim it's undefined behavior :)

-Chris



From clattner at apple.com  Mon Sep  7 10:29:34 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 7 Sep 2009 08:29:34 -0700
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <4AA42343.8090308@gmail.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
	<4AA42343.8090308@gmail.com>
Message-ID: <62EA9781-1135-4A28-9EEE-95A5F4BA6717@apple.com>


On Sep 6, 2009, at 2:01 PM, T?r?k Edwin wrote:

> On 2009-09-06 20:52, Bill Wendling wrote:
>> The problem he's facing here isn't necessarily one of correctness.
>> He's dealing with undefined behavior (at least in C code). There are
>> no guarantees that the compiler will retain a certain semantic
>> interpretation of an undefined construct between different versions  
>> of
>> the compiler, let alone different optimization levels.
>>
>
> Should LLVM IR inherit all that is undefined behavior in C?

Yes, where it is useful for optimization purposes.

> That makes it harder to support other languages, or new languages that
> want different semantics
> for things that the C standard defines as undefined.

This is another question though.  I think that LLVM should support  
taking advantage of undefined behavior in C, but it should also allow  
other languages to model what they need.

As a concrete example, there is no reason not to add a "bit" to  
LoadInst saying whether an "invalid" load is undefined or whether it  
causes an "exception".  The fun part is nailing down which cases of  
"invalid" are allowed, but it isn't that big of a deal.

>>
>> This is something that LLVM isn't currently good at, but that we're
>> actively interested in improving.  Here is some related stuff:
>> http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt
>>
>
> Looks interesting, but it also looks like a lot of work to implement.

Well that is why it hasn't been done yet :)

> Could instructions have a flag that says whether their semantics is
> C-like (i.e. undefined behavior when you load from null etc.), or
> something else? (throw exception, etc.).

Yes.  You need to tell the optimizer what the possible control flow is  
though, or else it will move operations in invalid ways.

> What do you think?

Right!

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

From edwintorok at gmail.com  Mon Sep  7 10:36:04 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Mon, 07 Sep 2009 18:36:04 +0300
Subject: [LLVMdev] loads from a null address and optimizations
In-Reply-To: <62EA9781-1135-4A28-9EEE-95A5F4BA6717@apple.com>
References: <295e750a0909051219k372406c1mf38a664a476722bd@mail.gmail.com>
	<272C030F-C957-4DC9-9AC3-1425282BEDE3@gmail.com>
	<295e750a0909051459w21c3cc9aqf5a7099b25d3919@mail.gmail.com>
	<400d33ea0909060452t65093738g1a0870d0144c51ba@mail.gmail.com>
	<400d33ea0909060822q7864d01dq5aa9d36edc4fcece@mail.gmail.com>
	<EF978F1B-E097-45BE-B250-70DF62414980@gmail.com>
	<4AA42343.8090308@gmail.com>
	<62EA9781-1135-4A28-9EEE-95A5F4BA6717@apple.com>
Message-ID: <4AA52864.2070904@gmail.com>

On 2009-09-07 18:29, Chris Lattner wrote:
>
> On Sep 6, 2009, at 2:01 PM, T?r?k Edwin wrote:
>
>> On 2009-09-06 20:52, Bill Wendling wrote:
>>> The problem he's facing here isn't necessarily one of correctness.  
>>> He's dealing with undefined behavior (at least in C code). There are  
>>> no guarantees that the compiler will retain a certain semantic  
>>> interpretation of an undefined construct between different versions of  
>>> the compiler, let alone different optimization levels.
>>>
>>
>> Should LLVM IR inherit all that is undefined behavior in C?
>
> Yes, where it is useful for optimization purposes.
>
>> That makes it harder to support other languages, or new languages that
>> want different semantics
>> for things that the C standard defines as undefined.
>
> This is another question though.  I think that LLVM should support
> taking advantage of undefined behavior in C, but it should also allow
> other languages to model what they need.
>
> As a concrete example, there is no reason not to add a "bit" to
> LoadInst saying whether an "invalid" load is undefined or whether it
> causes an "exception".  The fun part is nailing down which cases of
> "invalid" are allowed, but it isn't that big of a deal.
>
>>>
>>> This is something that LLVM isn't currently good at, but that we're  
>>> actively interested in improving.  Here is some related stuff:
>>> http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt
>>>
>>
>> Looks interesting, but it also looks like a lot of work to implement.
>
> Well that is why it hasn't been done yet :)
>
>> Could instructions have a flag that says whether their semantics is
>> C-like (i.e. undefined behavior when you load from null etc.), or
>> something else? (throw exception, etc.).
>
> Yes.  You need to tell the optimizer what the possible control flow is
> though, or else it will move operations in invalid ways.
>

Another crazy idea: what if we'd model the invalid/undefined behavior
via an llvm.undefinedbehavior intrinsic that has a parameter specifying
the kind of undefined behavior.
Optimizers should then either insert calls to this intrinsic, or do
whatever they do for C currently if TargetData says
llvm.undefinedbehavior should not be preserved.
Languages that need to handle these undefined behaviors could defined
llvm.undefinedbehavior to throw an exception, call runtime function, etc.

This should work even if functions are marked nounwind, since the
unwinder will find the first stackframe that does have a landingpad and
land there, right [*]?
Frontends for languages that want exception for undef behavior could
then use invoke/unwind to. When LLVM will have a better invoke they'll
switch to that of course.

[*] it seems to work for LLVM at least, operator new throws
std::bad_alloc and opt's catch() catches it, although all of llvm is
compiled with no-exceptions.

Best regards,
--Edwin

From michael.silvanus at gmail.com  Mon Sep  7 12:53:15 2009
From: michael.silvanus at gmail.com (Michel Alexandre Salim)
Date: Mon, 7 Sep 2009 13:53:15 -0400
Subject: [LLVMdev] LLVM 2.6 pre1: test failures on Fedora 11.91 (Rawhide) ppc
Message-ID: <615c05430909071053q4bd71d3et6fe72eedc8d536e6@mail.gmail.com>

Hello,

I'm updating Fedora's LLVM to the latest 2.6 prerelease, and
experiencing test failures on ppc. On x86_64 and x86_32 all tests pass
as expected.

http://koji.fedoraproject.org/koji/taskinfo?taskID=1660661

(see root.log to see what packages are installed for the build, and
build.log for the build log -- 'make check' is called towards the end.

Thanks,

-- 
Michel Alexandre Salim

From kuba at gcc.gnu.org  Mon Sep  7 13:10:37 2009
From: kuba at gcc.gnu.org (Jakub Staszak)
Date: Mon, 7 Sep 2009 16:10:37 -0200
Subject: [LLVMdev] PR4882
Message-ID: <7CCDA687-7448-4284-BE04-678DCF6C6CDA@gcc.gnu.org>

Hello,

This patch fixes bug 4882.

Regards
-Jakub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr4882.patch
Type: application/octet-stream
Size: 6856 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090907/266f900c/attachment.obj 

From baldrick at free.fr  Mon Sep  7 14:02:03 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 07 Sep 2009 21:02:03 +0200
Subject: [LLVMdev] PR4882
In-Reply-To: <7CCDA687-7448-4284-BE04-678DCF6C6CDA@gcc.gnu.org>
References: <7CCDA687-7448-4284-BE04-678DCF6C6CDA@gcc.gnu.org>
Message-ID: <4AA558AB.3020004@free.fr>

Hi Jakub, looks good.

> +  LLVMContext *Context = &SI->getContext();

I guess this could be
   LLVMContext &Context = SI->getContext();
which means you can use Context rather than *Context below.

> -      const Type *Ty = Type::getInt64Ty(SI->getContext());
> -      MemSetF = Intrinsic::getDeclaration(M, Intrinsic::memset, &Ty, 1);
> +      const Type *Tys[] = {Type::getInt64Ty(*Context)};
> +      MemSetF = Intrinsic::getDeclaration(M, Intrinsic::memset,
> +                                          Tys, 1);

Why did you introduce Tys and not stick with Ty?

Ciao,

Duncan.

From ioannis.nousias at googlemail.com  Mon Sep  7 15:08:34 2009
From: ioannis.nousias at googlemail.com (Ioannis Nousias)
Date: Mon, 07 Sep 2009 21:08:34 +0100
Subject: [LLVMdev] Graphviz and LLVM-TV
In-Reply-To: <4AA41914.50805@gmail.com>
References: <4A8437A8.4040606@googlemail.com>		<58FA02CE-B68E-466C-9E84-CCF378489A45@apple.com>		<25381_1250181387_4A84410B_25381_341_1_4A843C90.4030307@googlemail.com>		<1250183964.11328.63.camel@localhost>		<25381_1250188295_4A845C07_25381_974_1_4A845C03.3090804@googlemail.com>	<1250194639.11328.270.camel@localhost>
	<4AA3C78C.6010200@googlemail.com> <4AA3D834.6050605@gmail.com>
	<4AA3E9F8.7030106@googlemail.com> <4AA41914.50805@gmail.com>
Message-ID: <4AA56842.1060803@googlemail.com>

Edwin,

thanks, it starts making sense

inline comments...

T?r?k Edwin wrote:
> On 2009-09-06 19:57, Ioannis Nousias wrote:
>   
>> Edwin,
>>
>> thank you for your effort, but I'm not sure I understand.
>> Are you describing a graph traversal problem? Is the data model stored
>> in a predecessor/successor fashion, which requires you to 'walk' the
>> graph in order to visit all nodes? (and what happens when you have
>> disjointed DFGs?).
>>     
>
> Sorry for the confusion, it was only an example on how to use the
> dataflow graphs from DataFlow.h, you don't need depth-first iteration to
> implement dot graphs for DFGs.
>
> Disjoint DFGs are the reason I mentioned the need to walk all
> instructions/arguments in order to get all DFGs.
> If you are only interested in a DFG starting from a particular Value*,
> then forget about the iteration I mentioned.
>
> I think your fundamental problem was that there is already a Graph for
> Function*, the CFG, and you want a DFG Graph.
>
>   
yes that's right, the CFG is getting in the way

> I think you could do something like this:
> template <typename T>
> class DFG {
> private:
>   T p;
> public:
>   DFG(T t) : p(t) {}
>   T operator*() { return p; }
> };
> template <> struct GraphTraits<DFG<Function*> > : public
> GraphTraits<Value*> {
>   typedef inst_iterator nodes_iterator;
>   static nodes_iterator nodes_begin(DFG<Function *> F) {
>     return inst_begin(*F);
>   }
>   static nodes_iterator nodes_end(DFG<Function *> F) {
>     return inst_end(*F);
>   }
> };
>
> ...
>   ViewGraph(DFG<Function*>(F), "test");
>
> Then you could implement a DOTGraphTraits for DFG<Function*>.
>
>   
ok I'll give it a try.

>> inline comments follow...
>>
>> T?r?k Edwin wrote:
>>     
>>> On 2009-09-06 17:30, Ioannis Nousias wrote:
>>>  
>>>       
>>>> I've tried to write a DFGPrinter based on the CFGPrinter, as you
>>>> suggested, but encountered problems.
>>>>
>>>> The GraphWriter expects
>>>> GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is
>>>> implemented in CFG.h, a function is a graph of basic blocks. A
>>>> GraphTraits<Function*>  inherits from GraphTraits<BasicBlock*>, and
>>>> implements those nodes_begin()/nodes_end() wrapper functions. Should
>>>> I modify CFG.h and make now BasicBlock a graph of Instruction(s) ?
>>>>
>>>> The DataFlow.h deals with Value and User. Now BasicBlock is derived
>>>> from Value and Instruction from User, but I don't understand how
>>>> that helps.
>>>>
>>>> It's a bit confusing to be honest. Can you help?
>>>>       
>>>>         
>>> Here are some examples on how to use the dataflow graphs:
>>>
>>> Value *V = ...
>>> for(df_iterator<Value*> UI = df_begin(V), UE = df_end(V); UI != UE;
>>> ++UI) {
>>> ...
>>> }
>>>
>>>
>>> typedef SmallPtrSet<const Value*, 16> SmallValueSet;
>>> SmallValueSet DFSet;
>>> const User* U = ...;
>>> for (idf_ext_iterator<const User*, SmallValueSet> I=idf_ext_begin(U,
>>> DFSet), E=idf_ext_end(U, DFSet); I != E; ++I) {
>>> ..
>>> }
>>>
>>>
>>>   
>>>       
>> I don't understand why I'd need a depth-first iterator.
>>     
>
> It was just an example to show something that uses the GraphTraits from
> DataFlow.h.
>
>   
>>     
>>> There is no common root for the dataflow graph from which you can
>>> enumerate all dataflows, but you could take
>>> each instruction in a function that you're interested in, and output a
>>> dataflow graph rooted at that instruction,
>>> unless that instruction was part of some other dataflow graph already.
>>>
>>>   
>>>       
>> from this I'm getting that you suggest finding all "root" instructions
>> and traverse each chain of instruction (data-flow) separately.
>> Considering that most dataflows are not simple expanding trees, and
>> are instead merging and spliting at several points, I'm not sure what
>> good that would do.
>>     
>
> int foo(int b, int c)
> {
> int a = b+4;
> int z = a+c;
> int y = c+1;
> ..
> }
>
> If you start writing out the dataflow for 'b', then the graph contains
> only 'a' and 'z'. If you start at 'c' the graph will contain only 'z'
> and 'y'.
> This is unlike CFG graphs where the entrypoint in a function is the root
> of the CFG for that function, the DFG graphs are disjoint in this case.
>
>   
>>> Perhaps something like:
>>>
>>> SmallValueSet PrintedSet;
>>> for (Function::arg_iterator I=F.arg_begin(), E=F.arg_end(); I != E;
>>> ++I) {
>>>        if (!PrintedSet.count(*I)) {
>>>              ... print graph rooted at V, add each node printed to
>>> PrintedSet
>>>       }   }
>>> for (inst_iterator I=inst_begin(F), E=inst_end(F); I != E; ++I) {
>>>        if (!PrintedSet.count(*I)) {
>>>              ... print graph rooted at V, add each node printed to
>>> PrintedSet
>>>       }   }
>>>
>>> Best regards,
>>> --Edwin
>>>   
>>>       
>> Most likely I'm missing some information here. There's probably some
>> internal structure, probably how the data-model is build, that
>> requires this sort of traversal. Can you elaborate please.
>>
>> What I'm looking for, to start with, is something rather simple (or at
>> least it should be). A per BasicBlock view of their DFGs. I'm not
>> interested in the inter-BasicBlock connections, for now. I'm tempted
>> to just iterate through the instructions container of each BasicBlock
>> and output the graphviz manually. However, I'd prefer using any
>> facilities present. The way I see it, all I need to do is iterate
>> through the instructions of the BasicBlock, enumerate them to the
>> graphviz data model, then iterate through them once more, checking
>> their predecessor/successor instructions (inputs/outputs), to register
>> their connectivity (edges). Right?
>>     
>
>
> Well the GraphTraits in DataFlow.h are really simple, LLVM's graph
> algorithms expect
> a child_begin()/child_end(), so DataFlow.h only maps
> child_begin/child_end to use_begin/use_end, and op_begin/op_end for the
> Def-Use, and Use-Def graphs respectively.
> That however doesn't know of any basicblock boundaries, it enumerates
> *all* uses of a value, so I think that writing out a full DFG is easier
> than writing out a partial one.
>
>   
ok I see


thanks,
Ioannis




From ioannis.nousias at googlemail.com  Mon Sep  7 15:08:48 2009
From: ioannis.nousias at googlemail.com (Ioannis Nousias)
Date: Mon, 07 Sep 2009 21:08:48 +0100
Subject: [LLVMdev] Graphviz and LLVM-TV
In-Reply-To: <4AA41914.50805@gmail.com>
References: <4A8437A8.4040606@googlemail.com>		<58FA02CE-B68E-466C-9E84-CCF378489A45@apple.com>		<25381_1250181387_4A84410B_25381_341_1_4A843C90.4030307@googlemail.com>		<1250183964.11328.63.camel@localhost>		<25381_1250188295_4A845C07_25381_974_1_4A845C03.3090804@googlemail.com>	<1250194639.11328.270.camel@localhost>
	<4AA3C78C.6010200@googlemail.com> <4AA3D834.6050605@gmail.com>
	<4AA3E9F8.7030106@googlemail.com> <4AA41914.50805@gmail.com>
Message-ID: <4AA56850.7080109@googlemail.com>

Edwin,

thanks, it starts making sense

inline comments...

T?r?k Edwin wrote:
> On 2009-09-06 19:57, Ioannis Nousias wrote:
>   
>> Edwin,
>>
>> thank you for your effort, but I'm not sure I understand.
>> Are you describing a graph traversal problem? Is the data model stored
>> in a predecessor/successor fashion, which requires you to 'walk' the
>> graph in order to visit all nodes? (and what happens when you have
>> disjointed DFGs?).
>>     
>
> Sorry for the confusion, it was only an example on how to use the
> dataflow graphs from DataFlow.h, you don't need depth-first iteration to
> implement dot graphs for DFGs.
>
> Disjoint DFGs are the reason I mentioned the need to walk all
> instructions/arguments in order to get all DFGs.
> If you are only interested in a DFG starting from a particular Value*,
> then forget about the iteration I mentioned.
>
> I think your fundamental problem was that there is already a Graph for
> Function*, the CFG, and you want a DFG Graph.
>
>   
yes that's right, the CFG is getting in the way

> I think you could do something like this:
> template <typename T>
> class DFG {
> private:
>   T p;
> public:
>   DFG(T t) : p(t) {}
>   T operator*() { return p; }
> };
> template <> struct GraphTraits<DFG<Function*> > : public
> GraphTraits<Value*> {
>   typedef inst_iterator nodes_iterator;
>   static nodes_iterator nodes_begin(DFG<Function *> F) {
>     return inst_begin(*F);
>   }
>   static nodes_iterator nodes_end(DFG<Function *> F) {
>     return inst_end(*F);
>   }
> };
>
> ...
>   ViewGraph(DFG<Function*>(F), "test");
>
> Then you could implement a DOTGraphTraits for DFG<Function*>.
>
>   
ok I'll give it a try.

>> inline comments follow...
>>
>> T?r?k Edwin wrote:
>>     
>>> On 2009-09-06 17:30, Ioannis Nousias wrote:
>>>  
>>>       
>>>> I've tried to write a DFGPrinter based on the CFGPrinter, as you
>>>> suggested, but encountered problems.
>>>>
>>>> The GraphWriter expects
>>>> GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is
>>>> implemented in CFG.h, a function is a graph of basic blocks. A
>>>> GraphTraits<Function*>  inherits from GraphTraits<BasicBlock*>, and
>>>> implements those nodes_begin()/nodes_end() wrapper functions. Should
>>>> I modify CFG.h and make now BasicBlock a graph of Instruction(s) ?
>>>>
>>>> The DataFlow.h deals with Value and User. Now BasicBlock is derived
>>>> from Value and Instruction from User, but I don't understand how
>>>> that helps.
>>>>
>>>> It's a bit confusing to be honest. Can you help?
>>>>       
>>>>         
>>> Here are some examples on how to use the dataflow graphs:
>>>
>>> Value *V = ...
>>> for(df_iterator<Value*> UI = df_begin(V), UE = df_end(V); UI != UE;
>>> ++UI) {
>>> ...
>>> }
>>>
>>>
>>> typedef SmallPtrSet<const Value*, 16> SmallValueSet;
>>> SmallValueSet DFSet;
>>> const User* U = ...;
>>> for (idf_ext_iterator<const User*, SmallValueSet> I=idf_ext_begin(U,
>>> DFSet), E=idf_ext_end(U, DFSet); I != E; ++I) {
>>> ..
>>> }
>>>
>>>
>>>   
>>>       
>> I don't understand why I'd need a depth-first iterator.
>>     
>
> It was just an example to show something that uses the GraphTraits from
> DataFlow.h.
>
>   
>>     
>>> There is no common root for the dataflow graph from which you can
>>> enumerate all dataflows, but you could take
>>> each instruction in a function that you're interested in, and output a
>>> dataflow graph rooted at that instruction,
>>> unless that instruction was part of some other dataflow graph already.
>>>
>>>   
>>>       
>> from this I'm getting that you suggest finding all "root" instructions
>> and traverse each chain of instruction (data-flow) separately.
>> Considering that most dataflows are not simple expanding trees, and
>> are instead merging and spliting at several points, I'm not sure what
>> good that would do.
>>     
>
> int foo(int b, int c)
> {
> int a = b+4;
> int z = a+c;
> int y = c+1;
> ..
> }
>
> If you start writing out the dataflow for 'b', then the graph contains
> only 'a' and 'z'. If you start at 'c' the graph will contain only 'z'
> and 'y'.
> This is unlike CFG graphs where the entrypoint in a function is the root
> of the CFG for that function, the DFG graphs are disjoint in this case.
>
>   
>>> Perhaps something like:
>>>
>>> SmallValueSet PrintedSet;
>>> for (Function::arg_iterator I=F.arg_begin(), E=F.arg_end(); I != E;
>>> ++I) {
>>>        if (!PrintedSet.count(*I)) {
>>>              ... print graph rooted at V, add each node printed to
>>> PrintedSet
>>>       }   }
>>> for (inst_iterator I=inst_begin(F), E=inst_end(F); I != E; ++I) {
>>>        if (!PrintedSet.count(*I)) {
>>>              ... print graph rooted at V, add each node printed to
>>> PrintedSet
>>>       }   }
>>>
>>> Best regards,
>>> --Edwin
>>>   
>>>       
>> Most likely I'm missing some information here. There's probably some
>> internal structure, probably how the data-model is build, that
>> requires this sort of traversal. Can you elaborate please.
>>
>> What I'm looking for, to start with, is something rather simple (or at
>> least it should be). A per BasicBlock view of their DFGs. I'm not
>> interested in the inter-BasicBlock connections, for now. I'm tempted
>> to just iterate through the instructions container of each BasicBlock
>> and output the graphviz manually. However, I'd prefer using any
>> facilities present. The way I see it, all I need to do is iterate
>> through the instructions of the BasicBlock, enumerate them to the
>> graphviz data model, then iterate through them once more, checking
>> their predecessor/successor instructions (inputs/outputs), to register
>> their connectivity (edges). Right?
>>     
>
>
> Well the GraphTraits in DataFlow.h are really simple, LLVM's graph
> algorithms expect
> a child_begin()/child_end(), so DataFlow.h only maps
> child_begin/child_end to use_begin/use_end, and op_begin/op_end for the
> Def-Use, and Use-Def graphs respectively.
> That however doesn't know of any basicblock boundaries, it enumerates
> *all* uses of a value, so I think that writing out a full DFG is easier
> than writing out a partial one.
>
>   
ok I see


thanks,
Ioannis




From kuba at gcc.gnu.org  Mon Sep  7 15:49:49 2009
From: kuba at gcc.gnu.org (Jakub Staszak)
Date: Mon, 7 Sep 2009 18:49:49 -0200
Subject: [LLVMdev] PR4882
In-Reply-To: <4AA558AB.3020004@free.fr>
References: <7CCDA687-7448-4284-BE04-678DCF6C6CDA@gcc.gnu.org>
	<4AA558AB.3020004@free.fr>
Message-ID: <C3DD549A-7B1B-473B-92CF-3F0900B9EA77@gcc.gnu.org>


On Sep 7, 2009, at 5:02 PM, Duncan Sands wrote:

> Hi Jakub, looks good.
>
>> +  LLVMContext *Context = &SI->getContext();
>
> I guess this could be
>  LLVMContext &Context = SI->getContext();
> which means you can use Context rather than *Context below.

Right, C bad habit ;) Fixed.

>> -      const Type *Ty = Type::getInt64Ty(SI->getContext());
>> -      MemSetF = Intrinsic::getDeclaration(M, Intrinsic::memset,  
>> &Ty, 1);
>> +      const Type *Tys[] = {Type::getInt64Ty(*Context)};
>> +      MemSetF = Intrinsic::getDeclaration(M, Intrinsic::memset,
>> +                                          Tys, 1);
>
> Why did you introduce Tys and not stick with Ty?

Ah, I did "svn update" after my correction and I didn't notice that.  
Fixed.

I also added "-disable-output" to test-case.

-Jakub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr4882-2.patch
Type: application/octet-stream
Size: 6696 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090907/b766cf19/attachment.obj 

From mlyle at translattice.com  Mon Sep  7 16:27:37 2009
From: mlyle at translattice.com (Michael Lyle)
Date: Mon, 7 Sep 2009 14:27:37 -0700
Subject: [LLVMdev] 2.6 request - Bug 4879
Message-ID: <C433FD4D-BF4D-412D-A6F1-93C8A1106806@translattice.com>

First-- thanks to Daniel Dunbar for reporting this issue from my  
earlier coarse report on IRC and to Devang Patel for fixing it.

I'm writing to request that this fix (r81058) find its way into the  
2.6 release.  Code compiled with clang that uses VLAs is horribly  
broken without r81058 (at least on x86-64).  I don't know if it has  
any other implications but it's definitely greatly stabilizing for our  
code base.

Thanks,

Mike

PS -- I am not subscribed to this list.

-- 
Michael P. Lyle
Chief Executive Officer
Translattice, Inc.
mlyle at translattice.com


From clattner at apple.com  Mon Sep  7 19:28:23 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 7 Sep 2009 17:28:23 -0700
Subject: [LLVMdev] PR4882
In-Reply-To: <C3DD549A-7B1B-473B-92CF-3F0900B9EA77@gcc.gnu.org>
References: <7CCDA687-7448-4284-BE04-678DCF6C6CDA@gcc.gnu.org>
	<4AA558AB.3020004@free.fr>
	<C3DD549A-7B1B-473B-92CF-3F0900B9EA77@gcc.gnu.org>
Message-ID: <FCB0B42F-9797-4D6D-A2FD-5D8FEAEA05D6@apple.com>


On Sep 7, 2009, at 1:49 PM, Jakub Staszak wrote:

>
> On Sep 7, 2009, at 5:02 PM, Duncan Sands wrote:
>
>> Hi Jakub, looks good.
>>
>>> +  LLVMContext *Context = &SI->getContext();
>>
>> I guess this could be
>> LLVMContext &Context = SI->getContext();
>> which means you can use Context rather than *Context below.
>
> Right, C bad habit ;) Fixed.
>
>>> -      const Type *Ty = Type::getInt64Ty(SI->getContext());
>>> -      MemSetF = Intrinsic::getDeclaration(M, Intrinsic::memset,  
>>> &Ty, 1);
>>> +      const Type *Tys[] = {Type::getInt64Ty(*Context)};
>>> +      MemSetF = Intrinsic::getDeclaration(M, Intrinsic::memset,
>>> +                                          Tys, 1);
>>
>> Why did you introduce Tys and not stick with Ty?
>
> Ah, I did "svn update" after my correction and I didn't notice that.  
> Fixed.
>
> I also added "-disable-output" to test-case.

Thanks!  I hand minimized the testcase a bit, applied as r81175.

-Chris

From npickito at gmail.com  Mon Sep  7 20:43:14 2009
From: npickito at gmail.com (kito)
Date: Tue, 8 Sep 2009 09:43:14 +0800
Subject: [LLVMdev] About llvm's capability
Message-ID: <5fe70660909071843h61359a36vb5d71d7e64bcd549@mail.gmail.com>

Hello everybody

I am newbie in llvm and compiler, I have some questions about llvm's
capability - How large project llvm can compile now?
I mean, such as linux kernel or ggc...llvm can build it?
especially on the other architecture, ARM or alpha
because I must choice one between gcc and llvm to study.
In my long tern, I will port some other architecture to gcc or llvm.

In fact, I prefer like llvm because the code is more structure and
easy to understand than gcc.

thanks.

From clattner at apple.com  Mon Sep  7 20:49:30 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 7 Sep 2009 18:49:30 -0700
Subject: [LLVMdev] Sparc debug info patch
In-Reply-To: <4AA41CF2.3050007@pennware.com>
References: <4AA41CF2.3050007@pennware.com>
Message-ID: <59AD539D-5CA1-4F85-883E-455D73DBD391@apple.com>


On Sep 6, 2009, at 1:34 PM, Richard Pennington wrote:

> Please review the enclosed patch for Sparc debug info.
> I have been able to view source files, set breakpoints, and single  
> step source lines after applying this patch. I can't view variables  
> because I haven't implemented Dwarf type data, yet.

Cool!  I'm glad to see progress on the sparc backend:

+++ lib/Target/Sparc/AsmPrinter/SparcAsmPrinter.cpp	(working copy)
@@ -44,6 +44,8 @@

  namespace {
    class VISIBILITY_HIDDEN SparcAsmPrinter : public AsmPrinter {
+    DwarfWriter *DW;
+

This shouldn't be needed, the AsmPrinter base class now has this.   
This allows you to remove SparcAsmPrinter::doInitialization.

Otherwise, looks great, please apply.

-Chris



From clattner at apple.com  Mon Sep  7 22:50:07 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 7 Sep 2009 20:50:07 -0700
Subject: [LLVMdev] TOT opt does not terminate!
In-Reply-To: <14DD0B1CD80F5C46841ED44E4CC2CAA330494C@seurexmb2.amd.com>
References: <14DD0B1CD80F5C46841ED44E4CC2CAA330494C@seurexmb2.amd.com>
Message-ID: <6539417A-CFB0-4644-A8C0-0F6DACBA6EC7@apple.com>


On Sep 4, 2009, at 9:37 AM, Gaster, Benedict wrote:

> The following code causes opt to not terminate!

This works for me now, please file bugs when you hit problems.

-Chris


>
> With TOT this morning, and of a week ago:
>
> clang foo.c and clang ?O1 foo.c
>
> work fine.
>
> clang ?O2 foo.c and clang ?O3 foo.c
>
> do not terminate. (At least after 10 minutes)
>
> If I generate the bit code (clang-cc ?emit-llvmbc) and then run:
>
> opt ?O3 foo.bc
>
> it does not terminate.
>
> //foo.c
> int get_id(int);
>
> typedef short short2 __attribute__ ((vector_size (2)));
>
> union _X {
>     short2 s;
>     int i;
> };
>
> typedef union _X X;
>
> inline short2 as_short2(int x)
> {
>     X result;
>
>     result.i = x;
>     return result.s;
> }
>
> inline int as_int(short2 x)
> {
>     X result;
>
>     result.s = x;
>     return result.i;
> }
>
> void short2_int_swap(
>   short2* b,
>   int* c)
> {
>     int gidx = get_id(0);
>     short2 bval = b[gidx];
>     int cval = c[gidx];
>
>     b[gidx] = as_short2(cval);
>     c[gidx] = as_int(bval);
> }
> _______________________________________________
> 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/20090907/dad04ca8/attachment.html 

From clattner at apple.com  Mon Sep  7 23:19:29 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 7 Sep 2009 21:19:29 -0700
Subject: [LLVMdev] 2.6 request - Bug 4879
In-Reply-To: <C433FD4D-BF4D-412D-A6F1-93C8A1106806@translattice.com>
References: <C433FD4D-BF4D-412D-A6F1-93C8A1106806@translattice.com>
Message-ID: <3594D394-1F67-4097-A3FD-C0AFAC0AB64B@apple.com>

On Sep 7, 2009, at 2:27 PM, Michael Lyle wrote:
First-- thanks to Daniel Dunbar for reporting this issue from my
> earlier coarse report on IRC and to Devang Patel for fixing it.
>
> I'm writing to request that this fix (r81058) find its way into the
> 2.6 release.  Code compiled with clang that uses VLAs is horribly
> broken without r81058 (at least on x86-64).  I don't know if it has
> any other implications but it's definitely greatly stabilizing for our
> code base.

Makes sense.

Tanya, please pull http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090831/086443.html 
  into 2.6 when convenient, thanks!


-Chris

>
> Thanks,
>
> Mike
>
> PS -- I am not subscribed to this list.
>
> -- 
> Michael P. Lyle
> Chief Executive Officer
> Translattice, Inc.
> mlyle at translattice.com
>
> _______________________________________________
> 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  Tue Sep  8 00:16:07 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 7 Sep 2009 22:16:07 -0700
Subject: [LLVMdev] Error in Hello World Pass
In-Reply-To: <bf0e41fc0909041029q3d9cdefnfa35a91635a49739@mail.gmail.com>
References: <bf0e41fc0909041029q3d9cdefnfa35a91635a49739@mail.gmail.com>
Message-ID: <83EE2EE5-12FA-4EEA-91D8-DE13C52071AE@apple.com>


On Sep 4, 2009, at 10:29 AM, Rakesh Komuravelli wrote:

> Hi,
>
> I am trying to compile the Hello World pass (described at http://llvm.org/docs/WritingAnLLVMPass.html#basiccode 
> ) in an LLVM Project and I get an error, 'no match for ?operator<<?  
> at line
> llvm::cerr << "Hello: " << F.getName() << "\n";
> But when I looked up in the LLVM API Documentation, I think "<<"  
> operator is not overloaded for the StringRef class returned by  
> getName() of the Function class. If I replace the above line with
> llvm::cerr << "Hello: " << F.getName().str() << "\n";
> it compiles fine. I was just wondering if its a bug in the document  
> describing the Hello World pass or am I referring it incorrectly?

I updated the documentation.  You should use errs() From raw_ostream.h  
now, thanks.

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

From isanbard at gmail.com  Tue Sep  8 01:36:24 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 7 Sep 2009 23:36:24 -0700
Subject: [LLVMdev] About llvm's capability
In-Reply-To: <5fe70660909071843h61359a36vb5d71d7e64bcd549@mail.gmail.com>
References: <5fe70660909071843h61359a36vb5d71d7e64bcd549@mail.gmail.com>
Message-ID: <9CC9FCE2-610D-4130-B022-1D4470E22AB1@gmail.com>

On Sep 7, 2009, at 6:43 PM, kito wrote:

> Hello everybody
>
> I am newbie in llvm and compiler, I have some questions about llvm's
> capability - How large project llvm can compile now?
> I mean, such as linux kernel or ggc...llvm can build it?
> especially on the other architecture, ARM or alpha
> because I must choice one between gcc and llvm to study.
> In my long tern, I will port some other architecture to gcc or llvm.
>
> In fact, I prefer like llvm because the code is more structure and
> easy to understand than gcc.
>
Hi Kito,

LLVM is capable of compiling many big projects. It's used at several  
companies to do just that. And I think that the Linux Kernel has been  
compiled by someone...

So, it should be capable of compiling whatever you need it to. There  
may be bugs, of course. But that's going to be the same with any  
compiler. :-)

-bw


From astifter-llvm at gmx.at  Tue Sep  8 03:27:02 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Tue, 08 Sep 2009 10:27:02 +0200
Subject: [LLVMdev] [PATCH] & Question: Preserving ProfileInfo for backend.
Message-ID: <4AA61556.6090300@gmx.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

the second part of my work is to preserve the profiling information
through all the transformation passes and make it available to the
backend machinery.

Attached is an example patch on how I plan to preserve the information
for a given transformation pass.

And now comes the question into place: whats the best way to attach the
profile info also the MachineBlocks and MachineFunctions? I was thinking
of converting the ProfileInfo into a template and using it for both
BasicBlocks and MachineBasicBlocks.

And where is the best point to transfer this information from the
bytecode CFG to the machinecode CFG?

Thanks, Andi

- --
==========================================================================
This email is signed, for more information see
http://web.student.tuwien.ac.at/~e0325716/gpg.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqmFVYACgkQPiYq0rq7s/AxcgCggdPJqtjo8aujpZ6NxtQTQVBY
TrEAnRrwHSHToDA6t8p4zqVVWdahj585
=8kyz
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-r81204.preserve.profiling.info.patch
Type: text/x-patch
Size: 2157 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090908/ab02c8b2/attachment.bin 

From rich at pennware.com  Tue Sep  8 06:45:12 2009
From: rich at pennware.com (Richard Pennington)
Date: Tue, 08 Sep 2009 06:45:12 -0500
Subject: [LLVMdev] Status update (was Re:  Sparc debug info patch)
In-Reply-To: <59AD539D-5CA1-4F85-883E-455D73DBD391@apple.com>
References: <4AA41CF2.3050007@pennware.com>
	<59AD539D-5CA1-4F85-883E-455D73DBD391@apple.com>
Message-ID: <4AA643C8.8060506@pennware.com>

Chris Lattner wrote:
> Cool!  I'm glad to see progress on the sparc backend:
> 
> +++ lib/Target/Sparc/AsmPrinter/SparcAsmPrinter.cpp    (working copy)
> @@ -44,6 +44,8 @@
> 
>  namespace {
>    class VISIBILITY_HIDDEN SparcAsmPrinter : public AsmPrinter {
> +    DwarfWriter *DW;
> +
> 
> This shouldn't be needed, the AsmPrinter base class now has this.  This 
> allows you to remove SparcAsmPrinter::doInitialization.
> 
> Otherwise, looks great, please apply.

Thanks Chris,

I'm in the process of syncing up with TOT, after which I'll test and 
apply the patch.

Just to keep you up to date about what I'm doing...

I'm trying to set up a code generator test bed, initially for all the 
targets supported by both LLVM and qemu.

I've put together a standard library consisting of newlib, soft-flt, and 
compiler-rt. Currently I'm targeting Linux, but I'm trying to isolate 
the OS specific bits so that eventually I'll be targeting other OSes and 
bare metal.

I can use qemu in Linux user mode to execute and debug programs for the 
x86, ARM, and Sparc so far. I have some code generation issues with 
powerpc and mips (e.g. http://llvm.org/bugs/show_bug.cgi?id=4851) but I 
think things are progressing fairly well.

I do have a question however: Which code generators currently fully 
support debug information? I know the x86 generator does, but ARM and 
Sparc seem to ignore local variable information. since I'm coming in 
with little familiarity with the LLVM debug info stuff, where should I 
look to come up to speed?

-Rich

From andrewl at lenharth.org  Tue Sep  8 07:46:56 2009
From: andrewl at lenharth.org (Andrew Lenharth)
Date: Tue, 8 Sep 2009 07:46:56 -0500
Subject: [LLVMdev] About llvm's capability
In-Reply-To: <9CC9FCE2-610D-4130-B022-1D4470E22AB1@gmail.com>
References: <5fe70660909071843h61359a36vb5d71d7e64bcd549@mail.gmail.com>
	<9CC9FCE2-610D-4130-B022-1D4470E22AB1@gmail.com>
Message-ID: <85dfcd7f0909080546p2b0527d8xe2cf54f6d30945e4@mail.gmail.com>

On Tue, Sep 8, 2009 at 1:36 AM, Bill Wendling<isanbard at gmail.com> wrote:
> On Sep 7, 2009, at 6:43 PM, kito wrote:
>
>> Hello everybody
>>
>> I am newbie in llvm and compiler, I have some questions about llvm's
>> capability - How large project llvm can compile now?
>> I mean, such as linux kernel or ggc...llvm can build it?
>> especially on the other architecture, ARM or alpha
>> because I must choice one between gcc and llvm to study.
>> In my long tern, I will port some other architecture to gcc or llvm.
>>
>> In fact, I prefer like llvm because the code is more structure and
>> easy to understand than gcc.
>>
> Hi Kito,
>
> LLVM is capable of compiling many big projects. It's used at several
> companies to do just that. And I think that the Linux Kernel has been
> compiled by someone...

Yes, I have whole kernel bitcode for linux (x86 amd amd64).

Andrew

From kennethuil at gmail.com  Tue Sep  8 08:16:35 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 8 Sep 2009 08:16:35 -0500
Subject: [LLVMdev] llc crash when a const struct includes a zero-length
	member
In-Reply-To: <400d33ea0909051934k73077770jd3a9da5fcf054c94@mail.gmail.com>
References: <400d33ea0909051934k73077770jd3a9da5fcf054c94@mail.gmail.com>
Message-ID: <400d33ea0909080616l1baed5b9q77986cb537bce3f4@mail.gmail.com>

I just realized that I could get a bugzilla account.  I put it in
against the product "new-bugs" and it became Bug 4925.

From kuba at gcc.gnu.org  Tue Sep  8 10:20:25 2009
From: kuba at gcc.gnu.org (Jakub Staszak)
Date: Tue, 8 Sep 2009 13:20:25 -0200
Subject: [LLVMdev] PR4909
Message-ID: <3E1AFF38-88FD-40EA-913D-B70514CF42E9@gcc.gnu.org>

Hello,

This patch fixes PR4909.

-Jakub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr4909.patch
Type: application/octet-stream
Size: 1124 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090908/f5241ea3/attachment-0001.obj 

From criswell at cs.uiuc.edu  Tue Sep  8 10:32:04 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Tue, 8 Sep 2009 10:32:04 -0500
Subject: [LLVMdev] LLVM 2.6 Branch Fails to Compile
Message-ID: <4AA678F4.5050409@cs.uiuc.edu>

Dear All,

The LLVM 2.6 Release Branch doesn't compile for me on Mac OS X.  The
following patch seems to fix it (it adds a missing include file to get
WeakVH defined).

Has anyone else seen this breakage, or is it possible that I've got the
wrong branch checked out?

-- John T.

Index: lib/Transforms/Scalar/DeadStoreElimination.cpp
===================================================================
--- lib/Transforms/Scalar/DeadStoreElimination.cpp      (revision 81219)
+++ lib/Transforms/Scalar/DeadStoreElimination.cpp      (working copy)
@@ -30,6 +30,8 @@
 #include "llvm/Target/TargetData.h"
 #include "llvm/Transforms/Utils/Local.h"
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/ValueHandle.h"
+
 using namespace llvm;

 STATISTIC(NumFastStores, "Number of stores deleted");



From clattner at apple.com  Tue Sep  8 10:34:13 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 8 Sep 2009 08:34:13 -0700
Subject: [LLVMdev] Status update (was Re:  Sparc debug info patch)
In-Reply-To: <4AA643C8.8060506@pennware.com>
References: <4AA41CF2.3050007@pennware.com>
	<59AD539D-5CA1-4F85-883E-455D73DBD391@apple.com>
	<4AA643C8.8060506@pennware.com>
Message-ID: <F7FC6915-471B-4549-BB70-30AD3B202A5A@apple.com>


On Sep 8, 2009, at 4:45 AM, Richard Pennington wrote:

>
> I do have a question however: Which code generators currently fully
> support debug information? I know the x86 generator does, but ARM and
> Sparc seem to ignore local variable information. since I'm coming in
> with little familiarity with the LLVM debug info stuff, where should I
> look to come up to speed?

I think that PPC and X86 are the only ones with full support so far,

-Chris

From kuba at gcc.gnu.org  Tue Sep  8 11:26:54 2009
From: kuba at gcc.gnu.org (Jakub Staszak)
Date: Tue, 8 Sep 2009 14:26:54 -0200
Subject: [LLVMdev] Non-local DSE optimization
In-Reply-To: <4AA36E3C.7070507@mxc.ca>
References: <830819AC-2A14-435D-86FE-CB09F73F31F6@gcc.gnu.org>	<4A9F86F4.3070609@free.fr>
	<273A970E-E76D-4BC0-8EF0-64E9C391DA6F@gcc.gnu.org>
	<4AA36E3C.7070507@mxc.ca>
Message-ID: <E2502CE4-E9D7-4A31-8864-28B6F5544165@gcc.gnu.org>

Hello,

Bug is already fixed by Chris (see: http://llvm.org/bugs/show_bug.cgi?id=4915) 
.

I added getRootNode() == NULL condition to my patch. It's not a great  
solution, but it is enough for now I think. New patch attached.

-Jakub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dse_ssu-2.patch
Type: application/octet-stream
Size: 17762 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090908/e8d20e71/attachment.obj 
-------------- next part --------------

On Sep 6, 2009, at 6:09 AM, Nick Lewycky wrote:

> Jakub Staszak wrote:
>> Hi,
>> It looks like PDT.getRootNode() returns NULL for:
>> define fastcc void @c974001__lengthy_calculation.  
>> 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn {
>> entry:
>>   br label %bb
>> bb:
>>   br label %bb
>> }
>> Isn't it a bug in PostDominatorTree?
>> Please note that this crashes:
>> opt -postdomtree -debug dom_crash.bc
>> I think this should be reported as a bug,
>
> Yes, that's a bug. Please file it.
>
> The PDT root calculation is looking for all BBs with no successors,  
> this won't work in the face of loops. Either we need to teach PDT  
> users that there can be zero roots, or we need to synthesize a fake  
> root.
>
> The latter is already supported (to handle multiple exits) so that's  
> probably the easiest fix.
>
> Nick
>
>> -Jakub
>> On Sep 3, 2009, at 7:05 AM, Duncan Sands wrote:
>>> Hi Jakub, interesting patch.  I ran it over the Ada testsuite and  
>>> this
>>> picked up some problems even without enabling dse-ssu.  For example,
>>> "opt -inline -dse -domtree" crashes on the attached testcase.
>>>
>>> Ciao,
>>>
>>> Duncan.
>>> ; ModuleID = 'dom_crash.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"
>>>
>>> %struct.FRAME.c974001 = type { i32, i8, void   
>>> (%struct.c974001__timed_calculation*)* }
>>> %struct.FRAME.c974001__timed_calculationB = type   
>>> { %struct.FRAME.c974001*, i32 }
>>> %struct.FRAME.c974001__timed_calculation__calculationA = type   
>>> { %struct.system__tasking__async_delays__delay_block }
>>> %struct.RETURN = type { i32, i32 }
>>> %struct.ada__exceptions__exception_occurrence = type   
>>> { %struct.system__standard_library__exception_data*, i32, [200 x   
>>> i8], i8, i8, i32, i32, [50 x i32], i32 }
>>> %struct.c974001__timed_calculation = type   
>>> { %struct.system__tasking__ada_task_control_block* }
>>> %struct.system__os_interface__pthread_mutex_t = type { i32, i32,   
>>> i32, i32, %struct.RETURN }
>>> %struct.system__soft_links__tsd = type   
>>> { %struct.system__stack_checking__stack_info, i32, i32,   
>>> %struct.ada__exceptions__exception_occurrence }
>>> %struct.system__stack_checking__stack_info = type { i32, i32, i32 }
>>> %struct.system__stack_usage__stack_analyzer = type { [32 x i8],  
>>> i32,  i32, i32, i32, i32, i32, i32, i8, i32 }
>>> %struct.system__standard_library__exception_data = type { i8, i8,   
>>> i32, i32, %struct.system__standard_library__exception_data*, i32,   
>>> void ()* }
>>> %struct.system__task_primitives__private_data = type { i32, i32,  
>>> [48  x i8], %struct.system__os_interface__pthread_mutex_t }
>>> %struct.system__tasking__accept_alternative = type { i8, i32 }
>>> %struct.system__tasking__accept_list_access = type { [0 x   
>>> %struct.system__tasking__accept_alternative]*, %struct.RETURN* }
>>> %struct.system__tasking__ada_task_control_block = type { i32,   
>>> %struct.system__tasking__common_atcb, [19 x   
>>> %struct.system__tasking__entry_call_record], i32,   
>>> %struct.system__tasking__accept_list_access, i32, i32, i32, i32,   
>>> i32, i8, i8, i8, i8, i8, i8, i8, i8, i32, i32, i32, i64, i32,  
>>> i32,  [4 x i32], i8, i32*, [0 x  
>>> %struct.system__tasking__entry_queue] }
>>> %struct.system__tasking__async_delays__delay_block = type   
>>> { %struct.system__tasking__ada_task_control_block*, i32, i64, i8,   
>>> %struct.system__tasking__async_delays__delay_block*,   
>>> %struct.system__tasking__async_delays__delay_block* }
>>> %struct.system__tasking__common_atcb = type { i8,   
>>> %struct.system__tasking__ada_task_control_block*, i32, i32, i32,  
>>> [32  x i8], i32, %struct.system__tasking__entry_call_record*,   
>>> %struct.system__task_primitives__private_data, i32, void (i32)*,   
>>> %struct.system__soft_links__tsd,   
>>> %struct.system__tasking__ada_task_control_block*,   
>>> %struct.system__tasking__ada_task_control_block*,   
>>> %struct.system__tasking__ada_task_control_block*, i32, i8*, i8,  
>>> i8,  %struct.system__stack_usage__stack_analyzer, i32,   
>>> %struct.system__tasking__termination_handler,   
>>> %struct.system__tasking__termination_handler }
>>> %struct.system__tasking__entry_call_record = type   
>>> { %struct.system__tasking__ada_task_control_block*, i8, i8, i32,   
>>> %struct.system__standard_library__exception_data*,   
>>> %struct.system__tasking__entry_call_record*,   
>>> %struct.system__tasking__entry_call_record*, i32, i32, i32,   
>>> %struct.system__tasking__ada_task_control_block*, i32,   
>>> %struct.system__tasking__entry_call_record*, i32, i8, i8, i8 }
>>> %struct.system__tasking__entry_queue = type   
>>> { %struct.system__tasking__entry_call_record*,   
>>> %struct.system__tasking__entry_call_record* }
>>> %struct.system__tasking__termination_handler = type { i32, void   
>>> (i32, i8, %struct.system__tasking__ada_task_control_block*,   
>>> %struct.ada__exceptions__exception_occurrence*)* }
>>>
>>> @C.168.1967 = external constant %struct.RETURN    ; <  
>>> %struct.RETURN*> [#uses=1]
>>>
>>> define void  @system__tasking__activation_chainIP  
>>> (%struct.c974001__timed_calculation* nocapture %_init) nounwind {
>>> entry:
>>> ret void
>>> }
>>>
>>> define void @_ada_c974001() {
>>> entry:
>>> %tramp = call i8* @llvm.init.trampoline(i8* undef, i8* bitcast   
>>> (void (%struct.FRAME.c974001*,  
>>> %struct.c974001__timed_calculation*)*   
>>> @c974001__timed_calculationB.1770 to i8*), i8* undef) ; <i8*>   
>>> [#uses=0]
>>> unreachable
>>> }
>>>
>>> declare i8* @llvm.init.trampoline(i8*, i8*, i8*) nounwind
>>>
>>> define fastcc void @c974001__lengthy_calculation.  
>>> 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn {
>>> entry:
>>> br label %bb
>>>
>>> bb:                                               ; preds = %bb,   
>>> %entry
>>> br label %bb
>>> }
>>>
>>> define fastcc void   
>>> @c974001__timed_calculation__calculation__B19b__B21b__A17b___clean 
>>> . 1830(%struct.FRAME.c974001__timed_calculation__calculationA*  
>>> %CHAIN. 188) {
>>> entry:
>>> ret void
>>> }
>>>
>>> define fastcc void @c974001__timed_calculation__calculationA.  
>>> 1820(%struct.FRAME.c974001__timed_calculationB* nocapture %CHAIN.  
>>> 190) {
>>> entry:
>>> br i1 undef, label %bb, label %bb3
>>>
>>> bb:                                               ; preds = %entry
>>> unreachable
>>>
>>> bb3:                                              ; preds = %entry
>>> br i1 undef, label %bb4, label %bb5
>>>
>>> bb4:                                              ; preds = %bb3
>>> unreachable
>>>
>>> bb5:                                              ; preds = %bb3
>>> invoke void undef()
>>>         to label %invcont unwind label %lpad
>>>
>>> invcont:                                          ; preds = %bb5
>>> %0 = invoke i8  
>>> @system__tasking__async_delays__enqueue_duration(i64  undef,  
>>> %struct.system__tasking__async_delays__delay_block* undef)
>>>         to label %bb8 unwind label %lpad        ; <i8> [#uses=0]
>>>
>>> bb8:                                              ; preds = %invcont
>>> invoke void undef()
>>>         to label %invcont9 unwind label %lpad75
>>>
>>> invcont9:                                         ; preds = %bb8
>>> invoke fastcc void @c974001__lengthy_calculation.  
>>> 1736(%struct.FRAME.c974001* undef)
>>>         to label %invcont10 unwind label %lpad75
>>>
>>> invcont10:                                        ; preds =  
>>> %invcont9
>>> invoke void @report__failed([0 x i8]* undef, %struct.RETURN* @C.  
>>> 168.1967)
>>>         to label %bb16 unwind label %lpad75
>>>
>>> bb16:                                             ; preds =  
>>> %invcont10
>>> invoke fastcc void   
>>> @c974001__timed_calculation__calculation__B19b__B21b__A17b___clean 
>>> . 1830(%struct.FRAME.c974001__timed_calculation__calculationA*  
>>> undef)
>>>         to label %bb27 unwind label %lpad71
>>>
>>> bb27:                                             ; preds = %bb16
>>> unreachable
>>>
>>> lpad:                                             ; preds =   
>>> %invcont, %bb5
>>> unreachable
>>>
>>> lpad71:                                           ; preds = %bb16
>>> unreachable
>>>
>>> lpad75:                                           ; preds =   
>>> %invcont10, %invcont9, %bb8
>>> unreachable
>>> }
>>>
>>> declare i8 @system__tasking__async_delays__enqueue_duration(i64,   
>>> %struct.system__tasking__async_delays__delay_block*)
>>>
>>> declare void @report__failed([0 x i8]*, %struct.RETURN*)
>>>
>>> define void @c974001__timed_calculationB. 
>>> 1770(%struct.FRAME.c974001*  nest %CHAIN.191,  
>>> %struct.c974001__timed_calculation* nocapture  %_task) {
>>> entry:
>>> invoke void undef()
>>>         to label %invcont unwind label %lpad
>>>
>>> invcont:                                          ; preds = %entry
>>> invoke void @system__tasking__stages__complete_activation()
>>>         to label %bb unwind label %lpad
>>>
>>> bb:                                               ; preds = %bb5,   
>>> %invcont4, %invcont
>>> invoke void   
>>> @system__tasking__rendezvous__selective_wait(%struct.RETURN*  
>>> noalias  sret undef, [0 x  
>>> %struct.system__tasking__accept_alternative]*  undef,  
>>> %struct.RETURN* undef, i8 2)
>>>         to label %invcont4 unwind label %lpad25
>>>
>>> invcont4:                                         ; preds = %bb
>>> br i1 undef, label %bb5, label %bb
>>>
>>> bb5:                                              ; preds =  
>>> %invcont4
>>> invoke fastcc void @c974001__timed_calculation__calculationA.  
>>> 1820(%struct.FRAME.c974001__timed_calculationB* undef)
>>>         to label %bb unwind label %lpad25
>>>
>>> bb7:                                              ; preds = %lpad25
>>> unreachable
>>>
>>> lpad:                                             ; preds =   
>>> %invcont, %entry
>>> unreachable
>>>
>>> lpad25:                                           ; preds = %bb5,  
>>> %bb
>>> br i1 undef, label %bb7, label %ppad
>>>
>>> ppad:                                             ; preds = %lpad25
>>> unreachable
>>> }
>>>
>>> declare void @system__tasking__stages__complete_activation()
>>>
>>> declare void   
>>> @system__tasking__rendezvous__selective_wait(%struct.RETURN*  
>>> noalias  sret, [0 x  
>>> %struct.system__tasking__accept_alternative]*,  %struct.RETURN*, i8)
>> _______________________________________________
>> 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  Tue Sep  8 12:20:15 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 08 Sep 2009 22:50:15 +0530
Subject: [LLVMdev] Finding the functions whose addresses are taken.
Message-ID: <4AA6924F.3010300@microchip.com>

Hi,
How to find in a module, the list of functions whose addresses are ever 
taken into some variables?

- Sanjiv


From kennethuil at gmail.com  Tue Sep  8 12:23:56 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 8 Sep 2009 12:23:56 -0500
Subject: [LLVMdev] Finding the functions whose addresses are taken.
In-Reply-To: <4AA6924F.3010300@microchip.com>
References: <4AA6924F.3010300@microchip.com>
Message-ID: <400d33ea0909081023k2395418nf009835c9c301624@mail.gmail.com>

Each function is a GlobalValue.  Find all the uses of them... any uses
that are not a "call" with the function as callee goes into your list.

Global variables work the same way.  Find the uses of them that are
not "Load" or "Store" instructions with the global value as the
pointer operand.

On Tue, Sep 8, 2009 at 12:20 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote:
> Hi,
> How to find in a module, the list of functions whose addresses are ever
> taken into some variables?
>
> - Sanjiv
>
> _______________________________________________
> 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 Sep  8 13:21:03 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 8 Sep 2009 11:21:03 -0700
Subject: [LLVMdev] [PATCH] & Question: Preserving ProfileInfo for
	backend.
In-Reply-To: <4AA61556.6090300@gmx.at>
References: <4AA61556.6090300@gmx.at>
Message-ID: <A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com>


On Sep 8, 2009, at 1:27 AM, Andreas Neustifter wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> the second part of my work is to preserve the profiling information
> through all the transformation passes and make it available to the
> backend machinery.
>
> Attached is an example patch on how I plan to preserve the information
> for a given transformation pass.

At a brief glance, this looks good.  It would be helpful to override the
verifyAnalysis method from the Pass class to verify that the profiling
information has been kept current.

>
> And now comes the question into place: whats the best way to attach  
> the
> profile info also the MachineBlocks and MachineFunctions? I was  
> thinking
> of converting the ProfileInfo into a template and using it for both
> BasicBlocks and MachineBasicBlocks.
>
> And where is the best point to transfer this information from the
> bytecode CFG to the machinecode CFG?

The SelectionDAGBuild phase is the only place where the precise  
relationship
between the BasicBlock CFG and the MachineBasicBlock CFG is
known.  It would also be possible to do the transfer in a later phase,  
though that
would require a fair amount of guesswork to determine how the two CFGs
correspond.

This does point out a limitation of doing instrumentation at the LLVM  
IR level;
it won't be able to cover branches inserted during CodeGen.

Dan


From lattner at apple.com  Tue Sep  8 14:07:25 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 8 Sep 2009 12:07:25 -0700
Subject: [LLVMdev] LLVM 2.6 pre1: test failures on Fedora 11.91
	(Rawhide) ppc
In-Reply-To: <615c05430909071053q4bd71d3et6fe72eedc8d536e6@mail.gmail.com>
References: <615c05430909071053q4bd71d3et6fe72eedc8d536e6@mail.gmail.com>
Message-ID: <20AE05AD-6CBE-4CFC-81D7-1FF8EF4C7366@apple.com>

On Sep 7, 2009, at 10:53 AM, Michel Alexandre Salim wrote:

> Hello,
>
> I'm updating Fedora's LLVM to the latest 2.6 prerelease, and
> experiencing test failures on ppc. On x86_64 and x86_32 all tests pass
> as expected.
>

Since we do not have someone to qualify PPC for this release, PPC is  
not officially being supported. If you would like to be a part of the  
release team for 2.7 to qualify PPC, please let me know.

Please file bugs for any test failures. They are not required for 2.6  
though.

Thanks,
Tanya

> http://koji.fedoraproject.org/koji/taskinfo?taskID=1660661
>
> (see root.log to see what packages are installed for the build, and
> build.log for the build log -- 'make check' is called towards the end.
>
> Thanks,
>
> -- 
> Michel Alexandre Salim
> _______________________________________________
> 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/20090908/f3a7bea3/attachment.html 

From lattner at apple.com  Tue Sep  8 14:20:38 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 8 Sep 2009 12:20:38 -0700
Subject: [LLVMdev] Register for the 2009 LLVM Developers' Meeting
Message-ID: <7D55671B-D41D-4886-93EF-B51FC0397C11@apple.com>

The deadline to register for the developers' meeting is September  
20th. Please register here:
http://llvm.org/devmtg/register.php

Registration is required and we will not accept registration after  
September 20th. There are no exceptions! If you did not register for  
dinner and wanted to, you must contact me before this date as well.

If you registered and are no longer able to attend, please email me  
and I will remove you.

Lastly, the hotel cut off date for the special price is September 17th.

Thanks,
Tanya Lattner


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

From Dr.Graef at t-online.de  Tue Sep  8 15:18:16 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Tue, 08 Sep 2009 22:18:16 +0200
Subject: [LLVMdev] LLVM 2.6 Branch Fails to Compile
In-Reply-To: <4AA678F4.5050409@cs.uiuc.edu>
References: <4AA678F4.5050409@cs.uiuc.edu>
Message-ID: <4AA6BC08.6080205@t-online.de>

John Criswell wrote:
> The LLVM 2.6 Release Branch doesn't compile for me on Mac OS X.  The
> following patch seems to fix it (it adds a missing include file to get
> WeakVH defined).
> 
> Has anyone else seen this breakage, or is it possible that I've got the
> wrong branch checked out?

I fails to compile on Linux as well. Has been that way for a few days.

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 xerxes at zafena.se  Tue Sep  8 16:00:54 2009
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Tue, 08 Sep 2009 23:00:54 +0200
Subject: [LLVMdev] sys::MemoryFence() using __sync_synchronize() with GCC on
 ARM does not generate a memory fence
Message-ID: <4AA6C606.5080006@zafena.se>

Andrew Haley brought up this interesting issue on the GCC mailing-list
that directly affect the stability of the ARM llvm target when using
multi-threading.
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00600.html

basically using __sync_synchronize() with GCC on ARM does not generate
any code for the fence.

For what I know:
The only working fix for this issue on Linux would be to create a call
to a high address Linux kernel helper named __kernel_dmb located at
0xffff0fa0 that performs the memory fence correctly dependent on what
kind of ARM CPU the Linux kernel are built against.

I belive ARM Darwin might have a similar issue but i dont know how to
fix it on that platform. ARM Darwin gurus please enlighten me how memory
barriers are performed for ARM on Darwin.

The kernel helper are implemented in
http://kernel.ubuntu.com/git-repos/rtg/linux-2.6/arch/arm/kernel/entry-armv.S
of the Linux sourcetree.

/*
 * Reference prototype:
 *
 *	void __kernel_memory_barrier(void)
 *
 * Input:
 *
 *	lr = return address
 *
 * Output:
 *
 *	none
 *
 * Clobbered:
 *
 *	none
 *
 * Definition and user space usage example:
 *
 *	typedef void (__kernel_dmb_t)(void);
 *	#define __kernel_dmb (*(__kernel_dmb_t *)0xffff0fa0)
 *
 * Apply any needed memory barrier to preserve consistency with data modified
 * manually and __kuser_cmpxchg usage.
 *
 * This could be used as follows:
 *
 * #define __kernel_dmb() \
 *         asm volatile ( "mov r0, #0xffff0fff; mov lr, pc; sub pc, r0, #95" \
 *	        : : : "r0", "lr","cc" )
 */


Cheers
Xerxes







From foldr at codedgers.com  Tue Sep  8 16:01:13 2009
From: foldr at codedgers.com (Mikhail Glushenkov)
Date: Tue, 8 Sep 2009 21:01:13 +0000 (UTC)
Subject: [LLVMdev] Finding the functions whose addresses are taken.
References: <4AA6924F.3010300@microchip.com>
	<400d33ea0909081023k2395418nf009835c9c301624@mail.gmail.com>
Message-ID: <loom.20090908T230044-569@post.gmane.org>

Kenneth Uildriks <kennethuil <at> gmail.com> writes:

> 
> Each function is a GlobalValue.  Find all the uses of them... any uses
> that are not a "call" with the function as callee goes into your list.

One fun possibility is the following "call which is not
a call" (was actually spotted in the wild):

call void (...)* bitcast (void (i32)* @exit to void (...)*)(i32
73) noreturn nounwind


From lattner at apple.com  Tue Sep  8 16:05:45 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 8 Sep 2009 14:05:45 -0700
Subject: [LLVMdev] 2.6 request - Bug 4879
In-Reply-To: <3594D394-1F67-4097-A3FD-C0AFAC0AB64B@apple.com>
References: <C433FD4D-BF4D-412D-A6F1-93C8A1106806@translattice.com>
	<3594D394-1F67-4097-A3FD-C0AFAC0AB64B@apple.com>
Message-ID: <D68AC775-86B8-49F3-A9EA-43D6787E4A2B@apple.com>


On Sep 7, 2009, at 9:19 PM, Chris Lattner wrote:

> On Sep 7, 2009, at 2:27 PM, Michael Lyle wrote:
> First-- thanks to Daniel Dunbar for reporting this issue from my
>> earlier coarse report on IRC and to Devang Patel for fixing it.
>>
>> I'm writing to request that this fix (r81058) find its way into the
>> 2.6 release.  Code compiled with clang that uses VLAs is horribly
>> broken without r81058 (at least on x86-64).  I don't know if it has
>> any other implications but it's definitely greatly stabilizing for  
>> our
>> code base.
>
> Makes sense.
>
> Tanya, please pull http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090831/086443.html 
>  into 2.6 when convenient, thanks!
>

This can not go into 2.6, because r79742 is not in 2.6:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/085284.html

Should this really be a release candidate? Its changing quite a bit  
and its not causing a regression.

-Tanya

>
> -Chris
>
>>
>> Thanks,
>>
>> Mike
>>
>> PS -- I am not subscribed to this list.
>>
>> -- 
>> Michael P. Lyle
>> Chief Executive Officer
>> Translattice, Inc.
>> mlyle at translattice.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 --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090908/c89ad5a3/attachment.html 

From lattner at apple.com  Tue Sep  8 16:06:15 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 8 Sep 2009 14:06:15 -0700
Subject: [LLVMdev] LLVM 2.6 Branch Fails to Compile
In-Reply-To: <4AA6BC08.6080205@t-online.de>
References: <4AA678F4.5050409@cs.uiuc.edu> <4AA6BC08.6080205@t-online.de>
Message-ID: <94761590-5E2A-43FA-ADA0-BA7D1253ECC2@apple.com>


On Sep 8, 2009, at 1:18 PM, Albert Graef wrote:

> John Criswell wrote:
>> The LLVM 2.6 Release Branch doesn't compile for me on Mac OS X.  The
>> following patch seems to fix it (it adds a missing include file to  
>> get
>> WeakVH defined).
>>
>> Has anyone else seen this breakage, or is it possible that I've got  
>> the
>> wrong branch checked out?
>
> I fails to compile on Linux as well. Has been that way for a few days.
>

This is now fixed.

-Tanya

> 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
> _______________________________________________
> 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/20090908/30a9d3a0/attachment.html 

From horwitz at cs.wisc.edu  Tue Sep  8 16:46:34 2009
From: horwitz at cs.wisc.edu (Susan Horwitz)
Date: Tue, 8 Sep 2009 16:46:34 -0500 (CDT)
Subject: [LLVMdev] how to change one operand of an LLVM instruction
Message-ID: <Pine.LNX.4.64.0909081639150.17889@curds.cs.wisc.edu>

I am trying to implement node splitting to transform irreducible CFGS to 
reducible ones.  This means making copies of some basic blocks, which in 
turn means making copies of individual instructions.  I can use the 
"clone" function to make an exact copy, but then I need to change some 
operands. For example, when I copy
 	%1 = ...
 	%2 = add %1, 5

I get
 	%3 = ...
 	%4 = add %1, 5

and I need to change the %1 operand in the copy to be %3.

The only way I see to do this is to create a new instruction instead of a 
clone, using a big switch on the opcode (since different instructions' 
constructors have different parameters).

Anyone know of an easier way to do this?


From clattner at apple.com  Tue Sep  8 16:53:13 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 8 Sep 2009 14:53:13 -0700
Subject: [LLVMdev] 2.6 request - Bug 4879
In-Reply-To: <D68AC775-86B8-49F3-A9EA-43D6787E4A2B@apple.com>
References: <C433FD4D-BF4D-412D-A6F1-93C8A1106806@translattice.com>
	<3594D394-1F67-4097-A3FD-C0AFAC0AB64B@apple.com>
	<D68AC775-86B8-49F3-A9EA-43D6787E4A2B@apple.com>
Message-ID: <AC3F5482-3A7A-4C23-B669-3E1DAD50D8E3@apple.com>


On Sep 8, 2009, at 2:05 PM, Tanya Lattner wrote:
> This can not go into 2.6, because r79742 is not in 2.6:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/085284.html
>
> Should this really be a release candidate? Its changing quite a bit  
> and its not causing a regression.

No, the bigger patch should not go into 2.6.  Devang, can you please  
prepare a version of this patch that applies cleanly to the 2.6 branch?

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

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

From clattner at apple.com  Tue Sep  8 16:55:32 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 8 Sep 2009 14:55:32 -0700
Subject: [LLVMdev] how to change one operand of an LLVM instruction
In-Reply-To: <Pine.LNX.4.64.0909081639150.17889@curds.cs.wisc.edu>
References: <Pine.LNX.4.64.0909081639150.17889@curds.cs.wisc.edu>
Message-ID: <F83C3376-38B7-45A6-AE3F-BDF7BA4D61B2@apple.com>

On Sep 8, 2009, at 2:46 PM, Susan Horwitz wrote:
> I am trying to implement node splitting to transform irreducible  
> CFGS to
> reducible ones.  This means making copies of some basic blocks,  
> which in
> turn means making copies of individual instructions.  I can use the
> "clone" function to make an exact copy, but then I need to change some
> operands. For example, when I copy
> 	%1 = ...
> 	%2 = add %1, 5
>
> I get
> 	%3 = ...
> 	%4 = add %1, 5
>
> and I need to change the %1 operand in the copy to be %3.
>
> The only way I see to do this is to create a new instruction instead  
> of a
> clone, using a big switch on the opcode (since different instructions'
> constructors have different parameters).

Hi Susan,

Because LLVM IR is in SSA form, you shouldn't think of the  
"name" (like %2) as being a property of the instruction... the name  
*is* the instruction.  If you need to duplicate blocks like this, you  
should probably demote the cross-block values to memory (using the  
reg2mem utilities), perform your transformation, then use the mem2reg  
pass to eliminate the temporary memory accesses and reconstruct SSA  
form.

One example pass that does this is lib/Transforms/Scalar/ 
JumpThreading.cpp.  Search for "DemoteRegToStack".

-Chris

From lattner at apple.com  Tue Sep  8 16:57:44 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 8 Sep 2009 14:57:44 -0700
Subject: [LLVMdev] how to change one operand of an LLVM instruction
In-Reply-To: <Pine.LNX.4.64.0909081639150.17889@curds.cs.wisc.edu>
References: <Pine.LNX.4.64.0909081639150.17889@curds.cs.wisc.edu>
Message-ID: <35FCB838-5809-4733-AA6F-862E402DA807@apple.com>


On Sep 8, 2009, at 2:46 PM, Susan Horwitz wrote:

> I am trying to implement node splitting to transform irreducible  
> CFGS to
> reducible ones.  This means making copies of some basic blocks,  
> which in
> turn means making copies of individual instructions.  I can use the
> "clone" function to make an exact copy, but then I need to change some
> operands. For example, when I copy
> 	%1 = ...
> 	%2 = add %1, 5
>
> I get
> 	%3 = ...
> 	%4 = add %1, 5
>
> and I need to change the %1 operand in the copy to be %3.
>
> The only way I see to do this is to create a new instruction instead  
> of a
> clone, using a big switch on the opcode (since different instructions'
> constructors have different parameters).
>
> Anyone know of an easier way to do this?
>

Are you using CloneBasicBlock? If so, you should pass it a ValueMap.  
You can then iterate over the instructions in the new basicblock and  
update the instruction operand references.

Check out CloneFunction.cpp for some examples.

-Tanya





> _______________________________________________
> 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/20090908/d2a47689/attachment.html 

From dpatel at apple.com  Tue Sep  8 17:01:52 2009
From: dpatel at apple.com (Devang Patel)
Date: Tue, 8 Sep 2009 15:01:52 -0700
Subject: [LLVMdev] 2.6 request - Bug 4879
In-Reply-To: <AC3F5482-3A7A-4C23-B669-3E1DAD50D8E3@apple.com>
References: <C433FD4D-BF4D-412D-A6F1-93C8A1106806@translattice.com>
	<3594D394-1F67-4097-A3FD-C0AFAC0AB64B@apple.com>
	<D68AC775-86B8-49F3-A9EA-43D6787E4A2B@apple.com>
	<AC3F5482-3A7A-4C23-B669-3E1DAD50D8E3@apple.com>
Message-ID: <79AF0688-58FA-4406-ABBE-C04958863621@apple.com>


On Sep 8, 2009, at 2:53 PM, Chris Lattner wrote:

>
> On Sep 8, 2009, at 2:05 PM, Tanya Lattner wrote:
>> This can not go into 2.6, because r79742 is not in 2.6:
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/085284.html
>>
>> Should this really be a release candidate? Its changing quite a bit  
>> and its not causing a regression.
>
> No, the bigger patch should not go into 2.6.  Devang, can you please  
> prepare a version of this patch that applies cleanly to the 2.6  
> branch?
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090831/086443.html

hmmm... r81058 fixes a bug in the code that I added as part of r79742.  
We definitely do not want to add r79742 in 2.6. Are we sure that 4879  
is not a recent regression ?

-
Devang


From clattner at apple.com  Tue Sep  8 19:56:30 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 8 Sep 2009 17:56:30 -0700
Subject: [LLVMdev] X86 Disassembler
In-Reply-To: <23D8260F-BA48-4A4A-9CA6-7F831A602EBC@apple.com>
References: <5CAC0029-31A2-4490-9232-E6098907AEC9@apple.com>
	<DDEDF415-4B49-4DC5-A743-8A81B8DA9DE8@gmail.com>
	<F909DDB3-DD12-4901-9662-DCF7B0FA8801@apple.com>
	<F49ADA4A-FF00-4823-A50F-01975E3C87F0@apple.com>
	<23D8260F-BA48-4A4A-9CA6-7F831A602EBC@apple.com>
Message-ID: <3A81247B-99F2-4851-948B-F988DD8C6294@apple.com>


On Sep 3, 2009, at 5:25 PM, Sean Callanan wrote:

> I was away doing other things for a while, but I have an API patch  
> separated out, which (in addition to being much smaller than past  
> megapatches) corrects two issues Chris identified in his most recent  
> set of patches:
>
> - First, it makes the API a good deal simpler.  Now, you can  
> instantiate a single MCDisassembler and, each time you want an  
> instruction disassembled, you can simply pass it a MemoryRegion, an  
> offset, and an MCInst to populate.
>
> - Second, it adds MCDisassembler to the list of things you can get  
> from a TargetMachine, so you don't have to #include something from  
> lib/Target/X86 just to use the X86 disassembler.
>
> Please let me know what you think of this API.  Thanks for your time.

Hi Sean,

Sorry for the delay, this got buried in my inbox.

This API looks great, please commit it with a couple of minor tweaks:

+++ include/llvm/MC/MCDisassembler.h	(revision 0)

+#include "llvm/MC/MCInst.h"
+#include "llvm/Support/MemoryObject.h"
+#include "llvm/Support/raw_ostream.h"

Please forward declare these classes instead of #including their  
headers.

+  virtual bool          getInstruction(MCInst& instr,
+                                       uint64_t& size,
+                                       MemoryObject &region,
+                                       uint64_t address,
+                                       raw_ostream &vStream) const = 0;

"MCInst &instr", likewise with size.  Can "region" be passed in by  
const reference?


+++ lib/MC/MCDisassembler.cpp	(revision 0)
@@ -0,0 +1,20 @@
+//===-- lib/MC/MCDisassembler.h - Disassembler interface --------*- C+ 
+ -*-===//

Please fix the comment line (.h -> .cpp)

+namespace llvm {
+
+MCDisassembler::MCDisassembler() {
+}
+

In the .cpp files, please change them to 'using namespace llvm;' at  
the top to avoid nesting the entire file in a namespace.


Thanks Sean,

-Chris

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

From max.stonebraker at gmail.com  Wed Sep  9 00:16:43 2009
From: max.stonebraker at gmail.com (Max Stonebraker)
Date: Tue, 8 Sep 2009 22:16:43 -0700
Subject: [LLVMdev] disable insertion of unreachables
In-Reply-To: <400d33ea0909061455l6837b7b7j6768454214f3f4a5@mail.gmail.com>
References: <808cbd330909061449w4abe76a6kce710bd1bb9deeb3@mail.gmail.com>
	<400d33ea0909061455l6837b7b7j6768454214f3f4a5@mail.gmail.com>
Message-ID: <808cbd330909082216g3095f645q9282d07693f11c1d@mail.gmail.com>

> if so, the assembly language docs say that
> program behavior is undefined if such a function
> ever returns.

Yes, that's true, but for some static analysis applications such as control
dependence analysis for programs that have arbitrary interprocedural control
flow, one needs these additional non-executable control flow edges from
noreturn functions to their immediate CFG successor.

Is there any way to avoid having the unreachables inserted in the first
place?

Max


On Sun, Sep 6, 2009 at 2:55 PM, Kenneth Uildriks <kennethuil at gmail.com>wrote:

> What do you mean by "terminating function call"?  Is it one with the
> "noreturn" attribute?  if so, the assembly language docs say that
> program behavior is undefined if such a function ever returns.  If
> your function could possibly return, it needs to not have that
> attribute.
>
> On Sun, Sep 6, 2009 at 4:49 PM, Max
> Stonebraker<max.stonebraker at gmail.com> wrote:
> > Hello all,
> >
> > LLVM inserts unreachable instructions after every call to a terminating
> > function. Is there a way to disable this feature so that it treats
> > terminating function calls like any other function call, so the
> unreachable
> > instruction would not be inserted? Unfortunately, simply removing the
> > unreachable instructions after the fact would not suffice for my needs
> > because I need to preserve the original control flow of the program. That
> > is, I need to know the instruction that would have been executed if the
> call
> > to the terminating function didn't actually terminate the program.
> >
> > Thanks!
> >
> > Max
> >
> > _______________________________________________
> > 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/20090908/996f9a0c/attachment.html 

From eli.friedman at gmail.com  Wed Sep  9 00:30:06 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 8 Sep 2009 22:30:06 -0700
Subject: [LLVMdev] disable insertion of unreachables
In-Reply-To: <808cbd330909082216g3095f645q9282d07693f11c1d@mail.gmail.com>
References: <808cbd330909061449w4abe76a6kce710bd1bb9deeb3@mail.gmail.com>
	<400d33ea0909061455l6837b7b7j6768454214f3f4a5@mail.gmail.com>
	<808cbd330909082216g3095f645q9282d07693f11c1d@mail.gmail.com>
Message-ID: <f5aa3e9b0909082230q487f5312p82e362c9602d6bed@mail.gmail.com>

On Tue, Sep 8, 2009 at 10:16 PM, Max
Stonebraker<max.stonebraker at gmail.com> wrote:
> Is there any way to avoid having the unreachables inserted in the first
> place?

If there's sensible control flow after a function returns, don't mark
it or calls to it noreturn.  If in fact cannot return, the concept of
control flow after the function returns fundamentally makes no sense.

-Eli

From shang1982 at gmail.com  Wed Sep  9 02:50:21 2009
From: shang1982 at gmail.com (Lei Shang)
Date: Wed, 9 Sep 2009 17:50:21 +1000
Subject: [LLVMdev] Where is steens-aa and ds-aa?
Message-ID: <b67dc9380909090050yceebb40i824f10f512cbc088@mail.gmail.com>

Hi,

   I just found -steens-aa and -ds-aa Alias Analysis listed in documents do
not exist in my llvm-2.3 code. Both from opt -help and the lib/Analysis.
And then I go to download the llvm-2.5 version, there is still no these 2
options. Where are they?

Lei

-- 
/******
* Lei Shang
* PhD candidate, Computer Science & Engineering,
* University of New South Wales, Sydney, Australia, 2052
* Email:  shang1982 at Gmail.com Mobile: 0425711216
* Homepage: http://shangl.info
**********/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090909/dd1a16aa/attachment.html 

From eli.friedman at gmail.com  Wed Sep  9 03:28:38 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 9 Sep 2009 01:28:38 -0700
Subject: [LLVMdev] Where is steens-aa and ds-aa?
In-Reply-To: <b67dc9380909090050yceebb40i824f10f512cbc088@mail.gmail.com>
References: <b67dc9380909090050yceebb40i824f10f512cbc088@mail.gmail.com>
Message-ID: <f5aa3e9b0909090128h626d5b8dlb175e299cb5fd282@mail.gmail.com>

On Wed, Sep 9, 2009 at 12:50 AM, Lei Shang<shang1982 at gmail.com> wrote:
> Hi,
>
> ?? I just found -steens-aa and -ds-aa Alias Analysis listed in documents do
> not exist in my llvm-2.3 code. Both from opt -help and the lib/Analysis.
> And then I go to download the llvm-2.5 version, there is still no these 2
> options. Where are they?

http://llvm.org/svn/llvm-project/poolalloc/trunk/ .  They're not part
of a normal checkout due to patent issues.

-Eli


From kennethuil at gmail.com  Wed Sep  9 08:12:09 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Wed, 9 Sep 2009 08:12:09 -0500
Subject: [LLVMdev] disable insertion of unreachables
In-Reply-To: <808cbd330909082216g3095f645q9282d07693f11c1d@mail.gmail.com>
References: <808cbd330909061449w4abe76a6kce710bd1bb9deeb3@mail.gmail.com>
	<400d33ea0909061455l6837b7b7j6768454214f3f4a5@mail.gmail.com>
	<808cbd330909082216g3095f645q9282d07693f11c1d@mail.gmail.com>
Message-ID: <400d33ea0909090612q1de37271l208d597144ba1e3@mail.gmail.com>

On Wed, Sep 9, 2009 at 12:16 AM, Max
Stonebraker<max.stonebraker at gmail.com> wrote:
>> if so, the assembly language docs say that
>> program behavior is undefined if such a function
>> ever returns.
>
> Yes, that's true, but for some static analysis applications such as control
> dependence analysis for programs that have arbitrary interprocedural control
> flow, one needs these additional non-executable control flow edges from
> noreturn functions to their immediate CFG successor.

But a block containing a noreturn function shouldn't *have* a CFG successor.

>
> Is there any way to avoid having the unreachables inserted in the first
> place?

If you do that, you'll have to terminate the block with some other
instruction.  Which, according to the language definition, is
guaranteed to never execute.

"noreturn" is not what you're looking for.  It means something
completely different from what you have in mind.

From clattner at apple.com  Wed Sep  9 10:50:38 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 9 Sep 2009 08:50:38 -0700
Subject: [LLVMdev] 2.6 request - Bug 4879
In-Reply-To: <79AF0688-58FA-4406-ABBE-C04958863621@apple.com>
References: <C433FD4D-BF4D-412D-A6F1-93C8A1106806@translattice.com>
	<3594D394-1F67-4097-A3FD-C0AFAC0AB64B@apple.com>
	<D68AC775-86B8-49F3-A9EA-43D6787E4A2B@apple.com>
	<AC3F5482-3A7A-4C23-B669-3E1DAD50D8E3@apple.com>
	<79AF0688-58FA-4406-ABBE-C04958863621@apple.com>
Message-ID: <7C494AC2-D252-402D-9108-81FA5F0464C7@apple.com>


On Sep 8, 2009, at 3:01 PM, Devang Patel wrote:

>
> On Sep 8, 2009, at 2:53 PM, Chris Lattner wrote:
>
>>
>> On Sep 8, 2009, at 2:05 PM, Tanya Lattner wrote:
>>> This can not go into 2.6, because r79742 is not in 2.6:
>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/085284.html
>>>
>>> Should this really be a release candidate? Its changing quite a  
>>> bit and its not causing a regression.
>>
>> No, the bigger patch should not go into 2.6.  Devang, can you  
>> please prepare a version of this patch that applies cleanly to the  
>> 2.6 branch?
>>
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090831/086443.html
>
> hmmm... r81058 fixes a bug in the code that I added as part of  
> r79742. We definitely do not want to add r79742 in 2.6. Are we sure  
> that 4879 is not a recent regression ?

Ok, if 2.6 is not affected, then we definitely don't want to mess with  
it.  Thanks.

-Chris

From shuguang.feng at gmail.com  Wed Sep  9 11:46:40 2009
From: shuguang.feng at gmail.com (Shuguang Feng)
Date: Wed, 9 Sep 2009 09:46:40 -0700 (PDT)
Subject: [LLVMdev] [PATCH] & Question: Preserving ProfileInfo for
	backend.
In-Reply-To: <A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com>
References: <4AA61556.6090300@gmx.at>
	<A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com>
Message-ID: <4071a327-c2d3-4757-85a7-a1c4c4c10275@y21g2000yqn.googlegroups.com>

Hi,

Does the current LLVM backend support reading in profile information
(without preserving across transformations)? An earlier poster

http://groups.google.com/group/llvm-dev/browse_thread/thread/4bd65dbe84394bb7

noted that accessing execution counts in a MachineFunction pass (using
the BasicBlock* corresponding to the respective MachineBasicBlock)
returned 0 for all blocks.  Running llc with --debug-pass=Structure I
noticed that the NoProfileInfo pass was being executed.  I tried
adding a ProfileLoaderPass in the addPreRegAlloc function of the X86
target machine to load the profile information but receive the
following runtime error when the pass manager attempts to add the
ProfileLoader pass:

llc: <path to llvm>/llvm/lib/VMCore/PassManager.cpp:1597: virtual void
llvm::ModulePass::assignPassManager(llvm::PMStack&,
llvm::PassManagerType): Assertion `!PMS.empty() && "Unable to find
appropriate Pass Manager"' failed.

I'm not very familiar with the inner workings of the pass manager
framework.  Is there a simple fix that can allow existing profile
information to be loaded by backend passes?  I realize that the
profile data would not be completely accurate, but as a first order
approximation it could be useful until the proper framework is
implemented?

Thanks!



From Arnaud.AllardDeGrandMaison at dibcom.com  Wed Sep  9 11:44:22 2009
From: Arnaud.AllardDeGrandMaison at dibcom.com (Arnaud Allard de Grandmaison)
Date: Wed, 9 Sep 2009 18:44:22 +0200
Subject: [LLVMdev] How to express physical register dependencies between
	instructions
Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4A0102E549DB73@FRPAR1CL009.coe.adi.dibcom.com>

I am wondering how to express physical register dependencies between
instructions, typically in the case for conditionnal branch, where an
instruction which sets the condition codes is followed by a conditionnal
branch.

Assuming CCFLAGS is defined in my registerInfo.td, and that I am using
llvm-2.5 release, it seems several items need to be set in the .td file :
1 - SDNPOptInFlag / SDNPOptOutFlag
2 - Defs = [CCFLAGS] / Uses = [CCFLAGS]
3 - (implicit CCFLAGS)
4 - explicit usage of CCFLAGS

As a new comer to LLVM, I am missing the druid's lore to pick up the mixture
of right items to have it work.

I am asking the question because in our case, I observe that the
pre-RA-scheduling pass moves an instruction which clobbers CCFLAGS in between
my 2 instructions (set ccflags / brcc). I found on bugzilla that only the
burr scheduler has been taught about physical register dependencies, so I
made sure this is the one I am using. I am currently using #1 + #2 + #3, and have not yet used option #4, but I can
see this is the one being used for the X86.  Is this the one I should be using ?

Thanks in advance for any suggestion or hint,
--
Arnaud de Grandmaison

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 daniel at zuster.org  Wed Sep  9 12:46:12 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Wed, 9 Sep 2009 10:46:12 -0700
Subject: [LLVMdev] 2.6 request - Bug 4879
In-Reply-To: <7C494AC2-D252-402D-9108-81FA5F0464C7@apple.com>
References: <C433FD4D-BF4D-412D-A6F1-93C8A1106806@translattice.com>
	<3594D394-1F67-4097-A3FD-C0AFAC0AB64B@apple.com>
	<D68AC775-86B8-49F3-A9EA-43D6787E4A2B@apple.com>
	<AC3F5482-3A7A-4C23-B669-3E1DAD50D8E3@apple.com>
	<79AF0688-58FA-4406-ABBE-C04958863621@apple.com>
	<7C494AC2-D252-402D-9108-81FA5F0464C7@apple.com>
Message-ID: <6a8523d60909091046q61ec1546mfffe5fc32fd41ca8@mail.gmail.com>

I believe the original reporter was using 2.6. We should confirm it
isn't in 2.6, since if it is I suspect it is a regression?

Michael, are you using 2.6 or top of tree?

 - Daniel

On Wed, Sep 9, 2009 at 8:50 AM, Chris Lattner<clattner at apple.com> wrote:
>
> On Sep 8, 2009, at 3:01 PM, Devang Patel wrote:
>
>>
>> On Sep 8, 2009, at 2:53 PM, Chris Lattner wrote:
>>
>>>
>>> On Sep 8, 2009, at 2:05 PM, Tanya Lattner wrote:
>>>> This can not go into 2.6, because r79742 is not in 2.6:
>>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/085284.html
>>>>
>>>> Should this really be a release candidate? Its changing quite a
>>>> bit and its not causing a regression.
>>>
>>> No, the bigger patch should not go into 2.6. ?Devang, can you
>>> please prepare a version of this patch that applies cleanly to the
>>> 2.6 branch?
>>>
>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090831/086443.html
>>
>> hmmm... r81058 fixes a bug in the code that I added as part of
>> r79742. We definitely do not want to add r79742 in 2.6. Are we sure
>> that 4879 is not a recent regression ?
>
> Ok, if 2.6 is not affected, then we definitely don't want to mess with
> it. ?Thanks.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From astifter-llvm at gmx.at  Wed Sep  9 12:47:06 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Wed, 09 Sep 2009 19:47:06 +0200
Subject: [LLVMdev] [PATCH] & Question: Preserving ProfileInfo
	for	backend.
In-Reply-To: <4071a327-c2d3-4757-85a7-a1c4c4c10275@y21g2000yqn.googlegroups.com>
References: <4AA61556.6090300@gmx.at>	<A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com>
	<4071a327-c2d3-4757-85a7-a1c4c4c10275@y21g2000yqn.googlegroups.com>
Message-ID: <4AA7EA1A.2020007@gmx.at>

Hi,

Shuguang Feng wrote:
> Does the current LLVM backend support reading in profile information
> (without preserving across transformations)? An earlier poster
Yes, it does.

> http://groups.google.com/group/llvm-dev/browse_thread/thread/4bd65dbe84394bb7
> 
> noted that accessing execution counts in a MachineFunction pass (using
> the BasicBlock* corresponding to the respective MachineBasicBlock)
> returned 0 for all blocks.  Running llc with   I
> noticed that the NoProfileInfo pass was being executed.  

Yes, llc currently does not support the loading of profiles, but I
attach a patch that does that, can you try that please?

> I tried
> adding a ProfileLoaderPass in the addPreRegAlloc function of the X86
> target machine to load the profile information but receive the
> following runtime error when the pass manager attempts to add the
> ProfileLoader pass:
> 
> llc: <path to llvm>/llvm/lib/VMCore/PassManager.cpp:1597: virtual void
> llvm::ModulePass::assignPassManager(llvm::PMStack&,
> llvm::PassManagerType): Assertion `!PMS.empty() && "Unable to find
> appropriate Pass Manager"' failed.
>
> I'm not very familiar with the inner workings of the pass manager
> framework.  Is there a simple fix that can allow existing profile
> information to be loaded by backend passes?  I realize that the
> profile data would not be completely accurate, but as a first order
> approximation it could be useful until the proper framework is
> implemented?

Don't know about Passes in the backend, but this could be a problem of
an FunctionPassManager trying to use a ModulePass.

Andi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-r81350.llc.profile.loader.patch
Type: text/x-patch
Size: 2198 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090909/12900261/attachment.bin 

From shuguang.feng at gmail.com  Wed Sep  9 17:15:57 2009
From: shuguang.feng at gmail.com (Shuguang Feng)
Date: Wed, 9 Sep 2009 15:15:57 -0700 (PDT)
Subject: [LLVMdev] [PATCH] & Question: Preserving ProfileInfo for
	backend.
In-Reply-To: <4AA7EA1A.2020007@gmx.at>
References: <4AA61556.6090300@gmx.at>
	<A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com> 
	<4071a327-c2d3-4757-85a7-a1c4c4c10275@y21g2000yqn.googlegroups.com> 
	<4AA7EA1A.2020007@gmx.at>
Message-ID: <d9bf7e58-6457-4344-be5a-22474c12d0b3@g31g2000yqc.googlegroups.com>

Thanks for such a rapid response!

> Don't know about Passes in the backend, but this could be a problem of
> an FunctionPassManager trying to use a ModulePass.

I manually applied the patch you provided for llc (I'm using the 2.5
release of LLVM not ToT) and it fixed my compilation error.  When your
patch replaced the FunctionPassManager used by llc with a PassManager
the error went away.

Unfortunately, I'm still seeing execution counts of -1 when I print
them out in my MachineFunction pass. I access the profiling
information at each MachineBasicBlock with the following code, where
"bb" is a reference to the current MachineBasicBlock:

PI->getExecutionCount(bb.getBasicBlock())

I believe I've integrated all the ProfileInfo* files from ToT with my
LLVM-2.5 installation properly.  The profiling code (and llvm-prof)
seems to be working since llvm-prof is generating/printing the
appropriate execution frequencies.  Is there an obvious mistake that I
could be making?  Since I've had to customize my current installation
of llvm I would like to avoid updating to the latest revision if
possible.

Thanks!

From lattner at apple.com  Wed Sep  9 19:47:15 2009
From: lattner at apple.com (Tanya Lattner)
Date: Wed, 9 Sep 2009 17:47:15 -0700
Subject: [LLVMdev] Need volunteers to fix 2.6 release bugs
Message-ID: <C1E400E7-3D09-4145-AE63-4D3962207E36@apple.com>

Hello all! The 2.6 release is currently blocked by a number of bugs  
that need to be fixed.

Please see the master 2.6 bug (see depends on field):
http://llvm.org/bugs/show_bug.cgi?id=4886

If anyone can volunteer to help out, please do so!

The 2.6 release will not progress until these bugs are fixed. We hope  
this is the last of them!

Thanks,
Tanya

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

From haohui.mai at gmail.com  Wed Sep  9 22:49:36 2009
From: haohui.mai at gmail.com (Mai, Haohui)
Date: Wed, 09 Sep 2009 22:49:36 -0500
Subject: [LLVMdev] Where is steens-aa and ds-aa?
In-Reply-To: <f5aa3e9b0909090128h626d5b8dlb175e299cb5fd282@mail.gmail.com>
References: <b67dc9380909090050yceebb40i824f10f512cbc088@mail.gmail.com>
	<f5aa3e9b0909090128h626d5b8dlb175e299cb5fd282@mail.gmail.com>
Message-ID: <4AA87750.8020003@gmail.com>

On 9/9/09 3:28 AM, Eli Friedman wrote:
> On Wed, Sep 9, 2009 at 12:50 AM, Lei Shang<shang1982 at gmail.com>  wrote:
>    
>> Hi,
>>
>>     I just found -steens-aa and -ds-aa Alias Analysis listed in documents do
>> not exist in my llvm-2.3 code. Both from opt -help and the lib/Analysis.
>> And then I go to download the llvm-2.5 version, there is still no these 2
>> options. Where are they?
>>      
> http://llvm.org/svn/llvm-project/poolalloc/trunk/ .  They're not part
> of a normal checkout due to patent issues.
>
>    

I don't quite understand. You mean steensgaard / DSA are patented?

Haohui
> -Eli
>
> _______________________________________________
> 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  Wed Sep  9 22:57:51 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Thu, 10 Sep 2009 09:27:51 +0530
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>
References: <4AA2B20B.1030903@microchip.com> <4AA2B82A.3070105@microchip.com>	
	<3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>	
	<4AA3F5D2.1040402@microchip.com>	
	<3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>	
	<3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>
	<3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>
Message-ID: <4AA8793F.8080503@microchip.com>

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> On Sun, Sep 6, 2009 at 8:13 PM, Mikhail
> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>   
>> Hi Sanjiv,
>>
>> On Sun, Sep 6, 2009 at 8:07 PM, Mikhail
>> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>>     
>>> [...]
>>>       
>> [Sorry, the formatting was a bit off]
>>
>>     
>>> The following snippet gives the expected behaviour (not tested, but
>>> you should get the idea):
>>>       
>
> BTW, your mail has got me thinking about the semantics of 'case',
> which is currently somewhat ambiguous (since it depends on context).
> Probably 'case' should be modified to always mean 'if ... else if ...
> else if ... [...] else ...' and the 'if (...) ... if (...) ... if
> (...) ... [...]' form should be called something like 'match'. That
> would be backwards-incompatible, though.
>
> What do you think?
>
>   
Another way would be to include a "break" command, to take you after the 
default label.
- Sanjiv


From shang1982 at gmail.com  Wed Sep  9 23:06:11 2009
From: shang1982 at gmail.com (Lei Shang)
Date: Thu, 10 Sep 2009 14:06:11 +1000
Subject: [LLVMdev] Where is steens-aa and ds-aa?
In-Reply-To: <4AA87750.8020003@gmail.com>
References: <b67dc9380909090050yceebb40i824f10f512cbc088@mail.gmail.com>
	<f5aa3e9b0909090128h626d5b8dlb175e299cb5fd282@mail.gmail.com>
	<4AA87750.8020003@gmail.com>
Message-ID: <b67dc9380909092106n24fe0dc0sbd8dfd76be2ec388@mail.gmail.com>

I have downloaded the poolalloc, but it fails to compile as it requires some
files do
not exist in current llvm-2.5 version.

Should I download old version of poolalloc?

Lei

2009/9/10 Mai, Haohui <haohui.mai at gmail.com>

>  On 9/9/09 3:28 AM, Eli Friedman wrote:
> > On Wed, Sep 9, 2009 at 12:50 AM, Lei Shang<shang1982 at gmail.com>  wrote:
> >
> >> Hi,
> >>
> >>     I just found -steens-aa and -ds-aa Alias Analysis listed in
> documents do
> >> not exist in my llvm-2.3 code. Both from opt -help and the lib/Analysis.
> >> And then I go to download the llvm-2.5 version, there is still no these
> 2
> >> options. Where are they?
> >>
> > http://llvm.org/svn/llvm-project/poolalloc/trunk/ .  They're not part
> > of a normal checkout due to patent issues.
> >
> >
>
> I don't quite understand. You mean steensgaard / DSA are patented?
>
> Haohui
> > -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
>



-- 
/******
* Lei Shang
* PhD candidate, Computer Science & Engineering,
* University of New South Wales, Sydney, Australia, 2052
* Email:  shang1982 at Gmail.com Mobile: 0425711216
* Homepage: http://shangl.info
**********/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090910/f67dde9f/attachment.html 

From dberlin at dberlin.org  Wed Sep  9 23:43:57 2009
From: dberlin at dberlin.org (Daniel Berlin)
Date: Thu, 10 Sep 2009 00:43:57 -0400
Subject: [LLVMdev] Where is steens-aa and ds-aa?
In-Reply-To: <4AA87750.8020003@gmail.com>
References: <b67dc9380909090050yceebb40i824f10f512cbc088@mail.gmail.com>
	<f5aa3e9b0909090128h626d5b8dlb175e299cb5fd282@mail.gmail.com>
	<4AA87750.8020003@gmail.com>
Message-ID: <4aca3dc20909092143m3901ada5oa035b2e547cb5f87@mail.gmail.com>

On Wed, Sep 9, 2009 at 11:49 PM, Mai, Haohui <haohui.mai at gmail.com> wrote:
> On 9/9/09 3:28 AM, Eli Friedman wrote:
>> On Wed, Sep 9, 2009 at 12:50 AM, Lei Shang<shang1982 at gmail.com> ?wrote:
>>
>>> Hi,
>>>
>>> ? ? I just found -steens-aa and -ds-aa Alias Analysis listed in documents do
>>> not exist in my llvm-2.3 code. Both from opt -help and the lib/Analysis.
>>> And then I go to download the llvm-2.5 version, there is still no these 2
>>> options. Where are they?
>>>
>> http://llvm.org/svn/llvm-project/poolalloc/trunk/ . ?They're not part
>> of a normal checkout due to patent issues.
>>
>>
>
> I don't quite understand. You mean steensgaard / DSA are patented?

Steensgaard certainly is.
It's covered by multiple patents, in fact
Steensgaard (and MS Research) hold patents on all unification based
pointer analysis.


From andrewl at lenharth.org  Wed Sep  9 23:56:25 2009
From: andrewl at lenharth.org (Andrew Lenharth)
Date: Wed, 9 Sep 2009 23:56:25 -0500
Subject: [LLVMdev] Where is steens-aa and ds-aa?
In-Reply-To: <4aca3dc20909092143m3901ada5oa035b2e547cb5f87@mail.gmail.com>
References: <b67dc9380909090050yceebb40i824f10f512cbc088@mail.gmail.com>
	<f5aa3e9b0909090128h626d5b8dlb175e299cb5fd282@mail.gmail.com>
	<4AA87750.8020003@gmail.com>
	<4aca3dc20909092143m3901ada5oa035b2e547cb5f87@mail.gmail.com>
Message-ID: <85dfcd7f0909092156x2be6eda7pc780021e512b5c5f@mail.gmail.com>

On Wed, Sep 9, 2009 at 11:43 PM, Daniel Berlin<dberlin at dberlin.org> wrote:
> On Wed, Sep 9, 2009 at 11:49 PM, Mai, Haohui <haohui.mai at gmail.com> wrote:
>> On 9/9/09 3:28 AM, Eli Friedman wrote:
>>> On Wed, Sep 9, 2009 at 12:50 AM, Lei Shang<shang1982 at gmail.com> ?wrote:
>>>
>>>> Hi,
>>>>
>>>> ? ? I just found -steens-aa and -ds-aa Alias Analysis listed in documents do
>>>> not exist in my llvm-2.3 code. Both from opt -help and the lib/Analysis.
>>>> And then I go to download the llvm-2.5 version, there is still no these 2
>>>> options. Where are they?
>>>>
>>> http://llvm.org/svn/llvm-project/poolalloc/trunk/ . ?They're not part
>>> of a normal checkout due to patent issues.
>>>
>>>
>>
>> I don't quite understand. You mean steensgaard / DSA are patented?
>
> Steensgaard certainly is.
> It's covered by multiple patents, in fact
> Steensgaard (and MS Research) hold patents on all unification based
> pointer analysis.

DSA is unification based and assumed to be under those patents also.

poolalloc is currently being developed (and should compile) against
2.6.  It will track releases not TOT for the immediate future.

Andrew


From komurav1 at illinois.edu  Wed Sep  9 23:58:05 2009
From: komurav1 at illinois.edu (Rakesh Komuravelli)
Date: Wed, 9 Sep 2009 23:58:05 -0500
Subject: [LLVMdev] Finding call points to a function
Message-ID: <bf0e41fc0909092158k385fb69dxd52e04d1f2cb7012@mail.gmail.com>

Hi,

I am writing an LLVM Pass and I would like to know how would I do the
following:

1. I have a function foo, and I need to get all the call points calling this
function in each Function of the Module. The only way I can think of is to
iterate over the BasicBlocks of each Function, look for all the Call
Instructions and check if the called function is foo. I was wondering if
there is any other better way to do this.

2. Is it possible to distinguish a class method from a non class method
while analyzing the emitted LLVM code for a C++ program? Because, I need to
interpret the calls made to foo differently in a class method and in a non
class method.

Thanks,
Rakesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090909/292649b8/attachment.html 

From sanjiv.gupta at microchip.com  Thu Sep 10 00:26:03 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Thu, 10 Sep 2009 10:56:03 +0530
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <4AA8793F.8080503@microchip.com>
References: <4AA2B20B.1030903@microchip.com>
	<4AA2B82A.3070105@microchip.com>		<3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>		<4AA3F5D2.1040402@microchip.com>		<3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>		<3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>	<3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>
	<4AA8793F.8080503@microchip.com>
Message-ID: <4AA88DEB.3090700@microchip.com>

Sanjiv Gupta wrote:
> Mikhail Glushenkov wrote:
>   
>> Hi Sanjiv,
>>
>> On Sun, Sep 6, 2009 at 8:13 PM, Mikhail
>> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>>   
>>     
>>> Hi Sanjiv,
>>>
>>> On Sun, Sep 6, 2009 at 8:07 PM, Mikhail
>>> Glushenkov<the.dead.shall.rise at gmail.com> wrote:
>>>     
>>>       
>>>> [...]
>>>>       
>>>>         
>>> [Sorry, the formatting was a bit off]
>>>
>>>     
>>>       
>>>> The following snippet gives the expected behaviour (not tested, but
>>>> you should get the idea):
>>>>       
>>>>         
>> BTW, your mail has got me thinking about the semantics of 'case',
>> which is currently somewhat ambiguous (since it depends on context).
>> Probably 'case' should be modified to always mean 'if ... else if ...
>> else if ... [...] else ...' and the 'if (...) ... if (...) ... if
>> (...) ... [...]' form should be called something like 'match'. That
>> would be backwards-incompatible, though.
>>
>> What do you think?
>>
>>   
>>     
> Another way would be to include a "break" command, to take you after the 
> default label.
> - Sanjiv
>   
Sow we can write:

  case ( (switch_on "O0") [(append_cmd "-blah0"), (break)],
             (switch_on "O1")[(append_cmd "-blah1"), (break)],
             (switch_on "O2")[(append_cmd "-blah2"), (break)],
             (default) (append_cmd "-blah2"))

            
        
This would require generation of an unique label after each case 
construct, and a   goto uniquelabel;  in each if ( ) {...}
The other way is:
  if (first_test) {
    ....
    stop_case = true;
  }

  if (!stop_case && second_test) {
    ...
    stop_case = true;
  }

  if (!stop_case && third_test) {
    ...
  }  else {
    // default case
    ...
  }
  stop_case = false;

Also, it would be nice to have some "general predicates" to do some 
cleaning up of the command line.
For example: if an user specifies all -O0, -O1, -O2 on the command line, 
one would be able to choose only the first or last, or give an error.

option_validator ("O0", "O1", "O2"), (choose_first)
OR
option_validator ("O0", "O1", "O2"), (choose_last)
OR
option_validator ("O0", "O1", "O2"), (error "Only one of -O0, -O1, or 
-O2 are allowed).


> _______________________________________________
> 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 Sep 10 00:27:53 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Thu, 10 Sep 2009 10:57:53 +0530
Subject: [LLVMdev] Finding call points to a function
In-Reply-To: <bf0e41fc0909092158k385fb69dxd52e04d1f2cb7012@mail.gmail.com>
References: <bf0e41fc0909092158k385fb69dxd52e04d1f2cb7012@mail.gmail.com>
Message-ID: <4AA88E59.1070100@microchip.com>

Rakesh Komuravelli wrote:
> Hi,
>
> I am writing an LLVM Pass and I would like to know how would I do the 
> following:
>
> 1. I have a function foo, and I need to get all the call points 
> calling this function in each Function of the Module. The only way I 
> can think of is to iterate over the BasicBlocks of each Function, look 
> for all the Call Instructions and check if the called function is foo. 
> I was wondering if there is any other better way to do this.
Write a ModulePass and use CallGraph analysis in that.

>
> 2. Is it possible to distinguish a class method from a non class 
> method while analyzing the emitted LLVM code for a C++ program? 
> Because, I need to interpret the calls made to foo differently in a 
> class method and in a non class method.
>
> Thanks,
> Rakesh
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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  Thu Sep 10 01:36:38 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Wed, 09 Sep 2009 23:36:38 -0700
Subject: [LLVMdev] Finding call points to a function
In-Reply-To: <bf0e41fc0909092158k385fb69dxd52e04d1f2cb7012@mail.gmail.com>
References: <bf0e41fc0909092158k385fb69dxd52e04d1f2cb7012@mail.gmail.com>
Message-ID: <4AA89E76.2060105@mxc.ca>

Rakesh Komuravelli wrote:
> Hi,
> 
> I am writing an LLVM Pass and I would like to know how would I do the 
> following:
> 
> 1. I have a function foo, and I need to get all the call points calling 
> this function in each Function of the Module. The only way I can think 
> of is to iterate over the BasicBlocks of each Function, look for all the 
> Call Instructions and check if the called function is foo. I was 
> wondering if there is any other better way to do this.

Iterate over @foo's use list. 
http://wiki.llvm.org/HowTo:_Find_all_call_sites_of_a_function

> 2. Is it possible to distinguish a class method from a non class method 
> while analyzing the emitted LLVM code for a C++ program? Because, I need 
> to interpret the calls made to foo differently in a class method and in 
> a non class method.

No. Methods turn into functions that happen to take the class type 
pointer as first argument.

Nick


From astifter-llvm at gmx.at  Thu Sep 10 03:20:14 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Thu, 10 Sep 2009 10:20:14 +0200
Subject: [LLVMdev] [PATCH] Preserver ProfileInfo in CodeGenPrepare
Message-ID: <4AA8B6BE.90905@gmx.at>

Hi all!

Attached a patch to preserve ProfileInfo in CodeGenPrepare.

Would it be okay to commit such patches (that touch parts of LLVM to
preserve ProfileInfo) without prior approval?

Thanks, Andi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-r81438.preserver.profile.info.patch
Type: text/x-patch
Size: 4480 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090910/ebb9c114/attachment.bin 

From astifter-llvm at gmx.at  Thu Sep 10 03:35:37 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Thu, 10 Sep 2009 10:35:37 +0200
Subject: [LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question:
 Preserving ProfileInfo for backend.)
In-Reply-To: <d9bf7e58-6457-4344-be5a-22474c12d0b3@g31g2000yqc.googlegroups.com>
References: <4AA61556.6090300@gmx.at>	<A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com>
	<4071a327-c2d3-4757-85a7-a1c4c4c10275@y21g2000yqn.googlegroups.com>
	<4AA7EA1A.2020007@gmx.at>
	<d9bf7e58-6457-4344-be5a-22474c12d0b3@g31g2000yqc.googlegroups.com>
Message-ID: <4AA8BA59.1000100@gmx.at>

Hi,

Shuguang Feng wrote:
> Thanks for such a rapid response!
> 
>> Don't know about Passes in the backend, but this could be a problem of
>> an FunctionPassManager trying to use a ModulePass.
> 
> I manually applied the patch you provided for llc (I'm using the 2.5
> release of LLVM not ToT) and it fixed my compilation error.  When your
> patch replaced the FunctionPassManager used by llc with a PassManager
> the error went away.
> 
> Unfortunately, I'm still seeing execution counts of -1 when I print
> them out in my MachineFunction pass. I access the profiling
> information at each MachineBasicBlock with the following code, where
> "bb" is a reference to the current MachineBasicBlock:
> 
> PI->getExecutionCount(bb.getBasicBlock())

What does "llc -debug-pass=Structure" say? Is the ProfileLoaderPass
really the last pass to touch the ProfileInfo before you are using it?

Also, does bb.getBasicBlock() for sure always returns a valid block
refrerence?

You are getting the PI by getAnalysis<ProfileInfo>() I presume? Is this
really the instance created by ProfileLoaderPass?

(I guess for the last two questions its best to use gdb, are you
familiar with it?)

Andi



From the.dead.shall.rise at gmail.com  Thu Sep 10 07:25:51 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 10 Sep 2009 14:25:51 +0200
Subject: [LLVMdev] Fwd:  tblgen bug in handling case , switch_on
In-Reply-To: <3cb898890909100524h7e3658eer24572747d626b47b@mail.gmail.com>
References: <4AA2B20B.1030903@microchip.com> <4AA2B82A.3070105@microchip.com>
	<3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>
	<4AA3F5D2.1040402@microchip.com>
	<3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>
	<3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>
	<3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>
	<4AA8793F.8080503@microchip.com> <4AA88DEB.3090700@microchip.com>
	<3cb898890909100524h7e3658eer24572747d626b47b@mail.gmail.com>
Message-ID: <3cb898890909100525w956ffe7r7201e12e77c2c7ba@mail.gmail.com>

Hi,

On Thu, Sep 10, 2009 at 7:26 AM, Sanjiv Gupta
<sanjiv.gupta at microchip.com> wrote:
>
>> Another way would be to include a "break" command, to take you after the
>> default label.

Yes, this can be useful. I think we should add both 'break' and a
'match' form, and make 'match' the only one allowed in the cmd_line
property. This will make the semantics of 'case' less ambiguous.

> Also, it would be nice to have some "general predicates" to do some cleaning
> up of the command line.
> For example: if an user specifies all -O0, -O1, -O2 on the command line, one
> would be able to choose only the first or last, or give an error.
>
> option_validator ("O0", "O1", "O2"), (choose_first)
> OR
> option_validator ("O0", "O1", "O2"), (choose_last)
> OR
> option_validator ("O0", "O1", "O2"), (error "Only one of -O0, -O1, or -O2
> are allowed).

Good idea. I propose adding something along these lines:

def Preprocess : OptionPreprocessor <[
?(squash ["O1", "O2", "O3"], "O3"),
?(squash ["O1", "O2"], "O2"),
?(conflict ?(and (switch_on "E"), (switch_on "S"))),
?(warning (and (switch_on "E"), (switch_on "S")), "-E conflicts with -S")
]>;

The preprocessing code will run once in the beginning.

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


From astifter at gmx.at  Thu Sep 10 03:19:43 2009
From: astifter at gmx.at (Andreas Neustifter)
Date: Thu, 10 Sep 2009 10:19:43 +0200
Subject: [LLVMdev] [PATCH] Preserver ProfileInfo in CodeGenPrepare
Message-ID: <4AA8B69F.4080405@gmx.at>

Hi all!

Attached a patch to preserve ProfileInfo in CodeGenPrepare.

Would it be okay to commit such patches (that touch parts of LLVM to
preserve ProfileInfo) without prior approval?

Thanks, Andi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-r81438.preserver.profile.info.patch
Type: text/x-patch
Size: 4479 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090910/9165f0f4/attachment.bin 

From nisse at lysator.liu.se  Thu Sep 10 05:45:48 2009
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Thu, 10 Sep 2009 12:45:48 +0200
Subject: [LLVMdev] Build problem with gcc-4.3.2
Message-ID: <nnbplj2i3n.fsf@stalhein.lysator.liu.se>

Hi,

on http://llvm.org/docs/GettingStarted.html#requirements you say you
want to know about problems compiling llvm with gcc.

I just tried compiling llvm and clang, using ./configure; make, and I
got the following error,

  llvm[2]: Compiling StrongPHIElimination.cpp for Debug build
  StrongPHIElimination.cpp:1051: internal compiler error: in value_format, at dwarf2out.c:7218
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See <http://gcc.gnu.org/bugs.html> for instructions.
  /bin/rm: cannot remove `/home/nisse/hack/llvm/lib/CodeGen/Debug/StrongPHIElimination.d.tmp': No such file or directory
  make[2]: *** [/home/nisse/hack/llvm/lib/CodeGen/Debug/StrongPHIElimination.o] Error 1
  make[2]: Leaving directory `/home/nisse/hack/llvm/lib/CodeGen'
  make[1]: *** [CodeGen/.makeall] Error 2
  make[1]: Leaving directory `/home/nisse/hack/llvm/lib'
  make: *** [all] Error 1

This is on a debian gnu/linux x86 box, using gcc-4.3.2 which (as far
as I remember) was compiled with default options. I checked out
revision 81438 from http://llvm.org/svn/llvm-project/llvm/trunk.

I'm not planning on investigating this problem further, I'll next
install gcc-4.4.1 and try again.

Regards,
/Niels

From shuguang.feng at gmail.com  Thu Sep 10 09:44:34 2009
From: shuguang.feng at gmail.com (Shuguang Feng)
Date: Thu, 10 Sep 2009 07:44:34 -0700 (PDT)
Subject: [LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] &
	Question: Preserving ProfileInfo for backend.)
In-Reply-To: <4AA8BA59.1000100@gmx.at>
References: <4AA61556.6090300@gmx.at>
	<A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com> 
	<4071a327-c2d3-4757-85a7-a1c4c4c10275@y21g2000yqn.googlegroups.com> 
	<4AA7EA1A.2020007@gmx.at>
	<d9bf7e58-6457-4344-be5a-22474c12d0b3@g31g2000yqc.googlegroups.com>
	<4AA8BA59.1000100@gmx.at>
Message-ID: <4cb478d1-4cd9-4133-9bee-4ff07d3d97d9@j19g2000yqk.googlegroups.com>

> What does "llc -debug-pass=Structure" say? Is the ProfileLoaderPass
> really the last pass to touch the ProfileInfo before you are using it?

Below is the sequence of passes that I see.  Although the
NoProfileInfo pass is being run, it should be subsequently overridden
by ProfileInfoLoaderPass (LoaderPass) correct?

Target Data Layout
Create Garbage Collector Module Metadata
Basic Alias Analysis (default AA impl)
DWARF Information Writer
No Profile Information
Module Information
  ModulePass Manager
    Profiling information loader
    FunctionPass Manager
      Preliminary module verification
      Dominator Tree Construction
      Module Verifier
      Natural Loop Construction
      Canonicalize natural loops
      Scalar Evolution Analysis
      Loop Pass Manager
        Loop Strength Reduction
      Lower Garbage Collection Instructions
      Remove unreachable blocks from the CFG
      Optimize for code generation
      Insert stack protectors
      X86 DAG->DAG Instruction Selection
      X86 FP_REG_KILL inserter
      X86 Maximal Stack Alignment Calculator
      <MY PASS RUNS HERE>


> Also, does bb.getBasicBlock() for sure always returns a valid block
> refrerence?

Yes. I am printing bb and *bb.getBasicBlock() in order to compare the
contents of the IR in the BasicBlock and the target assembly in the
MachineBasicBlock.

> You are getting the PI by getAnalysis<ProfileInfo>() I presume? Is this
> really the instance created by ProfileLoaderPass?

Yes, I have "PI = &getAnalysis<ProfileInfo>()" in my code (modeled
after BasicBlockPlacement.cpp).  However, when I run gdb the value of
the Pass* pointer returned by createProfileLoaderPass() does not match
the value of PI (of type ProfileInfo*) that I see inside my
MachineFunctionPass.  The abbreviated output of gdb is found below:

Breakpoint 1, main (argc=11, argv=0xbfffd394) at <path to llvm>/tools/
llc/llc.cpp:292
292	      Pass* tmp = createProfileLoaderPass();
(gdb) p tmp
$1 = (class llvm::Pass *) 0x3573000
(gdb) c
Continuing.

Breakpoint 2, main (argc=11, argv=0xbfffd394) at <path to llvm>/tools/
llc/llc.cpp:293
293	      Passes.add(tmp);
(gdb) p tmp
$2 = (class llvm::Pass *) 0x8feeaf0

So the address of the ProfileLoaderPass should be 0x8feeaf0 correct?
But I see the following inside my own pass:

Breakpoint 3, MyCodeGenPass::runOnMachineFunction (this=0x90be200,
MF=@0x90ca280) at <path to llvm>/lib/Target/X86/MyCodeGenPass.cpp:108
108	                   <random line of code after PI =
&getAnalysis<ProfileInfo>() executes>
(gdb) p PI
$3 = (class llvm::ProfileInfo *) 0x90be438


> (I guess for the last two questions its best to use gdb, are you
> familiar with it?)

I have a working knowledge :) but haven't used any bells and whistles.

Thanks for your help.

From criswell at cs.uiuc.edu  Thu Sep 10 10:00:55 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 10 Sep 2009 10:00:55 -0500
Subject: [LLVMdev] Finding call points to a function
In-Reply-To: <4AA89E76.2060105@mxc.ca>
References: <bf0e41fc0909092158k385fb69dxd52e04d1f2cb7012@mail.gmail.com>
	<4AA89E76.2060105@mxc.ca>
Message-ID: <4AA914A7.4020704@cs.uiuc.edu>

Nick Lewycky wrote:
> Rakesh Komuravelli wrote:
>   
>> Hi,
>>
>> I am writing an LLVM Pass and I would like to know how would I do the 
>> following:
>>
>> 1. I have a function foo, and I need to get all the call points calling 
>> this function in each Function of the Module. The only way I can think 
>> of is to iterate over the BasicBlocks of each Function, look for all the 
>> Call Instructions and check if the called function is foo. I was 
>> wondering if there is any other better way to do this.
>>     
>
> Iterate over @foo's use list. 
> http://wiki.llvm.org/HowTo:_Find_all_call_sites_of_a_function
>   
Note that you can have indirect calls to function foo.  If foo is marked
with internal linkage, then the only way it can be used indirectly is if
it has a use that is either:

a) Not a call instruction
b) Is a call instruction, but foo is passed as an argument to the function

If foo is marked with external linkage, then, in theory, external
libraries linked into the program after code generation can call foo.

If you need to deal with indirect function calls, there are some
options.  First, I believe the CallGraph analysis pass provides correct
(but very conservative) information on which functions are reachable by
which indirect call instructions.  If you need more accurate results,
then you can use the DSA pointer analysis code in the poolalloc project.

>   
>> 2. Is it possible to distinguish a class method from a non class method 
>> while analyzing the emitted LLVM code for a C++ program? Because, I need 
>> to interpret the calls made to foo differently in a class method and in 
>> a non class method.
>>     
>
> No. Methods turn into functions that happen to take the class type 
> pointer as first argument.
>   
There might be a hack'ish way to do this.  The LLVM function name is (or
is close to) the mangled name of the original C++ function.  If you're
unable to demangle the name, you should be able to tell whether the
function is a class method or a regular function.

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


From astifter-llvm at gmx.at  Thu Sep 10 10:23:29 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Thu, 10 Sep 2009 17:23:29 +0200
Subject: [LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH]
 &	Question: Preserving ProfileInfo for backend.)
In-Reply-To: <4cb478d1-4cd9-4133-9bee-4ff07d3d97d9@j19g2000yqk.googlegroups.com>
References: <4AA61556.6090300@gmx.at>	<A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com>
	<4071a327-c2d3-4757-85a7-a1c4c4c10275@y21g2000yqn.googlegroups.com>
	<4AA7EA1A.2020007@gmx.at>	<d9bf7e58-6457-4344-be5a-22474c12d0b3@g31g2000yqc.googlegroups.com>	<4AA8BA59.1000100@gmx.at>
	<4cb478d1-4cd9-4133-9bee-4ff07d3d97d9@j19g2000yqk.googlegroups.com>
Message-ID: <4AA919F1.6070306@gmx.at>

Shuguang Feng wrote:
>> What does "llc -debug-pass=Structure" say? Is the ProfileLoaderPass
>> really the last pass to touch the ProfileInfo before you are using it?
> 
> Below is the sequence of passes that I see.  Although the
> NoProfileInfo pass is being run, it should be subsequently overridden
> by ProfileInfoLoaderPass (LoaderPass) correct?

Yes.

> Target Data Layout
> Create Garbage Collector Module Metadata
> Basic Alias Analysis (default AA impl)
> DWARF Information Writer
> No Profile Information
> Module Information
>   ModulePass Manager
>     FunctionPass Manager
>       Preliminary module verification
>       Dominator Tree Construction
>       Module Verifier
>       Natural Loop Construction
>       Canonicalize natural loops
>       Scalar Evolution Analysis
>       Loop Pass Manager
>         Loop Strength Reduction
>       Lower Garbage Collection Instructions
>       Remove unreachable blocks from the CFG
>       Optimize for code generation
>       Insert stack protectors
>       X86 DAG->DAG Instruction Selection
>       X86 FP_REG_KILL inserter
>       X86 Maximal Stack Alignment Calculator
>       <MY PASS RUNS HERE>
> 
> 
>> Also, does bb.getBasicBlock() for sure always returns a valid block
>> refrerence?
> 
> Yes. I am printing bb and *bb.getBasicBlock() in order to compare the
> contents of the IR in the BasicBlock and the target assembly in the
> MachineBasicBlock.
> 
>> You are getting the PI by getAnalysis<ProfileInfo>() I presume? Is this
>> really the instance created by ProfileLoaderPass?
> 
> Yes, I have "PI = &getAnalysis<ProfileInfo>()" in my code (modeled
> after BasicBlockPlacement.cpp).  However, when I run gdb the value of
> the Pass* pointer returned by createProfileLoaderPass() does not match
> the value of PI (of type ProfileInfo*) that I see inside my
> MachineFunctionPass.  The abbreviated output of gdb is found below:
> 
> Breakpoint 1, main (argc=11, argv=0xbfffd394) at <path to llvm>/tools/
> llc/llc.cpp:292
> 292	      Pass* tmp = createProfileLoaderPass();
> (gdb) p tmp
> $1 = (class llvm::Pass *) 0x3573000
> (gdb) c
> Continuing.
> 
> Breakpoint 2, main (argc=11, argv=0xbfffd394) at <path to llvm>/tools/
> llc/llc.cpp:293
> 293	      Passes.add(tmp);
> (gdb) p tmp
> $2 = (class llvm::Pass *) 0x8feeaf0
> 
> So the address of the ProfileLoaderPass should be 0x8feeaf0 correct?
> But I see the following inside my own pass:
> 
> Breakpoint 3, MyCodeGenPass::runOnMachineFunction (this=0x90be200,
> MF=@0x90ca280) at <path to llvm>/lib/Target/X86/MyCodeGenPass.cpp:108
> 108	                   <random line of code after PI =
> &getAnalysis<ProfileInfo>() executes>
> (gdb) p PI
> $3 = (class llvm::ProfileInfo *) 0x90be438

I *guess* this two pointer should point to the same object, this could
explain why the ProfileInfo you are reading is not the expected one. Can
anyone from the list confirm this?

It *is* allowed to access ModulePass analysis information from an
FunctionPass?

Can you try to manually override the PI value in the
MyCodeGenPass::runOnMachineFunction() to the value seen in llc and then
access the ProfileInfo?

>> (I guess for the last two questions its best to use gdb, are you
>> familiar with it?)
> 
> I have a working knowledge :) but haven't used any bells and whistles.

Worked fine enough!

Andi

From shuguang.feng at gmail.com  Thu Sep 10 11:21:47 2009
From: shuguang.feng at gmail.com (Shuguang Feng)
Date: Thu, 10 Sep 2009 09:21:47 -0700 (PDT)
Subject: [LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] &
	Question: Preserving ProfileInfo for backend.)
In-Reply-To: <4AA919F1.6070306@gmx.at>
References: <4AA61556.6090300@gmx.at>
	<A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com> 
	<4071a327-c2d3-4757-85a7-a1c4c4c10275@y21g2000yqn.googlegroups.com> 
	<4AA7EA1A.2020007@gmx.at>
	<d9bf7e58-6457-4344-be5a-22474c12d0b3@g31g2000yqc.googlegroups.com>
	<4AA8BA59.1000100@gmx.at>
	<4cb478d1-4cd9-4133-9bee-4ff07d3d97d9@j19g2000yqk.googlegroups.com>
	<4AA919F1.6070306@gmx.at>
Message-ID: <62cd7614-dae8-4e34-ace1-786c5dbc0c0f@h13g2000yqk.googlegroups.com>

> It *is* allowed to access ModulePass analysis information from an
> FunctionPass?

BasicBlockPlacement (a FunctionPass) also accesses the profile
information and I assumed it worked (but haven't independently
verified this).

> Can you try to manually override the PI value in the
> MyCodeGenPass::runOnMachineFunction() to the value seen in llc and then
> access the ProfileInfo?

Good suggestion.  Unfortunately the end result is that for some blocks
instead of seeing the sentinel value of "-1" I see other bogus
execution counts instead.  For example, llvm-prof prints out the
following as the most frequently executed basic block:

 ##      %% 	Frequency
  1. 4.80749% 18002906/3.74476e+08	inflate_stored() - bb20

but in my pass the frequency I see from PI->getExecutionCount
(bb.getBasicBlock()) for the exact same BasicBlock (bb20 from function
inflate_stored()) is 7.47821e-316.  I verified that PI is indeed
pointing to the same object created in llc.cpp with the following gdb
trace:

Breakpoint 1, main (argc=11, argv=0xbfffd394) at <path to llvm>/tools/
llc/llc.cpp:293
293	      Passes.add(tmp);
(gdb) p tmp
$1 = (class llvm::Pass *) 0x8feeaf0
(gdb) c
Continuing.

Breakpoint 2, MyCodeGenPass::runOnMachineFunction (this=0x90be200,
MF=@0x90ca280) at <path to llvm>/lib/Target/X86/MyCodeGenPass.cpp:100
100	      <random line of code after executing PI = (ProfileInfo*)
0x8feeaf0>
(gdb) p PI
$2 = (class llvm::ProfileInfo *) 0x8feeaf0
(gdb) clear
Deleted breakpoint 2
(gdb) c
Continuing.

I will go back through my files and make sure I didn't do anything
silly when I merged the latest ProfileInfo* code with my LLVM-2.5
codebase.

From clattner at apple.com  Thu Sep 10 11:25:12 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 10 Sep 2009 09:25:12 -0700
Subject: [LLVMdev] Build problem with gcc-4.3.2
In-Reply-To: <nnbplj2i3n.fsf@stalhein.lysator.liu.se>
References: <nnbplj2i3n.fsf@stalhein.lysator.liu.se>
Message-ID: <007D528F-DDD2-4062-AD9A-D7882787E438@apple.com>


On Sep 10, 2009, at 3:45 AM, Niels M?ller wrote:

> Hi,
>
> on http://llvm.org/docs/GettingStarted.html#requirements you say you
> want to know about problems compiling llvm with gcc.
>
> I just tried compiling llvm and clang, using ./configure; make, and I
> got the following error,
>
>  llvm[2]: Compiling StrongPHIElimination.cpp for Debug build
>  StrongPHIElimination.cpp:1051: internal compiler error: in  
> value_format, at dwarf2out.c:7218
>  Please submit a full bug report,
>  with preprocessed source if appropriate.
>  See <http://gcc.gnu.org/bugs.html> for instructions.
>  /bin/rm: cannot remove `/home/nisse/hack/llvm/lib/CodeGen/Debug/ 
> StrongPHIElimination.d.tmp': No such file or directory
>  make[2]: *** [/home/nisse/hack/llvm/lib/CodeGen/Debug/ 
> StrongPHIElimination.o] Error 1
>  make[2]: Leaving directory `/home/nisse/hack/llvm/lib/CodeGen'
>  make[1]: *** [CodeGen/.makeall] Error 2
>  make[1]: Leaving directory `/home/nisse/hack/llvm/lib'
>  make: *** [all] Error 1
>
> This is on a debian gnu/linux x86 box, using gcc-4.3.2 which (as far
> as I remember) was compiled with default options. I checked out
> revision 81438 from http://llvm.org/svn/llvm-project/llvm/trunk.

Thanks, I added it to the wall of shame :)

-Chris

From horwitz at cs.wisc.edu  Thu Sep 10 12:23:10 2009
From: horwitz at cs.wisc.edu (Susan Horwitz)
Date: Thu, 10 Sep 2009 12:23:10 -0500 (CDT)
Subject: [LLVMdev] problem with multiple LLVM passes
Message-ID: <Pine.LNX.4.64.0909101221490.4193@curds.cs.wisc.edu>

I'm trying to write two LLVM passes, one of which uses the results of the
other.  The first is LiveVars and the second is RemoveUseless.  In the
RemoveUseless class I have:
   virtual void getAnalysisUsage(AnalysisUsage &AU) const {
     AU.addRequired<LiveVars>();
   }

This compiles fine, but when I try to run it I get an error:
       Pass class not registered!

The error goes away if I take out that "addRequired".

The code for the LiveVars pass includes
 	RegisterPass<LiveVars> X("liveVars", "Live vars analysis", true,
 	true);

and I can run the LiveVars pass like this:
 	opt -load Debug/lib/dataflowAnalysis.so -f -analyze -liveVars ...

I've tried running the RemoveUseless pass with various combinations of flags 
(just -removeUseless, both -liveVars and -removeUseles, with and without 
-analyze), but I always get the same error.


Any help will be much appreciated!

From devang.patel at gmail.com  Thu Sep 10 12:48:41 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Thu, 10 Sep 2009 10:48:41 -0700
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with LLVM
	instruction
Message-ID: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>

Hi All,

Today, debugging information is encoded in LLVM IR using various
llvm.dbg intrinsics, such as llvm.dbg.stoppoint. For exmaple,

!1 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c", metadata
!"/tmp", metadata !"clang 1.0", i1 true, i1 false, metadata !"", i32
0}

  ...
  call void @llvm.dbg.stoppoint(i32 5, i32 5, metadata !1)
  store i32 42, i32* %i
  call void @llvm.dbg.stoppoint(i32 6, i32 5, metadata !1)
  store i32 1, i32* %j.addr
  br label %if.end
  ...


This approach has several disadvantages.
- The llvm.dbg.stoppoint()s act like hurdles to the optimizer. The
LLVM customers expect that the optimizer does not trip over these
hurdles. They expect LLVM to produce same high quality code
irrespective of the presence of debug info. It is a tedious and never
ending task to ensure that the optimizer safely ignores these llvm.dbg
intrinsics.
- The instructions lose original location info when the optimizer
moves them around.
- It is extremely error prone to keep track of lexical scopes and
inlined functions using a pair of llvm.dbg intrinsics.


The proposed solution is to optionally attach debug information with
llvm instruction directly. A new keyword 'dbg' is used to identify
debugging information associated with an instruction. The debugging
information, if available, is printed after the last instruction
operand. The debugging information entry uses MDNode and it is not
counted as an instruction operand. For example,

!1 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c", metadata
!"/tmp", metadata !"clang 1.0", i1 true, i1 false, metadata !"", i32
0}
!7 = metadata !{i32 5, i32 5, metadata !1, metadata !1}
!8 = metadata !{i32 6, i32 5, metadata !1, metadata !1}

  ...
  store i32 42, i32* %i, dbg metadata !7
  store i32 1, i32* %j.addr, dbg metadata !8
  br label %if.end, dbg metadata !8
  ...


Now, the optimizer does not need to worry about those llvm.dbg
hurdles. Instructions do not lose their location information when they
are rearranged in instruction stream. And the stage is set to produce,
preserve and emit accurate debug information for inlined functions.

Any thoughts/suggestions/questions ?

-
Devang

From mrs at apple.com  Thu Sep 10 13:10:41 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 10 Sep 2009 11:10:41 -0700
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with
	LLVM	instruction
In-Reply-To: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
Message-ID: <09F9ED66-AA27-4063-94C8-08588089A982@apple.com>

On Sep 10, 2009, at 10:48 AM, Devang Patel wrote:
> Any thoughts/suggestions/questions ?

Sounds good to me.

From clattner at apple.com  Thu Sep 10 15:14:24 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 10 Sep 2009 13:14:24 -0700
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with
	LLVM	instruction
In-Reply-To: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
Message-ID: <84D053DD-6FA4-49FE-A5B0-77D314D0EA8E@apple.com>


On Sep 10, 2009, at 10:48 AM, Devang Patel wrote:

> Hi All,
>
> Today, debugging information is encoded in LLVM IR using various
> llvm.dbg intrinsics, such as llvm.dbg.stoppoint. For exmaple,

Right.

> This approach has several disadvantages.
> - The llvm.dbg.stoppoint()s act like hurdles to the optimizer. The
> LLVM customers expect that the optimizer does not trip over these
> hurdles. They expect LLVM to produce same high quality code
> irrespective of the presence of debug info. It is a tedious and never
> ending task to ensure that the optimizer safely ignores these llvm.dbg
> intrinsics.

This is not a problem with stoppoints.  Even after we eliminate  
stoppoints, we'll still have the same thing for other debug info.

> - The instructions lose original location info when the optimizer
> moves them around.
> - It is extremely error prone to keep track of lexical scopes and
> inlined functions using a pair of llvm.dbg intrinsics.

Right.

> The proposed solution is to optionally attach debug information with
> llvm instruction directly. A new keyword 'dbg' is used to identify
> debugging information associated with an instruction. The debugging
> information, if available, is printed after the last instruction
> operand. The debugging information entry uses MDNode and it is not
> counted as an instruction operand. For example,
>
> !1 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c", metadata
> !"/tmp", metadata !"clang 1.0", i1 true, i1 false, metadata !"", i32
> 0}
> !7 = metadata !{i32 5, i32 5, metadata !1, metadata !1}
> !8 = metadata !{i32 6, i32 5, metadata !1, metadata !1}
>
>  ...
>  store i32 42, i32* %i, dbg metadata !7
>  store i32 1, i32* %j.addr, dbg metadata !8
>  br label %if.end, dbg metadata !8
>  ...

Instead of 'dbg metadata !7', is it sufficient to have 'dbg !7'?

I think this is a pretty reasonable syntax, we can even get the  
asmprinter to handle this as a special case and print it as:

store i32 42, i32* %i, dbg metadata !{i32 5, i32 5, metadata !1,  
metadata !1}

which makes it easier to read.

> Now, the optimizer does not need to worry about those llvm.dbg
> hurdles. Instructions do not lose their location information when they
> are rearranged in instruction stream. And the stage is set to produce,
> preserve and emit accurate debug information for inlined functions.

Sounds nice!

-Chris

From echristo at apple.com  Thu Sep 10 15:33:01 2009
From: echristo at apple.com (Eric Christopher)
Date: Thu, 10 Sep 2009 13:33:01 -0700
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with
	LLVM	instruction
In-Reply-To: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
Message-ID: <DAEB5CAD-9EC5-42A9-99E6-F20FA0DE88F8@apple.com>


On Sep 10, 2009, at 10:48 AM, Devang Patel wrote:

> The proposed solution is to optionally attach debug information with
> llvm instruction directly. A new keyword 'dbg' is used to identify
> debugging information associated with an instruction. The debugging
> information, if available, is printed after the last instruction
> operand. The debugging information entry uses MDNode and it is not
> counted as an instruction operand. For example,
>
> !1 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c", metadata
> !"/tmp", metadata !"clang 1.0", i1 true, i1 false, metadata !"", i32
> 0}
> !7 = metadata !{i32 5, i32 5, metadata !1, metadata !1}
> !8 = metadata !{i32 6, i32 5, metadata !1, metadata !1}
>
>  ...
>  store i32 42, i32* %i, dbg metadata !7
>  store i32 1, i32* %j.addr, dbg metadata !8
>  br label %if.end, dbg metadata !8
>  ...

So, if we later wanted to attach some other metadata to an instruction  
it would look something like:

store i32 42, i32* %i, dbg metadata !7, spork !15

or some such? And when you attach the metadata to the instruction how  
do you plan on making it evident as debug as opposed to spork?

-eric

From edwintorok at gmail.com  Thu Sep 10 15:39:51 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Thu, 10 Sep 2009 23:39:51 +0300
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with LLVM
	instruction
In-Reply-To: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
Message-ID: <4AA96417.2040506@gmail.com>

On 2009-09-10 20:48, Devang Patel wrote:
> Now, the optimizer does not need to worry about those llvm.dbg
> hurdles. Instructions do not lose their location information when they
> are rearranged in instruction stream. And the stage is set to produce,
> preserve and emit accurate debug information for inlined functions.
>
> Any thoughts/suggestions/questions ?
>   

Sounds good.

To ease transition from LLVM 2.6->2.7, could there be a pass that adds
back the llvm.dbg intrinsics based on the metadata on the instructions?
No in-tree pass should need that, but it could help external projects
that rely on stoppoints being present.

Also would it be possible to have source:line debuginfo generated for
macros (at least in clang)?
The debug info generated by gcc, llvm-gcc or clang doesn't deal with
macros in a way that would allow single-stepping through them.
-g3 in gcc allows me to expand a macro from gcc, but thats it, as far as
debugging is concerned it acts like a single instruction, not
single-steppable.

I generally tend to avoid the use of macros that do something
non-trivial (i.e. requires debugging), but unfortunately C doesn't
support templates,
so in some situations I am forced to use macros, instead of functions.

Best regards,
--Edwin

From clattner at apple.com  Thu Sep 10 16:10:03 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 10 Sep 2009 14:10:03 -0700
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with	LLVM
	instruction
In-Reply-To: <DAEB5CAD-9EC5-42A9-99E6-F20FA0DE88F8@apple.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
	<DAEB5CAD-9EC5-42A9-99E6-F20FA0DE88F8@apple.com>
Message-ID: <9064DA23-87DE-4E51-87B3-D86E900CC22F@apple.com>


On Sep 10, 2009, at 1:33 PM, Eric Christopher wrote:

>> store i32 42, i32* %i, dbg metadata !7
>> store i32 1, i32* %j.addr, dbg metadata !8
>> br label %if.end, dbg metadata !8
>> ...
>
> So, if we later wanted to attach some other metadata to an instruction
> it would look something like:
>
> store i32 42, i32* %i, dbg metadata !7, spork !15
>
> or some such? And when you attach the metadata to the instruction how
> do you plan on making it evident as debug as opposed to spork?

yes, I'll send out a proposal to cover this in the next couple days.

-Chris

From devang.patel at gmail.com  Thu Sep 10 16:52:11 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Thu, 10 Sep 2009 14:52:11 -0700
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with LLVM
	instruction
In-Reply-To: <84D053DD-6FA4-49FE-A5B0-77D314D0EA8E@apple.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
	<84D053DD-6FA4-49FE-A5B0-77D314D0EA8E@apple.com>
Message-ID: <352a1fb20909101452g35f4c78o83001d0884a21fe8@mail.gmail.com>

On Thu, Sep 10, 2009 at 1:14 PM, Chris Lattner <clattner at apple.com> wrote:

>> ?...
>> ?store i32 42, i32* %i, dbg metadata !7
>> ?store i32 1, i32* %j.addr, dbg metadata !8
>> ?br label %if.end, dbg metadata !8
>> ?...
>
> Instead of 'dbg metadata !7', is it sufficient to have 'dbg !7'?

It is! In fact, that's what my prototype does.
-
Devang


From rich at pennware.com  Thu Sep 10 16:55:16 2009
From: rich at pennware.com (Richard Pennington)
Date: Thu, 10 Sep 2009 16:55:16 -0500
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with
	LLVM	instruction
In-Reply-To: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
Message-ID: <4AA975C4.2040804@pennware.com>

Devang Patel wrote:
>
>   store i32 42, i32* %i, dbg metadata !7
>   store i32 1, i32* %j.addr, dbg metadata !8
>   br label %if.end, dbg metadata !8
>   ...
> 
> 
> Now, the optimizer does not need to worry about those llvm.dbg
> hurdles. Instructions do not lose their location information when they
> are rearranged in instruction stream. And the stage is set to produce,
> preserve and emit accurate debug information for inlined functions.
>

I like this.

Would it be very ugly to treat stoppoint like a pseudo op that filled in 
the metadata for subsequent instructions until the end of the basic 
block? It might help for backward compatibility.

-Rich

From devang.patel at gmail.com  Thu Sep 10 16:56:24 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Thu, 10 Sep 2009 14:56:24 -0700
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with LLVM
	instruction
In-Reply-To: <4AA96417.2040506@gmail.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
	<4AA96417.2040506@gmail.com>
Message-ID: <352a1fb20909101456y5c7791f3kcef8bbe9b4d982f0@mail.gmail.com>

2009/9/10 T?r?k Edwin <edwintorok at gmail.com>:
> On 2009-09-10 20:48, Devang Patel wrote:
>> Now, the optimizer does not need to worry about those llvm.dbg
>> hurdles. Instructions do not lose their location information when they
>> are rearranged in instruction stream. And the stage is set to produce,
>> preserve and emit accurate debug information for inlined functions.
>>
>> Any thoughts/suggestions/questions ?
>>
>
> Sounds good.
>
> To ease transition from LLVM 2.6->2.7, could there be a pass that adds
> back the llvm.dbg intrinsics based on the metadata on the instructions?

I'd prefer to not overload llvm.dbg intrinsics, if possible.

> No in-tree pass should need that, but it could help external projects
> that rely on stoppoints being present.
.. just during transition or forever ?

-
Devang


From jlerouge at apple.com  Thu Sep 10 19:55:37 2009
From: jlerouge at apple.com (Julien Lerouge)
Date: Thu, 10 Sep 2009 17:55:37 -0700
Subject: [LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
Message-ID: <20090911005537.GA48002@pom.apple.com>

Hello folks,

I have a small piece of C code written like this:

    typedef struct {
        char a;
        int b;
        int c;
    } foo;
    
    foo myFoo[5] = {{0}};

With llvm-gcc 2.5, I get the following IR:

    %struct.foo = type { i8, i32, i32 }
    @myFoo = global [5 x %struct.foo] zeroinitializer, align 32

With the current 2.6, I get this:

    %0 = type { i8, [11 x i8] }
    %struct.foo = type { i8, i32, i32 }
    @myFoo = global [5 x %0] zeroinitializer, align 32

Is there any reason for the change ? It is weird that in the end, with
2.6 myFoo doesn't have the [5 x %struct.foo]* type.

Thanks,
Julien

-- 
Julien Lerouge
PGP Key Id: 0xB1964A62
PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62
PGP Public Key from: keyserver.pgp.com

From samuraileumas at yahoo.com  Thu Sep 10 22:10:00 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Thu, 10 Sep 2009 20:10:00 -0700 (PDT)
Subject: [LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
In-Reply-To: <20090911005537.GA48002@pom.apple.com>
References: <20090911005537.GA48002@pom.apple.com>
Message-ID: <663952.56915.qm@web62003.mail.re1.yahoo.com>

Hello Julien,

I think the reason for the change was because there is processor context information stored in the type in 2.6.  The reason it's there is to support multicore JIT architecture.

--Sam



----- Original Message ----
> From: Julien Lerouge <jlerouge at apple.com>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Thursday, September 10, 2009 7:55:37 PM
> Subject: [LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
> 
> Hello folks,
> 
> I have a small piece of C code written like this:
> 
>     typedef struct {
>         char a;
>         int b;
>         int c;
>     } foo;
>     
>     foo myFoo[5] = {{0}};
> 
> With llvm-gcc 2.5, I get the following IR:
> 
>     %struct.foo = type { i8, i32, i32 }
>     @myFoo = global [5 x %struct.foo] zeroinitializer, align 32
> 
> With the current 2.6, I get this:
> 
>     %0 = type { i8, [11 x i8] }
>     %struct.foo = type { i8, i32, i32 }
>     @myFoo = global [5 x %0] zeroinitializer, align 32
> 
> Is there any reason for the change ? It is weird that in the end, with
> 2.6 myFoo doesn't have the [5 x %struct.foo]* type.
> 
> Thanks,
> Julien
> 
> -- 
> Julien Lerouge
> PGP Key Id: 0xB1964A62
> PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62
> PGP Public Key from: keyserver.pgp.com
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



      

From rayfix.ml at gmail.com  Thu Sep 10 22:48:17 2009
From: rayfix.ml at gmail.com (Ray Fix)
Date: Thu, 10 Sep 2009 23:48:17 -0400
Subject: [LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
In-Reply-To: <663952.56915.qm@web62003.mail.re1.yahoo.com>
References: <20090911005537.GA48002@pom.apple.com>
	<663952.56915.qm@web62003.mail.re1.yahoo.com>
Message-ID: <1A65F032-8E8B-43A9-B347-C4BF8430BDE1@gmail.com>

On Sep 10, 2009, at 11:10 PM, Samuel Crow wrote:
> I think the reason for the change was because there is processor  
> context information stored in the type in 2.6.  The reason it's  
> there is to support multicore JIT architecture.

Interesting.  FWIW, clang-cc -emit-llvm also produces something  
similar but not quite the same:

>> From: Julien Lerouge <jlerouge at apple.com>
>> I have a small piece of C code written like this:
>>
>>    typedef struct {
>>        char a;
>>        int b;
>>        int c;
>>    } foo;
>>
>>    foo myFoo[5] = {{0}};


%0 = type <{ %1, %struct.anon, %struct.anon, %struct.anon,  
%struct.anon }>
%1 = type { i8, [11 x i8] }
%struct.anon = type { i8, i32, i32 }

@myFoo = global %0 zeroinitializer, align 4       ; <%0*> [#uses=0]

So that [11 x i8] is somehow for multicore JIT?  It produces this even  
if the architecture is set to blackfin.   This seems pretty weird and  
non-intuitive to me too.  I would be interested in learning about the  
rationale. Ultimately clang is storing 3 bytes extra in the lead  
element, llvm-gcc has 3*5=15.

Ray





From ssen at apple.com  Fri Sep 11 00:07:05 2009
From: ssen at apple.com (Shantonu Sen)
Date: Thu, 10 Sep 2009 22:07:05 -0700
Subject: [LLVMdev] Grand Central Dispatch open sourced,
	with links to clang/compiler-rt
Message-ID: <09DC57CC-2378-4F6E-AD4F-E90F8AA44235@apple.com>

Hello,

The source code for Grand Central Dispatch (libdispatch) in Mac OS X  
10.6 Snow Leopard has been released: <http:// 
libdispatch.macosforge.org/>

Prominently noted on the page is a link for a portable C compiler with  
blocks support (clang) and the blocks runtime (part of compiler-rt)!

The libdispatch project consists of the user space implementation of  
the Grand Central Dispatch API as seen in Mac OS X version 10.6 Snow  
Leopard. The Mac OS X kernel support for GCD may be found in the xnu  
project. While kernel support provides many performance optimizations  
on Mac OS X, it is not strictly required for portability to other  
platforms. However, in order to implement the full API for Grand  
Central Dispatch, C compiler support for blocks is required. The  
blocks runtime is available as part of the LLVM project.

Shantonu

Sent from my MacBook

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

From baldrick at free.fr  Fri Sep 11 02:15:18 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 11 Sep 2009 09:15:18 +0200
Subject: [LLVMdev] [PROPOSAL] Attach debugging information
	with	LLVM	instruction
In-Reply-To: <DAEB5CAD-9EC5-42A9-99E6-F20FA0DE88F8@apple.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
	<DAEB5CAD-9EC5-42A9-99E6-F20FA0DE88F8@apple.com>
Message-ID: <4AA9F906.8050600@free.fr>

> So, if we later wanted to attach some other metadata to an instruction  
> it would look something like:

For example, we may want to attach a list of typeinfos to invokes,
representing the catch clauses.

Ciao,

Duncan.

From baldrick at free.fr  Fri Sep 11 02:22:59 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 11 Sep 2009 09:22:59 +0200
Subject: [LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
In-Reply-To: <20090911005537.GA48002@pom.apple.com>
References: <20090911005537.GA48002@pom.apple.com>
Message-ID: <4AA9FAD3.4020105@free.fr>

Hi Julien Lerouge,

> I have a small piece of C code written like this:
> 
>     typedef struct {
>         char a;
>         int b;
>         int c;
>     } foo;

>     %0 = type { i8, [11 x i8] }

I guess it wants to initialize the alignment padding to zero.  Anyway,
it sure looks like a bug/inefficiency.  Please open a bugreport.

Ciao,

Duncan.

From jlerouge at apple.com  Fri Sep 11 02:43:22 2009
From: jlerouge at apple.com (Julien Lerouge)
Date: Fri, 11 Sep 2009 00:43:22 -0700
Subject: [LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
In-Reply-To: <4AA9FAD3.4020105@free.fr>
References: <20090911005537.GA48002@pom.apple.com> <4AA9FAD3.4020105@free.fr>
Message-ID: <20090911074321.GA71320@pom.apple.com>

On Fri, Sep 11, 2009 at 09:22:59AM +0200, Duncan Sands wrote:
> I guess it wants to initialize the alignment padding to zero.  Anyway,
> it sure looks like a bug/inefficiency.  Please open a bugreport.

Alright, filed http://llvm.org/bugs/show_bug.cgi?id=4947

Thanks,
Julien

-- 
Julien Lerouge
PGP Key Id: 0xB1964A62
PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62
PGP Public Key from: keyserver.pgp.com

From sanjiv.gupta at microchip.com  Fri Sep 11 04:46:01 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Fri, 11 Sep 2009 15:16:01 +0530
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <3cb898890909101110x3b248a39g9a195507f445a390@mail.gmail.com>
References: <4AA2B20B.1030903@microchip.com>	
	<3cb898890909051332n4779e7fdt92824db8b4d9d72a@mail.gmail.com>	
	<4AA3F5D2.1040402@microchip.com>	
	<3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>	
	<3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>	
	<3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>	
	<4AA8793F.8080503@microchip.com> <4AA88DEB.3090700@microchip.com>	
	<3cb898890909100524h7e3658eer24572747d626b47b@mail.gmail.com>	
	<4AA93EEB.7060002@microchip.com>
	<3cb898890909101110x3b248a39g9a195507f445a390@mail.gmail.com>
Message-ID: <4AAA1C59.2010404@microchip.com>

Mikhail Glushenkov wrote:
> Hi,
>
> On Thu, Sep 10, 2009 at 8:01 PM, Sanjiv Gupta
> <sanjiv.gupta at microchip.com> wrote:
>   
>> Why do we need both 'conflict' and 'warning' ?
>>     
>
> 'warning' just prints a warning, 'conflict' is a fatal error.
>
> A better example would be something like:
>
> (warning (and (switch_on "O1"), (switch_on "O2")) "-O1 has no effect.")
>
>
>   
Looks good.
One more quick query.
How to extract  libname from "-l std" from the driver and pass it as 
"std.lib" to the linker tool?
I know that unpack_values will give me "std", but an (append_cmd ".lib") 
with that will insert a space.
Anything like append_cmd_nospace ? or any other way?

- Sanjiv



- Sanjiv

From the.dead.shall.rise at gmail.com  Fri Sep 11 07:10:40 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Fri, 11 Sep 2009 14:10:40 +0200
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <4AAA1C59.2010404@microchip.com>
References: <4AA2B20B.1030903@microchip.com>
	<3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>
	<3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>
	<3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>
	<4AA8793F.8080503@microchip.com> <4AA88DEB.3090700@microchip.com>
	<3cb898890909100524h7e3658eer24572747d626b47b@mail.gmail.com>
	<4AA93EEB.7060002@microchip.com>
	<3cb898890909101110x3b248a39g9a195507f445a390@mail.gmail.com>
	<4AAA1C59.2010404@microchip.com>
Message-ID: <3cb898890909110510m596e110do1156512055e36f67@mail.gmail.com>

Hi,

On Fri, Sep 11, 2009 at 11:46 AM, Sanjiv Gupta
<sanjiv.gupta at microchip.com> wrote:
>
> Looks good.
> One more quick query.
> How to extract ?libname from "-l std" from the driver and pass it as
> "std.lib" to the linker tool?
> I know that unpack_values will give me "std", but an (append_cmd ".lib")
> with that will insert a space.

This won't work since actions are not composable (alas).

> Anything like append_cmd_nospace ? or any other way?

I'm afraid there is no way to do this right now. One way to support
this is to extend the hook mechanism to work with actions:

(case (not_empty "-l"), (append_cmd "$CALL(AppendLibSuffix)"))

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


From Olaf.Krzikalla at tu-dresden.de  Fri Sep 11 07:24:11 2009
From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla)
Date: Fri, 11 Sep 2009 14:24:11 +0200
Subject: [LLVMdev] compiling clang with rtti
Message-ID: <4AAA416B.7060806@tu-dresden.de>

Hi @llvm,

I've already asked the following questions to the clang dev list but got no response. Maybe there is a wider audience at llvmdev and someone here can help me. The question actually boils down to: How can I compile clang with rtti enabled?

And this was my original mail (with some points now better explained) to clang:

<--BEGIN-->
Hi @clang,

I'm somewhat puzzled about using rtti when building clang under gcc (gcc 
4.3.3, linux/ubuntu).
(There is no problem under MSVC since rtti seems to be active there anyway).
The appropriate line 348 in llvm/makefile.rules is commented out meaning 
that llvm is usually compiled using rtti. However every clang lib adds 
-fno-rtti to CXXFLAGS by hand.
This is not filtered out by makefile.rules even if REQUIRES_RTTI is 
defined (IMHO -fno-rtti should be filtered out in that case).
Now I'm two-way bewildered.
First: why is line 348 commented out? This renders REQUIRES_RTTI 
useless. Does rtti (llvm) and non-rtti (clang) code work together at 
all? I had serious trouble when trying this with my own application and 
eventually resigned .

I'm forced to use rtti in my application as it uses some clang libs but 
also some tr1 stuff (which apparently needs rtti) and boost. This leads 
me to the second question:
How can I compile the clang libs with rtti enabled? Eventually I got it 
by editing every single Makefile in the "lib" sub-directories and 
commenting out the appropriate line "CXXFLAGS = -fno-rtti".

However this can't be a proper solution. As stated earlier if 
REQUIRES_RTTI would be evaluated similiar to ENABLE_EXPENSIVE_CHECKS 
regarding rtti then it would be easy to enable rtti for clang.
OTOH I'm not a makefile expert (to be honest I'm very far away from it). 
Thus maybe I'm just overlooking the right way to enable rtti for the 
clang libs.
<--END-->

Thanks in advance for any help...

Best regards
Olaf Krzikalla


-- 
Olaf Krzikalla
Technische Universitaet Dresden
Zentrum fuer Informationsdienste und Hochleistungsrechnen
Abteilung Verteiltes und Datenintensives Rechnen
Zellescher Weg 12, 01069 Dresden
Willersbau, Zimmer A105
Telefonnr.: +49 351 463-32442


From daniel at zuster.org  Fri Sep 11 10:39:28 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 11 Sep 2009 08:39:28 -0700
Subject: [LLVMdev] compiling clang with rtti
In-Reply-To: <4AAA416B.7060806@tu-dresden.de>
References: <4AAA416B.7060806@tu-dresden.de>
Message-ID: <6a8523d60909110839q392e1cc8k3c41bb9b569488eb@mail.gmail.com>

Hi Olaf,

On Fri, Sep 11, 2009 at 5:24 AM, Olaf Krzikalla
<Olaf.Krzikalla at tu-dresden.de> wrote:
> Hi @clang,
>
> I'm somewhat puzzled about using rtti when building clang under gcc (gcc
> 4.3.3, linux/ubuntu).
> (There is no problem under MSVC since rtti seems to be active there anyway).
> The appropriate line 348 in llvm/makefile.rules is commented out meaning
> that llvm is usually compiled using rtti. However every clang lib adds
> -fno-rtti to CXXFLAGS by hand.
> This is not filtered out by makefile.rules even if REQUIRES_RTTI is
> defined (IMHO -fno-rtti should be filtered out in that case).
> Now I'm two-way bewildered.
> First: why is line 348 commented out? This renders REQUIRES_RTTI
> useless. Does rtti (llvm) and non-rtti (clang) code work together at
> all? I had serious trouble when trying this with my own application and
> eventually resigned .

Dunno, but I think its fine to fix REQUIRES_RTTI, I'll do so right now.

> I'm forced to use rtti in my application as it uses some clang libs but
> also some tr1 stuff (which apparently needs rtti) and boost. This leads
> me to the second question:

That doesn't necessarily explain why you are forced to use RTTI (just
as clang doesn't use RTTI but LLVM does, and only the LLVM parts build
with RTTI).

 - Daniel

From clattner at apple.com  Fri Sep 11 11:57:03 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 11 Sep 2009 09:57:03 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
Message-ID: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>

Devang's work on debug info prompted this, thoughts welcome:
http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt

-Chris

From clattner at apple.com  Fri Sep 11 12:04:15 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 11 Sep 2009 10:04:15 -0700
Subject: [LLVMdev] opt -S change
Message-ID: <B8B19C32-1EEB-4D27-8E87-41DDBE707833@apple.com>

Hi Dan,

Please change all the tests you made use "opt %s -S" use "opt < %s - 
S".  I'm getting a ton of failures because of the moduleids include  
the full path to the bc file and it matches grep lines.  I fixed a  
couple of them on mainline, but these are just a few of the ones  
affecting me, it is probably easiest to revert my change and r81257  
and change all the tests at once again.

-Chris

From gohman at apple.com  Fri Sep 11 13:03:15 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 11 Sep 2009 11:03:15 -0700
Subject: [LLVMdev] opt -S change
In-Reply-To: <B8B19C32-1EEB-4D27-8E87-41DDBE707833@apple.com>
References: <B8B19C32-1EEB-4D27-8E87-41DDBE707833@apple.com>
Message-ID: <A3E5D284-DC9F-4655-A4D5-01CFE07697C6@apple.com>


On Sep 11, 2009, at 10:04 AM, Chris Lattner wrote:


> Hi Dan,
>
> Please change all the tests you made use "opt %s -S" use "opt < %s - 
> S".  I'm getting a ton of failures because of the moduleids include  
> the full path to the bc file and it matches grep lines.  I fixed a  
> couple of them on mainline, but these are just a few of the ones  
> affecting me, it is probably easiest to revert my
> change and r81257 and change all the tests at once again.

Fixed.

Dan


From kennethuil at gmail.com  Fri Sep 11 13:08:32 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Fri, 11 Sep 2009 13:08:32 -0500
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
Message-ID: <400d33ea0909111108p14218bf4p7851c42e31f52dd8@mail.gmail.com>

On Fri, Sep 11, 2009 at 11:57 AM, Chris Lattner <clattner at apple.com> wrote:
> The demand for metadata is even greater in non-C languages.  For high level
> scripting languages like python, it would be nice to be able to do static type
> inference and annotate various pointers with type class information ("this is
> a python string object", "this is a dictionary", whatever).

So this particular metadata would be an extension of the type?  And
get propagated through as you create instructions that depend on other
instructions which had the type metadata attached?

I found myself wishing for such a thing several times recently.  I
ended up using a "type tag" of type [0 x opaque*] in my structs to
force the type system to differentiate them from each other and make
unique classes out of them.  It works, but I need a separate hashtable
to get back to a "class description" from a Value of a given Type.

From clattner at apple.com  Fri Sep 11 13:28:00 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 11 Sep 2009 11:28:00 -0700
Subject: [LLVMdev] opt -S change
In-Reply-To: <A3E5D284-DC9F-4655-A4D5-01CFE07697C6@apple.com>
References: <B8B19C32-1EEB-4D27-8E87-41DDBE707833@apple.com>
	<A3E5D284-DC9F-4655-A4D5-01CFE07697C6@apple.com>
Message-ID: <83A3D4F4-6BF9-49F8-A5B6-10703CFB7B45@apple.com>


On Sep 11, 2009, at 11:03 AM, Dan Gohman wrote:

>
> On Sep 11, 2009, at 10:04 AM, Chris Lattner wrote:
>
>
>> Hi Dan,
>>
>> Please change all the tests you made use "opt %s -S" use "opt < %s - 
>> S".  I'm getting a ton of failures because of the moduleids include  
>> the full path to the bc file and it matches grep lines.  I fixed a  
>> couple of them on mainline, but these are just a few of the ones  
>> affecting me, it is probably easiest to revert my
>> change and r81257 and change all the tests at once again.
>
> Fixed.

thanks :)

From clattner at apple.com  Fri Sep 11 13:29:19 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 11 Sep 2009 11:29:19 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <400d33ea0909111108p14218bf4p7851c42e31f52dd8@mail.gmail.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<400d33ea0909111108p14218bf4p7851c42e31f52dd8@mail.gmail.com>
Message-ID: <9E911563-0635-48D4-B976-4D0E624FC66A@apple.com>


On Sep 11, 2009, at 11:08 AM, Kenneth Uildriks wrote:

> On Fri, Sep 11, 2009 at 11:57 AM, Chris Lattner <clattner at apple.com>  
> wrote:
>> The demand for metadata is even greater in non-C languages.  For  
>> high level
>> scripting languages like python, it would be nice to be able to do  
>> static type
>> inference and annotate various pointers with type class information  
>> ("this is
>> a python string object", "this is a dictionary", whatever).
>
> So this particular metadata would be an extension of the type?  And
> get propagated through as you create instructions that depend on other
> instructions which had the type metadata attached?

No, this would be a property of the operation.  In a dynamically typed  
language like python (and many others) a naive translation will turn  
all python objects into "void*"s.  However, with some static or  
dynamic analysis, many types can be guessed at or inferred.  This is a  
property of various operations, not about "void*".

-Chris


From criswell at cs.uiuc.edu  Fri Sep 11 14:36:39 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Fri, 11 Sep 2009 14:36:39 -0500
Subject: [LLVMdev] [Fwd: Re:  problem with multiple LLVM passes]
Message-ID: <4AAAA6C7.8080106@cs.uiuc.edu>

My reply button isn't working like it used to...
:)

-- John T.

-------------- next part --------------
An embedded message was scrubbed...
From: John Criswell <criswell at cs.uiuc.edu>
Subject: Re: [LLVMdev] problem with multiple LLVM passes
Date: Fri, 11 Sep 2009 14:35:52 -0500
Size: 2553
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090911/44fb77a5/attachment.eml 

From jyasskin at google.com  Fri Sep 11 15:20:34 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Fri, 11 Sep 2009 13:20:34 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
Message-ID: <bb55930e0909111320w6e8c18b2qdc652fa72be2058c@mail.gmail.com>

I've got a suggestion for a refinement:

Right now, we have classes like DILocation that wrap an MDNode* to
provide more convenient access to it. It would be more convenient for
users if instead of

  MDNode *DbgInfo = Inst->getMD(MDKind::DbgTag);
  Inst2->setMD(MDKind::DbgTag, DbgInfo);

they could write:

  DILocation DbgInfo = Inst->getMD<DILocation>();
  inst2->setMD(DbgInfo);

we'd use TheContext->RegisterMDKind<MyKindWrapper>() or
...Register<MyKindWrapper>("name"); to register a new kind. (I prefer
the first.)

These kind wrappers need a couple methods to make them work:

const StringRef KindWrapper::name("...");
KindWrapper(MDNode*);  // Except for special cases like LdStAlign.
KindWrapper::operator bool() {return mdnode!=NULL;} // ??
int StaticTypeId<KindWrapper>::value;  // Used for the proposal's MDKind
KindWrapper::ValidOnValue(const Value*);
MDNode* KindWrapper::merge(MDNode*, MDNode*)  // For the optimizers

StaticTypeId is a new class that maps each of its template arguments
to a small, unique integer, which may be different in different
executions.

Since the optimizers may want more methods over time, but we don't
really want to require users to extend their wrappers, we should say
that all wrappers must inherit from a particular type. I'd name this
type "MDKind" and rename the proposed MDKind to MDKindID. Then we can
add defaults to MDKind over time. Nothing needs to be virtual since
these types are all used as template arguments.

We could either use a global list of IDs for the MDKinds or have
separate lists for each Context. StaticTypeId can only provide a
global list, so giving each Context its own list would take an extra
lookup, and wouldn't provide any benefit I can see.

Chris mentioned that .bc files would store the mapping from name->ID,
so the fact that StaticTypeId changes its values between runs isn't a
problem.

Thoughts?

On Fri, Sep 11, 2009 at 9:57 AM, Chris Lattner <clattner at apple.com> wrote:
> Devang's work on debug info prompted this, thoughts welcome:
> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
>
> -Chris
> _______________________________________________
> 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  Fri Sep 11 16:11:20 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 11 Sep 2009 14:11:20 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
Message-ID: <3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>


On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote:


> Devang's work on debug info prompted this, thoughts welcome:
> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt

The document mentions "instructions" a lot. We'll want to be able to
apply metadata to ConstantExprs as well at least, if not also Arguments
(think noalias) and other stuff, so it seems best to just talk about
"values" instead, and DenseMap<Value *, ...> instead of
DenseMap<Instruction *, ...>.

Dan


From dag at cray.com  Fri Sep 11 16:57:35 2009
From: dag at cray.com (David Greene)
Date: Fri, 11 Sep 2009 16:57:35 -0500
Subject: [LLVMdev] [PROPOSAL] Attach debugging information with LLVM
	instruction
In-Reply-To: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
References: <352a1fb20909101048x1f492af7g865c0109ec150758@mail.gmail.com>
Message-ID: <200909111657.38387.dag@cray.com>

On Thursday 10 September 2009 12:48, Devang Patel wrote:

> !1 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c", metadata
> !"/tmp", metadata !"clang 1.0", i1 true, i1 false, metadata !"", i32
> 0}
> !7 = metadata !{i32 5, i32 5, metadata !1, metadata !1}
> !8 = metadata !{i32 6, i32 5, metadata !1, metadata !1}
>
>   ...
>   store i32 42, i32* %i, dbg metadata !7
>   store i32 1, i32* %j.addr, dbg metadata !8
>   br label %if.end, dbg metadata !8
>   ...

Hooray!  I like this and the suggestions others have brought forward to 
enhance it.

                               -Dave

From dag at cray.com  Fri Sep 11 17:23:57 2009
From: dag at cray.com (David Greene)
Date: Fri, 11 Sep 2009 17:23:57 -0500
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <bb55930e0909111320w6e8c18b2qdc652fa72be2058c@mail.gmail.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<bb55930e0909111320w6e8c18b2qdc652fa72be2058c@mail.gmail.com>
Message-ID: <200909111723.59396.dag@cray.com>

On Friday 11 September 2009 15:20, Jeffrey Yasskin wrote:
> I've got a suggestion for a refinement:
>
> Right now, we have classes like DILocation that wrap an MDNode* to
> provide more convenient access to it. It would be more convenient for
> users if instead of
>
>   MDNode *DbgInfo = Inst->getMD(MDKind::DbgTag);
>   Inst2->setMD(MDKind::DbgTag, DbgInfo);
>
> they could write:
>
>   DILocation DbgInfo = Inst->getMD<DILocation>();
>   inst2->setMD(DbgInfo);
>
> we'd use TheContext->RegisterMDKind<MyKindWrapper>() or
> ...Register<MyKindWrapper>("name"); to register a new kind. (I prefer
> the first.)

Yes, this is very convenient.  This along with the rest of Chris' proposal is
very similar to the way we handled metadata in a compiler I worked on years 
ago.  It was so useful we even used it to stash dataflow information away as
we did analysis.  Of course we had metatadat tagged on control structures as
well.  I'd like to see the currently proposal extended to other constructs as
Chris notes.

> StaticTypeId is a new class that maps each of its template arguments
> to a small, unique integer, which may be different in different
> executions.

How does this work across compilation units?  How about with shared LLVM 
libraries?  These kinds of global unique IDs are notoriously difficult
to get right.  I'd suggest using a third-party unique-id library.  Boost.UUID 
is one possibility but not the only one.

I have a few questions and comments about Chris' initial proposal as well.

- I don't like the separation between "built-in" metadata and "extended" 
  metadata.  Why not make all metadata use the RegisterMDKind interface and
  just have the LLVM libraries do it automatically for the "built-in" stuff?
  Having a separate namespace of enums is going to get confusing.  Practically
  every day I curse the fact that "int" is different than "MyInt" in C++.  :-/

- Defaulting alignment to 1 when metatadata is not present is going to be a
  huge performance hit on many architectures.  I hope we can find a better
  solution.  I'm not sure what it is yet because we have to maintain safety.
  I just fear a Pass inadvertantly dropping metadata and really screwing 
  things up.

This looks very promising!

                            -Dave

From dag at cray.com  Fri Sep 11 17:31:22 2009
From: dag at cray.com (David Greene)
Date: Fri, 11 Sep 2009 17:31:22 -0500
Subject: [LLVMdev] [PATCH] Spill Comments
Message-ID: <200909111731.22486.dag@cray.com>

Attached is a patch to print asm comments for spill information.
We've discussed the mechanisms before but I wanted to run the
patch by everyone before I start to commit pieces.

                             -Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spillcomments.patch
Type: text/x-diff
Size: 58930 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090911/9c86795e/attachment.bin 

From clattner at apple.com  Fri Sep 11 18:47:52 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 11 Sep 2009 16:47:52 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
Message-ID: <A1035606-5C6D-4435-91A6-317EE3DF8B4D@apple.com>


On Sep 11, 2009, at 2:11 PM, Dan Gohman wrote:

>
> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote:
>
>
>> Devang's work on debug info prompted this, thoughts welcome:
>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
>
> The document mentions "instructions" a lot. We'll want to be able to
> apply metadata to ConstantExprs as well at least, if not also  
> Arguments
> (think noalias) and other stuff, so it seems best to just talk about
> "values" instead, and DenseMap<Value *, ...> instead of
> DenseMap<Instruction *, ...>.

I wrote: "Note that this document talks about metadata for  
instructions, it might make sense to generalize this to being metadata  
for all non-uniqued values (global variables, functions, basic blocks,  
arguments), but I'm just keeping it simple for now."

However, constant exprs are uniqued.  What would you find it useful for?

-Chris

From gohman at apple.com  Fri Sep 11 18:55:37 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 11 Sep 2009 16:55:37 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <A1035606-5C6D-4435-91A6-317EE3DF8B4D@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
	<A1035606-5C6D-4435-91A6-317EE3DF8B4D@apple.com>
Message-ID: <988DF1AD-026B-4EB4-87AA-51F548D23393@apple.com>


On Sep 11, 2009, at 4:47 PM, Chris Lattner wrote:


>
> On Sep 11, 2009, at 2:11 PM, Dan Gohman wrote:
>
>
>>
>>
>> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote:
>>
>>
>>
>>
>>
>>> Devang's work on debug info prompted this, thoughts welcome:
>>>
>>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
>>>
>>
>>
>> The document mentions "instructions" a lot. We'll want to be able to
>>
>> apply metadata to ConstantExprs as well at least, if not also  
>> Arguments
>>
>> (think noalias) and other stuff, so it seems best to just talk about
>>
>> "values" instead, and DenseMap<Value *, ...> instead of
>>
>> DenseMap<Instruction *, ...>.
>>
>
> I wrote: "Note that this document talks about metadata for  
> instructions, it might make sense to generalize this to being  
> metadata for all non-uniqued values (global variables, functions,  
> basic blocks, arguments), but I'm just keeping it simple for now."

I missed that part.

> However, constant exprs are uniqued.  What would you find it useful  
> for?

We have inbounds on ConstantExprs today, for example.

Dan


From clattner at apple.com  Fri Sep 11 18:57:58 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 11 Sep 2009 16:57:58 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <988DF1AD-026B-4EB4-87AA-51F548D23393@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
	<A1035606-5C6D-4435-91A6-317EE3DF8B4D@apple.com>
	<988DF1AD-026B-4EB4-87AA-51F548D23393@apple.com>
Message-ID: <F4153558-FA86-4C98-827B-269101365C0A@apple.com>


On Sep 11, 2009, at 4:55 PM, Dan Gohman wrote:

>>
>> I wrote: "Note that this document talks about metadata for  
>> instructions, it might make sense to generalize this to being  
>> metadata for all non-uniqued values (global variables, functions,  
>> basic blocks, arguments), but I'm just keeping it simple for now."
>
> I missed that part.
>
>> However, constant exprs are uniqued.  What would you find it useful  
>> for?
>
> We have inbounds on ConstantExprs today, for example.

... and it was an interesting source of problems.  Do you think that  
inbounds on constantexprs is really a good idea?  It means that we can  
get into a world where we have:  "gep p, 0, 1" and "gep inbounds p, 0,  
1" not be uniqued.

The impact of this is somewhat reduced by libanalysis and vmcore  
trying to infer inbounds etc.  Instead of putting inbounds on the  
constantexpr, why not make that "inference" be a predicate that any  
client could ask of the constantexpr?

-Chris

From jyasskin at google.com  Fri Sep 11 19:15:56 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Fri, 11 Sep 2009 17:15:56 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <200909111723.59396.dag@cray.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<bb55930e0909111320w6e8c18b2qdc652fa72be2058c@mail.gmail.com>
	<200909111723.59396.dag@cray.com>
Message-ID: <bb55930e0909111715t41f12f6cq86dbe14b7923b580@mail.gmail.com>

On Fri, Sep 11, 2009 at 3:23 PM, David Greene <dag at cray.com> wrote:
> On Friday 11 September 2009 15:20, Jeffrey Yasskin wrote:
>> StaticTypeId is a new class that maps each of its template arguments
>> to a small, unique integer, which may be different in different
>> executions.
>
> How does this work across compilation units? ?How about with shared LLVM
> libraries? ?These kinds of global unique IDs are notoriously difficult
> to get right. ?I'd suggest using a third-party unique-id library. ?Boost.UUID
> is one possibility but not the only one.

template<typename T>
class StaticTypeId {
  static int id;
}
extern int NextStaticTypeId;  // Initialized to 0. Possibly an atomic
type instead.
template<typename T> int StaticTypeId<T>::id = NextStaticTypeId++;

This relies on the compiler uniquing static member variables across
translation units, and I've never tested that across shared library
boundaries.  The initializer didn't work with gcc-2 (there was a
workaround), but I believe it works with gcc-4. I've never tested it
with MSVC. We can also use static local variables, which would have a
different set of bugs, but they're very slightly slower to access.

Since there's a registration step, we could also use Pass-style IDs,
and have the registration fill them in, which would avoid uniquing
problems.


From clattner at apple.com  Fri Sep 11 19:22:51 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 11 Sep 2009 17:22:51 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <200909111723.59396.dag@cray.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<bb55930e0909111320w6e8c18b2qdc652fa72be2058c@mail.gmail.com>
	<200909111723.59396.dag@cray.com>
Message-ID: <A72AF6DB-7ECA-49B9-B687-6944D0B8E5DA@apple.com>

On Sep 11, 2009, at 3:23 PM, David Greene wrote:
> I have a few questions and comments about Chris' initial proposal as  
> well.
>
> - I don't like the separation between "built-in" metadata and  
> "extended"
>  metadata.  Why not make all metadata use the RegisterMDKind  
> interface and
>  just have the LLVM libraries do it automatically for the "built-in"  
> stuff?
>  Having a separate namespace of enums is going to get confusing.   
> Practically
>  every day I curse the fact that "int" is different than "MyInt" in C 
> ++.  :-/

"builtin" metadata would also be registered, the only magic would be  
that the encoding would be smaller in the IR.

> - Defaulting alignment to 1 when metatadata is not present is going  
> to be a
>  huge performance hit on many architectures.  I hope we can find a  
> better
>  solution.  I'm not sure what it is yet because we have to maintain  
> safety.
>  I just fear a Pass inadvertantly dropping metadata and really  
> screwing
>  things up.

I don't expect metadata to be commonly stripped.  This could be just  
as bad a perf problem for other things like TBAA or high level type  
information for a dynamic language.  I think it is important that the  
IR is possible to reason about even in uncommon cases though.

-Chris

From dag at cray.com  Fri Sep 11 19:54:31 2009
From: dag at cray.com (David Greene)
Date: Fri, 11 Sep 2009 19:54:31 -0500
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <A72AF6DB-7ECA-49B9-B687-6944D0B8E5DA@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<200909111723.59396.dag@cray.com>
	<A72AF6DB-7ECA-49B9-B687-6944D0B8E5DA@apple.com>
Message-ID: <200909111954.32555.dag@cray.com>

On Friday 11 September 2009 19:22, Chris Lattner wrote:

> > - I don't like the separation between "built-in" metadata and
> > "extended"
> >  metadata.  Why not make all metadata use the RegisterMDKind
> > interface and
> >  just have the LLVM libraries do it automatically for the "built-in"
> > stuff?
> >  Having a separate namespace of enums is going to get confusing.
> > Practically
> >  every day I curse the fact that "int" is different than "MyInt" in C
> > ++.  :-/
>
> "builtin" metadata would also be registered, the only magic would be
> that the encoding would be smaller in the IR.

Except the API is different.  Built-in types use a well-known enum
value not available to extended metadata.  I have no problem with a
smaller IR encoding.  It's the programming interface I'm concerned
about.  I'd rather it be the same for everything.

> I don't expect metadata to be commonly stripped.  This could be just
> as bad a perf problem for other things like TBAA or high level type
> information for a dynamic language.  I think it is important that the
> IR is possible to reason about even in uncommon cases though.

Sure.  Just something we need to be aware of.

                               -Dave

From dag at cray.com  Fri Sep 11 19:57:59 2009
From: dag at cray.com (David Greene)
Date: Fri, 11 Sep 2009 19:57:59 -0500
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <bb55930e0909111715t41f12f6cq86dbe14b7923b580@mail.gmail.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<200909111723.59396.dag@cray.com>
	<bb55930e0909111715t41f12f6cq86dbe14b7923b580@mail.gmail.com>
Message-ID: <200909111957.59579.dag@cray.com>

On Friday 11 September 2009 19:15, Jeffrey Yasskin wrote:

> This relies on the compiler uniquing static member variables across
> translation units, and I've never tested that across shared library
> boundaries.  The initializer didn't work with gcc-2 (there was a
> workaround), but I believe it works with gcc-4. I've never tested it
> with MSVC. We can also use static local variables, which would have a
> different set of bugs, but they're very slightly slower to access.

Shared libraries are the big problem.  I know the Boost guys had endless 
discussions about how to design a Singleton to work in the presence of shared 
libraries and this is pretty close to the same problem.

> Since there's a registration step, we could also use Pass-style IDs,
> and have the registration fill them in, which would avoid uniquing
> problems.

Yes, I think that should work.  Doing things with static initializer magic is 
asking for trouble.

                                 -Dave

From nicholas at mxc.ca  Fri Sep 11 21:17:44 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Fri, 11 Sep 2009 19:17:44 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
Message-ID: <4AAB04C8.80807@mxc.ca>

Dan Gohman wrote:
> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote:
> 
> 
>> Devang's work on debug info prompted this, thoughts welcome:
>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
> 
> The document mentions "instructions" a lot. We'll want to be able to
> apply metadata to ConstantExprs as well at least, if not also Arguments
> (think noalias) and other stuff, so it seems best to just talk about
> "values" instead, and DenseMap<Value *, ...> instead of
> DenseMap<Instruction *, ...>.

I'm wondering that too. Can we replace LLVM function attributes with 
metadata? There's been some pushback to adding new function attributes 
in the past and it would be nice to be able to prototype new ones 
without having to change all of the vm core.

Nick

From bobbypowers at gmail.com  Fri Sep 11 22:24:17 2009
From: bobbypowers at gmail.com (Bobby Powers)
Date: Sat, 12 Sep 2009 03:24:17 +0000
Subject: [LLVMdev] [PATCH] Linux support for compiler-rt's BlocksRuntime
Message-ID: <23e2e54b0909112024l60d08531i68c0f365889ac92@mail.gmail.com>

Hi Folks,

The attached patches gets the Blocks runtime built and installed on my
Linux system.  Let me know if the patches are okay as is, or what I
need to do to get them merged into compiler-rt.  Thanks!

yours,
Bobby Powers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-define-OSAtomicCompareAndSwap-Long-Int-for-non-Mac-W.patch
Type: text/x-patch
Size: 1750 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090912/d4a65f0e/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Don-t-include-Apple-header-files-if-we-re-on-Linux.patch
Type: text/x-patch
Size: 1113 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090912/d4a65f0e/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Enable-make-install-in-cmake-for-Blocks-runtime.patch
Type: text/x-patch
Size: 802 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090912/d4a65f0e/attachment-0002.bin 

From clattner at apple.com  Fri Sep 11 22:33:07 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 11 Sep 2009 20:33:07 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <4AAB04C8.80807@mxc.ca>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
	<4AAB04C8.80807@mxc.ca>
Message-ID: <4D25ADCF-75BE-44CF-A0E6-A89A0B619B82@apple.com>


On Sep 11, 2009, at 7:17 PM, Nick Lewycky wrote:

> Dan Gohman wrote:
>> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote:
>>> Devang's work on debug info prompted this, thoughts welcome:
>>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
>> The document mentions "instructions" a lot. We'll want to be able to
>> apply metadata to ConstantExprs as well at least, if not also  
>> Arguments
>> (think noalias) and other stuff, so it seems best to just talk about
>> "values" instead, and DenseMap<Value *, ...> instead of
>> DenseMap<Instruction *, ...>.
>
> I'm wondering that too. Can we replace LLVM function attributes with  
> metadata? There's been some pushback to adding new function  
> attributes in the past and it would be nice to be able to prototype  
> new ones without having to change all of the vm core.

The pushback has been about adding lots of weird and special purpose  
extensions, not the encoding.

-Chris

From nicholas at mxc.ca  Fri Sep 11 23:00:39 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Fri, 11 Sep 2009 21:00:39 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <4D25ADCF-75BE-44CF-A0E6-A89A0B619B82@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
	<4AAB04C8.80807@mxc.ca>
	<4D25ADCF-75BE-44CF-A0E6-A89A0B619B82@apple.com>
Message-ID: <4AAB1CE7.6090802@mxc.ca>

Chris Lattner wrote:
> 
> On Sep 11, 2009, at 7:17 PM, Nick Lewycky wrote:
> 
>> Dan Gohman wrote:
>>> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote:
>>>> Devang's work on debug info prompted this, thoughts welcome:
>>>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
>>> The document mentions "instructions" a lot. We'll want to be able to
>>> apply metadata to ConstantExprs as well at least, if not also Arguments
>>> (think noalias) and other stuff, so it seems best to just talk about
>>> "values" instead, and DenseMap<Value *, ...> instead of
>>> DenseMap<Instruction *, ...>.
>>
>> I'm wondering that too. Can we replace LLVM function attributes with 
>> metadata? There's been some pushback to adding new function attributes 
>> in the past and it would be nice to be able to prototype new ones 
>> without having to change all of the vm core.
> 
> The pushback has been about adding lots of weird and special purpose 
> extensions, not the encoding.

The bar is higher for getting something into the vm core, as it should 
be. It sounds like we're planning to permit special purpose metadata 
which is why I asked.

If nothing else, it would be more convenient to prototype new extensions 
to find out what they're really worth.

Nick


From rengolin at systemcall.org  Sat Sep 12 03:39:06 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Sat, 12 Sep 2009 09:39:06 +0100
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <4AAB04C8.80807@mxc.ca>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
	<4AAB04C8.80807@mxc.ca>
Message-ID: <d9b9d95f0909120139k6a7405a5j5229fe3339891c54@mail.gmail.com>

2009/9/12 Nick Lewycky <nicholas at mxc.ca>:
> I'm wondering that too. Can we replace LLVM function attributes with
> metadata? There's been some pushback to adding new function attributes
> in the past and it would be nice to be able to prototype new ones
> without having to change all of the vm core.

I just wonder how stable that would become as time passes by.

It is true that enabling the addition of metadata as part of the
structure is good for specialized optimizations that are not
represented internally (or relevant) in the LLVM core, but there is a
practical limit on what you can do.

My (humble) opinion is that basic language structure, such as function
attributes, should still be part of the core. And if there isn't
always easy ways of getting them and passing them through we should
make it easier... in the core.

Metadata is a completely different beast. It's good for things that
only your own optimization pass or machine code will understand. It's
an additional rather than required information, which the lack of
would be completely harmless.

I completely agree with the text argument that the demand (and
necessity) for metadata is increasing, but that doesn't mean we should
transform everything into it.

The RDF [1] developments sent a clear message that metadata per se are
too loose to hold value. We need a fixed, basic structure on where to
stick metadata, otherwise it'd just be a big slimy blob of untreatable
data.

My two cents...

cheers,
--renato

[1] http://www.w3.org/RDF/


Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From rengolin at systemcall.org  Sat Sep 12 03:54:32 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Sat, 12 Sep 2009 09:54:32 +0100
Subject: [LLVMdev] IDE on *nix
Message-ID: <d9b9d95f0909120154m217217c2g908a42be2c3e42cb@mail.gmail.com>

Hi all,

Is anyone using any flavour of Unix to develop LLVM? I suppose the
Apple guys are using Mac, right? ;)

I've seen some docs on the website to set-up Visual Studio but I
haven't seen anything related to cross-platform IDEs (such as Eclipse)
and how to attach the tests to them.

So far I'm not doing any modifications to the LLVM and my project is
still too small to become a memory black-hole on Eclipse, but putting
LLVM itself on it was a bit harsh.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From choudharydhruv at gmail.com  Sat Sep 12 07:19:36 2009
From: choudharydhruv at gmail.com (dhruv choudhary)
Date: Sat, 12 Sep 2009 08:19:36 -0400
Subject: [LLVMdev] Cache optimizations and data layout
Message-ID: <aceb74670909120519h5aa0ab0fl6aac09a0ff3607fd@mail.gmail.com>

Hello,

I am new to LLVM. I am using an x86 code generator. I need to write a few
passes based on cache blocks and data layout information. Does LLVM provide
a way for me to see the data layout and analyze what are the cache blocks?
If not is it possible to implement the same in the current framework?

Thank You

Dhruv Choudhary

-- 
School of Electrical and Computer Engineering
Georgia Institute of Technology
(M)  +1 770 827 9264

Personal Email : choudharydhruv at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090912/ca5d6966/attachment.html 

From bobbypowers at gmail.com  Sat Sep 12 11:04:42 2009
From: bobbypowers at gmail.com (Bobby Powers)
Date: Sat, 12 Sep 2009 16:04:42 +0000
Subject: [LLVMdev] [PATCH] Linux support for compiler-rt's BlocksRuntime
In-Reply-To: <23e2e54b0909112024l60d08531i68c0f365889ac92@mail.gmail.com>
References: <23e2e54b0909112024l60d08531i68c0f365889ac92@mail.gmail.com>
Message-ID: <23e2e54b0909120904r1f259ea0haf71b137111b8819@mail.gmail.com>

I've reattached the patch to runtime.c, this time as output from svn
instead of git.  As the original git commit noted, it does the
following:

define OSAtomicCompareAndSwap(Long|Int) for non-Mac/Win32 systems

if neither TARGET_OS_MAC or TARGET_OS_WINDOWS are defined, check to
see if GCC atomic built-ins are available (and use them if they are).

yours,
Bobby

On Sat, Sep 12, 2009 at 3:24 AM, Bobby Powers <bobbypowers at gmail.com> wrote:
> Hi Folks,
>
> The attached patches gets the Blocks runtime built and installed on my
> Linux system. ?Let me know if the patches are okay as is, or what I
> need to do to get them merged into compiler-rt. ?Thanks!
>
> yours,
> Bobby Powers
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc_atomic_ops.patch
Type: text/x-patch
Size: 1787 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090912/d2ca6907/attachment.bin 

From eocallaghan at auroraux.org  Sat Sep 12 11:30:22 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Sat, 12 Sep 2009 17:30:22 +0100
Subject: [LLVMdev] [PATCH] Linux support for compiler-rt's BlocksRuntime
In-Reply-To: <23e2e54b0909120904r1f259ea0haf71b137111b8819@mail.gmail.com>
References: <23e2e54b0909112024l60d08531i68c0f365889ac92@mail.gmail.com>
	<23e2e54b0909120904r1f259ea0haf71b137111b8819@mail.gmail.com>
Message-ID: <521640720909120930i41399b52geff9d15d8fdb1585@mail.gmail.com>

Applied 81615.

Thank you,
Edward O'Callaghan.

2009/9/12 Bobby Powers <bobbypowers at gmail.com>:
> I've reattached the patch to runtime.c, this time as output from svn
> instead of git. ?As the original git commit noted, it does the
> following:
>
> define OSAtomicCompareAndSwap(Long|Int) for non-Mac/Win32 systems
>
> if neither TARGET_OS_MAC or TARGET_OS_WINDOWS are defined, check to
> see if GCC atomic built-ins are available (and use them if they are).
>
> yours,
> Bobby
>
> On Sat, Sep 12, 2009 at 3:24 AM, Bobby Powers <bobbypowers at gmail.com> wrote:
>> Hi Folks,
>>
>> The attached patches gets the Blocks runtime built and installed on my
>> Linux system. ?Let me know if the patches are okay as is, or what I
>> need to do to get them merged into compiler-rt. ?Thanks!
>>
>> yours,
>> Bobby Powers
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From ofv at wanadoo.es  Sat Sep 12 12:01:21 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Sat, 12 Sep 2009 19:01:21 +0200
Subject: [LLVMdev] Saving/restoring executable code from the the JIT?
Message-ID: <87my50p066.fsf@telefonica.net>

Hi.

IIRC some time ago there was some discussion about saving the executable
code produced by the JIT to a file, for loading it at the next
session. This would require to stream out the executable code before
externals are resolved and resolve them when the code is loaded.

AFAIK, LLVM does not support this at the moment.

What's the difficulty of implementing this feature, on terms of existing
infrastructure etc?

-- 
?scar


From rnk at mit.edu  Sat Sep 12 12:49:01 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Sat, 12 Sep 2009 13:49:01 -0400
Subject: [LLVMdev] Saving/restoring executable code from the the JIT?
In-Reply-To: <87my50p066.fsf@telefonica.net>
References: <87my50p066.fsf@telefonica.net>
Message-ID: <9a9942200909121049q707c0671r1e57466aad6b9c2b@mail.gmail.com>

It's not clear how valuable the feature is if users start to do things
like inlining pointers to heap allocated objects with guards as
optimizations.

I could imagine an IR class representing a pointer to an object on the
heap that gets serialized to bitcode as some kind of relocatable
symbol, and then re-resolved at runtime.  If the corresponding symbol
doesn't exist at runtime, the implementation could choose to drop the
particular function on the floor and recompile from source.

Reid

On Sat, Sep 12, 2009 at 1:01 PM, ?scar Fuentes <ofv at wanadoo.es> wrote:
> Hi.
>
> IIRC some time ago there was some discussion about saving the executable
> code produced by the JIT to a file, for loading it at the next
> session. This would require to stream out the executable code before
> externals are resolved and resolve them when the code is loaded.
>
> AFAIK, LLVM does not support this at the moment.
>
> What's the difficulty of implementing this feature, on terms of existing
> infrastructure etc?
>
> --
> ?scar
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From rengolin at systemcall.org  Sat Sep 12 12:53:55 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Sat, 12 Sep 2009 18:53:55 +0100
Subject: [LLVMdev] Saving/restoring executable code from the the JIT?
In-Reply-To: <87my50p066.fsf@telefonica.net>
References: <87my50p066.fsf@telefonica.net>
Message-ID: <d9b9d95f0909121053t797cf78mdf28362cbca3caea@mail.gmail.com>

2009/9/12 ?scar Fuentes <ofv at wanadoo.es>:
> IIRC some time ago there was some discussion about saving the executable
> code produced by the JIT to a file, for loading it at the next
> session. This would require to stream out the executable code before
> externals are resolved and resolve them when the code is loaded.

That reminds me of network agents... One could send the executable
through the network to execute on remote machines (collecting local
statistics, for instance). Despite all the security and locality
concerns, it's a pretty cool idea.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From rengolin at systemcall.org  Sat Sep 12 14:31:42 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Sat, 12 Sep 2009 20:31:42 +0100
Subject: [LLVMdev] Saving/restoring executable code from the the JIT?
In-Reply-To: <9a9942200909121049q707c0671r1e57466aad6b9c2b@mail.gmail.com>
References: <87my50p066.fsf@telefonica.net>
	<9a9942200909121049q707c0671r1e57466aad6b9c2b@mail.gmail.com>
Message-ID: <d9b9d95f0909121231g327a28abw56dd2925e12b3c0a@mail.gmail.com>

2009/9/12 Reid Kleckner <rnk at mit.edu>:
> It's not clear how valuable the feature is if users start to do things
> like inlining pointers to heap allocated objects with guards as
> optimizations.

or what about register variables, or objects half as registers half in
memory, or optimizations that exists on one machine (presence of FPU,
MMU, etc) and not on others, byte sex, word size and many other
problems... All of this is the job of serialization engine.

I suppose the JIT vm has already many solutions for the cross-platform
compatibility, but there will still be some lost context from one
place/time to another.


> I could imagine an IR class representing a pointer to an object on the
> heap that gets serialized to bitcode as some kind of relocatable
> symbol, and then re-resolved at runtime. ?If the corresponding symbol
> doesn't exist at runtime, the implementation could choose to drop the
> particular function on the floor and recompile from source.

You could loose the program's state with that, which I think is the
whole point. Maybe having a class that saves all values marked with a
specific metadata (all the rest could potentially be reinitialized) as
a globally accessed symbol and re-read (and deleted) at restart.

It's responsibility of the programmer to say what's to be saved and
what can be safely reinitialized. The IRBuilder could annotate during
allocation, so the JIT would know which ones to save on suspend and
keep track where they are.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From clattner at apple.com  Sat Sep 12 14:52:30 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 12 Sep 2009 12:52:30 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <4AAB1CE7.6090802@mxc.ca>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<3A812893-D72C-4C9D-89CD-45AFD512E3A1@apple.com>
	<4AAB04C8.80807@mxc.ca>
	<4D25ADCF-75BE-44CF-A0E6-A89A0B619B82@apple.com>
	<4AAB1CE7.6090802@mxc.ca>
Message-ID: <88D1D6DF-D946-4D48-9E32-5A35500B5018@apple.com>


On Sep 11, 2009, at 9:00 PM, Nick Lewycky wrote:

> Chris Lattner wrote:
>> On Sep 11, 2009, at 7:17 PM, Nick Lewycky wrote:
>>> Dan Gohman wrote:
>>>> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote:
>>>>> Devang's work on debug info prompted this, thoughts welcome:
>>>>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
>>>> The document mentions "instructions" a lot. We'll want to be able  
>>>> to
>>>> apply metadata to ConstantExprs as well at least, if not also  
>>>> Arguments
>>>> (think noalias) and other stuff, so it seems best to just talk  
>>>> about
>>>> "values" instead, and DenseMap<Value *, ...> instead of
>>>> DenseMap<Instruction *, ...>.
>>>
>>> I'm wondering that too. Can we replace LLVM function attributes  
>>> with metadata? There's been some pushback to adding new function  
>>> attributes in the past and it would be nice to be able to  
>>> prototype new ones without having to change all of the vm core.
>> The pushback has been about adding lots of weird and special  
>> purpose extensions, not the encoding.
>
> The bar is higher for getting something into the vm core, as it  
> should be. It sounds like we're planning to permit special purpose  
> metadata which is why I asked.
>
> If nothing else, it would be more convenient to prototype new  
> extensions to find out what they're really worth.

Yep, I completely agree!

-Chris

From ofv at wanadoo.es  Sat Sep 12 16:47:41 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Sat, 12 Sep 2009 23:47:41 +0200
Subject: [LLVMdev] Saving/restoring executable code from the the JIT?
References: <87my50p066.fsf@telefonica.net>
	<9a9942200909121049q707c0671r1e57466aad6b9c2b@mail.gmail.com>
	<d9b9d95f0909121231g327a28abw56dd2925e12b3c0a@mail.gmail.com>
Message-ID: <87hbv7q1he.fsf@telefonica.net>

Renato Golin <rengolin at systemcall.org> writes:

> or what about register variables, or objects half as registers half in
> memory, or optimizations that exists on one machine (presence of FPU,
> MMU, etc) and not on others, byte sex, word size and many other
> problems... All of this is the job of serialization engine.

[snip]

My goal is to avoid waiting several minutes on application startup until
optimization and native codegen ends. No suspending/restarting, just
compiling, saving native generated code, and loading on future sessions,
more akin a conventional compiler.

Generating a dll is not an option because:

 1. It will require distributing a linker.

 2. It will require the presence of an import library satisfying the
 external symbols referenced by the dll, and some of those symbols are
 unknown until the application starts (this may not apply to unixes, but
 it does for windows). Essentially, LLVM would have to do the linker's
 work when the previously saved native code is loaded back by the
 application on the next session.

 3. Some other reasons I forgot when studied the idea on the past.

-- 
?scar


From sanjiv.gupta at microchip.com  Sun Sep 13 02:14:36 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Sun, 13 Sep 2009 12:44:36 +0530
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <3cb898890909110510m596e110do1156512055e36f67@mail.gmail.com>
References: <4AA2B20B.1030903@microchip.com>	
	<3cb898890909061107h1e82b646qd14871371bcca2cf@mail.gmail.com>	
	<3cb898890909061113j278cd94cr343d34dc26c970d@mail.gmail.com>	
	<3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>	
	<4AA8793F.8080503@microchip.com> <4AA88DEB.3090700@microchip.com>	
	<3cb898890909100524h7e3658eer24572747d626b47b@mail.gmail.com>	
	<4AA93EEB.7060002@microchip.com>	
	<3cb898890909101110x3b248a39g9a195507f445a390@mail.gmail.com>	
	<4AAA1C59.2010404@microchip.com>
	<3cb898890909110510m596e110do1156512055e36f67@mail.gmail.com>
Message-ID: <4AAC9BDC.2080900@microchip.com>

Mikhail Glushenkov wrote:
> Hi,
>
> On Fri, Sep 11, 2009 at 11:46 AM, Sanjiv Gupta
> <sanjiv.gupta at microchip.com> wrote:
>   
>> Looks good.
>> One more quick query.
>> How to extract  libname from "-l std" from the driver and pass it as
>> "std.lib" to the linker tool?
>> I know that unpack_values will give me "std", but an (append_cmd ".lib")
>> with that will insert a space.
>>     
>
> This won't work since actions are not composable (alas).
>
>   
>> Anything like append_cmd_nospace ? or any other way?
>>     
>
> I'm afraid there is no way to do this right now. One way to support
> this is to extend the hook mechanism to work with actions:
>
> (case (not_empty "-l"), (append_cmd "$CALL(AppendLibSuffix)"))
>
>   
Thanks for thinking over it.
On second thoughts, I feel that it isn't right to ask for a feature for 
every such thing. The right way to do this is to fix one's linker itself 
so that it accepts a -l option as such forwarded by the driver.

- Sanjiv


From rengolin at systemcall.org  Sun Sep 13 05:23:27 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Sun, 13 Sep 2009 11:23:27 +0100
Subject: [LLVMdev] Saving/restoring executable code from the the JIT?
In-Reply-To: <87hbv7q1he.fsf@telefonica.net>
References: <87my50p066.fsf@telefonica.net>
	<9a9942200909121049q707c0671r1e57466aad6b9c2b@mail.gmail.com>
	<d9b9d95f0909121231g327a28abw56dd2925e12b3c0a@mail.gmail.com>
	<87hbv7q1he.fsf@telefonica.net>
Message-ID: <d9b9d95f0909130323m27b24c51w30153a5886bdb99d@mail.gmail.com>

2009/9/12 ?scar Fuentes <ofv at wanadoo.es>:
> My goal is to avoid waiting several minutes on application startup until
> optimization and native codegen ends. No suspending/restarting, just
> compiling, saving native generated code, and loading on future sessions,
> more akin a conventional compiler.

Saving IR shouldn't be any problem, I guess there is already a way of
doing this, and re-reading it by the JIT again.


> ?2. It will require the presence of an import library satisfying the
> ?external symbols referenced by the dll, and some of those symbols are
> ?unknown until the application starts (this may not apply to unixes, but
> ?it does for windows). Essentially, LLVM would have to do the linker's
> ?work when the previously saved native code is loaded back by the
> ?application on the next session.

No sense when you're just running on the VM. More hassle than savings.
The JVM is a good example on how things go bad when you're linking
native code.


cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From luoyonggang at gmail.com  Sun Sep 13 06:06:12 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Sun, 13 Sep 2009 19:06:12 +0800
Subject: [LLVMdev] Is it possible using anonymous namespace on template in
	header files.
Message-ID: <806065d90909130406l4db007aex58c48751447fe826@mail.gmail.com>

for example
  /// getPointerUnionTypeNum - If the argument has type PT1* or PT2* return
  /// false or true respectively.
  template <typename PT1, typename PT2>
  static inline int getPointerUnionTypeNum(PT1 *P) { return 0; }
  template <typename PT1, typename PT2>
  static inline int getPointerUnionTypeNum(PT2 *P) { return 1; }
  template <typename PT1, typename PT2>
  static inline int getPointerUnionTypeNum(...) { return -1; }

it's a peace of code comes from PointerUnion.h

can it change to be
namespace{
  template <typename PT1, typename PT2>
  inline int getPointerUnionTypeNum(PT1 *P) { return 0; }
  template <typename PT1, typename PT2>
  inline int getPointerUnionTypeNum(PT2 *P) { return 1; }
  template <typename PT1, typename PT2>
  inline int getPointerUnionTypeNum(...) { return -1; }
}




-- 
         ??
?
???
Yours
    sincerely,
Yonggang Luo


From sherief at mganin.com  Sun Sep 13 06:39:21 2009
From: sherief at mganin.com (Sherief N. Farouk)
Date: Sun, 13 Sep 2009 07:39:21 -0400
Subject: [LLVMdev] Saving/restoring executable code from the the JIT?
Message-ID: <000c01ca3466$d62b9750$8282c5f0$@com>

> My goal is to avoid waiting several minutes on application startup
> until
> optimization and native codegen ends. No suspending/restarting, just
> compiling, saving native generated code, and loading on future sessions,
> more akin a conventional compiler.
> 

I'm interested in something like that. I have a case (which seems similar to
one experienced by Nick Capens) where I have a lot of pure functions
(Functions that only reference first-level indirections of their input
parameters, a-la declspec(noalias) in VC++) that I'd like to store and avoid
re-generating. There were some issues with constants being pooled by the
execution engine iirc, but if there're plans to implement what Oscar's
thinking of I'd love to be in on it.

- Sherief


From sebastian.redl at getdesigned.at  Sun Sep 13 08:19:01 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Sun, 13 Sep 2009 15:19:01 +0200
Subject: [LLVMdev] Is it possible using anonymous namespace on template
 in	header files.
In-Reply-To: <806065d90909130406l4db007aex58c48751447fe826@mail.gmail.com>
References: <806065d90909130406l4db007aex58c48751447fe826@mail.gmail.com>
Message-ID: <4AACF145.8010706@getdesigned.at>

???(Yonggang Luo) wrote:
> for example
>   /// getPointerUnionTypeNum - If the argument has type PT1* or PT2* return
>   /// false or true respectively.
>   template <typename PT1, typename PT2>
>   static inline int getPointerUnionTypeNum(PT1 *P) { return 0; }
>   template <typename PT1, typename PT2>
>   static inline int getPointerUnionTypeNum(PT2 *P) { return 1; }
>   template <typename PT1, typename PT2>
>   static inline int getPointerUnionTypeNum(...) { return -1; }
>
> it's a peace of code comes from PointerUnion.h
>
> can it change to be
> namespace{
>   template <typename PT1, typename PT2>
>   inline int getPointerUnionTypeNum(PT1 *P) { return 0; }
>   template <typename PT1, typename PT2>
>   inline int getPointerUnionTypeNum(PT2 *P) { return 1; }
>   template <typename PT1, typename PT2>
>   inline int getPointerUnionTypeNum(...) { return -1; }
> }
>   
Using the anonymous namespace in a header file is generally a very bad
idea. The problem is that it is a different namespace in every
translation unit. This can lead to subtle errors or simply undesirable
behavior.

Why would you want these functions in the AN anyway?

Sebastian

From luoyonggang at gmail.com  Sun Sep 13 09:35:57 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Sun, 13 Sep 2009 22:35:57 +0800
Subject: [LLVMdev] I am suspicious on the setting of _WIN32_WINNT
Message-ID: <806065d90909130735t5c0c5ef0lf8eea58fa621ea7e@mail.gmail.com>

That's because when I am using Mingw to compile llvm.
It's report can't find the API

DWORD WINAPI GetProcessId(
  __in  HANDLE Process
);

In Mingw it's defined as
#if (_WIN32_WINNT >= 0x0501)
WINBASEAPI DWORD WINAPI GetProcessId(HANDLE);
#endif

but IN Wnidows SDK, there is nothing around GetProcessId.


But from MSDN
GetProcessId Function

Retrieves the process identifier of the specified process.


Syntax
DWORD WINAPI GetProcessId(
  __in  HANDLE Process
);

Parameters
Process
A handle to the process. The handle must have the
PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION access
right.

Return Value

If the function succeeds, the return value is the process identifier
of the specified process.




If the function fails, the return value is zero. To get extended error
information, call GetLastError.



Remarks
Until a process terminates, its process identifier uniquely identifies
it on the system. For more information about access rights, see
Process Security and Access Rights.

Requirements
Client Requires Windows Vista or Windows XP SP1.
Server Requires Windows Server 2008 or Windows Server 2003.
Header Declared in Winbase.h; include Windows.h.

Library Use Kernel32.lib.

DLL Requires Kernel32.dll.


That's means the minimal requirement is Windows XP sp1.

So, maybe we need to increment the
_WIN32_WINNT
in file Win32.h
recommended changed to be 0x0501

-- 
         ??
?
???
Yours
    sincerely,
Yonggang Luo


From clattner at apple.com  Sun Sep 13 13:17:55 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 13 Sep 2009 11:17:55 -0700
Subject: [LLVMdev] PIC16 question
Message-ID: <B2F67650-6666-471E-AFE3-84C83D285C46@apple.com>

In my ongoing work on refactoring the asmprinters, I've found that  
PIC16 doesn't put ':' after labels in some cases.  Specifically, it  
looks like basic block labels are emitted without a ':':

	movwf @__floatunsidf.frame. + 2
	movlp .BB1_2
	goto .BB1_2
.BB1_2                                                      ; %bb7
	movlw 0
	banksel @__floatunsidf.frame.

but that functions and global variables are.  Does lack of a colon  
mean that the label is private to the file? Is a colon on the basic  
block harmful (IOW, can I just emit basic block labels with a colon  
even though they aren't currently)?

-Chris

From foldr at codedgers.com  Sun Sep 13 14:41:58 2009
From: foldr at codedgers.com (Mikhail Glushenkov)
Date: Sun, 13 Sep 2009 19:41:58 +0000 (UTC)
Subject: [LLVMdev]
	=?utf-8?q?I_am_suspicious_on_the_setting_of_=5FWIN32=5F?=
	=?utf-8?q?WINNT?=
References: <806065d90909130735t5c0c5ef0lf8eea58fa621ea7e@mail.gmail.com>
Message-ID: <loom.20090913T212718-344@post.gmane.org>

Hi,

???(Yonggang Luo)  <luoyonggang <at> gmail.com> writes:

> 
> That's because when I am using Mingw to compile llvm.
> It's report can't find the API

This is a known issue, and will be fixed Real Soon Now.


From sanjiv.gupta at microchip.com  Sun Sep 13 21:53:57 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 14 Sep 2009 08:23:57 +0530
Subject: [LLVMdev] PIC16 question
In-Reply-To: <B2F67650-6666-471E-AFE3-84C83D285C46@apple.com>
References: <B2F67650-6666-471E-AFE3-84C83D285C46@apple.com>
Message-ID: <4AADB045.6060302@microchip.com>

Chris Lattner wrote:
> In my ongoing work on refactoring the asmprinters, I've found that  
> PIC16 doesn't put ':' after labels in some cases.  Specifically, it  
> looks like basic block labels are emitted without a ':':
>
> 	movwf @__floatunsidf.frame. + 2
> 	movlp .BB1_2
> 	goto .BB1_2
> .BB1_2                                                      ; %bb7
> 	movlw 0
> 	banksel @__floatunsidf.frame.
>
> but that functions and global variables are.  Does lack of a colon  
> mean that the label is private to the file? Is a colon on the basic  
> block harmful

>  (IOW, can I just emit basic block labels with a colon  
> even though they aren't currently)?
>   
Yes.
A ':' does not make any difference to pic16 labels.
They are optional.
 
- Sanjiv

From clattner at apple.com  Sun Sep 13 22:14:17 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 13 Sep 2009 20:14:17 -0700
Subject: [LLVMdev] PIC16 question
In-Reply-To: <4AADB045.6060302@microchip.com>
References: <B2F67650-6666-471E-AFE3-84C83D285C46@apple.com>
	<4AADB045.6060302@microchip.com>
Message-ID: <8F3D9A79-10C0-4DC6-8C24-C9342A315D6F@apple.com>


On Sep 13, 2009, at 7:53 PM, Sanjiv Gupta wrote:

> Chris Lattner wrote:
>> In my ongoing work on refactoring the asmprinters, I've found that   
>> PIC16 doesn't put ':' after labels in some cases.  Specifically,  
>> it  looks like basic block labels are emitted without a ':':
>>
>> 	movwf @__floatunsidf.frame. + 2
>> 	movlp .BB1_2
>> 	goto .BB1_2
>> .BB1_2                                                      ; %bb7
>> 	movlw 0
>> 	banksel @__floatunsidf.frame.
>>
>> but that functions and global variables are.  Does lack of a colon   
>> mean that the label is private to the file? Is a colon on the  
>> basic  block harmful
>
>> (IOW, can I just emit basic block labels with a colon  even though  
>> they aren't currently)?
>>
> Yes.
> A ':' does not make any difference to pic16 labels.
> They are optional.

Great, thanks Sanjiv!

-Chris

From isanbard at gmail.com  Sun Sep 13 22:49:32 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Sun, 13 Sep 2009 20:49:32 -0700
Subject: [LLVMdev] Exception Handling Tables Question
Message-ID: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>

I have a question concerning the exception handling tables that we  
generate.

Right now we generate call sites for all of the code in a function,  
even for code that cannot (or at least shouldn't) throw an exception.  
E.g., for this code:

#include <cstdio>

struct Cleanup {
    ~Cleanup(void) {
      printf("in cleanup\n");
    }
};

static void inline_me(void) {
    Cleanup C;
    throw 0;
}

int main(void) {
    try {
      inline_me();
    } catch (...) {
      printf("in catch all\n");
    }
    return 0;
}

(assume it's all been inlined), the EH handling table for "main" goes  
from Leh_func_begin1 to Leh_func_end1, marking off each region whether  
it can throw or not. From my reading of the Exception Tables  
documentation, this is unnecessary ? at least for C++. If a call  
throws and it doesn't have an entry in the unwind table, then the  
"terminate()" function is called. Is it fair to assume that there is a  
similar mechanism for other languages? The reason to ask this is that  
it could make the EH tables smaller and less cluttered if we elide  
those areas which we know don't throw (the functions called are marked  
'nounwind', etc.).

-bw



From wansheg at gmail.com  Mon Sep 14 02:19:47 2009
From: wansheg at gmail.com (wan sheg)
Date: Mon, 14 Sep 2009 15:19:47 +0800
Subject: [LLVMdev] Is LLVM backend is suitable for developing VLIW target
	machine ?
Message-ID: <99affacc0909140019u1f83dfedo759c15a79adcad05@mail.gmail.com>

 Is there some description module  that  support for pipeline usage
exposing  character ?

Some DSP has  clustered  architecture ,   Is LLVM  fitted for the
clustered-architecture ?

From linus_wind at zju.edu.cn  Mon Sep 14 02:25:24 2009
From: linus_wind at zju.edu.cn (Wenzhi Tao)
Date: Mon, 14 Sep 2009 15:25:24 +0800
Subject: [LLVMdev] How to split module?
Message-ID: <452911084.20899@zju.edu.cn>

Hi, all.

My question is about how to split one module into N modules(N >= 2)?
For example, given the following code:

#src.c#
int main()
{
    //......//
    func1();
    func2();
    //......//
    return 0;
}
void func1()
{
    //......//
}
void func2()
{
    //......//
}

func1() has no dependence with func2(), so they can perform parallel 
execution. And I have to split src.c into src1.c and src2.c instead of using 
thread library, because the target machine has multiple RISC processors 
without Operating System,

#src1.c#
int main()
{
    //......//
    // synchronization
    func1();
    // synchronization
    //......//
    return 0;
}
void func1()
{
    //......//
}

#src2.c#
int main()
{
    //......//
    // synchronization
    func2();
    // synchronization
    //......//
    return 0;
}
void func2()
{
    //......//
}

Well, Assume the synchronization statements has been added, how to perform the 
splitting on the orginal module wiht the guarantee of correctness. Thanks you!

From mikael.lepisto at tut.fi  Mon Sep 14 02:39:05 2009
From: mikael.lepisto at tut.fi (=?ISO-8859-1?Q?Mikael_Lepist=F6?=)
Date: Mon, 14 Sep 2009 10:39:05 +0300
Subject: [LLVMdev] Fwd: [llvm-commits] [PATCH] Building llvm-gcc with
	llvm-2.5 debian packages
References: <DACC02ED-6BF3-4BA1-83FD-A434EE28B2CA@tut.fi>
Message-ID: <B421EFAA-C664-4760-957E-8E04D70BDEA8@tut.fi>

Hi,

Anybody has an opinion would it be good thing  to add support for llvm- 
gcc to be able to be built with existing llvm installation?

Right now building works with llvm installation also, but only if llvm  
libs and includes are installed under the same prefix, even though  
this seems to be unintended functionality.

So after support for building llvm-gcc without llvm sources it would  
be possible to build e.g. llvm-gcc cross compilers with globally  
installed llvm package.

Mikael Lepist?

Begin forwarded message:

> From: Mikael Lepist? <mikael.lepisto at tut.fi>
> Date: 5. syyskuuta 2009 klo 20.16.48
> To: Commit Messages and Patches for LLVM <llvm-commits at cs.uiuc.edu>
> Subject: Re: [llvm-commits] [PATCH] Building llvm-gcc with llvm-2.5  
> debian packages
>
> I forgot reply to all setting so here is the mail to list also...
>
>>
>> Hi Mikael,
>>
>>> Patch fixes the problem in a way that it asks with llvm-config -- 
>>> includedir where include files really should be found.
>>
>> I don't get it.  The llvm-gcc build should not be used the installed
>> llvm at all - you shouldn't need to install llvm in order to build
>> llvm-gcc, only build it.
>
> It's not obligatory to install llvm to be able to compile llvm-gcc.  
> Still it's perfectly possible to compile llvm-gcc towards llvm  
> installation, if you don't want to compile your llvm from sources.  
> I.e. it is possible to compile llvm gcc with installed llvm or with  
> an llvm source tree, where llvm has been built.
>
> However if it is not even intended behavior that llvm-gcc is may be  
> compiled with llvm installation tree then the patch is obsolete.
>
>> So asking llvm-config where it was installed
>> is just wrong.
>
> If llvm-config is ran from llvm-source-tree/Release/bin the -- 
> includedir switch actually returns include directory of the source  
> tree, so basically we are not asking for installed headers, but just  
> any place where includes should be looked for.
>
> e.g. on my work computer i got following results for running lvm- 
> config in source dirctory
>
> elhigu at mr-lenovo:~/stow_sources/llvm-svn$ Debug/bin/llvm-config -- 
> includedir
> /home/elhigu/stow_sources/llvm-svn/include
>
> and from install directory.
>
> elhigu at mr-lenovo:~/stow_sources/llvm-svn$ ~/stow_installs/bin/llvm- 
> config --includedir
> /home/elhigu/stow_installs/include
>
>>  It sounds like the real problem is that LLVMOBJDIR and
>> LLVMSRCDIR are pointing to the wrong places.  What did you pass to
>> --enable-llvm when you configured llvm-gcc?
>
> When I compile llvm-gcc with llvm installation without llvm sources  
> I pass 'llvm-config --prefix' for --enable-llvm when I build llvm- 
> gcc towards llvm source tree I pass 'llvm-config --src-root'.
>
> -Mikael
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

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

From gausszhch at gmail.com  Mon Sep 14 03:32:29 2009
From: gausszhch at gmail.com (gauss)
Date: Mon, 14 Sep 2009 16:32:29 +0800
Subject: [LLVMdev] Can we use llvm-gcc to compile large project and generate
	IR?
Message-ID: <834cd97f0909140132u8fcdf82uf1238202310ee851@mail.gmail.com>

Hi, all.
I have written a pass to do some inter-procedure work.  Then I tried to
apply it to currently existing software.  But I failed to compile most of
them using llvm-gcc.

When I run   * ./configure CC=llvm-gcc CFLAGS="-emit-llvm -c"*,    it
reports "*cannot run C compiled programs*" and so on and then exit.
( I use CFLAGS="-emit-llvm -c" to produce LLVM bitcode so that my pass can
run on it. )

My solution is using the default CC and CFLAGS to *configure*, and before we
*make*, I write a shell script to replace the default gcc. This script will
invoke *llvm-gcc* later and pass arguments "*-emit-llvm -c*" to the
compiler.

However, there still exists many errors when I *make*, many of them are very
strange.

What's wrong here? It confused me a few days.  Can we use llvm-gcc to
compile large project and generate IR?  How?

Thanks!


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

From stefano.delliponti at gmail.com  Mon Sep 14 05:20:03 2009
From: stefano.delliponti at gmail.com (Stefano Delli Ponti)
Date: Mon, 14 Sep 2009 12:20:03 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
Message-ID: <h8l5cj$tqd$1@ger.gmane.org>

http://www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=1

Regards,
Stefano


From andrewl at lenharth.org  Mon Sep 14 09:17:15 2009
From: andrewl at lenharth.org (Andrew Lenharth)
Date: Mon, 14 Sep 2009 09:17:15 -0500
Subject: [LLVMdev] Can we use llvm-gcc to compile large project and
	generate IR?
In-Reply-To: <834cd97f0909140132u8fcdf82uf1238202310ee851@mail.gmail.com>
References: <834cd97f0909140132u8fcdf82uf1238202310ee851@mail.gmail.com>
Message-ID: <85dfcd7f0909140717ha90a022w76d1b5ae2359bf73@mail.gmail.com>

On Mon, Sep 14, 2009 at 3:32 AM, gauss <gausszhch at gmail.com> wrote:
> Hi, all.
> I have written a pass to do some inter-procedure work.? Then I tried to
> apply it to currently existing software.? But I failed to compile most of
> them using llvm-gcc.
>
> When I run??? ./configure CC=llvm-gcc CFLAGS="-emit-llvm -c",? ? it reports
> "cannot run C compiled programs" and so on and then exit.
> ( I use CFLAGS="-emit-llvm -c" to produce LLVM bitcode so that my pass can
> run on it. )

Try dropping the -c and try again.  The makefiles for the project
should add -c, not the CFLAGS passed in.

Andrew


From baldrick at free.fr  Mon Sep 14 08:50:57 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 14 Sep 2009 15:50:57 +0200
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
Message-ID: <4AAE4A41.7080703@free.fr>

Hi Bill,

> Right now we generate call sites for all of the code in a function,  
> even for code that cannot (or at least shouldn't) throw an exception.
...
> (assume it's all been inlined), the EH handling table for "main" goes  
> from Leh_func_begin1 to Leh_func_end1, marking off each region whether  
> it can throw or not. From my reading of the Exception Tables  
> documentation, this is unnecessary ? at least for C++. If a call  
> throws and it doesn't have an entry in the unwind table, then the  
> "terminate()" function is called. Is it fair to assume that there is a  
> similar mechanism for other languages?

in Ada these extra table entries are not needed at all: whether you
have them or not, an exception will continue to unwind.  There is no
calling of "terminate".  In short: you only need a table entry for
invoke calls, i.e. things you want to catch in this function.

The reason to ask this is that
> it could make the EH tables smaller and less cluttered if we elide  
> those areas which we know don't throw (the functions called are marked  
> 'nounwind', etc.).

Sure, that's what the SawPotentiallyThrowing boolean is for.  It is
currently set for any call, but in fact needn't be set for 'nounwind'
calls.  When I wrote this stuff 'nounwind' information wasn't available
at the codegen level, which is why this isn't done.  In case you care,
doing this would not hurt Ada :)

Ciao,

Duncan.



From vargaz at gmail.com  Mon Sep 14 09:51:40 2009
From: vargaz at gmail.com (Zoltan Varga)
Date: Mon, 14 Sep 2009 16:51:40 +0200
Subject: [LLVMdev] merge request for 2.6
Message-ID: <295e750a0909140751i35b399e6ubf9429b889a109eb@mail.gmail.com>

        Hi,

  Would it be possible to merge this commit:
http://llvm.org/viewvc/llvm-project?view=rev&revision=80960

to the llvm 2.6 branch ? Without it, incomplete unwind info is generated for
functions with 0 stack size.

               thanks

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

From clattner at apple.com  Mon Sep 14 11:51:09 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 09:51:09 -0700
Subject: [LLVMdev] How to split module?
In-Reply-To: <452911084.20899@zju.edu.cn>
References: <452911084.20899@zju.edu.cn>
Message-ID: <B9C3F10B-BF6C-4F37-8AFC-9EE0BD90110B@apple.com>


On Sep 14, 2009, at 12:25 AM, Wenzhi Tao wrote:

> Hi, all.
>
> My question is about how to split one module into N modules(N >= 2)?
> For example, given the following code:

I'd suggest looking at bugpoint and the llvm-extract tool.  Both slice  
and dice modules in various ways.  Look at the ExtractFunction.cpp in  
tools/bugpoint for example.

-Chris

>
> #src.c#
> int main()
> {
>    //......//
>    func1();
>    func2();
>    //......//
>    return 0;
> }
> void func1()
> {
>    //......//
> }
> void func2()
> {
>    //......//
> }
>
> func1() has no dependence with func2(), so they can perform parallel
> execution. And I have to split src.c into src1.c and src2.c instead  
> of using
> thread library, because the target machine has multiple RISC  
> processors
> without Operating System,
>
> #src1.c#
> int main()
> {
>    //......//
>    // synchronization
>    func1();
>    // synchronization
>    //......//
>    return 0;
> }
> void func1()
> {
>    //......//
> }
>
> #src2.c#
> int main()
> {
>    //......//
>    // synchronization
>    func2();
>    // synchronization
>    //......//
>    return 0;
> }
> void func2()
> {
>    //......//
> }
>
> Well, Assume the synchronization statements has been added, how to  
> perform the
> splitting on the orginal module wiht the guarantee of correctness.  
> Thanks you!
> _______________________________________________
> 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 Sep 14 11:59:19 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 09:59:19 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <h8l5cj$tqd$1@ger.gmane.org>
References: <h8l5cj$tqd$1@ger.gmane.org>
Message-ID: <E74EC97A-BD3E-470E-A5B1-AECA17C802E8@apple.com>

On Sep 14, 2009, at 3:20 AM, Stefano Delli Ponti wrote:

> http://www.phoronix.com/scan.php? 
> page=article&item=apple_llvm_gcc&num=1

Unfortunately, they don't specify what flags are used, what  
architecture is compiled for etc.  It's entirely possible that they  
are accidentally compiling the llvm-gcc binaries for x86-32 and the  
gcc ones for x86-64 for example.

If anyone has time to try to reproduce this, it would definitely be  
useful!

-Chris

From clattner at apple.com  Mon Sep 14 11:59:52 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 09:59:52 -0700
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <295e750a0909140751i35b399e6ubf9429b889a109eb@mail.gmail.com>
References: <295e750a0909140751i35b399e6ubf9429b889a109eb@mail.gmail.com>
Message-ID: <974F30A4-4239-4878-AEBF-0F6C0E3755BF@apple.com>

On Sep 14, 2009, at 7:51 AM, Zoltan Varga wrote:
>         Hi,
>
>   Would it be possible to merge this commit:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=80960
>
> to the llvm 2.6 branch ? Without it, incomplete unwind info is  
> generated for functions with 0 stack size.

Does it apply cleanly to the 2.6 branch?

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

From dag at cray.com  Mon Sep 14 11:51:25 2009
From: dag at cray.com (David Greene)
Date: Mon, 14 Sep 2009 11:51:25 -0500
Subject: [LLVMdev] Cache optimizations and data layout
In-Reply-To: <aceb74670909120519h5aa0ab0fl6aac09a0ff3607fd@mail.gmail.com>
References: <aceb74670909120519h5aa0ab0fl6aac09a0ff3607fd@mail.gmail.com>
Message-ID: <200909141151.26295.dag@cray.com>

On Saturday 12 September 2009 07:19, dhruv choudhary wrote:
> Hello,
>
> I am new to LLVM. I am using an x86 code generator. I need to write a few
> passes based on cache blocks and data layout information. Does LLVM provide
> a way for me to see the data layout and analyze what are the cache blocks?
> If not is it possible to implement the same in the current framework?

I've done some of this in our code.  Depending on what you want to do, you
often don't need to know the exact cache layout of data.  It's sufficient to
reason about the relationships of objects to each other.  So you need to know
things about padding and so forth.

For example, to determine whether two accesses to an array might conflict in
the cache, you might look at their objects' relative starting position in the 
address space (either as globals or locals -- dynamic allocations are a 
crapshoot) and determine whether there is enough "space" between the accesses 
to reasonably guess that they won't interfere.

Scalar evolution is essential for this kind of thing and by just adding a bit
more on top you can figure most of this out.

                                    -Dave

From dag at cray.com  Mon Sep 14 12:06:04 2009
From: dag at cray.com (David Greene)
Date: Mon, 14 Sep 2009 12:06:04 -0500
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909111731.22486.dag@cray.com>
References: <200909111731.22486.dag@cray.com>
Message-ID: <200909141206.04322.dag@cray.com>

On Friday 11 September 2009 17:31, you wrote:
> Attached is a patch to print asm comments for spill information.
> We've discussed the mechanisms before but I wanted to run the
> patch by everyone before I start to commit pieces.

No feedback?  What's one supposed to do in such cases?

                           -Dave

From clattner at apple.com  Mon Sep 14 12:12:58 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 10:12:58 -0700
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909141206.04322.dag@cray.com>
References: <200909111731.22486.dag@cray.com> <200909141206.04322.dag@cray.com>
Message-ID: <D34B069F-B80D-413D-AF4D-64B9270B3A2B@apple.com>


On Sep 14, 2009, at 10:06 AM, David Greene wrote:

> On Friday 11 September 2009 17:31, you wrote:
>> Attached is a patch to print asm comments for spill information.
>> We've discussed the mechanisms before but I wanted to run the
>> patch by everyone before I start to commit pieces.
>
> No feedback?  What's one supposed to do in such cases?

Generally you just ping it, as you did.  I'll take a look now.

-Chris

From gohman at apple.com  Mon Sep 14 12:22:42 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 14 Sep 2009 10:22:42 -0700
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909111731.22486.dag@cray.com>
References: <200909111731.22486.dag@cray.com>
Message-ID: <1136707A-857D-4AA6-AD53-0DE4B8E3AFAE@apple.com>

Hi Dave,

On Sep 11, 2009, at 3:31 PM, David Greene wrote:

> Attached is a patch to print asm comments for spill information.
> We've discussed the mechanisms before but I wanted to run the
> patch by everyone before I start to commit pieces.

The Offset->FrameIndex mapping seems rather heavy-weight, as
any expense is incurred even when AsmVerbose is off.   Would it
be possible to use MachineMemOperands instead? In theory,
they should already be preserving the needed information.  If
they're not sufficient, could they be improved?

There is work going on to improve the register allocator's ability
to use rematerlialization.  In a world where the register allocator
can aggressively remat misc. loads, will it still be interesting to
identify spill reloads?

You mentioned at one point that you have some scripts which
know how to read some of these comments.  Would it be
possible for you to include these scripts with the patch so that
others can consider your patch in context?

Dan


From vargaz at gmail.com  Mon Sep 14 12:31:02 2009
From: vargaz at gmail.com (Zoltan Varga)
Date: Mon, 14 Sep 2009 19:31:02 +0200
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <974F30A4-4239-4878-AEBF-0F6C0E3755BF@apple.com>
References: <295e750a0909140751i35b399e6ubf9429b889a109eb@mail.gmail.com>
	<974F30A4-4239-4878-AEBF-0F6C0E3755BF@apple.com>
Message-ID: <295e750a0909141031p23ac833evaffae6f06aa1c186@mail.gmail.com>

Hi,

  It does.

             Zoltan

On Mon, Sep 14, 2009 at 6:59 PM, Chris Lattner <clattner at apple.com> wrote:

> On Sep 14, 2009, at 7:51 AM, Zoltan Varga wrote:
>
>         Hi,
>
>   Would it be possible to merge this commit:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=80960
>
> to the llvm 2.6 branch ? Without it, incomplete unwind info is generated
> for functions with 0 stack size.
>
>
> Does it apply cleanly to the 2.6 branch?
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090914/cb25e0b0/attachment.html 

From dag at cray.com  Mon Sep 14 12:32:10 2009
From: dag at cray.com (David Greene)
Date: Mon, 14 Sep 2009 12:32:10 -0500
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <1136707A-857D-4AA6-AD53-0DE4B8E3AFAE@apple.com>
References: <200909111731.22486.dag@cray.com>
	<1136707A-857D-4AA6-AD53-0DE4B8E3AFAE@apple.com>
Message-ID: <200909141232.12900.dag@cray.com>

On Monday 14 September 2009 12:22, Dan Gohman wrote:
> Hi Dave,
>
> On Sep 11, 2009, at 3:31 PM, David Greene wrote:
> > Attached is a patch to print asm comments for spill information.
> > We've discussed the mechanisms before but I wanted to run the
> > patch by everyone before I start to commit pieces.
>
> The Offset->FrameIndex mapping seems rather heavy-weight, as
> any expense is incurred even when AsmVerbose is off.   Would it
> be possible to use MachineMemOperands instead? In theory,
> they should already be preserving the needed information.  If
> they're not sufficient, could they be improved?

Yeah, I'm not totally happy with that mapping either.  With 
MachineMemOperands, would that be the getOffset() method?  That's
only for FPRel data, though.  What if frame pointer elimination has
been run?

I would love to get out from under the map if possible.

> There is work going on to improve the register allocator's ability
> to use rematerlialization.  In a world where the register allocator
> can aggressively remat misc. loads, will it still be interesting to
> identify spill reloads?

Yes.  I have a later patch that marks remats as well.  The idea is to get a 
sense of how well regalloc is doing.  And you can't remat everything.

> You mentioned at one point that you have some scripts which
> know how to read some of these comments.  Would it be
> possible for you to include these scripts with the patch so that
> others can consider your patch in context?

I'm not sure.  The script counts a whole bunch of things.  All it does is
look for these commentsw and tally up statistics, what's in loops, etc.
It's pretty straightforward.

                                   -Dave

From clattner at apple.com  Mon Sep 14 12:32:25 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 10:32:25 -0700
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909111731.22486.dag@cray.com>
References: <200909111731.22486.dag@cray.com>
Message-ID: <8DA0E62B-A5AA-4AA5-B00F-BF363321196D@apple.com>


On Sep 11, 2009, at 3:31 PM, David Greene wrote:

> Attached is a patch to print asm comments for spill information.
> We've discussed the mechanisms before but I wanted to run the
> patch by everyone before I start to commit pieces.


Some thoughts:

The general approach to enhancing CreateStackObject and adding  
MachineInstr::AsmPrinterFlags seems fine to me!


The testcase should use filecheck to avoid running llc 4 times.  Also,  
it seems better to design a situation where you just have 16 live  
variables instead of taking some random function for  gcc (you're  
implicitly depending on how ra is handling this code instead of  
forcing a situation where any x86-64 codegen would have to spill).

The constness change to TargetRegisterInfo::getFrameRegister looks  
great, please commit it separately.

+  /// hasLoadFromStackSlot - If the specified machine instruction is a
+  /// direct load from a stack slot, return true along with the
+  /// FrameIndex of the loaded stack slot.  If not, return false.
+  /// Unlike isLoadFromStackSlot, this returns true for any
+  /// instructions that loads from the stack.

This comment is contradictory.  It returns true if it is a "direct  
load" but "returns true for any instructions that loads".  likewise  
with the comment on hasStoreToStackSlot.  Would it make sense for the  
default impl of hasLoadFromStackSlot to be isLoadFromStackSlot?

It might be worthwhile to say that this is a "best effort" method.  It  
is not guaranteed to return true for all instructions of the form, it  
is just a hint.


A couple of the methods you're adding to MachineFrameInfo.h are large,  
they should be moved to the .cpp file, allowing you to avoid <limits>  
in the header.


+  /// SpillObjects - A set of frame indices represnting spill slots.

typo represnting.


Why does SpillObjects need to be a DenseSet?  It seems that it is  
created in order.  I think it can just be a vector which is looked up  
with a binary search.


Instead of making CreateStackObject take a "bool isSpill", how about  
adding a new "CreateSpillStackObject"? That seems much nicer in the  
code than having: CreateStackObject(16, 16, /*isSpill*/false);   
everywhere.  The number of places that create spill slots is pretty  
small compared to the number of "/*isSpill*/false".


What is the lib/Target/X86/X86RegisterInfo.cpp change doing?  It needs  
a comment.


+bool X86InstrInfo::isFrameOperand(const MachineInstr *MI, unsigned  
int Op,
..
+    return true;
+  } else {
+    // Check for post-frame index elimination

Please eliminate the 'else' to avoid nesting.  Also, please terminate  
your comment with a period.  There are several comments in the patch  
that need to be terminated.



In AsmPrinter::EmitComments please make "Newline" be a bool  
"NeedsNewline" instead of a char with only two states (uninitialized  
and '\n').  Please initialize it.


Overall, the approach looks very nice.  Please commit this (with the  
changes above) as a series of patches:

1. Constify the TargetRegisterInfo::getFrameRegister argument.
2. Change CreateStackObject so MFI can maintain the information it  
needs.
3. Add the MachineInstr AsmPrinter flags stuff.
4. Land the Asmprinter changes themselves.

Thanks David,

-Chris












From clattner at apple.com  Mon Sep 14 12:33:14 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 10:33:14 -0700
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <1136707A-857D-4AA6-AD53-0DE4B8E3AFAE@apple.com>
References: <200909111731.22486.dag@cray.com>
	<1136707A-857D-4AA6-AD53-0DE4B8E3AFAE@apple.com>
Message-ID: <12D7D49E-4BE6-4007-AFB7-D11EF0CF3E97@apple.com>


On Sep 14, 2009, at 10:22 AM, Dan Gohman wrote:

> Hi Dave,
>
> On Sep 11, 2009, at 3:31 PM, David Greene wrote:
>
>> Attached is a patch to print asm comments for spill information.
>> We've discussed the mechanisms before but I wanted to run the
>> patch by everyone before I start to commit pieces.
>
> The Offset->FrameIndex mapping seems rather heavy-weight, as
> any expense is incurred even when AsmVerbose is off.

It should just be a vector which is binary searched.  I think that  
will make it cheap enough even with asmverbose off.

-Chris

From clattner at apple.com  Mon Sep 14 12:33:46 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 10:33:46 -0700
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <295e750a0909141031p23ac833evaffae6f06aa1c186@mail.gmail.com>
References: <295e750a0909140751i35b399e6ubf9429b889a109eb@mail.gmail.com>
	<974F30A4-4239-4878-AEBF-0F6C0E3755BF@apple.com>
	<295e750a0909141031p23ac833evaffae6f06aa1c186@mail.gmail.com>
Message-ID: <1972CF80-2D48-4970-BAA0-D0D0185DA1BC@apple.com>

Tanya, please pull this patch into 2.6 if there is still time.

-Chris

On Sep 14, 2009, at 10:31 AM, Zoltan Varga wrote:

> Hi,
>
>   It does.
>
>              Zoltan
>
> On Mon, Sep 14, 2009 at 6:59 PM, Chris Lattner <clattner at apple.com>  
> wrote:
> On Sep 14, 2009, at 7:51 AM, Zoltan Varga wrote:
>>         Hi,
>>
>>   Would it be possible to merge this commit:
>> http://llvm.org/viewvc/llvm-project?view=rev&revision=80960
>>
>> to the llvm 2.6 branch ? Without it, incomplete unwind info is  
>> generated for functions with 0 stack size.
>
> Does it apply cleanly to the 2.6 branch?
>
> -Chris
>

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

From dag at cray.com  Mon Sep 14 12:34:15 2009
From: dag at cray.com (David Greene)
Date: Mon, 14 Sep 2009 12:34:15 -0500
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909141232.12900.dag@cray.com>
References: <200909111731.22486.dag@cray.com>
	<1136707A-857D-4AA6-AD53-0DE4B8E3AFAE@apple.com>
	<200909141232.12900.dag@cray.com>
Message-ID: <200909141234.16193.dag@cray.com>

On Monday 14 September 2009 12:32, David Greene wrote:

> > The Offset->FrameIndex mapping seems rather heavy-weight, as
> > any expense is incurred even when AsmVerbose is off.   Would it
> > be possible to use MachineMemOperands instead? In theory,
> > they should already be preserving the needed information.  If
> > they're not sufficient, could they be improved?
>
> Yeah, I'm not totally happy with that mapping either.  With
> MachineMemOperands, would that be the getOffset() method?  That's
> only for FPRel data, though.  What if frame pointer elimination has
> been run?
>
> I would love to get out from under the map if possible.

Are MachineMemOperands available at AsmPrinter time?  Where are they stashed?

                               -Dave

From dag at cray.com  Mon Sep 14 12:50:54 2009
From: dag at cray.com (David Greene)
Date: Mon, 14 Sep 2009 12:50:54 -0500
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <8DA0E62B-A5AA-4AA5-B00F-BF363321196D@apple.com>
References: <200909111731.22486.dag@cray.com>
	<8DA0E62B-A5AA-4AA5-B00F-BF363321196D@apple.com>
Message-ID: <200909141250.55070.dag@cray.com>

On Monday 14 September 2009 12:32, Chris Lattner wrote:
> On Sep 11, 2009, at 3:31 PM, David Greene wrote:
> > Attached is a patch to print asm comments for spill information.
> > We've discussed the mechanisms before but I wanted to run the
> > patch by everyone before I start to commit pieces.
>
> Some thoughts:
>
> The general approach to enhancing CreateStackObject and adding
> MachineInstr::AsmPrinterFlags seems fine to me!

Ok.

> The testcase should use filecheck to avoid running llc 4 times.  Also,
> it seems better to design a situation where you just have 16 live
> variables instead of taking some random function for  gcc (you're
> implicitly depending on how ra is handling this code instead of
> forcing a situation where any x86-64 codegen would have to spill).

I just took some existing spill tests, but you're point is fair.

> The constness change to TargetRegisterInfo::getFrameRegister looks
> great, please commit it separately.

Will do.

> +  /// hasLoadFromStackSlot - If the specified machine instruction is a
> +  /// direct load from a stack slot, return true along with the
> +  /// FrameIndex of the loaded stack slot.  If not, return false.
> +  /// Unlike isLoadFromStackSlot, this returns true for any
> +  /// instructions that loads from the stack.
>
> This comment is contradictory.  It returns true if it is a "direct
> load" but "returns true for any instructions that loads".  likewise

Cut & paste error.  :)

> with the comment on hasStoreToStackSlot.  Would it make sense for the
> default impl of hasLoadFromStackSlot to be isLoadFromStackSlot?

Yeah, goo idea.

> It might be worthwhile to say that this is a "best effort" method.  It
> is not guaranteed to return true for all instructions of the form, it
> is just a hint.

Right.

> A couple of the methods you're adding to MachineFrameInfo.h are large,
> they should be moved to the .cpp file, allowing you to avoid <limits>
> in the header.

Ok.

> Why does SpillObjects need to be a DenseSet?  It seems that it is
> created in order.  I think it can just be a vector which is looked up
> with a binary search.

I wasn't sure ordering was guaranteed.  As I noted to Dan, I'd like to get
rid of this entirely.

> Instead of making CreateStackObject take a "bool isSpill", how about
> adding a new "CreateSpillStackObject"? That seems much nicer in the
> code than having: CreateStackObject(16, 16, /*isSpill*/false);
> everywhere.  The number of places that create spill slots is pretty
> small compared to the number of "/*isSpill*/false".

Yep, much better.

> What is the lib/Target/X86/X86RegisterInfo.cpp change doing?  It needs
> a comment.

Ok.  It's just setting the mapping of stack offset to FrameIndex.

                            -Dave

From gohman at apple.com  Mon Sep 14 12:52:45 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 14 Sep 2009 10:52:45 -0700
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909141234.16193.dag@cray.com>
References: <200909111731.22486.dag@cray.com>
	<1136707A-857D-4AA6-AD53-0DE4B8E3AFAE@apple.com>
	<200909141232.12900.dag@cray.com> <200909141234.16193.dag@cray.com>
Message-ID: <D4DB36AD-4E2D-4F64-BE4D-AC240B56CBD9@apple.com>


On Sep 14, 2009, at 10:34 AM, David Greene wrote:


> On Monday 14 September 2009 12:32, David Greene wrote:
>
>
>>> The Offset->FrameIndex mapping seems rather heavy-weight, as
>>>
>>> any expense is incurred even when AsmVerbose is off.   Would it
>>>
>>> be possible to use MachineMemOperands instead? In theory,
>>>
>>> they should already be preserving the needed information.  If
>>>
>>> they're not sufficient, could they be improved?
>>>
>>
>>
>> Yeah, I'm not totally happy with that mapping either.  With
>>
>> MachineMemOperands, would that be the getOffset() method?  That's
>>
>> only for FPRel data, though.  What if frame pointer elimination has
>>
>> been run?
>>
>>
>>
>> I would love to get out from under the map if possible.
>>
>
> Are MachineMemOperands available at AsmPrinter time?  Where are they  
> stashed?

Yes. There are some places where they aren't preserved, but otherwise
they stick around for the entire CodeGen process. The places that
don't preserve them should ideally be fixed eventually.

They're available via the memoperands_begin()/memoperands_end()
MachineInstr member functions.

Dan


From clattner at apple.com  Mon Sep 14 12:58:56 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 10:58:56 -0700
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909141250.55070.dag@cray.com>
References: <200909111731.22486.dag@cray.com>
	<8DA0E62B-A5AA-4AA5-B00F-BF363321196D@apple.com>
	<200909141250.55070.dag@cray.com>
Message-ID: <D1109068-EB26-49F7-AB8A-362C196A98AD@apple.com>


On Sep 14, 2009, at 10:50 AM, David Greene wrote:

>>
>> Why does SpillObjects need to be a DenseSet?  It seems that it is
>> created in order.  I think it can just be a vector which is looked up
>> with a binary search.
>
> I wasn't sure ordering was guaranteed.  As I noted to Dan, I'd like  
> to get
> rid of this entirely.

I'm pretty sure it is: the "is spill slot" is a property set when the  
spill is created, and spill slots are assigned increasing numbers in  
order.

-Chris

From gohman at apple.com  Mon Sep 14 13:07:37 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 14 Sep 2009 11:07:37 -0700
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909141232.12900.dag@cray.com>
References: <200909111731.22486.dag@cray.com>
	<1136707A-857D-4AA6-AD53-0DE4B8E3AFAE@apple.com>
	<200909141232.12900.dag@cray.com>
Message-ID: <8C0E1F91-4995-46A5-BB72-740216D56AC7@apple.com>


On Sep 14, 2009, at 10:32 AM, David Greene wrote:


> On Monday 14 September 2009 12:22, Dan Gohman wrote:
>
>> Hi Dave,
>>
>>
>>
>> On Sep 11, 2009, at 3:31 PM, David Greene wrote:
>>
>>> Attached is a patch to print asm comments for spill information.
>>>
>>> We've discussed the mechanisms before but I wanted to run the
>>>
>>> patch by everyone before I start to commit pieces.
>>>
>>
>>
>> The Offset->FrameIndex mapping seems rather heavy-weight, as
>>
>> any expense is incurred even when AsmVerbose is off.   Would it
>>
>> be possible to use MachineMemOperands instead? In theory,
>>
>> they should already be preserving the needed information.  If
>>
>> they're not sufficient, could they be improved?
>>
>
> Yeah, I'm not totally happy with that mapping either.  With
> MachineMemOperands, would that be the getOffset() method?  That's
> only for FPRel data, though.  What if frame pointer elimination has
> been run?
>
> I would love to get out from under the map if possible.

MachineMemOperands for spill slots use FixedStack PseudoSourceValues
as their base. There's a unique FixedStack PseudoSourceValue for each
fixed frame object, so it's independent of whether frame pointer
elimination has been done, and it's independent of the actual frame
offsets.

Dan


From isanbard at gmail.com  Mon Sep 14 13:25:41 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 14 Sep 2009 11:25:41 -0700
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <4AAE4A41.7080703@free.fr>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
	<4AAE4A41.7080703@free.fr>
Message-ID: <16e5fdf90909141125gfb405c8uc1deab59e5c9de28@mail.gmail.com>

On Mon, Sep 14, 2009 at 6:50 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Bill,
>
>> Right now we generate call sites for all of the code in a function, ?even
>> for code that cannot (or at least shouldn't) throw an exception.
>
> ...
>>
>> (assume it's all been inlined), the EH handling table for "main" goes
>> ?from Leh_func_begin1 to Leh_func_end1, marking off each region whether ?it
>> can throw or not. From my reading of the Exception Tables ?documentation,
>> this is unnecessary ? at least for C++. If a call ?throws and it doesn't
>> have an entry in the unwind table, then the ?"terminate()" function is
>> called. Is it fair to assume that there is a ?similar mechanism for other
>> languages?
>
> in Ada these extra table entries are not needed at all: whether you
> have them or not, an exception will continue to unwind. ?There is no
> calling of "terminate". ?In short: you only need a table entry for
> invoke calls, i.e. things you want to catch in this function.
>
> The reason to ask this is that
>>
>> it could make the EH tables smaller and less cluttered if we elide ?those
>> areas which we know don't throw (the functions called are marked
>> ?'nounwind', etc.).
>
> Sure, that's what the SawPotentiallyThrowing boolean is for. ?It is
> currently set for any call, but in fact needn't be set for 'nounwind'
> calls. ?When I wrote this stuff 'nounwind' information wasn't available
> at the codegen level, which is why this isn't done. ?In case you care,
> doing this would not hurt Ada :)
>
Yay! :-) I'm interested in getting the tables smaller. And it will
help debug when things go wrong. Thanks!

-bw


From eocallaghan at auroraux.org  Mon Sep 14 14:01:34 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 14 Sep 2009 20:01:34 +0100
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <E74EC97A-BD3E-470E-A5B1-AECA17C802E8@apple.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<E74EC97A-BD3E-470E-A5B1-AECA17C802E8@apple.com>
Message-ID: <521640720909141201w319f75dfx623d00752ed29e@mail.gmail.com>

screw that site, its useless info run by a linux gnu zealot.

2009/9/14 Chris Lattner <clattner at apple.com>:
> On Sep 14, 2009, at 3:20 AM, Stefano Delli Ponti wrote:
>
>> http://www.phoronix.com/scan.php?
>> page=article&item=apple_llvm_gcc&num=1
>
> Unfortunately, they don't specify what flags are used, what
> architecture is compiled for etc. ?It's entirely possible that they
> are accidentally compiling the llvm-gcc binaries for x86-32 and the
> gcc ones for x86-64 for example.
>
> If anyone has time to try to reproduce this, it would definitely be
> useful!
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From evan.cheng at apple.com  Mon Sep 14 14:18:15 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 14 Sep 2009 12:18:15 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <521640720909141201w319f75dfx623d00752ed29e@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<E74EC97A-BD3E-470E-A5B1-AECA17C802E8@apple.com>
	<521640720909141201w319f75dfx623d00752ed29e@mail.gmail.com>
Message-ID: <70AD6238-2523-4743-94A7-D9BDB9A9F563@apple.com>

I wouldn't be so quick to dismiss the numbers. For example, I know  
llvm-gcc does significantly worse on LAME. On the other hand, the  
dhrystone, md5, and blowfish numbers are out of line with my  
expectation.

It would be nice if someone can perform the tests independently and  
file bugzilla reports.

Thanks,

Evan

On Sep 14, 2009, at 12:01 PM, Edward O'Callaghan wrote:

> screw that site, its useless info run by a linux gnu zealot.
>
> 2009/9/14 Chris Lattner <clattner at apple.com>:
>> On Sep 14, 2009, at 3:20 AM, Stefano Delli Ponti wrote:
>>
>>> http://www.phoronix.com/scan.php?
>>> page=article&item=apple_llvm_gcc&num=1
>>
>> Unfortunately, they don't specify what flags are used, what
>> architecture is compiled for etc.  It's entirely possible that they
>> are accidentally compiling the llvm-gcc binaries for x86-32 and the
>> gcc ones for x86-64 for example.
>>
>> If anyone has time to try to reproduce this, it would definitely be
>> useful!
>>
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> -- 
> -- 
> Edward O'Callaghan
> http://www.auroraux.org/
> eocallaghan at auroraux dot org
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From rengolin at systemcall.org  Mon Sep 14 14:23:04 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Mon, 14 Sep 2009 20:23:04 +0100
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <521640720909141201w319f75dfx623d00752ed29e@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<E74EC97A-BD3E-470E-A5B1-AECA17C802E8@apple.com>
	<521640720909141201w319f75dfx623d00752ed29e@mail.gmail.com>
Message-ID: <d9b9d95f0909141223l5fc8f7a5y2f2cc94d3f858e3b@mail.gmail.com>

2009/9/14 Edward O'Callaghan <eocallaghan at auroraux.org>:
> screw that site, its useless info run by a linux gnu zealot.

Well, being a Linux GNU zealot doesn't invalidate numbers. What does
invalidate is that he has no numbers!

He just fired a few applications and counted the seconds, this is
utterly pointless. No reference to how many times he ran, standard
deviations, possible effects of OS cache, compilation parameters, etc,
etc. There simply isn't anything in there. It even lack text in
between the charts, a conclusion, and... well... everything.

"Ignore that site", would also be more polite... ;)

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From dag at cray.com  Mon Sep 14 14:34:11 2009
From: dag at cray.com (David Greene)
Date: Mon, 14 Sep 2009 14:34:11 -0500
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <D4DB36AD-4E2D-4F64-BE4D-AC240B56CBD9@apple.com>
References: <200909111731.22486.dag@cray.com> <200909141234.16193.dag@cray.com>
	<D4DB36AD-4E2D-4F64-BE4D-AC240B56CBD9@apple.com>
Message-ID: <200909141434.11366.dag@cray.com>

On Monday 14 September 2009 12:52, Dan Gohman wrote:

> > Are MachineMemOperands available at AsmPrinter time?  Where are they
> > stashed?
>
> Yes. There are some places where they aren't preserved, but otherwise
> they stick around for the entire CodeGen process. The places that
> don't preserve them should ideally be fixed eventually.
>
> They're available via the memoperands_begin()/memoperands_end()
> MachineInstr member functions.

Ok.  Since I'm using a variant of isLoadFromStackSlot to figure things out,
should we consider rewriting that function to look at memoperands rather
than operands?

Eventually, I mean, not part of this patch.

                           -Dave

From mierle at gmail.com  Mon Sep 14 15:02:33 2009
From: mierle at gmail.com (Keir Mierle)
Date: Mon, 14 Sep 2009 13:02:33 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <d9b9d95f0909141223l5fc8f7a5y2f2cc94d3f858e3b@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<E74EC97A-BD3E-470E-A5B1-AECA17C802E8@apple.com>
	<521640720909141201w319f75dfx623d00752ed29e@mail.gmail.com>
	<d9b9d95f0909141223l5fc8f7a5y2f2cc94d3f858e3b@mail.gmail.com>
Message-ID: <ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>

On Mon, Sep 14, 2009 at 12:23 PM, Renato Golin <rengolin at systemcall.org>wrote:

> 2009/9/14 Edward O'Callaghan <eocallaghan at auroraux.org>:
> > screw that site, its useless info run by a linux gnu zealot.
>
> Well, being a Linux GNU zealot doesn't invalidate numbers. What does
> invalidate is that he has no numbers!
>
> He just fired a few applications and counted the seconds, this is
> utterly pointless. No reference to how many times he ran, standard
> deviations, possible effects of OS cache, compilation parameters, etc,
> etc. There simply isn't anything in there. It even lack text in
> between the charts, a conclusion, and... well... everything.
>
> "Ignore that site", would also be more polite... ;)
>

Nevertheless, the site has a large audience. From a publicity perspective,
it may be worthwhile to work with the author to get more representative
numbers.

Keir



>
> cheers,
> --renato
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
> _______________________________________________
> 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/20090914/b7adc9af/attachment.html 

From dag at cray.com  Mon Sep 14 15:28:24 2009
From: dag at cray.com (David Greene)
Date: Mon, 14 Sep 2009 15:28:24 -0500
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <8C0E1F91-4995-46A5-BB72-740216D56AC7@apple.com>
References: <200909111731.22486.dag@cray.com> <200909141232.12900.dag@cray.com>
	<8C0E1F91-4995-46A5-BB72-740216D56AC7@apple.com>
Message-ID: <200909141528.24903.dag@cray.com>

On Monday 14 September 2009 13:07, Dan Gohman wrote:

> MachineMemOperands for spill slots use FixedStack PseudoSourceValues
> as their base. There's a unique FixedStack PseudoSourceValue for each
> fixed frame object, so it's independent of whether frame pointer
> elimination has been done, and it's independent of the actual frame
> offsets.

>From MachineMemOperand.h:

  /// getValue - Return the base address of the memory access.
  /// Special values are PseudoSourceValue::FPRel, PseudoSourceValue::SPRel,
  /// and the other PseudoSourceValue members which indicate references to
  /// frame/stack pointer relative references and other special references.
  const Value *getValue() const { return V; }

I don't see PseudoSourceValue::FPRel, etc. defined anywhere.  How do I know
if a PseudoSourceValue is from the stack?

                              -Dave


From dag at cray.com  Mon Sep 14 15:39:22 2009
From: dag at cray.com (David Greene)
Date: Mon, 14 Sep 2009 15:39:22 -0500
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909141528.24903.dag@cray.com>
References: <200909111731.22486.dag@cray.com>
	<8C0E1F91-4995-46A5-BB72-740216D56AC7@apple.com>
	<200909141528.24903.dag@cray.com>
Message-ID: <200909141539.23119.dag@cray.com>

On Monday 14 September 2009 15:28, David Greene wrote:

> I don't see PseudoSourceValue::FPRel, etc. defined anywhere.  How do I know
> if a PseudoSourceValue is from the stack?

Ok, the comment is misleading.  I see the class defined in 
PseudoSourceValue.cpp now.  I'll move it to the header.

I have another question.  Looking at the list of MachineMemOperands for an
instruction, is ther eany way to easily know whether the operand is loaded
from or stored to?

                            -Dave

From gohman at apple.com  Mon Sep 14 15:42:43 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 14 Sep 2009 13:42:43 -0700
Subject: [LLVMdev] [PATCH] Spill Comments
In-Reply-To: <200909141539.23119.dag@cray.com>
References: <200909111731.22486.dag@cray.com>
	<8C0E1F91-4995-46A5-BB72-740216D56AC7@apple.com>
	<200909141528.24903.dag@cray.com> <200909141539.23119.dag@cray.com>
Message-ID: <F35B144C-5A8F-4013-8C9F-1AE330228DBE@apple.com>


On Sep 14, 2009, at 1:39 PM, David Greene wrote:


> On Monday 14 September 2009 15:28, David Greene wrote:
>
>
>> I don't see PseudoSourceValue::FPRel, etc. defined anywhere.  How  
>> do I know
>>
>> if a PseudoSourceValue is from the stack?
>>
>
> Ok, the comment is misleading.  I see the class defined in
> PseudoSourceValue.cpp now.  I'll move it to the header.

Yes; the comment was out of date. I just updated it.

>
> I have another question.  Looking at the list of MachineMemOperands  
> for an
> instruction, is ther eany way to easily know whether the operand is  
> loaded
> from or stored to?

Yes. MachineMemOperand has isLoad and isStore flags.

Dan


From xu.xinfeng at gatech.edu  Mon Sep 14 18:34:38 2009
From: xu.xinfeng at gatech.edu (XU Xinfeng)
Date: Mon, 14 Sep 2009 19:34:38 -0400 (EDT)
Subject: [LLVMdev] Dear LLVM,
Message-ID: <348775035.1085651252971278408.JavaMail.root@mail6.gatech.edu>

Dear LLVM,

Now, I have to design special complier for my own multicore microprocessor with cusomized instruction-set and optimized architecture.

After have read a lot of papers about LLVM--a retargettable compiler framework, I still can't catch it clearly how to make LLVM support my target.

Would you please give me some necessary instructions or advice? Thanks!


Robinson Xu
ECE of Gatech

From devang.patel at gmail.com  Mon Sep 14 19:55:11 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Mon, 14 Sep 2009 17:55:11 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <bb55930e0909111320w6e8c18b2qdc652fa72be2058c@mail.gmail.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<bb55930e0909111320w6e8c18b2qdc652fa72be2058c@mail.gmail.com>
Message-ID: <352a1fb20909141755gd383180ncd5e48cfaf0cd99e@mail.gmail.com>

On Fri, Sep 11, 2009 at 1:20 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> I've got a suggestion for a refinement:
>
> Right now, we have classes like DILocation that wrap an MDNode* to
> provide more convenient access to it. It would be more convenient for
> users if instead of
>
> ?MDNode *DbgInfo = Inst->getMD(MDKind::DbgTag);
> ?Inst2->setMD(MDKind::DbgTag, DbgInfo);
>
> they could write:
>
> ?DILocation DbgInfo = Inst->getMD<DILocation>();
> ?inst2->setMD(DbgInfo);

IMO, there is not any need to add two llvm::Instruction  methods,
getMD and setMD. The metadata associated with an instruction will be
store separately anyway.
-
Devang

>
> we'd use TheContext->RegisterMDKind<MyKindWrapper>() or
> ...Register<MyKindWrapper>("name"); to register a new kind. (I prefer
> the first.)
>
> These kind wrappers need a couple methods to make them work:
>
> const StringRef KindWrapper::name("...");
> KindWrapper(MDNode*); ?// Except for special cases like LdStAlign.
> KindWrapper::operator bool() {return mdnode!=NULL;} // ??
> int StaticTypeId<KindWrapper>::value; ?// Used for the proposal's MDKind
> KindWrapper::ValidOnValue(const Value*);
> MDNode* KindWrapper::merge(MDNode*, MDNode*) ?// For the optimizers
>
> StaticTypeId is a new class that maps each of its template arguments
> to a small, unique integer, which may be different in different
> executions.
>
> Since the optimizers may want more methods over time, but we don't
> really want to require users to extend their wrappers, we should say
> that all wrappers must inherit from a particular type. I'd name this
> type "MDKind" and rename the proposed MDKind to MDKindID. Then we can
> add defaults to MDKind over time. Nothing needs to be virtual since
> these types are all used as template arguments.
>
> We could either use a global list of IDs for the MDKinds or have
> separate lists for each Context. StaticTypeId can only provide a
> global list, so giving each Context its own list would take an extra
> lookup, and wouldn't provide any benefit I can see.
>
> Chris mentioned that .bc files would store the mapping from name->ID,
> so the fact that StaticTypeId changes its values between runs isn't a
> problem.
>
> Thoughts?
>
> On Fri, Sep 11, 2009 at 9:57 AM, Chris Lattner <clattner at apple.com> wrote:
>> Devang's work on debug info prompted this, thoughts welcome:
>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
>>
>> -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
>



-- 
-
Devang


From zhunansjtu at gmail.com  Mon Sep 14 19:59:23 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Tue, 15 Sep 2009 08:59:23 +0800
Subject: [LLVMdev] Replace gcc with llvm-gcc???
Message-ID: <1252976363.8361.15.camel@UIUC>

Hi,all

Recently I met a question when I want to replace gcc with llvm-gcc
through configure script(command).

For simply,described like that

I typed as following

1.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-S
-emit-llvm"

configure will failed when it checks whether C compiler is working

2.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-c
-emit-llvm"

configure will failed when it checks the default output filename,just
means the C compiler cannot create executables.


I would like to know what's the matter with this replacing attempt?and
any possibility to overcome the trouble?

Thank you 

ZhuNan
2009.9.15




From ofv at wanadoo.es  Mon Sep 14 20:16:10 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 15 Sep 2009 03:16:10 +0200
Subject: [LLVMdev] Replace gcc with llvm-gcc???
References: <1252976363.8361.15.camel@UIUC>
Message-ID: <87vdjlnh2d.fsf@telefonica.net>

zhunan <zhunansjtu at gmail.com> writes:

> Recently I met a question when I want to replace gcc with llvm-gcc
> through configure script(command).
>
> For simply,described like that
>
> I typed as following
>
> 1.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-S
> -emit-llvm"
>
> configure will failed when it checks whether C compiler is working
>
> 2.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-c
> -emit-llvm"
>
> configure will failed when it checks the default output filename,just
> means the C compiler cannot create executables.
>
>
> I would like to know what's the matter with this replacing attempt?and
> any possibility to overcome the trouble?

Your CFLAGS is telling llvm-gcc that it must not produce an object code
file nor an executable file, but something else (llvm assembler on your
first attempt and llvm bitcode on your second attempt).

`configure' needs a fully working compiler toolset, which means that the
compiler must be able to produce executable files. Your CFLAGS setting
is preventing this.

Execute `configure' with just CC=llvm-gcc and then try

make CFLAGS="-emit-llvm"

if you want LLVM bitcode or

make CFLAGS="-S -emit-llvm"

if you want LLVM assembler.

`make' will fail at the linking phase, but you will have a set of LLVM
bitcode/assembler files for each of your C source files.

If you simply want to replace gcc with llvm-gcc for building your
software, forget about CFLAGS and just do

./configure CC=llvm-gcc && make

-- 
?scar


From wansheg at gmail.com  Mon Sep 14 20:58:29 2009
From: wansheg at gmail.com (=?gbk?B?U2hlbmduICAgV2FuZw==?=)
Date: Tue, 15 Sep 2009 09:58:29 +0800
Subject: [LLVMdev] Dear LLVM,
Message-ID: <tencent_4426E30E70E2E0470808713E@qq.com>

can you give a detail description about the target architecture?  
 
 
------------------ Original ------------------
From: "XU Xinfeng"<xu.xinfeng at gatech.edu>;
Date: 2009??9??15??(??????) ????7:34
To: "llvmdev"<llvmdev at cs.uiuc.edu>;
Subject: [LLVMdev] Dear LLVM,

 
Dear LLVM,

Now, I have to design special complier for my own multicore microprocessor with cusomized instruction-set and optimized architecture.

After have read a lot of papers about LLVM--a retargettable compiler framework, I still can't catch it clearly how to make LLVM support my target.

Would you please give me some necessary instructions or advice? Thanks!


Robinson Xu
ECE of Gatech
_______________________________________________
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/20090915/bb2fb2ae/attachment.html 

From talin at acm.org  Mon Sep 14 22:20:42 2009
From: talin at acm.org (Talin)
Date: Mon, 14 Sep 2009 20:20:42 -0700
Subject: [LLVMdev] My LLVM Project
Message-ID: <4AAF080A.2090201@acm.org>

It was a little over two years ago that I saw Chris give a tech talk on 
LLVM at Google, and that was when I knew that there was a way that I 
could actually build the programming language that I'd been thinking 
about for so long.

Well, the compiler is still not done, even though I've been plugging 
steadily away at it in my free time. However, a lot of progress has been 
made recently, and I thought perhaps some folks might be interested in 
what I am trying to do.

The language is called "Tart", and the one-sentence description is "Tart 
is to C++ as Python is to Perl". Rather than go on about the philosophy 
of the language, however, I will show some code samples.

For example, here's what the "Iterator" interface looks like:

   interface Iterator[%T] {
     def next -> T or void;
   }

'%T' introduces a template parameter named T. The reason for the '%' 
prefix is to support partial specialization - you can mix template 
parameters and regular type expressions in the template argument list, 
as in "Iterator[List[%T]]". This is different from C++ where the 
template parameters and the specialization arguments are in separate lists.

Like C++, Tart is a statically-typed language. Unlike C++, however, 
Tart's type solver can deduce the template parameters of a class from 
the arguments to the constructor or a static method. So for example, a 
factory function such as Array.of(1, 2, 3) can deduce that we want an 
integer array since the arguments are integers. Of course, we can always 
be explicit and say Array[int].of(1, 2, 3). Tart's type solver also 
allows function template arguments to be inferred based on the type of 
variable that the function's return value is assigned to. (Java does 
this as well). Thus, if you have some function that takes a set of 
Strings, you can say "myFunction(EmptySet())", and not have to 
explicitly specify a template argument to EmptySet - it knows what kind 
of set you want.

Back to the example, the result of the iterator's 'next' method is a 
disjoint type (also called a discriminated union) written as "T or 
void". That is, it returns T as long as there are elements in the 
sequence, after which it returns void, i.e. nothing.

LLVM's ability to efficiently  return small aggregate types is critical 
to making this perform well. Ideally, the Tart iterator protocol ought 
to be faster than either Java Enumerators (which requires two icalls per 
loop, one for hasNext() and one for next()), or Python's iterators 
(which depend on exceptions to signal the end of the sequence.)

To use the iterator interface, you can use the convenient "for .. in" 
syntax, similar to Python. Here's a snippet from one of my unit tests:

   def sum(nums:int...) -> int {
     var sum = 0;
     for i in nums {
       sum += i;
     }

     return sum;
   }

The 'sum' function takes a variable number of ints (The ... signals a 
varargs function), and returns an int.

The 'var' keyword declares a variable ('let', by contrast declares a 
constant, which can be local, similar to Java's 'final'). In this case, 
the type is omitted (you could say "var sum:int = 0" if you wanted to be 
explicit.)

You could also write this out longhand:

   def sum(nums:int...) -> int {
     var sum = 0;
     let iter = nums.iterate();
     repeat {
       classify iter.next() {
         as i:int {
           sum += i;
         }

         else {
           break;
         }
       }
     }

     return sum;
   }

Since the iter assignment never changes, we can use 'let' to bind it 
immutably to the variable.

'repeat' is an infinite loop, essentially the same as writing "while true".

'classify' is like a switch statement, except that the cases are types 
rather than values. It works with both disjoint types and polymorphic 
types, similar to what is seen in Scala and various functional languages 
such as OCaml. The variables in the individual 'as' clauses are never in 
scope unless the assignment to that variable actually succeeds, so 
there's no chance of seeing an uninitialized variable.

In any case, I don't want to go on about this too long - at least not 
until the compiler is in better shape to be shown to the world. I still 
need to work on closures, reflection, garbage collection, interface 
proxies, stack dumps, debug info, and a bunch of other stuff. (There's a 
Google code project for it, but I'm not encouraging people to go there 
until I have more of the language finished.)

-- Talin


From nicolas.geoffray at lip6.fr  Tue Sep 15 00:54:35 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Tue, 15 Sep 2009 07:54:35 +0200
Subject: [LLVMdev] Registering a MachineFunctionPass to JIT codegen
Message-ID: <4AAF2C1B.1090509@lip6.fr>

Hi all,

I can't find a way to add a MachineFunctionPass to the common codegen 
passes (LLVMTargetMachine::addPassesToEmitMachineCode) while JITting 
(the pass manager is associated with the jitstate of the JIT and I can't 
access it because it's private). Have I missed something? Or adding a 
MachineFunctionPass to codegen requires to change the 
LLVMTargetMachine::addPassesToEmitMachineCode function?

Thanks,
Nicolas

From clattner at apple.com  Tue Sep 15 00:59:45 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 22:59:45 -0700
Subject: [LLVMdev] Registering a MachineFunctionPass to JIT codegen
In-Reply-To: <4AAF2C1B.1090509@lip6.fr>
References: <4AAF2C1B.1090509@lip6.fr>
Message-ID: <60FEDBA1-ABC4-46CD-BB99-990332F61196@apple.com>


On Sep 14, 2009, at 10:54 PM, Nicolas Geoffray wrote:

> Hi all,
>
> I can't find a way to add a MachineFunctionPass to the common codegen
> passes (LLVMTargetMachine::addPassesToEmitMachineCode) while JITting
> (the pass manager is associated with the jitstate of the JIT and I  
> can't
> access it because it's private). Have I missed something? Or adding a
> MachineFunctionPass to codegen requires to change the
> LLVMTargetMachine::addPassesToEmitMachineCode function?

You haven't missed anything, there isn't currently a way to do this.

-Chris

From simmon12 at illinois.edu  Tue Sep 15 01:03:49 2009
From: simmon12 at illinois.edu (Patrick Simmons)
Date: Tue, 15 Sep 2009 00:03:49 -0600
Subject: [LLVMdev] IDE on *nix
In-Reply-To: <d9b9d95f0909120154m217217c2g908a42be2c3e42cb@mail.gmail.com>
References: <d9b9d95f0909120154m217217c2g908a42be2c3e42cb@mail.gmail.com>
Message-ID: <4AAF2E45.1050609@illinois.edu>

Hi Renato,

I've been using LLVM with Eclipse for a while now.  The way to do it is 
to build LLVM with CMake and tell CMake to generate an Eclipse project 
file, like so:

cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" 
-DBUILD_SHARED_LIBS=ON -DLLVM_TARGETS_TO_BUILD="X86;PowerPC;CBackend" 
/home/renato/llvm-sources

You'll need to modify that command for your real LLVM path and the 
correct build options for you, of course.

There is more information on this in the list archives.

--Patrick

Renato Golin wrote:
> Hi all,
>
> Is anyone using any flavour of Unix to develop LLVM? I suppose the
> Apple guys are using Mac, right? ;)
>
> I've seen some docs on the website to set-up Visual Studio but I
> haven't seen anything related to cross-platform IDEs (such as Eclipse)
> and how to attach the tests to them.
>
> So far I'm not doing any modifications to the LLVM and my project is
> still too small to become a memory black-hole on Eclipse, but putting
> LLVM itself on it was a bit harsh.
>
> cheers,
> --renato
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


-- 
If I'm not here, I've gone out to find myself.  If I get back before I return, please keep me here.


From nicholas at mxc.ca  Tue Sep 15 01:33:27 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 14 Sep 2009 23:33:27 -0700
Subject: [LLVMdev] [llvm-commits] [llvm] r81845 - in /llvm/trunk:
 lib/VMCore/ConstantFold.cpp test/Assembler/insertextractvalue.ll
In-Reply-To: <200909150628.n8F6SDib007558@zion.cs.uiuc.edu>
References: <200909150628.n8F6SDib007558@zion.cs.uiuc.edu>
Message-ID: <4AAF3537.6000904@mxc.ca>

Chris Lattner wrote:
> URL: http://llvm.org/viewvc/llvm-project?rev=81845&view=rev
> Log:
> fix PR4963: folding insertvalue would sometimes turn a packed struct into
> an unpacked one.

About this bug -- it happened because ConstantStruct::get has a default 
parameter for whether the struct should be packed or not, which defaults 
to not packed.

This is strikingly error prone. We even list struct and packed struct as 
two different types in the LangRef. We don't need to go so far as to 
offer separate ConstantStruct and ConstantPackedStruct but maybe the 
isPacked parameter should at least be mandatory?

Any objections?

Nick

From zhunansjtu at gmail.com  Tue Sep 15 01:35:19 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Tue, 15 Sep 2009 14:35:19 +0800
Subject: [LLVMdev] Replace gcc with llvm-gcc
In-Reply-To: <mailman.207.1252977404.11840.llvmdev@cs.uiuc.edu>
References: <mailman.207.1252977404.11840.llvmdev@cs.uiuc.edu>
Message-ID: <1252996519.8385.3.camel@UIUC>

I truly get the bytecode file for each souce file,but can I use
llvm-link to link them into a whole-program one automatically through
some scripts?


> 
> Message: 27
> Date: Tue, 15 Sep 2009 03:16:10 +0200
> From: ?scar Fuentes <ofv at wanadoo.es>
> Subject: Re: [LLVMdev] Replace gcc with llvm-gcc???
> To: llvmdev at cs.uiuc.edu
> Message-ID: <87vdjlnh2d.fsf at telefonica.net>
> Content-Type: text/plain; charset=windows-1252
> 
> zhunan <zhunansjtu at gmail.com> writes:
> 
> > Recently I met a question when I want to replace gcc with llvm-gcc
> > through configure script(command).
> >
> > For simply,described like that
> >
> > I typed as following
> >
> > 1.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-S
> > -emit-llvm"
> >
> > configure will failed when it checks whether C compiler is working
> >
> > 2.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-c
> > -emit-llvm"
> >
> > configure will failed when it checks the default output filename,just
> > means the C compiler cannot create executables.
> >
> >
> > I would like to know what's the matter with this replacing attempt?and
> > any possibility to overcome the trouble?
> 
> Your CFLAGS is telling llvm-gcc that it must not produce an object code
> file nor an executable file, but something else (llvm assembler on your
> first attempt and llvm bitcode on your second attempt).
> 
> `configure' needs a fully working compiler toolset, which means that the
> compiler must be able to produce executable files. Your CFLAGS setting
> is preventing this.
> 
> Execute `configure' with just CC=llvm-gcc and then try
> 
> make CFLAGS="-emit-llvm"
> 
> if you want LLVM bitcode or
> 
> make CFLAGS="-S -emit-llvm"
> 
> if you want LLVM assembler.
> 
> `make' will fail at the linking phase, but you will have a set of LLVM
> bitcode/assembler files for each of your C source files.
> 
> If you simply want to replace gcc with llvm-gcc for building your
> software, forget about CFLAGS and just do
> 
> ./configure CC=llvm-gcc && make
> 


From sabre at nondot.org  Tue Sep 15 01:43:06 2009
From: sabre at nondot.org (Chris Lattner)
Date: Mon, 14 Sep 2009 23:43:06 -0700
Subject: [LLVMdev] [llvm-commits] [llvm] r81845 - in /llvm/trunk:
	lib/VMCore/ConstantFold.cpp test/Assembler/insertextractvalue.ll
In-Reply-To: <4AAF3537.6000904@mxc.ca>
References: <200909150628.n8F6SDib007558@zion.cs.uiuc.edu>
	<4AAF3537.6000904@mxc.ca>
Message-ID: <A4541FEA-9BA0-49EB-972A-D135B9320019@nondot.org>


On Sep 14, 2009, at 11:33 PM, Nick Lewycky wrote:

> Chris Lattner wrote:
>> URL: http://llvm.org/viewvc/llvm-project?rev=81845&view=rev
>> Log:
>> fix PR4963: folding insertvalue would sometimes turn a packed  
>> struct into
>> an unpacked one.
>
> About this bug -- it happened because ConstantStruct::get has a  
> default
> parameter for whether the struct should be packed or not, which  
> defaults
> to not packed.
>
> This is strikingly error prone. We even list struct and packed  
> struct as
> two different types in the LangRef. We don't need to go so far as to
> offer separate ConstantStruct and ConstantPackedStruct but maybe the
> isPacked parameter should at least be mandatory?

Please do make it mandatory, thanks!

-Chris

From clattner at apple.com  Tue Sep 15 01:54:25 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 14 Sep 2009 23:54:25 -0700
Subject: [LLVMdev] SCCIterator and unconnected graphs
In-Reply-To: <4A9FA563.1030602@elis.UGent.be>
References: <4A9FA563.1030602@elis.UGent.be>
Message-ID: <5A7CDC28-1A9B-40E0-B0C7-653617889D77@apple.com>

On Sep 3, 2009, at 4:15 AM, Hans Vandierendonck wrote:
Hi,
>
> I am using the scc_iterator class in my code on a CallGraph, where  
> some
> functions are not called from within the module. It seems that
> scc_iterator does not list all SCCs if the graph is not connected;  
> only
> those nodes connected to the node pointed to by
> GraphTraits<...>::getEntryNode() are returned.
>
> Can someone verify this behavior?
> Any tips on how I should go about extending the class in order to  
> visit
> all SCCs?
> Is it desirable to augment the scc_iterator class itself, or should I
> construct another one? The change in behavior may impact things such  
> as
> CallGraphSCCPass, GlobalsModRef, etc. and I don't know if it is
> desirable to have that change there.

This definitely sounds bad, but doesn't match what I'm seeing with the  
callgraphscc passmanager.  How are you using SCCIterator?

-Chris

From Olaf.Krzikalla at tu-dresden.de  Tue Sep 15 01:55:29 2009
From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla)
Date: Tue, 15 Sep 2009 08:55:29 +0200
Subject: [LLVMdev] compiling clang with rtti
In-Reply-To: <6a8523d60909110839q392e1cc8k3c41bb9b569488eb@mail.gmail.com>
References: <4AAA416B.7060806@tu-dresden.de>
	<6a8523d60909110839q392e1cc8k3c41bb9b569488eb@mail.gmail.com>
Message-ID: <4AAF3A61.8060100@tu-dresden.de>

Daniel Dunbar schrieb:
>> Hi @clang,
>> First: why is line 348 commented out? This renders REQUIRES_RTTI
>> useless. Does rtti (llvm) and non-rtti (clang) code work together at
>> all? I had serious trouble when trying this with my own application and
>> eventually resigned .
>>     
>
> Dunno, but I think its fine to fix REQUIRES_RTTI, I'll do so right now
>   
Thank you, this should fix my actual problem.

>> I'm forced to use rtti in my application as it uses some clang libs but
>> also some tr1 stuff (which apparently needs rtti) and boost. This leads
>> me to the second question:
>>     
>
> That doesn't necessarily explain why you are forced to use RTTI (just
> as clang doesn't use RTTI but LLVM does, and only the LLVM parts build
> with RTTI).
>   
Digging deeper into this yields two issues.
First boost function (and gcc's tr1::function implementation) needs
rtti. Two months ago there was a discussion at the boost mailing list
about this requirement (Douglas Gregor was involved) and the conclusion
was that it needs to be working without rtti. However at the moment I
have to go with what we have.
Secondly gcc produces 'missing typeinfo' linker errors if I create a
object (of a class which was defined in a clang lib, e.g. AST) in my own
lib (where rtti is activated). The gcc strategy for creating these
typeinfo objects explains why there is no typeinfo object if the clang
lib is compiled without rtti. I'm not sure if the linker error is
necessary anyway but on the other hand mixing rtti and non-rtti this is
nothing covered by the standard. Thus I have to live with that too.
Eventually my only solution for both points was to turn on rtti for
clang libs.

Best regards
Olaf Krzikalla



From nicolas.geoffray at lip6.fr  Tue Sep 15 02:00:22 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Tue, 15 Sep 2009 09:00:22 +0200
Subject: [LLVMdev] Registering a MachineFunctionPass to JIT codegen
In-Reply-To: <60FEDBA1-ABC4-46CD-BB99-990332F61196@apple.com>
References: <4AAF2C1B.1090509@lip6.fr>
	<60FEDBA1-ABC4-46CD-BB99-990332F61196@apple.com>
Message-ID: <4AAF3B86.2060405@lip6.fr>

Hi Chris,

Chris Lattner wrote:
> You haven't missed anything, there isn't currently a way to do this.
>

Good to know. Anything against making the codegen pass manager 
accessible to users? Something like 
ExecutionEngine::getCommonCodegenPassManager() ?

Thanks,
Nicolas


From hvdieren at elis.UGent.be  Tue Sep 15 03:03:59 2009
From: hvdieren at elis.UGent.be (Hans Vandierendonck)
Date: Tue, 15 Sep 2009 10:03:59 +0200
Subject: [LLVMdev] SCCIterator and unconnected graphs
In-Reply-To: <5A7CDC28-1A9B-40E0-B0C7-653617889D77@apple.com>
References: <4A9FA563.1030602@elis.UGent.be>
	<5A7CDC28-1A9B-40E0-B0C7-653617889D77@apple.com>
Message-ID: <4AAF4A6F.5080504@elis.UGent.be>

Chris Lattner wrote:
> On Sep 3, 2009, at 4:15 AM, Hans Vandierendonck wrote:
> Hi,
>>
>> I am using the scc_iterator class in my code on a CallGraph, where some
>> functions are not called from within the module. It seems that
>> scc_iterator does not list all SCCs if the graph is not connected; only
>> those nodes connected to the node pointed to by
>> GraphTraits<...>::getEntryNode() are returned.
>>
>> Can someone verify this behavior?
>> Any tips on how I should go about extending the class in order to visit
>> all SCCs?
>> Is it desirable to augment the scc_iterator class itself, or should I
>> construct another one? The change in behavior may impact things such as
>> CallGraphSCCPass, GlobalsModRef, etc. and I don't know if it is
>> desirable to have that change there.
>
> This definitely sounds bad, but doesn't match what I'm seeing with the 
> callgraphscc passmanager.  How are you using SCCIterator?
>
> -Chris

I have digged deeper into this; it seems everything is ok for 
CallGraphs. Here is what I found.

Attached are 2 .ll files, reduced using bugpoint
and a Pass that uses the SCCIterator to traverse the CallGraph SCCs.
The pass simply prints all function names as it visits them.

The file bugpoint-reduced-simplified.ll has all external functions and 
one defined *internal* function (getGlobalCRC).
The callgraph is not connected as there is no way to call the internal 
function (it's dead).
In bugpoint-reduced-simplified2.ll, the defined function is now not 
internal, but also exported.
There is now theoretically a way to call the function getGlobalCRC, so 
the callgraph is connected.

When running the pass on the first .ll file, then the function 
getGlobalCRC() is *not* visited.
When running the pass on the second .ll file, then the function 
getGlobalCRC() is visited.

The problem pops up for me because I have a pass based on the 
CallGraphSCC that computes and caches info on the functions. In a second 
pass, I query this information by traversing all functions in the 
module. In the second pass I see a function for which I don't have any 
info, which is problematic. I should probably run -globaldce before 
running my passes.

This is probably all about semantics of what should be in the CallGraph 
and what not.
I guess I did not expect the CallGraph to be optimized to skip dead 
functions.


So far for the CallGraph.
If I want to run the SCCIterator on an unconnected graph (for instance, 
some dependence graph I create myself), would it visit all SCC 
components? Even though I can identify only one root node via the 
GraphTraits::getEntryNode()?

Thanks,
Hans.

-- 
-------------------------------------------------------------------------------
 Hans Vandierendonck, PhD, Ghent University, Electronics & Information Systems
 E-mail: hans.vandierendonck at UGent.be      http://www.elis.UGent.be/~hvdieren/
-------------------------------------------------------------------------------

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bugpoint-reduced-simplified.ll
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090915/5c27ac13/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bugpoint-reduced-simplified2.ll
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090915/5c27ac13/attachment-0001.pl 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestCGIt.cpp
Type: text/x-c++src
Size: 2158 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090915/5c27ac13/attachment.bin 

From pekka.jaaskelainen at tut.fi  Tue Sep 15 03:46:44 2009
From: pekka.jaaskelainen at tut.fi (=?ISO-8859-1?Q?Pekka_J=E4=E4skel=E4inen?=)
Date: Tue, 15 Sep 2009 11:46:44 +0300
Subject: [LLVMdev] Fwd: [llvm-commits] [PATCH] Building llvm-gcc with
 llvm-2.5 debian packages
In-Reply-To: <B421EFAA-C664-4760-957E-8E04D70BDEA8@tut.fi>
References: <DACC02ED-6BF3-4BA1-83FD-A434EE28B2CA@tut.fi>
	<B421EFAA-C664-4760-957E-8E04D70BDEA8@tut.fi>
Message-ID: <4AAF5474.7060702@tut.fi>

Mikael Lepist? wrote:
> Anybody has an opinion would it be good thing  to add support for 
> llvm-gcc to be able to be built with existing llvm installation? 

To put it the another way: is there a reason to disallow
compiling llvm-gcc (optionally) against an installed LLVM (e.g.
from the Debian package)? It seems to work fine with this patch
Mikael posted.

For us at TCE project* it's a bit nuisance as even though the TCE
user might have LLVM (and native llvm-gcc) installed from Debian,
he still needs to download LLVM sources just for recompiling llvm-gcc to
be used as the TCE cross-compiler.

(*)http://tce.cs.tut.fi

Best regards,
-- 
--Pekka J??skel?inen

From rengolin at systemcall.org  Tue Sep 15 04:06:56 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Tue, 15 Sep 2009 10:06:56 +0100
Subject: [LLVMdev] My LLVM Project
In-Reply-To: <4AAF080A.2090201@acm.org>
References: <4AAF080A.2090201@acm.org>
Message-ID: <d9b9d95f0909150206oe819eb7m3f2541a5eefce20c@mail.gmail.com>

2009/9/15 Talin <talin at acm.org>:
> For example, here's what the "Iterator" interface looks like:
>
> ? interface Iterator[%T] {
> ? ? def next -> T or void;
> ? }

So this would be something like:

template <class T>
virtual class Iterator {
  T next(); // or void?
};

So the power of having two types of return parameters is that you save
function calls (hasNext())?


> ? def sum(nums:int...) -> int {
> ? ? var sum = 0;
> ? ? for i in nums {
> ? ? ? sum += i;
> ? ? }
> ? ? return sum;
> ? }

I see you don't have types for variables, only for containers,
templates and functions. And yet you say your language is
statically-typed. If you do:

var foo = 10; // I'd presume it's an int
foo /= 3;

Would foo become a float?

foo /= 1e200;

Would it become a double?

What happens if you pass foo as an int, and inside the function it
becomes a double (without your consent, by a combination of
parameters) and you try to return it as an int?


> 'classify' is like a switch statement, except that the cases are types
> rather than values. It works with both disjoint types and polymorphic
> types, similar to what is seen in Scala and various functional languages
> such as OCaml. The variables in the individual 'as' clauses are never in
> scope unless the assignment to that variable actually succeeds, so
> there's no chance of seeing an uninitialized variable.

Is it run-time or compile-time? The former is Java's insanceof/C++
RTTI, the later has not many uses...


> In any case, I don't want to go on about this too long - at least not
> until the compiler is in better shape to be shown to the world. I still
> need to work on closures, reflection, garbage collection, interface
> proxies, stack dumps, debug info, and a bunch of other stuff. (There's a
> Google code project for it, but I'm not encouraging people to go there
> until I have more of the language finished.)

I think it's great to write compilers to learn how languages work (I'm
doing my own too).

My points about the language:

First, It's much more like a cross between Python/Perl and Java than
C++. It's not strongly typed and yet it use generic programming. As
long as it's not creating *types* with templates (like C++) but
creating only generic algorithms (like Java), it's ok.

It has too much syntactic sugar and names changed for no apparent
reason, it drives the user away from using your language. A good deal
of Java's success is because they used a syntax very similar to C++.

My (very personal) point of view is that, if you're not bringing
anything new, help the others that are instead of re-inventing the
wheel. But again, if your point is (as mine) to learn, well done! It's
much better than my own language! ;)

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From baldrick at free.fr  Tue Sep 15 04:11:30 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 15 Sep 2009 11:11:30 +0200
Subject: [LLVMdev] Fwd: [llvm-commits] [PATCH] Building llvm-gcc with
 llvm-2.5 debian packages
In-Reply-To: <4AAF5474.7060702@tut.fi>
References: <DACC02ED-6BF3-4BA1-83FD-A434EE28B2CA@tut.fi>	<B421EFAA-C664-4760-957E-8E04D70BDEA8@tut.fi>
	<4AAF5474.7060702@tut.fi>
Message-ID: <4AAF5A42.9020101@free.fr>

Hi Pekka,

> To put it the another way: is there a reason to disallow
> compiling llvm-gcc (optionally) against an installed LLVM (e.g.
> from the Debian package)? It seems to work fine with this patch
> Mikael posted.

I think it would be great if llvm-gcc could be built against
an installed LLVM.  However my impression was that Mikael's
original patch would break building against an not-installed llvm.

Ciao,

Duncan.

From rengolin at systemcall.org  Tue Sep 15 04:22:43 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Tue, 15 Sep 2009 10:22:43 +0100
Subject: [LLVMdev] IDE on *nix
In-Reply-To: <4AAF2E45.1050609@illinois.edu>
References: <d9b9d95f0909120154m217217c2g908a42be2c3e42cb@mail.gmail.com>
	<4AAF2E45.1050609@illinois.edu>
Message-ID: <d9b9d95f0909150222u4e887b7fr80bcf82b3e1436c4@mail.gmail.com>

2009/9/15 Patrick Simmons <simmon12 at illinois.edu>:
> cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug"
> -DBUILD_SHARED_LIBS=ON -DLLVM_TARGETS_TO_BUILD="X86;PowerPC;CBackend"
> /home/renato/llvm-sources

Thanks Patrick, I'll give it a try.

At least now I know that it can be done. My previous attempts all
ended up in memory depletion during the indexing. ;)

I'll check the archives...

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From mikael.lepisto at tut.fi  Tue Sep 15 05:28:38 2009
From: mikael.lepisto at tut.fi (=?ISO-8859-1?Q?Mikael_Lepist=F6?=)
Date: Tue, 15 Sep 2009 13:28:38 +0300
Subject: [LLVMdev] Fwd: [llvm-commits] [PATCH] Building llvm-gcc with
	llvm-2.5 debian packages
In-Reply-To: <4AAF5A42.9020101@free.fr>
References: <DACC02ED-6BF3-4BA1-83FD-A434EE28B2CA@tut.fi>	<B421EFAA-C664-4760-957E-8E04D70BDEA8@tut.fi>
	<4AAF5474.7060702@tut.fi> <4AAF5A42.9020101@free.fr>
Message-ID: <BC7B9DEE-C1E3-4142-8618-7E134CE61BEB@tut.fi>


On 15.9.2009, at 12:11, Duncan Sands wrote:

> Hi Pekka,
>
>> To put it the another way: is there a reason to disallow
>> compiling llvm-gcc (optionally) against an installed LLVM (e.g.
>> from the Debian package)? It seems to work fine with this patch
>> Mikael posted.
>
> I think it would be great if llvm-gcc could be built against
> an installed LLVM.  However my impression was that Mikael's
> original patch would break building against an not-installed llvm.
>

Hi, sorry for being a bit unclear before.

The patch would just fix llvm-gcc build system to be able to compile  
with both, *llvm build in source directory* and *installed llvm  
version*.

Correct include directory can be get with llvm-config --includedir,  
because when llvm-config is excuted from llvm source tree (from  
Release or Debug directory) it will return the include directory of  
source tree (e.g. llvm-2.6svn/include). If llvm-config is called from  
installation path it returns include directory of installed llvm  
includes.

I  tried the patch with compiling llvm-gcc with:
- llvm-2.5 source tree build
- installed llvm-2.5 from sources
- apt-get installed debian llvm-2.5 packages.

I will try if the patch works correctly with llvm trunk as well and  
show also the compile commands which were used to configure and  
compile the llvm-gcc.

- Mikael

> 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 meurant.olivier at gmail.com  Tue Sep 15 08:16:17 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Tue, 15 Sep 2009 15:16:17 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<E74EC97A-BD3E-470E-A5B1-AECA17C802E8@apple.com>
	<521640720909141201w319f75dfx623d00752ed29e@mail.gmail.com>
	<d9b9d95f0909141223l5fc8f7a5y2f2cc94d3f858e3b@mail.gmail.com>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
Message-ID: <549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>

Hi everyone,
I have replayed the "unix benchmark v3.6 dhrystone 2" test.

You can find the archive of the test here :
http://www.phoronix-test-suite.com/benchmark-files/byte-benchmark-1.tar.gz
To play the test on gcc :
make
./Run dhry2
To play the test on llvm-gcc :
Replace in Makefile : CC=gcc by CC=llvm-gcc
in Run : CC=gcc by CC=llvm-gcc
make
./Run dhry2

Some information on the test platform :

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.04
DISTRIB_CODENAME=jaunty
DISTRIB_DESCRIPTION="Ubuntu 9.04"

uname -a
Linux zaraki 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009
i686 GNU/Linux

/proc/cpuinfo
dual core Intel(R) Core(TM)2 CPU X6800  @ 2.93GHz (cache size 4096)

llvm-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../llvm-gcc4.2-2.5.source/
configure
--prefix=/mounts/zion/disks/0/localhome/tbrethou/2.5/prerelease2/llvm-gcc/obj/../install
--program-prefix=llvm-
--enable-llvm=/localhome/tbrethou/2.5/prerelease2/llvm-2.5/
--disable-bootstrap --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5636) (LLVM build 2.5)
(Binary from official x86 2.5 release)

gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)

The test displays its results in form of a number with unit seems to be
"loops per seconds". So it's logical to say that the bigger is better.
I run the test 10 times for each compiler (for an approximate duration of 20
minutes each compiler).

Results:
LLVM average : 10696687.14
GCC average : 9563046.99
LLVM is on average 10.58% faster than GCC on this test.

If you need more informations or if you think my test was not correctly
made... ping me. :)

Here a quick report on the test. (shows individual result of each test) :


LLVM GCC Difference Difference %




 Run 1 10720897.7 9875431 845466.7 7.89  Run 2 10411474.6 9666138.5 745336.1
7.16  Run 3 10580705.2 9265904.6 1314800.6 12.43  Run 4 10746408 9539499.9
1206908.1 11.23  Run 5 10818845.5 9766210.7 1052634.8 9.73  Run 6 10904404.3
10034620.8 869783.5 7.98  Run 7 10861482.8 9028718.6 1832764.2 16.87  Run 8
10480568.5 9568849.4 911719.1 8.7  Run 9 10857968.2 9306331.6 1551636.6
14.29  Run 10 10584116.6 9578764.8 1005351.8 9.5




 Average 10696687.14 9563046.99 1133640.15 10.58  Standard deviation
172714.92 300445.48 345992.26 3.13
Cheers,
Olivier.


On Mon, Sep 14, 2009 at 10:02 PM, Keir Mierle <mierle at gmail.com> wrote:
>
> On Mon, Sep 14, 2009 at 12:23 PM, Renato Golin <rengolin at systemcall.org>
wrote:
>>
>> 2009/9/14 Edward O'Callaghan <eocallaghan at auroraux.org>:
>> > screw that site, its useless info run by a linux gnu zealot.
>>
>> Well, being a Linux GNU zealot doesn't invalidate numbers. What does
>> invalidate is that he has no numbers!
>>
>> He just fired a few applications and counted the seconds, this is
>> utterly pointless. No reference to how many times he ran, standard
>> deviations, possible effects of OS cache, compilation parameters, etc,
>> etc. There simply isn't anything in there. It even lack text in
>> between the charts, a conclusion, and... well... everything.
>>
>> "Ignore that site", would also be more polite... ;)
>
> Nevertheless, the site has a large audience. From a publicity perspective,
it may be worthwhile to work with the author to get more representative
numbers.
> Keir
>
>>
>> cheers,
>> --renato
>>
>> Reclaim your digital rights, eliminate DRM, learn more at
>> http://www.defectivebydesign.org/what_is_drm
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090915/edc5ef63/attachment-0001.html 

From graham.hemingway at gmail.com  Tue Sep 15 08:29:40 2009
From: graham.hemingway at gmail.com (Graham Hemingway)
Date: Tue, 15 Sep 2009 08:29:40 -0500
Subject: [LLVMdev] LLVM Beginner Question
Message-ID: <A3A43566-CBB1-47D0-A537-DA157A4767A1@gmail.com>

Hello,

I am just getting started with LLVM and am having some build issues.
I am running Snow Leopard and like to use XCode as my IDE.  I know
that I need to compile with llvm-config to get all of the proper build
settings.  My question is how do I incorporate llvm-config into my
XCode project settings?  I would prefer to not have to use the command
line to build.

Thanks,

Graham



From llvm at assumetheposition.nl  Tue Sep 15 08:34:09 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Tue, 15 Sep 2009 15:34:09 +0200 (CEST)
Subject: [LLVMdev] C API linking problem
Message-ID: <33411.145.100.6.164.1253021649.squirrel@www.assumetheposition.nl>

Hello all,

Does anyone have any inside why I can't get the below simple C API test to
link? This is on a 32-bit Gentoo Linux system and LLVM TOT which was
compiled with enable-optimized, gcc is 4.3.2.

15:26|melis at juggle2:~/c/llvmpy> cat t.c
#include "llvm-c/Core.h"

int main()
{
    LLVMContextRef ctx;
    ctx = LLVMContextCreate();
    return 0;
}

15:29|melis at juggle2:~/c/llvmpy> llvm-config --cflags --ldflags --libs all
-I/home/melis/llvm/include  -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -O3 -fomit-frame-pointer -fPIC
-L/home/melis/llvm/lib  -lpthread -ldl -lm
-lLLVMLinker -lLLVMipo -lLLVMInterpreter -lLLVMInstrumentation -lLLVMJIT
-lLLVMExecutionEngine -lLLVMDebugger -lLLVMCBackend -lLLVMCBackendInfo
-lLLVMBitWriter -lLLVMX86AsmParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen
-lLLVMSelectionDAG -lLLVMX86Info -lLLVMAsmPrinter -lLLVMCodeGen
-lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa -lLLVMAsmParser
-lLLVMArchive -lLLVMBitReader -lLLVMAnalysis -lLLVMTarget -lLLVMMC
-lLLVMCore -lLLVMSupport -lLLVMSystem

15:29|melis at juggle2:~/c/llvmpy> gcc -W -Wall -o blah `llvm-config --cflags
--ldflags --libs all` t.c
/tmp/ccs4MbKp.o: In function `main':
t.c:(.text+0x21): undefined reference to `LLVMContextCreate'
collect2: ld returned 1 exit status

15:29|melis at juggle2:~/c/llvmpy> nm ~/llvm/lib/libLLVMCore.a | grep
LLVMContextCreate
00001bc0 T LLVMContextCreate

Regards,
Paul



From kennethuil at gmail.com  Tue Sep 15 08:48:05 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 15 Sep 2009 08:48:05 -0500
Subject: [LLVMdev] My LLVM Project
In-Reply-To: <4AAF080A.2090201@acm.org>
References: <4AAF080A.2090201@acm.org>
Message-ID: <400d33ea0909150648v5bfa62d1x1d942023e494a38e@mail.gmail.com>

If your goal is to create a usable language, your best bet is to use
it.  Create a significant project and code it in your language.  This
will show you what the language/standard library still need, what
coding tasks are too awkward to carry out, what practical advantages
your language offers over alternatives, and so forth.

A compiler for your language is an obvious first project to try out.
This will exercise your language/standard library in parsing,
interacting with external libraries (including but not limited to
LLVM), file handling, data structure manipulation, and much more.
Replace your original compiler piece by piece, and see how easy your
language is to work with.  Pay attention to the tasks that are painful
or repetitive, and evolve you language to make those tasks easier.

From ofv at wanadoo.es  Tue Sep 15 09:50:23 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 15 Sep 2009 16:50:23 +0200
Subject: [LLVMdev] IDE on *nix
References: <d9b9d95f0909120154m217217c2g908a42be2c3e42cb@mail.gmail.com>
	<4AAF2E45.1050609@illinois.edu>
	<d9b9d95f0909150222u4e887b7fr80bcf82b3e1436c4@mail.gmail.com>
Message-ID: <87ocpcntxs.fsf@telefonica.net>

Renato Golin <rengolin at systemcall.org> writes:

>> cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug"
>> -DBUILD_SHARED_LIBS=ON -DLLVM_TARGETS_TO_BUILD="X86;PowerPC;CBackend"
>> /home/renato/llvm-sources
>
> Thanks Patrick, I'll give it a try.
>
> At least now I know that it can be done. My previous attempts all
> ended up in memory depletion during the indexing. ;)
>
> I'll check the archives...

This can be useful too:

http://www.llvm.org/docs/CMake.html

-- 
?scar


From ofv at wanadoo.es  Tue Sep 15 09:55:44 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 15 Sep 2009 16:55:44 +0200
Subject: [LLVMdev] LLVM Beginner Question
References: <A3A43566-CBB1-47D0-A537-DA157A4767A1@gmail.com>
Message-ID: <87k500ntov.fsf@telefonica.net>

Graham Hemingway <graham.hemingway at gmail.com> writes:

> I am just getting started with LLVM and am having some build issues.
> I am running Snow Leopard and like to use XCode as my IDE.  I know
> that I need to compile with llvm-config to get all of the proper build
> settings.  My question is how do I incorporate llvm-config into my
> XCode project settings?  I would prefer to not have to use the command
> line to build.

Generate the XCode project with cmake. See

http://www.llvm.org/docs/CMake.html

-- 
?scar


From tomas.l.olsen at gmail.com  Tue Sep 15 09:57:52 2009
From: tomas.l.olsen at gmail.com (Tomas Lindquist Olsen)
Date: Tue, 15 Sep 2009 16:57:52 +0200
Subject: [LLVMdev] merge request for 2.6
Message-ID: <7aa9f8a40909150757p73127496x26bdc441e86b8329@mail.gmail.com>

For 2.6 to really be a useful, we need this bug fixed:

http://llvm.org/bugs/show_bug.cgi?id=4963

Would it be possible to get this merged into 2.6?

-Tomas

From ofv at wanadoo.es  Tue Sep 15 09:59:13 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 15 Sep 2009 16:59:13 +0200
Subject: [LLVMdev] C API linking problem
References: <33411.145.100.6.164.1253021649.squirrel@www.assumetheposition.nl>
Message-ID: <87fxaontj2.fsf@telefonica.net>

"Paul Melis" <llvm at assumetheposition.nl> writes:

> 15:29|melis at juggle2:~/c/llvmpy> gcc -W -Wall -o blah `llvm-config --cflags
> --ldflags --libs all` t.c
> /tmp/ccs4MbKp.o: In function `main':
> t.c:(.text+0x21): undefined reference to `LLVMContextCreate'
> collect2: ld returned 1 exit status
>
> 15:29|melis at juggle2:~/c/llvmpy> nm ~/llvm/lib/libLLVMCore.a | grep
> LLVMContextCreate
> 00001bc0 T LLVMContextCreate

Try this:

gcc t.c -W -Wall -o blah `llvm-config --cflags --libs all --ldflags`

-- 
?scar


From edwintorok at gmail.com  Tue Sep 15 10:06:22 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Tue, 15 Sep 2009 18:06:22 +0300
Subject: [LLVMdev] IDE on *nix
In-Reply-To: <d9b9d95f0909150222u4e887b7fr80bcf82b3e1436c4@mail.gmail.com>
References: <d9b9d95f0909120154m217217c2g908a42be2c3e42cb@mail.gmail.com>	<4AAF2E45.1050609@illinois.edu>
	<d9b9d95f0909150222u4e887b7fr80bcf82b3e1436c4@mail.gmail.com>
Message-ID: <4AAFAD6E.6070801@gmail.com>

On 2009-09-15 12:22, Renato Golin wrote:
> 2009/9/15 Patrick Simmons <simmon12 at illinois.edu>:
>   
>> cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug"
>> -DBUILD_SHARED_LIBS=ON -DLLVM_TARGETS_TO_BUILD="X86;PowerPC;CBackend"
>> /home/renato/llvm-sources
>>     
>
> Thanks Patrick, I'll give it a try.
>
> At least now I know that it can be done. My previous attempts all
> ended up in memory depletion during the indexing. ;)
>   

Maybe you were hitting this bug?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=253050

Are you using a new enough CDT that has the fix?

Best regards,
--Edwin


From rayfix.ml at gmail.com  Tue Sep 15 10:13:42 2009
From: rayfix.ml at gmail.com (Ray Fix)
Date: Tue, 15 Sep 2009 11:13:42 -0400
Subject: [LLVMdev] LLVM Beginner Question
In-Reply-To: <87k500ntov.fsf@telefonica.net>
References: <A3A43566-CBB1-47D0-A537-DA157A4767A1@gmail.com>
	<87k500ntov.fsf@telefonica.net>
Message-ID: <73631472-1390-497E-B19B-4BC3777D9C6F@gmail.com>

On Sep 15, 2009, at 10:55 AM, ?scar Fuentes wrote:

> Graham Hemingway <graham.hemingway at gmail.com> writes:
>
>> I am just getting started with LLVM and am having some build issues.
>> I am running Snow Leopard and like to use XCode as my IDE.  I know
>> that I need to compile with llvm-config to get all of the proper  
>> build
>> settings.  My question is how do I incorporate llvm-config into my
>> XCode project settings?  I would prefer to not have to use the  
>> command
>> line to build.
>
> Generate the XCode project with cmake. See
>
> http://www.llvm.org/docs/CMake.html


You will want to do:

mkdir my-llvm-project-dir
cd my-llvm-project-dir

cmake -G Xcode path/to/llvm/source/root

open LLVM.xcodeproj

If you don't specify -G Xcode it will default to a make style project.

Ray

PS:  BTW, I guess it is technically written Xcode, not XCode.  The  
command  might be case sensitive.
PPS: Someone should add the -G Xcode (and possibly other example  
targets to) example to the CMake.html doc.

From llvm at assumetheposition.nl  Tue Sep 15 10:25:12 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Tue, 15 Sep 2009 17:25:12 +0200 (CEST)
Subject: [LLVMdev] C API linking problem
In-Reply-To: <87fxaontj2.fsf@telefonica.net>
References: <33411.145.100.6.164.1253021649.squirrel@www.assumetheposition.nl>
	<87fxaontj2.fsf@telefonica.net>
Message-ID: <49750.145.100.6.164.1253028312.squirrel@www.assumetheposition.nl>

?scar Fuentes wrote:
> "Paul Melis" <llvm at assumetheposition.nl> writes:
>
>> 15:29|melis at juggle2:~/c/llvmpy> gcc -W -Wall -o blah `llvm-config
>> --cflags
>> --ldflags --libs all` t.c
>> /tmp/ccs4MbKp.o: In function `main':
>> t.c:(.text+0x21): undefined reference to `LLVMContextCreate'
>> collect2: ld returned 1 exit status
>>
>> 15:29|melis at juggle2:~/c/llvmpy> nm ~/llvm/lib/libLLVMCore.a | grep
>> LLVMContextCreate
>> 00001bc0 T LLVMContextCreate
>
> Try this:
>
> gcc t.c -W -Wall -o blah `llvm-config --cflags --libs all --ldflags`

Thanks! Moving t.c to the front of the command-line fixes it (although
--ldflags still needs to go before --libs in the above line). And I need
to link with g++ instead of gcc.

I guess I didn't figure this one out because when you normally manually
specify libraries they always go *after* the source file argument.
Splitting the llvm-config call into a cxxflags and a --libs/--ldflags part
and putting the sources in between is probably cleaner in this respect.

Paul


From ofv at wanadoo.es  Tue Sep 15 10:27:12 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar?= Fuentes)
Date: Tue, 15 Sep 2009 17:27:12 +0200
Subject: [LLVMdev] C API linking problem
In-Reply-To: <60175.145.100.6.164.1253026973.squirrel@www.assumetheposition.nl>
	(Paul Melis's message of "Tue, 15 Sep 2009 17:02:53 +0200 (CEST)")
References: <33411.145.100.6.164.1253021649.squirrel@www.assumetheposition.nl>
	<87fxaontj2.fsf@telefonica.net>
	<60175.145.100.6.164.1253026973.squirrel@www.assumetheposition.nl>
Message-ID: <87bplcns8f.fsf@telefonica.net>

"Paul Melis" <llvm at assumetheposition.nl> writes:

>>> 15:29|melis at juggle2:~/c/llvmpy> gcc -W -Wall -o blah `llvm-config
>>> --cflags
>>> --ldflags --libs all` t.c
>>> /tmp/ccs4MbKp.o: In function `main':
>>> t.c:(.text+0x21): undefined reference to `LLVMContextCreate'
>>> collect2: ld returned 1 exit status
>>>
>>> 15:29|melis at juggle2:~/c/llvmpy> nm ~/llvm/lib/libLLVMCore.a | grep
>>> LLVMContextCreate
>>> 00001bc0 T LLVMContextCreate
>>
>> Try this:
>>
>> gcc t.c -W -Wall -o blah `llvm-config --cflags --libs all --ldflags`
>
> Are you sure that's what you meant? Now the linker can't find anything
> anymore and I get tons of unresolved symbols.

That is because -L comes after the LLVM libraries.

Try

gcc t.c -W -Wall -o blah `llvm-config --cflags --ldflags --libs all`

However, if your linker is sensitive to library order, you may get
unresolved externals for -lpthread and other system libraries that
are list before the LLVM libraries on the llvm-config output.

If that happens try

gcc t.c -W -Wall -o blah -L/home/melis/llvm/lib `llvm-config --cflags --libs all --ldflags`

HTH.

-- 
?scar


From ofv at wanadoo.es  Tue Sep 15 10:31:07 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 15 Sep 2009 17:31:07 +0200
Subject: [LLVMdev] LLVM Beginner Question
References: <A3A43566-CBB1-47D0-A537-DA157A4767A1@gmail.com>
	<87k500ntov.fsf@telefonica.net>
	<73631472-1390-497E-B19B-4BC3777D9C6F@gmail.com>
Message-ID: <877hw0ns1w.fsf@telefonica.net>

Ray Fix <rayfix.ml at gmail.com> writes:

>> Generate the XCode project with cmake. See
>>
>> http://www.llvm.org/docs/CMake.html

[snip]

> PPS: Someone should add the -G Xcode (and possibly other example  
> targets to) example to the CMake.html doc.

The document explains how to list the available generators. It mentions
that generator's names are case-sensitive too.

-- 
?scar


From kennethuil at gmail.com  Tue Sep 15 10:32:00 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 15 Sep 2009 10:32:00 -0500
Subject: [LLVMdev] struct returns
Message-ID: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>

In the latest snapshot from SVN on X86, llc refuses to compile
functions returning structs larger than two i32 members.

According to the docs, such limitations can be expected to exist on
other platforms.

This leads to a number of questions and observations:

1. Is there a good way to retrieve the current target limitations on
struct return sizes?

2. The sretpromotion pass does not take struct size limitations into
account; it will happily convert an sret parameter with five members
into a return value that llc chokes on.

3. There is no sretdemotion pass.

4. If the answer to #1 is "no", perhaps we need platform-specific
sretpromotion and sretdemotion passes to allow small struct returns to
happen efficiently while large struct returns can be successfully
codegen'd, all without having to build such platform-specific
knowledge into all front-ends.

From dag at cray.com  Tue Sep 15 10:35:57 2009
From: dag at cray.com (David Greene)
Date: Tue, 15 Sep 2009 10:35:57 -0500
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
Message-ID: <200909151035.58610.dag@cray.com>

On Tuesday 15 September 2009 08:16, Olivier Meurant wrote:

> llvm-gcc -v
> Using built-in specs.
> Target: i686-pc-linux-gnu

>
> gcc -v
> Using built-in specs.
> Target: i486-linux-gnu

Different targets.  It's no surprise 486 code would perform much worse than 
i686 code.  These compilers need to target the same architecture.  Ideally the 
Makefile would include appropriate -march/-mtune/whatever the gcc architecture 
switch of the day is.

All test reports should also include switches passed to the compiler for each 
run.

Right now this isn't a fair test.  It's practically meaningless.

Remember, the goal here isn't to show how great LLVM is.  It's to get an 
honest assessment of where we are at.  Phoronix did us a big favor.  Getting
more details about his tests would help us even more.

For one thing, we (Cray) have a number of LLVM enhancements geared toward 
Opteron that make a big difference in performance.  I'm planning to contribute 
much of this to our open source community.  So there is definitely room for 
improvement to LLVM.  The biggest mistake we can make is to think we're the 
best.

                                 -Dave

From rayfix.ml at gmail.com  Tue Sep 15 10:54:36 2009
From: rayfix.ml at gmail.com (Ray Fix)
Date: Tue, 15 Sep 2009 11:54:36 -0400
Subject: [LLVMdev] LLVM Beginner Question
In-Reply-To: <877hw0ns1w.fsf@telefonica.net>
References: <A3A43566-CBB1-47D0-A537-DA157A4767A1@gmail.com>
	<87k500ntov.fsf@telefonica.net>
	<73631472-1390-497E-B19B-4BC3777D9C6F@gmail.com>
	<877hw0ns1w.fsf@telefonica.net>
Message-ID: <A4DDDE21-04B6-494C-8699-1B3DC3D41DF5@gmail.com>

On Sep 15, 2009, at 11:31 AM, ?scar Fuentes wrote:
>
>> PPS: Someone should add the -G Xcode (and possibly other example
>> targets to) example to the CMake.html doc.
>
> The document explains how to list the available generators. It  
> mentions
> that generator's names are case-sensitive too.
>

Ah, ic.  My apologies.  I followed the first step of the getting  
started guide, "Read the documentation." But then I forgot to follow  
the second step, "Read the documentation." ;-)

Thanks.
Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090915/3fa93e1e/attachment.html 

From rengolin at systemcall.org  Tue Sep 15 11:04:10 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Tue, 15 Sep 2009 17:04:10 +0100
Subject: [LLVMdev] IDE on *nix
In-Reply-To: <4AAFAD6E.6070801@gmail.com>
References: <d9b9d95f0909120154m217217c2g908a42be2c3e42cb@mail.gmail.com>
	<4AAF2E45.1050609@illinois.edu>
	<d9b9d95f0909150222u4e887b7fr80bcf82b3e1436c4@mail.gmail.com>
	<4AAFAD6E.6070801@gmail.com>
Message-ID: <d9b9d95f0909150904t24263db8g70f7cf59423cd6ee@mail.gmail.com>

2009/9/15 T?r?k Edwin <edwintorok at gmail.com>:
> Maybe you were hitting this bug?
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=253050

hum... that sounds familiar... ;)


> Are you using a new enough CDT that has the fix?

I wasn't (3.2) but now I am (galileo), will give it another try.


thanks!
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From luoyonggang at gmail.com  Tue Sep 15 11:07:06 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Wed, 16 Sep 2009 00:07:06 +0800
Subject: [LLVMdev] Replace gcc with llvm-gcc
In-Reply-To: <1252996519.8385.3.camel@UIUC>
References: <mailman.207.1252977404.11840.llvmdev@cs.uiuc.edu>
	<1252996519.8385.3.camel@UIUC>
Message-ID: <806065d90909150907o1d07f65agc72c6f8ff27f7d1b@mail.gmail.com>

Just set llvm-ld as the default ld .
Such as LD = llvm-ld in makefile, if it's not working, then there is no solution

2009/9/15, zhunan <zhunansjtu at gmail.com>:
> I truly get the bytecode file for each souce file,but can I use
> llvm-link to link them into a whole-program one automatically through
> some scripts?
>
>
>>
>> Message: 27
>> Date: Tue, 15 Sep 2009 03:16:10 +0200
>> From: ?scar Fuentes <ofv at wanadoo.es>
>> Subject: Re: [LLVMdev] Replace gcc with llvm-gcc???
>> To: llvmdev at cs.uiuc.edu
>> Message-ID: <87vdjlnh2d.fsf at telefonica.net>
>> Content-Type: text/plain; charset=windows-1252
>>
>> zhunan <zhunansjtu at gmail.com> writes:
>>
>> > Recently I met a question when I want to replace gcc with llvm-gcc
>> > through configure script(command).
>> >
>> > For simply,described like that
>> >
>> > I typed as following
>> >
>> > 1.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-S
>> > -emit-llvm"
>> >
>> > configure will failed when it checks whether C compiler is working
>> >
>> > 2.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-c
>> > -emit-llvm"
>> >
>> > configure will failed when it checks the default output filename,just
>> > means the C compiler cannot create executables.
>> >
>> >
>> > I would like to know what's the matter with this replacing attempt?and
>> > any possibility to overcome the trouble?
>>
>> Your CFLAGS is telling llvm-gcc that it must not produce an object code
>> file nor an executable file, but something else (llvm assembler on your
>> first attempt and llvm bitcode on your second attempt).
>>
>> `configure' needs a fully working compiler toolset, which means that the
>> compiler must be able to produce executable files. Your CFLAGS setting
>> is preventing this.
>>
>> Execute `configure' with just CC=llvm-gcc and then try
>>
>> make CFLAGS="-emit-llvm"
>>
>> if you want LLVM bitcode or
>>
>> make CFLAGS="-S -emit-llvm"
>>
>> if you want LLVM assembler.
>>
>> `make' will fail at the linking phase, but you will have a set of LLVM
>> bitcode/assembler files for each of your C source files.
>>
>> If you simply want to replace gcc with llvm-gcc for building your
>> software, forget about CFLAGS and just do
>>
>> ./configure CC=llvm-gcc && make
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From luoyonggang at gmail.com  Tue Sep 15 11:24:43 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Wed, 16 Sep 2009 00:24:43 +0800
Subject: [LLVMdev] An nice advertisement for llvm-gcc.
Message-ID: <806065d90909150924r52626291mdc14ed2abc88ece8@mail.gmail.com>

We know if we add -emit-llvm option to llvm-gcc will deduce emit bc
code, but the problem once  llvm-gcc as the linker in some configure
system, it's will call the default ld in default and have no idea to
change this, maybe we can set the default linker as llvm-ld once
-emit-llvm as the option of gcc.  And we can't just rename llvm-ld as
ld because. llvm-ld will call binutils ld. So we can make llvm-gcc
more like gcc even if emit-llvm. By the way,   llvm-ld can't recognize
the options -pthread, it's an weak to compile some project. Such as
amaya
And also we can make the same modification on llvm-g++:) and so on.

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From luoyonggang at gmail.com  Tue Sep 15 11:28:07 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Wed, 16 Sep 2009 00:28:07 +0800
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <200909151035.58610.dag@cray.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
	<200909151035.58610.dag@cray.com>
Message-ID: <806065d90909150928w34aa87d6x4badf24fca021701@mail.gmail.com>

Wow, that's beautiful: and thanks

2009/9/15, David Greene <dag at cray.com>:
> On Tuesday 15 September 2009 08:16, Olivier Meurant wrote:
>
>> llvm-gcc -v
>> Using built-in specs.
>> Target: i686-pc-linux-gnu
>
>>
>> gcc -v
>> Using built-in specs.
>> Target: i486-linux-gnu
>
> Different targets.  It's no surprise 486 code would perform much worse than
> i686 code.  These compilers need to target the same architecture.  Ideally
> the
> Makefile would include appropriate -march/-mtune/whatever the gcc
> architecture
> switch of the day is.
>
> All test reports should also include switches passed to the compiler for
> each
> run.
>
> Right now this isn't a fair test.  It's practically meaningless.
>
> Remember, the goal here isn't to show how great LLVM is.  It's to get an
> honest assessment of where we are at.  Phoronix did us a big favor.  Getting
> more details about his tests would help us even more.
>
> For one thing, we (Cray) have a number of LLVM enhancements geared toward
> Opteron that make a big difference in performance.  I'm planning to
> contribute
> much of this to our open source community.  So there is definitely room for
> improvement to LLVM.  The biggest mistake we can make is to think we're the
> best.
>
>                                  -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From viridia at gmail.com  Tue Sep 15 11:32:00 2009
From: viridia at gmail.com (Talin)
Date: Tue, 15 Sep 2009 09:32:00 -0700
Subject: [LLVMdev] My LLVM Project
In-Reply-To: <d9b9d95f0909150206oe819eb7m3f2541a5eefce20c@mail.gmail.com>
References: <4AAF080A.2090201@acm.org>
	<d9b9d95f0909150206oe819eb7m3f2541a5eefce20c@mail.gmail.com>
Message-ID: <4AAFC180.2050604@gmail.com>

Renato Golin wrote:
> 2009/9/15 Talin <talin at acm.org>:
>   
>> For example, here's what the "Iterator" interface looks like:
>>
>>   interface Iterator[%T] {
>>     def next -> T or void;
>>   }
>>     
>
> So this would be something like:
>
> template <class T>
> virtual class Iterator {
>   T next(); // or void?
> };
>
> So the power of having two types of return parameters is that you save
> function calls (hasNext())?
>   
There are other benefits as well. Having disjoint types makes library 
APIs cleaner - often a function will need to return either a result, or 
an error code. In C++, this has to be handled either via a reference 
parameter (which is inefficient because the compiler's live variable 
analysis can't determine if the value was assigned or not) or by 
returning a struct.
>>   def sum(nums:int...) -> int {
>>     var sum = 0;
>>     for i in nums {
>>       sum += i;
>>     }
>>     return sum;
>>   }
>>     
>
> I see you don't have types for variables, only for containers,
> templates and functions. And yet you say your language is
> statically-typed. If you do:
>   
The type of a variable is optional - if omitted, it is deduced from the 
initializer.
> var foo = 10; // I'd presume it's an int
> foo /= 3;
>
> Would foo become a float?
>
> foo /= 1e200;
>
> Would it become a double?
>
> What happens if you pass foo as an int, and inside the function it
> becomes a double (without your consent, by a combination of
> parameters) and you try to return it as an int?
>
>
>   
>> 'classify' is like a switch statement, except that the cases are types
>> rather than values. It works with both disjoint types and polymorphic
>> types, similar to what is seen in Scala and various functional languages
>> such as OCaml. The variables in the individual 'as' clauses are never in
>> scope unless the assignment to that variable actually succeeds, so
>> there's no chance of seeing an uninitialized variable.
>>     
>
> Is it run-time or compile-time? The former is Java's insanceof/C++
> RTTI, the later has not many uses...
>
>   
It's like Java's "instanceof", i.e. a runtime type test.
>> In any case, I don't want to go on about this too long - at least not
>> until the compiler is in better shape to be shown to the world. I still
>> need to work on closures, reflection, garbage collection, interface
>> proxies, stack dumps, debug info, and a bunch of other stuff. (There's a
>> Google code project for it, but I'm not encouraging people to go there
>> until I have more of the language finished.)
>>     
>
> I think it's great to write compilers to learn how languages work (I'm
> doing my own too).
>
> My points about the language:
>
> First, It's much more like a cross between Python/Perl and Java than
> C++. It's not strongly typed and yet it use generic programming. As
> long as it's not creating *types* with templates (like C++) but
> creating only generic algorithms (like Java), it's ok.
>   
It's not meant to "look" like C++ - it's meant to occupy the same 
ecological niche. I have many years of experience programming in Java, 
C# and Python, and I'm happy using those languages to write things like 
web servers and desktop applications. But there are some tasks which I 
*wouldn't* use those languages for - XBox games, MPEG decoders, 
AudioUnits, signal processing, and so on. For those kinds of tasks, I 
would normally use C++ - but over the years I have collected hundreds of 
gripes with C++, which I'd like to fix.
> It has too much syntactic sugar and names changed for no apparent
> reason, it drives the user away from using your language. A good deal
> of Java's success is because they used a syntax very similar to C++.
>
> My (very personal) point of view is that, if you're not bringing
> anything new, help the others that are instead of re-inventing the
> wheel. But again, if your point is (as mine) to learn, well done! It's
> much better than my own language! ;)
>
>   
I've only shown a small part of what I have. This forum is not the place 
for language advocacy, I don't want to start a discussion on the merits 
of my language or any other. I'm absolutely convinced that I have 
something to contribute, and I'm going to forge ahead despite the 
naysayers :)

Mainly, I just wanted to share with the LLVM community how I am using 
LLVM, and I don't want the topic to stray too far from that.
> cheers,
> --renato
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
>
> _______________________________________________
> 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 Sep 15 11:41:33 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Tue, 15 Sep 2009 11:41:33 -0500
Subject: [LLVMdev] Replace gcc with llvm-gcc
In-Reply-To: <806065d90909150907o1d07f65agc72c6f8ff27f7d1b@mail.gmail.com>
References: <mailman.207.1252977404.11840.llvmdev@cs.uiuc.edu>	<1252996519.8385.3.camel@UIUC>
	<806065d90909150907o1d07f65agc72c6f8ff27f7d1b@mail.gmail.com>
Message-ID: <4AAFC3BD.7060206@cs.uiuc.edu>

???(Yonggang Luo) wrote:
> Just set llvm-ld as the default ld .
> Such as LD = llvm-ld in makefile, if it's not working, then there is no solution
>   
Some Makefiles use the C compiler (e.g., gcc or llvm-gcc) as the
linker.  For such Makefiles, the above will not work because llvm-gcc
runs ld.  What you need is a linker that can link LLVM bitcode files
together.

If that is the case, then an alternative is to use the LLVM plugin for
the gold linker (http://llvm.org/docs/GoldPlugin.html).  If gold is your
system linker (or you can make llvm-gcc use it instead of ld), then (I
believe) you can get the Makefiles to transparently link LLVM bitcode
files together into a single bitcode file.

The above is for Linux.  On Mac OS X, I think the linker with Xcode can
link bitcode files together, but I'm not sure.

Please note that I haven't tried this myself yet; it's one of the things
I will try the next time I need to create a single bitcode file for an
executable.

-- John T.

> 2009/9/15, zhunan <zhunansjtu at gmail.com>:
>   
>> I truly get the bytecode file for each souce file,but can I use
>> llvm-link to link them into a whole-program one automatically through
>> some scripts?
>>
>>
>>     
>>> Message: 27
>>> Date: Tue, 15 Sep 2009 03:16:10 +0200
>>> From: ?scar Fuentes <ofv at wanadoo.es>
>>> Subject: Re: [LLVMdev] Replace gcc with llvm-gcc???
>>> To: llvmdev at cs.uiuc.edu
>>> Message-ID: <87vdjlnh2d.fsf at telefonica.net>
>>> Content-Type: text/plain; charset=windows-1252
>>>
>>> zhunan <zhunansjtu at gmail.com> writes:
>>>
>>>       
>>>> Recently I met a question when I want to replace gcc with llvm-gcc
>>>> through configure script(command).
>>>>
>>>> For simply,described like that
>>>>
>>>> I typed as following
>>>>
>>>> 1.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-S
>>>> -emit-llvm"
>>>>
>>>> configure will failed when it checks whether C compiler is working
>>>>
>>>> 2.zhunan at sjtu:~/workplace/$ ./configure CC=llvm-gcc CFLAGS="-c
>>>> -emit-llvm"
>>>>
>>>> configure will failed when it checks the default output filename,just
>>>> means the C compiler cannot create executables.
>>>>
>>>>
>>>> I would like to know what's the matter with this replacing attempt?and
>>>> any possibility to overcome the trouble?
>>>>         
>>> Your CFLAGS is telling llvm-gcc that it must not produce an object code
>>> file nor an executable file, but something else (llvm assembler on your
>>> first attempt and llvm bitcode on your second attempt).
>>>
>>> `configure' needs a fully working compiler toolset, which means that the
>>> compiler must be able to produce executable files. Your CFLAGS setting
>>> is preventing this.
>>>
>>> Execute `configure' with just CC=llvm-gcc and then try
>>>
>>> make CFLAGS="-emit-llvm"
>>>
>>> if you want LLVM bitcode or
>>>
>>> make CFLAGS="-S -emit-llvm"
>>>
>>> if you want LLVM assembler.
>>>
>>> `make' will fail at the linking phase, but you will have a set of LLVM
>>> bitcode/assembler files for each of your C source files.
>>>
>>> If you simply want to replace gcc with llvm-gcc for building your
>>> software, forget about CFLAGS and just do
>>>
>>> ./configure CC=llvm-gcc && make
>>>
>>>       
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>     
>
>   




From Dr.Graef at t-online.de  Tue Sep 15 11:42:05 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Tue, 15 Sep 2009 18:42:05 +0200
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <7aa9f8a40909150757p73127496x26bdc441e86b8329@mail.gmail.com>
References: <7aa9f8a40909150757p73127496x26bdc441e86b8329@mail.gmail.com>
Message-ID: <4AAFC3DD.3060707@t-online.de>

Tomas Lindquist Olsen wrote:
> For 2.6 to really be a useful, we need this bug fixed:
> 
> http://llvm.org/bugs/show_bug.cgi?id=4963
> 
> Would it be possible to get this merged into 2.6?

While we're at it, what about:

http://llvm.org/bugs/show_bug.cgi?id=3239

This is a real nuisance, as people regularly build LLVM in a way
(--enable-pic, which even is the default now) which makes the JIT create
wrong code on x86-32. I've seen this on Ubuntu and Fedora Core 10
(thankfully Michel Salim has fixed the FC LLVM packages now).

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 edwintorok at gmail.com  Tue Sep 15 11:52:53 2009
From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=)
Date: Tue, 15 Sep 2009 19:52:53 +0300
Subject: [LLVMdev] Replace gcc with llvm-gcc
In-Reply-To: <4AAFC3BD.7060206@cs.uiuc.edu>
References: <mailman.207.1252977404.11840.llvmdev@cs.uiuc.edu>	<1252996519.8385.3.camel@UIUC>	<806065d90909150907o1d07f65agc72c6f8ff27f7d1b@mail.gmail.com>
	<4AAFC3BD.7060206@cs.uiuc.edu>
Message-ID: <4AAFC665.2080206@gmail.com>

On 2009-09-15 19:41, John Criswell wrote:
> ???(Yonggang Luo) wrote:
>   
>> Just set llvm-ld as the default ld .
>> Such as LD = llvm-ld in makefile, if it's not working, then there is no solution
>>   
>>     
> Some Makefiles use the C compiler (e.g., gcc or llvm-gcc) as the
> linker.  For such Makefiles, the above will not work because llvm-gcc
> runs ld.  What you need is a linker that can link LLVM bitcode files
> together.
>   

It is called CCLD/CXXLD for automake generated makefiles.

Best regards,
--Edwin


From gohman at apple.com  Tue Sep 15 11:55:37 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 15 Sep 2009 09:55:37 -0700
Subject: [LLVMdev] struct returns
In-Reply-To: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
Message-ID: <FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>


On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote:

> In the latest snapshot from SVN on X86, llc refuses to compile
> functions returning structs larger than two i32 members.
>
> According to the docs, such limitations can be expected to exist on
> other platforms.
>
> This leads to a number of questions and observations:
>
> 1. Is there a good way to retrieve the current target limitations on
> struct return sizes?

No.  The information can be inferred from what's in the *CallingConv.td
files, though there are currently no utilities specifically for this.

> 2. The sretpromotion pass does not take struct size limitations into
> account; it will happily convert an sret parameter with five members
> into a return value that llc chokes on.
>
> 3. There is no sretdemotion pass.
>
> 4. If the answer to #1 is "no", perhaps we need platform-specific
> sretpromotion and sretdemotion passes to allow small struct returns to
> happen efficiently while large struct returns can be successfully
> codegen'd, all without having to build such platform-specific
> knowledge into all front-ends.

Sure. Alternatively, we could fix codegen to do this itself.  I'd be
happy to help anyone interested in working on this.

I recently made a major reorganization of the calling-convention
lowering code which cleared away one of the major obstacles to
doing this within codegen.

Dan


From baldrick at free.fr  Tue Sep 15 12:09:27 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 15 Sep 2009 19:09:27 +0200
Subject: [LLVMdev] An nice advertisement for llvm-gcc.
In-Reply-To: <806065d90909150924r52626291mdc14ed2abc88ece8@mail.gmail.com>
References: <806065d90909150924r52626291mdc14ed2abc88ece8@mail.gmail.com>
Message-ID: <4AAFCA47.7040202@free.fr>

http://llvm.org/docs/GoldPlugin.html

From kennethuil at gmail.com  Tue Sep 15 12:10:47 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 15 Sep 2009 12:10:47 -0500
Subject: [LLVMdev] struct returns
In-Reply-To: <FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
	<FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
Message-ID: <400d33ea0909151010t3f340c76ob99bc82726cf9826@mail.gmail.com>

On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote:
>
> On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote:
>
>> In the latest snapshot from SVN on X86, llc refuses to compile
>> functions returning structs larger than two i32 members.
>>
>> According to the docs, such limitations can be expected to exist on
>> other platforms.
>>
>> This leads to a number of questions and observations:
>>
>> 1. Is there a good way to retrieve the current target limitations on
>> struct return sizes?
>
> No. ?The information can be inferred from what's in the *CallingConv.td
> files, though there are currently no utilities specifically for this.
>
>> 2. The sretpromotion pass does not take struct size limitations into
>> account; it will happily convert an sret parameter with five members
>> into a return value that llc chokes on.
>>
>> 3. There is no sretdemotion pass.
>>
>> 4. If the answer to #1 is "no", perhaps we need platform-specific
>> sretpromotion and sretdemotion passes to allow small struct returns to
>> happen efficiently while large struct returns can be successfully
>> codegen'd, all without having to build such platform-specific
>> knowledge into all front-ends.
>
> Sure. Alternatively, we could fix codegen to do this itself. ?I'd be
> happy to help anyone interested in working on this.
>
> I recently made a major reorganization of the calling-convention
> lowering code which cleared away one of the major obstacles to
> doing this within codegen.
>
> Dan

That would be even better.  I suppose codegen would have to do
something like the sret parameter demotion when the number of members
exceeds the number of available registers?  Or did you have something
else in mind?

Fixing this would make my front-end noticeably simpler, and would
probably benefit other front-ends as well, so I'd be willing to spend
some time on it.


From clattner at apple.com  Tue Sep 15 12:19:05 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 15 Sep 2009 10:19:05 -0700
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <7aa9f8a40909150757p73127496x26bdc441e86b8329@mail.gmail.com>
References: <7aa9f8a40909150757p73127496x26bdc441e86b8329@mail.gmail.com>
Message-ID: <D27B4971-E9D0-4E04-B7A0-F0D8552F9B25@apple.com>

On Sep 15, 2009, at 7:57 AM, Tomas Lindquist Olsen wrote:

> For 2.6 to really be a useful, we need this bug fixed:
>
> http://llvm.org/bugs/show_bug.cgi?id=4963
>
> Would it be possible to get this merged into 2.6?

I requested it to be merged in, thanks.

-Chris

From llvm at assumetheposition.nl  Tue Sep 15 12:22:43 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Tue, 15 Sep 2009 19:22:43 +0200
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <4AAFC3DD.3060707@t-online.de>
References: <7aa9f8a40909150757p73127496x26bdc441e86b8329@mail.gmail.com>
	<4AAFC3DD.3060707@t-online.de>
Message-ID: <4AAFCD63.4070804@assumetheposition.nl>

Albert Graef wrote:
> Tomas Lindquist Olsen wrote:
>   
>> For 2.6 to really be a useful, we need this bug fixed:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=4963
>>
>> Would it be possible to get this merged into 2.6?
>>     
>
> While we're at it, what about:
>
> http://llvm.org/bugs/show_bug.cgi?id=3239
>
> This is a real nuisance, as people regularly build LLVM in a way
> (--enable-pic, which even is the default now) which makes the JIT create
> wrong code on x86-32. I've seen this on Ubuntu and Fedora Core 10
> (thankfully Michel Salim has fixed the FC LLVM packages now).
>   
I think this one is fixed already in TOT.

Paul


From anton at korobeynikov.info  Tue Sep 15 12:24:32 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 15 Sep 2009 21:24:32 +0400
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <4AAFC3DD.3060707@t-online.de>
References: <7aa9f8a40909150757p73127496x26bdc441e86b8329@mail.gmail.com>
	<4AAFC3DD.3060707@t-online.de>
Message-ID: <b087fca00909151024p18414df5g98e86e2ca82bcffb@mail.gmail.com>

Hello, Albert

> While we're at it, what about:
> http://llvm.org/bugs/show_bug.cgi?id=3239
>
> This is a real nuisance, as people regularly build LLVM in a way
> (--enable-pic, which even is the default now) which makes the JIT create
> wrong code on x86-32. I've seen this on Ubuntu and Fedora Core 10
> (thankfully Michel Salim has fixed the FC LLVM packages now).
This is dup of PR3801. Much better fix (as attached to PR) was already
integrated into 2.6 & mainline.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From devang.patel at gmail.com  Tue Sep 15 12:33:51 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Tue, 15 Sep 2009 10:33:51 -0700
Subject: [LLVMdev] Dear LLVM,
In-Reply-To: <tencent_4426E30E70E2E0470808713E@qq.com>
References: <tencent_4426E30E70E2E0470808713E@qq.com>
Message-ID: <352a1fb20909151033w787eea12sc4e919473456d248@mail.gmail.com>

 http://llvm.org/docs/CodeGenerator.html
 http://llvm.org/docs/WritingAnLLVMBackend.html

-
Devang
2009/9/14 Shengn   Wang <wansheg at gmail.com>:
> can?you?give?a?detail?description?about?the?target?architecture?
>
>
> ------------------?Original?------------------
> From: "XU Xinfeng"<xu.xinfeng at gatech.edu>;
> Date: 2009?9?15?(???) ??7:34
> To: "llvmdev"<llvmdev at cs.uiuc.edu>;
> Subject: [LLVMdev] Dear LLVM,
>
> Dear LLVM,
>
> Now, I have to design special complier for my own multicore microprocessor
> with cusomized instruction-set and optimized architecture.
>
> After have read a lot of papers about LLVM--a retargettable compiler
> framework, I still can't catch it clearly how to make LLVM support my
> target.
>
> Would you please give me some necessary instructions or advice? Thanks!
>
>
> Robinson Xu
> ECE of Gatech
> _______________________________________________
> 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
>
>



-- 
-
Devang


From carlos.delalama at urjc.es  Tue Sep 15 12:59:28 2009
From: carlos.delalama at urjc.es (=?ISO-8859-1?Q?Carlos_S=E1nchez_de_La_Lama?=)
Date: Tue, 15 Sep 2009 19:59:28 +0200
Subject: [LLVMdev] Opaque types in function parameters
Message-ID: <FA6652EF-05DF-4395-984C-959126DE5DAF@urjc.es>

Hi all,

I am creating a function and trying to call it using the LLVM API. It  
seems that whenever the function type includes an opaque-typed  
parameter, the CallInst::Create call causes an assert:

Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)  
== Params[i]->getType()) && "Calling a function with a bad  
signature!"), function init, file /usr/home/csanchez/shared/prj/tce/ 
src/llvm-2.5/lib/VMCore/Instructions.cpp, line 294.

If I change the code so the function type has only non-opaque types,  
everything is correct. Of course, the parameters passed to the  
function are correct (I call with either an opaque parameter or an  
integer parameter, to match function type). According to the assert,  
I would say an opaque type always compares to false (even with  
another opaque), but this does not make much sense I do not see such  
in the source. I am using llvm-2.5

Does anybody find an explanation for this?

Thanks a lot,

Carlos

From kennethuil at gmail.com  Tue Sep 15 13:05:33 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 15 Sep 2009 13:05:33 -0500
Subject: [LLVMdev] Opaque types in function parameters
In-Reply-To: <FA6652EF-05DF-4395-984C-959126DE5DAF@urjc.es>
References: <FA6652EF-05DF-4395-984C-959126DE5DAF@urjc.es>
Message-ID: <400d33ea0909151105s5b4e9972jc6cf85a149cd9ee1@mail.gmail.com>

2009/9/15 Carlos S?nchez de La Lama <carlos.delalama at urjc.es>:
> Hi all,
>
> I am creating a function and trying to call it using the LLVM API. It
> seems that whenever the function type includes an opaque-typed
> parameter, the CallInst::Create call causes an assert:
>
> Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)
> == Params[i]->getType()) && "Calling a function with a bad
> signature!"), function init, file /usr/home/csanchez/shared/prj/tce/
> src/llvm-2.5/lib/VMCore/Instructions.cpp, line 294.
>
> If I change the code so the function type has only non-opaque types,
> everything is correct. Of course, the parameters passed to the
> function are correct (I call with either an opaque parameter or an
> integer parameter, to match function type). According to the assert,
> I would say an opaque type always compares to false (even with
> another opaque), but this does not make much sense I do not see such
> in the source. I am using llvm-2.5
>
> Does anybody find an explanation for this?
>
> Thanks a lot,
>
> Carlos
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Every time you call OpaqueType::get, you get a distinct opaque type...
they compare unequal.  If you call OpaqueType::get once and store the
result, and use that same instance in declaring your function and in
calling it, it'll match and the assert will go away.

In other words, while there is only one i32 type, and using the API to
fetch it any number of times will always fetch the same one, there can
be an unlimited number of different opaque types... it's up to you to
make sure you're using the same opaque type in situations where you
need them to match, and to make sure you're using different opaque
types in situations where you don't want them to match.

Also, when writing stuff using a single opaque type out to IR, those
uses will come back as using different opaque types unless you gave
your opaque type a name in the module's type symbol table.

(Also, you can't have a parameter or a value of type opaque... it must
be of type pointer-to-opaque.  Opaque is not a first-class type.)


From clattner at apple.com  Tue Sep 15 13:44:48 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 15 Sep 2009 11:44:48 -0700
Subject: [LLVMdev] SCCIterator and unconnected graphs
In-Reply-To: <4AAF4A6F.5080504@elis.UGent.be>
References: <4A9FA563.1030602@elis.UGent.be>
	<5A7CDC28-1A9B-40E0-B0C7-653617889D77@apple.com>
	<4AAF4A6F.5080504@elis.UGent.be>
Message-ID: <DCECE5E6-5BCD-4B5C-8C30-68E799CD8D91@apple.com>


On Sep 15, 2009, at 1:03 AM, Hans Vandierendonck wrote:

> The problem pops up for me because I have a pass based on the  
> CallGraphSCC that computes and caches info on the functions. In a  
> second pass, I query this information by traversing all functions in  
> the module. In the second pass I see a function for which I don't  
> have any info, which is problematic. I should probably run - 
> globaldce before running my passes.
>
> This is probably all about semantics of what should be in the  
> CallGraph and what not.
> I guess I did not expect the CallGraph to be optimized to skip dead  
> functions.
>
>
> So far for the CallGraph.
> If I want to run the SCCIterator on an unconnected graph (for  
> instance, some dependence graph I create myself), would it visit all  
> SCC components? Even though I can identify only one root node via  
> the GraphTraits::getEntryNode()?

Ok, two issues here:

It only makes sense for SCCIterator to visit nodes reachable from the  
graph root.  It can't see any other nodes, so having it visit  
unreachable nodes doesn't make sense.

For CGSCC passes, it could get special case code to visit unreachable  
functions.  However, I think that it is beneficial for CGSCC PassMgr  
to "optimize out" optimizations on unreachable functions.  This means  
that your pass should tolerate this case by checking to see if the  
function was analyzed or not.

This seems exactly analogous to the dominator tree not having nodes  
for blocks that are unreachable in a function.

-Chris

From clattner at apple.com  Tue Sep 15 13:45:28 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 15 Sep 2009 11:45:28 -0700
Subject: [LLVMdev] Registering a MachineFunctionPass to JIT codegen
In-Reply-To: <4AAF3B86.2060405@lip6.fr>
References: <4AAF2C1B.1090509@lip6.fr>
	<60FEDBA1-ABC4-46CD-BB99-990332F61196@apple.com>
	<4AAF3B86.2060405@lip6.fr>
Message-ID: <F974987C-93F5-4E8F-A27B-697082D26F10@apple.com>


On Sep 15, 2009, at 12:00 AM, Nicolas Geoffray wrote:

> Hi Chris,
>
> Chris Lattner wrote:
>> You haven't missed anything, there isn't currently a way to do this.
>>
>
> Good to know. Anything against making the codegen pass manager
> accessible to users? Something like
> ExecutionEngine::getCommonCodegenPassManager() ?

I don't have a problem with that, the interface should be discussed  
though.  You'd want some sort of interface to say "stick this in the  
'before regalloc' bucket" etc.

What do you intend to use this for?

-Chris

From Dr.Graef at t-online.de  Tue Sep 15 15:19:19 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Tue, 15 Sep 2009 22:19:19 +0200
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <b087fca00909151024p18414df5g98e86e2ca82bcffb@mail.gmail.com>
References: <7aa9f8a40909150757p73127496x26bdc441e86b8329@mail.gmail.com>	
	<4AAFC3DD.3060707@t-online.de>
	<b087fca00909151024p18414df5g98e86e2ca82bcffb@mail.gmail.com>
Message-ID: <4AAFF6C7.6050106@t-online.de>

Anton Korobeynikov wrote:
> This is dup of PR3801. Much better fix (as attached to PR) was already
> integrated into 2.6 & mainline.

Hi Anton, that's really good news, thanks!

-- 
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 carlos.delalama at urjc.es  Tue Sep 15 16:42:26 2009
From: carlos.delalama at urjc.es (=?ISO-8859-1?Q?Carlos_S=E1nchez_de_La_Lama?=)
Date: Tue, 15 Sep 2009 23:42:26 +0200
Subject: [LLVMdev] Opaque types in function parameters
In-Reply-To: <400d33ea0909151105s5b4e9972jc6cf85a149cd9ee1@mail.gmail.com>
References: <FA6652EF-05DF-4395-984C-959126DE5DAF@urjc.es> 
	<400d33ea0909151105s5b4e9972jc6cf85a149cd9ee1@mail.gmail.com>
Message-ID: <DDDCB019-758A-40BD-9607-9C2919980FF7@urjc.es>

Ok, this explains my issue :)

Also, I was actually using a pointer-to-opaque at the first place,  
obtaining exact same results. I tested with integers and saw it was  
ok, and then with plain opaques ang get same error as with pointer-to- 
opaques, so when writting to the list I said plain opaques in a try  
to simplify the explanation.

Thanks Kenneth!

Carlos

El 15/09/2009, a las 20:05, Kenneth Uildriks escribi?:

> 2009/9/15 Carlos S?nchez de La Lama <carlos.delalama at urjc.es>:
>> Hi all,
>>
>> I am creating a function and trying to call it using the LLVM API. It
>> seems that whenever the function type includes an opaque-typed
>> parameter, the CallInst::Create call causes an assert:
>>
>> Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)
>> == Params[i]->getType()) && "Calling a function with a bad
>> signature!"), function init, file /usr/home/csanchez/shared/prj/tce/
>> src/llvm-2.5/lib/VMCore/Instructions.cpp, line 294.
>>
>> If I change the code so the function type has only non-opaque types,
>> everything is correct. Of course, the parameters passed to the
>> function are correct (I call with either an opaque parameter or an
>> integer parameter, to match function type). According to the assert,
>> I would say an opaque type always compares to false (even with
>> another opaque), but this does not make much sense I do not see such
>> in the source. I am using llvm-2.5
>>
>> Does anybody find an explanation for this?
>>
>> Thanks a lot,
>>
>> Carlos
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> Every time you call OpaqueType::get, you get a distinct opaque type...
> they compare unequal.  If you call OpaqueType::get once and store the
> result, and use that same instance in declaring your function and in
> calling it, it'll match and the assert will go away.
>
> In other words, while there is only one i32 type, and using the API to
> fetch it any number of times will always fetch the same one, there can
> be an unlimited number of different opaque types... it's up to you to
> make sure you're using the same opaque type in situations where you
> need them to match, and to make sure you're using different opaque
> types in situations where you don't want them to match.
>
> Also, when writing stuff using a single opaque type out to IR, those
> uses will come back as using different opaque types unless you gave
> your opaque type a name in the module's type symbol table.
>
> (Also, you can't have a parameter or a value of type opaque... it must
> be of type pointer-to-opaque.  Opaque is not a first-class type.)



From nicolas.geoffray at lip6.fr  Tue Sep 15 16:54:03 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Tue, 15 Sep 2009 23:54:03 +0200
Subject: [LLVMdev] Registering a MachineFunctionPass to JIT codegen
In-Reply-To: <F974987C-93F5-4E8F-A27B-697082D26F10@apple.com>
References: <4AAF2C1B.1090509@lip6.fr>
	<60FEDBA1-ABC4-46CD-BB99-990332F61196@apple.com>
	<4AAF3B86.2060405@lip6.fr>
	<F974987C-93F5-4E8F-A27B-697082D26F10@apple.com>
Message-ID: <4AB00CFB.1010506@lip6.fr>

Chris Lattner wrote:
>> Something like
>> ExecutionEngine::getCommonCodegenPassManager() ?
>
> I don't have a problem with that, the interface should be discussed 
> though.  You'd want some sort of interface to say "stick this in the 
> 'before regalloc' bucket" etc.
>
> What do you intend to use this for?
>

Actually, we can forget about that in my particular case. I wanted to 
add a pass that gathers the GC information (the GCFunctionInfo object) 
provided by the GCMachineCodeAnalysis pass. However, I didn't realize 
the GCStrategy already has a link to the GCFunctionInfos. So creating an 
interface is not needed anymore for my particular case.

Thanks,
Nicolas

> -Chris


From the.dead.shall.rise at gmail.com  Tue Sep 15 17:22:42 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Wed, 16 Sep 2009 00:22:42 +0200
Subject: [LLVMdev] tblgen bug in handling case , switch_on
In-Reply-To: <4AAC9BDC.2080900@microchip.com>
References: <4AA2B20B.1030903@microchip.com>
	<3cb898890909061449g1eb3723an8fec514fe5eabdfb@mail.gmail.com>
	<4AA8793F.8080503@microchip.com> <4AA88DEB.3090700@microchip.com>
	<3cb898890909100524h7e3658eer24572747d626b47b@mail.gmail.com>
	<4AA93EEB.7060002@microchip.com>
	<3cb898890909101110x3b248a39g9a195507f445a390@mail.gmail.com>
	<4AAA1C59.2010404@microchip.com>
	<3cb898890909110510m596e110do1156512055e36f67@mail.gmail.com>
	<4AAC9BDC.2080900@microchip.com>
Message-ID: <3cb898890909151522h7141d7aeq5d844b353605122c@mail.gmail.com>

Hi,

On Sun, Sep 13, 2009 at 9:14 AM, Sanjiv Gupta
<sanjiv.gupta at microchip.com> wrote:
>
> Thanks for thinking over it.
> On second thoughts, I feel that it isn't right to ask for a feature for
> every such thing. The right way to do this is to fix one's linker itself so
> that it accepts a -l option as such forwarded by the driver.

FWIW, I added this feature to my TODO, though I agree that moving
complexity out of llvmc plugins is a good thing.


-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

From jkh at apple.com  Tue Sep 15 17:58:27 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Tue, 15 Sep 2009 15:58:27 -0700
Subject: [LLVMdev] Status of blocks runtime in compiler-rt?
Message-ID: <94E2D101-57DB-4318-AE15-FF9752FBDDD0@apple.com>

Hi folks,

So, various folks are in the process of porting Grand Central Dispatch  
to FreeBSD (c.f. http://libdispatch.macosforge.org and http://lists.macosforge.org/pipermail/libdispatch-dev 
  for mailing list discussion on the topic) and are making good  
progress, but one of the issues they're running into is support for  
Blocks in FreeBSD.

On the one hand, they could try and back-port the gcc changes from http://www.opensource.apple.com/source/gcc/gcc-5646 
  and solve the problem that way or, on the other hand, they could  
just continue FreeBSD's inexorable march towards Clang and get the  
blocks support as part of compiler-rt.  The only problem seems to be  
that the build support for Blocks in compiler-rt isn't wired up yet,  
which came as something of a surprise to all involved given that  
people have been talking about Clang and Blocks since this summer.

Is there a roadmap for this anywhere that we can read?  If this simply  
has not been done due to a lack of resources, the GCD porting folks  
could perhaps help move this along, assuming they had appropriate  
access to the bits.

Thanks!

- Jordan


From eocallaghan at auroraux.org  Tue Sep 15 18:42:37 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Wed, 16 Sep 2009 00:42:37 +0100
Subject: [LLVMdev] Status of blocks runtime in compiler-rt?
In-Reply-To: <94E2D101-57DB-4318-AE15-FF9752FBDDD0@apple.com>
References: <94E2D101-57DB-4318-AE15-FF9752FBDDD0@apple.com>
Message-ID: <521640720909151642w432d5ec0g1afea918c79cea20@mail.gmail.com>

Good day,

I been working on the CMake build system (which is nice and portable)
+ code clean ups over the whole Compiler-RT software suit.
I recently added Blocks to the CMake build system but there is some
ugly looking warnings I need to fix up in the Blocks code which I have
not had time to look into yet.
N.B. The CMake build system is not complete yet due to my lack of
time, however I am still active, help really welcome !

My main goal is to have Compiler-RT as a highly portable runtime that
will build and run on AuroraUX, *BSD, Linux and OSX with lint clean
code and zero build warnings. Also, I plan to add SPARC support in the
near future if I get time. (As I work on AuroraUX almost full time
also.)

These are my personal goals working on Compiler-RT.

Could you please outline *exactly* what you would like to see happen
with Blocks,
I don't really know much about Blocks to be fair however I would be
interested to hear and at least it would be 'on record' here.

Cheers,
Edward O'Callaghan.

2009/9/15 Jordan K. Hubbard <jkh at apple.com>:
> Hi folks,
>
> So, various folks are in the process of porting Grand Central Dispatch
> to FreeBSD (c.f. http://libdispatch.macosforge.org and http://lists.macosforge.org/pipermail/libdispatch-dev
> ?for mailing list discussion on the topic) and are making good
> progress, but one of the issues they're running into is support for
> Blocks in FreeBSD.
>
> On the one hand, they could try and back-port the gcc changes from http://www.opensource.apple.com/source/gcc/gcc-5646
> ?and solve the problem that way or, on the other hand, they could
> just continue FreeBSD's inexorable march towards Clang and get the
> blocks support as part of compiler-rt. ?The only problem seems to be
> that the build support for Blocks in compiler-rt isn't wired up yet,
> which came as something of a surprise to all involved given that
> people have been talking about Clang and Blocks since this summer.
>
> Is there a roadmap for this anywhere that we can read? ?If this simply
> has not been done due to a lack of resources, the GCD porting folks
> could perhaps help move this along, assuming they had appropriate
> access to the bits.
>
> Thanks!
>
> - Jordan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From graham.hemingway at gmail.com  Tue Sep 15 20:42:15 2009
From: graham.hemingway at gmail.com (Graham Hemingway)
Date: Tue, 15 Sep 2009 20:42:15 -0500
Subject: [LLVMdev] LLVM Beginner Question
In-Reply-To: <A4DDDE21-04B6-494C-8699-1B3DC3D41DF5@gmail.com>
References: <A3A43566-CBB1-47D0-A537-DA157A4767A1@gmail.com>
	<87k500ntov.fsf@telefonica.net>
	<73631472-1390-497E-B19B-4BC3777D9C6F@gmail.com>
	<877hw0ns1w.fsf@telefonica.net>
	<A4DDDE21-04B6-494C-8699-1B3DC3D41DF5@gmail.com>
Message-ID: <EB08625C-80BB-4FFB-93B1-82A45AFACF49@gmail.com>

Thank you two for your guidance.  I have built LLVM and have a simple  
example problem up and running.  Now comes the fun part.

Cheers,
     Graham

On Sep 15, 2009, at 10:54 AM, Ray Fix wrote:

> On Sep 15, 2009, at 11:31 AM, ?scar Fuentes wrote:
>>
>>> PPS: Someone should add the -G Xcode (and possibly other example
>>> targets to) example to the CMake.html doc.
>>
>> The document explains how to list the available generators. It  
>> mentions
>> that generator's names are case-sensitive too.
>>
>
> Ah, ic.  My apologies.  I followed the first step of the getting  
> started guide, "Read the documentation." But then I forgot to follow  
> the second step, "Read the documentation." ;-)
>
> Thanks.
> Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090915/5c8e30ec/attachment.html 

From lattner at apple.com  Tue Sep 15 23:38:09 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 15 Sep 2009 21:38:09 -0700
Subject: [LLVMdev] Limited space left for the 2009 LLVM Developers' Meeting
Message-ID: <943CF98C-40C1-47FD-B892-351E4F1C2777@apple.com>

We did not expect the LLVM Developers' meeting to be so popular this  
year! Due to space limitations, we must limit the registration to 190  
people. There are a few registration slots left, so sign up today!

As a reminder, registration is required to be able to attend:
http://llvm.org/devmtg/register.php

If you registered and are no longer able to attend, please let me  
know, so someone else can fill your slot.

Lastly, the hotel cut off date for the special price is September 17th.

Thanks,
Tanya Lattner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090915/03524ad1/attachment.html 

From devang.patel at gmail.com  Wed Sep 16 00:24:24 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Tue, 15 Sep 2009 22:24:24 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <bb55930e0909111320w6e8c18b2qdc652fa72be2058c@mail.gmail.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<bb55930e0909111320w6e8c18b2qdc652fa72be2058c@mail.gmail.com>
Message-ID: <352a1fb20909152224i442d08e9mc4d51e16c37c891c@mail.gmail.com>

On Fri, Sep 11, 2009 at 1:20 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> I've got a suggestion for a refinement:
>
> Right now, we have classes like DILocation that wrap an MDNode* to
> provide more convenient access to it. It would be more convenient for
> users if instead of
>
> ?MDNode *DbgInfo = Inst->getMD(MDKind::DbgTag);
> ?Inst2->setMD(MDKind::DbgTag, DbgInfo);
>
> they could write:
>
> ?DILocation DbgInfo = Inst->getMD<DILocation>();
> ?inst2->setMD(DbgInfo);
>
> we'd use TheContext->RegisterMDKind<MyKindWrapper>() or
> ...Register<MyKindWrapper>("name"); to register a new kind. (I prefer
> the first.)

Right now, I am preparing a very simple implementation that allows us
to make progress on debug info front. And the same time, it'd be
possible for someone to extend it for other uses.
-
Devang


From viridia at gmail.com  Wed Sep 16 01:03:55 2009
From: viridia at gmail.com (Talin)
Date: Tue, 15 Sep 2009 23:03:55 -0700
Subject: [LLVMdev] struct returns
In-Reply-To: <400d33ea0909151010t3f340c76ob99bc82726cf9826@mail.gmail.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>	<FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
	<400d33ea0909151010t3f340c76ob99bc82726cf9826@mail.gmail.com>
Message-ID: <4AB07FCB.3050404@gmail.com>

Kenneth Uildriks wrote:
> On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote:
>   
>> On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote:
>>
>>     
>>> In the latest snapshot from SVN on X86, llc refuses to compile
>>> functions returning structs larger than two i32 members.
>>>
>>> According to the docs, such limitations can be expected to exist on
>>> other platforms.
>>>
>>> This leads to a number of questions and observations:
>>>
>>> 1. Is there a good way to retrieve the current target limitations on
>>> struct return sizes?
>>>       
>> No.  The information can be inferred from what's in the *CallingConv.td
>> files, though there are currently no utilities specifically for this.
>>
>>     
>>> 2. The sretpromotion pass does not take struct size limitations into
>>> account; it will happily convert an sret parameter with five members
>>> into a return value that llc chokes on.
>>>
>>> 3. There is no sretdemotion pass.
>>>
>>> 4. If the answer to #1 is "no", perhaps we need platform-specific
>>> sretpromotion and sretdemotion passes to allow small struct returns to
>>> happen efficiently while large struct returns can be successfully
>>> codegen'd, all without having to build such platform-specific
>>> knowledge into all front-ends.
>>>       
>> Sure. Alternatively, we could fix codegen to do this itself.  I'd be
>> happy to help anyone interested in working on this.
>>
>> I recently made a major reorganization of the calling-convention
>> lowering code which cleared away one of the major obstacles to
>> doing this within codegen.
>>
>> Dan
>>     
>
> That would be even better.  I suppose codegen would have to do
> something like the sret parameter demotion when the number of members
> exceeds the number of available registers?  Or did you have something
> else in mind?
>
> Fixing this would make my front-end noticeably simpler, and would
> probably benefit other front-ends as well, so I'd be willing to spend
> some time on it.
>
>   
It would definitely help my front end :)

-- Talin


From talin at acm.org  Wed Sep 16 01:15:41 2009
From: talin at acm.org (Talin)
Date: Tue, 15 Sep 2009 23:15:41 -0700
Subject: [LLVMdev] Type strengthening and type weakening
Message-ID: <4AB0828D.7030503@acm.org>

Has anyone done any experiments with regards to type strengthening or 
weakening in the context of LLVM?

For example, the GWT compiler does type strengthening - that is, if you 
are calling a method on an interface or abstract type, and the compiler 
determines through live variable analysis what the concrete type is, 
then it goes ahead and re-writes the type information to be the stronger 
type. The advantage is that it may then be able to do additional 
optimizations, such as inlining the method or avoiding indirect dispatch.

Conversely, Java's "type erasure" is an extreme case of type weakening - 
that is, if you have a bunch of functions which operate on similar types 
(which might be produced through something like C++ template 
instantiation), you can throw away all of the information about those 
types that aren't relevant to those functions, and you may find as a 
result that many of them become identical and can be merged into a 
single function.

In the context of LLVM, it would be interesting to have a pass that 
could go through a function and transform the types of the input 
arguments to be opaque except where the function actually needs the type 
information - so for example if a pointer argument is never dereferenced 
it can be converted into a void *.

Similarly, a pass that would generate a hash value for a function, and 
then see if functions with identical hashes could be merged.

The hardest part would be doing this in a way that preserves the ability 
to debug the code.

-- Talin

From devang.patel at gmail.com  Wed Sep 16 01:37:04 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Tue, 15 Sep 2009 23:37:04 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
Message-ID: <352a1fb20909152337u312eea85s2bccd834d3744545@mail.gmail.com>

On Fri, Sep 11, 2009 at 9:57 AM, Chris Lattner <clattner at apple.com> wrote:
> Devang's work on debug info prompted this, thoughts welcome:
> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt

Here is partial initial implementation.
Thoughts ?
-
Devang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mdn.diff
Type: application/octet-stream
Size: 7859 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090915/3b4fb271/attachment.obj 

From sebastian.redl at getdesigned.at  Wed Sep 16 02:12:49 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Wed, 16 Sep 2009 09:12:49 +0200
Subject: [LLVMdev] Type strengthening and type weakening
In-Reply-To: <4AB0828D.7030503@acm.org>
References: <4AB0828D.7030503@acm.org>
Message-ID: <4AB08FF1.3000800@getdesigned.at>

Talin wrote:
> For example, the GWT compiler does type strengthening - that is, if you 
> are calling a method on an interface or abstract type, and the compiler 
> determines through live variable analysis what the concrete type is, 
> then it goes ahead and re-writes the type information to be the stronger 
> type. The advantage is that it may then be able to do additional 
> optimizations, such as inlining the method or avoiding indirect dispatch.
>
> Conversely, Java's "type erasure" is an extreme case of type weakening - 
> that is, if you have a bunch of functions which operate on similar types 
> (which might be produced through something like C++ template 
> instantiation), you can throw away all of the information about those 
> types that aren't relevant to those functions, and you may find as a 
> result that many of them become identical and can be merged into a 
> single function.
>
> In the context of LLVM, it would be interesting to have a pass that 
> could go through a function and transform the types of the input 
> arguments to be opaque except where the function actually needs the type 
> information - so for example if a pointer argument is never dereferenced 
> it can be converted into a void *.
>   
Given that LLVM doesn't have much information about the relationships
between types, would this be worth it? Such an optimization should IMO
be done by the front-end, which has higher-level information about
types, such as class hierarchies.

Sebastian

From mikael.lepisto at tut.fi  Wed Sep 16 02:40:57 2009
From: mikael.lepisto at tut.fi (=?ISO-8859-1?Q?Mikael_Lepist=F6?=)
Date: Wed, 16 Sep 2009 10:40:57 +0300
Subject: [LLVMdev] Fwd: [llvm-commits] [PATCH] Building llvm-gcc with
 llvm-2.5 debian packages
In-Reply-To: <BC7B9DEE-C1E3-4142-8618-7E134CE61BEB@tut.fi>
References: <DACC02ED-6BF3-4BA1-83FD-A434EE28B2CA@tut.fi>	<B421EFAA-C664-4760-957E-8E04D70BDEA8@tut.fi>	<4AAF5474.7060702@tut.fi>
	<4AAF5A42.9020101@free.fr>
	<BC7B9DEE-C1E3-4142-8618-7E134CE61BEB@tut.fi>
Message-ID: <4AB09689.9050407@tut.fi>

Mikael Lepist? wrote:
> On 15.9.2009, at 12:11, Duncan Sands wrote:
>
>   
>> Hi Pekka,
>>
>>     
>>> To put it the another way: is there a reason to disallow
>>> compiling llvm-gcc (optionally) against an installed LLVM (e.g.
>>> from the Debian package)? It seems to work fine with this patch
>>> Mikael posted.
>>>       
>> I think it would be great if llvm-gcc could be built against
>> an installed LLVM.  However my impression was that Mikael's
>> original patch would break building against an not-installed llvm.
>>
>>     
>
> Hi, sorry for being a bit unclear before.
>
> The patch would just fix llvm-gcc build system to be able to compile  
> with both, *llvm build in source directory* and *installed llvm  
> version*.
>
> Correct include directory can be get with llvm-config --includedir,  
> because when llvm-config is excuted from llvm source tree (from  
> Release or Debug directory) it will return the include directory of  
> source tree (e.g. llvm-2.6svn/include). If llvm-config is called from  
> installation path it returns include directory of installed llvm  
> includes.
>
> I  tried the patch with compiling llvm-gcc with:
> - llvm-2.5 source tree build
> - installed llvm-2.5 from sources
> - apt-get installed debian llvm-2.5 packages.
>
> I will try if the patch works correctly with llvm trunk as well and  
> show also the compile commands which were used to configure and  
> compile the llvm-gcc.
>   
Hi,

I tested the trunk and it seems to work as well. Below some information 
about testing process. I also attached the latest version of the patch.

- Mikael

elhigu at mr-lenovo:~/stow_sources/llvm-svn$ ./configure 
--prefix=/home/elhigu/stow_repo/test_install/
elhigu at mr-lenovo:~/stow_sources/llvm-svn$ make
elhigu at mr-lenovo:~/stow_sources/llvm-svn$ make install

...

elhigu at mr-lenovo:~/test_llvm_gcc_compilation/llvm-gcc-built-source-tree$ 
llvm-config
The program 'llvm-config' is currently not installed.  You can install 
it by typing:
sudo apt-get install llvm
bash: llvm-config: command not found

# the source tree build

elhigu at mr-lenovo:~/test_llvm_gcc_compilation/llvm-gcc-built-source-tree$ 
../../stow_sources/llvm-gcc-4.2-svn/configure 
--enable-llvm=/home/elhigu/stow_sources/llvm-svn/ --enable-languages=c

...

elhigu at mr-lenovo:~/test_llvm_gcc_compilation/llvm-gcc-built-source-tree$ 
make

...
And include switches in compile command in llvm-gcc/gcc directory are:

-I. -I. -I../../../stow_sources/llvm-gcc-4.2-svn/gcc 
-I../../../stow_sources/llvm-gcc-4.2-svn/gcc/. 
-I../../../stow_sources/llvm-gcc-4.2-svn/gcc/../include
-I../../../stow_sources/llvm-gcc-4.2-svn/gcc/../libcpp/include  
-I../../../stow_sources/llvm-gcc-4.2-svn/gcc/../libdecnumber 
-I../libdecnumber
-I/home/elhigu/stow_sources/llvm-svn/include 
-I/home/elhigu/stow_sources/llvm-svn/include 
-I/home/elhigu/stow_sources/llvm-svn/include

...

# and with installed build

elhigu at mr-lenovo:~/test_llvm_gcc_compilation/llvm-gcc-with-installed-llvm$ 
../../stow_sources/llvm-gcc-4.2-svn/configure 
--enable-llvm=/home/elhigu/stow_repo/test_install/ --enable-languages=c

...

elhigu at mr-lenovo:~/test_llvm_gcc_compilation/llvm-gcc-built-source-tree$ 
make

...

include switches in compile command in llvm-gcc/gcc directory are:

-I. -I. -I../../../stow_sources/llvm-gcc-4.2-svn/gcc 
-I../../../stow_sources/llvm-gcc-4.2-svn/gcc/. 
-I../../../stow_sources/llvm-gcc-4.2-svn/gcc/../include
-I../../../stow_sources/llvm-gcc-4.2-svn/gcc/../libcpp/include  
-I../../../stow_sources/llvm-gcc-4.2-svn/gcc/../libdecnumber 
-I../libdecnumber
-I/home/elhigu/stow_repo/test_install/include 
-I/home/elhigu/stow_repo/test_install/include

> - Mikael
>
>   
>> Ciao,
>>
>> Duncan.
>> _______________________________________________
>> 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
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile-fix-for-allowing-to-build-with-pre-installed-llvm.patch
Type: text/x-diff
Size: 1988 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/bc115de6/attachment-0001.bin 

From simon.harmony at gmail.com  Wed Sep 16 03:13:47 2009
From: simon.harmony at gmail.com (Simon Zhou)
Date: Wed, 16 Sep 2009 16:13:47 +0800
Subject: [LLVMdev] [codegen] how to generate x87 instructions using LLVM
Message-ID: <3db9f87f0909160113i29b6cc85p929d22a5abcd6081@mail.gmail.com>

 Hi All

  I am a greenhand for LLVM.

  I find the LLVM generate SSE instrctions for floating pointing
computation, is there some method or options to let it generate x87
instructions?


 Thanks
Simon

-- 
>From : Simon.Zhou at PPI, Fudan University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/4717f6df/attachment.html 

From meurant.olivier at gmail.com  Wed Sep 16 03:42:40 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Wed, 16 Sep 2009 10:42:40 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <200909151035.58610.dag@cray.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
	<200909151035.58610.dag@cray.com>
Message-ID: <549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>

On Tue, Sep 15, 2009 at 5:35 PM, David Greene <dag at cray.com> wrote:

>
> Remember, the goal here isn't to show how great LLVM is.  It's to get an
> honest assessment of where we are at.  Phoronix did us a big favor.
>  Getting
> more details about his tests would help us even more.
>

It's exactly what I'm trying to do. I'm not even a LLVM contributor, so I
don't feel responsible for a good or bad performances of LLVM. :)
Anyway, thanks for pointing this target differences. After some hours at
recompiling gcc, here we are :

Some information on the test platform :

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.04
DISTRIB_CODENAME=jaunty
DISTRIB_DESCRIPTION="Ubuntu 9.04"

uname -a
Linux zaraki 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009
i686 GNU/Linux

/proc/cpuinfo
dual core Intel(R) Core(TM)2 CPU X6800  @ 2.93GHz (cache size 4096)

llvm-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../llvm-gcc4.2-2.5.source/configure
--prefix=/mounts/zion/disks/0/localhome/tbrethou/2.5/prerelease2/llvm-gcc/obj/../install
--program-prefix=llvm-
--enable-llvm=/localhome/tbrethou/2.5/prerelease2/llvm-2.5/
--disable-bootstrap --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5636) (LLVM build 2.5)
(Binary from official x86 2.5 release)

gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/usr/local
Thread model: posix
gcc version 4.4.1 (GCC)

The compilation line are :
gcc -o bin src.c -O3
llvm-gcc -o bin src.c -O3


Results :
LLVM average : 13553161.95
gcc average : 14624441.45
Average : gcc is better with 8%

The full report :
        "LLVM"  "GCC"   "Difference"    "Difference %"

"Run 1" 13842616        14693115.8      -850499.8       -6.14
"Run 2" 13773202.9      14785734.9      -1012532        -7.35
"Run 3" 13671309.3      14985114        -1313804.7      -9.61
"Run 4" 12916939        14640392.9      -1723453.9      -13.34
"Run 5" 13572133.3      14425575        -853441.7       -6.29
"Run 6" 13810096.5      14694240.6      -884144.1       -6.4
"Run 7" 13427435.8      14695094.6      -1267658.8      -9.44
"Run 8" 14056659.9      14468968.4      -412308.5       -2.93
"Run 9" 13699125.3      14373360.9      -674235.6       -4.92
"Run 10 12762101.5      14482817.4      -1720715.9      -13.48

"Average"       13553161.95     14624441.45     -1071279.5      -7.99
"Standard deviation"    412810.77       187898.68       430895.31       3.46

Is there again something wrong on this test ?

Olivier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/17b14394/attachment.html 

From isanbard at gmail.com  Wed Sep 16 03:53:29 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 16 Sep 2009 01:53:29 -0700
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <974F30A4-4239-4878-AEBF-0F6C0E3755BF@apple.com>
References: <295e750a0909140751i35b399e6ubf9429b889a109eb@mail.gmail.com>
	<974F30A4-4239-4878-AEBF-0F6C0E3755BF@apple.com>
Message-ID: <0219F7F1-1B46-467D-B01D-EFE55F0EF4E4@gmail.com>

FYI, it should apply cleanly.

-bw

On Sep 14, 2009, at 9:59 AM, Chris Lattner wrote:

> On Sep 14, 2009, at 7:51 AM, Zoltan Varga wrote:
>>         Hi,
>>
>>   Would it be possible to merge this commit:
>> http://llvm.org/viewvc/llvm-project?view=rev&revision=80960
>>
>> to the llvm 2.6 branch ? Without it, incomplete unwind info is  
>> generated for functions with 0 stack size.
>
> Does it apply cleanly to the 2.6 branch?
>
> -Chris
> _______________________________________________
> 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  Wed Sep 16 04:14:03 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 16 Sep 2009 13:14:03 +0400
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
	<200909151035.58610.dag@cray.com>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
Message-ID: <b087fca00909160214w1969b491h6357e50aca548fe6@mail.gmail.com>

Hello, Oliver

> The compilation line are :
> gcc -o bin src.c -O3
> llvm-gcc -o bin src.c -O3
I'm not quite sure which target processor the compiler will optimize
code for. I'd suggest adding explicit -march=core2 here. Also, could
you please do a separate run with O2, not O3.

Thanks!

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From edwintorok at gmail.com  Wed Sep 16 04:22:54 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Wed, 16 Sep 2009 12:22:54 +0300
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>	<200909151035.58610.dag@cray.com>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
Message-ID: <4AB0AE6E.5090409@gmail.com>

On 2009-09-16 11:42, Olivier Meurant wrote:
> On Tue, Sep 15, 2009 at 5:35 PM, David Greene <dag at cray.com
> <mailto:dag at cray.com>> wrote:
>
>
>     Remember, the goal here isn't to show how great LLVM is.  It's to
>     get an
>     honest assessment of where we are at.  Phoronix did us a big
>     favor.  Getting
>     more details about his tests would help us even more.
>
>
> It's exactly what I'm trying to do. I'm not even a LLVM contributor,
> so I don't feel responsible for a good or bad performances of LLVM. :)
> Anyway, thanks for pointing this target differences. After some hours
> at recompiling gcc, here we are :
>
> Some information on the test platform :
>
> cat /etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=9.04
> DISTRIB_CODENAME=jaunty
> DISTRIB_DESCRIPTION="Ubuntu 9.04"
>
> uname -a
> Linux zaraki 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC
> 2009 i686 GNU/Linux
>
> /proc/cpuinfo
> dual core Intel(R) Core(TM)2 CPU X6800  @ 2.93GHz (cache size 4096)
>
> llvm-gcc -v
> Using built-in specs.
> Target: i686-pc-linux-gnu
> Configured with: ../llvm-gcc4.2-2.5.source/configure
> --prefix=/mounts/zion/disks/0/localhome/tbrethou/2.5/prerelease2/llvm-gcc/obj/../install
> --program-prefix=llvm-
> --enable-llvm=/localhome/tbrethou/2.5/prerelease2/llvm-2.5/
> --disable-bootstrap --enable-languages=c,c++,fortran
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5636) (LLVM build 2.5)
> (Binary from official x86 2.5 release)
>
> gcc -v
> Using built-in specs.
> Target: i686-pc-linux-gnu
> Configured with: ./configure --prefix=/usr/local
> Thread model: posix
> gcc version 4.4.1 (GCC)

Phoronix tested with gcc 4.2.1 (Apple's).

>
> The compilation line are :
> gcc -o bin src.c -O3
> llvm-gcc -o bin src.c -O3

The Makefile uses -O by default, perhaps that is what Phoronix used too.

>
>
> Results :
> LLVM average : 13553161.95
> gcc average : 14624441.45
> Average : gcc is better with 8%
>
> The full report :
>         "LLVM"  "GCC"   "Difference"    "Difference %"
>
> "Run 1" 13842616        14693115.8      -850499.8       -6.14
> "Run 2" 13773202.9      14785734.9      -1012532        -7.35
> "Run 3" 13671309.3      14985114        -1313804.7      -9.61
> "Run 4" 12916939        14640392.9      -1723453.9      -13.34
> "Run 5" 13572133.3      14425575        -853441.7       -6.29
> "Run 6" 13810096.5      14694240.6      -884144.1       -6.4
> "Run 7" 13427435.8      14695094.6      -1267658.8      -9.44
> "Run 8" 14056659.9      14468968.4      -412308.5       -2.93
> "Run 9" 13699125.3      14373360.9      -674235.6       -4.92
> "Run 10 12762101.5      14482817.4      -1720715.9      -13.48
>
> "Average"       13553161.95     14624441.45     -1071279.5      -7.99
> "Standard deviation"    412810.77       187898.68      
> 430895.31       3.46
>
> Is there again something wrong on this test ?

No, it seems fine.

I get different results on x86-64 though (with -O), the difference is
very small (4% with 3% stddev, or 3% with 1.5% stddev).

Maybe you should try to reproduce one of the other benchmarks that show
a higher difference, according to phoronix JOhn the Ripper shown 40%
performance drop, there was also a huge drop for blowfish.



	GCC 4.4.1 	GCC 4.2.4 	LLVM-GCC 2.5 	LLVM-GCC 2.6 	GCC-4.4/LLVM2.5
GCC-4.4/LLVM2.6 	GCC-4.4/GCC-4.2

	144663277 	139072037 	154747143 	151467440 	0.935 	0.955 	1.040

	144413249 	139042455 	150949846 	150322055 	0.957 	0.961 	1.039

	144915166 	138131283 	150630261 	150650540 	0.962 	0.962 	1.049

	145602711 	138587982 	154993781 	147281539 	0.939 	0.989 	1.051

	145547868 	139224734 	150650813 	147998859 	0.966 	0.983 	1.045

	145719970 	139224734 	144055081 	152474829 	1.012 	0.956 	1.047
average 	145143706.83 	138880537.5 	151004487.5 	150032543.67 	0.962
0.968 	1.045
stdev 	551855.54 	435155.79 	3961926.31 	2009642.82 	0.027 	0.015 	0.005


Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.1-4'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --enable-multiarch --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.1 (Debian 4.4.1-4)

llvm2.5:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../llvm-gcc-4.2/configure --program-prefix=llvm-
--enable-llvm=/home/edwin/llvm2.5/obj --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5636) (LLVM build)

llvm2.6pre1:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../llvm-gcc4.2-2.6.source/configure
--program-prefix=llvm- --enable-languages=c,c++,fortran
--enable-llvm=/home/edwin/llvm2.6/obj/
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5649) (LLVM build)

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-6)


Best regards,
--Edwin


From meurant.olivier at gmail.com  Wed Sep 16 06:37:06 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Wed, 16 Sep 2009 13:37:06 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <4AB0AE6E.5090409@gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
	<200909151035.58610.dag@cray.com>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
Message-ID: <549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>

Some additional tests :

With : -O2 -march=core2 for both gcc and llvm-gcc : LLVM is better with 10%.

        LLVM    GCC     Difference      Difference %

        Run 1   13771597.2      13105010.6      666586.6        4.84
        Run 2   13813420.8      12536327.1      1277093.7       9.25
        Run 3   13769573.8      12124207.3      1645366.5       11.95
        Run 4   13883222.6      12794159.1      1089063.5       7.84
        Run 5   13890414.6      12105946        1784468.6       12.85
        Run 6   13784627.3      11648245        2136382.3       15.5
        Run 7   13920748.9      11781692.4      2139056.5       15.37
        Run 8   13816843.9      12460451.3      1356392.6       9.82
        Run 9   13864682.1      12959671.4      905010.7        6.53
        Run 10  13849863.4      12964021.5      885841.9        6.4

        Average 13836499.46     12447973.17     1388526.29      10.03
        Standard deviation      53189.13        515638.56
522400.98       3.77



With : -O3 -march=core2 for both compiler : GCC is better with 5.75%

        LLVM    GCC     Difference      Difference %

        Run 1   13790728.3      14902550.9      -1111822.6      -8.06
        Run 2   13840499.3      14759093.2      -918593.9       -6.64
        Run 3   13975018.5      14545983.5      -570965 -4.09
        Run 4   13853799.5      15126446.4      -1272646.9      -9.19
        Run 5   13993633.5      14824100.4      -830466.9       -5.93
        Run 6   13903645.3      12768793.8      1134851.5       8.16
        Run 7   13816401.7      15003783.8      -1187382.1      -8.59
        Run 8   13735232.8      14976854.3      -1241621.5      -9.04
        Run 9   13902380.7      14778159.5      -875778.8       -6.3
        Run 10  13936761.8      15022553.5      -1085791.7      -7.79

        Average 13874810.14     14670831.93     -796021.79      -5.75
        Standard deviation      82443.34        688446.69
712123.9        5.14


Olivier.





2009/9/16 T?r?k Edwin <edwintorok at gmail.com>

> On 2009-09-16 11:42, Olivier Meurant wrote:
> > On Tue, Sep 15, 2009 at 5:35 PM, David Greene <dag at cray.com
> > <mailto:dag at cray.com>> wrote:
> >
> >
> >     Remember, the goal here isn't to show how great LLVM is.  It's to
> >     get an
> >     honest assessment of where we are at.  Phoronix did us a big
> >     favor.  Getting
> >     more details about his tests would help us even more.
> >
> >
> > It's exactly what I'm trying to do. I'm not even a LLVM contributor,
> > so I don't feel responsible for a good or bad performances of LLVM. :)
> > Anyway, thanks for pointing this target differences. After some hours
> > at recompiling gcc, here we are :
> >
> > Some information on the test platform :
> >
> > cat /etc/lsb-release
> > DISTRIB_ID=Ubuntu
> > DISTRIB_RELEASE=9.04
> > DISTRIB_CODENAME=jaunty
> > DISTRIB_DESCRIPTION="Ubuntu 9.04"
> >
> > uname -a
> > Linux zaraki 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC
> > 2009 i686 GNU/Linux
> >
> > /proc/cpuinfo
> > dual core Intel(R) Core(TM)2 CPU X6800  @ 2.93GHz (cache size 4096)
> >
> > llvm-gcc -v
> > Using built-in specs.
> > Target: i686-pc-linux-gnu
> > Configured with: ../llvm-gcc4.2-2.5.source/configure
> >
> --prefix=/mounts/zion/disks/0/localhome/tbrethou/2.5/prerelease2/llvm-gcc/obj/../install
> > --program-prefix=llvm-
> > --enable-llvm=/localhome/tbrethou/2.5/prerelease2/llvm-2.5/
> > --disable-bootstrap --enable-languages=c,c++,fortran
> > Thread model: posix
> > gcc version 4.2.1 (Based on Apple Inc. build 5636) (LLVM build 2.5)
> > (Binary from official x86 2.5 release)
> >
> > gcc -v
> > Using built-in specs.
> > Target: i686-pc-linux-gnu
> > Configured with: ./configure --prefix=/usr/local
> > Thread model: posix
> > gcc version 4.4.1 (GCC)
>
> Phoronix tested with gcc 4.2.1 (Apple's).
>
> >
> > The compilation line are :
> > gcc -o bin src.c -O3
> > llvm-gcc -o bin src.c -O3
>
> The Makefile uses -O by default, perhaps that is what Phoronix used too.
>
> >
> >
> > Results :
> > LLVM average : 13553161.95
> > gcc average : 14624441.45
> > Average : gcc is better with 8%
> >
> > The full report :
> >         "LLVM"  "GCC"   "Difference"    "Difference %"
> >
> > "Run 1" 13842616        14693115.8      -850499.8       -6.14
> > "Run 2" 13773202.9      14785734.9      -1012532        -7.35
> > "Run 3" 13671309.3      14985114        -1313804.7      -9.61
> > "Run 4" 12916939        14640392.9      -1723453.9      -13.34
> > "Run 5" 13572133.3      14425575        -853441.7       -6.29
> > "Run 6" 13810096.5      14694240.6      -884144.1       -6.4
> > "Run 7" 13427435.8      14695094.6      -1267658.8      -9.44
> > "Run 8" 14056659.9      14468968.4      -412308.5       -2.93
> > "Run 9" 13699125.3      14373360.9      -674235.6       -4.92
> > "Run 10 12762101.5      14482817.4      -1720715.9      -13.48
> >
> > "Average"       13553161.95     14624441.45     -1071279.5      -7.99
> > "Standard deviation"    412810.77       187898.68
> > 430895.31       3.46
> >
> > Is there again something wrong on this test ?
>
> No, it seems fine.
>
> I get different results on x86-64 though (with -O), the difference is
> very small (4% with 3% stddev, or 3% with 1.5% stddev).
>
> Maybe you should try to reproduce one of the other benchmarks that show
> a higher difference, according to phoronix JOhn the Ripper shown 40%
> performance drop, there was also a huge drop for blowfish.
>
>
>
>        GCC 4.4.1       GCC 4.2.4       LLVM-GCC 2.5    LLVM-GCC 2.6
>  GCC-4.4/LLVM2.5
> GCC-4.4/LLVM2.6         GCC-4.4/GCC-4.2
>
>        144663277       139072037       154747143       151467440
> 0.935   0.955   1.040
>
>        144413249       139042455       150949846       150322055
> 0.957   0.961   1.039
>
>        144915166       138131283       150630261       150650540
> 0.962   0.962   1.049
>
>        145602711       138587982       154993781       147281539
> 0.939   0.989   1.051
>
>        145547868       139224734       150650813       147998859
> 0.966   0.983   1.045
>
>        145719970       139224734       144055081       152474829
> 1.012   0.956   1.047
> average         145143706.83    138880537.5     151004487.5
> 150032543.67    0.962
> 0.968   1.045
> stdev   551855.54       435155.79       3961926.31      2009642.82
>  0.027   0.015   0.005
>
>
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.1-4'
> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --enable-multiarch --enable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-mpfr --enable-objc-gc
> --with-arch-32=i486 --with-tune=generic --enable-checking=release
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.4.1 (Debian 4.4.1-4)
>
> llvm2.5:
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ../llvm-gcc-4.2/configure --program-prefix=llvm-
> --enable-llvm=/home/edwin/llvm2.5/obj --enable-languages=c,c++,fortran
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5636) (LLVM build)
>
> llvm2.6pre1:
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ../llvm-gcc4.2-2.6.source/configure
> --program-prefix=llvm- --enable-languages=c,c++,fortran
> --enable-llvm=/home/edwin/llvm2.6/obj/
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5649) (LLVM build)
>
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
> --enable-mpfr --with-tune=generic --enable-checking=release
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.2.4 (Debian 4.2.4-6)
>
>
> Best regards,
> --Edwin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/b0ee0726/attachment.html 

From rengolin at systemcall.org  Wed Sep 16 07:40:14 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Wed, 16 Sep 2009 13:40:14 +0100
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
	<200909151035.58610.dag@cray.com>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
Message-ID: <d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>

2009/9/16 Olivier Meurant <meurant.olivier at gmail.com>:
> ??????? Average 13836499.46???? 12447973.17???? 1388526.29????? 10.03
> ??????? Standard deviation????? 53189.13??????? 515638.56
> 522400.98?????? 3.77


That was pretty much what I was expecting from the article... numbers.
It doesn't matter who's best, you can't be best in all areas, but
profiling must be done right. The standard deviation is, at least, one
order of magnitude lower than the difference between the two averages,
which means the measurements have a meaning and express some reality.

There is little value in the results on the article. People had to
re-do it properly again, anyway...

Shouldn't it be part of the standard release? I mean, add profiling as
an automated task before every big release, comparing to previous
versions of LLVM and other important compilers. Not to be waving the
results about, but to know the weakness and work on them on the next
release. It might take a while to build such infrastructure, but it's
a good thing to do, I guess.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From baldrick at free.fr  Wed Sep 16 07:50:40 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 16 Sep 2009 14:50:40 +0200
Subject: [LLVMdev] Fwd: [llvm-commits] [PATCH] Building llvm-gcc with
 llvm-2.5 debian packages
In-Reply-To: <4AB09689.9050407@tut.fi>
References: <DACC02ED-6BF3-4BA1-83FD-A434EE28B2CA@tut.fi>	<B421EFAA-C664-4760-957E-8E04D70BDEA8@tut.fi>	<4AAF5474.7060702@tut.fi>
	<4AAF5A42.9020101@free.fr>
	<BC7B9DEE-C1E3-4142-8618-7E134CE61BEB@tut.fi>
	<4AB09689.9050407@tut.fi>
Message-ID: <4AB0DF20.7030903@free.fr>

Hi Mikael, I don't like this bit:

+# Also remove extra llvm postfix from includedir, because llvm-config
+# on debian seems to return /usr/include/llvm instead /usr/include

Can this not be fixed in debian?

Ciao,

Duncan.

From kennethuil at gmail.com  Wed Sep 16 07:58:07 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Wed, 16 Sep 2009 07:58:07 -0500
Subject: [LLVMdev] struct returns
In-Reply-To: <FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
	<FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
Message-ID: <400d33ea0909160558kd7fd636m12a63ee2bcbcc752@mail.gmail.com>

> I recently made a major reorganization of the calling-convention
> lowering code which cleared away one of the major obstacles to
> doing this within codegen.
>
> Dan

So what was the obstacle, and how was it cleared?  And how do you see
the large struct return working in codegen?

Anything you care to tell me would be welcome.  I will be starting on
this today or tomorrow.

From baldrick at free.fr  Wed Sep 16 08:02:19 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 16 Sep 2009 15:02:19 +0200
Subject: [LLVMdev] Fwd: [llvm-commits] [PATCH] Building llvm-gcc with
 llvm-2.5 debian packages
In-Reply-To: <4AB09689.9050407@tut.fi>
References: <DACC02ED-6BF3-4BA1-83FD-A434EE28B2CA@tut.fi>	<B421EFAA-C664-4760-957E-8E04D70BDEA8@tut.fi>	<4AAF5474.7060702@tut.fi>
	<4AAF5A42.9020101@free.fr>
	<BC7B9DEE-C1E3-4142-8618-7E134CE61BEB@tut.fi>
	<4AB09689.9050407@tut.fi>
Message-ID: <4AB0E1DB.9060005@free.fr>

Hi Mikael, with your patch I can't build llvm-gcc:

make[2]: *** No rule to make target 
`/home/duncan/LLVM/llvm-objects/../llvm/include/llvm/Intrinsics.gen', 
needed by `llvm-convert.o'. Stop.

Maybe because I use objdir != srcdir in my LLVM build?

Ciao,

Duncan.

From meurant.olivier at gmail.com  Wed Sep 16 08:05:19 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Wed, 16 Sep 2009 15:05:19 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
	<200909151035.58610.dag@cray.com>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
Message-ID: <549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>

I have run the john the ripper test.
I have used the official archive (same version as phoronix) from
http://www.openwall.com/john/g/john-1.7.3.1.tar.bz2

To build with llvm-gcc, replace the line CC = gcc with CC = llvm-gcc.
I have used the following command to build : make clean linux-x86-sse2
(seems to be the best on x86-32)
The makefile invocation is "gcc -c -Wall -O2 -fomit-frame-pointer
-funroll-loops src.c" and "llvm-gcc -c -Wall -O2 -fomit-frame-pointer
-funroll-loops src.c".

I have runned 10 tests : "./john --test" in the run directory. It does 6
benchmarking on various algorithms :

Benchmarking: Traditional DES [128/128 BS SSE2]... DONE

    LLVM    GCC    Difference    Difference %

    Run 1    2371    2358    13    0.55
    Run 2    2499    2497    2    0.08
    Run 3    2489    2487    2    0.08
    Run 4    2305    2504    -199    -8.63
    Run 5    2499    2445    54    2.16
    Run 6    2404    2503    -99    -4.12
    Run 7    2482    2502    -20    -0.81
    Run 8    2479    2475    4    0.16
    Run 9    2463    2489    -26    -1.06
    Run 10    2484    2483    1    0.04

    Average    2447.5    2474.3    -26.8    -1.15
    Std dev    65.69    44.5    71.81    3.07

==> Similar results


Benchmarking: BSDI DES (x725) [128/128 BS SSE2]... DONE

    LLVM    GCC    Difference    Difference %

    Run 1    72584    81280    -8696    -11.98
    Run 2    76620    79795    -3175    -4.14
    Run 3    79820    75264    4556    5.71
    Run 4    76339    81484    -5145    -6.74
    Run 5    81484    76441    5043    6.19
    Run 6    80742    81433    -691    -0.86
    Run 7    81510    79104    2406    2.95
    Run 8    81049    79872    1177    1.45
    Run 9    80409    81100    -691    -0.86
    Run 10    80204    80921    -717    -0.89

    Average    79076.1    79669.4    -593.3    -0.92
    Std dev    2937.56    2181.15    4262.03    5.59

==> Similar results

Benchmarking: FreeBSD MD5 [32/32]... DONE

    LLVM    GCC    Difference    Difference %

    Run 1    7552    8009    -457    -6.05
    Run 2    7739    7724    15    0.19
    Run 3    7997    7696    301    3.76
    Run 4    8038    8041    -3    -0.04
    Run 5    7474    7938    -464    -6.21
    Run 6    7871    8078    -207    -2.63
    Run 7    7884    7980    -96    -1.22
    Run 8    7870    8025    -155    -1.97
    Run 9    7989    8046    -57    -0.71
    Run 10    7986    7989    -3    -0.04

    Average    7840    7952.6    -112.6    -1.49
    Std dev    193.87    133.78    227.92    2.98

==> Similar results

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE

    LLVM    GCC    Difference    Difference %

    Run 1    494    495    -1    -0.2
    Run 2    457    485    -28    -6.13
    Run 3    492    474    18    3.66
    Run 4    494    492    2    0.4
    Run 5    486    469    17    3.5
    Run 6    491    495    -4    -0.81
    Run 7    495    493    2    0.4
    Run 8    490    490    0    0
    Run 9    493    494    -1    -0.2
    Run 10    493    492    1    0.2

    Average    488.5    487.9    0.6    0.08
    Std dev    11.37    9.19    12.56    2.67

==> Similar results

Benchmarking: Kerberos AFS DES [48/64 4K MMX]... DONE

    LLVM    GCC    Difference    Difference %

    Run 1    399001    403712    -4711    -1.18
    Run 2    396697    377292    19405    4.89
    Run 3    395520    401971    -6451    -1.63
    Run 4    392396    404172    -11776    -3
    Run 5    392294    376217    16077    4.1
    Run 6    395571    404172    -8601    -2.17
    Run 7    400128    402995    -2867    -0.72
    Run 8    397516    395110    2406    0.61
    Run 9    396748    403507    -6759    -1.7
    Run 10    396263    403712    -7449    -1.88

    Average    396213.4    397286    -1072.6    -0.27
    Std dev    2497.59    11150.79    10620.52    2.69

==> Similar results


Benchmarking: LM DES [128/128 BS SSE2]... DONE

    LLVM    GCC    Difference    Difference %

    Run 1    6879    11433    -4554    -66.2
    Run 2    8984    12252    -3268    -36.38
    Run 3    9142    12182    -3040    -33.25
    Run 4    8802    12205    -3403    -38.66
    Run 5    8756    11971    -3215    -36.72
    Run 6    9227    12224    -2997    -32.48
    Run 7    8667    12191    -3524    -40.66
    Run 8    9163    11942    -2779    -30.33
    Run 9    9117    12254    -3137    -34.41
    Run 10    9076    12166    -3090    -34.05

    Average    8781.3    12082    -3300.7    -38.31
    Std dev    695.06    252.95    487.97    10.26

==> This one is interesting as gcc is better with near 40%
I have no idea why but anyone interested could take a look at LM_fmt.c which
seems to define test and source for this algorithm.

Olivier.






On Wed, Sep 16, 2009 at 2:40 PM, Renato Golin <rengolin at systemcall.org>wrote:

> 2009/9/16 Olivier Meurant <meurant.olivier at gmail.com>:
> >         Average 13836499.46     12447973.17     1388526.29      10.03
> >         Standard deviation      53189.13        515638.56
> > 522400.98       3.77
>
>
> That was pretty much what I was expecting from the article... numbers.
> It doesn't matter who's best, you can't be best in all areas, but
> profiling must be done right. The standard deviation is, at least, one
> order of magnitude lower than the difference between the two averages,
> which means the measurements have a meaning and express some reality.
>
> There is little value in the results on the article. People had to
> re-do it properly again, anyway...
>
> Shouldn't it be part of the standard release? I mean, add profiling as
> an automated task before every big release, comparing to previous
> versions of LLVM and other important compilers. Not to be waving the
> results about, but to know the weakness and work on them on the next
> release. It might take a while to build such infrastructure, but it's
> a good thing to do, I guess.
>
> cheers,
> --renato
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/90b427bd/attachment.html 

From mikael.lepisto at tut.fi  Wed Sep 16 08:11:31 2009
From: mikael.lepisto at tut.fi (=?ISO-8859-1?Q?Mikael_Lepist=F6?=)
Date: Wed, 16 Sep 2009 16:11:31 +0300
Subject: [LLVMdev] Fwd: [llvm-commits] [PATCH] Building llvm-gcc with
	llvm-2.5 debian packages
In-Reply-To: <4AB0E1DB.9060005@free.fr>
References: <DACC02ED-6BF3-4BA1-83FD-A434EE28B2CA@tut.fi>	<B421EFAA-C664-4760-957E-8E04D70BDEA8@tut.fi>	<4AAF5474.7060702@tut.fi>
	<4AAF5A42.9020101@free.fr>
	<BC7B9DEE-C1E3-4142-8618-7E134CE61BEB@tut.fi>
	<4AB09689.9050407@tut.fi> <4AB0E1DB.9060005@free.fr>
Message-ID: <2005F8B9-7CA9-4F33-886C-572838C8CC72@tut.fi>

Hi, thanks for testing.

I'll try to duplicate and fix the problem. I also remove that debian  
(actually it was ubuntu) dependent fix and file a bug report to  
package maintainer.

For now on I will also test compilation with llvm built when objdir !=  
srcdir. Hopefully I get updated patch before end of the week.

- Mikael

On 16.9.2009, at 16:02, Duncan Sands wrote:

> Hi Mikael, with your patch I can't build llvm-gcc:
>
> make[2]: *** No rule to make target `/home/duncan/LLVM/llvm- 
> objects/../llvm/include/llvm/Intrinsics.gen', needed by `llvm- 
> convert.o'. Stop.
>
> Maybe because I use objdir != srcdir in my LLVM build?
>
> Ciao,
>
> Duncan.


From duncan.sands at math.u-psud.fr  Wed Sep 16 08:50:29 2009
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Wed, 16 Sep 2009 15:50:29 +0200
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
Message-ID: <4AB0ED25.60404@math.u-psud.fr>

Hi Bill,

> The reason to ask this is that
>> it could make the EH tables smaller and less cluttered if we elide  
>> those areas which we know don't throw (the functions called are marked  
>> 'nounwind', etc.).
> 
> Sure, that's what the SawPotentiallyThrowing boolean is for.  It is
> currently set for any call, but in fact needn't be set for 'nounwind'
> calls.  When I wrote this stuff 'nounwind' information wasn't available
> at the codegen level, which is why this isn't done.  In case you care,
> doing this would not hurt Ada :)

now I think about it further, I guess SawPotentiallyThrowing is not for
this exactly, you'll need to add some additional logic near this place.

Ciao,

Duncan.

From stefano.delliponti at gmail.com  Wed Sep 16 08:46:20 2009
From: stefano.delliponti at gmail.com (Stefano Delli Ponti)
Date: Wed, 16 Sep 2009 15:46:20 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>	<200909151035.58610.dag@cray.com>	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>	<4AB0AE6E.5090409@gmail.com>	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
Message-ID: <h8qq7d$scp$1@ger.gmane.org>

Olivier Meurant:
> I have run the john the ripper test.
> I have used the official archive (same version as phoronix) from 
> http://www.openwall.com/john/g/john-1.7.3.1.tar.bz2
> 
> To build with llvm-gcc, replace the line CC = gcc with CC = llvm-gcc.
> I have used the following command to build : make clean linux-x86-sse2 
> (seems to be the best on x86-32)
> The makefile invocation is "gcc -c -Wall -O2 -fomit-frame-pointer 
> -funroll-loops src.c" and "llvm-gcc -c -Wall -O2 -fomit-frame-pointer 
> -funroll-loops src.c".

I don't know what you think about this, but shouldn't it be more 
meaningful to make these tests with -O3? I mean, we ought to make the 
comparisons with the highest level of optimization available for both of 
the compilers. It is difficult to compare an intermediate level.

Stefano


From meurant.olivier at gmail.com  Wed Sep 16 09:32:36 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Wed, 16 Sep 2009 16:32:36 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <h8qq7d$scp$1@ger.gmane.org>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
	<200909151035.58610.dag@cray.com>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
Message-ID: <549cee610909160732p4d1a2b6ar2bad14578dd14570@mail.gmail.com>

On Wed, Sep 16, 2009 at 3:46 PM, Stefano Delli Ponti <
stefano.delliponti at gmail.com> wrote:

> I don't know what you think about this, but shouldn't it be more
> meaningful to make these tests with -O3? I mean, we ought to make the
> comparisons with the highest level of optimization available for both of
> the compilers. It is difficult to compare an intermediate level.
>


A quick test confirms that the 40% difference stays even with an -O3 switch
on both compilers.
I just "choose" -O2 as it's the default of the original makefile.

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

From ssen at apple.com  Wed Sep 16 10:00:31 2009
From: ssen at apple.com (Shantonu Sen)
Date: Wed, 16 Sep 2009 08:00:31 -0700
Subject: [LLVMdev] Status of blocks runtime in compiler-rt?
In-Reply-To: <521640720909151642w432d5ec0g1afea918c79cea20@mail.gmail.com>
References: <94E2D101-57DB-4318-AE15-FF9752FBDDD0@apple.com>
	<521640720909151642w432d5ec0g1afea918c79cea20@mail.gmail.com>
Message-ID: <A1276AA4-105C-4672-937A-A31ED216DE19@apple.com>

The Blocks language and implementation specifications are checked into  
clang/docs.

More generally, on Mac OS X, the blocks runtime is linked into the C  
library ("libSystem"), and available to the entire OS. Clients that  
create blocks may implicitly get compiler-generated calls to some of  
the runtime functions, and the developer may also make explicit calls  
to, e.g., Block_copy().

On other OSes, the library would need to be built and installed  
somewhere. There's also the question of whether it should be a shared  
library or static library. I can see both points, but think that a  
shared library is probably the right way for it.

It should probably be generally portable (it doesn't appear to  
compiler correctly with llvm-gcc and clang on Linux), and install its  
headers (doesn't appear to).

I can spend some time on this, since I have some familiarity with  
libdispatch (Apple's APIs that heavily use Blocks for developer  
convenience).

Shantonu

Sent from my MacBook

On Sep 15, 2009, at 4:42 PM, Edward O'Callaghan wrote:

> Good day,
>
> I been working on the CMake build system (which is nice and portable)
> + code clean ups over the whole Compiler-RT software suit.
> I recently added Blocks to the CMake build system but there is some
> ugly looking warnings I need to fix up in the Blocks code which I have
> not had time to look into yet.
> N.B. The CMake build system is not complete yet due to my lack of
> time, however I am still active, help really welcome !
>
> My main goal is to have Compiler-RT as a highly portable runtime that
> will build and run on AuroraUX, *BSD, Linux and OSX with lint clean
> code and zero build warnings. Also, I plan to add SPARC support in the
> near future if I get time. (As I work on AuroraUX almost full time
> also.)
>
> These are my personal goals working on Compiler-RT.
>
> Could you please outline *exactly* what you would like to see happen
> with Blocks,
> I don't really know much about Blocks to be fair however I would be
> interested to hear and at least it would be 'on record' here.
>
> Cheers,
> Edward O'Callaghan.
>
> 2009/9/15 Jordan K. Hubbard <jkh at apple.com>:
>> Hi folks,
>>
>> So, various folks are in the process of porting Grand Central  
>> Dispatch
>> to FreeBSD (c.f. http://libdispatch.macosforge.org and http://lists.macosforge.org/pipermail/libdispatch-dev
>>  for mailing list discussion on the topic) and are making good
>> progress, but one of the issues they're running into is support for
>> Blocks in FreeBSD.
>>
>> On the one hand, they could try and back-port the gcc changes from http://www.opensource.apple.com/source/gcc/gcc-5646
>>  and solve the problem that way or, on the other hand, they could
>> just continue FreeBSD's inexorable march towards Clang and get the
>> blocks support as part of compiler-rt.  The only problem seems to be
>> that the build support for Blocks in compiler-rt isn't wired up yet,
>> which came as something of a surprise to all involved given that
>> people have been talking about Clang and Blocks since this summer.
>>
>> Is there a roadmap for this anywhere that we can read?  If this  
>> simply
>> has not been done due to a lack of resources, the GCD porting folks
>> could perhaps help move this along, assuming they had appropriate
>> access to the bits.
>>
>> Thanks!
>>
>> - Jordan
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> -- 
> -- 
> Edward O'Callaghan
> http://www.auroraux.org/
> eocallaghan at auroraux dot org
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From astifter-llvm at gmx.at  Wed Sep 16 10:19:30 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Wed, 16 Sep 2009 17:19:30 +0200
Subject: [LLVMdev] FunctionPass Analysis is not saved after ModulePasses run?
Message-ID: <4AB10202.7020601@gmx.at>

Hi,

I have a problem with the following scenario:

I use the ProfileEstimatorPass to get ProfileInfo and verifiy this info with the ProfileVerifierPass. (Please bear with me, its not about the profiling but about the Pass interaction.) Then the LowerSetJumpPass is executed and I want to verify that the esimtated ProfileInfo survives this pass by calling again the ProfileVerifierPass. This is what it looks like:

No Profile Information
   ModulePass Manager
     FunctionPass Manager
       Dominator Tree Construction
       Natural Loop Information
       Profiling information estimator
       Profiling information verifier
     Lower Set Jump
     FunctionPass Manager
       Profiling information verifier
       Preliminary module verification
       Dominator Tree Construction
       Module Verifier
     Bitcode Writer

Unfortunatelly the second execution of the ProfileVerifierPass does not access the ProfileInfo generated by the ProfileEstimator but the one provided by the default ProfileInfo provider (the NoProfileInfo pass).

Even telling the PassManager that LowerSetJumpPass preserves the ProfileInfo (AU.addPreserved<ProfileInfo>();) does not change this behavior.

Is this intentional? I'm currently modifying passes to preserve ProfileInfo through the whole compilation, to be available in the backend so this is a little counter-productive :-)

Is it necessary to add the AU.addPreserved<ProfileInfo>(); to all passes in order for the info to life on?

Thanks, Andi




From e0325716 at student.tuwien.ac.at  Wed Sep 16 10:07:59 2009
From: e0325716 at student.tuwien.ac.at (Andreas Neustifter)
Date: Wed, 16 Sep 2009 17:07:59 +0200
Subject: [LLVMdev] FunctionPass Analysis is not saved after ModulePasses run?
Message-ID: <4AB0FF4F.8020900@student.tuwien.ac.at>

Hi,

I have a problem with the following scenario:

I use the ProfileEstimatorPass to get ProfileInfo and verifiy this info with the ProfileVerifierPass. (Please bear with me, its not about the profiling but about the Pass interaction.) Then the LowerSetJumpPass is executed and I want to verify that the esimtated ProfileInfo survives this pass by calling again the ProfileVerifierPass. This is what it looks like:

No Profile Information
   ModulePass Manager
     FunctionPass Manager
       Dominator Tree Construction
       Natural Loop Information
       Profiling information estimator
       Profiling information verifier
     Lower Set Jump
     FunctionPass Manager
       Profiling information verifier
       Preliminary module verification
       Dominator Tree Construction
       Module Verifier
     Bitcode Writer

Unfortunatelly the second execution of the ProfileVerifierPass does not access the ProfileInfo generated by the ProfileEstimator but the one provided by the default ProfileInfo provider (the NoProfileInfo pass).

Even telling the PassManager that LowerSetJumpPass preserves the ProfileInfo (AU.addPreserved<ProfileInfo>();) does not change this behavior.

Is this intentional? I'm currently modifying passes to preserve ProfileInfo through the whole compilation, to be available in the backend so this is a little counter-productive :-)

Is it necessary to add the AU.addPreserved<ProfileInfo>(); to all passes in order for the info to life on?

Thanks, Andi



From clattner at apple.com  Wed Sep 16 10:49:30 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 16 Sep 2009 08:49:30 -0700
Subject: [LLVMdev] merge request for 2.6
In-Reply-To: <0219F7F1-1B46-467D-B01D-EFE55F0EF4E4@gmail.com>
References: <295e750a0909140751i35b399e6ubf9429b889a109eb@mail.gmail.com>
	<974F30A4-4239-4878-AEBF-0F6C0E3755BF@apple.com>
	<0219F7F1-1B46-467D-B01D-EFE55F0EF4E4@gmail.com>
Message-ID: <D693FE49-1B09-4A2A-AA77-7C3E1A8B6434@apple.com>

Tanya, please pull r80960 into 2.6 if there is still time, thanks!

-Chris


On Sep 16, 2009, at 1:53 AM, Bill Wendling wrote:

> FYI, it should apply cleanly.
>
> -bw
>
> On Sep 14, 2009, at 9:59 AM, Chris Lattner wrote:
>
>> On Sep 14, 2009, at 7:51 AM, Zoltan Varga wrote:
>>>        Hi,
>>>
>>>  Would it be possible to merge this commit:
>>> http://llvm.org/viewvc/llvm-project?view=rev&revision=80960
>>>
>>> to the llvm 2.6 branch ? Without it, incomplete unwind info is  
>>> generated for functions with 0 stack size.
>>
>> Does it apply cleanly to the 2.6 branch?
>>
>> -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  Wed Sep 16 10:50:39 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 16 Sep 2009 08:50:39 -0700
Subject: [LLVMdev] [codegen] how to generate x87 instructions using LLVM
In-Reply-To: <3db9f87f0909160113i29b6cc85p929d22a5abcd6081@mail.gmail.com>
References: <3db9f87f0909160113i29b6cc85p929d22a5abcd6081@mail.gmail.com>
Message-ID: <39EC70C1-6EB1-4754-970E-0FE6752FB26E@apple.com>


On Sep 16, 2009, at 1:13 AM, Simon Zhou wrote:

> Hi All
>
>   I am a greenhand for LLVM.
>
>   I find the LLVM generate SSE instrctions for floating pointing  
> computation, is there some method or options to let it generate x87  
> instructions?

Are you using the low level llvm tools like 'llc'?  If so, pass - 
mattr=-sse to disable SSE codegen, for example:

llc ~/fp.bc -o - -mattr=-sse

-Chris

From vadve at illinois.edu  Wed Sep 16 10:52:22 2009
From: vadve at illinois.edu (Vikram S. Adve)
Date: Wed, 16 Sep 2009 10:52:22 -0500
Subject: [LLVMdev] Type strengthening and type weakening
In-Reply-To: <4AB0828D.7030503@acm.org>
References: <4AB0828D.7030503@acm.org>
Message-ID: <5D44E294-5077-48E9-88F3-036008217FED@illinois.edu>

On Sep 16, 2009, at 1:15 AM, Talin wrote:

> Has anyone done any experiments with regards to type strengthening or
> weakening in the context of LLVM?
>
> For example, the GWT compiler does type strengthening - that is, if  
> you
> are calling a method on an interface or abstract type, and the  
> compiler
> determines through live variable analysis what the concrete type is,
> then it goes ahead and re-writes the type information to be the  
> stronger
> type. The advantage is that it may then be able to do additional
> optimizations, such as inlining the method or avoiding indirect  
> dispatch.

Data Structure Analysis (DSA), available through the llvm-poolalloc  
download, attempts to infer subsets of pointers that are always used  
in a type-consistent manner.  More info is here:

	http://llvm.org/pubs/2007-06-10-PLDI-DSA.html

This can be used to perform the above kind of optimization and several  
others.  DSA is flow-insensitive so it could be strengthened further  
by flow-sensitive analyses built on top of it.


And on Sep 16, 2009, at 2:12 AM, Sebastian Redl wrote:

> Given that LLVM doesn't have much information about the relationships
> between types, would this be worth it? Such an optimization should IMO
> be done by the front-end, which has higher-level information about
> types, such as class hierarchies.

Optimizations that require information in the front-end should be done  
there.  But there are some that can be done effectively at the LLVM  
level, e.g., see:

	http://llvm.org/pubs/2005-05-21-PLDI-PoolAlloc.html

--Vikram
Associate Professor, Computer Science
University of Illinois at Urbana-Champaign
http://llvm.org/~vadve


From clattner at apple.com  Wed Sep 16 11:02:09 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 16 Sep 2009 09:02:09 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <h8qq7d$scp$1@ger.gmane.org>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
	<200909151035.58610.dag@cray.com>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
Message-ID: <06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>


On Sep 16, 2009, at 6:46 AM, Stefano Delli Ponti wrote:

> Olivier Meurant:
>> I have run the john the ripper test.
>> I have used the official archive (same version as phoronix) from
>> http://www.openwall.com/john/g/john-1.7.3.1.tar.bz2
>>
>> To build with llvm-gcc, replace the line CC = gcc with CC = llvm-gcc.
>> I have used the following command to build : make clean linux-x86- 
>> sse2
>> (seems to be the best on x86-32)
>> The makefile invocation is "gcc -c -Wall -O2 -fomit-frame-pointer
>> -funroll-loops src.c" and "llvm-gcc -c -Wall -O2 -fomit-frame-pointer
>> -funroll-loops src.c".
>
> I don't know what you think about this, but shouldn't it be more
> meaningful to make these tests with -O3? I mean, we ought to make the
> comparisons with the highest level of optimization available for  
> both of
> the compilers. It is difficult to compare an intermediate level.

Comparing -O3 (and even -O4) is interesting, but we want all  
optimization levels to perform better than GCC :).  Lots of people use  
-O2 and -Os, so comparing against other compiler's -O2 and -Os levels  
is just as interesting as comparing -O3 vs -O3.

-Chris 

From clattner at apple.com  Wed Sep 16 11:05:45 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 16 Sep 2009 09:05:45 -0700
Subject: [LLVMdev] Type strengthening and type weakening
In-Reply-To: <4AB08FF1.3000800@getdesigned.at>
References: <4AB0828D.7030503@acm.org> <4AB08FF1.3000800@getdesigned.at>
Message-ID: <237F1111-8676-440C-B4BD-CAC74E55DB2D@apple.com>


On Sep 16, 2009, at 12:12 AM, Sebastian Redl wrote:

> Talin wrote:
>> For example, the GWT compiler does type strengthening - that is, if  
>> you
>> are calling a method on an interface or abstract type, and the  
>> compiler
>> determines through live variable analysis what the concrete type is,
>> then it goes ahead and re-writes the type information to be the  
>> stronger
>> type. The advantage is that it may then be able to do additional
>> optimizations, such as inlining the method or avoiding indirect  
>> dispatch.
>>
>> Conversely, Java's "type erasure" is an extreme case of type  
>> weakening -
>> that is, if you have a bunch of functions which operate on similar  
>> types
>> (which might be produced through something like C++ template
>> instantiation), you can throw away all of the information about those
>> types that aren't relevant to those functions, and you may find as a
>> result that many of them become identical and can be merged into a
>> single function.
>>
>> In the context of LLVM, it would be interesting to have a pass that
>> could go through a function and transform the types of the input
>> arguments to be opaque except where the function actually needs the  
>> type
>> information - so for example if a pointer argument is never  
>> dereferenced
>> it can be converted into a void *.
>>
> Given that LLVM doesn't have much information about the relationships
> between types, would this be worth it? Such an optimization should IMO
> be done by the front-end, which has higher-level information about
> types, such as class hierarchies.

Getting this information into the IR is exactly what the extensible  
metadata proposal is all about :)
http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt

-Chris

From jyasskin at google.com  Wed Sep 16 11:53:45 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Wed, 16 Sep 2009 09:53:45 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <352a1fb20909152337u312eea85s2bccd834d3744545@mail.gmail.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<352a1fb20909152337u312eea85s2bccd834d3744545@mail.gmail.com>
Message-ID: <bb55930e0909160953i170e7abdq3b5ee1b60c9c016a@mail.gmail.com>

On Tue, Sep 15, 2009 at 11:37 PM, Devang Patel <devang.patel at gmail.com> wrote:
> On Fri, Sep 11, 2009 at 9:57 AM, Chris Lattner <clattner at apple.com> wrote:
>> Devang's work on debug info prompted this, thoughts welcome:
>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
>
> Here is partial initial implementation.
> Thoughts ?

setHasMetadata probably shouldn't be public, like there's no way to
directly set HasValueHandle.

I'd make the MDKindId type (or typedef) now so it's obvious what those
"unsigned"s mean.

Should the metadata name->id map be per-context or global? I think
it's unlikely people will be registering these things during
compilation, so we can afford the overhead of a lock, and making it
global helps with the wrapper types (avoids one vector lookup). But I
can also change it when I add the wrapper types.

It's too bad we don't have a SmallMap class to give MDInfoTy a good
API and make it efficient at both small and large map sizes.  Maybe
s/MDInfoTy/MDMapTy/ to point out that it's a map from MDKindIds to
MDNodes?

Comment whether RegisterMDKind requires that its argument is
as-yet-unknown in Metadata.h.

Context.pImpl->TheMetadata.ValueIsDeleted(this); in ~Value will always
call the empty ValueIsDeleted(Value*) overload.

Please write a unittest for this.

Metadata::getMDKind(Name) can just be "return MDHandlerNames.lookup(Name)"

Could you comment what the WeakVH in MDPairTy is following? I got
confused and thought it was tracking the Instruction holding the
metadata rather than the MDNode.


You did say this was partial; sorry if I pointed out anything you were
already planning to do.

Jeffrey

From stefano.delliponti at gmail.com  Wed Sep 16 12:05:44 2009
From: stefano.delliponti at gmail.com (Stefano Delli Ponti)
Date: Wed, 16 Sep 2009 19:05:44 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
References: <h8l5cj$tqd$1@ger.gmane.org>	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>	<200909151035.58610.dag@cray.com>	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>	<4AB0AE6E.5090409@gmail.com>	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
Message-ID: <4AB11AE8.4020701@gmail.com>

Chris Lattner:
> Comparing -O3 (and even -O4) is interesting, but we want all  
> optimization levels to perform better than GCC :).  Lots of people use  
> -O2 and -Os, so comparing against other compiler's -O2 and -Os levels  
> is just as interesting as comparing -O3 vs -O3.
> 

My thinking was that, for instance, -02 for GCC and -02 for LLVM(-GCC) 
do not necessarily mean the same thing, they may be not /commensurable/.
But perhaps, my ignorance, you are saying that they _are_, that LLVM 
assigns the same types of optimizations as GCC to the different levels.

Regards,
Stefano



From stefano.delliponti at gmail.com  Wed Sep 16 12:05:44 2009
From: stefano.delliponti at gmail.com (Stefano Delli Ponti)
Date: Wed, 16 Sep 2009 19:05:44 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
References: <h8l5cj$tqd$1@ger.gmane.org>	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>	<200909151035.58610.dag@cray.com>	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>	<4AB0AE6E.5090409@gmail.com>	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
Message-ID: <4AB11AE8.4020701@gmail.com>

Chris Lattner:
> Comparing -O3 (and even -O4) is interesting, but we want all  
> optimization levels to perform better than GCC :).  Lots of people use  
> -O2 and -Os, so comparing against other compiler's -O2 and -Os levels  
> is just as interesting as comparing -O3 vs -O3.
> 

My thinking was that, for instance, -02 for GCC and -02 for LLVM(-GCC) 
do not necessarily mean the same thing, they may be not /commensurable/.
But perhaps, my ignorance, you are saying that they _are_, that LLVM 
assigns the same types of optimizations as GCC to the different levels.

Regards,
Stefano



From clattner at apple.com  Wed Sep 16 12:11:05 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 16 Sep 2009 10:11:05 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <4AB11AE8.4020701@gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>
	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>
	<200909151035.58610.dag@cray.com>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
Message-ID: <F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>


On Sep 16, 2009, at 10:05 AM, Stefano Delli Ponti wrote:

> Chris Lattner:
>> Comparing -O3 (and even -O4) is interesting, but we want all   
>> optimization levels to perform better than GCC :).  Lots of people  
>> use  -O2 and -Os, so comparing against other compiler's -O2 and -Os  
>> levels  is just as interesting as comparing -O3 vs -O3.
>
> My thinking was that, for instance, -02 for GCC and -02 for LLVM(- 
> GCC) do not necessarily mean the same thing, they may be not / 
> commensurable/.
> But perhaps, my ignorance, you are saying that they _are_, that LLVM  
> assigns the same types of optimizations as GCC to the different  
> levels.

Right, we want them to be roughly comparable.

O0 -> best debug experience, fastest compile times.
O2 -> optimize without bloating the code too much and without burning  
*too* many cycles.
O3 -> take more time and produce fatter code to get faster code.

O1 is something of a wasteland with no clear purpose :)

-Chris

From devang.patel at gmail.com  Wed Sep 16 12:11:33 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Wed, 16 Sep 2009 10:11:33 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <bb55930e0909160953i170e7abdq3b5ee1b60c9c016a@mail.gmail.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<352a1fb20909152337u312eea85s2bccd834d3744545@mail.gmail.com>
	<bb55930e0909160953i170e7abdq3b5ee1b60c9c016a@mail.gmail.com>
Message-ID: <352a1fb20909161011jbde3bc7jc75413ca68a3d317@mail.gmail.com>

On Wed, Sep 16, 2009 at 9:53 AM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> On Tue, Sep 15, 2009 at 11:37 PM, Devang Patel <devang.patel at gmail.com> wrote:
>> On Fri, Sep 11, 2009 at 9:57 AM, Chris Lattner <clattner at apple.com> wrote:
>>> Devang's work on debug info prompted this, thoughts welcome:
>>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt
>>
>> Here is partial initial implementation.
>> Thoughts ?
>
> setHasMetadata probably shouldn't be public, like there's no way to
> directly set HasValueHandle.

that means making llvm::Metadata a friend of llvm::Value. fine.

> I'd make the MDKindId type (or typedef) now so it's obvious what those
> "unsigned"s mean.

OK

> Should the metadata name->id map be per-context or global? I think
> it's unlikely people will be registering these things during
> compilation, so we can afford the overhead of a lock, and making it
> global helps with the wrapper types (avoids one vector lookup). But I
> can also change it when I add the wrapper types.
>
> It's too bad we don't have a SmallMap class to give MDInfoTy a good
> API and make it efficient at both small and large map sizes. ?Maybe
> s/MDInfoTy/MDMapTy/ to point out that it's a map from MDKindIds to
> MDNodes?

ok


> Comment whether RegisterMDKind requires that its argument is
> as-yet-unknown in Metadata.h.

ok

> Context.pImpl->TheMetadata.ValueIsDeleted(this); in ~Value will always
> call the empty ValueIsDeleted(Value*) overload.
>
> Please write a unittest for this.
>
> Metadata::getMDKind(Name) can just be "return MDHandlerNames.lookup(Name)"

ok

> Could you comment what the WeakVH in MDPairTy is following? I got
> confused and thought it was tracking the Instruction holding the
> metadata rather than the MDNode.

Instruction can hold either MDNode or MDString. MDNode can be replaced
transparently by the MDNode uniquing scheme, so its holder should
always use WeakVH.


> You did say this was partial; sorry if I pointed out anything you were
> already planning to do.

I meant, this only covers basic metadata storage. Change required in
llvm parser/printer, bitcode reader/writer, IR builder and test cases
are missing :)

-
Devang


From devang.patel at gmail.com  Wed Sep 16 12:18:36 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Wed, 16 Sep 2009 10:18:36 -0700
Subject: [LLVMdev] FunctionPass Analysis is not saved after ModulePasses
	run?
In-Reply-To: <4AB0FF4F.8020900@student.tuwien.ac.at>
References: <4AB0FF4F.8020900@student.tuwien.ac.at>
Message-ID: <352a1fb20909161018r60f11cbcla8afa35bb5a3c82d@mail.gmail.com>

On Wed, Sep 16, 2009 at 8:07 AM, Andreas Neustifter
<e0325716 at student.tuwien.ac.at> wrote:
> Hi,
>
> I have a problem with the following scenario:
>
> I use the ProfileEstimatorPass to get ProfileInfo and verifiy this info with the ProfileVerifierPass. (Please bear with me, its not about the profiling but about the Pass interaction.) Then the LowerSetJumpPass is executed and I want to verify that the esimtated ProfileInfo survives this pass by calling again the ProfileVerifierPass. This is what it looks like:
>
> No Profile Information
> ? ModulePass Manager
> ? ? FunctionPass Manager
> ? ? ? Dominator Tree Construction
> ? ? ? Natural Loop Information
> ? ? ? Profiling information estimator
> ? ? ? Profiling information verifier
> ? ? Lower Set Jump
> ? ? FunctionPass Manager
> ? ? ? Profiling information verifier
> ? ? ? Preliminary module verification
> ? ? ? Dominator Tree Construction
> ? ? ? Module Verifier
> ? ? Bitcode Writer
>
> Unfortunatelly the second execution of the ProfileVerifierPass does not access the ProfileInfo generated by the ProfileEstimator but the one provided by the default ProfileInfo provider (the NoProfileInfo pass).
>

I have not studied Profile* passes in detail but, if you have function
F1 and F2 in your module then execution sequence is

No Profile Information
  ModulePass Manager
    FunctionPass Manager
      Dominator Tree Construction  - F1
      Natural Loop Information        - F1
      Profiling information estimator - F1
      Profiling information verifier     - F1

      Dominator Tree Construction  - F2
      Natural Loop Information        - F2
      Profiling information estimator - F2
      Profiling information verifier     - F2

    Lower Set Jump - F1 & F2

At this point, last run of profile information estimator  operated on
F2 and it was released at then end of FunctionPass manager  before
Lower Set Jump pass run.

    FunctionPass Manager
      Profiling information verifier  - F1
      Preliminary module verification - F1

Use -debug-pass=Details command line option to understand pass
execution sequence.

-
Devang


From daniel at zuster.org  Wed Sep 16 12:36:21 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Wed, 16 Sep 2009 10:36:21 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
Message-ID: <6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>

Since we are in the area, what *should* O1 do?

It's basically good for nothing, since it doesn't tune for size or
performance. The only good I personally ever have for it is once in a
while there is a miscompile at -O1 which narrows the problem.

Would it be crazy to make -O1 equivalent to -Os?

 - Daniel

On Wednesday, September 16, 2009, Chris Lattner <clattner at apple.com> wrote:
>
> On Sep 16, 2009, at 10:05 AM, Stefano Delli Ponti wrote:
>
>> Chris Lattner:
>>> Comparing -O3 (and even -O4) is interesting, but we want all
>>> optimization levels to perform better than GCC :). ?Lots of people
>>> use ?-O2 and -Os, so comparing against other compiler's -O2 and -Os
>>> levels ?is just as interesting as comparing -O3 vs -O3.
>>
>> My thinking was that, for instance, -02 for GCC and -02 for LLVM(-
>> GCC) do not necessarily mean the same thing, they may be not /
>> commensurable/.
>> But perhaps, my ignorance, you are saying that they _are_, that LLVM
>> assigns the same types of optimizations as GCC to the different
>> levels.
>
> Right, we want them to be roughly comparable.
>
> O0 -> best debug experience, fastest compile times.
> O2 -> optimize without bloating the code too much and without burning
> *too* many cycles.
> O3 -> take more time and produce fatter code to get faster code.
>
> O1 is something of a wasteland with no clear purpose :)
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From echristo at apple.com  Wed Sep 16 12:52:56 2009
From: echristo at apple.com (Eric Christopher)
Date: Wed, 16 Sep 2009 10:52:56 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
	<6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
Message-ID: <1C4F63F7-2A63-40B3-AFC6-813D12676FEB@apple.com>


On Sep 16, 2009, at 10:36 AM, Daniel Dunbar wrote:

> Since we are in the area, what *should* O1 do?
>
> It's basically good for nothing, since it doesn't tune for size or
> performance. The only good I personally ever have for it is once in a
> while there is a miscompile at -O1 which narrows the problem.
>
> Would it be crazy to make -O1 equivalent to -Os?

I've always used O1 for a quick cleanup so that my debug code doesn't  
completely suck, but hasn't been optimized into oblivion for gdb.   
Also makes looking at the resultant assembly dumps fairly easy.

But yes, that'd be crazy :)

-eric

From mrs at apple.com  Wed Sep 16 12:54:34 2009
From: mrs at apple.com (Mike Stump)
Date: Wed, 16 Sep 2009 10:54:34 -0700
Subject: [LLVMdev] [proposal] Extensible IR metadata
In-Reply-To: <352a1fb20909152337u312eea85s2bccd834d3744545@mail.gmail.com>
References: <0FFEC9C7-0E7D-46F5-AC58-B7D563267955@apple.com>
	<352a1fb20909152337u312eea85s2bccd834d3744545@mail.gmail.com>
Message-ID: <2923E02A-CC6F-4D63-8C78-DA12BFD1CF0F@apple.com>

On Sep 15, 2009, at 11:37 PM, Devang Patel wrote:
> Here is partial initial implementation.

+  /// setMD - Atttach the metadata of given kind with an Instruction.
+  void setMD(unsigned MDKind, MDNode *Node, Instruction *Inst);

Spelling: Attach.

+/// setMD - Atttach the metadata of given kind with an Instruction.
+void Metadata::setMD(unsigned MDKind, MDNode *Node, Instruction  
*Inst) {

Spelling: Attach.

From gohman at apple.com  Wed Sep 16 12:55:58 2009
From: gohman at apple.com (Dan Gohman)
Date: Wed, 16 Sep 2009 10:55:58 -0700
Subject: [LLVMdev] struct returns
In-Reply-To: <400d33ea0909160558kd7fd636m12a63ee2bcbcc752@mail.gmail.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
	<FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
	<400d33ea0909160558kd7fd636m12a63ee2bcbcc752@mail.gmail.com>
Message-ID: <01C8409B-A919-48F4-BEA6-6C9CA25B49DD@apple.com>


On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote:

>> I recently made a major reorganization of the calling-convention
>> lowering code which cleared away one of the major obstacles to
>> doing this within codegen.
>>
>> Dan
>
> So what was the obstacle, and how was it cleared?

The biggest obstacle is that there used to be two different methods
for lowering call arguments; some of the targets used on and some
used another. There wasn't a good reason for having two, but no one
had taken the time to update all the targets. Now, all targets are
using the same basic set of hooks. And, the hooks are more
straight-forward than the mechanisms they replaced.

>  And how do you see
> the large struct return working in codegen?

One part of the action will be in
lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp. This is where LLVM IR
is translated into the special-purpose instruction-selection IR, which
is lower-level. Calls are split up into multiple parts which are
eventually lowered into the actual instructions for the calling
sequence. The main areas of attention will be

SelectionDAGISel::LowerArguments
SelectionDAGLowering::LowerCallTo
SelectionDAGLowering::visitRet

These functions are responsible for breaking up LLVM IR values into
register-sized pieces and handing them off to target-specific code
through these virtual functions:

TLI.LowerFormalArguments
TLI.LowerCall
TLI.LowerReturn

(Actually, SelectionDAGLowering::LowerCallTo calls
TargetLowering::LowerCallTo, which calls TargetLowering::LowerCall,
for historical reasons.)

Basically, the task here is to interpose code which will recognize
when an automatic sret is needed, set up a static alloca to hold the
value (see the StaticAllocaMap), and adjust the argument list and
return code accordingly.

For recognizing when an sret is needed, it'll be necessary to know
what the target supports. This is described in the targets'
*CallingConv.td files. Currently the consumer of this information
is the CallingConvLowering code in

include/llvm/CodeGen/CallingConvLower.h
lib/CodeGen/SelectionDAG/CallingConvLower.cpp

This code is currently used from within the target-specific code
inside LowerFormalArguments and friends. However, it could also
be called from the SelectionDAGBuild directly to determine
if there are sufficient registers. It'll need to be extended
some, because it calls llvm_unreachable() when it runs
out of registers, which is the behavior we're trying to avoid
here :-).

If you're not familiar with the SelectionDAG IR, feel free to
ask questions. I recommend using the -view-dag-combine1-dags
option, which provides a visualization of the SelectionDAG for
each basic block immediately after it has been constructed, to
get an idea of what's being built.

>
> Anything you care to tell me would be welcome.  I will be starting on
> this today or tomorrow.

Ok, let me know if I can answer any questions.

Dan


From ofv at wanadoo.es  Wed Sep 16 12:56:48 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Wed, 16 Sep 2009 19:56:48 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
	<6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
Message-ID: <873a6mojrz.fsf@telefonica.net>

Daniel Dunbar <daniel at zuster.org> writes:

> Since we are in the area, what *should* O1 do?

"Try to produce fast code but do not apply transformations that makes
debugging hard"

-- 
?scar


From clattner at apple.com  Wed Sep 16 13:07:41 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 16 Sep 2009 11:07:41 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>
	<4AB0AE6E.5090409@gmail.com>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
	<6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
Message-ID: <E3109D88-097E-4B32-89BA-8642A17D4282@apple.com>


On Sep 16, 2009, at 10:36 AM, Daniel Dunbar wrote:

> Since we are in the area, what *should* O1 do?
>
> It's basically good for nothing, since it doesn't tune for size or
> performance. The only good I personally ever have for it is once in a
> while there is a miscompile at -O1 which narrows the problem.
>
> Would it be crazy to make -O1 equivalent to -Os?

That works for me! :-)

From rengolin at systemcall.org  Wed Sep 16 14:10:21 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Wed, 16 Sep 2009 20:10:21 +0100
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <1C4F63F7-2A63-40B3-AFC6-813D12676FEB@apple.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
	<6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
	<1C4F63F7-2A63-40B3-AFC6-813D12676FEB@apple.com>
Message-ID: <d9b9d95f0909161210r15fc35e6mc77e86f380ef1c61@mail.gmail.com>

2009/9/16 Eric Christopher <echristo at apple.com>:
> Also makes looking at the resultant assembly dumps fairly easy.
>
> But yes, that'd be crazy :)

My father prefers that to writing assembly code directly. Seems like a
pretty normal thing to do...

Crazy is producing assembly directly, which he still does most of the time... ;)

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From aaronngray.lists at googlemail.com  Wed Sep 16 15:28:55 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 16 Sep 2009 21:28:55 +0100
Subject: [LLVMdev] [OT] GCC specs language and adding options
Message-ID: <9719867c0909161328i79b479aie13808b0b92c09bb@mail.gmail.com>

Hi,
I have been trying to get to grips with GCC's specs language in order to add
COFF and ELF emission options.

I have noticed that the '-emit-llvm-bc' option does not appear to work at
all either with -S or without, giving :-

    llvm-gcc: unrecognized option '-emit-llvm-bc'

Also this seems by default seems for '-emit-llvm' to produce a '.o' file
instead of a '.bc' file extension, unless using a '-o' option and overriding
the filename.

The LLVM code is as follows :-

"%{O4|emit-llvm|flto:%{S:-emit-llvm} %{!S:-emit-llvm-bc %{c: %W{o*} %{!o*:-o
%b%w.o}} %{!c:-o %d%w%u%O}}}"

So we have '-O4', '-emit-llvm', and '-flto' equivalent options.

What I out like is either a '-emit-llvm-coff' and '-emit-llvm-elf' or
ideally an '-emit-llvm=coff' if this can be done transparently with an
'-emit-llvm' functioning normally.

Any Help welcome !

Many thanks in advance,

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/699f8570/attachment.html 

From jalbert at eecs.berkeley.edu  Wed Sep 16 15:34:21 2009
From: jalbert at eecs.berkeley.edu (Nick Jalbert)
Date: Wed, 16 Sep 2009 13:34:21 -0700
Subject: [LLVMdev] llc and debug information
Message-ID: <12af9dc80909161334r527ba1fci69090b8d7e416d3b@mail.gmail.com>

Hi all,

I'm having an issue with debug information and llc.  A test program:

#include <iostream>

using namespace std;

void foo() {
    cout << "My return address is " << __builtin_return_address(0) <<
        endl << flush;
}

int main(int argc, char *argv[]) {
    foo();
    return 0;
}


When I compile my test program to LLVM bytecode, and then use llc to take
the bytecode to assembly, llc appears to strip the debugging information
along the way:

> llvm-g++ -g -c -emit-llvm test.cpp
> llc test.o
> g++ test.o.s
> ./a.out
My return address is 0x400b92
> addr2line 0x400b92
??:0

My goal is to run a transformation pass on the bytecode to put in a few
instrumentation hooks for a dynamic analysis I'm writing.  Debug
information, even if it's a little off, would be extremely useful to have in
the final binary.  This build chain worked with a 2.6svn version of llc
(that is, the final binary would have debug information which corresponded
reasonably well to the source.  Also it seemed to work when this question
was sent http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-April/021697.html),
but I recently upgraded to a 2.7svn version with the results above.  Is this
change intended?  Is there a way tell llc to keep debug information in?

Thanks!
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/06872df2/attachment.html 

From rengolin at systemcall.org  Wed Sep 16 15:56:21 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Wed, 16 Sep 2009 21:56:21 +0100
Subject: [LLVMdev] llc and debug information
In-Reply-To: <12af9dc80909161334r527ba1fci69090b8d7e416d3b@mail.gmail.com>
References: <12af9dc80909161334r527ba1fci69090b8d7e416d3b@mail.gmail.com>
Message-ID: <d9b9d95f0909161356r3f96867fma2eb4ec9e2ad4a65@mail.gmail.com>

2009/9/16 Nick Jalbert <jalbert at eecs.berkeley.edu>:
>> llvm-g++ -g -c -emit-llvm test.cpp

I always use -O0 together with -g because I had far too many problems
of the like already to define on the fly if it's safe or not *not* to
use it.

Maybe that helps...

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From devang.patel at gmail.com  Wed Sep 16 16:29:29 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Wed, 16 Sep 2009 14:29:29 -0700
Subject: [LLVMdev] llc and debug information
In-Reply-To: <12af9dc80909161334r527ba1fci69090b8d7e416d3b@mail.gmail.com>
References: <12af9dc80909161334r527ba1fci69090b8d7e416d3b@mail.gmail.com>
Message-ID: <352a1fb20909161429h7a384053n767c215779c04e6e@mail.gmail.com>

On Wed, Sep 16, 2009 at 1:34 PM, Nick Jalbert <jalbert at eecs.berkeley.edu> wrote:
> Hi all,
> I'm having an issue with debug information and llc. ?A test program:
> #include <iostream>
> using namespace std;
> void foo() {
> ?? ?cout << "My return address is " << __builtin_return_address(0) <<
> ?? ? ? ?endl << flush;
> }
> int main(int argc, char *argv[]) {
> ?? ?foo();
> ?? ?return 0;
> }
>
> When I compile my test program to LLVM bytecode, and then use llc to take
> the bytecode to assembly, llc appears to strip the debugging information
> along the way:
>> llvm-g++ -g -c -emit-llvm test.cpp
>> llc test.o

try -O0 in llc command line.
-
Devang


From rayfix.ml at gmail.com  Wed Sep 16 16:38:26 2009
From: rayfix.ml at gmail.com (Ray Fix)
Date: Wed, 16 Sep 2009 17:38:26 -0400
Subject: [LLVMdev] Suppressing cmake's LLVM_ENABLE_PIC for the Xcode
	generator
Message-ID: <BA824A5E-81DB-41C3-9175-86D0172A0FE0@gmail.com>

Hi,

If you create an Xcode project with

     cmake -G Xcode ~/llvm

and do a build, you end up with 68 warnings like this:

  -mdynamic-no-pic overrides -fpic or -fPIC

This can be easily avoided doing:

   cmake -G Xcode -ULLVM_ENABLE_PIC ~/llvm

But I think it would be nicer if it built warning-free with the  
simpler form.




What do you think?

Ray

PS: CMake generated make style builds on Mac OS X don't use the - 
mdynamic-no-pic, so I guess you want -fPIC enabled there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/1c0a639a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undef_llvm_enable_pic_for_xcode.patch.patch
Type: application/octet-stream
Size: 571 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/1c0a639a/attachment.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/1c0a639a/attachment-0001.html 

From jalbert at eecs.berkeley.edu  Wed Sep 16 18:02:03 2009
From: jalbert at eecs.berkeley.edu (Nick Jalbert)
Date: Wed, 16 Sep 2009 16:02:03 -0700
Subject: [LLVMdev] llc and debug information
In-Reply-To: <352a1fb20909161429h7a384053n767c215779c04e6e@mail.gmail.com>
References: <12af9dc80909161334r527ba1fci69090b8d7e416d3b@mail.gmail.com>
	<352a1fb20909161429h7a384053n767c215779c04e6e@mail.gmail.com>
Message-ID: <12af9dc80909161602k1021614mbf79c5dd62a051a4@mail.gmail.com>

Thanks for the quick responses, but unfortunately still no luck:
> llvm-g++ -g -O0 -c -emit-llvm test.cpp
> llc -O0 test.o
> g++ test.o.s
> ./a.out
My return address is 0x400bb2
> addr2line 0x400bb2
??:0

Also to further implicate llc, this works:

> llvm-g++ -g -O0 -S test.cpp
> g++ test.s
> ./a.out
My return address is 0x400bf9
> addr2line 0x400bf9
/home/jalbert/llvmtest//test.cpp:13

Anymore thoughts?

-Nick


On Wed, Sep 16, 2009 at 2:29 PM, Devang Patel <devang.patel at gmail.com>wrote:

> On Wed, Sep 16, 2009 at 1:34 PM, Nick Jalbert <jalbert at eecs.berkeley.edu>
> wrote:
> > Hi all,
> > I'm having an issue with debug information and llc.  A test program:
> > #include <iostream>
> > using namespace std;
> > void foo() {
> >     cout << "My return address is " << __builtin_return_address(0) <<
> >         endl << flush;
> > }
> > int main(int argc, char *argv[]) {
> >     foo();
> >     return 0;
> > }
> >
> > When I compile my test program to LLVM bytecode, and then use llc to take
> > the bytecode to assembly, llc appears to strip the debugging information
> > along the way:
> >> llvm-g++ -g -c -emit-llvm test.cpp
> >> llc test.o
>
> try -O0 in llc command line.
> -
> Devang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090916/5c5d888f/attachment.html 

From ahmadsharif at hotmail.com  Wed Sep 16 20:55:02 2009
From: ahmadsharif at hotmail.com (madiyaan)
Date: Wed, 16 Sep 2009 18:55:02 -0700 (PDT)
Subject: [LLVMdev]  Forcing function inline not working
Message-ID: <25483934.post@talk.nabble.com>


I have the following code:

static inline void foo() __attribute((always_inline));

int a;
static inline void foo()
{
  a++;
}

int main(int argc, char *argv[])
{
  foo();
  return 0;
}


However, the code generated by llvm 2.4 toolchain does not inline this
function. opt retains the function call. Here is the output when I try to
compile with -debug-only=inline:

..\..\..\win32\bin\win32\debug\opt.exe -O3 -debug-only=inline -mem2reg -f -o
test_opt.bc test.bc
Inliner visiting SCC: foo: 0 call sites.
Inliner visiting SCC: main: 1 call sites.
    Inlining: cost=always, Call:        call void (...)* @foo()
Inliner visiting SCC: INDIRECTNODE: 0 call sites.

Here is the .ll file:

; ModuleID = 'test_opt.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-win32"
@a = common global i32 0, align 4		; <i32*> [#uses=2]

define i32 @main(i32 %argc, i8** %argv) nounwind {
entry:
	tail call void (...)* @foo()
	ret i32 0
}

define internal void @foo(...) nounwind alwaysinline {
entry:
	%tmp = load i32* @a		; <i32> [#uses=1]
	%inc = add i32 %tmp, 1		; <i32> [#uses=1]
	store i32 %inc, i32* @a
	ret void
}


What am I doing wrong here? Is there a way to force a function to be inlined
by opt?

Best Regards,
-- 
View this message in context: http://www.nabble.com/Forcing-function-inline-not-working-tp25483934p25483934.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From dalej at apple.com  Wed Sep 16 22:17:49 2009
From: dalej at apple.com (Dale Johannesen)
Date: Wed, 16 Sep 2009 20:17:49 -0700
Subject: [LLVMdev] Forcing function inline not working
In-Reply-To: <25483934.post@talk.nabble.com>
References: <25483934.post@talk.nabble.com>
Message-ID: <92BA3A99-DBA9-488D-BC70-48CF4673B341@apple.com>


On Sep 16, 2009, at 6:55 PM, madiyaan wrote:

>
> I have the following code:
>
> static inline void foo() __attribute((always_inline));
>
> int a;
> static inline void foo()
> {
>  a++;
> }
>
> int main(int argc, char *argv[])
> {
>  foo();
>  return 0;
> }

This works fine in current sources.  You should upgrade; 2.5 has been  
out for a while and 2.6 will be soon.

> However, the code generated by llvm 2.4 toolchain does not inline this
> function. opt retains the function call. Here is the output when I  
> try to
> compile with -debug-only=inline:
>
> ..\..\..\win32\bin\win32\debug\opt.exe -O3 -debug-only=inline - 
> mem2reg -f -o
> test_opt.bc test.bc
> Inliner visiting SCC: foo: 0 call sites.
> Inliner visiting SCC: main: 1 call sites.
>    Inlining: cost=always, Call:        call void (...)* @foo()
> Inliner visiting SCC: INDIRECTNODE: 0 call sites.
>
> Here is the .ll file:
>
> ; ModuleID = 'test_opt.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-win32"
> @a = common global i32 0, align 4		; <i32*> [#uses=2]
>
> define i32 @main(i32 %argc, i8** %argv) nounwind {
> entry:
> 	tail call void (...)* @foo()
> 	ret i32 0
> }
>
> define internal void @foo(...) nounwind alwaysinline {
> entry:
> 	%tmp = load i32* @a		; <i32> [#uses=1]
> 	%inc = add i32 %tmp, 1		; <i32> [#uses=1]
> 	store i32 %inc, i32* @a
> 	ret void
> }
>
>
> What am I doing wrong here? Is there a way to force a function to be  
> inlined
> by opt?
>
> Best Regards,
> -- 
> View this message in context: http://www.nabble.com/Forcing-function-inline-not-working-tp25483934p25483934.html
> Sent from the LLVM - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> 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  Thu Sep 17 04:15:37 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 17 Sep 2009 11:15:37 +0200
Subject: [LLVMdev] [OT] GCC specs language and adding options
In-Reply-To: <9719867c0909161328i79b479aie13808b0b92c09bb@mail.gmail.com>
References: <9719867c0909161328i79b479aie13808b0b92c09bb@mail.gmail.com>
Message-ID: <4AB1FE39.1040909@free.fr>

Hi Aaron Gray,

> I have been trying to get to grips with GCC's specs language in order to 
> add COFF and ELF emission options.
> 
> I have noticed that the '-emit-llvm-bc' option does not appear to work 
> at all either with -S or without, giving :-
> 
>     llvm-gcc: unrecognized option '-emit-llvm-bc'

you should use -emit-llvm.  If used with -S then this gets passed to the
backend (cc1 for example) as -emit-llvm; if used with -c then it gets
passed as -emit-llvm-bc.  So -emit-llvm-bc is an internal flag that
users don't need to know about.

> Also this seems by default seems for '-emit-llvm' to produce a '.o' file 
> instead of a '.bc' file extension, unless using a '-o' option and 
> overriding the filename.

The output is placed in whatever output file gcc would normally use,
so .o if -emit-llvm is used with -c, .s if used with -S.  This is
needed to make lto transparent: if -emit-llvm caused .bc to be generated
rather than .o then that would break makefiles etc.  As it is you can
add -emit-llvm to your CFLAGS and have everything work without any
change to your makefile (assuming you have LLVM aware system tools, like
the gold linker).

> What I out like is either a '-emit-llvm-coff' and '-emit-llvm-elf' or 
> ideally an '-emit-llvm=coff' if this can be done transparently with an 
> '-emit-llvm' functioning normally.

This doesn't make much sense to me.  LLVM bitcode is the same whether
the final object file will be elf or coff.  Since -emit-llvm means to
output LLVM bitcode or LLVM assembler, elf/coff doesn't seem relevant.
Elf/coff is a codegen option.

Ciao,

Duncan.

From baldrick at free.fr  Thu Sep 17 04:20:03 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 17 Sep 2009 11:20:03 +0200
Subject: [LLVMdev] llc and debug information
In-Reply-To: <12af9dc80909161602k1021614mbf79c5dd62a051a4@mail.gmail.com>
References: <12af9dc80909161334r527ba1fci69090b8d7e416d3b@mail.gmail.com>	<352a1fb20909161429h7a384053n767c215779c04e6e@mail.gmail.com>
	<12af9dc80909161602k1021614mbf79c5dd62a051a4@mail.gmail.com>
Message-ID: <4AB1FF43.3000409@free.fr>

Nick Jalbert wrote:
> Thanks for the quick responses, but unfortunately still no luck:
> 
>  > llvm-g++ -g -O0 -c -emit-llvm test.cpp
>  > llc -O0 test.o
>  > g++ test.o.s
>  > ./a.out 
> My return address is 0x400bb2
>  > addr2line 0x400bb2
> ??:0
> 
> Also to further implicate llc, this works:
> 
>  > llvm-g++ -g -O0 -S test.cpp 
>  > g++ test.s 
>  > ./a.out 
> My return address is 0x400bf9
>  > addr2line 0x400bf9
> /home/jalbert/llvmtest//test.cpp:13
> 
> Anymore thoughts?

maybe try passing -disable-fp-elim to llc?

Ciao,

Duncan.

From isanbard at gmail.com  Thu Sep 17 04:55:49 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Thu, 17 Sep 2009 02:55:49 -0700
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <4AB0ED25.60404@math.u-psud.fr>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
	<4AB0ED25.60404@math.u-psud.fr>
Message-ID: <8C3D88DB-C5D0-4DCE-9733-5666D6731FD2@gmail.com>

On Sep 16, 2009, at 6:50 AM, Duncan Sands wrote:

> Hi Bill,
>
>> The reason to ask this is that
>>> it could make the EH tables smaller and less cluttered if we  
>>> elide  those areas which we know don't throw (the functions called  
>>> are marked  'nounwind', etc.).
>> Sure, that's what the SawPotentiallyThrowing boolean is for.  It is
>> currently set for any call, but in fact needn't be set for 'nounwind'
>> calls.  When I wrote this stuff 'nounwind' information wasn't  
>> available
>> at the codegen level, which is why this isn't done.  In case you  
>> care,
>> doing this would not hurt Ada :)
>
> now I think about it further, I guess SawPotentiallyThrowing is not  
> for
> this exactly, you'll need to add some additional logic near this  
> place.
>
Yeah. The logic will need tweaking for sure. I'm also concerned about  
the _Unwind_resume() call. GCC emits a call site region for it in the  
exception table. We...kind of do that. It looks like it's being  
included in one of the "this is a region which isn't in a try-catch  
block, but it has a call in it, so lets add it to the exception table"  
areas. If I implement my suggestion, this will likely go away. I think  
Eric's working on something that will add the _Unwind_resume() call  
during selection DAG time, where we can place EH labels around it. But  
it's just another thing I have to worry about when doing this. :-)

-bw


From duncan.sands at math.u-psud.fr  Thu Sep 17 05:40:59 2009
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Thu, 17 Sep 2009 12:40:59 +0200
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <8C3D88DB-C5D0-4DCE-9733-5666D6731FD2@gmail.com>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
	<4AB0ED25.60404@math.u-psud.fr>
	<8C3D88DB-C5D0-4DCE-9733-5666D6731FD2@gmail.com>
Message-ID: <4AB2123B.3020807@math.u-psud.fr>

Hi Bill,

> Yeah. The logic will need tweaking for sure. I'm also concerned about 
> the _Unwind_resume() call. GCC emits a call site region for it in the 
> exception table. We...kind of do that. It looks like it's being included 
> in one of the "this is a region which isn't in a try-catch block, but it 
> has a call in it, so lets add it to the exception table" areas.

isn't that exactly how it should be?  This is a call that will unwind
out of the function, so C++ requires it to have a call site region just
like any other call that we want to let unwind out of the function.  I
don't see why it needs any special logic.  If I understood right the
change you want to make is that if a call is known not to unwind then
you want to omit adding a call-site entry if that saves some space in
the call site table, which seems irrelevant to this, or am I missing
something?  By the way, LLVM "nounwind" calls are different to GCC no
throw regions IIRC.  If an exception is thrown in a GCC no throw region
then it must (C++) result in a call to "terminate".  These are not
mapped to "nounwind", instead we create explicit "catch-all" filter
expressions for this (IIRC).  In LLVM it is undefined what happens if
a call is marked "nounwind" but nonetheless an exception unwinds out
of it.  Thus you can add call-site entries for nounwind calls,
or not add them, as you like - whatever is most convenient (eg: saves
the most space).  An interesting optimization which we don't do is to
identify which calls correspond to a "catch-all" filter and not generate
an entry for them in the call-site table (no need to add the filter
either) - this saves space and the C++ runtime knows to handle this
just like if we added the filter explicitly.

If I
> implement my suggestion, this will likely go away. I think Eric's 
> working on something that will add the _Unwind_resume() call during 
> selection DAG time, where we can place EH labels around it. But it's 
> just another thing I have to worry about when doing this. :-)

I don't see why _Unwind_resume needs special handling.  That said,
I'm not opposed to having "unwind" be turned into a special SDAG node
which targets can handle specially.  I didn't do that because it seemed
awkward and not that useful (since targets can already specify whether
they want to call _Unwind_Resume or something else).

Ciao,

Duncan.

From zhunansjtu at gmail.com  Thu Sep 17 07:49:29 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Thu, 17 Sep 2009 20:49:29 +0800
Subject: [LLVMdev] Where should I put libLLVMgold.so??
Message-ID: <1253191769.4354.6.camel@UIUC>

Hi,all

I'm using ubuntu8.04 and I'm installing gold-plugin along with the
document of that,

After I built the binutils and LLVM with plugin enabling,and I also
replace ld with ld-new which supports plugin,I tried to compile a hello
world program by this:

llvm-gcc -use-gold-plugin a.a b.o -o hello

which is similar with the example in the document,it tells me that
libLLVMgold.so can not be found ,but I truly put it in the directory
which is the same as the cc1's.

What's the problem with my libLLVMgold.so's position?

Thanks!

Nan




From espindola at google.com  Thu Sep 17 08:49:54 2009
From: espindola at google.com (Rafael Espindola)
Date: Thu, 17 Sep 2009 09:49:54 -0400
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <1253191769.4354.6.camel@UIUC>
References: <1253191769.4354.6.camel@UIUC>
Message-ID: <38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>

> llvm-gcc -use-gold-plugin a.a b.o -o hello
>
> which is similar with the example in the document,it tells me that
> libLLVMgold.so can not be found ,but I truly put it in the directory
> which is the same as the cc1's.
>
> What's the problem with my libLLVMgold.so's position?

That looks correct. Can you check that
*) It is the correct cc1 :-) (run llvm-gcc with -v)
*) It works if you call gold directly with it

> Thanks!
>
> Nan
>


Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

From ahmadsharif at hotmail.com  Thu Sep 17 11:45:14 2009
From: ahmadsharif at hotmail.com (madiyaan)
Date: Thu, 17 Sep 2009 09:45:14 -0700 (PDT)
Subject: [LLVMdev] Forcing function inline not working
In-Reply-To: <92BA3A99-DBA9-488D-BC70-48CF4673B341@apple.com>
References: <25483934.post@talk.nabble.com>
	<92BA3A99-DBA9-488D-BC70-48CF4673B341@apple.com>
Message-ID: <25491988.post@talk.nabble.com>


Thanks for your message. However, even with using version 2.5 of llvm the
function is not inlined. Can you try this with your llvm with the same opt
flags, which are as follows?

-O3 -debug-only=inline -mem2reg

If it does work for you, can you tell me the exact flags you used for clang
or llvm-gcc to produce the .bc file and the exact flags you specified when
you invoked opt?

Does the inlining happen at clang level or after opt?


Dale Johannesen wrote:
> 
> 
> On Sep 16, 2009, at 6:55 PM, madiyaan wrote:
> 
>>
>> I have the following code:
>>
>> static inline void foo() __attribute((always_inline));
>>
>> int a;
>> static inline void foo()
>> {
>>  a++;
>> }
>>
>> int main(int argc, char *argv[])
>> {
>>  foo();
>>  return 0;
>> }
> 
> This works fine in current sources.  You should upgrade; 2.5 has been  
> out for a while and 2.6 will be soon.
> 
>> However, the code generated by llvm 2.4 toolchain does not inline this
>> function. opt retains the function call. Here is the output when I  
>> try to
>> compile with -debug-only=inline:
>>
>> ..\..\..\win32\bin\win32\debug\opt.exe -O3 -debug-only=inline - 
>> mem2reg -f -o
>> test_opt.bc test.bc
>> Inliner visiting SCC: foo: 0 call sites.
>> Inliner visiting SCC: main: 1 call sites.
>>    Inlining: cost=always, Call:        call void (...)* @foo()
>> Inliner visiting SCC: INDIRECTNODE: 0 call sites.
>>
>> Here is the .ll file:
>>
>> ; ModuleID = 'test_opt.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-win32"
>> @a = common global i32 0, align 4		; <i32*> [#uses=2]
>>
>> define i32 @main(i32 %argc, i8** %argv) nounwind {
>> entry:
>> 	tail call void (...)* @foo()
>> 	ret i32 0
>> }
>>
>> define internal void @foo(...) nounwind alwaysinline {
>> entry:
>> 	%tmp = load i32* @a		; <i32> [#uses=1]
>> 	%inc = add i32 %tmp, 1		; <i32> [#uses=1]
>> 	store i32 %inc, i32* @a
>> 	ret void
>> }
>>
>>
>> What am I doing wrong here? Is there a way to force a function to be  
>> inlined
>> by opt?
>>
>> Best Regards,
>> -- 
>> View this message in context:
>> http://www.nabble.com/Forcing-function-inline-not-working-tp25483934p25483934.html
>> Sent from the LLVM - Dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> 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
> 
> 

-- 
View this message in context: http://www.nabble.com/Forcing-function-inline-not-working-tp25483934p25491988.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From lattner at apple.com  Thu Sep 17 11:46:12 2009
From: lattner at apple.com (Tanya Lattner)
Date: Thu, 17 Sep 2009 09:46:12 -0700
Subject: [LLVMdev] Updated 2.6 release schedule
Message-ID: <5CF99723-0FA6-4464-83D8-48D4E05CD8D6@apple.com>

On Tuesday, I began my pre-release2 testing. We will no longer be  
accepting any patches for 2.6 unless they meet the criteria of a  
regression:
http://llvm.org/docs/HowToReleaseLLVM.html#release-qualify

I've already filed a few regressions. Please see the master 2.6 bug:
http://llvm.org/PR4886

Assuming the best, the 2.6 release schedule is as follows (shifted 2  
weeks):
Sept 25 - Community Pre-release2 testing begins
Oct 02 - Community Pre-release2 testing ends
Oct 05 - Release!

Thanks,
Tanya Lattner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090917/e5cbc78f/attachment.html 

From ransford at cs.umass.edu  Thu Sep 17 12:08:25 2009
From: ransford at cs.umass.edu (Ben Ransford)
Date: Thu, 17 Sep 2009 13:08:25 -0400
Subject: [LLVMdev] Patch for PR4776
Message-ID: <b7e7fde10909171008j770c772p9fec17a763572a17@mail.gmail.com>

Hello,

This patch against svn r82147 "fixes" PR4776.  Certain targets (e.g.,
MSP430) allow a symbol to start with a number, e.g. "0x0021"; you can
say stuff like "mov.b &0x0021, r15" to copy a byte from memory address
0x0021 to register r15.  LLVM had been generating this ill-formed code
instead:

  mov.b   &_30_x0021, r15     # note ASCII '0' has character code 0x30

Chris suggested that I add a bool for "symbols can start with digit"
to MCAsmInfo and set it to true in the MSP430 backend, then make the
mangler and MCSymbol printer respect that bool -- so that's what I
did.

Chris blessed the patch in the Bugzilla thread, but I wanted to
solicit comments here because it's my first.  (Is my approach
reasonable?  Would a more conservative strategy, e.g., just allowing
symbols to start with "0x", suffice?)

My own comments: there's a lot of code duplication between MCSymbol
and Mangler; I'm not sure whether that's intentional or unavoidable.
I also noticed words like "name" and "symbol" being used
interchangeably and somewhat inconsistently; my patch simply follows
the naming schemes apparent in each file I touched.

-ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr4776-vs-r82147.patch
Type: application/octet-stream
Size: 5938 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090917/b29c66ce/attachment.obj 

From javier at jmartinez.org  Thu Sep 17 12:22:03 2009
From: javier at jmartinez.org (Javier Martinez)
Date: Thu, 17 Sep 2009 10:22:03 -0700
Subject: [LLVMdev] Forcing function inline not working
In-Reply-To: <25491988.post@talk.nabble.com>
References: <25483934.post@talk.nabble.com>
	<92BA3A99-DBA9-488D-BC70-48CF4673B341@apple.com>
	<25491988.post@talk.nabble.com>
Message-ID: <6e557be24f1546479b84906bc29c9fa4@127.0.0.1>

I got the code to work in a LLVM 2.5. I think the reason your code wasn't
working is that the function definition and declaration for foo were
missing 'void'. This is perfectly legal C but maybe there's a bug in the
inliner pass that sees the function in the module and the symbol table as
different. Here are the files I used:

[test.c]
int a;

void foo(void);

int main(int argc, int *argv) {
  foo();
  
  return 0;
}

__attribute__((always_inline)) void foo(void) {
  a++;
}


[test.ll]
; ModuleID = 'test.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-pc-win32"
	%struct.__block_descriptor = type { i32, i32 }
	%struct.__block_literal_generic = type { i8*, i32, i32, i8*,
%struct.__block_descriptor* }
@a = common global i32 0, align 4		; <i32*> [#uses=2]

define i32 @main(i32 %argc, i32* %argv) nounwind {
entry:
	call void @foo()
	ret i32 0
}

define void @foo() nounwind alwaysinline {
entry:
	%tmp = load i32* @a		; <i32> [#uses=1]
	%inc = add i32 %tmp, 1		; <i32> [#uses=1]
	store i32 %inc, i32* @a
	ret void
}

[test_out.ll]
; ModuleID = 'test_out.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-win32"
	%struct.__block_descriptor = type { i32, i32 }
	%struct.__block_literal_generic = type { i8*, i32, i32, i8*,
%struct.__block_descriptor* }
@a = common global i32 0, align 4		; <i32*> [#uses=4]

define i32 @main(i32 %argc, i32* %argv) nounwind {
entry:
	%tmp.i = load i32* @a		; <i32> [#uses=1]
	%inc.i = add i32 %tmp.i, 1		; <i32> [#uses=1]
	store i32 %inc.i, i32* @a
	ret i32 0
}

define void @foo() nounwind alwaysinline {
entry:
	%tmp = load i32* @a		; <i32> [#uses=1]
	%inc = add i32 %tmp, 1		; <i32> [#uses=1]
	store i32 %inc, i32* @a
	ret void
}

For bonus points, if you want the definition of foo to be removed after it
has been inlined you have to add linkonce_odr to foo's llvm definition (see
below). I don't know how to get the same result from the .c file.
[test2.ll]
; ModuleID = 'test.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-pc-win32"
	%struct.__block_descriptor = type { i32, i32 }
	%struct.__block_literal_generic = type { i8*, i32, i32, i8*,
%struct.__block_descriptor* }
@a = common global i32 0, align 4		; <i32*> [#uses=2]

define i32 @main(i32 %argc, i32* %argv) nounwind {
entry:
	call void @foo()
	ret i32 0
}

define linkonce_odr void @foo() nounwind alwaysinline {
entry:
	%tmp = load i32* @a		; <i32> [#uses=1]
	%inc = add i32 %tmp, 1		; <i32> [#uses=1]
	store i32 %inc, i32* @a
	ret void
}

Javier

On Thu, 17 Sep 2009 09:45:14 -0700 (PDT), madiyaan
<ahmadsharif at hotmail.com>
wrote:
> Thanks for your message. However, even with using version 2.5 of llvm the
> function is not inlined. Can you try this with your llvm with the same
opt
> flags, which are as follows?
> 
> -O3 -debug-only=inline -mem2reg
> 
> If it does work for you, can you tell me the exact flags you used for
clang
> or llvm-gcc to produce the .bc file and the exact flags you specified
when
> you invoked opt?
> 
> Does the inlining happen at clang level or after opt?
> 
> 
> Dale Johannesen wrote:
>> 
>> 
>> On Sep 16, 2009, at 6:55 PM, madiyaan wrote:
>> 
>>>
>>> I have the following code:
>>>
>>> static inline void foo() __attribute((always_inline));
>>>
>>> int a;
>>> static inline void foo()
>>> {
>>>  a++;
>>> }
>>>
>>> int main(int argc, char *argv[])
>>> {
>>>  foo();
>>>  return 0;
>>> }
>> 
>> This works fine in current sources.  You should upgrade; 2.5 has been  
>> out for a while and 2.6 will be soon.
>> 
>>> However, the code generated by llvm 2.4 toolchain does not inline this
>>> function. opt retains the function call. Here is the output when I  
>>> try to
>>> compile with -debug-only=inline:
>>>
>>> ..\..\..\win32\bin\win32\debug\opt.exe -O3 -debug-only=inline - 
>>> mem2reg -f -o
>>> test_opt.bc test.bc
>>> Inliner visiting SCC: foo: 0 call sites.
>>> Inliner visiting SCC: main: 1 call sites.
>>>    Inlining: cost=always, Call:        call void (...)* @foo()
>>> Inliner visiting SCC: INDIRECTNODE: 0 call sites.
>>>
>>> Here is the .ll file:
>>>
>>> ; ModuleID = 'test_opt.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-win32"
>>> @a = common global i32 0, align 4		; <i32*> [#uses=2]
>>>
>>> define i32 @main(i32 %argc, i8** %argv) nounwind {
>>> entry:
>>> 	tail call void (...)* @foo()
>>> 	ret i32 0
>>> }
>>>
>>> define internal void @foo(...) nounwind alwaysinline {
>>> entry:
>>> 	%tmp = load i32* @a		; <i32> [#uses=1]
>>> 	%inc = add i32 %tmp, 1		; <i32> [#uses=1]
>>> 	store i32 %inc, i32* @a
>>> 	ret void
>>> }
>>>
>>>
>>> What am I doing wrong here? Is there a way to force a function to be  
>>> inlined
>>> by opt?
>>>
>>> Best Regards,
>>> -- 
>>> View this message in context:
>>>
http://www.nabble.com/Forcing-function-inline-not-working-tp25483934p25483934.html
>>> Sent from the LLVM - Dev mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> 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 zhunansjtu at gmail.com  Thu Sep 17 12:39:32 2009
From: zhunansjtu at gmail.com (Nan Zhu)
Date: Fri, 18 Sep 2009 01:39:32 +0800
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>
References: <1253191769.4354.6.camel@UIUC>
	<38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>
Message-ID: <ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>

Yes,it's indeedly the correct one,and new ld can also support -plugin
option,I don't know the reason of the trouble,




2009/9/17 Rafael Espindola <espindola at google.com>

> > llvm-gcc -use-gold-plugin a.a b.o -o hello
> >
> > which is similar with the example in the document,it tells me that
> > libLLVMgold.so can not be found ,but I truly put it in the directory
> > which is the same as the cc1's.
> >
> > What's the problem with my libLLVMgold.so's position?
>
> That looks correct. Can you check that
> *) It is the correct cc1 :-) (run llvm-gcc with -v)
> *) It works if you call gold directly with it
>
> > Thanks!
> >
> > Nan
> >
>
>
> Cheers,
> --
> Rafael Avila de Espindola
>
> Google | Gordon House | Barrow Street | Dublin 4 | Ireland
> Registered in Dublin, Ireland | Registration Number: 368047
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090918/ffcfbee0/attachment.html 

From espindola at google.com  Thu Sep 17 12:52:05 2009
From: espindola at google.com (Rafael Espindola)
Date: Thu, 17 Sep 2009 13:52:05 -0400
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>
References: <1253191769.4354.6.camel@UIUC>
	<38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>
	<ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>
Message-ID: <38a0d8450909171052j3385d151q4b288ba5c21d6dd9@mail.gmail.com>

2009/9/17 Nan Zhu <zhunansjtu at gmail.com>:
> Yes,it's indeedly the correct one,and new ld can also support -plugin
> option,I don't know the reason of the trouble,

Does ld actually work if you pass libLLVMGold.so to it? Try to link
with llvm-gcc without the -use-gold-plugin option and with -v (it will
fail as expected). Copy the collect2 line and add the -plugin line. If
that does work, the only think I can think of is to run llvm-gcc in
gdb and set a breakpoint on the error message.

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

From clattner at apple.com  Thu Sep 17 12:55:20 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 17 Sep 2009 10:55:20 -0700
Subject: [LLVMdev] Patch for PR4776
In-Reply-To: <b7e7fde10909171008j770c772p9fec17a763572a17@mail.gmail.com>
References: <b7e7fde10909171008j770c772p9fec17a763572a17@mail.gmail.com>
Message-ID: <723A0D68-0AAC-41E8-BED4-37294CE263F6@apple.com>

Looks great to me, please commit.

On Sep 17, 2009, at 10:08 AM, Ben Ransford wrote:

> Hello,
>
> This patch against svn r82147 "fixes" PR4776.  Certain targets (e.g.,
> MSP430) allow a symbol to start with a number, e.g. "0x0021"; you can
> say stuff like "mov.b &0x0021, r15" to copy a byte from memory address
> 0x0021 to register r15.  LLVM had been generating this ill-formed code
> instead:
>
> mov.b   &_30_x0021, r15     # note ASCII '0' has character code 0x30
>
> Chris suggested that I add a bool for "symbols can start with digit"
> to MCAsmInfo and set it to true in the MSP430 backend, then make the
> mangler and MCSymbol printer respect that bool -- so that's what I
> did.
>
> Chris blessed the patch in the Bugzilla thread, but I wanted to
> solicit comments here because it's my first.  (Is my approach
> reasonable?  Would a more conservative strategy, e.g., just allowing
> symbols to start with "0x", suffice?)
>
> My own comments: there's a lot of code duplication between MCSymbol
> and Mangler; I'm not sure whether that's intentional or unavoidable.
> I also noticed words like "name" and "symbol" being used
> interchangeably and somewhat inconsistently; my patch simply follows
> the naming schemes apparent in each file I touched.
>
> -ben
> <pr4776-vs- 
> r82147.patch>_______________________________________________
> 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  Thu Sep 17 12:55:52 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 17 Sep 2009 10:55:52 -0700
Subject: [LLVMdev] Forcing function inline not working
In-Reply-To: <6e557be24f1546479b84906bc29c9fa4@127.0.0.1>
References: <25483934.post@talk.nabble.com>
	<92BA3A99-DBA9-488D-BC70-48CF4673B341@apple.com>
	<25491988.post@talk.nabble.com>
	<6e557be24f1546479b84906bc29c9fa4@127.0.0.1>
Message-ID: <40C7969B-D808-448F-9B34-91A4307761B4@apple.com>


On Sep 17, 2009, at 10:22 AM, Javier Martinez wrote:

> I got the code to work in a LLVM 2.5. I think the reason your code  
> wasn't
> working is that the function definition and declaration for foo were
> missing 'void'. This is perfectly legal C but maybe there's a bug in  
> the
> inliner pass that sees the function in the module and the symbol  
> table as
> different.

If this reproduces with mainline, please file a bugzilla, thanks!

-Chris

From isanbard at gmail.com  Thu Sep 17 15:11:06 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Thu, 17 Sep 2009 13:11:06 -0700
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <4AB2123B.3020807@math.u-psud.fr>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
	<4AB0ED25.60404@math.u-psud.fr>
	<8C3D88DB-C5D0-4DCE-9733-5666D6731FD2@gmail.com>
	<4AB2123B.3020807@math.u-psud.fr>
Message-ID: <16e5fdf90909171311y56936ef8t86ef8f9b4c8cd2a5@mail.gmail.com>

On Thu, Sep 17, 2009 at 3:40 AM, Duncan Sands
<duncan.sands at math.u-psud.fr> wrote:
> Hi Bill,
>
>> Yeah. The logic will need tweaking for sure. I'm also concerned about the
>> _Unwind_resume() call. GCC emits a call site region for it in the exception
>> table. We...kind of do that. It looks like it's being included in one of the
>> "this is a region which isn't in a try-catch block, but it has a call in it,
>> so lets add it to the exception table" areas.
>
> isn't that exactly how it should be? ?This is a call that will unwind
> out of the function, so C++ requires it to have a call site region just
> like any other call that we want to let unwind out of the function. ?I
> don't see why it needs any special logic. ?If I understood right the
> change you want to make is that if a call is known not to unwind then
> you want to omit adding a call-site entry if that saves some space in
> the call site table, which seems irrelevant to this, or am I missing
> something? ?By the way, LLVM "nounwind" calls are different to GCC no
> throw regions IIRC. ?If an exception is thrown in a GCC no throw region
> then it must (C++) result in a call to "terminate". ?These are not
> mapped to "nounwind", instead we create explicit "catch-all" filter
> expressions for this (IIRC). ?In LLVM it is undefined what happens if
> a call is marked "nounwind" but nonetheless an exception unwinds out
> of it. ?Thus you can add call-site entries for nounwind calls,
> or not add them, as you like - whatever is most convenient (eg: saves
> the most space). ?An interesting optimization which we don't do is to
> identify which calls correspond to a "catch-all" filter and not generate
> an entry for them in the call-site table (no need to add the filter
> either) - this saves space and the C++ runtime knows to handle this
> just like if we added the filter explicitly.
>
There's a miscommunication here. :-) The _Unwind_resume call isn't
marked with "nounwind", however it's not called through an "invoke"
instruction, only a regular "call" instruction. From what I can see,
the only reason it falls within a call site in the exception table is
because we're generating call sites for areas of code without
"invokes". If I implement my optimization to eliminate these call site
entries which don't have "invoke" calls in them, then the
_Unwind_resume call won't have an entry into the exception table, and
that would be bad.

That was all I'm saying here.

-bw


From andreas at digitalplaywright.com  Thu Sep 17 17:59:18 2009
From: andreas at digitalplaywright.com (Andreas Saebjoernsen)
Date: Thu, 17 Sep 2009 15:59:18 -0700
Subject: [LLVMdev] compiling java frontend
Message-ID: <167925200909171559t28ce0e49w2d556367118f09aa@mail.gmail.com>

I am looking for a way to translate Java bytecode to LLVM bytecode and the
LLVM Java frontend seem like a good match for initial testing.  But after
checking out the svn version of the Java frontend I get the following error
when running configure
    configure: error: cannot find install-sh or install.sh in ../../autoconf
./../../autoconf

This error persisted even after successfully regenerating configure with the
'AutoRegen.sh' script in the 'java/trunk/autoconf' subdirectory. Do you have
any advice on how to configure and compile the Java frontend?

thanks,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090917/dd954f01/attachment.html 

From clattner at apple.com  Thu Sep 17 18:03:38 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 17 Sep 2009 16:03:38 -0700
Subject: [LLVMdev] compiling java frontend
In-Reply-To: <167925200909171559t28ce0e49w2d556367118f09aa@mail.gmail.com>
References: <167925200909171559t28ce0e49w2d556367118f09aa@mail.gmail.com>
Message-ID: <5CC16047-3CA6-4C83-8162-80BFA89A9334@apple.com>


On Sep 17, 2009, at 3:59 PM, Andreas Saebjoernsen wrote:

> I am looking for a way to translate Java bytecode to LLVM bytecode  
> and the LLVM Java frontend seem like a good match for initial  
> testing.  But after checking out the svn version of the Java  
> frontend I get the following error when running configure
>
>     configure: error: cannot find install-sh or install.sh in ../../ 
> autoconf ./../../autoconf
>
> This error persisted even after successfully regenerating configure  
> with the 'AutoRegen.sh' script in the 'java/trunk/autoconf'  
> subdirectory. Do you have any advice on how to configure and compile  
> the Java frontend?

Which java frontend?

-Chris

From andreas at digitalplaywright.com  Thu Sep 17 18:17:13 2009
From: andreas at digitalplaywright.com (Andreas Saebjoernsen)
Date: Thu, 17 Sep 2009 16:17:13 -0700
Subject: [LLVMdev] compiling java frontend
In-Reply-To: <5CC16047-3CA6-4C83-8162-80BFA89A9334@apple.com>
References: <167925200909171559t28ce0e49w2d556367118f09aa@mail.gmail.com>
	<5CC16047-3CA6-4C83-8162-80BFA89A9334@apple.com>
Message-ID: <167925200909171617x5bc77887hc5a92dee22f784d1@mail.gmail.com>

I am trying to compile the Java frontend in     https:/
llvm.org/svn/llvm-project/java/trunk
If there are another preferred Java frontend available, and it is suited for
translating Java bytecode to LLVM bytecode, I'd be happy to use that
frontend instead.

thanks,
Andreas

On Thu, Sep 17, 2009 at 4:03 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Sep 17, 2009, at 3:59 PM, Andreas Saebjoernsen wrote:
>
>  I am looking for a way to translate Java bytecode to LLVM bytecode and the
>> LLVM Java frontend seem like a good match for initial testing.  But after
>> checking out the svn version of the Java frontend I get the following error
>> when running configure
>>
>>    configure: error: cannot find install-sh or install.sh in
>> ../../autoconf ./../../autoconf
>>
>> This error persisted even after successfully regenerating configure with
>> the 'AutoRegen.sh' script in the 'java/trunk/autoconf' subdirectory. Do you
>> have any advice on how to configure and compile the Java frontend?
>>
>
> Which java frontend?
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090917/f0dbbd4e/attachment.html 

From clattner at apple.com  Thu Sep 17 18:22:48 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 17 Sep 2009 16:22:48 -0700
Subject: [LLVMdev] compiling java frontend
In-Reply-To: <167925200909171617x5bc77887hc5a92dee22f784d1@mail.gmail.com>
References: <167925200909171559t28ce0e49w2d556367118f09aa@mail.gmail.com>
	<5CC16047-3CA6-4C83-8162-80BFA89A9334@apple.com>
	<167925200909171617x5bc77887hc5a92dee22f784d1@mail.gmail.com>
Message-ID: <ED47E4D2-359B-40E6-86F5-312A55F5CE89@apple.com>


On Sep 17, 2009, at 4:17 PM, Andreas Saebjoernsen wrote:

> I am trying to compile the Java frontend in
>      https:/llvm.org/svn/llvm-project/java/trunk
> If there are another preferred Java frontend available, and it is  
> suited for translating Java bytecode to LLVM bytecode, I'd be happy  
> to use that frontend instead.

That is really old and out of date, I'm sure it doesn't work anymore.   
Check out http://vmkit.llvm.org/

-Chris

>
> thanks,
> Andreas
>
> On Thu, Sep 17, 2009 at 4:03 PM, Chris Lattner <clattner at apple.com>  
> wrote:
>
> On Sep 17, 2009, at 3:59 PM, Andreas Saebjoernsen wrote:
>
> I am looking for a way to translate Java bytecode to LLVM bytecode  
> and the LLVM Java frontend seem like a good match for initial  
> testing.  But after checking out the svn version of the Java  
> frontend I get the following error when running configure
>
>    configure: error: cannot find install-sh or install.sh in ../../ 
> autoconf ./../../autoconf
>
> This error persisted even after successfully regenerating configure  
> with the 'AutoRegen.sh' script in the 'java/trunk/autoconf'  
> subdirectory. Do you have any advice on how to configure and compile  
> the Java frontend?
>
> Which java frontend?
>
> -Chris
>

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

From zhunansjtu at gmail.com  Thu Sep 17 19:06:52 2009
From: zhunansjtu at gmail.com (Nan Zhu)
Date: Fri, 18 Sep 2009 08:06:52 +0800
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <38a0d8450909171052j3385d151q4b288ba5c21d6dd9@mail.gmail.com>
References: <1253191769.4354.6.camel@UIUC>
	<38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>
	<ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>
	<38a0d8450909171052j3385d151q4b288ba5c21d6dd9@mail.gmail.com>
Message-ID: <ffabe8bd0909171706q1a3ced2eq2e2f326e39c5bca6@mail.gmail.com>

OMG,that's just my situation...

I can link with libLLVMgold.so manualy,but will fail in that by llvm-gcc.

Debug llvm-gcc?????

Any one installed the gold-plugin successfully can give some instruction?

2009/9/18 Rafael Espindola <espindola at google.com>

> 2009/9/17 Nan Zhu <zhunansjtu at gmail.com>:
> > Yes,it's indeedly the correct one,and new ld can also support -plugin
> > option,I don't know the reason of the trouble,
>
> Does ld actually work if you pass libLLVMGold.so to it? Try to link
> with llvm-gcc without the -use-gold-plugin option and with -v (it will
> fail as expected). Copy the collect2 line and add the -plugin line. If
> that does work, the only think I can think of is to run llvm-gcc in
> gdb and set a breakpoint on the error message.
>
> Cheers,
> --
> Rafael Avila de Espindola
>
> Google | Gordon House | Barrow Street | Dublin 4 | Ireland
> Registered in Dublin, Ireland | Registration Number: 368047
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090918/5ecd78e7/attachment.html 

From baldrick at free.fr  Thu Sep 17 20:03:24 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 18 Sep 2009 03:03:24 +0200
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <16e5fdf90909171311y56936ef8t86ef8f9b4c8cd2a5@mail.gmail.com>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>	<4AB0ED25.60404@math.u-psud.fr>	<8C3D88DB-C5D0-4DCE-9733-5666D6731FD2@gmail.com>	<4AB2123B.3020807@math.u-psud.fr>
	<16e5fdf90909171311y56936ef8t86ef8f9b4c8cd2a5@mail.gmail.com>
Message-ID: <4AB2DC5C.10206@free.fr>

Hi Bill,

>>> Yeah. The logic will need tweaking for sure. I'm also concerned about the
>>> _Unwind_resume() call. GCC emits a call site region for it in the exception
>>> table. We...kind of do that. It looks like it's being included in one of the
>>> "this is a region which isn't in a try-catch block, but it has a call in it,
>>> so lets add it to the exception table" areas.
>> isn't that exactly how it should be?  This is a call that will unwind
>> out of the function, so C++ requires it to have a call site region just
>> like any other call that we want to let unwind out of the function.  I
>> don't see why it needs any special logic.  If I understood right the
>> change you want to make is that if a call is known not to unwind then
>> you want to omit adding a call-site entry if that saves some space in
>> the call site table, which seems irrelevant to this, or am I missing
>> something?  By the way, LLVM "nounwind" calls are different to GCC no
>> throw regions IIRC.  If an exception is thrown in a GCC no throw region
>> then it must (C++) result in a call to "terminate".  These are not
>> mapped to "nounwind", instead we create explicit "catch-all" filter
>> expressions for this (IIRC).  In LLVM it is undefined what happens if
>> a call is marked "nounwind" but nonetheless an exception unwinds out
>> of it.  Thus you can add call-site entries for nounwind calls,
>> or not add them, as you like - whatever is most convenient (eg: saves
>> the most space).  An interesting optimization which we don't do is to
>> identify which calls correspond to a "catch-all" filter and not generate
>> an entry for them in the call-site table (no need to add the filter
>> either) - this saves space and the C++ runtime knows to handle this
>> just like if we added the filter explicitly.
>>
> There's a miscommunication here. :-) The _Unwind_resume call isn't
> marked with "nounwind", however it's not called through an "invoke"
> instruction, only a regular "call" instruction. From what I can see,
> the only reason it falls within a call site in the exception table is
> because we're generating call sites for areas of code without
> "invokes".

yes, and that's absolutely the right thing to do!  Due to a strange
design choice, if a call does *not* have an entry in the call-site
table, and the call unwinds, then the runtime calls std::terminate.
All calls that may throw (like _Unwind_Resume!) must have an entry
in the call-site table.

If I implement my optimization to eliminate these call site
> entries which don't have "invoke" calls in them, then the
> _Unwind_resume call won't have an entry into the exception table, and
> that would be bad.

As explained above, you can only eliminate call-site entries for
nounwind calls.  Having a call-site entry has nothing to do with
whether a call is an invoke or not, it is to do with whether the
call can throw an exception or not.

Ciao,

Duncan.


From andreas at digitalplaywright.com  Thu Sep 17 20:42:08 2009
From: andreas at digitalplaywright.com (Andreas Saebjoernsen)
Date: Thu, 17 Sep 2009 18:42:08 -0700
Subject: [LLVMdev] compiling java frontend
In-Reply-To: <ED47E4D2-359B-40E6-86F5-312A55F5CE89@apple.com>
References: <167925200909171559t28ce0e49w2d556367118f09aa@mail.gmail.com>
	<5CC16047-3CA6-4C83-8162-80BFA89A9334@apple.com>
	<167925200909171617x5bc77887hc5a92dee22f784d1@mail.gmail.com>
	<ED47E4D2-359B-40E6-86F5-312A55F5CE89@apple.com>
Message-ID: <167925200909171842h1c7a702fj3420ec284fb9a45b@mail.gmail.com>

Thanks, I am now working on compiling up VMKit.  When compiling VMKit in my
up-to-date svn checkout I get several error messages on missing members of
the class 'llvm::Type':

PNetLib.cpp: In function ?void decapsulePrimitive(n3::VMObject*, const
llvm::Type*, std::vector<llvm::GenericValue,
std::allocator<llvm::GenericValue> >&)?:
PNetLib.cpp:694: error: ?Int1Ty? is not a member of ?llvm::Type?
PNetLib.cpp:698: error: ?Int8Ty? is not a member of ?llvm::Type?
PNetLib.cpp:702: error: ?Int16Ty? is not a member of ?llvm::Type?
PNetLib.cpp:706: error: ?Int32Ty? is not a member of ?llvm::Type?

There are several other errors on the same form. When inspecting the source
code of llvm::Type I do not see any member variables with those names, but I
see member functions on the form 'getInt1Ty(LLVMContext &C)' where
LLVMContextImpl have member variables with those names. Do you know how to
solve this problem?

thanks,
Andreas


On Thu, Sep 17, 2009 at 4:22 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Sep 17, 2009, at 4:17 PM, Andreas Saebjoernsen wrote:
>
> I am trying to compile the Java frontend in     https:/
> llvm.org/svn/llvm-project/java/trunk
> If there are another preferred Java frontend available, and it is suited
> for translating Java bytecode to LLVM bytecode, I'd be happy to use that
> frontend instead.
>
>
> That is really old and out of date, I'm sure it doesn't work anymore.
>  Check out http://vmkit.llvm.org/
>
> -Chris
>
>
> thanks,
> Andreas
>
> On Thu, Sep 17, 2009 at 4:03 PM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On Sep 17, 2009, at 3:59 PM, Andreas Saebjoernsen wrote:
>>
>>  I am looking for a way to translate Java bytecode to LLVM bytecode and
>>> the LLVM Java frontend seem like a good match for initial testing.  But
>>> after checking out the svn version of the Java frontend I get the following
>>> error when running configure
>>>
>>>    configure: error: cannot find install-sh or install.sh in
>>> ../../autoconf ./../../autoconf
>>>
>>> This error persisted even after successfully regenerating configure with
>>> the 'AutoRegen.sh' script in the 'java/trunk/autoconf' subdirectory. Do you
>>> have any advice on how to configure and compile the Java frontend?
>>>
>>
>> Which java frontend?
>>
>> -Chris
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090917/a1f3c29c/attachment.html 

From zhunansjtu at gmail.com  Thu Sep 17 21:25:49 2009
From: zhunansjtu at gmail.com (Nan Zhu)
Date: Fri, 18 Sep 2009 10:25:49 +0800
Subject: [LLVMdev] a bug for llvm-gcc??
Message-ID: <ffabe8bd0909171925u76b4c284oc5e13d39fc8a4c32@mail.gmail.com>

Hi,all

I met the following quesiton, and I'm no sure it's a bug for llvm-gcc:
I want to use gold plugin , so I compile and build all following the
documents, and copy the libLLVMgold.so to the same directory as cc1's,

after above all,I use llvm-gcc -used-gold-plugin to link the plugin library
libLLVMgold.so with the original source file,


but llvm-gcc always tells me that it cannot find the libLLVMgold.so since
it's just there.

and I use collect2 -plugin to link the generated object files
manually,everything is OK, the generated executable can also give
the expected result.


Is it a bug for llvm-gcc can not search the correct plugin library file??If
not,what's the matter with my operations?

Best regards.

ZhuNan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090918/9d4989fc/attachment.html 

From kledzik at apple.com  Thu Sep 17 23:18:38 2009
From: kledzik at apple.com (Nick Kledzik)
Date: Thu, 17 Sep 2009 21:18:38 -0700
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <4AB2DC5C.10206@free.fr>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
	<4AB0ED25.60404@math.u-psud.fr>
	<8C3D88DB-C5D0-4DCE-9733-5666D6731FD2@gmail.com>
	<4AB2123B.3020807@math.u-psud.fr>
	<16e5fdf90909171311y56936ef8t86ef8f9b4c8cd2a5@mail.gmail.com>
	<4AB2DC5C.10206@free.fr>
Message-ID: <A9504AC1-4674-46A3-9CAA-4D11620262A5@apple.com>


On Sep 17, 2009, at 6:03 PM, Duncan Sands wrote:

> Hi Bill,
>
>>>> Yeah. The logic will need tweaking for sure. I'm also concerned  
>>>> about the
>>>> _Unwind_resume() call. GCC emits a call site region for it in the  
>>>> exception
>>>> table. We...kind of do that. It looks like it's being included in  
>>>> one of the
>>>> "this is a region which isn't in a try-catch block, but it has a  
>>>> call in it,
>>>> so lets add it to the exception table" areas.
>>> isn't that exactly how it should be?  This is a call that will  
>>> unwind
>>> out of the function, so C++ requires it to have a call site region  
>>> just
>>> like any other call that we want to let unwind out of the  
>>> function.  I
>>> don't see why it needs any special logic.  If I understood right the
>>> change you want to make is that if a call is known not to unwind  
>>> then
>>> you want to omit adding a call-site entry if that saves some space  
>>> in
>>> the call site table, which seems irrelevant to this, or am I missing
>>> something?  By the way, LLVM "nounwind" calls are different to GCC  
>>> no
>>> throw regions IIRC.  If an exception is thrown in a GCC no throw  
>>> region
>>> then it must (C++) result in a call to "terminate".  These are not
>>> mapped to "nounwind", instead we create explicit "catch-all" filter
>>> expressions for this (IIRC).  In LLVM it is undefined what happens  
>>> if
>>> a call is marked "nounwind" but nonetheless an exception unwinds out
>>> of it.  Thus you can add call-site entries for nounwind calls,
>>> or not add them, as you like - whatever is most convenient (eg:  
>>> saves
>>> the most space).  An interesting optimization which we don't do is  
>>> to
>>> identify which calls correspond to a "catch-all" filter and not  
>>> generate
>>> an entry for them in the call-site table (no need to add the filter
>>> either) - this saves space and the C++ runtime knows to handle this
>>> just like if we added the filter explicitly.
>>>
>> There's a miscommunication here. :-) The _Unwind_resume call isn't
>> marked with "nounwind", however it's not called through an "invoke"
>> instruction, only a regular "call" instruction. From what I can see,
>> the only reason it falls within a call site in the exception table is
>> because we're generating call sites for areas of code without
>> "invokes".
>
> yes, and that's absolutely the right thing to do!  Due to a strange
> design choice, if a call does *not* have an entry in the call-site
> table, and the call unwinds, then the runtime calls std::terminate.
> All calls that may throw (like _Unwind_Resume!) must have an entry
> in the call-site table.


But _Unwind_Resume() is special.  It never returns. It does not throw.

The purpose of  _Unwind_Resume() is for when you have a function with  
a destructor that implicitly needs running during exception processing  
as the exception unwinds through the stack.  The unwinder jumps into  
that function's landing pad where the compiler has laid down a call to  
the destructor followed by a call to _Unwind_Resume() which then  
continues where the unwinding left off in processing the exception.

Therefore, I don't see the point of having a call-site entry for the  
_Unwind_Resume() "call".

-Nick




From clattner at apple.com  Thu Sep 17 23:48:43 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 17 Sep 2009 21:48:43 -0700
Subject: [LLVMdev] compiling java frontend
In-Reply-To: <167925200909171842h1c7a702fj3420ec284fb9a45b@mail.gmail.com>
References: <167925200909171559t28ce0e49w2d556367118f09aa@mail.gmail.com>
	<5CC16047-3CA6-4C83-8162-80BFA89A9334@apple.com>
	<167925200909171617x5bc77887hc5a92dee22f784d1@mail.gmail.com>
	<ED47E4D2-359B-40E6-86F5-312A55F5CE89@apple.com>
	<167925200909171842h1c7a702fj3420ec284fb9a45b@mail.gmail.com>
Message-ID: <32B420F2-6B6C-4C36-ACDF-AEF5C78DD3EF@apple.com>


On Sep 17, 2009, at 6:42 PM, Andreas Saebjoernsen wrote:

> Thanks, I am now working on compiling up VMKit.  When compiling  
> VMKit in my up-to-date svn checkout I get several error messages on  
> missing members of the class 'llvm::Type':
>
> PNetLib.cpp: In function ?void decapsulePrimitive(n3::VMObject*,  
> const llvm::Type*, std::vector<llvm::GenericValue,  
> std::allocator<llvm::GenericValue> >&)?:
> PNetLib.cpp:694: error: ?Int1Ty? is not a member of ?llvm::Type?
> PNetLib.cpp:698: error: ?Int8Ty? is not a member of ?llvm::Type?
> PNetLib.cpp:702: error: ?Int16Ty? is not a member of ?llvm::Type?
> PNetLib.cpp:706: error: ?Int32Ty? is not a member of ?llvm::Type?
>
> There are several other errors on the same form. When inspecting the  
> source code of llvm::Type I do not see any member variables with  
> those names, but I see member functions on the form 'getInt1Ty 
> (LLVMContext &C)' where LLVMContextImpl have member variables with  
> those names. Do you know how to solve this problem?

vmkit probably expects to be built against llvm 2.5, I'd recommend  
asking on a vmkit list like http://lists.cs.uiuc.edu/mailman/listinfo/vmkit-commits

-Chris



From nicolas.geoffray at lip6.fr  Fri Sep 18 00:43:34 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Fri, 18 Sep 2009 07:43:34 +0200
Subject: [LLVMdev] compiling java frontend
In-Reply-To: <167925200909171842h1c7a702fj3420ec284fb9a45b@mail.gmail.com>
References: <167925200909171559t28ce0e49w2d556367118f09aa@mail.gmail.com>	<5CC16047-3CA6-4C83-8162-80BFA89A9334@apple.com>	<167925200909171617x5bc77887hc5a92dee22f784d1@mail.gmail.com>	<ED47E4D2-359B-40E6-86F5-312A55F5CE89@apple.com>
	<167925200909171842h1c7a702fj3420ec284fb9a45b@mail.gmail.com>
Message-ID: <4AB31E06.8030505@lip6.fr>

Hi Andreas,

Since you're only looking for a Java frontend, I suggest you only build 
the Java frontend of vmkit and don't pass any pnet or mono information 
to the configure script. I haven't updated the pnet part of the .Net 
frontend. On the other hand, the Java frontend is up-to-date.

Nicolas

Andreas Saebjoernsen wrote:
> Thanks, I am now working on compiling up VMKit.  When compiling VMKit 
> in my up-to-date svn checkout I get several error messages on missing 
> members of the class 'llvm::Type':
>
> PNetLib.cpp: In function ?void decapsulePrimitive(n3::VMObject*, const 
> llvm::Type*, std::vector<llvm::GenericValue, 
> std::allocator<llvm::GenericValue> >&)?:
> PNetLib.cpp:694: error: ?Int1Ty? is not a member of ?llvm::Type?
> PNetLib.cpp:698: error: ?Int8Ty? is not a member of ?llvm::Type?
> PNetLib.cpp:702: error: ?Int16Ty? is not a member of ?llvm::Type?
> PNetLib.cpp:706: error: ?Int32Ty? is not a member of ?llvm::Type?
>
> There are several other errors on the same form. When inspecting the 
> source code of llvm::Type I do not see any member variables with those 
> names, but I see member functions on the form 'getInt1Ty(LLVMContext 
> &C)' where LLVMContextImpl have member variables with those names. Do 
> you know how to solve this problem?
>
> thanks,
> Andreas
>
>
> On Thu, Sep 17, 2009 at 4:22 PM, Chris Lattner <clattner at apple.com 
> <mailto:clattner at apple.com>> wrote:
>
>
>     On Sep 17, 2009, at 4:17 PM, Andreas Saebjoernsen wrote:
>
>>     I am trying to compile the Java frontend in
>>          https:/llvm.org/svn/llvm-project/java/trunk
>>     <http://llvm.org/svn/llvm-project/java/trunk>
>>     If there are another preferred Java frontend available, and it is
>>     suited for translating Java bytecode to LLVM bytecode, I'd be
>>     happy to use that frontend instead. 
>
>     That is really old and out of date, I'm sure it doesn't work
>     anymore.  Check out http://vmkit.llvm.org/
>
>     -Chris
>
>>
>>     thanks,
>>     Andreas
>>
>>     On Thu, Sep 17, 2009 at 4:03 PM, Chris Lattner
>>     <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>
>>
>>         On Sep 17, 2009, at 3:59 PM, Andreas Saebjoernsen wrote:
>>
>>             I am looking for a way to translate Java bytecode to LLVM
>>             bytecode and the LLVM Java frontend seem like a good
>>             match for initial testing.  But after checking out the
>>             svn version of the Java frontend I get the following
>>             error when running configure
>>
>>                configure: error: cannot find install-sh or install.sh
>>             in ../../autoconf ./../../autoconf
>>
>>             This error persisted even after successfully regenerating
>>             configure with the 'AutoRegen.sh' script in the
>>             'java/trunk/autoconf' subdirectory. Do you have any
>>             advice on how to configure and compile the Java frontend?
>>
>>
>>         Which java frontend?
>>
>>         -Chris
>>
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From daniel at zuster.org  Fri Sep 18 02:38:38 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 18 Sep 2009 00:38:38 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <1C4F63F7-2A63-40B3-AFC6-813D12676FEB@apple.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
	<6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
	<1C4F63F7-2A63-40B3-AFC6-813D12676FEB@apple.com>
Message-ID: <6a8523d60909180038n751086c1u45bd6c8b2780bb95@mail.gmail.com>

On Wed, Sep 16, 2009 at 10:52 AM, Eric Christopher <echristo at apple.com> wrote:
> On Sep 16, 2009, at 10:36 AM, Daniel Dunbar wrote:
>> Since we are in the area, what *should* O1 do?
>>
>> It's basically good for nothing, since it doesn't tune for size or
>> performance. The only good I personally ever have for it is once in a
>> while there is a miscompile at -O1 which narrows the problem.
>>
>> Would it be crazy to make -O1 equivalent to -Os?
>
> I've always used O1 for a quick cleanup so that my debug code doesn't
> completely suck, but hasn't been optimized into oblivion for gdb. ?Also
> makes looking at the resultant assembly dumps fairly easy.

If this is from the compiler programmer perspective, we have better
tools for that. If this is from the user perspective, currently they
all are bad with LLVM for the former, and we should similarly fix all
of them. :)

> But yes, that'd be crazy :)

Was that a -1 on doing it, though? :)

 - Daniel


From edwintorok at gmail.com  Fri Sep 18 02:59:09 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Fri, 18 Sep 2009 10:59:09 +0300
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <549cee610909160732p4d1a2b6ar2bad14578dd14570@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>	<ef5675f30909141302m1427fde6odedfe3b5ffec5f34@mail.gmail.com>	<549cee610909150616q17b38a7atd1aa85e6e3e20b7b@mail.gmail.com>	<200909151035.58610.dag@cray.com>	<549cee610909160142y292d6390o99eab1d8dd538b69@mail.gmail.com>	<4AB0AE6E.5090409@gmail.com>	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>	<h8qq7d$scp$1@ger.gmane.org>
	<549cee610909160732p4d1a2b6ar2bad14578dd14570@mail.gmail.com>
Message-ID: <4AB33DCD.7030905@gmail.com>

On 2009-09-16 17:32, Olivier Meurant wrote:
>
>
> On Wed, Sep 16, 2009 at 3:46 PM, Stefano Delli Ponti
> <stefano.delliponti at gmail.com <mailto:stefano.delliponti at gmail.com>>
> wrote:
>
>     I don't know what you think about this, but shouldn't it be more
>     meaningful to make these tests with -O3? I mean, we ought to make the
>     comparisons with the highest level of optimization available for
>     both of
>     the compilers. It is difficult to compare an intermediate level.
>
>
>
> A quick test confirms that the 40% difference stays even with an -O3
> switch on both compilers.
> I just "choose" -O2 as it's the default of the original makefile.

It would be interesting to see if LLVM has improved since 2.5 on this
benchmark, could you try the prerelease here?
http://llvm.org/prereleases/2.6/

A 40% performance loss is bad, something should be done about it for
LLVM 2.7 (if it is too late for 2.6 already).

Best regards,
--Edwin

From daniel at zuster.org  Fri Sep 18 03:00:58 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 18 Sep 2009 01:00:58 -0700
Subject: [LLVMdev] [OT] GCC specs language and adding options
In-Reply-To: <9719867c0909161328i79b479aie13808b0b92c09bb@mail.gmail.com>
References: <9719867c0909161328i79b479aie13808b0b92c09bb@mail.gmail.com>
Message-ID: <6a8523d60909180100x32afbc94pcd8df9da1ee6979f@mail.gmail.com>

To add to what Duncan said,

On Wed, Sep 16, 2009 at 1:28 PM, Aaron Gray
<aaronngray.lists at googlemail.com> wrote:
> Hi,
> I have been trying to get to grips with GCC's specs language in order to add
> COFF and ELF emission options.

Good luck. :)

> I have noticed that the '-emit-llvm-bc' option does not appear to work at
> all either with -S or without, giving :-
> ?? ?llvm-gcc: unrecognized option '-emit-llvm-bc'
> Also this seems by default seems for '-emit-llvm' to produce a '.o' file
> instead of a '.bc' file extension, unless using a '-o' option and overriding
> the filename.
> The LLVM code is as follows :-
> "%{O4|emit-llvm|flto:%{S:-emit-llvm}?%{!S:-emit-llvm-bc %{c: %W{o*} %{!o*:-o
> %b%w.o}} %{!c:-o %d%w%u%O}}}"
> So we have '-O4', '-emit-llvm', and '-flto' equivalent options.

Yes, although they aren't actually equivalent, they definitely overlap
a lot. The distinctions are *mostly* pedantic though.

> What I out like is either a '-emit-llvm-coff' and '-emit-llvm-elf' or
> ideally an '-emit-llvm=coff' if this can be done transparently with an
> '-emit-llvm' functioning normally.

As Duncan said, this doesn't make sense.

Is there any precedent for what this option should be called? I'd like
to agree on a design, since clang will eventually want the same thing.

Off the top of my head, I think the design "most compatible" with the
gcc driver design is to have '-integrated-asm' and
'-no-integrated-asm'. The object file format itself should be
determined by the target. Presumably -no-integrated-asm would start
off as the default, and eventually we would make it default when
everything works. -S would of course not use it.

As precedent, this conceptually matches -{no-,}integrated-cpp, for
example. The verbosity of the option shouldn't matter, since the
default should almost always be "right".

Unfortunately, implementing this in llvm-gcc is going to require
significant surgery, I think, although I haven't looked closely. It's
possible that you can just make the invoke_as 'spec' be empty if this
flag is present and have things just work, although you will still
have to work out the details of getting the correct output file to
cc1, suppressing the .s temporary files, etc.

It may even be worth mentioning whatever design we go with on the gcc
list, since we largely share the UI and they may want the same option
one day.

 - Daniel


From duncan.sands at math.u-psud.fr  Fri Sep 18 04:30:11 2009
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Fri, 18 Sep 2009 11:30:11 +0200
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <A9504AC1-4674-46A3-9CAA-4D11620262A5@apple.com>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>
	<4AB0ED25.60404@math.u-psud.fr>
	<8C3D88DB-C5D0-4DCE-9733-5666D6731FD2@gmail.com>
	<4AB2123B.3020807@math.u-psud.fr>
	<16e5fdf90909171311y56936ef8t86ef8f9b4c8cd2a5@mail.gmail.com>
	<4AB2DC5C.10206@free.fr>
	<A9504AC1-4674-46A3-9CAA-4D11620262A5@apple.com>
Message-ID: <4AB35323.9030902@math.u-psud.fr>

Hi Nick,

> But _Unwind_Resume() is special.  It never returns. It does not throw.

I disagree - this depends on the system libgcc version.  Starting from
gcc-4.3, mainline gcc uses _Unwind_GetCFA rather than _Unwind_GetIP in
uw_identify_context.  So from gcc-4.3 onwards, libgcc will indeed ignore
any call-site entry covering the position of the _Unwind_Resume call, so
indeed it doesn't matter what you put there.  However lots of systems
still use libgcc from gcc-4.2 or earlier (for example, all of the LLVM
nightly testers running linux), and for them it does matter what is in
the call site table: they need an entry appropriate for a "throwing
call".  [To be honest I didn't test this, but since on such systems it
is perfectly possible to catch the exception "thrown" by _Unwind_Resume
by placing an appropriate entry in the call-site table, it seems that
the address of the call is being looked up in the usual way in the
table].

So for compatibility with systems with an older libgcc, it is important
to have a call-site entry for _Unwind_Resume, like we produce right now.

> The purpose of  _Unwind_Resume() is for when you have a function with a 
> destructor that implicitly needs running during exception processing as 
> the exception unwinds through the stack.  The unwinder jumps into that 
> function's landing pad where the compiler has laid down a call to the 
> destructor followed by a call to _Unwind_Resume() which then continues 
> where the unwinding left off in processing the exception.
> 
> Therefore, I don't see the point of having a call-site entry for the 
> _Unwind_Resume() "call".

As I mentioned above, this behaviour can't be relied upon on linux at
least.  However maybe it can be relied upon for darwin, since the CFA
change has been in Apple gcc for a long time now.  If you want to
exploit this, it can be done in a generic way as part of a more general
optimization, as follows.

First, observe that it doesn't matter if you have a call-site entry
or not for the _Unwind_Resume call, since the call is never looked up
in the table.  It may not be optimal to omit the call-site entry, since
if the preceding and following entries have the same catches and
landing pads, all three entries (i.e. preceding, _Unwind_Resume and
following) could be merged into one entry with an address range that
covers all three.  This kind of merging logic already exists in
ComputeCallSiteTable, it just needs to be taught that it doesn't matter
whether _Unwind_Resume is in any particular call-site or not.  What
needs to happen is that in this line
         SawPotentiallyThrowing |= MI->getDesc().isCall();
you shouldn't set SawPotentiallyThrowing to true if the call is to
_Unwind_Resume.

However, there is no need to special case _Unwind_Resume, since there
is a whole class of calls for which you can do the same: all calls with
the nounwind attribute.  If such a call does throw an exception, that
results in undefined behaviour, so it is perfectly fine to not have a
call-site entry for it, or to have one, just like for _Unwind_Resume.
Thus I suggest adding a codegen flag to say whether a call is a
"nounwind" call.  The above line can change to something like:

         SawPotentiallyThrowing |= (MI->getDesc().isCall() && 
!MI->getDesc().isNoUnwind);

The code in ComputeCallSiteTable will then compute a minimal set of
call-sites in a way that should make you happy :)

In DwarfEHPrepare.cpp, if the platform is darwin then the calls to
_Unwind_Resume it generates can be marked "nounwind", and the rest
will happen automagically.

By the way, since nounwind calls occur a lot, this may result in
a big win in call-site table size, so I think it's worth doing
whether or not you do something special for _Unwind_Resume.

Ciao,

Duncan.

PS: I said to Bill that in fact SawPotentiallyThrowing was not what
he was looking for for nounwind calls, but I changed my mind again :)

From edwintorok at gmail.com  Fri Sep 18 04:58:55 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Fri, 18 Sep 2009 12:58:55 +0300
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <ffabe8bd0909171706q1a3ced2eq2e2f326e39c5bca6@mail.gmail.com>
References: <1253191769.4354.6.camel@UIUC>	<38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>	<ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>	<38a0d8450909171052j3385d151q4b288ba5c21d6dd9@mail.gmail.com>
	<ffabe8bd0909171706q1a3ced2eq2e2f326e39c5bca6@mail.gmail.com>
Message-ID: <4AB359DF.70500@gmail.com>

On 2009-09-18 03:06, Nan Zhu wrote:
> OMG,that's just my situation...
>  
> I can link with libLLVMgold.so manualy,but will fail in that by llvm-gcc.
>  
> Debug llvm-gcc?????
>  
> Any one installed the gold-plugin successfully can give some instruction?

Does the directory where you put the gold plugin look like this?
$PREFIX/libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/

Where $PREFIX is the prefix where you installed llvm-gcc

Best regards,
--Edwin


From st at invia.fr  Fri Sep 18 10:13:26 2009
From: st at invia.fr (Sylvere Teissier)
Date: Fri, 18 Sep 2009 17:13:26 +0200
Subject: [LLVMdev] Problems with live-ins and live-outs
Message-ID: <4AB3A396.3040203@invia.fr>

Hi,
With the MSP430 target I have live-in/live-out problems pointed out by
Machine Instruction Verifier with the attached test-case compiled with:

clang-cc -triple=msp430-unknown-unknown test-live.c -S -o - -O1
-verify-machineinstrs -debug

For example: %R15W is killed in MBB#0:
CMP16rr %R14W<kill>, %R15W<kill>, %SRW<imp-def>

But %R15 as live-in in MMB#1:
if.else: 0xa244c20, LLVM BB @0xa1f0a08, ID#1:
Live Ins: %R15W %R15B
    Predecessors according to CFG: 0xa244bd4 (#0)
	CMP16ir -21, %R15W, %SRW<imp-def>

Does someone have any idea of what can be the root cause of these
errors? How can I debug this?

---------------------------Complete Output:----------------------
# Machine code for f():
Live Ins: R15W in VR#1025  R14W in VR#1026
Live Outs: R15W

entry: 0xa244bd4, LLVM BB @0xa1f0c10, ID#0:
Live Ins: %R15W %R14W
	CMP16rr %R14W<kill>, %R15W<kill>, %SRW<imp-def>
	JCC mbb<return,0xa244d04>, 5, %SRW<imp-use>
    Successors according to CFG: 0xa244d04 (#4) 0xa244c20 (#1)

if.else: 0xa244c20, LLVM BB @0xa1f0a08, ID#1:
Live Ins: %R15W %R15B
    Predecessors according to CFG: 0xa244bd4 (#0)
	CMP16ir -21, %R15W, %SRW<imp-def>
	JCC mbb<if.end7,0xa244cb8>, 5, %SRW<imp-use>
    Successors according to CFG: 0xa244c6c (#2) 0xa244cb8 (#3)

if.then5: 0xa244c6c, LLVM BB @0xa1e93c0, ID#2:
Live Ins: %R15W %R15B
    Predecessors according to CFG: 0xa244c20 (#1)
	%R12W<def> = MOV16ri 10
	%R12W<def> = SUB16rr %R12W, %R15W<kill>, %SRW<imp-def>
	%R15W<def> = MOV16rr %R12W<kill>
	RET %R15W<imp-use,kill>

if.end7: 0xa244cb8, LLVM BB @0xa1f09c0, ID#3:
Live Ins: %R15W %R15B
    Predecessors according to CFG: 0xa244c20 (#1)
	%R15W<def> = ADD16ri %R15W, 18, %SRW<imp-def>
	RET %R15W<imp-use,kill>

return: 0xa244d04, LLVM BB @0xa1efa18, ID#4:
Live Ins: %R15W %R15B
    Predecessors according to CFG: 0xa244bd4 (#0)
	RET %R15W<imp-use,kill>

# End machine code for f().

*** Bad machine code: Live-in physical register is not live-out from
predecessor ***
- function:    f
- basic block: if.else 0xa244c20 (#1)
Register R15W is not live-out from MBB #0.

*** Bad machine code: Live-in physical register is not live-out from
predecessor ***
- function:    f
- basic block: if.else 0xa244c20 (#1)
Register R15B is not live-out from MBB #0.

*** Bad machine code: Live-in physical register is not live-out from
predecessor ***
- function:    f
- basic block: return 0xa244d04 (#4)
Register R15W is not live-out from MBB #0.

*** Bad machine code: Live-in physical register is not live-out from
predecessor ***
- function:    f
- basic block: return 0xa244d04 (#4)
Register R15B is not live-out from MBB #0.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-live.c
Type: text/x-csrc
Size: 113 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090918/492aa38f/attachment.bin 

From howarth at bromo.med.uc.edu  Fri Sep 18 10:16:45 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 18 Sep 2009 11:16:45 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
Message-ID: <20090918151645.GA9655@bromo.med.uc.edu>

  I realize this is off-topic for the list, but I thought
all the darwin developers here might want to be aware of
this. The current regressions in gcc trunk regarding
exception handling has been escalated to a P1 in order to
attract darwin developers to the issue...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260#c31

If these regressions aren't fixed before gcc 4.5's release,
it appears the *-*-darwin will be removed from the primary
target list for FSF gcc. This would be rather unfortunate
since it would eventually compromise the quality of fortran
compilers that darwin users have access to. Hopefully the
current darwin maintainers listed for FSF gcc can find some
approach acceptable to their management where the other
FSF gcc developers can be guided through debugging and
fixing this regression.
                Jack

From kledzik at apple.com  Fri Sep 18 11:21:52 2009
From: kledzik at apple.com (Nick Kledzik)
Date: Fri, 18 Sep 2009 09:21:52 -0700
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <20090918151645.GA9655@bromo.med.uc.edu>
References: <20090918151645.GA9655@bromo.med.uc.edu>
Message-ID: <08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>

This may be that the libgcc_s.dylib based unwinder is incompatible  
with the darwin unwinder.  You cannot mix and match the two.  One of  
the lines from the bugzilla comments shows:
/sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
being used.   That will not work.  All of the libgcc_s.dylib  
functionality has been subsumed into libSystem.dylib on SnowLeopard  
(darwin10).   The gcc compiler that shipped with SnowLeopard leaves  
the -lgcc_s off the link line when targeting SnowLeopard.   If there  
is a newer libgcc_s with new functions added, then the link line needs  
to change to "-lSystem -lgcc_s", that way the linker will find the  
most routines in libSystem.dylib and only the new functions from  
libgcc_s.dylib.  Thus all linkage units will use the same unwinder.

-Nick

On Sep 18, 2009, at 8:16 AM, Jack Howarth wrote:
>  I realize this is off-topic for the list, but I thought
> all the darwin developers here might want to be aware of
> this. The current regressions in gcc trunk regarding
> exception handling has been escalated to a P1 in order to
> attract darwin developers to the issue...
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260#c31
>
> If these regressions aren't fixed before gcc 4.5's release,
> it appears the *-*-darwin will be removed from the primary
> target list for FSF gcc. This would be rather unfortunate
> since it would eventually compromise the quality of fortran
> compilers that darwin users have access to. Hopefully the
> current darwin maintainers listed for FSF gcc can find some
> approach acceptable to their management where the other
> FSF gcc developers can be guided through debugging and
> fixing this regression.
>                Jack
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From wishinet at googlemail.com  Fri Sep 18 11:23:36 2009
From: wishinet at googlemail.com (Marius)
Date: Fri, 18 Sep 2009 18:23:36 +0200
Subject: [LLVMdev] x86-32 to llvm bytecode
Message-ID: <20090918162336.GA95965@dawn.local>

Sers!

I recently strumbled across llvm-qemu
(http://code.google.com/p/llvm-qemu/) which apparantly should be able to
translate qemu supported architectures to LLVM IR
(http://markmail.org/message/iyqzgtcux62wdhkb) to ease analysing
binaries. 

Using LLVM for (dynamic binary) translations seems to be a great
idea. However I haven't seen many approaches being made in that
direction. Valgrind's VEX (CISC like intermediate language) seems to be
used in Bitblaze VINE (http://bitblaze.cs.berkeley.edu/vine.html).

Does anybody know a similar project for LLVM? - Because the llvm-qemu
seems to have specific downsides linked to qemu emulation engine. 

Thanks,
Marius

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090918/d9acdf3d/attachment.bin 

From devang.patel at gmail.com  Fri Sep 18 10:25:01 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Fri, 18 Sep 2009 08:25:01 -0700
Subject: [LLVMdev] [OT] GCC specs language and adding options
In-Reply-To: <6a8523d60909180100x32afbc94pcd8df9da1ee6979f@mail.gmail.com>
References: <9719867c0909161328i79b479aie13808b0b92c09bb@mail.gmail.com>
	<6a8523d60909180100x32afbc94pcd8df9da1ee6979f@mail.gmail.com>
Message-ID: <352a1fb20909180825p2679fa84x6b9048e0eaba85d1@mail.gmail.com>

On Fri, Sep 18, 2009 at 1:00 AM, Daniel Dunbar <daniel at zuster.org> wrote:
>> The LLVM code is as follows :-
>> "%{O4|emit-llvm|flto:%{S:-emit-llvm}?%{!S:-emit-llvm-bc %{c: %W{o*} %{!o*:-o
>> %b%w.o}} %{!c:-o %d%w%u%O}}}"
>> So we have '-O4', '-emit-llvm', and '-flto' equivalent options.
>
> Yes, although they aren't actually equivalent, they definitely overlap
> a lot. The distinctions are *mostly* pedantic though.
>

-flto is documented command line options for llvm-gcc users to enable
link time optimization (LTO).

-emit-llvm was added for folks who has write access to llvm svn (IMO
:). -emit-llvm is intentionally not documented in man page. -emit-llvm
is not appropriate name to enable LTO, it does not follow usual gcc
command line naming conversions and it was introduced before LTO.

Yes, internally, -flto and -emit-llvm enables same functionality.

However, -O4 is not same as -flto.  -flto enables link time
optimization but one can use various -Oblah flags to select compile
time options. -O4 means -O3 + -flto. It would be OK to say -Os + -flto
 also, if code size is important.

-
Devang


From howarth at bromo.med.uc.edu  Fri Sep 18 11:47:52 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 18 Sep 2009 12:47:52 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
Message-ID: <20090918164752.GB10212@bromo.med.uc.edu>

Nick,
    How exactly do you envision this being done? Looking at the contents
of config/darwin.h, I see...

/* Support -mmacosx-version-min by supplying different (stub) libgcc_s.dylib
   libraries to link against, and by not linking against libgcc_s on
   earlier-than-10.3.9.

   Note that by default, -lgcc_eh is not linked against!  This is
   because in a future version of Darwin the EH frame information may
   be in a new format, or the fallback routine might be changed; if
   you want to explicitly link against the static version of those
   routines, because you know you don't need to unwind through system
   libraries, you need to explicitly say -static-libgcc.

   If it is linked against, it has to be before -lgcc, because it may
   need symbols from -lgcc.  */
#undef REAL_LIBGCC_SPEC
#define REAL_LIBGCC_SPEC                                                   \
   "%{static-libgcc|static: -lgcc_eh -lgcc;                                \
      shared-libgcc|fexceptions|fgnu-runtime:                              \
       %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)        \
       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)        \
       -lgcc;                                                              \
      :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)        \
       -lgcc}"

Would it be as simple as adding...

%:version-compare(>= 10.6 mmacosx-version-min= -lgcc_s.10.5)        \
       -lSystem -lgcc}"

or could we even use...

%:version-compare(>= 10.6 mmacosx-version-min= -lgcc_s.10.5)        \
       -lSystem -lgcc_s}"

I think the second case would solve the outstanding issue of the
TLS emutls not being linked in on darwin...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

which would definitely be nice and take a lot of the testsuite
out of the unsupported result mode.
   If anyone would like to propose a specific patch, I would be
more than happy to test it against current gcc trunk.
                    Jack

On Fri, Sep 18, 2009 at 09:21:52AM -0700, Nick Kledzik wrote:
> This may be that the libgcc_s.dylib based unwinder is incompatible with 
> the darwin unwinder.  You cannot mix and match the two.  One of the lines 
> from the bugzilla comments shows:
> /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
> being used.   That will not work.  All of the libgcc_s.dylib  
> functionality has been subsumed into libSystem.dylib on SnowLeopard  
> (darwin10).   The gcc compiler that shipped with SnowLeopard leaves the 
> -lgcc_s off the link line when targeting SnowLeopard.   If there is a 
> newer libgcc_s with new functions added, then the link line needs to 
> change to "-lSystem -lgcc_s", that way the linker will find the most 
> routines in libSystem.dylib and only the new functions from  
> libgcc_s.dylib.  Thus all linkage units will use the same unwinder.
>
> -Nick
>
> On Sep 18, 2009, at 8:16 AM, Jack Howarth wrote:
>>  I realize this is off-topic for the list, but I thought
>> all the darwin developers here might want to be aware of
>> this. The current regressions in gcc trunk regarding
>> exception handling has been escalated to a P1 in order to
>> attract darwin developers to the issue...
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260#c31
>>
>> If these regressions aren't fixed before gcc 4.5's release,
>> it appears the *-*-darwin will be removed from the primary
>> target list for FSF gcc. This would be rather unfortunate
>> since it would eventually compromise the quality of fortran
>> compilers that darwin users have access to. Hopefully the
>> current darwin maintainers listed for FSF gcc can find some
>> approach acceptable to their management where the other
>> FSF gcc developers can be guided through debugging and
>> fixing this regression.
>>                Jack
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From kledzik at apple.com  Fri Sep 18 12:28:15 2009
From: kledzik at apple.com (Nick Kledzik)
Date: Fri, 18 Sep 2009 10:28:15 -0700
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <20090918164752.GB10212@bromo.med.uc.edu>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
Message-ID: <45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>

Jack,

I think there is an extra dimension to darwin that might be confusing  
things.  Darwin uses two-level-name-space.  That means that at build  
time the linker records where it found each dylib (SO) symbol.  (It  
records the path the dylib supplied as its "install name" - not just  
the leafname as SO_NEEDED does.)

On a SnowLeopard system you *can* link against /usr/lib/libgcc_s. 
10.5.dylib, but the linker will not record any symbols coming from  
it.  In fact, the link order does not matter.  That is because /usr/ 
lib/libgcc_s.10.5.dylib has magic symbols in it that say if you are  
targeting 10.6 then _Unwind_Resume  (and other other symbols) are not  
in that dylib, so the linker looks elsewhere and finds them in  
libSystem.B.dylib.  In other words, the compiler changes to  
SnowLeopard to omit /re-order the linking with -lgcc_s when targeting  
10.6 was just an optimization and not required.

So, when these test cases are run, is the binary linked against /usr/ 
lib/libgcc_s.10.5.dylib? or against some just built libgcc_s. 
10.5.dylib? or against some just build libgcc_s.dylib?  If either of  
the latter, then if you changed the FSF build of libgcc_s for darwin  
to have the right magic symbols, then when targeting 10.6, the linker  
will ignore those dylibs and record that the symbols should be found  
in /usr/lib/libSystem.B.dylib at runtime.

That does mean you will *not* be implicitly testing the libgcc just  
built (since at runtime the OS implementation of libgcc functions in  
libSystem.dylib will be used), but I think this test suite is supposed  
to be testing the compiler.  So that should be OK.

It also means any new symbols introduced in main line libgcc *will* be  
recorded as coming from /custom/path/libgcc_s.1.dylib.  Which again is  
what you want (as long as the functions are independent and don't need  
to be used in sets). And very similar to the libgcc_ext.dylib idea  
from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3988

-Nick

On Sep 18, 2009, at 9:47 AM, Jack Howarth wrote:

> Nick,
>    How exactly do you envision this being done? Looking at the  
> contents
> of config/darwin.h, I see...
>
> /* Support -mmacosx-version-min by supplying different (stub)  
> libgcc_s.dylib
>   libraries to link against, and by not linking against libgcc_s on
>   earlier-than-10.3.9.
>
>   Note that by default, -lgcc_eh is not linked against!  This is
>   because in a future version of Darwin the EH frame information may
>   be in a new format, or the fallback routine might be changed; if
>   you want to explicitly link against the static version of those
>   routines, because you know you don't need to unwind through system
>   libraries, you need to explicitly say -static-libgcc.
>
>   If it is linked against, it has to be before -lgcc, because it may
>   need symbols from -lgcc.  */
> #undef REAL_LIBGCC_SPEC
> #define  
> REAL_LIBGCC_SPEC                                                   \
>   "%{static-libgcc|static: -lgcc_eh - 
> lgcc;                                \
>      shared-libgcc|fexceptions|fgnu- 
> runtime:                              \
>       %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s. 
> 10.4)        \
>       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s. 
> 10.5)        \
>       - 
> lgcc;                                                              \
>      :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s. 
> 10.4) \
>       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s. 
> 10.5)        \
>       -lgcc}"
>
> Would it be as simple as adding...
>
> %:version-compare(>= 10.6 mmacosx-version-min= -lgcc_s.10.5)        \
>       -lSystem -lgcc}"
>
> or could we even use...
>
> %:version-compare(>= 10.6 mmacosx-version-min= -lgcc_s.10.5)        \
>       -lSystem -lgcc_s}"
>
> I think the second case would solve the outstanding issue of the
> TLS emutls not being linked in on darwin...
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
>
> which would definitely be nice and take a lot of the testsuite
> out of the unsupported result mode.
>   If anyone would like to propose a specific patch, I would be
> more than happy to test it against current gcc trunk.
>                    Jack
>
> On Fri, Sep 18, 2009 at 09:21:52AM -0700, Nick Kledzik wrote:
>> This may be that the libgcc_s.dylib based unwinder is incompatible  
>> with
>> the darwin unwinder.  You cannot mix and match the two.  One of the  
>> lines
>> from the bugzilla comments shows:
>> /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
>> being used.   That will not work.  All of the libgcc_s.dylib
>> functionality has been subsumed into libSystem.dylib on SnowLeopard
>> (darwin10).   The gcc compiler that shipped with SnowLeopard leaves  
>> the
>> -lgcc_s off the link line when targeting SnowLeopard.   If there is a
>> newer libgcc_s with new functions added, then the link line needs to
>> change to "-lSystem -lgcc_s", that way the linker will find the most
>> routines in libSystem.dylib and only the new functions from
>> libgcc_s.dylib.  Thus all linkage units will use the same unwinder.
>>
>> -Nick
>>
>> On Sep 18, 2009, at 8:16 AM, Jack Howarth wrote:
>>> I realize this is off-topic for the list, but I thought
>>> all the darwin developers here might want to be aware of
>>> this. The current regressions in gcc trunk regarding
>>> exception handling has been escalated to a P1 in order to
>>> attract darwin developers to the issue...
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260#c31
>>>
>>> If these regressions aren't fixed before gcc 4.5's release,
>>> it appears the *-*-darwin will be removed from the primary
>>> target list for FSF gcc. This would be rather unfortunate
>>> since it would eventually compromise the quality of fortran
>>> compilers that darwin users have access to. Hopefully the
>>> current darwin maintainers listed for FSF gcc can find some
>>> approach acceptable to their management where the other
>>> FSF gcc developers can be guided through debugging and
>>> fixing this regression.
>>>               Jack
>>> _______________________________________________
>>> 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  Fri Sep 18 12:43:31 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 18 Sep 2009 13:43:31 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
Message-ID: <20090918174331.GA10727@bromo.med.uc.edu>

On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote:
> So, when these test cases are run, is the binary linked against /usr/ 
> lib/libgcc_s.10.5.dylib? or against some just built libgcc_s.10.5.dylib? 
> or against some just build libgcc_s.dylib?  If either of the latter, then 
> if you changed the FSF build of libgcc_s for darwin to have the right 
> magic symbols, then when targeting 10.6, the linker will ignore those 
> dylibs and record that the symbols should be found in 
> /usr/lib/libSystem.B.dylib at runtime.
>
I'll double check but I believe that the testsuite always links the
libgcc_s.10.5.dylib built by the FSF gcc build. The problem with the
emutls symbols if I recall correctly is that those are not exposed
through libgcc_s.10.5 but rather libgcc_s directly. For now, it would
be better to ignore the emults issues and focus on what needs to be
done to fix the unwinding. I guess you are saying we need to move
the unwinders symbols out into a libgcc_ext and use that in the
linkage on 10.6 or later so the FSF unwinder is used instead of 
the system one?
                  Jack

From kledzik at apple.com  Fri Sep 18 13:13:52 2009
From: kledzik at apple.com (Nick Kledzik)
Date: Fri, 18 Sep 2009 11:13:52 -0700
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <20090918174331.GA10727@bromo.med.uc.edu>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
Message-ID: <86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>


On Sep 18, 2009, at 10:43 AM, Jack Howarth wrote:

> On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote:
>> So, when these test cases are run, is the binary linked against /usr/
>> lib/libgcc_s.10.5.dylib? or against some just built libgcc_s. 
>> 10.5.dylib?
>> or against some just build libgcc_s.dylib?  If either of the  
>> latter, then
>> if you changed the FSF build of libgcc_s for darwin to have the right
>> magic symbols, then when targeting 10.6, the linker will ignore those
>> dylibs and record that the symbols should be found in
>> /usr/lib/libSystem.B.dylib at runtime.
>>
> I'll double check but I believe that the testsuite always links the
> libgcc_s.10.5.dylib built by the FSF gcc build. The problem with the
> emutls symbols if I recall correctly is that those are not exposed
> through libgcc_s.10.5 but rather libgcc_s directly. For now, it would
> be better to ignore the emults issues and focus on what needs to be
> done to fix the unwinding. I guess you are saying we need to move
> the unwinders symbols out into a libgcc_ext and use that in the
> linkage on 10.6 or later so the FSF unwinder is used instead of
> the system one?
>                  Jack

The important thing is that only one unwinder is used.  The  
_Unwind_Context data structure is different between the darwin and FSF  
implementations, so you can't pass it between two different  
implementations.   Since darwin uses two-level namespace and swapping  
in a new libgcc_s.dylib at runtime is not going to effect the various  
OS dylibs that are looking for _Unwind_* routines in libSystem.dylib.

Even if you managed to get the test suite to run where everything is  
consistently using the just built libgcc_s.dylib, how will this work  
for end users of the gcc-4.5+ who want to ship an app built with  
gcc-4.5+?  Their code needs to use the OS unwinder.

So it seems to me you should be testing the compiler against the OS  
unwinder - not against the just built unwinder.

Has something changed in the FSF unwinder that clients of gcc will want?

-Nick

P.S. One minor pet peeve of mine is that the exception handling is  
well layered (e.g. _cxa_* layer on top the _Unwind_* layer (which on  
darwin is now built upon the libunwind layer)).  Except for one  
glaring problem.  The compiler mostly emits calls to _cxa_* functions,  
but it makes one call to _Unwind_Resume.   Ah!!   And those are in  
different dylibs!  If instead the compiler made some call like  
__cxa_resume() in libstdc++.dylib which turned around and called  
_Unwind_Resume() in libgcc_s.dylib, then much of the problem above  
would never happen.



From ssen at apple.com  Fri Sep 18 13:14:13 2009
From: ssen at apple.com (Shantonu Sen)
Date: Fri, 18 Sep 2009 11:14:13 -0700
Subject: [LLVMdev] [PATCH] BlocksRuntime updates for Linux
Message-ID: <74663C84-9383-4D23-A844-7E8C16AA0D5E@apple.com>

The attached diff cleans up the BlocksRuntime/ directory of compiler- 
rt for better portability, eliminates compiler warnings, and adds  
support to the cmake build to install the results.

More specifically, the changes:
1) Remove cmake-specific #define usage from the exported Block.h/ 
Block_private.h headers, since clients won't know what to set. These  
are moved into runtime.c as appropriate
2) Use cmake checks for CAS builtins, instead of guessing based on GCC  
#defines (which aren't set by clang and llvm-gcc anyway)
3) "#pragma mark" isn't supported by FSF gcc, so "#if 0" it out. It  
should still show up in IDEs that support it
4) Fix some compiler warnings. GCC 4.3.3 seems super strict about %p.  
function pointers can't be cast to void * either.
5) Avoid a warning for apple_versioning.c that "ISO C does not allow  
empty files"

Tested on Ubuntu Linux 9.04 with clang and llvm-gcc and -fblocks to  
define and copy some blocks (and invoke them, obviously). Also tested  
on Mac OS X 10.6 and linking against -lBlocksRuntime ahead of -lSystem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocks-linux.diff
Type: application/octet-stream
Size: 10483 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090918/ebbb7903/attachment.obj 
-------------- next part --------------

Shantonu Sen
ssen at apple.com

Sent from my Mac Pro


From howarth at bromo.med.uc.edu  Fri Sep 18 13:40:12 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 18 Sep 2009 14:40:12 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
Message-ID: <20090918184012.GA11168@bromo.med.uc.edu>

On Fri, Sep 18, 2009 at 11:13:52AM -0700, Nick Kledzik wrote:
>
> The important thing is that only one unwinder is used.  The  
> _Unwind_Context data structure is different between the darwin and FSF  
> implementations, so you can't pass it between two different  
> implementations.   Since darwin uses two-level namespace and swapping in 
> a new libgcc_s.dylib at runtime is not going to effect the various OS 
> dylibs that are looking for _Unwind_* routines in libSystem.dylib.
>
> Even if you managed to get the test suite to run where everything is  
> consistently using the just built libgcc_s.dylib, how will this work for 
> end users of the gcc-4.5+ who want to ship an app built with gcc-4.5+?  
> Their code needs to use the OS unwinder.
>
> So it seems to me you should be testing the compiler against the OS  
> unwinder - not against the just built unwinder.
>
> Has something changed in the FSF unwinder that clients of gcc will want?
>
> -Nick
>
> P.S. One minor pet peeve of mine is that the exception handling is well 
> layered (e.g. _cxa_* layer on top the _Unwind_* layer (which on darwin is 
> now built upon the libunwind layer)).  Except for one glaring problem.  
> The compiler mostly emits calls to _cxa_* functions, but it makes one 
> call to _Unwind_Resume.   Ah!!   And those are in different dylibs!  If 
> instead the compiler made some call like __cxa_resume() in 
> libstdc++.dylib which turned around and called _Unwind_Resume() in 
> libgcc_s.dylib, then much of the problem above would never happen.
>

I am not sure if some of these problems were latent and only
exposed by the change, but the mass regressions in the g++
and libjava testsuites were triggered by the commit...

Author: rth
Date: Sat May 30 00:33:46 2009
New Revision: 147995

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147995
Log:
        * cfgcleanup.c (try_crossjump_to_edge): Only skip past
        NOTE_INSN_BASIC_BLOCK.
        * cfglayout.c (duplicate_insn_chain): Copy epilogue insn marks.
        Duplicate NOTE_INSN_EPILOGUE_BEG notes.
        * cfgrtl.c (can_delete_note_p): Allow NOTE_INSN_EPILOGUE_BEG
        to be deleted.
        * dwarf2out.c (struct cfa_loc): Change indirect field to bitfield,
        add in_use field.
        (add_cfi): Disable check redefining cfa away from drap.
        (lookup_cfa_1): Add remember argument; handle remember/restore.
        (lookup_cfa): Pass remember argument.
        (cfa_remember): New.
        (compute_barrier_args_size_1): Remove sibcall check.
        (dwarf2out_frame_debug_def_cfa): New.
        (dwarf2out_frame_debug_adjust_cfa): New.
        (dwarf2out_frame_debug_cfa_offset): New.
        (dwarf2out_frame_debug_cfa_register): New.
        (dwarf2out_frame_debug_cfa_restore): New.
        (dwarf2out_frame_debug): Handle REG_CFA_* notes.
        (dwarf2out_begin_epilogue): New.
        (dwarf2out_frame_debug_restore_state): New.
        (dw_cfi_oprnd1_desc): Handle DW_CFA_remember_state,
        DW_CFA_restore_state.
        (output_cfi_directive): Likewise.
        (convert_cfa_to_fb_loc_list): Likewise.
        (dw_cfi_oprnd1_desc): Handle DW_CFA_restore.
        * dwarf2out.h: Update.
        * emit-rtl.c (try_split): Don't split RTX_FRAME_RELATED_P.
        (copy_insn_1): Early out for null.
        * final.c (final_scan_insn): Call dwarf2out_begin_epilogue
        and dwarf2out_frame_debug_restore_state.
        * function.c (prologue, epilogue, sibcall_epilogue): Remove.
        (prologue_insn_hash, epilogue_insn_hash): New.
        (free_after_compilation): Adjust freeing accordingly.
        (record_insns): Create hash table if needed; push insns into
        hash instead of array.
        (maybe_copy_epilogue_insn): New.
        (contains): Search hash table instead of array.
        (sibcall_epilogue_contains): Remove.
        (thread_prologue_and_epilogue_insns): Split eh_return insns
        and mark them as epilogues.
        (reposition_prologue_and_epilogue_notes): Rewrite epilogue
        scanning in terms of basic blocks.
        * insn-notes.def (CFA_RESTORE_STATE): New.
        * jump.c (returnjump_p_1): Accept EH_RETURN.
        (eh_returnjump_p_1, eh_returnjump_p): New.
        * reg-notes.def (CFA_DEF_CFA, CFA_ADJUST_CFA, CFA_OFFSET,
        CFA_REGISTER, CFA_RESTORE): New.
        * rtl.def (EH_RETURN): New.
        * rtl.h (eh_returnjump_p, maybe_copy_epilogue_insn): Declare.

        * config/bfin/bfin.md (UNSPEC_VOLATILE_EH_RETURN): Remove.
        (eh_return_internal): Use eh_return rtx; split w/ epilogue.

        * config/i386/i386.c (gen_push): Update cfa state.
        (pro_epilogue_adjust_stack): Add set_cfa argument.  When true,
        add a CFA_ADJUST_CFA note.
        (ix86_dwarf_handle_frame_unspec): Remove.
        (ix86_expand_prologue): Update cfa state.
        (ix86_emit_restore_reg_using_pop): New.
        (ix86_emit_restore_regs_using_pop): New.
        (ix86_emit_leave): New.
        (ix86_emit_restore_regs_using_mov): Add CFA_RESTORE notes.
        (ix86_expand_epilogue): Add notes for unwinding the epilogue.
        * config/i386/i386.h (struct machine_cfa_state): New.
        (ix86_cfa_state): New.
        * config/i386/i386.md (UNSPEC_EH_RETURN): Remove.
        (eh_return_internal): Merge from eh_return_<mode>,
        use eh_return rtx, split w/ epilogue.



From devlists at shadowlab.org  Fri Sep 18 14:03:52 2009
From: devlists at shadowlab.org (Jean-Daniel Dupas)
Date: Fri, 18 Sep 2009 21:03:52 +0200
Subject: [LLVMdev] [PATCH] BlocksRuntime updates for Linux
In-Reply-To: <74663C84-9383-4D23-A844-7E8C16AA0D5E@apple.com>
References: <74663C84-9383-4D23-A844-7E8C16AA0D5E@apple.com>
Message-ID: <6F9239E0-A8ED-4B4F-8C3F-B080CF05DC33@shadowlab.org>


Le 18 sept. 2009 ? 20:14, Shantonu Sen a ?crit :

> The attached diff cleans up the BlocksRuntime/ directory of compiler- 
> rt for better portability, eliminates compiler warnings, and adds  
> support to the cmake build to install the results.
>
> More specifically, the changes:
> 1) Remove cmake-specific #define usage from the exported Block.h/ 
> Block_private.h headers, since clients won't know what to set. These  
> are moved into runtime.c as appropriate
> 2) Use cmake checks for CAS builtins, instead of guessing based on  
> GCC #defines (which aren't set by clang and llvm-gcc anyway)
> 3) "#pragma mark" isn't supported by FSF gcc, so "#if 0" it out. It  
> should still show up in IDEs that support it

FWIW, Xcode supports the following syntax instead of pragma mark:

// MARK: Your Label
or
// MARK:-
to create a separator.

If there is no other IDE that uses this pragma, it may be cleaner to  
replace them by this equivalent syntax.

> 4) Fix some compiler warnings. GCC 4.3.3 seems super strict about  
> %p. function pointers can't be cast to void * either.
> 5) Avoid a warning for apple_versioning.c that "ISO C does not allow  
> empty files"
>
> Tested on Ubuntu Linux 9.04 with clang and llvm-gcc and -fblocks to  
> define and copy some blocks (and invoke them, obviously). Also  
> tested on Mac OS X 10.6 and linking against -lBlocksRuntime ahead of  
> -lSystem.
>
> <blocks-linux.diff>
> Shantonu Sen
> ssen at apple.com
>
> Sent from my Mac Pro

-- Jean-Daniel






From howarth at bromo.med.uc.edu  Fri Sep 18 14:11:55 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 18 Sep 2009 15:11:55 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
Message-ID: <20090918191155.GA11242@bromo.med.uc.edu>

On Fri, Sep 18, 2009 at 11:13:52AM -0700, Nick Kledzik wrote:
>
>
> Has something changed in the FSF unwinder that clients of gcc will want?
>
> -Nick
>
>
Nick,
   I've always built FSF gcc as a stock build (which defaults to the
FSF libgcc for linking). The last time I can recall seeing anyone
build FSF gcc against the system libgcc was related to the thread...

http://gcc.gnu.org/ml/gcc/2008-11/msg00280.html

I believe this was being done with --with-slibdir='\$\${prefix}/ lib'.
Tonight I'll try building like that under SL and see what happens. It
is very non-standard though for how everyone builds FSF gcc on darwin.
                  Jack

From howarth at bromo.med.uc.edu  Fri Sep 18 14:33:15 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 18 Sep 2009 15:33:15 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
Message-ID: <20090918193315.GA11546@bromo.med.uc.edu>

Nick,
   So is this basically a depreciation of libgcc for darwin10 and
later? I was wondering about that very issue awhile ago (as in
what exactly what relationship clang would have to libgcc). If
so, perhaps the correct answer is to see if FSF gcc would accept
changing the default build for darwin10 and later to not use
the FSF libgcc and instead move any additional symbols into a
libgcc-ext.
                        Jack

From clattner at apple.com  Fri Sep 18 14:50:55 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 18 Sep 2009 12:50:55 -0700
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <20090918193315.GA11546@bromo.med.uc.edu>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
	<20090918193315.GA11546@bromo.med.uc.edu>
Message-ID: <314B0943-44E9-4ADF-BF96-491699229A6C@apple.com>


On Sep 18, 2009, at 12:33 PM, Jack Howarth wrote:

> Nick,
>   So is this basically a depreciation of libgcc for darwin10 and
> later?

Hi Jack,

I'm not sure what you mean by depreciation here.  Some perspective:

Darwin (like windows) has it's own system exception handling  
mechanisms and GCC shouldn't try to replace it.  Darwin has always  
been extremely conservative about ABI/API changes: we don't want to  
break our customer apps.  Any changes to libgcc that would break "old"  
unwinder functionality would be unacceptable on our platform,  
regardless of whether the unwinder is part of libsystem or not.

libgcc is still useful for adding other functionality (like emultls as  
you mentioned) as well as other arithmetic support libraries.  I do  
NOT think that "libgcc shouldn't be used on darwin", I just don't  
think the EH pieces should be.

> I was wondering about that very issue awhile ago (as in
> what exactly what relationship clang would have to libgcc). If
> so, perhaps the correct answer is to see if FSF gcc would accept
> changing the default build for darwin10 and later to not use
> the FSF libgcc and instead move any additional symbols into a
> libgcc-ext.

 From my limited understanding, that solution seems like it would work!

-Chris

From lattner at apple.com  Fri Sep 18 15:48:18 2009
From: lattner at apple.com (Tanya Lattner)
Date: Fri, 18 Sep 2009 13:48:18 -0700
Subject: [LLVMdev] BOFs at LLVM Developers' Meeting
Message-ID: <62AFA1A1-3B8F-4442-9D9A-F50E0198020A@apple.com>

Unique to this year's Developer Meeting, we will have Birds-of-a- 
Feather sessions (BOFs) that will coincide with the talks. For those  
unfamiliar with BOFs, these are attendee organized meetings for people  
to meet, exchange ideas, and share information on a variety of topics.  
BOF slots will be 40 minutes long. BOFs will be printed on the  
official schedule and be put on the website so attendees can plan to  
attend.

If you are interested in organizing a BOF, please email us no later  
than September 26th (llvm-devmtg-admin at nondot.org).

Thanks,
Tanya & Ted

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

From kledzik at apple.com  Fri Sep 18 16:27:30 2009
From: kledzik at apple.com (Nick Kledzik)
Date: Fri, 18 Sep 2009 14:27:30 -0700
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <20090918184012.GA11168@bromo.med.uc.edu>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
	<20090918184012.GA11168@bromo.med.uc.edu>
Message-ID: <4966267E-8EB7-4A61-BF0B-9FAB55A617E0@apple.com>

I dug into this.  Based on the .s files in bugzilla, the latest gcc is  
now adding dwarf unwind info to describe the function epilog.  If you  
run dwarfdump --eh-frame on the .o files made with the new compiler,  
you'll see extra dwarf unwind instructions at the end like:

                 ...
                 DW_CFA_advance_loc4 (64)  #<-- advance to near end of  
function
                 DW_CFA_restore (rbp)
                 DW_CFA_def_cfa (rsp, 8)
                 DW_CFA_nop
                 DW_CFA_nop

The linker's conversion to compact unwind "runs" the dwarf unwind info  
for a function and then records the state at the end.  Adding unwind  
info for the epilog breaks this.  In the long term, I can add  
heuristics to the linker to detect that what looks like unwind info  
for the epilog and stop processing the dwarf instructions.

The short term fix for gcc is to *not* add epilog unwind information  
for Darwin.

Epilog unwind information is never needed for exception processing.   
Its only use is for debugging or sampling when you want to  
asynchronously make a stack back trace.

-Nick

On Sep 18, 2009, at 11:40 AM, Jack Howarth wrote:
> I am not sure if some of these problems were latent and only
> exposed by the change, but the mass regressions in the g++
> and libjava testsuites were triggered by the commit...
>
> Author: rth
> Date: Sat May 30 00:33:46 2009
> New Revision: 147995
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147995


From kledzik at apple.com  Fri Sep 18 16:40:17 2009
From: kledzik at apple.com (Nick Kledzik)
Date: Fri, 18 Sep 2009 14:40:17 -0700
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <4966267E-8EB7-4A61-BF0B-9FAB55A617E0@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
	<20090918184012.GA11168@bromo.med.uc.edu>
	<4966267E-8EB7-4A61-BF0B-9FAB55A617E0@apple.com>
Message-ID: <A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>

I thought of another work around.  The FSF gcc driver can implicitly  
add -no_compact_unwind to the link line.  This tells the linker to not  
produce compact unwind information from the dwarf unwind info in .o  
files.  Then at runtime the darwin unwinder will fallback and use the  
slow dwarf unwind info.

-Nick

On Sep 18, 2009, at 2:27 PM, Nick Kledzik wrote:
> I dug into this.  Based on the .s files in bugzilla, the latest gcc is
> now adding dwarf unwind info to describe the function epilog.  If you
> run dwarfdump --eh-frame on the .o files made with the new compiler,
> you'll see extra dwarf unwind instructions at the end like:
>
>                 ...
>                 DW_CFA_advance_loc4 (64)  #<-- advance to near end of
> function
>                 DW_CFA_restore (rbp)
>                 DW_CFA_def_cfa (rsp, 8)
>                 DW_CFA_nop
>                 DW_CFA_nop
>
> The linker's conversion to compact unwind "runs" the dwarf unwind info
> for a function and then records the state at the end.  Adding unwind
> info for the epilog breaks this.  In the long term, I can add
> heuristics to the linker to detect that what looks like unwind info
> for the epilog and stop processing the dwarf instructions.
>
> The short term fix for gcc is to *not* add epilog unwind information
> for Darwin.
>
> Epilog unwind information is never needed for exception processing.
> Its only use is for debugging or sampling when you want to
> asynchronously make a stack back trace.
>
> -Nick
>
> On Sep 18, 2009, at 11:40 AM, Jack Howarth wrote:
>> I am not sure if some of these problems were latent and only
>> exposed by the change, but the mass regressions in the g++
>> and libjava testsuites were triggered by the commit...
>>
>> Author: rth
>> Date: Sat May 30 00:33:46 2009
>> New Revision: 147995
>>
>> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147995
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From andreas at digitalplaywright.com  Fri Sep 18 16:46:33 2009
From: andreas at digitalplaywright.com (Andreas Saebjoernsen)
Date: Fri, 18 Sep 2009 14:46:33 -0700
Subject: [LLVMdev] compiling java frontend
In-Reply-To: <4AB31E06.8030505@lip6.fr>
References: <167925200909171559t28ce0e49w2d556367118f09aa@mail.gmail.com>
	<5CC16047-3CA6-4C83-8162-80BFA89A9334@apple.com>
	<167925200909171617x5bc77887hc5a92dee22f784d1@mail.gmail.com>
	<ED47E4D2-359B-40E6-86F5-312A55F5CE89@apple.com>
	<167925200909171842h1c7a702fj3420ec284fb9a45b@mail.gmail.com>
	<4AB31E06.8030505@lip6.fr>
Message-ID: <167925200909181446r4af4ad2eu1aa8539c536bf217@mail.gmail.com>

Thanks! That worked. Everything is now set up and I am doing experiments.
Andreas

On Thu, Sep 17, 2009 at 10:43 PM, Nicolas Geoffray <nicolas.geoffray at lip6.fr
> wrote:

> Hi Andreas,
>
> Since you're only looking for a Java frontend, I suggest you only build
> the Java frontend of vmkit and don't pass any pnet or mono information
> to the configure script. I haven't updated the pnet part of the .Net
> frontend. On the other hand, the Java frontend is up-to-date.
>
> Nicolas
>
> Andreas Saebjoernsen wrote:
> > Thanks, I am now working on compiling up VMKit.  When compiling VMKit
> > in my up-to-date svn checkout I get several error messages on missing
> > members of the class 'llvm::Type':
> >
> > PNetLib.cpp: In function ?void decapsulePrimitive(n3::VMObject*, const
> > llvm::Type*, std::vector<llvm::GenericValue,
> > std::allocator<llvm::GenericValue> >&)?:
> > PNetLib.cpp:694: error: ?Int1Ty? is not a member of ?llvm::Type?
> > PNetLib.cpp:698: error: ?Int8Ty? is not a member of ?llvm::Type?
> > PNetLib.cpp:702: error: ?Int16Ty? is not a member of ?llvm::Type?
> > PNetLib.cpp:706: error: ?Int32Ty? is not a member of ?llvm::Type?
> >
> > There are several other errors on the same form. When inspecting the
> > source code of llvm::Type I do not see any member variables with those
> > names, but I see member functions on the form 'getInt1Ty(LLVMContext
> > &C)' where LLVMContextImpl have member variables with those names. Do
> > you know how to solve this problem?
> >
> > thanks,
> > Andreas
> >
> >
> > On Thu, Sep 17, 2009 at 4:22 PM, Chris Lattner <clattner at apple.com
> > <mailto:clattner at apple.com>> wrote:
> >
> >
> >     On Sep 17, 2009, at 4:17 PM, Andreas Saebjoernsen wrote:
> >
> >>     I am trying to compile the Java frontend in
> >>          https:/llvm.org/svn/llvm-project/java/trunk
> >>     <http://llvm.org/svn/llvm-project/java/trunk>
> >>     If there are another preferred Java frontend available, and it is
> >>     suited for translating Java bytecode to LLVM bytecode, I'd be
> >>     happy to use that frontend instead.
> >
> >     That is really old and out of date, I'm sure it doesn't work
> >     anymore.  Check out http://vmkit.llvm.org/
> >
> >     -Chris
> >
> >>
> >>     thanks,
> >>     Andreas
> >>
> >>     On Thu, Sep 17, 2009 at 4:03 PM, Chris Lattner
> >>     <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> >>
> >>
> >>         On Sep 17, 2009, at 3:59 PM, Andreas Saebjoernsen wrote:
> >>
> >>             I am looking for a way to translate Java bytecode to LLVM
> >>             bytecode and the LLVM Java frontend seem like a good
> >>             match for initial testing.  But after checking out the
> >>             svn version of the Java frontend I get the following
> >>             error when running configure
> >>
> >>                configure: error: cannot find install-sh or install.sh
> >>             in ../../autoconf ./../../autoconf
> >>
> >>             This error persisted even after successfully regenerating
> >>             configure with the 'AutoRegen.sh' script in the
> >>             'java/trunk/autoconf' subdirectory. Do you have any
> >>             advice on how to configure and compile the Java frontend?
> >>
> >>
> >>         Which java frontend?
> >>
> >>         -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090918/2caf0f41/attachment.html 

From jalbert at eecs.berkeley.edu  Fri Sep 18 17:10:51 2009
From: jalbert at eecs.berkeley.edu (Nick Jalbert)
Date: Fri, 18 Sep 2009 15:10:51 -0700
Subject: [LLVMdev] llc and debug information
In-Reply-To: <4AB1FF43.3000409@free.fr>
References: <12af9dc80909161334r527ba1fci69090b8d7e416d3b@mail.gmail.com>
	<352a1fb20909161429h7a384053n767c215779c04e6e@mail.gmail.com>
	<12af9dc80909161602k1021614mbf79c5dd62a051a4@mail.gmail.com>
	<4AB1FF43.3000409@free.fr>
Message-ID: <12af9dc80909181510y763e9e3bse8388ee38056aee6@mail.gmail.com>

Figured out my problem, mailing the list in case anyone else runs into the
same issue.  I had updated the LLVM tools to the svn version, but not the
front end.  It seems that debugging information is handled differently with
the latest version of the tools (perhaps as a result of this
proposal<http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025648.html>?).
 I ended up grabbing a prerelease of llvm2.6 found
here<http://llvm.org/prereleases/2.6/>,
and building both the front end and the LLVM tools from source.  Using tools
from a consistent period in time solved my problem--oops!
Thanks to everyone who tried to help out :).

-Nick

On Thu, Sep 17, 2009 at 2:20 AM, Duncan Sands <baldrick at free.fr> wrote:

> Nick Jalbert wrote:
>
>> Thanks for the quick responses, but unfortunately still no luck:
>>
>>  > llvm-g++ -g -O0 -c -emit-llvm test.cpp
>>  > llc -O0 test.o
>>  > g++ test.o.s
>>  > ./a.out My return address is 0x400bb2
>>  > addr2line 0x400bb2
>> ??:0
>>
>> Also to further implicate llc, this works:
>>
>>  > llvm-g++ -g -O0 -S test.cpp  > g++ test.s  > ./a.out My return address
>> is 0x400bf9
>>  > addr2line 0x400bf9
>> /home/jalbert/llvmtest//test.cpp:13
>>
>> Anymore thoughts?
>>
>
> maybe try passing -disable-fp-elim to llc?
>
> Ciao,
>
> Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090918/c8acc225/attachment.html 

From howarth at bromo.med.uc.edu  Fri Sep 18 18:28:56 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 18 Sep 2009 19:28:56 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
	<20090918184012.GA11168@bromo.med.uc.edu>
	<4966267E-8EB7-4A61-BF0B-9FAB55A617E0@apple.com>
	<A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>
Message-ID: <20090918232856.GA12805@bromo.med.uc.edu>

On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:
> I thought of another work around.  The FSF gcc driver can implicitly  
> add -no_compact_unwind to the link line.  This tells the linker to not  
> produce compact unwind information from the dwarf unwind info in .o  
> files.  Then at runtime the darwin unwinder will fallback and use the  
> slow dwarf unwind info.
> 
> -Nick
> 

Nick,
   Thanks! I have asked Richard to propose a patch to disable the
additional epilog info on darwin. While we are on the topic of
eh issues on darwin, could you take a look at PR37012? On darwin9/10.
we have the following remaining failures in gcc-4.4.1 at -m32...

FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -g  execution test

These eh failures are really weird because they are triggered by the
-g option. Without -g, the resulting test cases pass their execution
tests fine. The problem doesn't exist for -m64 (with or without -g).
I posted assembly files for these testcases at the various 
combinations (-m32 -O3, -m32 -O3 -g, -m64 -O3 -g, -m64 -O3)...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c48
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c51

Perhaps if you diff the assembly files, you might recognize the
problem in that one as well.
              Jack

From isanbard at gmail.com  Fri Sep 18 18:49:57 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Fri, 18 Sep 2009 16:49:57 -0700
Subject: [LLVMdev] Exception Handling Tables Question
In-Reply-To: <4AB2DC5C.10206@free.fr>
References: <69E71812-8BD1-4E91-89E6-E2A7451EC681@gmail.com>	<4AB0ED25.60404@math.u-psud.fr>	<8C3D88DB-C5D0-4DCE-9733-5666D6731FD2@gmail.com>	<4AB2123B.3020807@math.u-psud.fr>
	<16e5fdf90909171311y56936ef8t86ef8f9b4c8cd2a5@mail.gmail.com>
	<4AB2DC5C.10206@free.fr>
Message-ID: <57178CF0-0053-450C-B313-5F081CF89977@gmail.com>

On Sep 17, 2009, at 6:03 PM, Duncan Sands wrote:

>> There's a miscommunication here. :-) The _Unwind_resume call isn't
>> marked with "nounwind", however it's not called through an "invoke"
>> instruction, only a regular "call" instruction. From what I can see,
>> the only reason it falls within a call site in the exception table is
>> because we're generating call sites for areas of code without
>> "invokes".
>
> yes, and that's absolutely the right thing to do!  Due to a strange
> design choice, if a call does *not* have an entry in the call-site
> table, and the call unwinds, then the runtime calls std::terminate.
> All calls that may throw (like _Unwind_Resume!) must have an entry
> in the call-site table.
>
> If I implement my optimization to eliminate these call site
>> entries which don't have "invoke" calls in them, then the
>> _Unwind_resume call won't have an entry into the exception table, and
>> that would be bad.
>
> As explained above, you can only eliminate call-site entries for
> nounwind calls.  Having a call-site entry has nothing to do with
> whether a call is an invoke or not, it is to do with whether the
> call can throw an exception or not.
>
I was imprecise, but yes, I meant to say that we shouldn't have one  
for "nounwind" calls. :-)

-bw


From zhunansjtu at gmail.com  Fri Sep 18 19:28:57 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Sat, 19 Sep 2009 08:28:57 +0800
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <4AB359DF.70500@gmail.com>
References: <1253191769.4354.6.camel@UIUC>
	<38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>
	<ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>
	<38a0d8450909171052j3385d151q4b288ba5c21d6dd9@mail.gmail.com>
	<ffabe8bd0909171706q1a3ced2eq2e2f326e39c5bca6@mail.gmail.com>
	<4AB359DF.70500@gmail.com>
Message-ID: <1253320137.6408.2.camel@UIUC>

Yes,but ubuntu's directory structure is not exactly the same as the
classic linux distribute,

I put libLLVMgold.so in /usr/lib/gcc/i486-linux-gnu/4.2.4 where cc1 is
also in.

Strange situation,is it a bug for llvm-gcc????

? 2009-09-18?? 12:58 +0300?T?r?k Edwin???
> On 2009-09-18 03:06, Nan Zhu wrote:
> > OMG,that's just my situation...
> >  
> > I can link with libLLVMgold.so manualy,but will fail in that by llvm-gcc.
> >  
> > Debug llvm-gcc?????
> >  
> > Any one installed the gold-plugin successfully can give some instruction?
> 
> Does the directory where you put the gold plugin look like this?
> $PREFIX/libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/
> 
> Where $PREFIX is the prefix where you installed llvm-gcc
> 
> Best regards,
> --Edwin
> 


From espindola at google.com  Fri Sep 18 19:48:44 2009
From: espindola at google.com (Rafael Espindola)
Date: Fri, 18 Sep 2009 20:48:44 -0400
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <1253320137.6408.2.camel@UIUC>
References: <1253191769.4354.6.camel@UIUC>
	<38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>
	<ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>
	<38a0d8450909171052j3385d151q4b288ba5c21d6dd9@mail.gmail.com>
	<ffabe8bd0909171706q1a3ced2eq2e2f326e39c5bca6@mail.gmail.com>
	<4AB359DF.70500@gmail.com> <1253320137.6408.2.camel@UIUC>
Message-ID: <38a0d8450909181748x215405d9y93af4e65e4849a49@mail.gmail.com>

2009/9/18 zhunan <zhunansjtu at gmail.com>:
> Yes,but ubuntu's directory structure is not exactly the same as the
> classic linux distribute,
>
> I put libLLVMgold.so in /usr/lib/gcc/i486-linux-gnu/4.2.4 where cc1 is
> also in.
>
> Strange situation,is it a bug for llvm-gcc????

Could be. Are you comfortable using gdb? Last time I looked it
was working for me.

Cheers,
-- 
Rafael Avila de Espindola

From zhunansjtu at gmail.com  Fri Sep 18 21:06:47 2009
From: zhunansjtu at gmail.com (Nan Zhu)
Date: Sat, 19 Sep 2009 10:06:47 +0800
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <38a0d8450909181748x215405d9y93af4e65e4849a49@mail.gmail.com>
References: <1253191769.4354.6.camel@UIUC>
	<38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>
	<ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>
	<38a0d8450909171052j3385d151q4b288ba5c21d6dd9@mail.gmail.com>
	<ffabe8bd0909171706q1a3ced2eq2e2f326e39c5bca6@mail.gmail.com>
	<4AB359DF.70500@gmail.com> <1253320137.6408.2.camel@UIUC>
	<38a0d8450909181748x215405d9y93af4e65e4849a49@mail.gmail.com>
Message-ID: <ffabe8bd0909181906g680513d8tc375407f41eed80f@mail.gmail.com>

Yes,gdb could be a solution,but my final goal is to automalize the linking
procedure just like what the GNU build system does,gdb may not works for
that.

So,some others mentioned gold-plugin can work for some certain problems,I
don't know how they archieve this.




2009/9/19 Rafael Espindola <espindola at google.com>

> 2009/9/18 zhunan <zhunansjtu at gmail.com>:
> > Yes,but ubuntu's directory structure is not exactly the same as the
> > classic linux distribute,
> >
> > I put libLLVMgold.so in /usr/lib/gcc/i486-linux-gnu/4.2.4 where cc1 is
> > also in.
> >
> > Strange situation,is it a bug for llvm-gcc????
>
> Could be. Are you comfortable using gdb? Last time I looked it
> was working for me.
>
> Cheers,
> --
> Rafael Avila de Espindola
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090919/6adc15b7/attachment.html 

From howarth at bromo.med.uc.edu  Fri Sep 18 22:19:37 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 18 Sep 2009 23:19:37 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
	<20090918184012.GA11168@bromo.med.uc.edu>
	<4966267E-8EB7-4A61-BF0B-9FAB55A617E0@apple.com>
	<A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>
Message-ID: <20090919031936.GA14220@bromo.med.uc.edu>

On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:
> I thought of another work around.  The FSF gcc driver can implicitly  
> add -no_compact_unwind to the link line.  This tells the linker to not  
> produce compact unwind information from the dwarf unwind info in .o  
> files.  Then at runtime the darwin unwinder will fallback and use the  
> slow dwarf unwind info.
> 
> -Nick
> 

Nick,
   I can confirm that passing "-Wl,-no_compact_unwind" to the failing
testcase for g++.dg/torture/stackalign/eh-vararg-2.C eliminates the
run-time error. I'd run the entire testsuite with that approach but
I don't know how to suppress the comma in...

make -k  check RUNTESTFLAGS="--target_board=unix'{-Wl,-no_compact_unwind}'"

so that it runs as a single test passing "-Wl,-no_compact_unwind".
             Jack

From howarth at bromo.med.uc.edu  Sat Sep 19 01:27:41 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Sat, 19 Sep 2009 02:27:41 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
	<20090918184012.GA11168@bromo.med.uc.edu>
	<4966267E-8EB7-4A61-BF0B-9FAB55A617E0@apple.com>
	<A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>
Message-ID: <20090919062741.GA15120@bromo.med.uc.edu>

On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:
> I thought of another work around.  The FSF gcc driver can implicitly  
> add -no_compact_unwind to the link line.  This tells the linker to not  
> produce compact unwind information from the dwarf unwind info in .o  
> files.  Then at runtime the darwin unwinder will fallback and use the  
> slow dwarf unwind info.
> 
> -Nick
> 

Nick,
   FYI, executing...

make -k check RUNTESTFLAGS="--target_board=unix/-Wl,-no_compact_unwind"

reveals that this approach in fact eliminates all of the eh regressions
in gcc trunk. Unfortunately, it plays havoc with the gcc.dg/pch and
g++.dg/pch test cases causing hundreds of new failures of the form...

FAIL: ./common-1.h -O0 -g (test for excess errors)
FAIL: gcc.dg/pch/common-1.c -O0 -g
FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison


Executing on host: /sw/src/fink.build/gcc45-4.4.999-20090914/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20090914/darwin_objdir/gcc/ ./common-1.h  -O0 -g   -Wl,-no_compact_unwind -o common-1.h.gch    (timeout = 300)
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

FAIL: ./common-1.h -O0 -g (test for excess errors)
Excess errors:
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.5.o
ld: symbol(s) not found

pch file 'common-1.h.gch' missing
FAIL: gcc.dg/pch/common-1.c -O0 -g
assembly file 'common-1.s' missing
FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison


                 Jack

From edwintorok at gmail.com  Sat Sep 19 01:51:02 2009
From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=)
Date: Sat, 19 Sep 2009 09:51:02 +0300
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <1253320137.6408.2.camel@UIUC>
References: <1253191769.4354.6.camel@UIUC>	
	<38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>	
	<ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>	
	<38a0d8450909171052j3385d151q4b288ba5c21d6dd9@mail.gmail.com>	
	<ffabe8bd0909171706q1a3ced2eq2e2f326e39c5bca6@mail.gmail.com>	
	<4AB359DF.70500@gmail.com> <1253320137.6408.2.camel@UIUC>
Message-ID: <4AB47F56.8080006@gmail.com>

On 2009-09-19 03:28, zhunan wrote:
> Yes,but ubuntu's directory structure is not exactly the same as the
> classic linux distribute,
>
> I put libLLVMgold.so in /usr/lib/gcc/i486-linux-gnu/4.2.4 where cc1 is
> also in.
>
>   

Are you sure that is llvm-gcc's cc1, and not your system compiler's?
Try this:
$ llvm-gcc  -### -x c /dev/null

Then look for a line containing cc1, something similar to this one:
"/home/edwin/llvm-git/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/cc1"
"-quiet" "-iprefix"
"/home/edwin/llvm-git/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/"
"/dev/null" "-quiet" "-dumpbase" "null" "-mtune=generic" "-auxbase"
"null" "-o" "/tmp/cceoliII.s"


> Strange situation,is it a bug for llvm-gcc????
>
> ? 2009-09-18?? 12:58 +0300?T?r?k Edwin???
>   
>> On 2009-09-18 03:06, Nan Zhu wrote:
>>     
>>> OMG,that's just my situation...
>>>  
>>> I can link with libLLVMgold.so manualy,but will fail in that by llvm-gcc.
>>>  
>>> Debug llvm-gcc?????
>>>  
>>> Any one installed the gold-plugin successfully can give some instruction?
>>>       
>> Does the directory where you put the gold plugin look like this?
>> $PREFIX/libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/
>>
>> Where $PREFIX is the prefix where you installed llvm-gcc
>>
>> Best regards,
>> --Edwin
>>
>>     
>
>   


From daniel at zuster.org  Sat Sep 19 02:13:19 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 19 Sep 2009 00:13:19 -0700
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <20090919031936.GA14220@bromo.med.uc.edu>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
	<20090918184012.GA11168@bromo.med.uc.edu>
	<4966267E-8EB7-4A61-BF0B-9FAB55A617E0@apple.com>
	<A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>
	<20090919031936.GA14220@bromo.med.uc.edu>
Message-ID: <6a8523d60909190013y39feaeej3ea907c0c49fc075@mail.gmail.com>

On Fri, Sep 18, 2009 at 8:19 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:
>> I thought of another work around. ?The FSF gcc driver can implicitly
>> add -no_compact_unwind to the link line. ?This tells the linker to not
>> produce compact unwind information from the dwarf unwind info in .o
>> files. ?Then at runtime the darwin unwinder will fallback and use the
>> slow dwarf unwind info.
>>
>> -Nick
>>
>
> Nick,
> ? I can confirm that passing "-Wl,-no_compact_unwind" to the failing
> testcase for g++.dg/torture/stackalign/eh-vararg-2.C eliminates the
> run-time error. I'd run the entire testsuite with that approach but
> I don't know how to suppress the comma in...
>
> make -k ?check RUNTESTFLAGS="--target_board=unix'{-Wl,-no_compact_unwind}'"

Perhaps try using -Xlinker?

 - Daniel


From zhunansjtu at gmail.com  Sat Sep 19 03:47:08 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Sat, 19 Sep 2009 16:47:08 +0800
Subject: [LLVMdev] Where should I put libLLVMgold.so??
In-Reply-To: <4AB47F56.8080006@gmail.com>
References: <1253191769.4354.6.camel@UIUC>
	<38a0d8450909170649l5be7a0a2u684ed6cd1753eac5@mail.gmail.com>
	<ffabe8bd0909171039s2ff31c5fo328de6d9e7c703f4@mail.gmail.com>
	<38a0d8450909171052j3385d151q4b288ba5c21d6dd9@mail.gmail.com>
	<ffabe8bd0909171706q1a3ced2eq2e2f326e39c5bca6@mail.gmail.com>
	<4AB359DF.70500@gmail.com> <1253320137.6408.2.camel@UIUC>
	<4AB47F56.8080006@gmail.com>
Message-ID: <1253350028.10322.5.camel@UIUC>

Thank you , yes,I took the wrong directory,and I archieve the goal under
your instructions,

thank you 



? 2009-09-19?? 09:51 +0300?T?r?k Edwin???
> On 2009-09-19 03:28, zhunan wrote:
> > Yes,but ubuntu's directory structure is not exactly the same as the
> > classic linux distribute,
> >
> > I put libLLVMgold.so in /usr/lib/gcc/i486-linux-gnu/4.2.4 where cc1 is
> > also in.
> >
> >   
> 
> Are you sure that is llvm-gcc's cc1, and not your system compiler's?
> Try this:
> $ llvm-gcc  -### -x c /dev/null
> 
> Then look for a line containing cc1, something similar to this one:
> "/home/edwin/llvm-git/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/cc1"
> "-quiet" "-iprefix"
> "/home/edwin/llvm-git/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/"
> "/dev/null" "-quiet" "-dumpbase" "null" "-mtune=generic" "-auxbase"
> "null" "-o" "/tmp/cceoliII.s"
> 
> 
> > Strange situation,is it a bug for llvm-gcc????
> >
> > ? 2009-09-18?? 12:58 +0300?T?r?k Edwin???
> >   
> >> On 2009-09-18 03:06, Nan Zhu wrote:
> >>     
> >>> OMG,that's just my situation...
> >>>  
> >>> I can link with libLLVMgold.so manualy,but will fail in that by llvm-gcc.
> >>>  
> >>> Debug llvm-gcc?????
> >>>  
> >>> Any one installed the gold-plugin successfully can give some instruction?
> >>>       
> >> Does the directory where you put the gold plugin look like this?
> >> $PREFIX/libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/
> >>
> >> Where $PREFIX is the prefix where you installed llvm-gcc
> >>
> >> Best regards,
> >> --Edwin
> >>
> >>     
> >
> >   
> 


From tilmann.scheller at googlemail.com  Sat Sep 19 12:41:06 2009
From: tilmann.scheller at googlemail.com (Tilmann Scheller)
Date: Sat, 19 Sep 2009 19:41:06 +0200
Subject: [LLVMdev] x86-32 to llvm bytecode
In-Reply-To: <20090918162336.GA95965@dawn.local>
References: <20090918162336.GA95965@dawn.local>
Message-ID: <aec43a860909191041m34e4ae55jd23b59bcbdf451d2@mail.gmail.com>

Hi Marius,

On Fri, Sep 18, 2009 at 6:23 PM, Marius <wishinet at googlemail.com> wrote:
> I recently strumbled across llvm-qemu
> (http://code.google.com/p/llvm-qemu/) which apparantly should be able to
> translate qemu supported architectures to LLVM IR
> (http://markmail.org/message/iyqzgtcux62wdhkb) to ease analysing
> binaries.
Yes, at runtime and at basic block level this is very much possible.
Whether this is useful to you largely depends on what you actually
want to do :)  But e.g. for binary instrumentation this should work.

> Using LLVM for (dynamic binary) translations seems to be a great
> idea. However I haven't seen many approaches being made in that
> direction.
Yeah, I think llvm-qemu is the only project in this regard.

> Valgrind's VEX (RISC like intermediate language) seems to be
> used in Bitblaze VINE (http://bitblaze.cs.berkeley.edu/vine.html).
Looks like an interesting project. VEX seems to be very similar to
LLVM IR. I'd be curious to see how effective the static binary
analysis done by Vine actually is.

> Does anybody know a similar project for LLVM? - Because the llvm-qemu
> seems to have specific downsides linked to qemu emulation engine.
I'm not aware of any projects which do binary analysis with LLVM.

What downsides are you referring to? The fact that it doesn't do a
"direct" translation?

At one point someone was working on a direct translation from x86 to
LLVM IR, never heard anything about it again though.

Cheers,

Tilmann

From wanderon at comcast.net  Sat Sep 19 13:37:28 2009
From: wanderon at comcast.net (Wayne Anderson)
Date: Sat, 19 Sep 2009 12:37:28 -0600
Subject: [LLVMdev] Native Assembler for ARM
Message-ID: <D7663D09-3022-412D-AADD-4CEA0127CDFF@comcast.net>

Hello,

I hope I'm not missing something obvious.  I'm trying to get a native  
binary for ARM from a .s file.  If I try to run "as -arch arm  
myFile.s" I get an error message indicating that no installed  
assembler exists for arm.

as: assembler (/usr/bin/../libexec/gcc/darwin/arm/as or /usr/bin/../ 
local/libexec/gcc/darwin/arm/as) for architecture arm not installed
Installed assemblers are:
/usr/bin/../libexec/gcc/darwin/ppc64/as for architecture ppc64
/usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
/usr/bin/../libexec/gcc/darwin/ppc/as for architecture ppc
/usr/bin/../libexec/gcc/darwin/i386/as for architecture i386


Can anyone point me to where can I get the ARM assembler.  Or should  
I  be using something else.


Thanks,

Wayne


______________________
Wayne Anderson
wanderon at comcast.net

From brukman at gmail.com  Sat Sep 19 13:48:33 2009
From: brukman at gmail.com (Misha Brukman)
Date: Sat, 19 Sep 2009 14:48:33 -0400
Subject: [LLVMdev] Native Assembler for ARM
In-Reply-To: <D7663D09-3022-412D-AADD-4CEA0127CDFF@comcast.net>
References: <D7663D09-3022-412D-AADD-4CEA0127CDFF@comcast.net>
Message-ID: <f88b89a50909191148l160b42a4m9930e7a5f25808d5@mail.gmail.com>

On Sat, Sep 19, 2009 at 2:37 PM, Wayne Anderson <wanderon at comcast.net>wrote:

> I hope I'm not missing something obvious.  I'm trying to get a native
> binary for ARM from a .s file.  If I try to run "as -arch arm
> myFile.s" I get an error message indicating that no installed
> assembler exists for arm.
>
> as: assembler (/usr/bin/../libexec/gcc/darwin/arm/as or /usr/bin/../
> local/libexec/gcc/darwin/arm/as) for architecture arm not installed
> Installed assemblers are:
> /usr/bin/../libexec/gcc/darwin/ppc64/as for architecture ppc64
> /usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
> /usr/bin/../libexec/gcc/darwin/ppc/as for architecture ppc
> /usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
>
> Can anyone point me to where can I get the ARM assembler.  Or should
> I  be using something else.
>

You're trying to cross-compile, so you'll need to either download or build a
cross-assembler (from binutils).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090919/39c718a9/attachment.html 

From zhunansjtu at gmail.com  Sat Sep 19 20:13:29 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Sun, 20 Sep 2009 09:13:29 +0800
Subject: [LLVMdev] ld with gold-plugin can do this?
Message-ID: <1253409209.6504.39.camel@UIUC>

Hi,all

I have installed the gold-plugin and it can run correctly,but I still
have another two questions:

1.Can gold-plugin generate a bitcode file:

>From the document and also my experience on using it,"ld -plugin...."
will only generate an executable by link several LLVM bitcode file
together,but how to make it generate a whole-program bitcode file?(even
archieve it manually is OK)

2.llvm-gcc -c will stop the linker to run:

I have been trying to generate a whole-program bitcode file,but when I
use CFLAGS="-emit-llvm -c" to compile source files into LLVM bitcode
file,llvm-gcc will not call "ld" to link modules together,so that I
cannot link these modules together automatically.

How to overcome this trouble?

Thank you !Best regards!

Nan



From nicholas at mxc.ca  Sat Sep 19 20:23:55 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 19 Sep 2009 18:23:55 -0700
Subject: [LLVMdev] ld with gold-plugin can do this?
In-Reply-To: <1253409209.6504.39.camel@UIUC>
References: <1253409209.6504.39.camel@UIUC>
Message-ID: <4AB5842B.2040702@mxc.ca>

zhunan wrote:
> Hi,all
> 
> I have installed the gold-plugin and it can run correctly,but I still
> have another two questions:
> 
> 1.Can gold-plugin generate a bitcode file:

No. The task of linking many .bc files into a single .bc file falls on 
llvm-ld and llvm-link.

A common followup question is "but how do I link native libraries into 
my .bc file". You don't. A .bc file is llvm ir, you can't put a native 
binary library into a .bc (barring sticking it in as a string, etc).

The build then looks like:

a) 'llvm-gcc -c -flo -O2' to generate the .bc files.
b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a .a.
c) 'llc' to turn your combined .bc into a .s
d) 'as' to turn your .s into a .o
e) 'ld' to turn your .o into a .so or final executable. This is the step 
where you get to specify all the native libraries to link with.

You can use 'gcc' to merge steps d and e (it just runs as and ld for 
you). Or you can use the gold plugin to merge steps b through e, but 
with the added benefit that it will optimize slightly better. See the 
llvm LTO documentation on why.

>>From the document and also my experience on using it,"ld -plugin...."
> will only generate an executable by link several LLVM bitcode file
> together,but how to make it generate a whole-program bitcode file?(even
> archieve it manually is OK)
> 
> 2.llvm-gcc -c will stop the linker to run:
> 
> I have been trying to generate a whole-program bitcode file,but when I
> use CFLAGS="-emit-llvm -c" to compile source files into LLVM bitcode
> file,llvm-gcc will not call "ld" to link modules together,so that I
> cannot link these modules together automatically.
> 
> How to overcome this trouble?

You get to modify your program's build system. Things like 'configure' 
work by trying to compile and run small programs. You can't run a .bc file.

Nick


From andrew at aj.id.au  Sat Sep 19 20:47:40 2009
From: andrew at aj.id.au (Andrew Jeffery)
Date: Sun, 20 Sep 2009 11:17:40 +0930
Subject: [LLVMdev] Global register variables/custom calling conventions
Message-ID: <4AB589BC.1070702@aj.id.au>

Hi all,

I'm implementing an LLVM backend for qemu-arm (by creating an ARM 
frontend for LLVM - from what I understand a slightly different approach 
than the original llvm-qemu project) and I've got to the point where I 
have to deal with Qemu's use of global register variables. From what 
I've read LLVM doesn't support GCC style register variables and the 
workaround was to implement a custom calling convention to ensure they 
weren't clobbered (at least from a caller's point of view)[1]. I haven't 
played with the LLVM code base much, just used the interfaces, and so 
was wondering if anyone had some pointers on what to look at/how to go 
about this?

Cheers,

Andrew

[1] 
http://markmail.org/message/ko3rrf5zacoocvg5#query:+page:1+mid:5uygbscyiqmuxqi4+state:results

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090920/ec1016d7/attachment.bin 

From anton at korobeynikov.info  Sun Sep 20 01:45:40 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Sun, 20 Sep 2009 10:45:40 +0400
Subject: [LLVMdev] Global register variables/custom calling conventions
In-Reply-To: <4AB589BC.1070702@aj.id.au>
References: <4AB589BC.1070702@aj.id.au>
Message-ID: <b087fca00909192345k6b727fcdtf79a28599e5796ae@mail.gmail.com>

Hello

> I'm implementing an LLVM backend for qemu-arm (by creating an ARM frontend
> for LLVM - from what I understand a slightly different approach than the
> original llvm-qemu project)
I don't see the difference so far. Could you please explain?

> and I've got to the point where I have to deal with Qemu's use of global register variables.
Why? The whole point of llvm-qemu project was that you don't need to
go with all that hacks and workarounds - you just emit LLVM IR and let
the codegenerator deal with register allocation, etc. For example, you
have much available registers on x86-64 (and even on x86-32!).

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From andrew at aj.id.au  Sun Sep 20 04:01:36 2009
From: andrew at aj.id.au (Andrew Jeffery)
Date: Sun, 20 Sep 2009 18:31:36 +0930
Subject: [LLVMdev] Global register variables/custom calling conventions
In-Reply-To: <b087fca00909192345k6b727fcdtf79a28599e5796ae@mail.gmail.com>
References: <4AB589BC.1070702@aj.id.au>
	<b087fca00909192345k6b727fcdtf79a28599e5796ae@mail.gmail.com>
Message-ID: <4AB5EF70.20209@aj.id.au>

Anton Korobeynikov wrote:
> Hello
> 
>> I'm implementing an LLVM backend for qemu-arm (by creating an ARM frontend
>> for LLVM - from what I understand a slightly different approach than the
>> original llvm-qemu project)
> I don't see the difference so far. Could you please explain?

Again, from what I understand, llvm-qemu worked by emitting LLVM IR from 
QEMU IR API calls. This project goes straight from ARM to LLVM IR, 
bypassing QEMU's IR, (partially) in the hope that more information about 
the original intent of the code is retained. I don't have any numbers 
handy for comparison against the argument "it'd optimise away", however, 
we have to have an implementation to test this theory anyway ;)

> 
>> and I've got to the point where I have to deal with Qemu's use of global register variables.
> Why? The whole point of llvm-qemu project was that you don't need to
> go with all that hacks and workarounds

The point of this is to provide an alternative backend to QEMU that can 
be run in a separate thread to generate optimised blocks, while working 
as transparently as possible. A nice property of TCG (QEMU's current 
JIT, which was dyngen when llvm-qemu was written) is that it's extremely 
fast at generating reasonable code - this approach keeps it in place 
while we do extra, possibly more expensive work out of sight. It might 
not be a pretty idea, but LLVM does generate some very tight code :) 
It's an experiment - humour me...

Sorry if this is somewhat OT.

Cheers,

Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090920/e52618eb/attachment.bin 

From kennethuil at gmail.com  Sun Sep 20 13:36:08 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 20 Sep 2009 13:36:08 -0500
Subject: [LLVMdev] struct returns
In-Reply-To: <01C8409B-A919-48F4-BEA6-6C9CA25B49DD@apple.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
	<FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
	<400d33ea0909160558kd7fd636m12a63ee2bcbcc752@mail.gmail.com>
	<01C8409B-A919-48F4-BEA6-6C9CA25B49DD@apple.com>
Message-ID: <400d33ea0909201136y44fc37eenf5fb097adb680299@mail.gmail.com>

I wish to assure you that I have not forgotten this task, nor failed
to start on it, but I cannot give even a rough estimate on when it
will be completed.

It occurs to me that all declarations of a function pointer, and all
bitcasts to a function pointer, could possibly refer to a function
whose signature must be altered by this fix.  Is the function
signature relevant to the SelectionDAG representation of said function
pointers, or can it be safely ignored when lowering loads, stores, and
bitcasts involving such pointers?

Also, I cannot build the test suite: the option "-disable-llvm-optzns"
passed to llvm-gcc produces several warnings (cc1 seems to think every
letter after 'd' is an individual option), and the option "-m32"
passed to llvm-gcc produces an "unknown command line argument" error
from "cc1".  I have been using llvm-gcc extensively to build my own
front-end project, and have not had a problem with it.  I am reluctant
to make further changes to the source without being able to run the
test suite and satisfy myself that I have not broken something.  I am
running version 4.2.1 of llvm-gcc from the 2.5 release... should I
take a later development snapshot of llvm-gcc?

On Wed, Sep 16, 2009 at 12:55 PM, Dan Gohman <gohman at apple.com> wrote:
>
> On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote:
>
>>> I recently made a major reorganization of the calling-convention
>>> lowering code which cleared away one of the major obstacles to
>>> doing this within codegen.
>>>
>>> Dan
>>
>> So what was the obstacle, and how was it cleared?
>
> The biggest obstacle is that there used to be two different methods
> for lowering call arguments; some of the targets used on and some
> used another. There wasn't a good reason for having two, but no one
> had taken the time to update all the targets. Now, all targets are
> using the same basic set of hooks. And, the hooks are more
> straight-forward than the mechanisms they replaced.
>
>> ?And how do you see
>> the large struct return working in codegen?
>
> One part of the action will be in
> lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp. This is where LLVM IR
> is translated into the special-purpose instruction-selection IR, which
> is lower-level. Calls are split up into multiple parts which are
> eventually lowered into the actual instructions for the calling
> sequence. The main areas of attention will be
>
> SelectionDAGISel::LowerArguments
> SelectionDAGLowering::LowerCallTo
> SelectionDAGLowering::visitRet
>
> These functions are responsible for breaking up LLVM IR values into
> register-sized pieces and handing them off to target-specific code
> through these virtual functions:
>
> TLI.LowerFormalArguments
> TLI.LowerCall
> TLI.LowerReturn
>
> (Actually, SelectionDAGLowering::LowerCallTo calls
> TargetLowering::LowerCallTo, which calls TargetLowering::LowerCall,
> for historical reasons.)
>
> Basically, the task here is to interpose code which will recognize
> when an automatic sret is needed, set up a static alloca to hold the
> value (see the StaticAllocaMap), and adjust the argument list and
> return code accordingly.
>
> For recognizing when an sret is needed, it'll be necessary to know
> what the target supports. This is described in the targets'
> *CallingConv.td files. Currently the consumer of this information
> is the CallingConvLowering code in
>
> include/llvm/CodeGen/CallingConvLower.h
> lib/CodeGen/SelectionDAG/CallingConvLower.cpp
>
> This code is currently used from within the target-specific code
> inside LowerFormalArguments and friends. However, it could also
> be called from the SelectionDAGBuild directly to determine
> if there are sufficient registers. It'll need to be extended
> some, because it calls llvm_unreachable() when it runs
> out of registers, which is the behavior we're trying to avoid
> here :-).
>
> If you're not familiar with the SelectionDAG IR, feel free to
> ask questions. I recommend using the -view-dag-combine1-dags
> option, which provides a visualization of the SelectionDAG for
> each basic block immediately after it has been constructed, to
> get an idea of what's being built.
>
>>
>> Anything you care to tell me would be welcome. ?I will be starting on
>> this today or tomorrow.
>
> Ok, let me know if I can answer any questions.
>
> Dan
>
>


From echristo at apple.com  Sun Sep 20 14:47:05 2009
From: echristo at apple.com (Eric Christopher)
Date: Sun, 20 Sep 2009 12:47:05 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <6a8523d60909180038n751086c1u45bd6c8b2780bb95@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160437w2957b5eel201df618d7ec01d3@mail.gmail.com>
	<d9b9d95f0909160540j7dde955cocfee4c44a30aefe5@mail.gmail.com>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
	<6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
	<1C4F63F7-2A63-40B3-AFC6-813D12676FEB@apple.com>
	<6a8523d60909180038n751086c1u45bd6c8b2780bb95@mail.gmail.com>
Message-ID: <8417C555-383B-4CBB-9E08-D324C7E26D1D@apple.com>

>>
>> I've always used O1 for a quick cleanup so that my debug code doesn't
>> completely suck, but hasn't been optimized into oblivion for gdb.   
>> Also
>> makes looking at the resultant assembly dumps fairly easy.
>
> If this is from the compiler programmer perspective, we have better
> tools for that. If this is from the user perspective, currently they
> all are bad with LLVM for the former, and we should similarly fix all
> of them. :)
>

Well, it's mostly for both :)

>> But yes, that'd be crazy :)
>
> Was that a -1 on doing it, though? :)

Don't see much of a reason to be incompatible with gcc on this one.  
Maybe a new set of command line options for optimization? But what do  
I know?

*shrug* I've always hated dealing with command line options :)

-eric


From daniel at zuster.org  Sun Sep 20 16:44:49 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sun, 20 Sep 2009 14:44:49 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <8417C555-383B-4CBB-9E08-D324C7E26D1D@apple.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
	<6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
	<1C4F63F7-2A63-40B3-AFC6-813D12676FEB@apple.com>
	<6a8523d60909180038n751086c1u45bd6c8b2780bb95@mail.gmail.com>
	<8417C555-383B-4CBB-9E08-D324C7E26D1D@apple.com>
Message-ID: <6a8523d60909201444v1bb13583gf9ced4744c71e45@mail.gmail.com>

On Sun, Sep 20, 2009 at 12:47 PM, Eric Christopher <echristo at apple.com> wrote:
>>>
>>> I've always used O1 for a quick cleanup so that my debug code doesn't
>>> completely suck, but hasn't been optimized into oblivion for gdb. ?Also
>>> makes looking at the resultant assembly dumps fairly easy.
>>
>> If this is from the compiler programmer perspective, we have better
>> tools for that. If this is from the user perspective, currently they
>> all are bad with LLVM for the former, and we should similarly fix all
>> of them. :)
>>
>
> Well, it's mostly for both :)
>
>>> But yes, that'd be crazy :)
>>
>> Was that a -1 on doing it, though? :)
>
> Don't see much of a reason to be incompatible with gcc on this one.

Note that this comment doesn't really make sense. The set of
optimizations which runs for -O1 and -Os aren't at all "gcc
compatible", changing the list of what runs at -O1 doesn't make
llvm-gcc/clang any more or less "compatible". Given that we are free
to change the passes that run at -O1, I'm just suggesting we change it
enough that it coincides with -Os. :)

 - Daniel

> Maybe a
> new set of command line options for optimization? But what do I know?
>
> *shrug* I've always hated dealing with command line options :)
>
> -eric
>
>


From echristo at apple.com  Sun Sep 20 17:11:29 2009
From: echristo at apple.com (Eric Christopher)
Date: Sun, 20 Sep 2009 15:11:29 -0700
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
In-Reply-To: <6a8523d60909201444v1bb13583gf9ced4744c71e45@mail.gmail.com>
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
	<6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
	<1C4F63F7-2A63-40B3-AFC6-813D12676FEB@apple.com>
	<6a8523d60909180038n751086c1u45bd6c8b2780bb95@mail.gmail.com>
	<8417C555-383B-4CBB-9E08-D324C7E26D1D@apple.com>
	<6a8523d60909201444v1bb13583gf9ced4744c71e45@mail.gmail.com>
Message-ID: <F55CB371-4784-4C29-84AB-FF3CB5E18F49@apple.com>

>>
>> Don't see much of a reason to be incompatible with gcc on this one.
>
> Note that this comment doesn't really make sense. The set of
> optimizations which runs for -O1 and -Os aren't at all "gcc
> compatible", changing the list of what runs at -O1 doesn't make
> llvm-gcc/clang any more or less "compatible". Given that we are free
> to change the passes that run at -O1, I'm just suggesting we change it
> enough that it coincides with -Os. :)

Ha. It's a philosophical change. I'd still say that our O1 mostly  
matches with the idea of "compiling for speed without taking too much  
time" instead of "compiling for size".

That said, I'm not really against the idea in general, just that an  
incompatibility would be confusing for those accustomed to the other  
way. Why I thought that a new set of options would probably be best  
for this sort of thing.

-eric


From ofv at wanadoo.es  Sun Sep 20 17:41:23 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Mon, 21 Sep 2009 00:41:23 +0200
Subject: [LLVMdev] FYI: Phoronix GCC vs. LLVM-GCC benchmarks
References: <h8l5cj$tqd$1@ger.gmane.org>
	<549cee610909160605q706463e0td70d21fcb9cd1b3e@mail.gmail.com>
	<h8qq7d$scp$1@ger.gmane.org>
	<06C47A81-9F9C-49A2-93CB-8DBD3CEB2DD3@apple.com>
	<4AB11AE8.4020701@gmail.com>
	<F1FA003E-576F-44FF-AE9B-87B9B87730AD@apple.com>
	<6a8523d60909161036n75c05845yaf43e01b1b14303@mail.gmail.com>
	<1C4F63F7-2A63-40B3-AFC6-813D12676FEB@apple.com>
	<6a8523d60909180038n751086c1u45bd6c8b2780bb95@mail.gmail.com>
	<8417C555-383B-4CBB-9E08-D324C7E26D1D@apple.com>
	<6a8523d60909201444v1bb13583gf9ced4744c71e45@mail.gmail.com>
Message-ID: <87k4ztme7g.fsf@telefonica.net>

Daniel Dunbar <daniel at zuster.org> writes:

[snip]
> Given that we are free
> to change the passes that run at -O1, I'm just suggesting we change it
> enough that it coincides with -Os. :)

Why throw away one option making it a synonym for something else? If the
user wants -Os he already has it.

-O1 is interesting for "fast debuggable code" or, as Eric says, "fast
code, quickly made."

-- 
?scar


From howarth at bromo.med.uc.edu  Sun Sep 20 18:22:42 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Sun, 20 Sep 2009 19:22:42 -0400
Subject: [LLVMdev] OT: intel darwin losing primary target status
In-Reply-To: <A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>
References: <20090918151645.GA9655@bromo.med.uc.edu>
	<08BE7477-6E91-4369-8EE9-9C6C7AB8046D@apple.com>
	<20090918164752.GB10212@bromo.med.uc.edu>
	<45BF4D3D-646E-47A8-AE24-F0E6B6211EF7@apple.com>
	<20090918174331.GA10727@bromo.med.uc.edu>
	<86470E4A-4FB9-4878-B0F9-ACC5B5945B57@apple.com>
	<20090918184012.GA11168@bromo.med.uc.edu>
	<4966267E-8EB7-4A61-BF0B-9FAB55A617E0@apple.com>
	<A92EC2CB-5202-47DE-8BA9-28BE460B41E9@apple.com>
Message-ID: <20090920232242.GA20838@bromo.med.uc.edu>

On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:
> I thought of another work around.  The FSF gcc driver can implicitly  
> add -no_compact_unwind to the link line.  This tells the linker to not  
> produce compact unwind information from the dwarf unwind info in .o  
> files.  Then at runtime the darwin unwinder will fallback and use the  
> slow dwarf unwind info.
> 
> -Nick
> 

Nick,
   The second approach of passing -no_compact_unwind produced excellent
results...

http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01761.html

...eliminating all of the eh regressions in gcc trunk as well as a 
few failures in the libjava testsuite present since gcc 4.4. I've
submitted this change for gcc 4.5...

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01327.html

Hopefully FSF won't break backward compatibility with the non-compact
unwind any time soon. 
        Jack
ps How does the llvm project intend to handle this issue on the linux
side for llvm-gcc-4.2 and clang? Eventually the libgcc used by the
llvm projects and FSF gcc will fork irreversibly, no? I guess one would
have to resort to a llvm compiler-plugin for FSF gcc and not attempt
to mix code with clang/llvm-gcc-4.2 in that case.

From max.stonebraker at gmail.com  Sun Sep 20 22:56:48 2009
From: max.stonebraker at gmail.com (Max Stonebraker)
Date: Sun, 20 Sep 2009 20:56:48 -0700
Subject: [LLVMdev] disable insertion of unreachables
In-Reply-To: <f5aa3e9b0909082230q487f5312p82e362c9602d6bed@mail.gmail.com>
References: <808cbd330909061449w4abe76a6kce710bd1bb9deeb3@mail.gmail.com>
	<400d33ea0909061455l6837b7b7j6768454214f3f4a5@mail.gmail.com>
	<808cbd330909082216g3095f645q9282d07693f11c1d@mail.gmail.com>
	<f5aa3e9b0909082230q487f5312p82e362c9602d6bed@mail.gmail.com>
Message-ID: <808cbd330909202056p7d8a6823u24f4eb51e1b90cb0@mail.gmail.com>

> If there's sensible control flow after a function returns, don't mark
> it or calls to it noreturn.

How do I prevent llvm-gcc from labelling a particular function with the
noreturn attribute so an unreachable is not inserted after a call to it?
Does llvm-gcc keep a list of functions somewhere that it thinks do not
return?

Max

On Tue, Sep 8, 2009 at 10:30 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Tue, Sep 8, 2009 at 10:16 PM, Max
> Stonebraker<max.stonebraker at gmail.com> wrote:
> > Is there any way to avoid having the unreachables inserted in the first
> > place?
>
> If there's sensible control flow after a function returns, don't mark
> it or calls to it noreturn.  If in fact cannot return, the concept of
> control flow after the function returns fundamentally makes no sense.
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090920/27d91b74/attachment.html 

From eli.friedman at gmail.com  Sun Sep 20 23:22:44 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sun, 20 Sep 2009 21:22:44 -0700
Subject: [LLVMdev] disable insertion of unreachables
In-Reply-To: <808cbd330909202056p7d8a6823u24f4eb51e1b90cb0@mail.gmail.com>
References: <808cbd330909061449w4abe76a6kce710bd1bb9deeb3@mail.gmail.com>
	<400d33ea0909061455l6837b7b7j6768454214f3f4a5@mail.gmail.com>
	<808cbd330909082216g3095f645q9282d07693f11c1d@mail.gmail.com>
	<f5aa3e9b0909082230q487f5312p82e362c9602d6bed@mail.gmail.com>
	<808cbd330909202056p7d8a6823u24f4eb51e1b90cb0@mail.gmail.com>
Message-ID: <f5aa3e9b0909202122r1d99b8f7wb8cee3c98ad68d49@mail.gmail.com>

On Sun, Sep 20, 2009 at 8:56 PM, Max Stonebraker
<max.stonebraker at gmail.com> wrote:
>> If there's sensible control flow after a function returns, don't mark
>> it or calls to it noreturn.
>
> How do I prevent llvm-gcc from labelling a particular function with the
> noreturn attribute so an unreachable is not inserted after a call to it?
> Does llvm-gcc keep a list of functions somewhere that it thinks do not
> return?

llvm-gcc knows all the C library functions that are noreturn.  Control
flow after one of those doesn't make sense; if you really want
llvm-gcc to avoid making assumptions about them, use -fno-builtin.

llvm-gcc can also tell if a function is noreturn if the implementation
of the function is in the same file; in that case, there's no easy way
to prevent the functions from getting appropriately marked.

llvm-gcc also marks functions marked with __attribute__((noreturn)) as
noreturn; the solution there is simply not to mark the relevant
functions.

-Eli

From alexbenington at gmail.com  Mon Sep 21 01:05:11 2009
From: alexbenington at gmail.com (Alexia Benington)
Date: Mon, 21 Sep 2009 02:05:11 -0400
Subject: [LLVMdev] Error when building tutorial example
Message-ID: <7969168f0909202305rc82f6bcpac2e9ef439745ba3@mail.gmail.com>

Hi all,

I'm a new user to LLVM. Not really sure if this is the correct place
to post, since there isn't really any other forums around. Anyway, the
issue I'm encountering is that, I was trying out the first tutorial
(http://llvm.org/docs/tutorial/JITTutorial1.html). I attempted to do
this in another folder that was copied from llvm/projects/sample. I
created a new folder called "tut1" in sample/tools/ folder, and the
following Makefile.

LEVEL=../..
TOOLNAME=tut1
LINK_COMPONENTS += --cxxflags
LINK_COMPONENTS += --ldflags
LINK_COMPONENTS += --libs
LINK_COMPONENTS += core
LINK_COMPONENTS += engine
include $(LEVEL)/Makefile.common

However, I'm getting the following error on gmake.
gmake[2]: *** No rule to make target `-I/usr/src/llvm/include', needed
by `/sample/Release/bin/tut1'.  Stop.

I can get it to compile with the following command. But I want to make
sure I understand how the Makefiles integrate together.
g++ tut1.cpp `llvm-config --cxxflags --ldflags --libs core engine`

Really appreciate your help. Thank you.

-alex

From ofv at wanadoo.es  Mon Sep 21 01:32:28 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Mon, 21 Sep 2009 08:32:28 +0200
Subject: [LLVMdev] Error when building tutorial example
References: <7969168f0909202305rc82f6bcpac2e9ef439745ba3@mail.gmail.com>
Message-ID: <87fxagn6yr.fsf@telefonica.net>

Alexia Benington <alexbenington at gmail.com> writes:

> Hi all,
>
> I'm a new user to LLVM. Not really sure if this is the correct place
> to post, since there isn't really any other forums around. Anyway, the
> issue I'm encountering is that, I was trying out the first tutorial
> (http://llvm.org/docs/tutorial/JITTutorial1.html). I attempted to do
> this in another folder that was copied from llvm/projects/sample. I
> created a new folder called "tut1" in sample/tools/ folder, and the
> following Makefile.
>
> LEVEL=../..
> TOOLNAME=tut1
> LINK_COMPONENTS += --cxxflags
> LINK_COMPONENTS += --ldflags
> LINK_COMPONENTS += --libs

Remove the previous three LINK_COMPONENTS lines. LINK_COMPONENTS is for
names of LLVM components (roughly equivalent to libraries) that should
be linked to your project. It is equivalent to the names you put after
--libs on your invocation of llvm-config below.

> LINK_COMPONENTS += core
> LINK_COMPONENTS += engine

you can fuse the previous two lines on a single one:

LINK_COMPONENTS += core engine

> include $(LEVEL)/Makefile.common
>
> However, I'm getting the following error on gmake.
> gmake[2]: *** No rule to make target `-I/usr/src/llvm/include', needed
> by `/sample/Release/bin/tut1'.  Stop.
>
> I can get it to compile with the following command. But I want to make
> sure I understand how the Makefiles integrate together.
> g++ tut1.cpp `llvm-config --cxxflags --ldflags --libs core engine`
>
> Really appreciate your help. Thank you.

-- 
?scar


From evan.cheng at apple.com  Mon Sep 21 01:47:46 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Sun, 20 Sep 2009 23:47:46 -0700
Subject: [LLVMdev] Native Assembler for ARM
In-Reply-To: <f88b89a50909191148l160b42a4m9930e7a5f25808d5@mail.gmail.com>
References: <D7663D09-3022-412D-AADD-4CEA0127CDFF@comcast.net>
	<f88b89a50909191148l160b42a4m9930e7a5f25808d5@mail.gmail.com>
Message-ID: <92F36459-3B49-4AB7-80AC-36B11EB6C79F@apple.com>

If you want Darwin arm assembler, then you need to register and  
download the iphone sdk.

Evan

On Sep 19, 2009, at 11:48 AM, Misha Brukman wrote:

> On Sat, Sep 19, 2009 at 2:37 PM, Wayne Anderson  
> <wanderon at comcast.net> wrote:
> I hope I'm not missing something obvious.  I'm trying to get a native
> binary for ARM from a .s file.  If I try to run "as -arch arm
> myFile.s" I get an error message indicating that no installed
> assembler exists for arm.
>
> as: assembler (/usr/bin/../libexec/gcc/darwin/arm/as or /usr/bin/../
> local/libexec/gcc/darwin/arm/as) for architecture arm not installed
> Installed assemblers are:
> /usr/bin/../libexec/gcc/darwin/ppc64/as for architecture ppc64
> /usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
> /usr/bin/../libexec/gcc/darwin/ppc/as for architecture ppc
> /usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
>
> Can anyone point me to where can I get the ARM assembler.  Or should
> I  be using something else.
>
> You're trying to cross-compile, so you'll need to either download or  
> build a cross-assembler (from binutils).
> _______________________________________________
> 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/20090920/23e255f0/attachment.html 

From Sanjiv.Gupta at microchip.com  Mon Sep 21 01:57:21 2009
From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com)
Date: Sun, 20 Sep 2009 23:57:21 -0700
Subject: [LLVMdev] ld with gold-plugin can do this?
References: <1253409209.6504.39.camel@UIUC> <4AB5842B.2040702@mxc.ca>
Message-ID: <F536B7C316F9474E9F7091239725AC9A02FA7F7A@CHN-CL-MAIL01.mchp-main.com>

A common followup question is "but how do I link native libraries into 
my .bc file". You don't. A .bc file is llvm ir, you can't put a native 
binary library into a .bc (barring sticking it in as a string, etc).

The build then looks like:

a) 'llvm-gcc -c -flo -O2' to generate the .bc files.
b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a .a.
c) 'llc' to turn your combined .bc into a .s
d) 'as' to turn your .s into a .o
e) 'ld' to turn your .o into a .so or final executable. This is the step 
where you get to specify all the native libraries to link with.

You can use 'gcc' to merge steps d and e (it just runs as and ld for 
you). Or you can use the gold plugin to merge steps b through e, but 
with the added benefit that it will optimize slightly better. See the 
llvm LTO documentation on why.

[Sanjiv] - This is what PIC16 does. llvm-ld has an option called '-b' that you can
use to specify the output bitcode file name. Unfortunately, llvm-ld always tries to
generate a native executable (or a shell script) as well and currently there is no way to disable that.
Maybe an option like '-no-native' will be come handy.


- Sanjiv

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

From nicholas at mxc.ca  Mon Sep 21 02:06:04 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 21 Sep 2009 00:06:04 -0700
Subject: [LLVMdev] ld with gold-plugin can do this?
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A02FA7F7A@CHN-CL-MAIL01.mchp-main.com>
References: <1253409209.6504.39.camel@UIUC> <4AB5842B.2040702@mxc.ca>
	<F536B7C316F9474E9F7091239725AC9A02FA7F7A@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <4AB725DC.5020805@mxc.ca>

Sanjiv.Gupta at microchip.com wrote:
> 
> 
> A common followup question is "but how do I link native libraries into
> my .bc file". You don't. A .bc file is llvm ir, you can't put a native
> binary library into a .bc (barring sticking it in as a string, etc).
> 
> The build then looks like:
> 
> a) 'llvm-gcc -c -flo -O2' to generate the .bc files.
> b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a .a.
> c) 'llc' to turn your combined .bc into a .s
> d) 'as' to turn your .s into a .o
> e) 'ld' to turn your .o into a .so or final executable. This is the step
> where you get to specify all the native libraries to link with.
> 
> You can use 'gcc' to merge steps d and e (it just runs as and ld for
> you). Or you can use the gold plugin to merge steps b through e, but
> with the added benefit that it will optimize slightly better. See the
> llvm LTO documentation on why.
> 
> [Sanjiv] - This is what PIC16 does. llvm-ld has an option called '-b' 
> that you can
> use to specify the output bitcode file name. Unfortunately, llvm-ld 
> always tries to
> generate a native executable (or a shell script) as well and currently 
> there is no way to disable that.
> Maybe an option like '-no-native' will be come handy.

Yes there is, it's -link-as-library.

Nick

From idadesub at users.sourceforge.net  Mon Sep 21 04:43:20 2009
From: idadesub at users.sourceforge.net (Erick Tryzelaar)
Date: Mon, 21 Sep 2009 02:43:20 -0700
Subject: [LLVMdev] Error when building tutorial example
In-Reply-To: <7969168f0909202305rc82f6bcpac2e9ef439745ba3@mail.gmail.com>
References: <7969168f0909202305rc82f6bcpac2e9ef439745ba3@mail.gmail.com>
Message-ID: <1ef034530909210243q39505126u102aaa0e07cd4ad9@mail.gmail.com>

On Sun, Sep 20, 2009 at 11:05 PM, Alexia Benington
<alexbenington at gmail.com> wrote:
> Hi all,
>
> I can get it to compile with the following command. But I want to make
> sure I understand how the Makefiles integrate together.
> g++ tut1.cpp `llvm-config --cxxflags --ldflags --libs core engine`
>
> Really appreciate your help. Thank you.

I've been sitting on a patch that adds all the kaleidoscope tests to
the llvm tree, instead of just chapter 7. I'll look into pushing it
out tomorrow.

From howarth at bromo.med.uc.edu  Mon Sep 21 08:16:53 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Mon, 21 Sep 2009 09:16:53 -0400
Subject: [LLVMdev] OT: gdb and procmod on darwin9.8/darwin10
Message-ID: <20090921131653.GA30154@bromo.med.uc.edu>

   The gdb developers are rapidly approaching the
release of gdb 7.0 (which will be required to debug
optimized code generated by gcc 4.5 due changes 
related to the var tracking association merge and
other code). They currently have patches proposed
that allows gdb 7.0 to debug code in darwin9.6.
However there was some change made in darwin9.8
and darwin10 which no longer allows the previous
approach of making gdb belong to the procmod group...

sudo chgrp procmod gdb
sudo chmod g+s gdb

Under darwin9.6 and darwin10 (but not darwin9.5),
this results in the error...

(gdb) break 4
Breakpoint 1 at 0x10000154c: file himenoBMTxpa.c, line 4.
(gdb) r
Starting program: /Users/howarth/a.out 
Unable to find Mach task port for process-id 154: (os/kern) failure (0x5).
 (please check gdb is setgid procmod)
(gdb) 

Can someone at Apple provide the gdb developers with some
advice on what is the new approach recommnded for gdb to have
proper permissions and group ownership to function under darwin9.5.8
and darwin10? The messages discussing this issue are 
archived at...

http://sourceware.org/ml/gdb/2009-09/msg00239.html
http://sourceware.org/ml/gdb/2009-09/msg00240.html
http://sourceware.org/ml/gdb/2009-09/msg00241.html
http://sourceware.org/ml/gdb/2009-09/msg00242.html
http://sourceware.org/ml/gdb/2009-09/msg00243.html
http://sourceware.org/ml/gdb/2009-09/msg00245.html
http://sourceware.org/ml/gdb/2009-09/msg00246.html
http://sourceware.org/ml/gdb/2009-09/msg00247.html
http://sourceware.org/ml/gdb/2009-09/msg00248.html
http://sourceware.org/ml/gdb/2009-09/msg00249.html
http://sourceware.org/ml/gdb/2009-09/msg00250.html
http://sourceware.org/ml/gdb/2009-09/msg00252.html

Thanks for any authoritative answer on the correct
approach to solving this problem.
                   Jack
ps This does also indirectly effect the llvm project
on darwin (if any one wants to use FSF gdb 7.0).

From anton at korobeynikov.info  Mon Sep 21 08:31:20 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 21 Sep 2009 17:31:20 +0400
Subject: [LLVMdev] Global register variables/custom calling conventions
In-Reply-To: <4AB5EF70.20209@aj.id.au>
References: <4AB589BC.1070702@aj.id.au>
	<b087fca00909192345k6b727fcdtf79a28599e5796ae@mail.gmail.com>
	<4AB5EF70.20209@aj.id.au>
Message-ID: <b087fca00909210631m6a51bf57vf20ad6f35c95b3f6@mail.gmail.com>

Hello

> Again, from what I understand, llvm-qemu worked by emitting LLVM IR from
> QEMU IR API calls. This project goes straight from ARM to LLVM IR, bypassing
> QEMU's IR, (partially) in the hope that more information about the original
> intent of the code is retained.
Ok, what's left from QEMU then? :)

> generating reasonable code - this approach keeps it in place while we do
> extra, possibly more expensive work out of sight. It might not be a pretty
> idea, but LLVM does generate some very tight code :) It's an experiment -
> humour me...
Well, but I still don't get the reason why you need to pin (some)
internal QEMU state variables to fixed registers?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From ssen at apple.com  Mon Sep 21 10:42:18 2009
From: ssen at apple.com (Shantonu Sen)
Date: Mon, 21 Sep 2009 08:42:18 -0700
Subject: [LLVMdev] Native Assembler for ARM
In-Reply-To: <92F36459-3B49-4AB7-80AC-36B11EB6C79F@apple.com>
References: <D7663D09-3022-412D-AADD-4CEA0127CDFF@comcast.net>
	<f88b89a50909191148l160b42a4m9930e7a5f25808d5@mail.gmail.com>
	<92F36459-3B49-4AB7-80AC-36B11EB6C79F@apple.com>
Message-ID: <4C024C3F-1A69-45AB-ACB3-3F89454CC710@apple.com>

You can also download and build odcctools, which is a port of Mac OS  
X's low level toolchain to be more OS independent, and build reliably

<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-August/006012.html>

Shantonu Sen
ssen at apple.com

Sent from my Mac Pro

On Sep 20, 2009, at 11:47 PM, Evan Cheng wrote:

> If you want Darwin arm assembler, then you need to register and  
> download the iphone sdk.
>
> Evan
>
> On Sep 19, 2009, at 11:48 AM, Misha Brukman wrote:
>
>> On Sat, Sep 19, 2009 at 2:37 PM, Wayne Anderson  
>> <wanderon at comcast.net> wrote:
>> I hope I'm not missing something obvious.  I'm trying to get a native
>> binary for ARM from a .s file.  If I try to run "as -arch arm
>> myFile.s" I get an error message indicating that no installed
>> assembler exists for arm.
>>
>> as: assembler (/usr/bin/../libexec/gcc/darwin/arm/as or /usr/bin/../
>> local/libexec/gcc/darwin/arm/as) for architecture arm not installed
>> Installed assemblers are:
>> /usr/bin/../libexec/gcc/darwin/ppc64/as for architecture ppc64
>> /usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
>> /usr/bin/../libexec/gcc/darwin/ppc/as for architecture ppc
>> /usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
>>
>> Can anyone point me to where can I get the ARM assembler.  Or should
>> I  be using something else.
>>
>> You're trying to cross-compile, so you'll need to either download  
>> or build a cross-assembler (from binutils).
>> _______________________________________________
>> 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

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

From clattner at apple.com  Mon Sep 21 12:08:34 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 21 Sep 2009 10:08:34 -0700
Subject: [LLVMdev] OT: gdb and procmod on darwin9.8/darwin10
In-Reply-To: <20090921131653.GA30154@bromo.med.uc.edu>
References: <20090921131653.GA30154@bromo.med.uc.edu>
Message-ID: <85CB2502-0ABE-4617-9CF5-C5B3E42F8DA3@apple.com>


On Sep 21, 2009, at 6:16 AM, Jack Howarth wrote:

>   The gdb developers are rapidly approaching the
> release of gdb 7.0 (which will be required to debug

Hi Jack,

I know you're trying to help improve tools for Darwin, but llvm-dev is  
not really an appropriate place for it.  Please stick to LLVM related  
topics on this list where possible.

-Chris

From howarth at bromo.med.uc.edu  Mon Sep 21 12:23:15 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Mon, 21 Sep 2009 13:23:15 -0400
Subject: [LLVMdev] OT: gdb and procmod on darwin9.8/darwin10
In-Reply-To: <85CB2502-0ABE-4617-9CF5-C5B3E42F8DA3@apple.com>
References: <20090921131653.GA30154@bromo.med.uc.edu>
	<85CB2502-0ABE-4617-9CF5-C5B3E42F8DA3@apple.com>
Message-ID: <20090921172315.GB1372@bromo.med.uc.edu>

On Mon, Sep 21, 2009 at 10:08:34AM -0700, Chris Lattner wrote:
>
> On Sep 21, 2009, at 6:16 AM, Jack Howarth wrote:
>
>>   The gdb developers are rapidly approaching the
>> release of gdb 7.0 (which will be required to debug
>
> Hi Jack,
>
> I know you're trying to help improve tools for Darwin, but llvm-dev is  
> not really an appropriate place for it.  Please stick to LLVM related  
> topics on this list where possible.
>
> -Chris

Where are we most likely to find the Apple gdb developers? We are
very close to the gdb 7.0 release and I wanted to find the most
likely place that they would view the request.
               Jack

From clattner at apple.com  Mon Sep 21 12:27:14 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 21 Sep 2009 10:27:14 -0700
Subject: [LLVMdev] OT: gdb and procmod on darwin9.8/darwin10
In-Reply-To: <20090921172315.GB1372@bromo.med.uc.edu>
References: <20090921131653.GA30154@bromo.med.uc.edu>
	<85CB2502-0ABE-4617-9CF5-C5B3E42F8DA3@apple.com>
	<20090921172315.GB1372@bromo.med.uc.edu>
Message-ID: <CA641193-145F-4B6A-B16A-C5A3693F66FC@apple.com>


On Sep 21, 2009, at 10:23 AM, Jack Howarth wrote:

> On Mon, Sep 21, 2009 at 10:08:34AM -0700, Chris Lattner wrote:
>>
>> On Sep 21, 2009, at 6:16 AM, Jack Howarth wrote:
>>
>>>  The gdb developers are rapidly approaching the
>>> release of gdb 7.0 (which will be required to debug
>>
>> Hi Jack,
>>
>> I know you're trying to help improve tools for Darwin, but llvm-dev  
>> is
>> not really an appropriate place for it.  Please stick to LLVM related
>> topics on this list where possible.
>>
>> -Chris
>
> Where are we most likely to find the Apple gdb developers? We are
> very close to the gdb 7.0 release and I wanted to find the most
> likely place that they would view the request.

I don't know Jack, but llvmdev isn't a good place to look for them.   
If you'd like to continue this thread, please do so off-list.  Again,  
I know you're trying to help, but unfortunately this is just not the  
right place for random darwin questions.  You'd probably have more  
luck on one of the public apple xcode development lists.

-Chris

From gohman at apple.com  Mon Sep 21 12:50:03 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 21 Sep 2009 10:50:03 -0700
Subject: [LLVMdev] struct returns
In-Reply-To: <400d33ea0909201136y44fc37eenf5fb097adb680299@mail.gmail.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
	<FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
	<400d33ea0909160558kd7fd636m12a63ee2bcbcc752@mail.gmail.com>
	<01C8409B-A919-48F4-BEA6-6C9CA25B49DD@apple.com>
	<400d33ea0909201136y44fc37eenf5fb097adb680299@mail.gmail.com>
Message-ID: <B9070616-6238-4E15-B877-8990C526B421@apple.com>


On Sep 20, 2009, at 11:36 AM, Kenneth Uildriks wrote:

> I wish to assure you that I have not forgotten this task, nor failed
> to start on it, but I cannot give even a rough estimate on when it
> will be completed.

Ok, that's fine. Thanks for keeping me up to date.

> It occurs to me that all declarations of a function pointer, and all
> bitcasts to a function pointer, could possibly refer to a function
> whose signature must be altered by this fix.  Is the function
> signature relevant to the SelectionDAG representation of said function
> pointers, or can it be safely ignored when lowering loads, stores, and
> bitcasts involving such pointers?

No. Fortunately, you don't have to worry about complicated bitcast
situations here. There are only two constructs which are affected:
function definitions and function calls. And in the case of calls,
the only thing that matters is the type of the call operand itself,
not what the operand might have been bitcasted from.

LLVM can't always see what the operand may have been bitcasted from,
so it just has to trust the user. If the dynamic callee's type doesn't
match the static operand type on the call, it's undefined behavior.

> Also, I cannot build the test suite: the option "-disable-llvm-optzns"
> passed to llvm-gcc produces several warnings (cc1 seems to think every
> letter after 'd' is an individual option), and the option "-m32"
> passed to llvm-gcc produces an "unknown command line argument" error
> from "cc1".  I have been using llvm-gcc extensively to build my own
> front-end project, and have not had a problem with it.  I am reluctant
> to make further changes to the source without being able to run the
> test suite and satisfy myself that I have not broken something.  I am
> running version 4.2.1 of llvm-gcc from the 2.5 release... should I
> take a later development snapshot of llvm-gcc?

The -disable-llvm-optzns is preceded by a -mllvm, but it's likely
that that didn't work in 2.5 llvm-gcc. If you don't want to live on
the latest snapshot, the 2.6 pre-release (and the 2.6 release, once
it exists) should work here. As a temporary workaround, you might
also be able to replace "-mllvm -disable-llvm-optzns" with "-O0",
which isn't exactly the same, but basically works.

I'm not as familiar with what might be going on with -m32 option.
What host are you on, and what targets is your llvm-gcc configured
for? Does it include 64-bit support? It may be that an llvm-gcc
configured for 32-bit only doesn't recognize -m32. I'm not sure
what to suggest there. Perhaps the Makefile needs to be smarter.

Dan


From kennethuil at gmail.com  Mon Sep 21 13:12:37 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Mon, 21 Sep 2009 13:12:37 -0500
Subject: [LLVMdev] struct returns
In-Reply-To: <B9070616-6238-4E15-B877-8990C526B421@apple.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
	<FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
	<400d33ea0909160558kd7fd636m12a63ee2bcbcc752@mail.gmail.com>
	<01C8409B-A919-48F4-BEA6-6C9CA25B49DD@apple.com>
	<400d33ea0909201136y44fc37eenf5fb097adb680299@mail.gmail.com>
	<B9070616-6238-4E15-B877-8990C526B421@apple.com>
Message-ID: <400d33ea0909211112i128a100fl6c91f280a9dc76d0@mail.gmail.com>

>> It occurs to me that all declarations of a function pointer, and all
>> bitcasts to a function pointer, could possibly refer to a function
>> whose signature must be altered by this fix. ?Is the function
>> signature relevant to the SelectionDAG representation of said function
>> pointers, or can it be safely ignored when lowering loads, stores, and
>> bitcasts involving such pointers?
>
> No. Fortunately, you don't have to worry about complicated bitcast
> situations here. There are only two constructs which are affected:
> function definitions and function calls. And in the case of calls,
> the only thing that matters is the type of the call operand itself,
> not what the operand might have been bitcasted from.

What about the type of the ptr-to-function-ptr that the call operand
was *loaded* from?  This will come up whenever a function pointer is
stored in callback situations.  If I change the call operand, it won't
match the element type of the pointer it was loaded from.  Does this
matter in a SelectionDAG?

>> Also, I cannot build the test suite: the option "-disable-llvm-optzns"
>> passed to llvm-gcc produces several warnings (cc1 seems to think every
>> letter after 'd' is an individual option), and the option "-m32"
>> passed to llvm-gcc produces an "unknown command line argument" error
>> from "cc1". ?I have been using llvm-gcc extensively to build my own
>> front-end project, and have not had a problem with it. ?I am reluctant
>> to make further changes to the source without being able to run the
>> test suite and satisfy myself that I have not broken something. ?I am
>> running version 4.2.1 of llvm-gcc from the 2.5 release... should I
>> take a later development snapshot of llvm-gcc?
>
> The -disable-llvm-optzns is preceded by a -mllvm, but it's likely
> that that didn't work in 2.5 llvm-gcc. If you don't want to live on
> the latest snapshot, the 2.6 pre-release (and the 2.6 release, once
> it exists) should work here. As a temporary workaround, you might
> also be able to replace "-mllvm -disable-llvm-optzns" with "-O0",
> which isn't exactly the same, but basically works.
>
> I'm not as familiar with what might be going on with -m32 option.
> What host are you on, and what targets is your llvm-gcc configured
> for? Does it include 64-bit support? It may be that an llvm-gcc
> configured for 32-bit only doesn't recognize -m32. I'm not sure
> what to suggest there. Perhaps the Makefile needs to be smarter.

I am on linux x86 32 bit... no 64 bit support at all.  llvm-gcc is
configured for C and C++... I didn't add any other languages or
targets onto the defaults for LLVM or llvm-gcc.  I was hoping not to
install another version of llvm-gcc, since it is quite a beast and I
don't want to break the one I already have running.  (Giving it a new
prefix should be safe, right?)  I pretty much have to live on the
snapshot for the folder that I'm working on LLVM code in, so I'll just
have to bite the bullet and make it work.


From gohman at apple.com  Mon Sep 21 13:58:39 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 21 Sep 2009 11:58:39 -0700
Subject: [LLVMdev] struct returns
In-Reply-To: <400d33ea0909211112i128a100fl6c91f280a9dc76d0@mail.gmail.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
	<FE24FF4D-9201-489B-A1F3-9F85D2764537@apple.com>
	<400d33ea0909160558kd7fd636m12a63ee2bcbcc752@mail.gmail.com>
	<01C8409B-A919-48F4-BEA6-6C9CA25B49DD@apple.com>
	<400d33ea0909201136y44fc37eenf5fb097adb680299@mail.gmail.com>
	<B9070616-6238-4E15-B877-8990C526B421@apple.com>
	<400d33ea0909211112i128a100fl6c91f280a9dc76d0@mail.gmail.com>
Message-ID: <92753A14-284A-4D67-924C-123AD4A2F054@apple.com>


On Sep 21, 2009, at 11:12 AM, Kenneth Uildriks wrote:

>>> It occurs to me that all declarations of a function pointer, and all
>>> bitcasts to a function pointer, could possibly refer to a function
>>> whose signature must be altered by this fix.  Is the function
>>> signature relevant to the SelectionDAG representation of said  
>>> function
>>> pointers, or can it be safely ignored when lowering loads, stores,  
>>> and
>>> bitcasts involving such pointers?
>>
>> No. Fortunately, you don't have to worry about complicated bitcast
>> situations here. There are only two constructs which are affected:
>> function definitions and function calls. And in the case of calls,
>> the only thing that matters is the type of the call operand itself,
>> not what the operand might have been bitcasted from.
>
> What about the type of the ptr-to-function-ptr that the call operand
> was *loaded* from?  This will come up whenever a function pointer is
> stored in callback situations.  If I change the call operand, it won't
> match the element type of the pointer it was loaded from.  Does this
> matter in a SelectionDAG?

No, and it doesn't matter in LLVM IR either. It's a front-end's
responsibility to ensure that the (static) type of the call operand
is compatible with the type of all actual callees that it can call
at runtime.

Dan


From aishofpf at gmail.com  Mon Sep 21 15:56:47 2009
From: aishofpf at gmail.com (Alysson)
Date: Mon, 21 Sep 2009 17:56:47 -0300
Subject: [LLVMdev] Removing redundant type checks from Java
Message-ID: <c809d57b0909211356w59f1b91ar80a7a97be279dcb4@mail.gmail.com>

Hi, LLVMers,

    I am a CS student in my final year, and I would like to use LLVM in my
final course project. So, I just download LLVM and VMKit, and I have been
playing with both. I can produce llvm bytecodes from java programs, and now
my idea is to remove redundant type checks from the code. For instance, if
we consider a program like this:

if (o instanceof A) {
  A a = (A) o;
  // do something with a
}

we see that Java will put a type test before the cast, but this test is
unnecessary, as we already know that we have passed the instanceof test. So,
as my project I would like to remove these redundant tests. My questions:

1) Has this already been done by some of the VMKit optimizing passes?
2) If not, is this feasible?
3) Is this the right list to ask questions about VMKit?

All the best,

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

From ssen at apple.com  Mon Sep 21 20:21:22 2009
From: ssen at apple.com (Shantonu Sen)
Date: Mon, 21 Sep 2009 18:21:22 -0700
Subject: [LLVMdev] Status of blocks runtime in compiler-rt?
In-Reply-To: <A1276AA4-105C-4672-937A-A31ED216DE19@apple.com>
References: <94E2D101-57DB-4318-AE15-FF9752FBDDD0@apple.com>
	<521640720909151642w432d5ec0g1afea918c79cea20@mail.gmail.com>
	<A1276AA4-105C-4672-937A-A31ED216DE19@apple.com>
Message-ID: <3F76C812-EF84-48DD-876C-397D191CC67F@apple.com>

Hi Jordan,

I've committed my changes to hook up the BlocksRuntime/ subdirectory  
of compiler-rt, using CMake.

The cmake build process is documented at <http://llvm.org/docs/CMake.html 
 >

More specifically, to use this support on FreeBSD, for example, you  
would do:

1) Install cmake (<http://www.cmake.org/>), add it to your PATH
2) Check out the source code for llvm and clang
3) Build it with cmake, using:
$ mkdir build
$ cd build
$ env CC="cc -march=i686" CXX="c++ -march=i686" cmake - 
DCMAKE_INSTALL_PREFIX=$PREFIX ..
...
$ make
...
$ make install

4) Check out the source code for compiler-rt
5) Build it, optionally with clang, although this isn't strictly  
required. You can use the system gcc too, like in step 3.
$ mkdir build
$ cd build
$ env CC="clang" CXX="c++ -march=i686" cmake -DCMAKE_INSTALL_PREFIX= 
$PREFIX ..
...
$ make
...
$ make install

Simple programs seem to work at that point for me:
$ cat foo.c
#include <stdio.h>
#include <stdlib.h>
#include <Block.h>

int main(int argc, char *argv[]) {

   int x = 123;

   void (^printXAndY)(int) = ^(int y) {
     printf("%d %d\n", x, y);
   };
   void (^copyPrintXAndY)(int) = Block_copy(printXAndY);

   copyPrintXAndY(456); // prints: 123 456
   Block_release(copyPrintXAndY);

   return 0;
}


$ clang -I$PREFIX/include -fblocks -c foo.c
$ clang -L$PREFIX/lib -Wl,-rpath,$PREFIX/lib -o foo foo.o - 
lBlocksRuntime
$ ./foo
123 456
$

I've also tried similar steps on Ubuntu Linux, as well as with llvm- 
gcc-4.2, which also worked.

Shantonu Sen
ssen at apple.com

Sent from my Mac Pro

On Sep 16, 2009, at 8:00 AM, Shantonu Sen wrote:

> The Blocks language and implementation specifications are checked into
> clang/docs.
>
> More generally, on Mac OS X, the blocks runtime is linked into the C
> library ("libSystem"), and available to the entire OS. Clients that
> create blocks may implicitly get compiler-generated calls to some of
> the runtime functions, and the developer may also make explicit calls
> to, e.g., Block_copy().
>
> On other OSes, the library would need to be built and installed
> somewhere. There's also the question of whether it should be a shared
> library or static library. I can see both points, but think that a
> shared library is probably the right way for it.
>
> It should probably be generally portable (it doesn't appear to
> compiler correctly with llvm-gcc and clang on Linux), and install its
> headers (doesn't appear to).
>
> I can spend some time on this, since I have some familiarity with
> libdispatch (Apple's APIs that heavily use Blocks for developer
> convenience).
>
> Shantonu
>
> Sent from my MacBook
>
> On Sep 15, 2009, at 4:42 PM, Edward O'Callaghan wrote:
>
>> Good day,
>>
>> I been working on the CMake build system (which is nice and portable)
>> + code clean ups over the whole Compiler-RT software suit.
>> I recently added Blocks to the CMake build system but there is some
>> ugly looking warnings I need to fix up in the Blocks code which I  
>> have
>> not had time to look into yet.
>> N.B. The CMake build system is not complete yet due to my lack of
>> time, however I am still active, help really welcome !
>>
>> My main goal is to have Compiler-RT as a highly portable runtime that
>> will build and run on AuroraUX, *BSD, Linux and OSX with lint clean
>> code and zero build warnings. Also, I plan to add SPARC support in  
>> the
>> near future if I get time. (As I work on AuroraUX almost full time
>> also.)
>>
>> These are my personal goals working on Compiler-RT.
>>
>> Could you please outline *exactly* what you would like to see happen
>> with Blocks,
>> I don't really know much about Blocks to be fair however I would be
>> interested to hear and at least it would be 'on record' here.
>>
>> Cheers,
>> Edward O'Callaghan.
>>
>> 2009/9/15 Jordan K. Hubbard <jkh at apple.com>:
>>> Hi folks,
>>>
>>> So, various folks are in the process of porting Grand Central
>>> Dispatch
>>> to FreeBSD (c.f. http://libdispatch.macosforge.org and http://lists.macosforge.org/pipermail/libdispatch-dev
>>> for mailing list discussion on the topic) and are making good
>>> progress, but one of the issues they're running into is support for
>>> Blocks in FreeBSD.
>>>
>>> On the one hand, they could try and back-port the gcc changes from http://www.opensource.apple.com/source/gcc/gcc-5646
>>> and solve the problem that way or, on the other hand, they could
>>> just continue FreeBSD's inexorable march towards Clang and get the
>>> blocks support as part of compiler-rt.  The only problem seems to be
>>> that the build support for Blocks in compiler-rt isn't wired up yet,
>>> which came as something of a surprise to all involved given that
>>> people have been talking about Clang and Blocks since this summer.
>>>
>>> Is there a roadmap for this anywhere that we can read?  If this
>>> simply
>>> has not been done due to a lack of resources, the GCD porting folks
>>> could perhaps help move this along, assuming they had appropriate
>>> access to the bits.
>>>
>>> Thanks!
>>>
>>> - Jordan
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>>
>>
>> -- 
>> -- 
>> Edward O'Callaghan
>> http://www.auroraux.org/
>> eocallaghan at auroraux dot org
>>
>> _______________________________________________
>> 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 nicolas.geoffray at lip6.fr  Tue Sep 22 00:49:02 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Tue, 22 Sep 2009 07:49:02 +0200
Subject: [LLVMdev] Removing redundant type checks from Java
In-Reply-To: <c809d57b0909211356w59f1b91ar80a7a97be279dcb4@mail.gmail.com>
References: <c809d57b0909211356w59f1b91ar80a7a97be279dcb4@mail.gmail.com>
Message-ID: <4AB8654E.5050805@lip6.fr>

Hi Alysson,

Alysson wrote:
> Hi, LLVMers,
>
>     I am a CS student in my final year, and I would like to use LLVM 
> in my final course project. So, I just download LLVM and VMKit, and I 
> have been playing with both. I can produce llvm bytecodes from java 
> programs, and now my idea is to remove redundant type checks from the 
> code. For instance, if we consider a program like this:
>
> if (o instanceof A) {
>   A a = (A) o;
>   // do something with a
> }
>
> we see that Java will put a type test before the cast, but this test 
> is unnecessary, as we already know that we have passed the instanceof 
> test. So, as my project I would like to remove these redundant tests.

OK.

> My questions:
>
> 1) Has this already been done by some of the VMKit optimizing passes?

I believe it must be done if you run the -gvn pass on the llvm bytecode. 
You can for example give the "-std-compile-opts" command line argument 
to vmjc.

> 2) If not, is this feasible?

If the -gvn pass does not remove it, you can write your own optimization 
pass on the llvm bytecode and detect the redundant checks. Then use the 
opt tool to load your pass and apply it to your llvm bytecode.

> 3) Is this the right list to ask questions about VMKit?
>

These kinds of questions, I believe yes :)

Cheers,
Nicolas

> All the best,
>
> Alysson
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From curtis.jones at gmail.com  Mon Sep 21 17:49:04 2009
From: curtis.jones at gmail.com (Curtis Jones)
Date: Mon, 21 Sep 2009 18:49:04 -0400
Subject: [LLVMdev] LLVM Build Difficulties
Message-ID: <CA456906-F66B-4EFE-9082-9DA42F6CE48D@gmail.com>

I hope this is the right list for such questions.... I've been trying  
to get LLVM compiled under Linux (Ubuntu 9.04, 64 bit) for the last  
couple of days.

It all ends with the error:

llvm[2]: Linking Release executable tblgen (without symbols)
/home/cjones/Desktop/Build/llvm/utils/TableGen/Release/ 
AsmMatcherEmitter.o: In function `(anonymous  
namespace)::AsmMatcherInfo::BuildInfo(llvm::CodeGenTarget&)':
AsmMatcherEmitter.cpp:(.text+0xbbbb): undefined reference to  
`llvm::StringRef::find(llvm::StringRef const&) const'
/home/cjones/Desktop/Build/llvm/utils/TableGen/Release/TableGen.o: In  
function `llvm::cl::opt<ActionType, false,  
llvm::cl::parser<ActionType> >::handleOccurrence(unsigned int,  
llvm::StringRef, llvm::StringRef)':
TableGen.cpp: 
(.gnu.linkonce.t 
._ZN4llvm2cl3optI10ActionTypeLb0ENS0_6parserIS2_EEE16handleOccurrenceEjNS_9StringRefES6_ 
+0x292): undefined reference to `llvm::cl::Option::error(llvm::Twine  
const&, llvm::StringRef)'
collect2: ld returned 1 exit status
make[2]: *** [/home/cjones/Desktop/Build/llvm/Release/bin/tblgen]  
Error 1
make[2]: Leaving directory `/home/cjones/Desktop/Build/llvm/utils/ 
TableGen'
make[1]: *** [TableGen/.makeall] Error 2
make[1]: Leaving directory `/home/cjones/Desktop/Build/llvm/utils'
make: *** [all] Error 1

I've tried an array of different gcc versions, and quite a few  
different configure options, but to no avail. The complete gamut of  
options looks like this presently:

	CXXFLAGS="-fPIC" ./configure --enable-optimized --enable-assertions -- 
disable-multilib

I've got the latest code from subversion. I have clang checked out  
into tools/clang.

Let me know what additional information I can provide....

Any help would be appreciated.

Thanks.

--
Curtis Jones
curtisjones.us
404.723.3728

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090921/888eaff2/attachment.bin 

From alvin.cheung at gmail.com  Mon Sep 21 23:34:58 2009
From: alvin.cheung at gmail.com (Alvin Cheung)
Date: Tue, 22 Sep 2009 00:34:58 -0400
Subject: [LLVMdev] getting debug info
Message-ID: <4AB853F2.7070402@gmail.com>

Hi all,

I am wondering if someone can give me pointers to how to use the DI* classes 
defined in DebugInfo.h.  In particular, I am confused about how to get a MDNode 
from the GlobalVariable's that hold the debug info so that they can be passed 
into the DI* classes, and the difference between MDNode and NamedMDNode in 
general.  Thanks for your help.

Alvin

From viridia at gmail.com  Tue Sep 22 02:14:00 2009
From: viridia at gmail.com (Talin)
Date: Tue, 22 Sep 2009 00:14:00 -0700
Subject: [LLVMdev] DebugFactory
Message-ID: <4AB87938.6080807@gmail.com>

So, one feature of the late, lamented DebugInfoBuilder that I am missing 
quite badly, and which is not available in the current DIFactory, is the 
ability to specify structure offsets abstractly. The DebugFactory 
requires that you pass in structure offset information as ints, whereas 
DebugInfoBuilder had "offsetOf" and "alignOf" methods, similar to the 
"sizeOf" trick, that would create the constants for you in a way that 
didn't require your front end to know the sizes of things. So far I've 
been able to avoid having any references to target machines in my 
frontend, but now that I am trying to flesh out my debug info more fully 
I'm finding it hard to use DIFactory as-is.

What I'd like to see is a set of alternative factory methods in 
DIFactory, where you pass in an LLVM type, and possibly a GEP index, 
plus all of the parameters that it can't figure out from looking at the 
type. So you can eliminate the offset, size, and alignment parameters 
since those can be figured out from the type.

-- Talin




From baldrick at free.fr  Tue Sep 22 04:11:48 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 22 Sep 2009 11:11:48 +0200
Subject: [LLVMdev] LLVM Build Difficulties
In-Reply-To: <CA456906-F66B-4EFE-9082-9DA42F6CE48D@gmail.com>
References: <CA456906-F66B-4EFE-9082-9DA42F6CE48D@gmail.com>
Message-ID: <4AB894D4.70100@free.fr>

Hi Curtis,

> I hope this is the right list for such questions.... I've been trying to 
> get LLVM compiled under Linux (Ubuntu 9.04, 64 bit) for the last couple 
> of days.

I can't reproduce this with ubuntu 9.10, 64 bit x86, gcc 4.4.1, using
your configure options.  What version of gcc are you using?

>     CXXFLAGS="-fPIC" ./configure --enable-optimized --enable-assertions 
> --disable-multilib

Not sure why you are passing -fPIC like this?  Anyway, on my system it
didn't hurt: everything built fine anyway.

Ciao,

Duncan.

From jon at ffconsultancy.com  Tue Sep 22 07:00:59 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Tue, 22 Sep 2009 13:00:59 +0100
Subject: [LLVMdev] struct returns
In-Reply-To: <4AB07FCB.3050404@gmail.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
	<400d33ea0909151010t3f340c76ob99bc82726cf9826@mail.gmail.com>
	<4AB07FCB.3050404@gmail.com>
Message-ID: <200909221300.59222.jon@ffconsultancy.com>

On Wednesday 16 September 2009 07:03:55 Talin wrote:
> Kenneth Uildriks wrote:
> > That would be even better.  I suppose codegen would have to do
> > something like the sret parameter demotion when the number of members
> > exceeds the number of available registers?  Or did you have something
> > else in mind?
> >
> > Fixing this would make my front-end noticeably simpler, and would
> > probably benefit other front-ends as well, so I'd be willing to spend
> > some time on it.
>
> It would definitely help my front end :)

And mine!

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

From jon at ffconsultancy.com  Tue Sep 22 07:01:48 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Tue, 22 Sep 2009 13:01:48 +0100
Subject: [LLVMdev] struct returns
In-Reply-To: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
References: <400d33ea0909150832u5b366ca8xe0212070d9decd82@mail.gmail.com>
Message-ID: <200909221301.48456.jon@ffconsultancy.com>

On Tuesday 15 September 2009 16:32:00 Kenneth Uildriks wrote:
> In the latest snapshot from SVN on X86, llc refuses to compile
> functions returning structs larger than two i32 members.

Does it not handle two double-precision floats for the C99 complex type? Or 
did you mean "larger" as in more fields rather than larger fields?

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

From stefan.oestreicher at deluxe-design.at  Tue Sep 22 08:09:05 2009
From: stefan.oestreicher at deluxe-design.at (Stefan Oestreicher)
Date: Tue, 22 Sep 2009 15:09:05 +0200
Subject: [LLVMdev] help with llvm make system
Message-ID: <4AB8CC71.5010105@deluxe-design.at>

Hi,

I'm working on a compiler for a small toy language and I'm using the
llvm sample project layout, i.e. the llvm make system.