From nicholas at mxc.ca Sat May 1 01:11:32 2010 From: nicholas at mxc.ca (Nick Lewycky) Date: Fri, 30 Apr 2010 23:11:32 -0700 Subject: [LLVMdev] Best intermediate form to... In-Reply-To: <28418568.post@talk.nabble.com> References: <28418568.post@talk.nabble.com> Message-ID: <4BDBC614.9060303@mxc.ca> nonpoly wrote: > > Hello Everyone! > New to the forums, so hopefully I'm not a nuisance. I just wanted to > know where to go (since I heard there were about 5 different intermediate > forms for llvm) to find the highest level intermediate form of llvm. I assume you're referring to this comment: http://lwn.net/Articles/383707/ LLVM has one major IR that we mean when we say "the IR", and that's the one described by the LangRef you linked to. As for the having five different ones, it really comes down to what you consider an IR. Many passes will to build up data structures on the side in order to facilitate their optimizations. At what point do those cross the line from being data to being another intermediate representation? I would argue that a good test is whether the intention is whether you lower from one to the next. For example, gcc lowers from GENERIC to GIMPLE and never looks back, Open64 lower VHL to HL to ML to LL to VLL the same way. The SCEV format at least isn't like that, but there is at least one lowering step from the IR to the DAG/MachineInsts that machine-specific CodeGen uses. MCInst may not be an IR on the grounds that it's not intermediate, it's just a direct representation of assembly instructions. I want > to be able to get as much information from a front-end as possible. Mainly > I need to find out dependencies and control flows, amongst a few other > things. So far I've seen http://llvm.org/docs/LangRef.html which might be > what I'm looking for, but I just wanted to make sure. Yes. > Also I heard that there's something that can convert GCCs GIMPLE to llvm > IR, which I looked up and I believe is llvm-gcc, but again, I want to make > sure that's it. Also, is there a plugin that converts llvm IR to GIMPLE, or > is there a project currently working on it? Yes, there's llvm-gcc which is a modified gcc 4.2. It's getting less attention as more work is done on clang. There's also the plugin you mentioned, dragonegg.llvm.org. Nick From llvm at assumetheposition.nl Sat May 1 04:09:00 2010 From: llvm at assumetheposition.nl (Paul Melis) Date: Sat, 01 May 2010 11:09:00 +0200 Subject: [LLVMdev] Using gcroot with value types In-Reply-To: References: <36426.145.100.6.164.1272267889.squirrel@www.assumetheposition.nl> <4BD88990.6080304@assumetheposition.nl> Message-ID: <4BDBEFAC.5080700@assumetheposition.nl> On 04/29/10 21:27, Talin wrote: > On Wed, Apr 28, 2010 at 12:16 PM, Paul Melis > > wrote: > > On 04/27/10 00:20, Talin wrote: >> On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis >> > wrote: >> >> Hi, >> >> Talin wrote: >> > I'm a little confused as to the rules for the arguments to >> llvm.gcroot, >> > which says it must be a pointer alloca. I'm not sure >> whether that means it >> > must be an alloca (which is always a pointer by definition) >> or an alloca >> > *of* a pointer. >> >> I'm pretty sure it should be "alloca of a pointer", as the >> first argument >> of llvm.gcroot has type i8**. >> >> However, http://llvm.org/docs/GarbageCollection.html#gcroot, >> isn't >> completely clear on this: >> >> "The first argument must be a value referring to an alloca >> instruction or >> a bitcast of an alloca." >> >> This last sentence seems to rule out passing GEPs on alloca's >> to llvm.gcroot. >> >> > What I am trying to figure out is how to declare roots >> contained in value >> > types. Suppose for example I have a small struct which >> contains several >> > garbage-collectable references. This struct is a local >> variable, so it's >> > contained in a block of memory which has been allocated via >> alloca. Now, I >> > don't want to add the struct itself as a root, since it >> isn't allocated on >> > the heap. But I want to declare the fields within the >> struct - which are >> > GEPs from the alloca pointer - as roots, since they are >> references to >> > objects on the heap. >> >> As reasonable as the above sounds, I don't think you can mark >> roots >> contained in structs. But if I'm wrong I'd love to know ;-) >> Perhaps you >> can ask the LDC devs how/if they handle this case, as it >> seems you can >> allocate a class instance on the stack in D. >> >> Ugh. If all roots have to be singleton pointers, not embedded >> within a larger structure, then I'm not sure that what I want to >> do is even possible. > In principle you could probably mark the alloca's of your value > structs as gcroots. Then during collection you would have to make > sure you recognize the value types so you don't > move/deallocate/... them during a collection. That would still > give you the option to trace all live objects by simply traversing > the fields of a value struct. You would only have to do this for > value structs (indirectly) containing references. Does that make > sense? > > > Unfortunately, when I try to do this, the function verifier reports > the function as broken. It requires that the argument to llvm.gcroot > be a pointer to an alloca of a pointer. I can't fool it with casts. Oops, I wasn't specific enough. Marking an alloca of a value type indeed won't work, as you noticed. Put differently, the idea is that value types and heap types are treated the same w.r.t. marking them with gcroot, while the former is allocated using alloca and the latter with your GC allocation routine. It's only during collection that you have to make sure not to collect value types. // Some value type %struct.V = type { i32, float, i8* } // Allocate space for a pointer to a V instance, which we mark as GC root %v = alloca %struct.V*, align 8 ; <%struct.V**> [#uses=2] %0 = bitcast %struct.V** %v to i8** ; [#uses=1] call void @llvm.gcroot(i8** %0, i8* null) // Allocate the V instance on the stack and store it's address in the root %1 = alloca %struct.V, align 4 ; <%struct.V*> [#uses=3] store %struct.V* %1, %struct.V** %v, align 8 Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/380a44a3/attachment.html From zapster at zapster.cc Sat May 1 08:34:50 2010 From: zapster at zapster.cc (Josef Eisl) Date: Sat, 01 May 2010 15:34:50 +0200 Subject: [LLVMdev] Register Allocation: Interference graph Message-ID: <4BDC2DFA.6090903@zapster.cc> Hello, I want learn more about register allocation and do some analysis for a current research project. After reading some papers (eg. Chaitin, Briggs) I think its time to get my hands dirty :). First I plan to (re)implement some of the classic approaches to get familiar with the framework. At the beginning the following questions came up: - Is there some documentation about register allocation in LLVM? - As far as I understand it, register allocators are implemented as MachineFunctionPasses. Does a MachineFunction object contain all information needed for a (classic) allocator? - Is there already a pass that prints interference graph (Chaitin et al. 1981) or something similar like opt -view-cfg prints a CFG? If not, is it even possible with the current LLVM infrastructure? - Is there an LLVM register allocator that uses graph coloring or something similar? - Which LLVM allocator would you recommend to look into to get the basic ideas how to use the framework? Many thanks in advance! Josef From kuba at gcc.gnu.org Sat May 1 10:07:16 2010 From: kuba at gcc.gnu.org (Jakub Staszak) Date: Sat, 1 May 2010 13:07:16 -0200 Subject: [LLVMdev] PR4174 Message-ID: <7667FAA5-DC0A-4CF8-A92C-38261E7C6D80@gcc.gnu.org> Hello again :) After some break I send patch for PR4174. It was proposed some time ago, this one works with trunk. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr4174-4.patch Type: application/octet-stream Size: 2932 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/bc8fa001/attachment.obj From kuba at gcc.gnu.org Sat May 1 10:11:02 2010 From: kuba at gcc.gnu.org (Jakub Staszak) Date: Sat, 1 May 2010 13:11:02 -0200 Subject: [LLVMdev] Inconsistent line ending style, patch Message-ID: <794BB3A1-23F4-4191-8FCD-83C895411760@gcc.gnu.org> Hello, I send a patch which fixes "svn: Inconsistent line ending style" error which I got when I was trying to import LLVM to my own SVN server. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_ending.diff Type: application/octet-stream Size: 2540 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/6185407c/attachment.obj From fxyxixe at gmail.com Sat May 1 11:07:31 2010 From: fxyxixe at gmail.com (nonpoly) Date: Sat, 1 May 2010 09:07:31 -0700 (PDT) Subject: [LLVMdev] Best intermediate form to... In-Reply-To: <4BDBC614.9060303@mxc.ca> References: <28418568.post@talk.nabble.com> <4BDBC614.9060303@mxc.ca> Message-ID: <28421718.post@talk.nabble.com> Wow, thanks for the super fast reply! I was asking about llvm-gcc because I want to be able to work with code that compiles on GCC (since there is so much already out there), but in an intermediate form. So I take it that clang plans on being able to compile code that compiles on GCC? I'm assuming that's what they mean by "GCC compatibility" on http://clang.llvm.org/ ;p On a side note, is clang - at least for the most part - hand coded like g++ was for GCC? Or is it making use of generators like lex/flex and yacc/bison? Thanks again! -nonpoly Nick Lewycky wrote: > > nonpoly wrote: >> >> Hello Everyone! >> New to the forums, so hopefully I'm not a nuisance. I just wanted to >> know where to go (since I heard there were about 5 different intermediate >> forms for llvm) to find the highest level intermediate form of llvm. > > I assume you're referring to this comment: > > http://lwn.net/Articles/383707/ > > LLVM has one major IR that we mean when we say "the IR", and that's the > one described by the LangRef you linked to. > > As for the having five different ones, it really comes down to what you > consider an IR. Many passes will to build up data structures on the side > in order to facilitate their optimizations. At what point do those cross > the line from being data to being another intermediate representation? I > would argue that a good test is whether the intention is whether you > lower from one to the next. For example, gcc lowers from GENERIC to > GIMPLE and never looks back, Open64 lower VHL to HL to ML to LL to VLL > the same way. The SCEV format at least isn't like that, but there is at > least one lowering step from the IR to the DAG/MachineInsts that > machine-specific CodeGen uses. MCInst may not be an IR on the grounds > that it's not intermediate, it's just a direct representation of > assembly instructions. > > I want >> to be able to get as much information from a front-end as possible. >> Mainly >> I need to find out dependencies and control flows, amongst a few other >> things. So far I've seen http://llvm.org/docs/LangRef.html which might >> be >> what I'm looking for, but I just wanted to make sure. > > Yes. > >> Also I heard that there's something that can convert GCCs GIMPLE to >> llvm >> IR, which I looked up and I believe is llvm-gcc, but again, I want to >> make >> sure that's it. Also, is there a plugin that converts llvm IR to GIMPLE, >> or >> is there a project currently working on it? > > Yes, there's llvm-gcc which is a modified gcc 4.2. It's getting less > attention as more work is done on clang. There's also the plugin you > mentioned, dragonegg.llvm.org. > > 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://old.nabble.com/Best-intermediate-form-to...-tp28418568p28421718.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From clattner at apple.com Sat May 1 12:38:07 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 1 May 2010 10:38:07 -0700 Subject: [LLVMdev] Inconsistent line ending style, patch In-Reply-To: <794BB3A1-23F4-4191-8FCD-83C895411760@gcc.gnu.org> References: <794BB3A1-23F4-4191-8FCD-83C895411760@gcc.gnu.org> Message-ID: Thanks, applied in r102852 -Chris On May 1, 2010, at 8:11 AM, Jakub Staszak wrote: > Hello, > > I send a patch which fixes "svn: Inconsistent line ending style" error which I got when I was trying to import LLVM to my own SVN server. > > Regards > -- > Jakub Staszak > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From resistor at mac.com Sat May 1 13:07:16 2010 From: resistor at mac.com (Owen Anderson) Date: Sat, 01 May 2010 11:07:16 -0700 Subject: [LLVMdev] Adding a halting function attribute? In-Reply-To: <20100501171938.80516312800A@llvm.org> References: <20100501171938.80516312800A@llvm.org> Message-ID: <3C5E4CAF-E189-4BBD-BAB9-B1AB61BC7C90@mac.com> Hey folks, In a recent blog post, John Regehr pointed out that LLVM is currently optimizing away read-only functions containing infinite loops whose return values are never used. The culprit for the moment is the inliner, but the more insidious problem is that isTriviallyDeletable currently returns true for any read-only function whose value is not used. In order to prevent this from happening while avoiding pessimizing the common case, I'm proposing adding a "halting" function attribute which is a hint to the optimizers that a function is guaranteed to halt. A pretty simple conservative implementation would be as a "contains no loops" analysis. Obviously fancier implementations are possible, but we'd like to avoid having the FunctionAttrs depend on LoopInfo or SCEV which would be needed for loop finiteness analysis. Additionally, we already have the LoopDeletion pass interleaved, which should handle exactly those cases anyways. Thoughts? --Owen From clattner at apple.com Sat May 1 13:19:48 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 1 May 2010 11:19:48 -0700 Subject: [LLVMdev] Adding a halting function attribute? In-Reply-To: <3C5E4CAF-E189-4BBD-BAB9-B1AB61BC7C90@mac.com> References: <20100501171938.80516312800A@llvm.org> <3C5E4CAF-E189-4BBD-BAB9-B1AB61BC7C90@mac.com> Message-ID: <9A0BC3E3-58D1-4461-A942-8DBD344EF13F@apple.com> On May 1, 2010, at 11:07 AM, Owen Anderson wrote: > Hey folks, > > In a recent blog post, John Regehr pointed out that LLVM is currently optimizing away read-only functions containing infinite loops whose return values are never used. The culprit for the moment is the inliner, but the more insidious problem is that isTriviallyDeletable currently returns true for any read-only function whose value is not used. > > In order to prevent this from happening while avoiding pessimizing the common case, I'm proposing adding a "halting" function attribute which is a hint to the optimizers that a function is guaranteed to halt. A pretty simple conservative implementation would be as a "contains no loops" analysis. Obviously fancier implementations are possible, but we'd like to avoid having the FunctionAttrs depend on LoopInfo or SCEV which would be needed for loop finiteness analysis. Additionally, we already have the LoopDeletion pass interleaved, which should handle exactly those cases anyways. Two (more) problems: 1) You have to prove that infinite recursion (which might be tail calls) doesn't happen. This means that anything that does an indirect call has to be assumed to not be halting. 2) You'd have to update all the builtins to say they are halting, because they are external functions. 3) This adds (even more) clutter to the IR. :( -Chris From eli.friedman at gmail.com Sat May 1 14:41:40 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 1 May 2010 12:41:40 -0700 Subject: [LLVMdev] Best intermediate form to... In-Reply-To: <28421718.post@talk.nabble.com> References: <28418568.post@talk.nabble.com> <4BDBC614.9060303@mxc.ca> <28421718.post@talk.nabble.com> Message-ID: On Sat, May 1, 2010 at 9:07 AM, nonpoly wrote: > > Wow, thanks for the super fast reply! > > I was asking about llvm-gcc because I want to be able to work with code that > compiles on GCC (since there is so much already out there), but in an > intermediate form. ?So I take it that clang plans on being able to compile > code that compiles on GCC? ?I'm assuming that's what they mean by "GCC > compatibility" on http://clang.llvm.org/ ;p With some caveats, yes... clang has gcc-compatible command-line parsing and supports all the commonly used gcc extensions. See http://clang.llvm.org/docs/UsersManual.html#c . > On a side note, is clang - at least for the most part - hand coded like g++ > was for GCC? ?Or is it making use of generators like lex/flex and > yacc/bison? Hand-coded; see http://clang.llvm.org/features.html#unifiedparser . -Eli From ambika at cse.iitb.ac.in Sat May 1 14:48:25 2010 From: ambika at cse.iitb.ac.in (ambika) Date: Sun, 02 May 2010 01:18:25 +0530 Subject: [LLVMdev] How to change successor of a regular Basic block Message-ID: <4BDC8589.7080201@cse.iitb.ac.in> Hi, I am working with regular dominator tree and not MachineDominatorTree. I wanted to modify the CFG structure and for that I need to change successor of a basic block. How can I do that? Or is there a way to cast a BasicBlock to MachineBasicBlock so that i can use functions addSucessor and removeSuccessor for the basic block. It will be great if someone can help. regards, Ambika From nicholas at mxc.ca Sat May 1 15:41:14 2010 From: nicholas at mxc.ca (Nick Lewycky) Date: Sat, 01 May 2010 13:41:14 -0700 Subject: [LLVMdev] How to change successor of a regular Basic block In-Reply-To: <4BDC8589.7080201@cse.iitb.ac.in> References: <4BDC8589.7080201@cse.iitb.ac.in> Message-ID: <4BDC91EA.4000000@mxc.ca> ambika wrote: > Hi, > > I am working with regular dominator tree and not MachineDominatorTree. > I wanted to modify the CFG structure and for that I need to change > successor of a basic block. > How can I do that? The last instruction in a BasicBlock is the TerminatorInst. Replace that instruction with one that flows into the blocks you want. See http://llvm.org/docs/LangRef.html#terminators . (Don't forget to update the phi nodes, if applicable. See BasicBlock::removePredecessor().) > Or is there a way to cast a BasicBlock to MachineBasicBlock so that i > can use functions addSucessor and removeSuccessor for the basic block. No. There's no Machine-etc classes until codegen time. Nick From llvm at tomvandijck.com Sat May 1 21:59:32 2010 From: llvm at tomvandijck.com (Tom van Dijck) Date: Sat, 1 May 2010 19:59:32 -0700 Subject: [LLVMdev] Compiling LLVM 2.7 with Visual Studio 2010. Message-ID: Hey, Downloaded the release, used CMake to create solution... building mostly seems to be OK, except for a couple of compiler errors. warning C4090: 'function' : different 'const' qualifiers d:\companyone\external\llvm\source\llvm-2.7\lib\support\regengine.inc 188 error C2248: 'llvm::EquivalenceClasses::ECValue::ECValue' : cannot access private member declared in class 'llvm::EquivalenceClasses::ECValue' C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory 208 error C2668: 'llvm::next' : ambiguous call to overloaded function D:\CompanyOne\External\LLVM\source\llvm-2.7\lib\Transforms\Scalar\LoopStrengthReduce.cpp 2820 error C2440: 'initializing' : cannot convert from 'int' to 'const llvm::TargetRegisterClass *' C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility 163 error C2439: 'std::_Pair_base<_Ty1,_Ty2>::second' : member could not be initialized C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility 163 it totals to 15 build errors and 2 warnings, but most of them are repeats of the above 5.. Are these known issues? Or did I fail to set some setting? 3 of the errors come from usage of templates, hence the file names end up somewhere in the VS SDK, I can provide more details if required though.. Tom. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/cad08ca5/attachment.html From llvm at tomvandijck.com Sat May 1 22:57:39 2010 From: llvm at tomvandijck.com (Tom van Dijck) Date: Sat, 1 May 2010 20:57:39 -0700 Subject: [LLVMdev] Compiling LLVM 2.7 with Visual Studio 2010. In-Reply-To: References: Message-ID: Hey, So I tried to fix these errors, and have everything compiling now... not too difficult, just annoying. error C2248: 'llvm::EquivalenceClasses< > > ElemTy>::ECValue::ECValue' : cannot access private member declared in class > 'llvm::EquivalenceClasses::ECValue' C:\Program Files > (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory 208 I moved: // ECValue ctor - Start out with EndOfList pointing to this node, Next is Null, isLeader = true. ECValue(const ElemTy &Elt) : Leader(this), Next((ECValue*)(intptr_t)1), Data(Elt) {} into the public section of the ECValue class, seemed to solve that one.. ------ the cast errors from below... pretty weird, but the Microsofts compiler seems to not like passing in 0 as a pointer into the pair<> template if that argument is in reality a pointer. seems weird since if (bla == 0) works fine, but pair(0,0); does not, anyway, the fix was to just cast that 0... so pair(0, (void*)0); ------ Last there is a gazillion errors around the fact that Microsoft for some crazy stupid reason has defined setjmp to _setjmp, and thus the generated intrinsics.gen goes completely insane everywhere. I'm sure this is a legacy thing in visual studios libraries, but wow... Anyway, my solution to this was to make a 'intrinsics.gen.proxy', which undefs that macro and then includes the intrinsics.gen, and then all includes to intrinsics.gen, I modified to include the proxy. This guarantees that at least the Instrinsic namespace is always setup correctly... and you're left with a couple other files where it still seems to be defined, so I just undef'ed it for the whole file in those files as well... Is there any interest in these changes applied to trunk? and if so how do I proceed... I'm fine keeping these changes local and integrate, but I figure there is more users out there wanting to move to VS2010 at some point. Tom. On Sat, May 1, 2010 at 7:59 PM, Tom van Dijck wrote: > Hey, > > Downloaded the release, used CMake to create solution... building mostly > seems to be OK, except for a couple of compiler errors. > > > warning C4090: 'function' : different 'const' qualifiers > d:\companyone\external\llvm\source\llvm-2.7\lib\support\regengine.inc 188 > error C2248: 'llvm::EquivalenceClasses::ECValue::ECValue' : cannot > access private member declared in class > 'llvm::EquivalenceClasses::ECValue' C:\Program Files > (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory 208 > error C2668: 'llvm::next' : ambiguous call to overloaded function > D:\CompanyOne\External\LLVM\source\llvm-2.7\lib\Transforms\Scalar\LoopStrengthReduce.cpp > 2820 > error C2440: 'initializing' : cannot convert from 'int' to 'const > llvm::TargetRegisterClass *' C:\Program Files (x86)\Microsoft Visual > Studio 10.0\VC\include\utility 163 > error C2439: 'std::_Pair_base<_Ty1,_Ty2>::second' : member could not be > initialized C:\Program Files (x86)\Microsoft Visual Studio > 10.0\VC\include\utility 163 > > it totals to 15 build errors and 2 warnings, but most of them are repeats > of the above 5.. > Are these known issues? Or did I fail to set some setting? > > 3 of the errors come from usage of templates, hence the file names end up > somewhere in the VS SDK, I can provide more details if required though.. > > Tom. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/1c14b5b8/attachment.html From albert.zeyer at rwth-aachen.de Sat May 1 16:50:30 2010 From: albert.zeyer at rwth-aachen.de (Albert Zeyer) Date: Sat, 01 May 2010 23:50:30 +0200 Subject: [LLVMdev] clang compiles OpenLieroX Message-ID: <4BDCA226.6090905@rwth-aachen.de> Heya, LLVM r102655 + clang r102825 compile OpenLieroX 31e0dac9 on MacOSX 10.5 and Linux! One small fix was needed in the MacOSX OpenAL alc.h system header: - typedef void ALCvoid; + #define ALCvoid void Because of this: /System/Library/Frameworks/OpenAL.framework/Headers/alc.h:182:68: error: empty parameter list defined with a typedef of 'void' not allowed in C++ ALC_API ALCcontext * ALC_APIENTRY alcGetCurrentContext( ALCvoid ); ^ See http://llvm.org/bugs/show_bug.cgi?id=7009. This is a bug in the MacOSX OpenAL headers. Otherwise, nothing was needed. OLX itself starts fine, you can also play net games (played on the Fast Mortars server a few rounds), performance is ok/good (haven't used any compiler flags for clang). Some other stuff crashes, like opening the local menu or Google Breakpad (no time yet to debug). That is a big step forward and the first time it compiles. I have tried frequently again and again with clang/llvm trunk the last couple of weeks. Got hit by many clang bugs which I reported upstream and which were fixed pretty fast. Greets, Albert From blunted2night at gmail.com Sat May 1 18:59:35 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Sat, 1 May 2010 16:59:35 -0700 Subject: [LLVMdev] Win32 COFF Support Message-ID: Hi All, I have created a minimally functional Win32 COFF Exporter using the new MC framework. I made some minor changes to other libraries to allow me to plug it in without building it as part of the LLVM project. I wanted to share it but wasn't sure how to go about doing so, so I have attached the code to this message. Any feedback on would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/2290f5c7/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: core-changes.patch Type: application/octet-stream Size: 9273 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/2290f5c7/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: COFF.7z Type: application/octet-stream Size: 5937 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/2290f5c7/attachment-0001.obj From llvm at tomvandijck.com Sat May 1 23:53:40 2010 From: llvm at tomvandijck.com (Tom van Dijck) Date: Sat, 1 May 2010 21:53:40 -0700 Subject: [LLVMdev] Compiling LLVM 2.7 with Visual Studio 2010. In-Reply-To: References: Message-ID: Sorry for just talking to myself here, just trying to keep people in the loop on my findings. The problem seems to be a much larger issue with the Visual Studio 2010 C++ Compiler and not really related to clang/llvm. The following snippet of code does *NOT *compile in 2010.. #include int main(int argc, char* argv[]) { std::pair mypair(0, NULL); return 0; } Tom. On Sat, May 1, 2010 at 8:57 PM, Tom van Dijck wrote: > Hey, > > So I tried to fix these errors, and have everything compiling now... not > too difficult, just annoying. > > error C2248: 'llvm::EquivalenceClasses< >> >> ElemTy>::ECValue::ECValue' : cannot access private member declared in >> class 'llvm::EquivalenceClasses::ECValue' C:\Program Files >> (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory 208 > > > I moved: > > // ECValue ctor - Start out with EndOfList pointing to this node, Next > is Null, isLeader = true. > ECValue(const ElemTy &Elt) > : Leader(this), Next((ECValue*)(intptr_t)1), Data(Elt) {} > > into the public section of the ECValue class, seemed to solve that one.. > > ------ > > the cast errors from below... pretty weird, but the Microsofts compiler > seems to not like passing in 0 as a pointer into the pair<> template if that > argument is in reality a pointer. seems weird since if (bla == 0) works > fine, but pair(0,0); does not, anyway, the fix was to just cast > that 0... so pair(0, (void*)0); > > ------ > > Last there is a gazillion errors around the fact that Microsoft for some > crazy stupid reason has defined setjmp to _setjmp, and thus the generated > intrinsics.gen goes completely insane everywhere. I'm sure this is a legacy > thing in visual studios libraries, but wow... > > Anyway, my solution to this was to make a 'intrinsics.gen.proxy', which > undefs that macro and then includes the intrinsics.gen, and then all > includes to intrinsics.gen, I modified to include the proxy. This guarantees > that at least the Instrinsic namespace is always setup correctly... and > you're left with a couple other files where it still seems to be defined, so > I just undef'ed it for the whole file in those files as well... > > Is there any interest in these changes applied to trunk? and if so how do I > proceed... I'm fine keeping these changes local and integrate, but I figure > there is more users out there wanting to move to VS2010 at some point. > > Tom. > > > On Sat, May 1, 2010 at 7:59 PM, Tom van Dijck wrote: > >> Hey, >> >> Downloaded the release, used CMake to create solution... building mostly >> seems to be OK, except for a couple of compiler errors. >> >> >> warning C4090: 'function' : different 'const' qualifiers >> d:\companyone\external\llvm\source\llvm-2.7\lib\support\regengine.inc 188 >> error C2248: 'llvm::EquivalenceClasses::ECValue::ECValue' : cannot >> access private member declared in class >> 'llvm::EquivalenceClasses::ECValue' C:\Program Files >> (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory 208 >> error C2668: 'llvm::next' : ambiguous call to overloaded function >> D:\CompanyOne\External\LLVM\source\llvm-2.7\lib\Transforms\Scalar\LoopStrengthReduce.cpp >> 2820 >> error C2440: 'initializing' : cannot convert from 'int' to 'const >> llvm::TargetRegisterClass *' C:\Program Files (x86)\Microsoft Visual >> Studio 10.0\VC\include\utility 163 >> error C2439: 'std::_Pair_base<_Ty1,_Ty2>::second' : member could not be >> initialized C:\Program Files (x86)\Microsoft Visual Studio >> 10.0\VC\include\utility 163 >> >> it totals to 15 build errors and 2 warnings, but most of them are repeats >> of the above 5.. >> Are these known issues? Or did I fail to set some setting? >> >> 3 of the errors come from usage of templates, hence the file names end up >> somewhere in the VS SDK, I can provide more details if required though.. >> >> Tom. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/df26a9fe/attachment.html From me22.ca at gmail.com Sun May 2 00:02:58 2010 From: me22.ca at gmail.com (me22) Date: Sun, 2 May 2010 01:02:58 -0400 Subject: [LLVMdev] Compiling LLVM 2.7 with Visual Studio 2010. In-Reply-To: References: Message-ID: On 2 May 2010 00:53, Tom van Dijck wrote: > The problem seems to be a much larger issue with the Visual Studio 2010 C++ > Compiler and not really related to clang/llvm. The following snippet of code > does NOT compile in 2010.. > > #include > int main(int argc, char* argv[]) > { > ??? std::pair mypair(0, NULL); > ??? return 0; > } > That's perfectly fine -- it never #includes , so there's no reason for std::pair to be in scope. From rgoparaj at umail.iu.edu Sun May 2 00:08:02 2010 From: rgoparaj at umail.iu.edu (Rohith Goparaju) Date: Sun, 2 May 2010 01:08:02 -0400 Subject: [LLVMdev] Unreachable Executed error. Message-ID: Hi, I've written a pass that basically does some code transformations to enable parallel execution. After the transformation llvm runs BitCode Writer pass , which is aborting with Unreachable Executed error. What does this error generally mean?. Any pointers on how to go about debugging this. Thanks, Rohith. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/b9b06f3b/attachment.html From llvm at tomvandijck.com Sun May 2 00:09:23 2010 From: llvm at tomvandijck.com (Tom van Dijck) Date: Sat, 1 May 2010 22:09:23 -0700 Subject: [LLVMdev] Compiling LLVM 2.7 with Visual Studio 2010. In-Reply-To: References: Message-ID: On Sat, May 1, 2010 at 10:02 PM, me22 wrote: > On 2 May 2010 00:53, Tom van Dijck wrote: > > The problem seems to be a much larger issue with the Visual Studio 2010 > C++ > > Compiler and not really related to clang/llvm. The following snippet of > code > > does NOT compile in 2010.. > > > > #include > > int main(int argc, char* argv[]) > > { > > std::pair mypair(0, NULL); > > return 0; > > } > > > > That's perfectly fine -- it never #includes , > so there's no reason for std::pair to be in scope. > #include int main(int argc, char* argv[]) { std::pair mypair(0, (void*)NULL); return 0; } compiles fine though... couple people have reported the same issue actually, and apparently this is by design due to C++0x: https://connect.microsoft.com/VisualStudio/feedback/details/520043/error-converting-from-null-to-a-pointer-type-in-std-pair?wa=wsignin1.0#tabs Tom. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/9d3c0d3f/attachment.html From rnk at mit.edu Sun May 2 00:12:38 2010 From: rnk at mit.edu (Reid Kleckner) Date: Sun, 2 May 2010 01:12:38 -0400 Subject: [LLVMdev] Unreachable Executed error. In-Reply-To: References: Message-ID: Run the verifier pass after your pass. The bitcode readers and writers assume that the IR is well-formed, which yours may not be. Reid On Sun, May 2, 2010 at 1:08 AM, Rohith Goparaju wrote: > Hi, > > ? I've written a pass that basically does some code transformations to > enable parallel execution. After the transformation llvm runs BitCode Writer > pass , which is aborting with Unreachable Executed error.? What does this > error generally mean?. > ? Any pointers on how to go about debugging this. > > Thanks, > ?Rohith. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From llvm at tomvandijck.com Sun May 2 00:34:26 2010 From: llvm at tomvandijck.com (Tom van Dijck) Date: Sat, 1 May 2010 22:34:26 -0700 Subject: [LLVMdev] Compiling LLVM 2.7 with Visual Studio 2010. In-Reply-To: References: Message-ID: K, last one..... Global search and replace in LLVM and Clang for NULL -> nullptr, and a couple of locations where 0 is used instead of a nullptr, makes both compile. Apart from the errors I mentioned earlier about the private/public method, and the setjmp related stuff. Not sure if it compiles with any other compiler now, so I won't be submitting this null->nullptr change, but the other errors might be worth taking... Tom. On Sat, May 1, 2010 at 10:09 PM, Tom van Dijck wrote: > > > On Sat, May 1, 2010 at 10:02 PM, me22 wrote: > >> On 2 May 2010 00:53, Tom van Dijck wrote: >> > The problem seems to be a much larger issue with the Visual Studio 2010 >> C++ >> > Compiler and not really related to clang/llvm. The following snippet of >> code >> > does NOT compile in 2010.. >> > >> > #include >> > int main(int argc, char* argv[]) >> > { >> > std::pair mypair(0, NULL); >> > return 0; >> > } >> > >> >> That's perfectly fine -- it never #includes , >> so there's no reason for std::pair to be in scope. >> > > #include > int main(int argc, char* argv[]) > { > std::pair mypair(0, (void*)NULL); > > return 0; > } > > compiles fine though... > couple people have reported the same issue actually, and apparently this is > by design due to C++0x: > > > https://connect.microsoft.com/VisualStudio/feedback/details/520043/error-converting-from-null-to-a-pointer-type-in-std-pair?wa=wsignin1.0#tabs > > Tom. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100501/cbc54f0e/attachment.html From clattner at apple.com Sun May 2 00:35:16 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 1 May 2010 22:35:16 -0700 Subject: [LLVMdev] Adding a halting function attribute? In-Reply-To: <9A0BC3E3-58D1-4461-A942-8DBD344EF13F@apple.com> References: <20100501171938.80516312800A@llvm.org> <3C5E4CAF-E189-4BBD-BAB9-B1AB61BC7C90@mac.com> <9A0BC3E3-58D1-4461-A942-8DBD344EF13F@apple.com> Message-ID: <5AAB0F42-04FF-4872-9CCB-77F275655D2B@apple.com> On May 1, 2010, at 11:19 AM, Chris Lattner wrote: > > On May 1, 2010, at 11:07 AM, Owen Anderson wrote: > >> Hey folks, >> >> In a recent blog post, John Regehr pointed out that LLVM is currently optimizing away read-only functions containing infinite loops whose return values are never used. The culprit for the moment is the inliner, but the more insidious problem is that isTriviallyDeletable currently returns true for any read-only function whose value is not used. >> >> In order to prevent this from happening while avoiding pessimizing the common case, I'm proposing adding a "halting" function attribute which is a hint to the optimizers that a function is guaranteed to halt. A pretty simple conservative implementation would be as a "contains no loops" analysis. Obviously fancier implementations are possible, but we'd like to avoid having the FunctionAttrs depend on LoopInfo or SCEV which would be needed for loop finiteness analysis. Additionally, we already have the LoopDeletion pass interleaved, which should handle exactly those cases anyways. > > Two (more) problems: > > 1) You have to prove that infinite recursion (which might be tail calls) doesn't happen. This means that anything that does an indirect call has to be assumed to not be halting. > > 2) You'd have to update all the builtins to say they are halting, because they are external functions. > > 3) This adds (even more) clutter to the IR. :( On reflection, perhaps this isn't so bad. This really only matters when the compiler is able to infer readnone/readonly, which typically doesn't include cases with indirect calls. Per #2, I think it could be handled by making the GCC-style pure/const attributes imply both readonly/readnone *and* halting. -Chris From rgoparaj at umail.iu.edu Sun May 2 00:42:01 2010 From: rgoparaj at umail.iu.edu (Rohith Goparaju) Date: Sun, 2 May 2010 01:42:01 -0400 Subject: [LLVMdev] Unreachable Executed error. In-Reply-To: References: Message-ID: The verifier pass is running after my pass completes. If the transformed code is not well-formed the module should break ideally, but it is not throwing an error during that pass. I can paste the stack dump if that helps. UNREACHABLE executed! 0 opt 0x000000000076cadf 1 opt 0x000000000076d118 2 libpthread.so.0 0x00007f1c51a6bef0 3 libc.so.6 0x00007f1c50b83665 gsignal + 53 4 libc.so.6 0x00007f1c50b84b83 abort + 387 5 opt 0x0000000000755dd8 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 344 6 opt 0x0000000000682f32 7 opt 0x0000000000684a8b 8 opt 0x0000000000686867 9 opt 0x0000000000686d1d llvm::WriteBitcodeToFile(llvm::Module const*, llvm::raw_ostream&) + 221 10 opt 0x000000000067f2fc 11 opt 0x000000000070cb45 llvm::MPPassManager::runOnModule(llvm::Module&) + 453 12 opt 0x000000000070cdb9 llvm::PassManagerImpl::run(llvm::Module&) + 105 13 opt 0x000000000048d6c1 main + 1313 14 libc.so.6 0x00007f1c50b6fa26 __libc_start_main + 230 15 opt 0x0000000000483a79 Stack dump: 0. Running pass 'Bitcode Writer' on module ''. Aborted Thanks, Rohith. On Sun, May 2, 2010 at 1:12 AM, Reid Kleckner wrote: > Run the verifier pass after your pass. The bitcode readers and > writers assume that the IR is well-formed, which yours may not be. > > Reid > > On Sun, May 2, 2010 at 1:08 AM, Rohith Goparaju > wrote: > > Hi, > > > > I've written a pass that basically does some code transformations to > > enable parallel execution. After the transformation llvm runs BitCode > Writer > > pass , which is aborting with Unreachable Executed error. What does this > > error generally mean?. > > Any pointers on how to go about debugging this. > > > > Thanks, > > Rohith. > > > > _______________________________________________ > > 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/20100502/a4fcbe76/attachment.html From ayoga at umail.iu.edu Sun May 2 01:17:46 2010 From: ayoga at umail.iu.edu (Adarsh Yoga) Date: Sun, 2 May 2010 02:17:46 -0400 Subject: [LLVMdev] Function insertion Message-ID: Is there a way to insert a function at the start of a module rather than inserting it at the end, which happens by default? -- Adarsh Yoga Graduate Student, Computer Science Indiana University, Bloomington -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/30f9e9d4/attachment.html From echristo at apple.com Sun May 2 01:26:16 2010 From: echristo at apple.com (Eric Christopher) Date: Sat, 1 May 2010 23:26:16 -0700 Subject: [LLVMdev] Function insertion In-Reply-To: References: Message-ID: <5555F6ED-1365-4552-A3CC-10D0939D2140@apple.com> On May 1, 2010, at 11:17 PM, Adarsh Yoga wrote: > Is there a way to insert a function at the start of a module rather than inserting it at the end, which happens by default? Maybe, but... why? -eric From etherzhhb at gmail.com Sun May 2 02:06:51 2010 From: etherzhhb at gmail.com (ether zhhb) Date: Sun, 2 May 2010 15:06:51 +0800 Subject: [LLVMdev] Compiling LLVM 2.7 with Visual Studio 2010. In-Reply-To: References: Message-ID: hi, On Sun, May 2, 2010 at 1:34 PM, Tom van Dijck wrote: > K, last one..... > > Global search and replace in LLVM and Clang for NULL -> nullptr, and a > couple of locations where 0 is used instead of a nullptr, makes both > compile. > Maybe we should define something like #ifdef VS2010 #undef NULL #define NULL nullptr #end in llvm/Support/Compiler.h best regards --ether -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/c1d4bfe8/attachment.html From edwintorok at gmail.com Sun May 2 02:13:28 2010 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sun, 02 May 2010 10:13:28 +0300 Subject: [LLVMdev] Compiling LLVM 2.7 with Visual Studio 2010. In-Reply-To: References: Message-ID: <4BDD2618.80100@gmail.com> On 05/02/2010 06:57 AM, Tom van Dijck wrote: > Last there is a gazillion errors around the fact that Microsoft for some > crazy stupid reason has defined setjmp to _setjmp, and thus the > generated intrinsics.gen goes completely insane everywhere. I'm sure > this is a legacy thing in visual studios libraries, but wow... In LowerInvoke.cpp change this: #if defined(_MSC_VER) && defined(setjmp) #define setjmp_undefined_for_visual_studio #undef setjmp #endif to this: #if defined(_MSC_VER) && defined(setjmp) && _MSC_VER < 600 #define setjmp_undefined_for_visual_studio #undef setjmp #endif Apparently setjmp IS defined to _setjmp everywhere, so if we don't undef it, everything "just works". There was also an error about next() being ambigous in one file (don't remember which one right now), changing that to llvm::next() worked. As for the null pointer issue, I only encountered it in 2 places in llvm, an explicit cast of 0, or a helper variable of the correct type helped. > > Anyway, my solution to this was to make a 'intrinsics.gen.proxy', which > undefs that macro and then includes the intrinsics.gen, and then all > includes to intrinsics.gen, I modified to include the proxy. This > guarantees that at least the Instrinsic namespace is always setup > correctly... and you're left with a couple other files where it still > seems to be defined, so I just undef'ed it for the whole file in those > files as well... > > Is there any interest in these changes applied to trunk? and if so how > do I proceed... I'm fine keeping these changes local and integrate, but > I figure there is more users out there wanting to move to VS2010 at some > point. Yes please apply to trunk if it doesn't break anything, and if the changes aren't too big (I don' think you need to replace all 0 with null, just the ones that cause problems). Best regards, --Edwin From aaronngray.lists at googlemail.com Sun May 2 02:40:59 2010 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Sun, 2 May 2010 08:40:59 +0100 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: On 2 May 2010 00:59, Nathan Jeffords wrote: > Hi All, > > I have created a minimally functional Win32 COFF Exporter using the new MC > framework. I made some minor changes to other libraries to allow me to plug > it in without building it as part of the LLVM project. I wanted to share it > but wasn't sure how to go about doing so, so I have attached the code to > this message. > > Any feedback on would be appreciated. > Hi Nathan, A couple of points :- 1) Your code seems incomplete, there is nothing envoking 'createWin32CoffStreamer()' in you patch. 2) You need to look at LLVM coding standards, i.e. maximum line length of 80 characters and tabs of 2. You need to look at the following document and existing code. Usage of spaces is quite strict. http://llvm.org/docs/CodingStandards.html I too have been working on a COFFWriter but with little success. Got a basic COFFWriter working but have had problems with the MC framework in regards to getting the right information to generate code properly. It will be good if we can get something working first, so send me a proper change set, read this :- http://llvm.org/docs/DeveloperPolicy.html I generally use :- utils/mkpatch patchname from the root svn directory with out the '.patch' to make patches. You need to include any files from 'svn status' with question marks, by doing an 'svn add filename'. Thanks for submitting a patch, most patches are welcomed, but they may need to be honed a bit. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/f52bd776/attachment.html From baldrick at free.fr Sun May 2 03:33:24 2010 From: baldrick at free.fr (Duncan Sands) Date: Sun, 02 May 2010 10:33:24 +0200 Subject: [LLVMdev] Adding a halting function attribute? In-Reply-To: <5AAB0F42-04FF-4872-9CCB-77F275655D2B@apple.com> References: <20100501171938.80516312800A@llvm.org> <3C5E4CAF-E189-4BBD-BAB9-B1AB61BC7C90@mac.com> <9A0BC3E3-58D1-4461-A942-8DBD344EF13F@apple.com> <5AAB0F42-04FF-4872-9CCB-77F275655D2B@apple.com> Message-ID: <4BDD38D4.4060604@free.fr> >> 1) You have to prove that infinite recursion (which might be tail calls) doesn't happen. This means that anything that does an indirect call has to be assumed to not be halting. >> >> 2) You'd have to update all the builtins to say they are halting, because they are external functions. >> >> 3) This adds (even more) clutter to the IR. :( > > On reflection, perhaps this isn't so bad. This really only matters when the compiler is able to infer readnone/readonly, which typically doesn't include cases with indirect calls. Per #2, I think it could be handled by making the GCC-style pure/const attributes imply both readonly/readnone *and* halting. Heh - I was just about to make these points myself :) Ciao, Duncan. From anton at korobeynikov.info Sun May 2 04:53:05 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Sun, 2 May 2010 13:53:05 +0400 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: Hello, Nathan First of all, I would like to mention that COFF MC backend will be a really good contribution to LLVM! > I have created a minimally functional Win32 COFF Exporter using the new MC > framework. I made some minor changes to other libraries to allow me to plug > it in without building it as part of the LLVM project. I wanted to share it > but wasn't sure how to go about doing so, so I have attached the code to > this message. > Any feedback on would be?appreciated. As it was already mentioned before you should definitely read & follow LLVM coding standards. I'll let others comment on MC hooks, I just made a very brief look over the contents of the archive. You can find the comments below. First of all, please include all the files as attachments. If you decide to put stuff into archive use something standard, e.g. .zip or .tar.gz. coff.h: Please document the source of the information for this file - some documents, links will be really good. If you copied stuff out of somewhere - there should be some license disclaimer, etc. > #pragma once Use standard include guards > typedef unsigned char uint8; > typedef unsigned short uint16; > typedef unsigned long uint32; Do not reinvent the wheel - use standard portable types e.g. uint8_t and friends. "unsigned long" is not 32 bit everywhere. > #pragma pack (push, 1) Do not use these pragma's. Not all compilers support them. > struct symbol Could you please add the comments describing the entities involved? > typedef std::map map; Please read http://llvm.org/docs/ProgrammersManual.html and use the data structures already provided by LLVM. E.g. http://llvm.org/docs/ProgrammersManual.html#dss_stringmap should definitely be used here. > #ifdef _MSC_VER > #include "stdafx.h" > #endif > #define report_fatal_error_dbg(x) __debugbreak () Generally it's prohibited to use target/compiler-specific defines outside of libSystem. > struct MCWin32CoffObjectWriter : > MCObjectWriter, > coff::file Any reason for such inheritance? > MCSectionCOFF const & Section = dynamic_cast (SectionData.getSection ()); LLVM normally compiles w/o RTTI, so this won't work > CoffSection->Header.Characteristics |= > coff::IMAGE_SCN_CNT_CODE | > coff::IMAGE_SCN_MEM_READ | > coff::IMAGE_SCN_MEM_EXECUTE | > false; Was "| false" intentional? Why? > default: > report_fatal_error_dbg ("unsupported section alignment"); Use llvm_unreachable() > for (SmallVector::const_iterator i = Data.begin (); i != Data.end (); i++) > { > if (i != Data.begin ()) > dbgout (' '); See llvm/Support/Debug.h for standard way of doing debug output in LLVM code. There are bunch of examples in many places. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From aaronngray.lists at googlemail.com Sun May 2 07:12:04 2010 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Sun, 2 May 2010 13:12:04 +0100 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: On 2 May 2010 10:53, Anton Korobeynikov wrote: > Hello, Nathan > I'll let others comment on MC hooks, I just made a very brief look > over the contents of the archive. You can find the comments below. > Yes I looked at this and there are several ways but TargetAsmBackend looked the bast place to deal with the MCStreamer choice for different TargetTriples. > for (SmallVector::const_iterator i = > Data.begin (); i != Data.end (); i++) > > { > > if (i != Data.begin ()) > > dbgout (' '); > See llvm/Support/Debug.h for standard way of doing debug output in > LLVM code. There are bunch of examples in many places. See :- http://llvm.org/docs/ProgrammersManual.html#DEBUG Also trailing commas on enums cause errors on GCC. There are more errors on GCC as well which I will forward you ASAIC. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/769a0999/attachment.html From clattner at apple.com Sun May 2 09:22:35 2010 From: clattner at apple.com (Chris Lattner) Date: Sun, 2 May 2010 07:22:35 -0700 Subject: [LLVMdev] Function insertion In-Reply-To: References: Message-ID: <780018B3-B7BB-42D2-AD44-7ED70A011480@apple.com> On May 1, 2010, at 11:17 PM, Adarsh Yoga wrote: > Is there a way to insert a function at the start of a module rather than inserting it at the end, which happens by default? You can create the function without specifying the module to insert into, then use M.getFunctionList().insert(..) to put it wherever you like. -Chris From regehr at cs.utah.edu Sun May 2 11:32:24 2010 From: regehr at cs.utah.edu (John Regehr) Date: Sun, 2 May 2010 10:32:24 -0600 (MDT) Subject: [LLVMdev] Adding a halting function attribute? In-Reply-To: <5AAB0F42-04FF-4872-9CCB-77F275655D2B@apple.com> References: <20100501171938.80516312800A@llvm.org> <3C5E4CAF-E189-4BBD-BAB9-B1AB61BC7C90@mac.com> <9A0BC3E3-58D1-4461-A942-8DBD344EF13F@apple.com> <5AAB0F42-04FF-4872-9CCB-77F275655D2B@apple.com> Message-ID: > On reflection, perhaps this isn't so bad. This really only matters when > the compiler is able to infer readnone/readonly, which typically doesn't > include cases with indirect calls. Per #2, I think it could be handled > by making the GCC-style pure/const attributes imply both > readonly/readnone *and* halting. This sounds right to me. John From viridia at gmail.com Sun May 2 12:13:08 2010 From: viridia at gmail.com (Talin) Date: Sun, 2 May 2010 10:13:08 -0700 Subject: [LLVMdev] Using gcroot with value types In-Reply-To: <4BDBEFAC.5080700@assumetheposition.nl> References: <36426.145.100.6.164.1272267889.squirrel@www.assumetheposition.nl> <4BD88990.6080304@assumetheposition.nl> <4BDBEFAC.5080700@assumetheposition.nl> Message-ID: On Sat, May 1, 2010 at 2:09 AM, Paul Melis wrote: > On 04/29/10 21:27, Talin wrote: > > On Wed, Apr 28, 2010 at 12:16 PM, Paul Melis wrote: > >> On 04/27/10 00:20, Talin wrote: >> >> On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis wrote: >> >>> Hi, >>> >>> Talin wrote: >>> > I'm a little confused as to the rules for the arguments to llvm.gcroot, >>> > which says it must be a pointer alloca. I'm not sure whether that means >>> it >>> > must be an alloca (which is always a pointer by definition) or an >>> alloca >>> > *of* a pointer. >>> >>> I'm pretty sure it should be "alloca of a pointer", as the first argument >>> of llvm.gcroot has type i8**. >>> >>> However, http://llvm.org/docs/GarbageCollection.html#gcroot, isn't >>> completely clear on this: >>> >>> "The first argument must be a value referring to an alloca instruction or >>> a bitcast of an alloca." >>> >>> This last sentence seems to rule out passing GEPs on alloca's to >>> llvm.gcroot. >>> >>> > What I am trying to figure out is how to declare roots contained in >>> value >>> > types. Suppose for example I have a small struct which contains several >>> > garbage-collectable references. This struct is a local variable, so >>> it's >>> > contained in a block of memory which has been allocated via alloca. >>> Now, I >>> > don't want to add the struct itself as a root, since it isn't allocated >>> on >>> > the heap. But I want to declare the fields within the struct - which >>> are >>> > GEPs from the alloca pointer - as roots, since they are references to >>> > objects on the heap. >>> >>> As reasonable as the above sounds, I don't think you can mark roots >>> contained in structs. But if I'm wrong I'd love to know ;-) Perhaps you >>> can ask the LDC devs how/if they handle this case, as it seems you can >>> allocate a class instance on the stack in D. >>> >>> Ugh. If all roots have to be singleton pointers, not embedded within a >> larger structure, then I'm not sure that what I want to do is even possible. >> >> In principle you could probably mark the alloca's of your value structs >> as gcroots. Then during collection you would have to make sure you recognize >> the value types so you don't move/deallocate/... them during a collection. >> That would still give you the option to trace all live objects by simply >> traversing the fields of a value struct. You would only have to do this for >> value structs (indirectly) containing references. Does that make sense? >> > > Unfortunately, when I try to do this, the function verifier reports the > function as broken. It requires that the argument to llvm.gcroot be a > pointer to an alloca of a pointer. I can't fool it with casts. > > Oops, I wasn't specific enough. Marking an alloca of a value type indeed > won't work, as you noticed. Put differently, the idea is that value types > and heap types are treated the same w.r.t. marking them with gcroot, while > the former is allocated using alloca and the latter with your GC allocation > routine. It's only during collection that you have to make sure not to > collect value types. > > // Some value type > %struct.V = type { i32, float, i8* } > > // Allocate space for a pointer to a V instance, which we mark as GC root > %v = alloca %struct.V*, align 8 ; <%struct.V**> [#uses=2] > %0 = bitcast %struct.V** %v to i8** ; [#uses=1] > call void @llvm.gcroot(i8** %0, i8* null) > > // Allocate the V instance on the stack and store it's address in the > root > %1 = alloca %struct.V, align 4 ; <%struct.V*> [#uses=3] > store %struct.V* %1, %struct.V** %v, align 8 > > I guess that will work, although I'm not happy about having to allocate an extra pointer for every value type. But that will work for now. The collection part is trivial, since in my scheme the metadata argument to gcroot is always null for reference types (since they are tagged), and non-null for value types (since they are not.) > Paul > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/9324d46c/attachment.html From samuraileumas at yahoo.com Sun May 2 12:45:06 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Sun, 2 May 2010 10:45:06 -0700 (PDT) Subject: [LLVMdev] Generic target? Message-ID: <222994.40935.qm@web62006.mail.re1.yahoo.com> Hello LLVM list, I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to have the alignment information or endianness until the final link stage at install time. Here's the build process currently: 1. The parser is built using LLVM-PEG parser generator which doesn't specify a target. It exports bitcode successfully. 2. The linker library used by the parser code and the main code completes the compiler bitcode thus creating a nearly complete compiler using LLVM-Link. 3. At install time system specific LibC wrapper written in C and compiled with Clang is linked to the incoming bitcode file with LLVM-Link. 4. Opt is invoked on it for LTO. 5. LLC converts the code to Assembly source. 6. The source is now assembled and linked to the real LibC calls contained in the LibC wrapper and the GLibC++ calls to satisfy the linker library are also linked in. 7. Execution reveals a core-dump due to a file handle being converted to a NULL for some reason. As for step 7, I'd prefer that execution would reveal a "hello world" output to indicate that our code was working. :-) Since the LibC wrapper is such simple code I doubt that it's truly to blame so I'm left at a loss to explain it except that the endianness and aligment characteristics of the linker library written using LLVM-C++ are embedded in the bitcode files too soon to allow generic linking. The goal is to produce an endian-agnostic alignment-neutral bitcode in steps 1 and 2. How far away is this in the LLVM side and what can be done to help with a generic target? Links: http://sourceforge.net/projects/llvmpeg/ is the project page for LLVM-PEG. (Code is in SVN repository. Click develop tab to access the SVN browser.) http://sourceforge.net/projects/llvmlibc/ is the project page for LLVM-LibC wrapper. (Code is in SVN repository.) Thanks for your time, --Sam Crow From blunted2night at gmail.com Sun May 2 13:32:38 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Sun, 2 May 2010 11:32:38 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: Thanks for both of your feedback, I will attempt to make it fit LLVM coding standards better before I resubmit my work. As far as the hooks I put in, they are really only there so I could build the object exporter outside of LLVM, I think having it built directly in like others is preferable in the end. I do think it would be useful if projects had the option of extending supported formats without having to modify LLVM itself, but my changes main goal was minimal impact on LLVM sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/77a98c24/attachment.html From aaronngray.lists at googlemail.com Sun May 2 15:47:48 2010 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Sun, 2 May 2010 21:47:48 +0100 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: On 2 May 2010 19:32, Nathan Jeffords wrote: > Thanks for both of your feedback, I will attempt to make it fit LLVM coding > standards better before I resubmit my work. You can send me early drafts to run past GCC, send me something that works. As far as the hooks I put in, they are really only there so I could build > the object exporter outside of LLVM, I think having it built directly in > like others is preferable in the end. I do think it would be useful if > projects had the option of extending supported formats without having to > modify LLVM itself, but my changes main goal was minimal impact on LLVM > sources. > AFAICT The hooks you sent did not call your code at all. Have a look at the MachOWriter, this is designed to be extendable to other writers. The MCStreamer stuff just needs the same doing probably in TargetAsmBackend. It would be good to have this as a separate patch. This will allow both COFFWriter and ELFWriter as well as the MachOWriter to coexist and be selected by TargetTriple. BTW could you have your Writer and Streamer in different source code files, and follow the MachO code format as far as is possible/reasonable. JTFYI The COFF code I have written consists of Reader and Writer of COFF internal object modules to/from COFF format. I am looking at producing a linker with the addition of a PE Writer class, and Library Reader class. This should then make LLVM and CLANG more independant on the Windows Platform. I have a COFF Dumper class too which works with the reader and the internal Object Module format. Regards, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/79f70e64/attachment.html From blunted2night at gmail.com Sun May 2 17:40:58 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Sun, 2 May 2010 15:40:58 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: On Sun, May 2, 2010 at 1:47 PM, Aaron Gray wrote: > On 2 May 2010 19:32, Nathan Jeffords wrote: > >> Thanks for both of your feedback, I will attempt to make it fit LLVM >> coding standards better before I resubmit my work. > > > You can send me early drafts to run past GCC, send me something that works. > I will test against GCC on my ubuntu virtual machine. > > As far as the hooks I put in, they are really only there so I could build >> the object exporter outside of LLVM, I think having it built directly in >> like others is preferable in the end. I do think it would be useful if >> projects had the option of extending supported formats without having to >> modify LLVM itself, but my changes main goal was minimal impact on LLVM >> sources. >> > > AFAICT The hooks you sent did not call your code at all. > > The hooks I put in place allow my compiler to specify its own MCStreamer factory function that TargetMachine::addPassesToEmitFile calls when its time to create the streamer object. I also made MCAssembler use a virtual function to construct the MCObjectWriter which I then override in my streamer to make it construct my object writer. To me, this was important to allow the streamer & object writer to be built as part of my compiler and not require me to run a build of LLVM every time I changed something. This aproach also allows me to keep this code in source control as I bounce between development machines multiple times a day. > Have a look at the MachOWriter, this is designed to be extendable to other > writers. The MCStreamer stuff just needs the same doing probably in > TargetAsmBackend. It would be good to have this as a separate patch. This > will allow both COFFWriter and ELFWriter as well as the MachOWriter to > coexist and be selected by TargetTriple. BTW could you have your Writer and > Streamer in different source code files, and follow the MachO code format as > far as is possible/reasonable. > I have already re-factored the code a bit to better fit LLVM coding standard. The writer & streamer are now two different source files, and code for the coff::file class has been moved directly into the writer instead of multiply inheriting from it. > > JTFYI The COFF code I have written consists of Reader and Writer of COFF > internal object modules to/from COFF format. I am looking at producing a > linker with the addition of a PE Writer class, and Library Reader class. > This should then make LLVM and CLANG more independant on the Windows > Platform. I have a COFF Dumper class too which works with the reader and the > internal Object Module format. > > Some time ago, I wrote a simple COFF based linker that would link into series of object files into a memory buffer then write out the linked and loaded image to a bin file for use with a OS project I was playing around with. I revived it to help me test some problems I was having with relocations. Perhaps some of that code could be useful. hopefully, I can have a version that will compile as part of LLVM later today Thanks, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/0ed77a77/attachment.html From blunted2night at gmail.com Mon May 3 00:47:51 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Sun, 2 May 2010 22:47:51 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: I cleaned up my code a bit, and integrated into the LLVM sources. While this code works for my purposes, it needs a bit more work before its generally useful. Two aspects I think will cause the most trouble are not having support for uninitialized data sections, and common symbols. Uninitialized data sections should be relatively simple to add, but its not clear to me how common symbols should be implemented. For normal symbols, I assume they are contained within the current section. >From what I understand, COFF common symbols must be in their own section. It can't tell if it is guaranteed that MCStreamer::SwitchSection will be called after the emission of a common symbol thus giving the exporter an opportunity to switch back to the section for normal symbols. On the other hand, there is a section pointer associated with the symbol, if this is reliable, what is the need for MCStreamer::SwitchSection, is it (or should it be) possible to emit data or code not tied to a symbol? - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/784626e2/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: win32coff.patch Type: application/octet-stream Size: 30467 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100502/784626e2/attachment.obj From stoklund at 2pi.dk Mon May 3 11:51:58 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Mon, 3 May 2010 09:51:58 -0700 Subject: [LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions In-Reply-To: References: <4D8BA08A-ACAB-4323-81BE-E32A1CE17711@apple.com> Message-ID: <10BE4981-C6F7-4C9F-A00D-CEB174B52F4E@2pi.dk> On Apr 29, 2010, at 2:06 PM, Villmow, Micah wrote: > Ping. Anyone have any idea on how to fix this? Does your getAllocatableSet() return a BitVector that is at least getNumRegs() bits long? Otherwise this doesn't work: BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); NonAllocatableRegs.flip(); From dag at cray.com Mon May 3 11:54:10 2010 From: dag at cray.com (David Greene) Date: Mon, 3 May 2010 11:54:10 -0500 Subject: [LLVMdev] Register Allocation: Interference graph In-Reply-To: <4BDC2DFA.6090903@zapster.cc> References: <4BDC2DFA.6090903@zapster.cc> Message-ID: <201005031154.10692.dag@cray.com> On Saturday 01 May 2010 08:34:50 Josef Eisl wrote: > Hello, > > I want learn more about register allocation and do some analysis for a > current research project. After reading some papers (eg. Chaitin, > Briggs) I think its time to get my hands dirty :). Welcome! > First I plan to (re)implement some of the classic approaches to get > familiar with the framework. Before doing that, can you describe your research a bit? A number of people (include me!) have done graph-coloring style register allocators for LLVM/x86 and not found much benefit over the existing "linear scan" scheme (in quotes because it's not actually linear scan anymore :)). It might be better to use your time to investigate other algorithms. If all you want to do right now is get familiar with the framework, there are simpler algorithms than graph coloring. > At the beginning the following questions came up: > > - Is there some documentation about register allocation in LLVM? http://llvm.org/docs/CodeGenerator.html http://llvm.org/docs/CodeGenerator.html#regalloc These are essential to read. A lot of details are missing which requires one to just get down into the code and start hacking but this document helps with understanding the broad picture. > - As far as I understand it, register allocators are implemented as > MachineFunctionPasses. Does a MachineFunction object contain all > information needed for a (classic) allocator? It has the instructions, operands and dependencies among them. There's a LiveInvervalAnalysis pass which you'll probably also need. That should be enough to get going. > - Is there already a pass that prints interference graph (Chaitin et al. > 1981) or something similar like opt -view-cfg prints a CFG? If not, is > it even possible with the current LLVM infrastructure? There's not one in trunk. When I did this I used Boost.Graph as the representation and relied on its ability to dump GraphViz files for visualization. You can also specialize LLVM's GraphTraits for your particular graph representation and get much the same thing. You'll need to add your own command-line options to display pretty pictures, of course. > - Is there an LLVM register allocator that uses graph coloring or > something similar? Not in trunk. Here's a message I looked at when I did mine: http://www.mail-archive.com/llvm-commits at cs.uiuc.edu/msg10962.html It's pretty stale at this point. It won't apply to trunk. Just use it as a guide to get started. > - Which LLVM allocator would you recommend to look into to get the basic > ideas how to use the framework? LinearScan is the only one widely used, AFAIK. There are some simpler allocators as well (local, simple). PBQP is cool but I don't know much about it. -Dave From hao.shen at imag.fr Mon May 3 11:12:33 2010 From: hao.shen at imag.fr (SHEN Hao) Date: Mon, 3 May 2010 18:12:33 +0200 Subject: [LLVMdev] How can I remove Intrinsic Functions during llvm-gcc compilation? Message-ID: Hi, all, I am using llvm-gcc --emit-llvm to generate byte code. With llvm readable ll format, I found some standard C library function such as llvm.memset. In fact, I'm trying to compile newlibc with llvm, I do not need this kind of llvm functions. How can I remove them during the compilation? Best regards, -- Hao Shen From Micah.Villmow at amd.com Mon May 3 12:21:47 2010 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Mon, 3 May 2010 12:21:47 -0500 Subject: [LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions In-Reply-To: <10BE4981-C6F7-4C9F-A00D-CEB174B52F4E@2pi.dk> References: <4D8BA08A-ACAB-4323-81BE-E32A1CE17711@apple.com> <10BE4981-C6F7-4C9F-A00D-CEB174B52F4E@2pi.dk> Message-ID: Jakob, Here is my implementation of getAllocatableSet: BitVector AMDILRegisterInfo::getAllocatableSet(const MachineFunction& MF, const TargetRegisterClass *RC = NULL) const { BitVector Allocatable(getNumRegs()); Allocatable.clear(); return Allocatable; } Micah -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Monday, May 03, 2010 9:52 AM To: Villmow, Micah Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions On Apr 29, 2010, at 2:06 PM, Villmow, Micah wrote: > Ping. Anyone have any idea on how to fix this? Does your getAllocatableSet() return a BitVector that is at least getNumRegs() bits long? Otherwise this doesn't work: BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); NonAllocatableRegs.flip(); From vladimir at acm.org Mon May 3 12:43:15 2010 From: vladimir at acm.org (Vladimir G. Ivanovic) Date: Mon, 03 May 2010 10:43:15 -0700 Subject: [LLVMdev] `make check' failures in r102924 Message-ID: <4BDF0B33.6070808@acm.org> I successfully built LLVM (r102824) with ./configure --enable-optimized --enable-targets=host --with-built-clang on Fedora 12 on an Athlon64 processor. (The clang is the 2.7 pre-built version.) However, running `make check' produced 6 unexpected failures (see below). If there's something you'd like me to do, just holler. --- Vladimir FAIL: /usr/local/src/llvm/test/Bindings/Ocaml/vmcore.ml Failed with exit(10) at line 2 while running: ./vmcore.ml.tmp vmcore.ml.tmp.bc FAILED: builder/builder/dbg #1 FAIL: /usr/local/src/llvm/test/FrontendC/crash-invalid-array.c for PR6913 Failed with exit(1) at line 1 while running: not /usr/local/llvm-gcc4.2-2.7-x86_64-linux/bin/llvm-gcc -emit-llvm -w -O1 /usr/local/src/llvm/test/FrontendC/crash-invalid-array.c -S |& /bin/grep {error: invalid use of array with unspecified bounds} child process exited abnormally FAIL: /usr/local/src/llvm/test/FrontendC/inline-asm-function.c Failed with exit(1) at line 1 while running: /usr/local/llvm-gcc4.2-2.7-x86_64-linux/bin/llvm-gcc -emit-llvm -w -S /usr/local/src/llvm/test/FrontendC/inline-asm-function.c -fasm-blocks -o - -O | /bin/grep naked child process exited abnormally Running /usr/local/src/llvm/test/FrontendC++/dg.exp ... FAIL: /usr/local/src/llvm/test/FrontendC++/2010-02-17-DbgArtificialArg.cpp Failed with exit(1) at line 1 while running: /usr/local/llvm-gcc4.2-2.7-x86_64-linux/bin/llvm-gcc -emit-llvm -w -g -S /usr/local/src/llvm/test/FrontendC++/2010-02-17-DbgArtificialArg.cpp -o - | /bin/grep DW_TAG_pointer_type | /bin/grep "i32 524303, metadata .., metadata ..., metadata .., i32 ., i64 .., i64 .., i64 0, i32 64, metadata ..." child process exited abnormally FAIL: /usr/local/src/llvm/test/FrontendC++/2010-03-22-empty-baseclass.cpp Failed with exit(1) at line 1 while running: /usr/local/llvm-gcc4.2-2.7-x86_64-linux/bin/llvm-gcc -emit-llvm -w -S -emit-llvm /usr/local/src/llvm/test/FrontendC++/2010-03-22-empty-baseclass.cpp -o - -O2 | FileCheck /usr/local/src/llvm/test/FrontendC++/2010-03-22-empty-baseclass.cpp /usr/local/src/llvm/test/FrontendC++/2010-03-22-empty-baseclass.cpp:134:11: error: expected string not found in input // CHECK: ret i32 ^ :1:1: note: scanning from here ; ModuleID = '/usr/local/src/llvm/test/FrontendC++/2010-03-22-empty-baseclass.cpp' ^ :14:5: note: possible intended match here declare i32 @puts(i8* nocapture) nounwind ^ FAIL: /usr/local/src/llvm/test/FrontendC++/2010-04-30-OptimizedMethod-Dbg.cpp Failed with exit(1) at line 2 while running: grep "i1 false, i1 true. . . DW_TAG_subprogram" 2010-04-30-OptimizedMethod-Dbg.cpp.tmp | count 2 Expected 2 lines, got 0. -- Vladimir G. Ivanovic http://www.leonora.org +1 650 450 4101 vladimir at acm.org -------------- 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/20100503/1bdd9feb/attachment.bin From stoklund at 2pi.dk Mon May 3 12:58:32 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Mon, 3 May 2010 10:58:32 -0700 Subject: [LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions In-Reply-To: References: <4D8BA08A-ACAB-4323-81BE-E32A1CE17711@apple.com> <10BE4981-C6F7-4C9F-A00D-CEB174B52F4E@2pi.dk> Message-ID: <2455C1C2-0CA2-4186-82E4-95010F452B3C@2pi.dk> On May 3, 2010, at 10:21 AM, Villmow, Micah wrote: > Jakob, > Here is my implementation of getAllocatableSet: > BitVector > AMDILRegisterInfo::getAllocatableSet(const MachineFunction& MF, > const TargetRegisterClass *RC = NULL) const > { > BitVector Allocatable(getNumRegs()); > Allocatable.clear(); > return Allocatable; > } Well, there's your problem. BitVector::clear() resets the size to 0, and callers of getAllocatableSet expect a bit per physical register. Please add an assert(NonAllocatableRegs.size() >= TRI->getNumRegs()) to DeadMachineInstructionElim. /jakob From devang.patel at gmail.com Mon May 3 13:09:07 2010 From: devang.patel at gmail.com (Devang Patel) Date: Mon, 3 May 2010 11:09:07 -0700 Subject: [LLVMdev] PR4174 In-Reply-To: <7667FAA5-DC0A-4CF8-A92C-38261E7C6D80@gcc.gnu.org> References: <7667FAA5-DC0A-4CF8-A92C-38261E7C6D80@gcc.gnu.org> Message-ID: On Sat, May 1, 2010 at 8:07 AM, Jakub Staszak wrote: > Hello again :) > > After some break I send patch for PR4174. It was proposed some time ago, this one works with trunk. Looks good. Applied. r102928. Thanks! - Devang From dalej at apple.com Mon May 3 13:13:47 2010 From: dalej at apple.com (Dale Johannesen) Date: Mon, 3 May 2010 11:13:47 -0700 Subject: [LLVMdev] `make check' failures in r102924 In-Reply-To: <4BDF0B33.6070808@acm.org> References: <4BDF0B33.6070808@acm.org> Message-ID: <9AC17D1D-4979-460D-B7A9-5604C0670AA7@apple.com> On May 3, 2010, at 10:43 AMPDT, Vladimir G. Ivanovic wrote: > I successfully built LLVM (r102824) with > > ./configure --enable-optimized --enable-targets=host --with-built-clang > > on Fedora 12 on an Athlon64 processor. (The clang is the 2.7 pre-built > version.) and the llvm-gcc appears to be also? > However, running `make check' produced 6 unexpected failures > (see below). If there's something you'd like me to do, just holler. In general, tests added after a branch forked won't pass on that branch. That accounts for these at least: > FAIL: /usr/local/src/llvm/test/FrontendC/inline-asm-function.c > Failed with exit(1) at line 1 > while running: /usr/local/llvm-gcc4.2-2.7-x86_64-linux/bin/llvm-gcc > -emit-llvm -w -S > /usr/local/src/llvm/test/FrontendC/inline-asm-function.c -fasm-blocks -o > - -O | /bin/grep naked > child process exited abnormally > Running /usr/local/src/llvm/test/FrontendC++/dg.exp ... > > FAIL: > /usr/local/src/llvm/test/FrontendC++/2010-04-30-OptimizedMethod-Dbg.cpp > Failed with exit(1) at line 2 > while running: grep "i1 false, i1 true. . . DW_TAG_subprogram" > 2010-04-30-OptimizedMethod-Dbg.cpp.tmp | count 2 > Expected 2 lines, got 0. and probably others. From vladimir at acm.org Mon May 3 14:09:32 2010 From: vladimir at acm.org (Vladimir G. Ivanovic) Date: Mon, 03 May 2010 12:09:32 -0700 Subject: [LLVMdev] `make check' failures in r102924 In-Reply-To: <9AC17D1D-4979-460D-B7A9-5604C0670AA7@apple.com> References: <4BDF0B33.6070808@acm.org> <9AC17D1D-4979-460D-B7A9-5604C0670AA7@apple.com> Message-ID: <4BDF1F6C.20307@acm.org> on 05/03/2010 11:13 AM Dale Johannesen said the following: > On May 3, 2010, at 10:43 AMPDT, Vladimir G. Ivanovic wrote: > > >> I successfully built LLVM (r102824) with >> >> ./configure --enable-optimized --enable-targets=host --with-built-clang >> >> on Fedora 12 on an Athlon64 processor. (The clang is the 2.7 pre-built >> version.) > > and the llvm-gcc appears to be also? Correct. Both are in my PATH. >> However, running `make check' produced 6 unexpected failures >> (see below). If there's something you'd like me to do, just holler. > > In general, tests added after a branch forked won't pass on that branch. That accounts for these at least: I don't understand. These are tests in the LLVM testsuite, not llvm-gcc tests. I have a consistent copy of LLVM and I don't know of any dependencies between post-2.7 LLVM and llvm-gcc-2.7. So they should pass, no? Or are you saying that there are such (heretofore) unmentioned dependencies that require a post-2.7 version of llvm-gcc to pass? --- Vladimir Vladimir G. Ivanovic http://www.leonora.org +1 650 450 4101 vladimir at acm.org >> FAIL: /usr/local/src/llvm/test/FrontendC/inline-asm-function.c >> Failed with exit(1) at line 1 >> while running: /usr/local/llvm-gcc4.2-2.7-x86_64-linux/bin/llvm-gcc >> -emit-llvm -w -S >> /usr/local/src/llvm/test/FrontendC/inline-asm-function.c -fasm-blocks -o >> - -O | /bin/grep naked >> child process exited abnormally >> Running /usr/local/src/llvm/test/FrontendC++/dg.exp ... >> >> FAIL: >> /usr/local/src/llvm/test/FrontendC++/2010-04-30-OptimizedMethod-Dbg.cpp >> Failed with exit(1) at line 2 >> while running: grep "i1 false, i1 true. . . DW_TAG_subprogram" >> 2010-04-30-OptimizedMethod-Dbg.cpp.tmp | count 2 >> Expected 2 lines, got 0. > > and probably others. > -------------- 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/20100503/e460be38/attachment.bin From dalej at apple.com Mon May 3 14:43:08 2010 From: dalej at apple.com (Dale Johannesen) Date: Mon, 3 May 2010 12:43:08 -0700 Subject: [LLVMdev] `make check' failures in r102924 In-Reply-To: <4BDF1F6C.20307@acm.org> References: <4BDF0B33.6070808@acm.org> <9AC17D1D-4979-460D-B7A9-5604C0670AA7@apple.com> <4BDF1F6C.20307@acm.org> Message-ID: On May 3, 2010, at 12:09 PMPDT, Vladimir G. Ivanovic wrote: > on 05/03/2010 11:13 AM Dale Johannesen said the following: >> On May 3, 2010, at 10:43 AMPDT, Vladimir G. Ivanovic wrote: >> >> >>> I successfully built LLVM (r102824) with >>> >>> ./configure --enable-optimized --enable-targets=host --with-built-clang >>> >>> on Fedora 12 on an Athlon64 processor. (The clang is the 2.7 pre-built >>> version.) >> >> and the llvm-gcc appears to be also? > Correct. Both are in my PATH. >>> However, running `make check' produced 6 unexpected failures >>> (see below). If there's something you'd like me to do, just holler. >> >> In general, tests added after a branch forked won't pass on that branch. That accounts for these at least: > I don't understand. These are tests in the LLVM testsuite, not llvm-gcc > tests. Tests in FrontendC and FrontendC++ are tests of llvm-gcc. > I have a consistent copy of LLVM and I don't know of any > dependencies between post-2.7 LLVM and llvm-gcc-2.7. So they should > pass, no? Or are you saying that there are such (heretofore) unmentioned > dependencies that require a post-2.7 version of llvm-gcc to pass? From vladimir at acm.org Mon May 3 15:27:07 2010 From: vladimir at acm.org (Vladimir G. Ivanovic) Date: Mon, 03 May 2010 13:27:07 -0700 Subject: [LLVMdev] `make check' failures in r102924 In-Reply-To: References: <4BDF0B33.6070808@acm.org> <9AC17D1D-4979-460D-B7A9-5604C0670AA7@apple.com> <4BDF1F6C.20307@acm.org> Message-ID: <4BDF319B.2050604@acm.org> on 05/03/2010 12:43 PM Dale Johannesen said the following: > However, running `make check' produced 6 unexpected failures >>>> (see below). If there's something you'd like me to do, just holler. >>> >>> In general, tests added after a branch forked won't pass on that branch. That accounts for these at least: >> I don't understand. These are tests in the LLVM testsuite, not llvm-gcc >> tests. > > Tests in FrontendC and FrontendC++ are tests of llvm-gcc. In general, tests in a particular distribution test that distribution and not some other. -- Vladimir Vladimir G. Ivanovic http://www.leonora.org +1 650 450 4101 vladimir at acm.org > >> I have a consistent copy of LLVM and I don't know of any >> dependencies between post-2.7 LLVM and llvm-gcc-2.7. So they should >> pass, no? Or are you saying that there are such (heretofore) unmentioned >> dependencies that require a post-2.7 version of llvm-gcc to pass? > -------------- 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/20100503/e81137ad/attachment.bin From dalej at apple.com Mon May 3 15:32:30 2010 From: dalej at apple.com (Dale Johannesen) Date: Mon, 3 May 2010 13:32:30 -0700 Subject: [LLVMdev] `make check' failures in r102924 In-Reply-To: <4BDF319B.2050604@acm.org> References: <4BDF0B33.6070808@acm.org> <9AC17D1D-4979-460D-B7A9-5604C0670AA7@apple.com> <4BDF1F6C.20307@acm.org> <4BDF319B.2050604@acm.org> Message-ID: On May 3, 2010, at 1:27 PMPDT, Vladimir G. Ivanovic wrote: > on 05/03/2010 12:43 PM Dale Johannesen said the following: >> However, running `make check' produced 6 unexpected failures >>>>> (see below). If there's something you'd like me to do, just holler. >>>> >>>> In general, tests added after a branch forked won't pass on that branch. That accounts for these at least: >>> I don't understand. These are tests in the LLVM testsuite, not llvm-gcc >>> tests. >> >> Tests in FrontendC and FrontendC++ are tests of llvm-gcc. > In general, tests in a particular distribution test that distribution > and not some other. That's true. People have suggested moving FrontendC and FrontendC++ into llvm-gcc from time to time, but as far as I know nobody's done anything about it. It's not clear everyone would approve of that, either; so far the people who think things are fine the way they are (if any) have had little reason to enter the discussion. From gohman at apple.com Mon May 3 15:34:55 2010 From: gohman at apple.com (Dan Gohman) Date: Mon, 3 May 2010 13:34:55 -0700 Subject: [LLVMdev] Generic target? In-Reply-To: <222994.40935.qm@web62006.mail.re1.yahoo.com> References: <222994.40935.qm@web62006.mail.re1.yahoo.com> Message-ID: <14ABCACB-03AF-4618-B793-BC2095384254@apple.com> On May 2, 2010, at 10:45 AM, Samuel Crow wrote: > Hello LLVM list, > > I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to have the alignment information or endianness until the final link stage at install time. > > Here's the build process currently: > > 1. The parser is built using LLVM-PEG parser generator which doesn't specify a target. It exports bitcode successfully. > > 2. The linker library used by the parser code and the main code completes the compiler bitcode thus creating a nearly complete compiler using LLVM-Link. > > 3. At install time system specific LibC wrapper written in C and compiled with Clang is linked to the incoming bitcode file with LLVM-Link. > > 4. Opt is invoked on it for LTO. > > 5. LLC converts the code to Assembly source. > > 6. The source is now assembled and linked to the real LibC calls contained in the LibC wrapper and the GLibC++ calls to satisfy the linker library are also linked in. What is GLibC++? > > 7. Execution reveals a core-dump due to a file handle being converted to a NULL for some reason. Have you looked at the resulting IR? If it's just libc wrappers and hello world, it ought to be fairly easy to visually inspect. > > As for step 7, I'd prefer that execution would reveal a "hello world" output to indicate that our code was working. :-) > > Since the LibC wrapper is such simple code I doubt that it's truly to blame so I'm left at a loss to explain it except that the endianness and aligment characteristics of the linker library written using LLVM-C++ are embedded in the bitcode files too soon to allow generic linking. The goal is to produce an endian-agnostic alignment-neutral bitcode in steps 1 and 2. How far away is this in the LLVM side and what can be done to help with a generic target? A fair amount of work was done to support "target-independent" IR in LLVM 2.7. If you omit TargetData, the optimizer conservatively avoids making any transformations which make memory layout assumptions. I don't know how widely used it is, but it works quite well for the things I've seen it used for. If you're just now trying hello world, it seems more likely that there's a problem in the wrappers or the main program than an optimization making memory layout assumptions. Dan From samuraileumas at yahoo.com Mon May 3 16:02:02 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Mon, 3 May 2010 14:02:02 -0700 (PDT) Subject: [LLVMdev] Generic target? In-Reply-To: <14ABCACB-03AF-4618-B793-BC2095384254@apple.com> References: <222994.40935.qm@web62006.mail.re1.yahoo.com> <14ABCACB-03AF-4618-B793-BC2095384254@apple.com> Message-ID: <702993.91017.qm@web62001.mail.re1.yahoo.com> Reply inlined. ----- Original Message ---- > From: Dan Gohman > To: Samuel Crow > Cc: LLVM Developers Mailing List > Sent: Mon, May 3, 2010 3:34:55 PM > Subject: Re: [LLVMdev] Generic target? > > On May 2, 2010, at 10:45 AM, Samuel Crow wrote: > Hello LLVM > list, > > I'm working on a wrapper for LibC and I think it would > work a whole lot better for what I'm trying to do if I wasn't forced to use a > specific endianness. I'm trying to make it work in such a way that the > compiler can generate code for a generic LLVM target such that the bitcodes > won't need to have the alignment information or endianness until the final link > stage at install time. > > Here's the build process > currently: > --snip-- > > 6. The source is now assembled and > linked to the real LibC calls contained in the LibC wrapper and the GLibC++ > calls to satisfy the linker library are also linked in. What is > GLibC++? Sorry, I meant LibStdC++. > > 7. Execution reveals a core-dump due to a > file handle being converted to a NULL for some reason. Have you looked at > the resulting IR? If it's just libc wrappers and hello world, it ought to be > fairly easy to visually inspect. The problem is that a pointer to a FILE structure is bitcasted to an i8 * and when it is read back it is null for some unkown reason. Then I end up with an exception that's the result of our compiled code. > > As for step 7, I'd prefer > that execution would reveal a "hello world" output to indicate that our code was > working. :-) > > Since the LibC wrapper is such simple code I > doubt that it's truly to blame so I'm left at a loss to explain it except that > the endianness and aligment characteristics of the linker library written using > LLVM-C++ are embedded in the bitcode files too soon to allow generic > linking. The goal is to produce an endian-agnostic alignment-neutral > bitcode in steps 1 and 2. How far away is this in the LLVM side and what > can be done to help with a generic target? A fair amount of work was done > to support "target-independent" IR in LLVM 2.7. If you omit TargetData, the > optimizer conservatively avoids making any transformations which make memory > layout assumptions. I don't know how widely used it is, but it works > quite well for the things I've seen it used for. If you're just now > trying hello world, it seems more likely that there's a problem in the > wrappers or the main program than an optimization making memory layout > assumptions. After having written the message you replied to, I figured the problem was probably with the fact that the linker library was written in C++ and compiled with LLVM-G++. Since GCC is known to make optimizations involving inlining and endianness independently of the LLVM optimizer, I think that is the culprit. Also, we were using LLVM 2.6 so we could avoid chasing our tails around with SVN head being in a semi-tested somewhat stable state only. I'll try updating the code to use 2.7 and see if that helps. Thanks for your response Dan, --Sam From gohman at apple.com Mon May 3 17:53:19 2010 From: gohman at apple.com (Dan Gohman) Date: Mon, 3 May 2010 15:53:19 -0700 Subject: [LLVMdev] API change: add, sub, and mul no longer do floating-point Message-ID: <128C97B5-FA51-4B02-A3C4-ECB099470D01@apple.com> Quick heads up: On LLVM trunk, the add, sub, and mul instructions no longer accept floating-point operands. The fadd, fsub, and fmul instructions should be used instead. This change actually happened back in LLVM 2.6; since then, LLVM has just been silently converting add into fadd and so on, and the change today is that it no longer does this silent conversion. Dan From eli.friedman at gmail.com Mon May 3 17:59:16 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 3 May 2010 15:59:16 -0700 Subject: [LLVMdev] API change: add, sub, and mul no longer do floating-point In-Reply-To: <128C97B5-FA51-4B02-A3C4-ECB099470D01@apple.com> References: <128C97B5-FA51-4B02-A3C4-ECB099470D01@apple.com> Message-ID: On Mon, May 3, 2010 at 3:53 PM, Dan Gohman wrote: > Quick heads up: On LLVM trunk, the add, sub, and mul instructions no > longer accept floating-point operands. The fadd, fsub, and fmul instructions > should be used instead. > > This change actually happened back in LLVM 2.6; since then, LLVM has just > been silently converting add into fadd and so on, and the change today is > that it no longer does this silent conversion. Does this affect backwards-compatibility for .bc and/or .ll files? -Eli From gohman at apple.com Mon May 3 18:27:05 2010 From: gohman at apple.com (Dan Gohman) Date: Mon, 3 May 2010 16:27:05 -0700 Subject: [LLVMdev] API change: add, sub, and mul no longer do floating-point In-Reply-To: References: <128C97B5-FA51-4B02-A3C4-ECB099470D01@apple.com> Message-ID: <4463E54E-CF0A-4093-A02B-B036958E7F99@apple.com> On May 3, 2010, at 3:59 PM, Eli Friedman wrote: > On Mon, May 3, 2010 at 3:53 PM, Dan Gohman wrote: >> Quick heads up: On LLVM trunk, the add, sub, and mul instructions no >> longer accept floating-point operands. The fadd, fsub, and fmul instructions >> should be used instead. >> >> This change actually happened back in LLVM 2.6; since then, LLVM has just >> been silently converting add into fadd and so on, and the change today is >> that it no longer does this silent conversion. > > Does this affect backwards-compatibility for .bc and/or .ll files? It affects .ll files but not .bc files. Dan From clattner at apple.com Mon May 3 18:36:26 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 3 May 2010 16:36:26 -0700 Subject: [LLVMdev] API change: add, sub, and mul no longer do floating-point In-Reply-To: <4463E54E-CF0A-4093-A02B-B036958E7F99@apple.com> References: <128C97B5-FA51-4B02-A3C4-ECB099470D01@apple.com> <4463E54E-CF0A-4093-A02B-B036958E7F99@apple.com> Message-ID: On May 3, 2010, at 4:27 PM, Dan Gohman wrote: >>> This change actually happened back in LLVM 2.6; since then, LLVM has just >>> been silently converting add into fadd and so on, and the change today is >>> that it no longer does this silent conversion. >> >> Does this affect backwards-compatibility for .bc and/or .ll files? > > > It affects .ll files but not .bc files. Please zap the 2.7 contents of docs/ReleaseNotes.html and add a note about this, thanks! From jyasskin at google.com Mon May 3 19:07:28 2010 From: jyasskin at google.com (Jeffrey Yasskin) Date: Mon, 3 May 2010 17:07:28 -0700 Subject: [LLVMdev] Is the option --enable-shared discontinued in 2.7? In-Reply-To: References: <4BD76DF8.7040205@tsoft.com> <4BD7F50C.6060007@tsoft.com> <4BD874E9.9060206@tsoft.com> Message-ID: On Thu, Apr 29, 2010 at 6:31 PM, Jeffrey Yasskin wrote: > On Wed, Apr 28, 2010 at 10:48 AM, Yuri wrote: >> Jeffrey Yasskin wrote: >>> >>> We currently use two different techniques to get whole libraries >>> included into the .so. On Linux (gnu ld and gold), we pass >>> --whole-archive, while on OSX we pass -all_load. Which ld does FreeBSD >>> use? If you can rearrange tools/llvm-shlib/Makefile until it works for >>> you and send us a patch, we can probably get it working for llvm-2.8. >>> >> >> >> ld on FreeBSD is from binutils. It takes --whole-archive option. > > Would you try the patch at > http://codereview.appspot.com/download/issue968046_1.diff? It should > make the BSDs fall into the same path as Linux, and since you use gnu > ld, that should work for you. Ping? From mdevan.foobar at gmail.com Tue May 4 02:56:53 2010 From: mdevan.foobar at gmail.com (Mahadevan R) Date: Tue, 4 May 2010 13:26:53 +0530 Subject: [LLVMdev] Branch prediction information? Message-ID: Hi, Is there a way for the front end to pass on branch prediction information (maybe user provided, like __builtin_expect, or statically computed) to the IR? Thanks & Regards, -Mahadevan. From Anton.Lokhmotov at arm.com Tue May 4 04:07:23 2010 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Tue, 4 May 2010 10:07:23 +0100 Subject: [LLVMdev] doxygen redux In-Reply-To: References: Message-ID: <000001caeb69$35d90930$a18b1b90$@Lokhmotov@arm.com> > Hi, I'm working on a patch to overhaul docs+doxygen builds for both > llvm and clang source trees. A-a-ah, this is something I've been longing for! The current style is barely readable, so I always end up looking in the sources. Keep up the good work! Anton/L. From zapster at zapster.cc Tue May 4 05:45:36 2010 From: zapster at zapster.cc (Josef Eisl) Date: Tue, 04 May 2010 12:45:36 +0200 Subject: [LLVMdev] Register Allocation: Interference graph In-Reply-To: <201005031154.10692.dag@cray.com> References: <4BDC2DFA.6090903@zapster.cc> <201005031154.10692.dag@cray.com> Message-ID: <4BDFFAD0.5050300@zapster.cc> David Greene wrote: > On Saturday 01 May 2010 08:34:50 Josef Eisl wrote: >> Hello, >> >> I want learn more about register allocation and do some analysis for a >> current research project. After reading some papers (eg. Chaitin, >> Briggs) I think its time to get my hands dirty :). > > Welcome! > >> First I plan to (re)implement some of the classic approaches to get >> familiar with the framework. > > Before doing that, can you describe your research a bit? A number of > people (include me!) have done graph-coloring style register allocators > for LLVM/x86 and not found much benefit over the existing "linear scan" > scheme (in quotes because it's not actually linear scan anymore :)). Maybe 'research' was not the appropriate term :). I am currently working on an assignment for the undergraduate course 'algorithms and data-structures' at our university and I want our attendee to see some real world examples. The topic of the assignment is graph coloring and I thought I can use LLVM to throw out some example input data. Maybe I'll port some of the submissions to LLVM and see what happens... Besides that, I am generally interested in all topics around compilation techniques/code generation especially using LLVM. I've been working on a back-end and recently implemented a tblgen pass to generate some hardware description files out of .td files. I am not planning to develop a highly efficient regalloc to compete with 'linear scan' ;). Just digging a little bit deeper into the topic. > > It might be better to use your time to investigate other algorithms. > If all you want to do right now is get familiar with the framework, there > are simpler algorithms than graph coloring. > >> At the beginning the following questions came up: >> >> - Is there some documentation about register allocation in LLVM? > > http://llvm.org/docs/CodeGenerator.html > http://llvm.org/docs/CodeGenerator.html#regalloc > > These are essential to read. A lot of details are missing which requires > one to just get down into the code and start hacking but this document helps > with understanding the broad picture. Thanks, I read these some time ago when I was starting the back-end implementation. I'll see if there are some new infos in it. > >> - As far as I understand it, register allocators are implemented as >> MachineFunctionPasses. Does a MachineFunction object contain all >> information needed for a (classic) allocator? > > It has the instructions, operands and dependencies among them. There's > a LiveInvervalAnalysis pass which you'll probably also need. That should > be enough to get going. I was able to set up my own allocator that uses LiveIntervals and it is currently printing out something that might become a conflict graph ;). Would be nice if there was some documentation about how to get all these objects out of the MachineFunction &MF parameter. Maybe I'll summarize how I did it and write something up... > >> - Is there already a pass that prints interference graph (Chaitin et al. >> 1981) or something similar like opt -view-cfg prints a CFG? If not, is >> it even possible with the current LLVM infrastructure? > > There's not one in trunk. When I did this I used Boost.Graph as the > representation and relied on its ability to dump GraphViz files for > visualization. You can also specialize LLVM's GraphTraits for your > particular graph representation and get much the same thing. You'll > need to add your own command-line options to display pretty pictures, > of course. I didn't know Boost.Graph. Seems pretty cool, thank for the hint. There is another questions that came up: Can I somehow get the PassManager to execute my MachineFunctionPass (loaded with llc -load) before the RegAlloc? As I am currently only printing out some LiveInterval infos so I don't need/want to implement a complete allocator. But if there is no pass that depends on my analysis the pass manager doesn't schedule my pass at all. I understand that that makes sense but it would be nice to 'force' the pass manager the execute my stuff before the allocator without changing the framework and only using llc -load (and maybe some custom cmd switches). Something similar is possible with opt but I can't figure it out with llc. > >> - Is there an LLVM register allocator that uses graph coloring or >> something similar? > > Not in trunk. Here's a message I looked at when I did mine: > > http://www.mail-archive.com/llvm-commits at cs.uiuc.edu/msg10962.html > > It's pretty stale at this point. It won't apply to trunk. Just > use it as a guide to get started. Hm, first class definition 'Interference graph node'. This looks very promising :). > >> - Which LLVM allocator would you recommend to look into to get the basic >> ideas how to use the framework? > > LinearScan is the only one widely used, AFAIK. There are some simpler > allocators as well (local, simple). PBQP is cool but I don't know much > about it. > > -Dave > > Many thanks your reply. I Really appreciate your help. Josef From capitrane at gmail.com Tue May 4 08:18:59 2010 From: capitrane at gmail.com (Mattias Lundell) Date: Tue, 4 May 2010 15:18:59 +0200 Subject: [LLVMdev] llvm-ld (and pthreads) problem Message-ID: Hi, I'm having some problems with producing native executables with llvm-ld. Both TimberLLVMLIB and TimberLLVMRTS is compiled into bitcode files and archived with llvm-ar. Everything works fine when using the flag -disable-opt llvm-ld -Xlinker='-pthread' -Xlinker='-m32' -native -disable-opt -L/home/capitrane/local/timber-llvm//share/timberc-1.0.3/rtsPOSIX ConcMap.bc ParPrimes.bc main.bc -o ParPrimes -lTimberLLVMRTS -lTimberLLVMLIB -v The generated file executes correctly. But when the flag -disable-opt is removed to introduce link-time optimizations the generated program segfaults. llvm-ld -Xlinker='-pthread' -Xlinker='-m32' -native -L/home/capitrane/local/timber-llvm//share/timberc-1.0.3/rtsPOSIX ConcMap.bc ParPrimes.bc main.bc -o ParPrimes -lTimberLLVMRTS -lTimberLLVMLIB -v Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb5fe4b70 (LWP 1662)] __pthread_mutex_lock (mutex=0x4) at pthread_mutex_lock.c:50 50 pthread_mutex_lock.c: No such file or directory. in pthread_mutex_lock.c Any tips on how to move on is appreciated. Regards Mattias From kuba at gcc.gnu.org Tue May 4 11:41:00 2010 From: kuba at gcc.gnu.org (Jakub Staszak) Date: Tue, 4 May 2010 14:41:00 -0200 Subject: [LLVMdev] Question about GVN Message-ID: <77E0913B-E538-4E7F-A4E2-1B9D2CE83976@gcc.gnu.org> Hello, I was investigating GVN.cpp file and I found suspicious part: 1587 bool NeedToSplitEdges = false; 1588 for (pred_iterator PI = pred_begin(LoadBB), E = pred_end(LoadBB); 1589 PI != E; ++PI) { 1590 BasicBlock *Pred = *PI; 1591 if (IsValueFullyAvailableInBlock(Pred, FullyAvailableBlocks)) { 1592 continue; 1593 } 1594 PredLoads[Pred] = 0; 1595 1596 if (Pred->getTerminator()->getNumSuccessors() != 1) { 1597 if (isa(Pred->getTerminator())) { 1598 DEBUG(dbgs() << "COULD NOT PRE LOAD BECAUSE OF INDBR CRITICAL EDGE '" 1599 << Pred->getName() << "': " << *LI << '\n'); 1600 return false; 1601 } 1602 unsigned SuccNum = GetSuccessorNumber(Pred, LoadBB); 1603 toSplit.push_back(std::make_pair(Pred->getTerminator(), SuccNum)); 1604 NeedToSplitEdges = true; 1605 } 1606 } 1607 if (NeedToSplitEdges) 1608 return false; Because it iterates over predecessors it may happen that not the first one has IndirectBrInst terminator. However some "toSplit" edges can be already added. Is this OK? Maybe I just misunderstood something? Regards -- Jakub Staszak From dag at cray.com Tue May 4 11:57:21 2010 From: dag at cray.com (David Greene) Date: Tue, 4 May 2010 11:57:21 -0500 Subject: [LLVMdev] Register Allocation: Interference graph In-Reply-To: <4BDFFAD0.5050300@zapster.cc> References: <4BDC2DFA.6090903@zapster.cc> <201005031154.10692.dag@cray.com> <4BDFFAD0.5050300@zapster.cc> Message-ID: <201005041157.22049.dag@cray.com> On Tuesday 04 May 2010 05:45:36 Josef Eisl wrote: > >> - As far as I understand it, register allocators are implemented as > >> MachineFunctionPasses. Does a MachineFunction object contain all > >> information needed for a (classic) allocator? > > > > It has the instructions, operands and dependencies among them. There's > > a LiveInvervalAnalysis pass which you'll probably also need. That should > > be enough to get going. > > I was able to set up my own allocator that uses LiveIntervals and it is > currently printing out something that might become a conflict graph ;). > Would be nice if there was some documentation about how to get all these > objects out of the MachineFunction &MF parameter. > Maybe I'll summarize how I did it and write something up... Which objects? Iterating over blocks and instructions from MachineFunction is pretty straightforward and getAnalysis<> is what you want for LiveIntervals. I presume you know all this since you have LiveIntervals dumping something. What else do you need to get at? > I didn't know Boost.Graph. Seems pretty cool, thank for the hint. It's a bit unwieldy at times. The interface is much more complex than it needs to be, but people are working on that. Slowly. :( > There is another questions that came up: Can I somehow get the > PassManager to execute my MachineFunctionPass (loaded with llc -load) > before the RegAlloc? As I am currently only printing out some > LiveInterval infos so I don't need/want to implement a complete > allocator. But if there is no pass that depends on my analysis the pass > manager doesn't schedule my pass at all. I understand that that makes > sense but it would be nice to 'force' the pass manager the execute my > stuff before the allocator without changing the framework and only using > llc -load (and maybe some custom cmd switches). Something similar is > possible with opt but I can't figure it out with llc. Passes in llc are hard-coded in LLVMTargetMachine.cpp. Does your pass actually do register allocation, or will it? If so, you want to use the RegisterRegAlloc object. Here is how linear scan uses it: static RegisterRegAlloc linearscanRegAlloc("linearscan", "linear scan register allocator", createLinearScanRegisterAllocator); Then createRegisterAllocator in CodeGen/Passes.cpp will pick up your allocator and list it as an option under -regalloc=. If you pass is just doing some analysis and dumps you can either add a invocation of it to LLVMTargetMachine.cpp or make some other pass dependent on it. -Dave From bob.wilson at apple.com Tue May 4 12:05:05 2010 From: bob.wilson at apple.com (Bob Wilson) Date: Tue, 4 May 2010 10:05:05 -0700 Subject: [LLVMdev] Question about GVN In-Reply-To: <77E0913B-E538-4E7F-A4E2-1B9D2CE83976@gcc.gnu.org> References: <77E0913B-E538-4E7F-A4E2-1B9D2CE83976@gcc.gnu.org> Message-ID: On May 4, 2010, at 9:41 AM, Jakub Staszak wrote: > Hello, I was investigating GVN.cpp file and I found suspicious part: > > 1587 bool NeedToSplitEdges = false; > 1588 for (pred_iterator PI = pred_begin(LoadBB), E = pred_end(LoadBB); > 1589 PI != E; ++PI) { > 1590 BasicBlock *Pred = *PI; > 1591 if (IsValueFullyAvailableInBlock(Pred, FullyAvailableBlocks)) { > 1592 continue; > 1593 } > 1594 PredLoads[Pred] = 0; > 1595 > 1596 if (Pred->getTerminator()->getNumSuccessors() != 1) { > 1597 if (isa(Pred->getTerminator())) { > 1598 DEBUG(dbgs() << "COULD NOT PRE LOAD BECAUSE OF INDBR CRITICAL EDGE '" > 1599 << Pred->getName() << "': " << *LI << '\n'); > 1600 return false; > 1601 } > 1602 unsigned SuccNum = GetSuccessorNumber(Pred, LoadBB); > 1603 toSplit.push_back(std::make_pair(Pred->getTerminator(), SuccNum)); > 1604 NeedToSplitEdges = true; > 1605 } > 1606 } > 1607 if (NeedToSplitEdges) > 1608 return false; > > Because it iterates over predecessors it may happen that not the first one has IndirectBrInst terminator. > However some "toSplit" edges can be already added. Is this OK? > Maybe I just misunderstood something? I suppose it might end up splitting some edges unnecessarily. That isn't a huge problem but it would be good to fix. The edges to be split could be saved on a local list and added to "toSplit" only after looking at all the predecessors. I'll fix that. From resistor at mac.com Tue May 4 12:08:40 2010 From: resistor at mac.com (Owen Anderson) Date: Tue, 04 May 2010 10:08:40 -0700 Subject: [LLVMdev] Question about GVN In-Reply-To: <77E0913B-E538-4E7F-A4E2-1B9D2CE83976@gcc.gnu.org> References: <77E0913B-E538-4E7F-A4E2-1B9D2CE83976@gcc.gnu.org> Message-ID: On May 4, 2010, at 9:41 AM, Jakub Staszak wrote: > > Because it iterates over predecessors it may happen that not the first one has IndirectBrInst terminator. > However some "toSplit" edges can be already added. Is this OK? > Maybe I just misunderstood something? It might result in doing some unnecessary edge splitting, but it's not dangerous in the "breaking the program" sense. Presumably SimplifyCFG will fold these blocks away if they're empty. --Owen From blunted2night at gmail.com Tue May 4 13:03:58 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Tue, 4 May 2010 11:03:58 -0700 Subject: [LLVMdev] MCStreamer itnerface Message-ID: This is a brain-dump of my thoughts on the MCStreamer interface after several days of digging around trying to get a COFF writer working. All fragments should be associated with a symbol. For assembler components, a unnammed "virtual" symbol can be used when there is no explicit label defined. Section assignment should be the responsiblity of the object imlementing the MCStreamer interface, with the caller givin the ability to give hints as to what section to place the symbol into. instead of SwitchSection, there would be BeginSymbol, and SymbolSymbol, it would be illegal to call any EmitXXX function outside of these two calls BeginSymbol(Symbol, SectionHint) EmitAttribute(...) EmitAttribute(...) ... StartFragmentEmission() EmitFragment(...) EmitFragment(...) ... EndSymbol() Object file writers would typically start recording fragments and attributes for a symbol on the BeginSymbol, then at EndSymbol they would evaluate what was streamed, and decide what section the symbol should be placed in. Assembly writers could with some state data emit assemble as emission calls are made. Assembler parsers could use 'section symbols' to provide section level attributes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100504/5cedc774/attachment.html From omerigener at gmail.com Tue May 4 13:26:01 2010 From: omerigener at gmail.com (Gener Omer) Date: Tue, 4 May 2010 21:26:01 +0300 Subject: [LLVMdev] Call graph node for function: 'main' Calls external node Message-ID: Hello, On the following code, // #include void f2(); int main(){ f2(); return 0; } void f2(){ printf("f2()\n"); } // I have obtained the .bc file and run opt -print-callgraph finename.bc. For the main function, the output of the above command is: Call graph node for function: 'main' Calls external node However, the function called by main(which is f2) is inside the module. Is there any way to detect all function calls, including the one above and those made via pointers to functions? Thanks, Gener -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100504/67b90ebc/attachment.html From baldrick at free.fr Tue May 4 14:11:59 2010 From: baldrick at free.fr (Duncan Sands) Date: Tue, 04 May 2010 21:11:59 +0200 Subject: [LLVMdev] Call graph node for function: 'main' Calls external node In-Reply-To: References: Message-ID: <4BE0717F.6090404@free.fr> Hi Gener, > For the main function, the output of the above command is: > > Call graph node for function: 'main' > Calls external node this means that callgraph saw that main calls something, but it doesn't know what it is. It might be any function, internal (eg: f2) or external. The reason for this poor quality information is that the use of the forward declaration "void f2();", which should be "void f2(void);", results in some unpleasantness in the bitcode. If you run the optimizers it will be cleaned up. Take a look at this: without optimization and with mild optimization: $ llvm-gcc -c -o - cg.c -emit-llvm -O0 | opt -print-callgraph -disable-output 2>&1 | grep "function: 'main'" -A 2 Call graph node for function: 'main'<<0x2f80c30>> #uses=1 CS<0x2f837b8> calls external node $ llvm-gcc -c -o - cg.c -emit-llvm -O1 | opt -print-callgraph -disable-output 2>&1 | grep "function: 'main'" -A 2 Call graph node for function: 'main'<<0x20536c0>> #uses=1 CS<0x2057468> calls function 'f2' The callgraph code doesn't try to be clever. It assumes that the optimizers have been run. Ciao, Duncan. From blunted2night at gmail.com Tue May 4 14:53:50 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Tue, 4 May 2010 12:53:50 -0700 Subject: [LLVMdev] MCStreamer itnerface Message-ID: I should probably elaborate on why I feel the interface should be as such. It seems to be the common case is compiler outputting to object files. In this case, all fragments are associated with symbols. What section the fragments go into is generally irrelevant to the compiler, except in special cases like global variable constructor/destructor lists and the like. At code generation time, the compiler would for all normal symbols, not specify any grouping information, and allow the streamer to make decisions about where to place data based of the content. For special scenarios, like constructor/destructor a set of hints could be defined to produce the expected behavior. i.e. struct SectionHint {}; // used by assemblers to put symbols into the // section specified by a section directive struct NamedSectionHint : SectionHint { // then name of the section to put the symbol in std::string Name; }; struct OrderedNamedHint : NamedSection { // the order to place the symbol into the section when finally linked, // each different "ordered section" should produce a separate section // in the object file // positive means put in ascending order before any other sections with the same name // 1 if first, 2 is second, and so on // negative means put in descending order after any other sections with the same name // -1 is last, -2 is second to last, and so on int Order; }; Any NamedHints would show up in between positive & negative named hints with the same name. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100504/697efeb6/attachment.html From zapster at zapster.cc Tue May 4 15:23:21 2010 From: zapster at zapster.cc (Josef Eisl) Date: Tue, 04 May 2010 22:23:21 +0200 Subject: [LLVMdev] Register Allocation: Interference graph In-Reply-To: <201005041157.22049.dag@cray.com> References: <4BDC2DFA.6090903@zapster.cc> <201005031154.10692.dag@cray.com> <4BDFFAD0.5050300@zapster.cc> <201005041157.22049.dag@cray.com> Message-ID: <4BE08239.90502@zapster.cc> David Greene wrote: > On Tuesday 04 May 2010 05:45:36 Josef Eisl wrote: > > >>>> - As far as I understand it, register allocators are implemented as >>>> MachineFunctionPasses. Does a MachineFunction object contain all >>>> information needed for a (classic) allocator? >>> It has the instructions, operands and dependencies among them. There's >>> a LiveInvervalAnalysis pass which you'll probably also need. That should >>> be enough to get going. >> I was able to set up my own allocator that uses LiveIntervals and it is >> currently printing out something that might become a conflict graph ;). >> Would be nice if there was some documentation about how to get all these >> objects out of the MachineFunction &MF parameter. >> Maybe I'll summarize how I did it and write something up... > > Which objects? Iterating over blocks and instructions from MachineFunction > is pretty straightforward and getAnalysis<> is what you want for > LiveIntervals. I presume you know all this since you have LiveIntervals > dumping something. After I've taken a second look at my code, I must admit, it is really straight forward. Don't know why I didn't got it the first time. > > What else do you need to get at? > >> I didn't know Boost.Graph. Seems pretty cool, thank for the hint. > > It's a bit unwieldy at times. The interface is much more complex > than it needs to be, but people are working on that. Slowly. :( > >> There is another questions that came up: Can I somehow get the >> PassManager to execute my MachineFunctionPass (loaded with llc -load) >> before the RegAlloc? As I am currently only printing out some >> LiveInterval infos so I don't need/want to implement a complete >> allocator. But if there is no pass that depends on my analysis the pass >> manager doesn't schedule my pass at all. I understand that that makes >> sense but it would be nice to 'force' the pass manager the execute my >> stuff before the allocator without changing the framework and only using >> llc -load (and maybe some custom cmd switches). Something similar is >> possible with opt but I can't figure it out with llc. > > Passes in llc are hard-coded in LLVMTargetMachine.cpp. Does your > pass actually do register allocation, or will it? If so, you want > to use the RegisterRegAlloc object. Here is how linear scan uses it: > > static RegisterRegAlloc > linearscanRegAlloc("linearscan", "linear scan register allocator", > createLinearScanRegisterAllocator); > > Then createRegisterAllocator in CodeGen/Passes.cpp will pick up > your allocator and list it as an option under -regalloc=. Yes, I've done so. After my pass is finished with the 'dumping' it calls runOnMachineFunction from another implemented RegAlloc until I implement my own. > > If you pass is just doing some analysis and dumps you can either > add a invocation of it to LLVMTargetMachine.cpp or make some > other pass dependent on it. Ok, thats what I expected. Would be nice to hook in a pass without changing llc but I guess it wouldn't make any sense for 'real' passes. Thanks again for your help! Josef From yuri at tsoft.com Tue May 4 19:31:50 2010 From: yuri at tsoft.com (Yuri) Date: Tue, 04 May 2010 17:31:50 -0700 Subject: [LLVMdev] Is the option --enable-shared discontinued in 2.7? In-Reply-To: References: <4BD76DF8.7040205@tsoft.com> <4BD7F50C.6060007@tsoft.com> <4BD874E9.9060206@tsoft.com> Message-ID: <4BE0BC76.8050400@tsoft.com> Jeffrey Yasskin wrote: >> Would you try the patch at >> http://codereview.appspot.com/download/issue968046_1.diff? It should >> make the BSDs fall into the same path as Linux, and since you use gnu >> ld, that should work for you. >> > > Ping? > Sorry for the delay. Here is what I am getting after applying the patch: gmake[2]: Leaving directory `/tmp/llvm-build/2.7/llvm-objects/lib/CodeGen' gmake[1]: Leaving directory `/tmp/llvm-build/2.7/llvm-objects/lib' gmake[1]: Entering directory `/tmp/llvm-build/2.7/llvm-objects/tools/llvm-shlib' llvm[1]: Linking Release Shared Library LLVM-2.7.so /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x135): In function `(anonymous namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': : undefined reference to `__assert' /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x3e3): In function `(anonymous namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': : undefined reference to `__assert' /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x5d8): In function `(anonymous namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': : undefined reference to `__assert' /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0xd10): In function `(anonymous namespace)::ARMAsmParser::MatchRegisterName(llvm::StringRef const&)': : undefined reference to `memcmp' /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0xd45): In function `(anonymous namespace)::ARMAsmParser::MatchRegisterName(llvm::StringRef const&)': : undefined reference to `memcmp' /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0xd6d): In function `(anonymous namespace)::ARMAsmParser::MatchRegisterName(llvm::StringRef const&)': : undefined reference to `memcmp' /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0xdd5): In function `(anonymous namespace)::ARMAsmParser::MaybeParseRegister((anonymous namespace)::ARMOperand&, bool)': : undefined reference to `__assert' Linking command line was: /usr/local/gcc/4.5.0/bin/g++ -I/tmp/llvm-build/2.7/llvm-objects/include -I/tmp/llvm-build/2.7/llvm-objects/tools/llvm-shlib -I/tmp/llvm-build/2.7/llvm/include -I/tmp/llvm-build/2.7/llvm/tools/llvm-shlib -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-exceptions -fno-rtti -fPIC -Woverloaded-virtual -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -O2 -Wl,-R -Wl,/tmp/llvm-build/2.7/llvm-objects/Release/lib -L/tmp/llvm-build/2.7/llvm-objects/Release/lib -L/tmp/llvm-build/2.7/llvm-objects/Release/lib -shared -o /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVM-2.7.so -Wl,--whole-archive -lLLVMARMAsmParser -lLLVMARMAsmPrinter -lLLVMARMCodeGen -lLLVMARMInfo -lLLVMAlphaAsmPrinter -lLLVMAlphaCodeGen -lLLVMAlphaInfo -lLLVMAnalysis -lLLVMArchive -lLLVMAsmParser -lLLVMAsmPrinter -lLLVMBitReader -lLLVMBitWriter -lLLVMBlackfinAsmPrinter -lLLVMBlackfinCodeGen -lLLVMBlackfinInfo -lLLVMCBackend -lLLVMCBackendInfo -lLLVMCellSPUAsmPrinter -lLLVMCellSPUCodeGen -lLLVMCellSPUInfo -lLLVMCodeGen -lLLVMCore -lLLVMCppBackend -lLLVMCppBackendInfo -lLLVMExecutionEngine -lLLVMInstCombine -lLLVMInstrumentation -lLLVMInterpreter -lLLVMJIT -lLLVMLinker -lLLVMMBlazeAsmPrinter -lLLVMMBlazeCodeGen -lLLVMMBlazeInfo -lLLVMMC -lLLVMMCParser -lLLVMMSIL -lLLVMMSILInfo -lLLVMMSP430AsmPrinter -lLLVMMSP430CodeGen -lLLVMMSP430Info -lLLVMMipsAsmPrinter -lLLVMMipsCodeGen -lLLVMMipsInfo -lLLVMPIC16AsmPrinter -lLLVMPIC16CodeGen -lLLVMPIC16Info -lLLVMPowerPCAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCInfo -lLLVMScalarOpts -lLLVMSelectionDAG -lLLVMSparcAsmPrinter -lLLVMSparcCodeGen -lLLVMSparcInfo -lLLVMSupport -lLLVMSystem -lLLVMSystemZAsmPrinter -lLLVMSystemZCodeGen -lLLVMSystemZInfo -lLLVMTarget -lLLVMTransformUtils -lLLVMX86AsmParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen -lLLVMX86Disassembler -lLLVMX86Info -lLLVMXCoreAsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreInfo -lLLVMipa -lLLVMipo -lLLVMpic16passes -Wl,--no-whole-archive -Wl,--no-undefined -lpthread -lm Adding -lc in the end fixes the errors and produces the full size libLLVM-2.7.so. Yuri From keveman at gmail.com Tue May 4 19:33:26 2010 From: keveman at gmail.com (Manjunath Kudlur) Date: Tue, 4 May 2010 17:33:26 -0700 Subject: [LLVMdev] SplitVecRes_LOAD Message-ID: I was going through the function DAGTypeLegalizer::SplitVecRes_LOAD in LegalizeVectorTypes.cpp. I noticed that it is using getSizeInBits()/8 to compute IncrementSize, which is the offset for the load of second half of the vector. I have a situation where the frontend is producing load for a <2 x i1> type, and the architecture has i1 registers (but not v2i1 registers). The store size of i1 is 8 bits (the size returned by getStoreSizeInBits()). When SplitVecRes_LOAD is called, because it is using getSizeInBits()/8, the offset for the second half is zero, so it ends up using the same i1 value for both the halves. Is this a bug, or am I missing something? Thanks, Manjunath From gohman at apple.com Tue May 4 21:35:58 2010 From: gohman at apple.com (Dan Gohman) Date: Tue, 4 May 2010 19:35:58 -0700 Subject: [LLVMdev] SplitVecRes_LOAD In-Reply-To: References: Message-ID: <92EB2A4D-6BBE-4E23-B1E7-8442ADD37E75@apple.com> On May 4, 2010, at 5:33 PM, Manjunath Kudlur wrote: > I was going through the function DAGTypeLegalizer::SplitVecRes_LOAD in > LegalizeVectorTypes.cpp. I noticed that it is using getSizeInBits()/8 > to compute IncrementSize, which is the offset for the load of second > half of the vector. I have a situation where the frontend is producing > load for a <2 x i1> type, and the architecture has i1 registers (but > not v2i1 registers). The store size of i1 is 8 bits (the size returned > by getStoreSizeInBits()). When SplitVecRes_LOAD is called, because it > is using getSizeInBits()/8, the offset for the second half is zero, so > it ends up using the same i1 value for both the halves. Is this a bug, > or am I missing something? It's a bug. LLVM doesn't really support vectors of non-byte-divisible elements in memory very well. Dan From proljc at gmail.com Tue May 4 22:57:24 2010 From: proljc at gmail.com (=?GB2312?B?sK66w9Xf?=) Date: Wed, 5 May 2010 11:57:24 +0800 Subject: [LLVMdev] hi, I can't find information about how to cross compile llvm-gcc in llvm docs. Message-ID: hi all We want speed up our applications, so we want use llvm-gcc. I nerver cross build it for arm, and I didn't find enough information in llvm docs. Our cpu is cortex a8, anybody tell me how can I do? Step by step. THANK YOU! yours Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/d7a92dcc/attachment.html From eli.friedman at gmail.com Tue May 4 23:25:34 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 4 May 2010 21:25:34 -0700 Subject: [LLVMdev] hi, I can't find information about how to cross compile llvm-gcc in llvm docs. In-Reply-To: References: Message-ID: On Tue, May 4, 2010 at 8:57 PM, ??? wrote: > hi all > ?? ? ?We want speed up our applications, so we want use llvm-gcc. I nerver > cross build it for arm, and I didn't find enough information in llvm docs. > ?? ? ?Our cpu is?cortex a8, anybody tell me how can I do? Step by step. > THANK YOU! > yours Liu Try the llvm/utils/crosstool/ARM/build-install-linux.sh script for a semi-automated approach (README in the same directory). The manual method is roughly the same method you'd use to cross-compile gcc, so there isn't much documentation specific to llvm-gcc. -Eli From proljc at gmail.com Wed May 5 00:57:45 2010 From: proljc at gmail.com (=?GB2312?B?sK66w9Xf?=) Date: Wed, 5 May 2010 13:57:45 +0800 Subject: [LLVMdev] hi, I can't find information about how to cross compile llvm-gcc in llvm docs. In-Reply-To: References: Message-ID: I place codesourcery toolchain 2010q1 there, but the sh tell me "CodeSourcery tarball not found in /root/tmp/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ", does 2007q3 support ARM Cortex A8? What can I do? 2010/5/5 Eli Friedman > On Tue, May 4, 2010 at 8:57 PM, ?????? wrote: > > hi all > > We want speed up our applications, so we want use llvm-gcc. I > nerver > > cross build it for arm, and I didn't find enough information in llvm > docs. > > Our cpu is cortex a8, anybody tell me how can I do? Step by step. > > THANK YOU! > > yours Liu > > Try the llvm/utils/crosstool/ARM/build-install-linux.sh script for a > semi-automated approach (README in the same directory). The manual > method is roughly the same method you'd use to cross-compile gcc, so > there isn't much documentation specific to llvm-gcc. > > -Eli > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/2ccc40dc/attachment.html From proljc at gmail.com Wed May 5 01:08:15 2010 From: proljc at gmail.com (=?GB2312?B?sK66w9Xf?=) Date: Wed, 5 May 2010 14:08:15 +0800 Subject: [LLVMdev] hi, I can't find information about how to cross compile llvm-gcc in llvm docs. In-Reply-To: References: Message-ID: and I see " readonly CROSS_MARCH="${CROSS_MARCH:-armv6}" " in the shell script ARM Cortex A8 is ARMv7, I want this get work. Anybody help me? ?? 2010??5??5?? ????1:57???????? ?????? > I place codesourcery toolchain 2010q1 there, but the sh tell me > "CodeSourcery tarball not found in > /root/tmp/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 > ", does 2007q3 support ARM Cortex A8? > What can I do? > > 2010/5/5 Eli Friedman > > On Tue, May 4, 2010 at 8:57 PM, ?????? wrote: >> > hi all >> > We want speed up our applications, so we want use llvm-gcc. I >> nerver >> > cross build it for arm, and I didn't find enough information in llvm >> docs. >> > Our cpu is cortex a8, anybody tell me how can I do? Step by step. >> > THANK YOU! >> > yours Liu >> >> Try the llvm/utils/crosstool/ARM/build-install-linux.sh script for a >> semi-automated approach (README in the same directory). The manual >> method is roughly the same method you'd use to cross-compile gcc, so >> there isn't much documentation specific to llvm-gcc. >> >> -Eli >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/9dd06d49/attachment.html From baldrick at free.fr Wed May 5 01:52:00 2010 From: baldrick at free.fr (Duncan Sands) Date: Wed, 05 May 2010 08:52:00 +0200 Subject: [LLVMdev] SplitVecRes_LOAD In-Reply-To: References: Message-ID: <4BE11590.5080400@free.fr> Hi Manjunath, see http://llvm.org/bugs/show_bug.cgi?id=1784 From proljc at gmail.com Wed May 5 08:42:48 2010 From: proljc at gmail.com (=?GB2312?B?sK66w9Xf?=) Date: Wed, 5 May 2010 21:42:48 +0800 Subject: [LLVMdev] How can I cross compile Clang+LLVM-2.7 for Arm Cortex-A8 Message-ID: hi all I saw that llvm-2.7 support arm cortex-a8 now, but I didn't find how to cross build it. thank you all -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/976c140e/attachment.html From jan_sjodin at yahoo.com Wed May 5 10:29:27 2010 From: jan_sjodin at yahoo.com (Jan Sjodin) Date: Wed, 5 May 2010 08:29:27 -0700 (PDT) Subject: [LLVMdev] Size of packed struct type <{<3 x i32>, i32}> Message-ID: <256191.4357.qm@web55604.mail.re4.yahoo.com> I have a packed struct <{<3 x i32>, i32}> type that LLVM determines to be 20 bytes. Is this the expected size for this type? I wrote a small example to illustrate: ; ModuleID = 'myexample.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128" target triple = "x86_64-pc-linux" %mytype = type <{<3 x i32>, i32}> define void @myexample(%mytype* %src, i64 %index, i32* %result) { entry: %vectoraddr = getelementptr %mytype* %src, i64 %index, i32 0 %vector = load <3 x i32>* %vectoraddr %tmp1 = extractelement <3 x i32> %vector, i32 2 store i32 %tmp1, i32* %result ret void } When I generate code (llc revision: 103084) i get: .Leh_func_begin0: # BB#0: # %entry leaq (%rsi,%rsi,4), %rax <- Multiply index by 5 pshufd $2, (%rdi,%rax,4), %xmm0 <- multiply again by 4 (element size 20) and add base pointer movd %xmm0, (%rdx) ret My guess was that the size should be 16 because I thought there should be no padding between elements. - Jan From luoyonggang at gmail.com Wed May 5 10:54:55 2010 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Wed, 5 May 2010 23:54:55 +0800 Subject: [LLVMdev] Why llvm function name is different with . and .. Message-ID: declare i8 @llvm.atomic.load.max.i8.p0i8( i8* , i8 ) declare i16 @llvm.atomic.load.max.i16.p0i16( i16* , i16 ) declare i32 @llvm.atomic.load.max.i32.p0i32( i32* , i32 ) declare i64 @llvm.atomic.load.max.i64.p0i64( i64* , i64 ) declare i8 @llvm.atomic.load.min.i8.p0i8( i8* , i8 ) declare i16 @llvm.atomic.load.min.i16.p0i16( i16* , i16 ) declare i32 @llvm.atomic.load.min.i32..p0i32( i32* , i32 ) declare i64 @llvm.atomic.load.min.i64..p0i64( i64* , i64 ) declare i8 @llvm.atomic.load.umax.i8.p0i8( i8* , i8 ) declare i16 @llvm.atomic.load.umax.i16.p0i16( i16* , i16 ) declare i32 @llvm.atomic.load.umax.i32.p0i32( i32* , i32 ) declare i64 @llvm.atomic.load.umax.i64.p0i64( i64* , i64 ) declare i8 @llvm.atomic.load.umin.i8..p0i8( i8* , i8 ) declare i16 @llvm.atomic.load.umin.i16.p0i16( i16* , i16 ) declare i32 @llvm.atomic.load.umin.i32..p0i32( i32* , i32 ) declare i64 @llvm.atomic.load.umin.i64..p0i64( i64* , i64 ) Why in the llvm function name, some functions containing "..", but others only contains only "." Thanks. -- ?? ? ??? Yours sincerely, Yonggang Luo From baldrick at free.fr Wed May 5 11:13:59 2010 From: baldrick at free.fr (Duncan Sands) Date: Wed, 05 May 2010 18:13:59 +0200 Subject: [LLVMdev] Size of packed struct type <{<3 x i32>, i32}> In-Reply-To: <256191.4357.qm@web55604.mail.re4.yahoo.com> References: <256191.4357.qm@web55604.mail.re4.yahoo.com> Message-ID: <4BE19947.4090204@free.fr> On 05/05/10 17:29, Jan Sjodin wrote: > I have a packed struct<{<3 x i32>, i32}> type that LLVM determines to be 20 bytes. > Is this the expected size for this type? Yes. LLVM systematically allocates the same amount of memory for an object of a given type (here <3 x i32>), whether on the stack, in an array, in a struct, or a packed struct etc. The fact that the struct is packed is not relevant [*]. > My guess was that the size should be 16 because I thought there should be no padding between elements. There is no padding between elements, there is padding inside an element! Ciao, Duncan. [*] This used to be different: when I first rationalized the notion of size in LLVM, I allocated less memory to types when they are in a packed struct. But I later reverted that, since having this exceptional case seemed too confusing. From nathan.mccauley at gmail.com Wed May 5 11:45:22 2010 From: nathan.mccauley at gmail.com (Nathan McCauley) Date: Wed, 5 May 2010 09:45:22 -0700 Subject: [LLVMdev] LLVM on ARM with the EABI Message-ID: Hi list, I'm wondering if LLC supports code generation targeting ARM processors and using the EABI. Thanks, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/3f16d04f/attachment.html From bob.wilson at apple.com Wed May 5 11:56:20 2010 From: bob.wilson at apple.com (Bob Wilson) Date: Wed, 5 May 2010 09:56:20 -0700 Subject: [LLVMdev] LLVM on ARM with the EABI In-Reply-To: References: Message-ID: <0421C441-1DFF-43F0-9872-97B5C12AF663@apple.com> On May 5, 2010, at 9:45 AM, Nathan McCauley wrote: > I'm wondering if LLC supports code generation targeting ARM processors and using the EABI. Yes, it does. From fxyxixe at gmail.com Wed May 5 12:00:18 2010 From: fxyxixe at gmail.com (nonpoly) Date: Wed, 5 May 2010 10:00:18 -0700 (PDT) Subject: [LLVMdev] emit after gvn pass? Message-ID: <28462901.post@talk.nabble.com> Hello again, Just wondering if there is a flag I can pass when compiling with llvm-gcc that can emit the llvm IR after the gvn pass (want to see the IR after dead code elimination/redundancy elimination). If so, will other passes be performed as well? I really just want to see the IR after the eliminations only, if it is at all possible. Thanks in advance, -nonpoly -- View this message in context: http://old.nabble.com/emit-after-gvn-pass--tp28462901p28462901.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From yuri at tsoft.com Wed May 5 12:08:13 2010 From: yuri at tsoft.com (Yuri) Date: Wed, 05 May 2010 10:08:13 -0700 Subject: [LLVMdev] Is the option --enable-shared discontinued in 2.7? (FreeBSD) In-Reply-To: References: <4BD76DF8.7040205@tsoft.com> <4BD7F50C.6060007@tsoft.com> <4BD874E9.9060206@tsoft.com> Message-ID: <4BE1A5FD.3080905@tsoft.com> Jeffrey Yasskin wrote: >> Would you try the patch at >> http://codereview.appspot.com/download/issue968046_1.diff? It should >> make the BSDs fall into the same path as Linux, and since you use gnu >> ld, that should work for you. >> > > Ping? > I also noticed that during the build in llvm-gcc-4.2-objects on sparc machine there is also a step: llvm[1]: Linking Release Shared Library LLVM-2.7.so Linking command is the similar (or same) as in llvm-objects. It fails just like the same command in llvm-objects. And adding -lc in the end saves it. I guess this is a bug in the Makefile because libLLVM-2.7.so already exists and --enable-llvm= is specified to configure. Not sure why this didn't fail the same way on i386. Yuri From anton at korobeynikov.info Wed May 5 12:35:45 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 5 May 2010 21:35:45 +0400 Subject: [LLVMdev] LLVM on ARM with the EABI In-Reply-To: References: Message-ID: Hello, Nathan > I'm wondering if LLC supports code generation targeting ARM processors and > using the EABI. Yes. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From skaplan at etinternational.com Wed May 5 12:54:12 2010 From: skaplan at etinternational.com (Sam Kaplan) Date: Wed, 05 May 2010 13:54:12 -0400 Subject: [LLVMdev] Register allocation questions Message-ID: <4BE1B0C4.8020800@etinternational.com> Hello, I am currently working another register allocator for LLVM, and I have a few questions. I have a list of LiveIntervals that interfere with each other, and once I figure out that I need to spill one of these, I'm using LiveIntervals::addIntervalsForSpills to generate spill code. I'm not sure I'm using this function correctly (or if it's even the right thing to use). Here are a few questions: - What exactly is the SpillIs parameter for this function? - The return value is a vector of LiveIntervals, but it looks like they have all been added to the LiveIntervals object already. Is this correct? - Is the Spiller class functional? Using the -new-spill-framework option with the linearscan allocator is giving me crashes. I'm using LLVM 2.6 (it's a project-wide requirement). It doesn't look like much of what I'm using has been changed for 2.7 anyway, but let me know if I'm wrong on this. Thanks, Sam From clattner at apple.com Wed May 5 13:15:10 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 5 May 2010 11:15:10 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: Message-ID: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > This is a brain-dump of my thoughts on the MCStreamer interface after several > days of digging around trying to get a COFF writer working. Great! Something that is worth pointing out is that the MCStreamer API is intended to directly reflect what is happening in .s files. We basically want one MCStreamer callback to correspond to one statement in the .s file. This makes it easier to handle from the compiler standpoint, but is also very important for the llvm-mc assembly parser itself. > All fragments should be associated with a symbol. For assembler components, a > unnammed "virtual" symbol can be used when there is no explicit label defined. What do you mean by fragment? Can you give me an analogy with what the syntax looks like in a .s file, I'm not sure exactly what you mean here. > Section assignment should be the responsiblity of the object imlementing the > MCStreamer interface, with the caller givin the ability to give hints as to > what section to place the symbol into. Section assignment really needs to happen at a higher level. The TargetLoweringObjectFile interfaces are the ones responsible for mapping a global/function -> section. This interface (not mcstreamer) should handle this. The important point here is that the COFF MCSection needs to have the right level of semantic information. In fact, MCSection is the place that I'd start for COFF bringup. > instead of SwitchSection, there would be BeginSymbol, and SymbolSymbol, it would > be illegal to call any EmitXXX function outside of these two calls > > BeginSymbol(Symbol, SectionHint) > EmitAttribute(...) > EmitAttribute(...) > ... > StartFragmentEmission() > EmitFragment(...) > EmitFragment(...) > ... > EndSymbol() > > Object file writers would typically start recording fragments and attributes for > a symbol on the BeginSymbol, then at EndSymbol they would evaluate what was > streamed, and decide what section the symbol should be placed in. Why do you need this? This concept doesn't exist in the .s file, so I don't think that MCStreamer is the right level for this. -Chris From steffen.geissinger at googlemail.com Wed May 5 13:15:16 2010 From: steffen.geissinger at googlemail.com (=?UTF-8?Q?Steffen_Gei=C3=9Finger?=) Date: Wed, 5 May 2010 20:15:16 +0200 Subject: [LLVMdev] bitcode with llvm-gcc (mingw) for windows Message-ID: Hi, i'm currently building a small JIT compiler. For the language I need a runtime library for some special math functions. I think the best would be to compile the lib to bitcode and link it. The compiler should be integrated in a product and as of this, it must work under windows (VC10, 64bit). So is it possible to build the math lib with the mingw llvm-gcc build an link it later with the JITed Code? Or are there any problems regarding the portability of the bitcode build with llvm-gcc under mingw? If there are problems, what solution would you suggest. Regards, Steffen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/29a20eaa/attachment.html From dag at cray.com Wed May 5 14:36:41 2010 From: dag at cray.com (David Greene) Date: Wed, 5 May 2010 14:36:41 -0500 Subject: [LLVMdev] emit after gvn pass? In-Reply-To: <28462901.post@talk.nabble.com> References: <28462901.post@talk.nabble.com> Message-ID: <201005051436.42321.dag@cray.com> On Wednesday 05 May 2010 12:00:18 nonpoly wrote: > Hello again, > Just wondering if there is a flag I can pass when compiling with > llvm-gcc that can emit the llvm IR after the gvn pass (want to see the IR > after dead code elimination/redundancy elimination). If so, will other > passes be performed as well? I really just want to see the IR after the > eliminations only, if it is at all possible. I don't know if the options are linked into llvm-gcc but with opt you can do "-debug -print-after=gvn." You'll get a lot more output than just the IR but it will be there. -Dave From samuraileumas at yahoo.com Wed May 5 15:12:47 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Wed, 5 May 2010 13:12:47 -0700 (PDT) Subject: [LLVMdev] Another bad binutils? Message-ID: <147506.66777.qm@web62005.mail.re1.yahoo.com> After waiting through about 2 hours of hard drive spinning for Clang to link under my Xubuntu Lucid Lynx Linux setup on VirtualBox, ld finally just gave up trying to link it. I was using CMake's build scripts on version 2.7 release of LLVM and Clang. The version of ld is (GNU Binutils for Ubuntu) 2.20.1-system.20100303. Can anyone confirm this problem? If needed I'll cross-post this to the Ubuntu forums. Thanks for your time. From blunted2night at gmail.com Wed May 5 15:22:19 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 5 May 2010 13:22:19 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> Message-ID: On Wed, May 5, 2010 at 11:15 AM, Chris Lattner wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one > statement in the .s file. This makes it easier to handle from the compiler > standpoint, but is also very important for the llvm-mc assembly parser > itself. > > This is an assumption I question. From an evolutionary perspective I agree; Given the existing code base I do see this as a logical transformation. As far as the assembly parser/streamer is concerned it certainly simplifies their implementations. But I also think that this interface could evolve in a direction that simplifies the common case (compiler -> object file) at a small expense to handling assembly language files. > All fragments should be associated with a symbol. For assembler > components, a > > unnammed "virtual" symbol can be used when there is no explicit label > defined. > > What do you mean by fragment? Can you give me an analogy with what the > syntax looks like in a .s file, I'm not sure exactly what you mean here. > I use the term fragment to refer to the MCFragment class and its derivatives. I understand that to mean any entity representing data in the final linked and loaded form. (something with an address) > Section assignment should be the responsiblity of the object imlementing > the > > MCStreamer interface, with the caller givin the ability to give hints as > to > > what section to place the symbol into. > > Section assignment really needs to happen at a higher level. The > TargetLoweringObjectFile interfaces are the ones responsible for mapping a > global/function -> section. This interface (not mcstreamer) should handle > this. > > The important point here is that the COFF MCSection needs to have the right > level of semantic information. In fact, MCSection is the place that I'd > start for COFF bringup. > > OK, I see that now. The current isolation between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has proven somewhat problematic, mostly due to my lack of understanding. I guess MCSectionXXX was meant to provide communication between them. Should the same be true of MCSymbol, and their data counterparts? > > instead of SwitchSection, there would be BeginSymbol, and SymbolSymbol, > it would > > be illegal to call any EmitXXX function outside of these two calls > > > > BeginSymbol(Symbol, SectionHint) > > EmitAttribute(...) > > EmitAttribute(...) > > ... > > StartFragmentEmission() > > EmitFragment(...) > > EmitFragment(...) > > ... > > EndSymbol() > > > > Object file writers would typically start recording fragments and > attributes for > > a symbol on the BeginSymbol, then at EndSymbol they would evaluate what > was > > streamed, and decide what section the symbol should be placed in. > > Why do you need this? This concept doesn't exist in the .s file, so I > don't think that MCStreamer is the right level for this. I realize that my expectations of the MCStreamer interface are not quite the same as the intentions behind its design. It seemed to be that having these calls with the restrictions on when they would be allowed would simplify an object file writers job sifting though the incoming data and organizing into what will become the output file. I had a problem with MCStreamer::EmitCommonSymbol & MCStreamer::EmitLocalCommonSymbol. When I implemented them I assumed this meant to put those symbols into the .bss segment. This required me to get a hold of the TLOF from the streamer. I now realize this is wrong after re-reading the description of the '.comm' directive a few times. I am not sure why an uninitialized global variable was being emitted using this, that seems wrong since global variables in different compilation units with the same name would get merged together at link time. (this is using clang on a C source file) Thanks for taking the time to read and respond to my post. I think I need to get better acquainted with these components. - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/dfea6f12/attachment.html From samuraileumas at yahoo.com Wed May 5 15:34:01 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Wed, 5 May 2010 13:34:01 -0700 (PDT) Subject: [LLVMdev] Another bad binutils? In-Reply-To: <415A2390-0C68-4E24-8FC5-8596FCE07676@gmail.com> References: <147506.66777.qm@web62005.mail.re1.yahoo.com> <415A2390-0C68-4E24-8FC5-8596FCE07676@gmail.com> Message-ID: <687859.42663.qm@web62003.mail.re1.yahoo.com> 384 MBytes RAM ----- Original Message ---- > From: mike-m > To: Samuel Crow > Sent: Wed, May 5, 2010 3:32:20 PM > Subject: Re: [LLVMdev] Another bad binutils? > > How much RAM have you allocated to vbox guest? --mike-m On > 2010-05-05, at 4:12 PM, Samuel Crow wrote: > After waiting through > about 2 hours of hard drive spinning for Clang to link under my Xubuntu Lucid > Lynx Linux setup on VirtualBox, ld finally just gave up trying to link it. > I was using CMake's build scripts on version 2.7 release of LLVM and > Clang. The version of ld is (GNU Binutils for Ubuntu) > 2.20.1-system.20100303. Can anyone confirm this problem? If needed > I'll cross-post this to the Ubuntu forums. Thanks for your time. > > > > > > > _______________________________________________ > LLVM Developers mailing > list > > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu > http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From samuraileumas at yahoo.com Wed May 5 15:41:26 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Wed, 5 May 2010 13:41:26 -0700 (PDT) Subject: [LLVMdev] Another bad binutils? In-Reply-To: <25172369-DCAC-437F-80B2-3ACE22BA81DC@gmail.com> References: <147506.66777.qm@web62005.mail.re1.yahoo.com> <415A2390-0C68-4E24-8FC5-8596FCE07676@gmail.com> <687859.42663.qm@web62003.mail.re1.yahoo.com> <25172369-DCAC-437F-80B2-3ACE22BA81DC@gmail.com> Message-ID: <997646.26537.qm@web62002.mail.re1.yahoo.com> Hi Mike-M, Thanks for the help. It seems I'll have to just download the precompiled binaries since I only have 1 Gig in the entire system I'm using. --Sam ----- Original Message ---- > From: mike-m > To: Samuel Crow > Sent: Wed, May 5, 2010 3:36:34 PM > Subject: Re: [LLVMdev] Another bad binutils? > > You will need a 1GB guest. Linking is the biggest memory hog of the entire build > process. I've measured it to require 850MB to 950MB for linking clang on various > 32 and 64 bit linux distros. If you try and link on a 512MB vbox, it will take > an order (or more) magnitude longer to link due to swapping than a 1GB guest. > --mike-m On 2010-05-05, at 4:34 PM, Samuel Crow > wrote: > 384 MBytes RAM > > > > > > ----- Original Message ---- >> From: mike-m < > ymailto="mailto:mikem.llvm at gmail.com" > href="mailto:mikem.llvm at gmail.com">mikem.llvm at gmail.com> >> To: > Samuel Crow < > href="mailto:samuraileumas at yahoo.com">samuraileumas at yahoo.com> >> > Sent: Wed, May 5, 2010 3:32:20 PM >> Subject: Re: [LLVMdev] Another bad > binutils? >> >> How much RAM have you allocated to vbox > guest? > > --mike-m > > On >> 2010-05-05, at > 4:12 PM, Samuel Crow wrote: > >> After waiting through > >> about 2 hours of hard drive spinning for Clang to link under my > Xubuntu Lucid >> Lynx Linux setup on VirtualBox, ld finally just gave > up trying to link it. >> I was using CMake's build scripts on > version 2.7 release of LLVM and >> Clang. The version of ld is > (GNU Binutils for Ubuntu) >> 2.20.1-system.20100303. Can anyone > confirm this problem? If needed >> I'll cross-post this to the > Ubuntu forums. Thanks for your time. >> >> >> > >> >> >> >> > _______________________________________________ >> LLVM Developers > mailing >> list >> >> href="mailto: > ymailto="mailto:LLVMdev at cs.uiuc.edu" > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu"> > ymailto="mailto:LLVMdev at cs.uiuc.edu" > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu > >> http://llvm.cs.uiuc.edu >> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > From jyasskin at google.com Wed May 5 15:52:00 2010 From: jyasskin at google.com (Jeffrey Yasskin) Date: Wed, 5 May 2010 13:52:00 -0700 Subject: [LLVMdev] Is the option --enable-shared discontinued in 2.7? In-Reply-To: <4BE0BC76.8050400@tsoft.com> References: <4BD76DF8.7040205@tsoft.com> <4BD7F50C.6060007@tsoft.com> <4BD874E9.9060206@tsoft.com> <4BE0BC76.8050400@tsoft.com> Message-ID: On Tue, May 4, 2010 at 5:31 PM, Yuri wrote: > Jeffrey Yasskin wrote: >>> >>> Would you try the patch at >>> http://codereview.appspot.com/download/issue968046_1.diff? It should >>> make the BSDs fall into the same path as Linux, and since you use gnu >>> ld, that should work for you. >>> >> >> Ping? >> > > > Sorry for the delay. > > Here is what I am getting after applying the patch: > gmake[2]: Leaving directory `/tmp/llvm-build/2.7/llvm-objects/lib/CodeGen' > gmake[1]: Leaving directory `/tmp/llvm-build/2.7/llvm-objects/lib' > gmake[1]: Entering directory > `/tmp/llvm-build/2.7/llvm-objects/tools/llvm-shlib' > llvm[1]: Linking Release Shared Library LLVM-2.7.so > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x135): > In function `(anonymous > namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': > : undefined reference to `__assert' > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x3e3): > In function `(anonymous > namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': > : undefined reference to `__assert' > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x5d8): > In function `(anonymous > namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': > : undefined reference to `__assert' > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0xd10): > In function `(anonymous > namespace)::ARMAsmParser::MatchRegisterName(llvm::StringRef const&)': > : undefined reference to `memcmp' > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0xd45): > In function `(anonymous > namespace)::ARMAsmParser::MatchRegisterName(llvm::StringRef const&)': > : undefined reference to `memcmp' > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0xd6d): > In function `(anonymous > namespace)::ARMAsmParser::MatchRegisterName(llvm::StringRef const&)': > : undefined reference to `memcmp' > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0xdd5): > In function `(anonymous > namespace)::ARMAsmParser::MaybeParseRegister((anonymous > namespace)::ARMOperand&, bool)': > : undefined reference to `__assert' > > Linking command line was: > /usr/local/gcc/4.5.0/bin/g++ -I/tmp/llvm-build/2.7/llvm-objects/include > -I/tmp/llvm-build/2.7/llvm-objects/tools/llvm-shlib > -I/tmp/llvm-build/2.7/llvm/include > -I/tmp/llvm-build/2.7/llvm/tools/llvm-shlib ?-D_DEBUG -D_GNU_SOURCE > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 ?-fno-exceptions > -fno-rtti -fPIC -Woverloaded-virtual ? ? -pedantic -Wno-long-long -Wall -W > -Wno-unused-parameter -Wwrite-strings ?-O2 -Wl,-R > -Wl,/tmp/llvm-build/2.7/llvm-objects/Release/lib > -L/tmp/llvm-build/2.7/llvm-objects/Release/lib > -L/tmp/llvm-build/2.7/llvm-objects/Release/lib ?-shared -o > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVM-2.7.so > -Wl,--whole-archive -lLLVMARMAsmParser -lLLVMARMAsmPrinter -lLLVMARMCodeGen > -lLLVMARMInfo -lLLVMAlphaAsmPrinter -lLLVMAlphaCodeGen -lLLVMAlphaInfo > -lLLVMAnalysis -lLLVMArchive -lLLVMAsmParser -lLLVMAsmPrinter > -lLLVMBitReader -lLLVMBitWriter -lLLVMBlackfinAsmPrinter > -lLLVMBlackfinCodeGen -lLLVMBlackfinInfo -lLLVMCBackend -lLLVMCBackendInfo > -lLLVMCellSPUAsmPrinter -lLLVMCellSPUCodeGen -lLLVMCellSPUInfo -lLLVMCodeGen > -lLLVMCore -lLLVMCppBackend -lLLVMCppBackendInfo -lLLVMExecutionEngine > -lLLVMInstCombine -lLLVMInstrumentation -lLLVMInterpreter -lLLVMJIT > -lLLVMLinker -lLLVMMBlazeAsmPrinter -lLLVMMBlazeCodeGen -lLLVMMBlazeInfo > -lLLVMMC -lLLVMMCParser -lLLVMMSIL -lLLVMMSILInfo -lLLVMMSP430AsmPrinter > -lLLVMMSP430CodeGen -lLLVMMSP430Info -lLLVMMipsAsmPrinter -lLLVMMipsCodeGen > -lLLVMMipsInfo -lLLVMPIC16AsmPrinter -lLLVMPIC16CodeGen -lLLVMPIC16Info > -lLLVMPowerPCAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCInfo > -lLLVMScalarOpts -lLLVMSelectionDAG -lLLVMSparcAsmPrinter -lLLVMSparcCodeGen > -lLLVMSparcInfo -lLLVMSupport -lLLVMSystem -lLLVMSystemZAsmPrinter > -lLLVMSystemZCodeGen -lLLVMSystemZInfo -lLLVMTarget -lLLVMTransformUtils > -lLLVMX86AsmParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen > -lLLVMX86Disassembler -lLLVMX86Info -lLLVMXCoreAsmPrinter -lLLVMXCoreCodeGen > -lLLVMXCoreInfo -lLLVMipa -lLLVMipo -lLLVMpic16passes -Wl,--no-whole-archive > -Wl,--no-undefined -lpthread -lm > > Adding -lc in the end fixes the errors and produces the full size > libLLVM-2.7.so. That's odd. On Linux, g++ adds -lc to the end of the link line itself. It must be adding -lstdc++ for you too, or you'd have more missing symbols. If you run that command with "-v", it'll show you the actual link line, but given your errors it does seem like -lc is missing. I don't think it'll hurt anyone else to add that, so I'll try it. I assume builds without --enable-shared do work for you? If so, I wonder why g++ would omit -lc for shared links but not executable links? Jeffrey From yuri at tsoft.com Wed May 5 15:58:33 2010 From: yuri at tsoft.com (Yuri) Date: Wed, 05 May 2010 13:58:33 -0700 Subject: [LLVMdev] Is the option --enable-shared discontinued in 2.7? In-Reply-To: References: <4BD76DF8.7040205@tsoft.com> <4BD7F50C.6060007@tsoft.com> <4BD874E9.9060206@tsoft.com> <4BE0BC76.8050400@tsoft.com> Message-ID: <4BE1DBF9.7080303@tsoft.com> Jeffrey Yasskin wrote: > That's odd. On Linux, g++ adds -lc to the end of the link line itself. > It must be adding -lstdc++ for you too, or you'd have more missing > symbols. If you run that command with "-v", it'll show you the actual > link line, but given your errors it does seem like -lc is missing. I > don't think it'll hurt anyone else to add that, so I'll try it. > That looks odd to me too, but somehow this happens. I used the patch to fix this, see attachment. > I assume builds without --enable-shared do work for you? If so, I > wonder why g++ would omit -lc for shared links but not executable > links? > Yes, without --enable-shared everything is fine. Yuri -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: llvm-patch-so.diff Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/9fd9c3fc/attachment.pl From steffen.geissinger at googlemail.com Wed May 5 16:08:15 2010 From: steffen.geissinger at googlemail.com (=?UTF-8?Q?Steffen_Gei=C3=9Finger?=) Date: Wed, 5 May 2010 23:08:15 +0200 Subject: [LLVMdev] LLVM: bitcode with llvm-gcc (mingw) for windows Message-ID: Hi, i'm currently building a small JIT compiler. For the language I need a runtime library for some special math functions. I think the best would be to compile the lib to bitcode and link it. The compiler should be integrated in a product and as of this, it must work under windows (VC10, 64bit). So is it possible to build the math lib with the mingw llvm-gcc build an link it later with the JITed Code? Or are there any problems regarding the portability of the bitcode build with llvm-gcc under mingw? If there are problems, what solution would you suggest? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/0062286a/attachment.html From eli.friedman at gmail.com Wed May 5 16:11:53 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 5 May 2010 14:11:53 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> Message-ID: On Wed, May 5, 2010 at 1:22 PM, Nathan Jeffords wrote: > I had a problem with MCStreamer::EmitCommonSymbol > &?MCStreamer::EmitLocalCommonSymbol. When I implemented them I assumed this > meant to put those symbols into the .bss segment. This required me to get a > hold of the TLOF from the streamer. I now realize this is wrong after > re-reading the description of the '.comm' directive a few times. ?I am not > sure why an?uninitialized?global variable was being emitted using this, that > seems wrong since global variables in different compilation units with the > same name would get merged together at link time. (this is using clang on a > C source file) Global definitions like "int x;" are treated as common to allow linking buggy programs that forget to use "extern" on declarations. -Eli From blunted2night at gmail.com Wed May 5 16:32:58 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 5 May 2010 14:32:58 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> Message-ID: > > > Global definitions like "int x;" are treated as common to allow > linking buggy programs that forget to use "extern" on declarations. Is this always the behavior, or only when certain options are set? This seems like a violation of the language standard. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/462b7188/attachment.html From dalej at apple.com Wed May 5 16:45:35 2010 From: dalej at apple.com (Dale Johannesen) Date: Wed, 5 May 2010 14:45:35 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> Message-ID: On May 5, 2010, at 2:32 PMPDT, Nathan Jeffords wrote: > > Global definitions like "int x;" are treated as common to allow > linking buggy programs that forget to use "extern" on declarations. > > Is this always the behavior, or only when certain options are set? This seems like a violation of the language standard. Technically yes; the original K&R C book had the one-definition rule in it. Early C compilers did not work this way, however, and by the time that book was published (1978) there was already a large body of code that assumed the "common" model (also Ritchie's preference, I believe). In practice most compilers still default to this model because a lot of widely used stuff will break if they don't, and the behavior is given in J.5.11 of C99 as a common extension. Use -fno-common to turn it off. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/9ea61ead/attachment.html From blunted2night at gmail.com Wed May 5 16:48:44 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 5 May 2010 14:48:44 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> Message-ID: Somewhere I had got it in my head that global variables had static storage class by default. I guess I was wrong. On May 5, 2010 2:45 PM, "Dale Johannesen" wrote: On May 5, 2010, at 2:32 PMPDT, Nathan Jeffords wrote: >> >> Global definitions like "int x;" are t... Technically yes; the original K&R C book had the one-definition rule in it. Early C compilers did not work this way, however, and by the time that book was published (1978) there was already a large body of code that assumed the "common" model (also Ritchie's preference, I believe). In practice most compilers still default to this model because a lot of widely used stuff will break if they don't, and the behavior is given in J.5.11 of C99 as a common extension. Use -fno-common to turn it off. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/ef477be9/attachment.html From eltoder at gmail.com Wed May 5 16:52:52 2010 From: eltoder at gmail.com (Eugene Toder) Date: Wed, 5 May 2010 22:52:52 +0100 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> Message-ID: Re having all fragments associated with some symbol -- this makes sense if you think in high level terms and assume all symbols to be some "objects". All data (fragments) you want to output is associated with some "object" (symbol). However, that's probably too high level thinking for MC interface. High level objects might not directly correspond to object-file level symbols. For example, module level inline assembler does not correspond to any symbol, or function may have more than one symbol when aliases are used. Common is not .bss, it's an archaic concept inherited from Fortran. C language specifies that global uninitialized variables are put into common. This isn't for "programs that forget to use extern" -- you can't get the same behaviour with extern, common variables are glued together and with "normal" variables, so no object is exclusively owns the variable. There's also some subtle difference when linking archives. Eugene On Wed, May 5, 2010 at 10:32 PM, Nathan Jeffords wrote: >> >> Global definitions like "int x;" are treated as common to allow >> linking buggy programs that forget to use "extern" on declarations. > > Is this always the behavior, or only when certain options are set? This > seems like a violation of the language standard. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From yuri at tsoft.com Wed May 5 18:05:29 2010 From: yuri at tsoft.com (Yuri) Date: Wed, 05 May 2010 16:05:29 -0700 Subject: [LLVMdev] How to cast an integer array to an integer pointer? (user question) Message-ID: <4BE1F9B9.3070100@tsoft.com> I am new to LLVM and couldn't find any llvm-user list, so I am posting my user question here, sorry. I am trying to create a simple "puts" call accepting the static string, with the code below. The last line (CallInst::Create) fails with an assert: "Calling a function with a bad signature!" Because the type of function is void(u8*) and the argument supplied is: getelementptr inbounds [4 x i8]* @0, i32 0 How to convert the pointer to the array to u8* ? I tried BitCastInst but it inserts an explicit bitcast. I don't think this is right. Yuri // assume BasicBlock *BB, Module *M // global string std::vector Ivars; Ivars.push_back(llvm::ConstantInt::get(Type::getInt8Ty(Context), 0x41)); Ivars.push_back(llvm::ConstantInt::get(Type::getInt8Ty(Context), 0x42)); Ivars.push_back(llvm::ConstantInt::get(Type::getInt8Ty(Context), 0x43)); Ivars.push_back(llvm::ConstantInt::get(Type::getInt8Ty(Context), 0)); GlobalVariable *GGV = new GlobalVariable( *M, ArrayType::get(Type::getInt8Ty(Context), 4), true, GlobalValue::PrivateLinkage, llvm::ConstantArray::get(ArrayType::get(Type::getInt8Ty(Context), 4), Ivars), "g_value_mine", 0, false, 0/*AddrSpace*/); // ptr GetElementPtrInst *gepi = GetElementPtrInst::CreateInBounds( GGV, ConstantInt::get(Type::getInt32Ty(Context), 0), "zzz", BB ); // func call Function *PutsF = cast(M->getOrInsertFunction("puts", Type::getVoidTy(Context), Type::getInt8Ty(Context)->getPointerTo(), (Type *)0)); CallInst::Create(PutsF, (Value* const*)&gepi, (Value* const*)(&gepi)+1, "", BB); From luoyonggang at gmail.com Wed May 5 18:23:11 2010 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Thu, 6 May 2010 07:23:11 +0800 Subject: [LLVMdev] Why llvm function name is different with . and .. In-Reply-To: References: Message-ID: Its seems an bug in langref, is there anyone have an look or give an explain? 2010/5/5, ???(Yonggang Luo) : > declare i8 @llvm.atomic.load.max.i8.p0i8( i8* , i8 ) > declare i16 @llvm.atomic.load.max.i16.p0i16( i16* , i16 ) > declare i32 @llvm.atomic.load.max.i32.p0i32( i32* , i32 ) > declare i64 @llvm.atomic.load.max.i64.p0i64( i64* , i64 ) > declare i8 @llvm.atomic.load.min.i8.p0i8( i8* , i8 ) > declare i16 @llvm.atomic.load.min.i16.p0i16( i16* , i16 ) > declare i32 @llvm.atomic.load.min.i32..p0i32( i32* , i32 ) > declare i64 @llvm.atomic.load.min.i64..p0i64( i64* , i64 ) > declare i8 @llvm.atomic.load.umax.i8.p0i8( i8* , i8 ) > declare i16 @llvm.atomic.load.umax.i16.p0i16( i16* , i16 ) > declare i32 @llvm.atomic.load.umax.i32.p0i32( i32* , i32 ) > declare i64 @llvm.atomic.load.umax.i64.p0i64( i64* , i64 ) > declare i8 @llvm.atomic.load.umin.i8..p0i8( i8* , i8 ) > declare i16 @llvm.atomic.load.umin.i16.p0i16( i16* , i16 ) > declare i32 @llvm.atomic.load.umin.i32..p0i32( i32* , i32 ) > declare i64 @llvm.atomic.load.umin.i64..p0i64( i64* , i64 ) > > Why in the llvm function name, some functions containing "..", but > others only contains only "." > Thanks. > -- > ?? > ? > ??? > Yours > sincerely, > Yonggang Luo > -- ????????? ?? ? ??? Yours sincerely, Yonggang Luo From clattner at apple.com Wed May 5 18:30:34 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 5 May 2010 16:30:34 -0700 Subject: [LLVMdev] Why llvm function name is different with . and .. In-Reply-To: References: Message-ID: <8C0EEC2E-3EED-4BE5-A699-78C02B725240@apple.com> On May 5, 2010, at 4:23 PM, ???(Yonggang Luo) wrote: > Its seems an bug in langref, is there anyone have an look or give an explain? > It's a bug in langref, fixed in r103134 From clattner at apple.com Wed May 5 18:37:09 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 5 May 2010 16:37:09 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> Message-ID: <62912497-D064-41C0-8B79-783D2333981F@apple.com> On May 5, 2010, at 1:22 PM, Nathan Jeffords wrote: > On Wed, May 5, 2010 at 11:15 AM, Chris Lattner wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one statement in the .s file. This makes it easier to handle from the compiler standpoint, but is also very important for the llvm-mc assembly parser itself. > > This is an assumption I question. From an evolutionary perspective I agree; Given the existing code base I do see this as a logical transformation. As far as the assembly parser/streamer is concerned it certainly simplifies their implementations. But I also think that this interface could evolve in a direction that simplifies the common case (compiler -> object file) at a small expense to handling assembly language files. The logic to handle this has to go somewhere, putting it in the MCStreamer *implementation* that needs it is the most logical place. We also aim to implement an assembler, it doesn't make sense to duplicate this logic in the compiler and the assembler parser. > > All fragments should be associated with a symbol. For assembler components, a > > unnammed "virtual" symbol can be used when there is no explicit label defined. > > What do you mean by fragment? Can you give me an analogy with what the syntax looks like in a .s file, I'm not sure exactly what you mean here. > > I use the term fragment to refer to the MCFragment class and its derivatives. I understand that to mean any entity representing data in the final linked and loaded form. (something with an address) Ok, MCFragment should definitely be formed behind the MCStreamer implementation. The .s printing implementation of MCStreamer, for example, has no use for it. With the current design, it would be a layering violation to make it earlier. > > > Section assignment should be the responsiblity of the object imlementing the > > MCStreamer interface, with the caller givin the ability to give hints as to > > what section to place the symbol into. > > Section assignment really needs to happen at a higher level. The TargetLoweringObjectFile interfaces are the ones responsible for mapping a global/function -> section. This interface (not mcstreamer) should handle this. > > The important point here is that the COFF MCSection needs to have the right level of semantic information. In fact, MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has proven somewhat problematic, mostly due to my lack of understanding. I guess MCSectionXXX was meant to provide communication between them. Should the same be true of MCSymbol, and their data counterparts? Yes somewhat. Currently, the COFF implementation of the assembler backend should maintain a DenseMap from MCSymbol* to whatever data you need to associate with a symbol. This is equivalent to embedding per-symbol stuff in the MCSymbol itself. MCSection should be subclassed and you should put COFF specific stuff in MCSectionCOFF. > I had a problem with MCStreamer::EmitCommonSymbol & MCStreamer::EmitLocalCommonSymbol. When I implemented them I assumed this meant to put those symbols into the .bss segment. This required me to get a hold of the TLOF from the streamer. I now realize this is wrong after re-reading the description of the '.comm' directive a few times. I am not sure why an uninitialized global variable was being emitted using this, that seems wrong since global variables in different compilation units with the same name would get merged together at link time. (this is using clang on a C source file) As others have pointed out, this is one of the many horrors of C :) -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/98610cd2/attachment-0001.html From blunted2night at gmail.com Wed May 5 18:38:35 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 5 May 2010 16:38:35 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> Message-ID: On Wed, May 5, 2010 at 2:52 PM, Eugene Toder wrote: > Re having all fragments associated with some symbol -- this makes > sense if you think in high level terms and assume all symbols to be > some "objects". All data (fragments) you want to output is associated > with some "object" (symbol). However, that's probably too high level > thinking for MC interface. High level objects might not directly > correspond to object-file level symbols. I agree with you one this, to me its a question of whose responsibility it is to determine the mapping, the compiler or the object file format. Another example would be labels, they are not high level objects in an of themselves, but must be represented as symbols in current object file formats. For example, module level > inline assembler does not correspond to any symbol, or function may > have more than one symbol when aliases are used. > module level assembly could easily be dealt with as an unnamed symbol that the object file is free to not create a object-level symbol for (though the only context I can see a use for this I think it would still be useful to identity such code). When you say aliases, I assume you mean embedding object level symbol records pointing to the same high-level symbol. A high level symbol could easily report multiple names though its interface. > Common is not .bss, it's an archaic concept inherited from Fortran. C > language specifies that global uninitialized variables are put into > common. This isn't for "programs that forget to use extern" -- you > can't get the same behaviour with extern, common variables are glued > together and with "normal" variables, so no object is exclusively owns > the variable. There's also some subtle difference when linking > archives. > Thanks for the details of this, I will have to update my COFF writer to properly put these symbols into a COMDAT section, as I currently put them into .bss section with static linkage. - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/ef936619/attachment.html From ayoga at umail.iu.edu Wed May 5 19:12:42 2010 From: ayoga at umail.iu.edu (Adarsh Yoga) Date: Wed, 5 May 2010 20:12:42 -0400 Subject: [LLVMdev] Unreachable code executed crash Message-ID: Hi, I've written a pass that basically does some code transformations to enable parallel execution of loops. After the transformation llvm runs BitCode Writer pass , which is aborting with Unreachable Executed error. I have attached the input llvm code and the output llvm code for reference. I am stuck at this problem for a few days now. Please let me know if you are able to find anything unusual. Regards, Adarsh -- Adarsh Yoga Graduate Student, Computer Science Indiana University, Bloomington -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/367f37fd/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: input Type: application/octet-stream Size: 4038 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/367f37fd/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: output Type: application/octet-stream Size: 6011 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/367f37fd/attachment-0001.obj From blunted2night at gmail.com Wed May 5 19:22:38 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 5 May 2010 17:22:38 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: <62912497-D064-41C0-8B79-783D2333981F@apple.com> References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <62912497-D064-41C0-8B79-783D2333981F@apple.com> Message-ID: > > > The logic to handle this has to go somewhere, putting it in the MCStreamer > *implementation* that needs it is the most logical place. We also aim to > implement an assembler, it doesn't make sense to duplicate this logic in the > compiler and the assembler parser. > > Assembly language has often been *the* intermediate form for between compilers and object files/executables, but I don't think its the most effective form. That said I have limited experience writing code generators so my opinions do not bear the wisdom of you and other developers of this library on this topic. > All fragments should be associated with a symbol. For assembler >> components, a >> > unnammed "virtual" symbol can be used when there is no explicit label >> defined. >> >> What do you mean by fragment? Can you give me an analogy with what the >> syntax looks like in a .s file, I'm not sure exactly what you mean here. > > >> I use the term fragment to refer to the MCFragment class and > its derivatives. I understand that to mean any entity representing data in > the final linked and loaded form. (something with an address) > > > Ok, MCFragment should definitely be formed behind the MCStreamer > implementation. The .s printing implementation of MCStreamer, for example, > has no use for it. With the current design, it would be a layering > violation to make it earlier. > > I agree with this completely, I quite like that aspect of the design: The streamer putting fragments into sections and allowing the assembler to combine it all resolving fix-ups when it can, letting the writer deal those it can't. > Yes somewhat. Currently, the COFF implementation of the assembler backend > should maintain a DenseMap from MCSymbol* to whatever data you need to > associate with a symbol. This is equivalent to embedding per-symbol stuff > in the MCSymbol itself. MCSection should be subclassed and you should put > COFF specific stuff in MCSectionCOFF. > > I think this is an important detail I was missing. I can already see how this will help with COMDAT sections. Is there any reason for the difference between symbol and section in this respect? As others have pointed out, this is one of the many horrors of C :) > > Another reason why I am attempting to develop my own language. :) p.s. I posted my coff backend patch to llvm-commit, but that apears to be the wrong place, where should I have posted it? - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/91acc053/attachment.html From nlewycky at google.com Wed May 5 19:39:09 2010 From: nlewycky at google.com (Nick Lewycky) Date: Wed, 5 May 2010 17:39:09 -0700 Subject: [LLVMdev] Unreachable code executed crash In-Reply-To: References: Message-ID: On 5 May 2010 17:12, Adarsh Yoga wrote: > Hi, > > I've written a pass that basically does some code transformations to > enable parallel execution of loops. After the transformation llvm runs > BitCode Writer pass , which is aborting with Unreachable Executed error. > I have attached the input llvm code and the output llvm code for reference. > I am stuck at this problem for a few days now. Please let me know if you are > able to find anything unusual. > Have you tried running the module verifier after your transform, before writing out to bitcode? Nick > Regards, > Adarsh > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington > > _______________________________________________ > 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/20100505/d2893de3/attachment.html From clattner at apple.com Wed May 5 19:53:11 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 5 May 2010 17:53:11 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <62912497-D064-41C0-8B79-783D2333981F@apple.com> Message-ID: On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: > > The logic to handle this has to go somewhere, putting it in the MCStreamer *implementation* that needs it is the most logical place. We also aim to implement an assembler, it doesn't make sense to duplicate this logic in the compiler and the assembler parser. > > > Assembly language has often been *the* intermediate form for between compilers and object files/executables, but I don't think its the most effective form. That said I have limited experience writing code generators so my opinions do not bear the wisdom of you and other developers of this library on this topic. I completely agree, but it is a very important and effective form of communication :) One nice fallout of the MCStreamer design is that once the COFF writer is available, we'll have a stand-alone coff assembler mostly "for free". In fact, developing this as a coff assembler (which can be accessed with 'llvm-mc foo.s -o foo.obj -filetype=obj') is easier in a lot of ways than dealing with the compiler! > > Yes somewhat. Currently, the COFF implementation of the assembler backend should maintain a DenseMap from MCSymbol* to whatever data you need to associate with a symbol. This is equivalent to embedding per-symbol stuff in the MCSymbol itself. MCSection should be subclassed and you should put COFF specific stuff in MCSectionCOFF. > >> > > I think this is an important detail I was missing. I can already see how this will help with COMDAT sections. Is there any reason for the difference between symbol and section in this respect? You'd have to ask Daniel about this. I don't recall if this is a short term thing that he'd like to fix or if this is an important design decision. > > As others have pointed out, this is one of the many horrors of C :) > > > Another reason why I am attempting to develop my own language. :) > > p.s. I posted my coff backend patch to llvm-commit, but that apears to be the wrong place, where should I have posted it? llvm-commits is a great place for it! -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/b3168959/attachment.html From ayoga at umail.iu.edu Wed May 5 20:08:19 2010 From: ayoga at umail.iu.edu (Adarsh Yoga) Date: Wed, 5 May 2010 21:08:19 -0400 Subject: [LLVMdev] Unreachable code executed crash In-Reply-To: References: Message-ID: Yes. Intially the pass was crashing when the module when the module verifier was running. I was able to solve that and now it is crashing when the bit writer pass is running. On Wed, May 5, 2010 at 8:39 PM, Nick Lewycky wrote: > On 5 May 2010 17:12, Adarsh Yoga wrote: > >> Hi, >> >> I've written a pass that basically does some code transformations to >> enable parallel execution of loops. After the transformation llvm runs >> BitCode Writer pass , which is aborting with Unreachable Executed error. >> I have attached the input llvm code and the output llvm code for >> reference. I am stuck at this problem for a few days now. Please let me know >> if you are able to find anything unusual. >> > > Have you tried running the module verifier after your transform, before > writing out to bitcode? > > Nick > > >> Regards, >> Adarsh >> >> -- >> Adarsh Yoga >> Graduate Student, Computer Science >> Indiana University, Bloomington >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > -- Adarsh Yoga Graduate Student, Computer Science Indiana University, Bloomington -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/1c96951d/attachment.html From rb5 at rice.edu Wed May 5 15:01:38 2010 From: rb5 at rice.edu (Rajkishore Barik) Date: Wed, 5 May 2010 15:01:38 -0500 Subject: [LLVMdev] Auto-Vectorization in LLVM Message-ID: <75698E3D-ED28-434A-94B5-ED99481C4D06@rice.edu> Hi, I found out that Auto-Vectorization was implemented as a part of GSoC 2009. Can someone point me to the code repository including any documentation available? I would also like to know if there is any progress/future plans to include this in the main trunk? Best Regards, Raj From rnk at mit.edu Wed May 5 20:35:03 2010 From: rnk at mit.edu (Reid Kleckner) Date: Wed, 5 May 2010 21:35:03 -0400 Subject: [LLVMdev] bitcode with llvm-gcc (mingw) for windows In-Reply-To: References: Message-ID: On Wed, May 5, 2010 at 2:15 PM, Steffen Gei?inger wrote: > Hi, > i'm currently building a small JIT compiler. > For the language I need a runtime library for some special math functions. > I think the best would be to compile the lib to bitcode and link it. > The compiler should be integrated in a product and as of this, it must work > under windows (VC10, 64bit). > So is it possible to build the math lib with the mingw llvm-gcc build an > link it later with the JITed Code? > Or are there any problems regarding?the portability of the bitcode build > with llvm-gcc under mingw? > If there are problems, what solution would you suggest. Sounds reasonable. Just read the bitcode from the filesystem and pass the module it yields to the JIT when you create it. IR generated by C frontends isn't portable (they lower things like sizeof and handle certain elements of ABI compatibility), so the bitcode would be restricted to the target you compile it for. Reid From eli.friedman at gmail.com Wed May 5 20:41:08 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 5 May 2010 18:41:08 -0700 Subject: [LLVMdev] How to cast an integer array to an integer pointer? (user question) In-Reply-To: <4BE1F9B9.3070100@tsoft.com> References: <4BE1F9B9.3070100@tsoft.com> Message-ID: On Wed, May 5, 2010 at 4:05 PM, Yuri wrote: > I am new to LLVM and couldn't find any llvm-user list, so I am posting > my user question here, sorry. This is the right mailing list for user questions. > I am trying to create a simple "puts" call accepting the static string, > with the code below. > The last line (CallInst::Create) fails with an assert: "Calling a > function with a bad signature!" > Because the type of function is void(u8*) and the argument supplied is: > getelementptr inbounds [4 x i8]* @0, i32 0 > How to convert the pointer to the array to u8* ? I tried BitCastInst but > it inserts an explicit bitcast. I don't think this is right. I think you're misunderstanding how the getelementptr instruction works; see http://llvm.org/docs/GetElementPtr.html , and try adding a call to "gepi->getType()->dump()". -Eli From blunted2night at gmail.com Wed May 5 20:44:12 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 5 May 2010 18:44:12 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: <15F4FDD1-2764-433D-A7CA-70165A49B64D@apple.com> References: <15F4FDD1-2764-433D-A7CA-70165A49B64D@apple.com> Message-ID: ... > Thanks, applied in r103150! llvm-mc -filetype=obj probably needs a similar > patch. > > cool!, I will make that change and submit it too. > ... > Yes probably, I don't know what the .def and .scl directives "do" :) > > I think I can figure out the right thing to do here. > Also, w.r.t. section handling stuff, there is this fixme in the asmprinter: > > } else if (const char *LinkOnce = MAI->getLinkOnceDirective()) { > // .globl _foo > OutStreamer.EmitSymbolAttribute(GVSym, MCSA_Global); > // FIXME: linkonce should be a section attribute, handled by COFF > Section > // assignment. > // > http://sourceware.org/binutils/docs-2.20/as/Linkonce.html#Linkonce > // .linkonce discard > // FIXME: It would be nice to use .linkonce samesize for non-common > // globals. > OutStreamer.EmitRawText(StringRef(LinkOnce)); > } else { > > Basically, it seems like the MCSectionCOFF implementation should get the > linkonce bit. I'm not an expert on COFF, but I think that's the right place > for it. ".linkonce" will also have to be added as a new MCStreamer api, > which would set the bit. > > linkonce is one option for COFF COMDAT sections. I think that this call should not exist at all, instead, when the AsmPrinter asks the TLOF what section to use for the global, TLOF should create a new unique section with the bit set already. One thing that I don't understand is why common symbols do not get sections assigned to them. I ended up assigning them to the '.bss' section in my streamer (which I now know was wrong) but it still seems like they should be part of some section. At least in COFF, they will be handled as a COMDAT just like symbols with the linkonce linkage type. I guess this all goes back to the assembly language view of things. I think I have enough information to handle these things correctly now. Thanks for the feedback. - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/297528de/attachment.html From proljc at gmail.com Wed May 5 20:49:21 2010 From: proljc at gmail.com (=?GB2312?B?sK66w9Xf?=) Date: Thu, 6 May 2010 09:49:21 +0800 Subject: [LLVMdev] Config LLVM with --enable-targets=arm , how to make Clang generate code for ARM Cortex-A8? Message-ID: hi all I use --enable-targets=arm configure LLVM, build it with Clang, but when I using Clang, it say: #clang -triple /root/a.c error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.' 1 diagnostic generated. How can I use Clang generate code for ARM Cortex-A8? thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100506/abccf4ce/attachment.html From clattner at apple.com Wed May 5 23:34:11 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 5 May 2010 21:34:11 -0700 Subject: [LLVMdev] Auto-Vectorization in LLVM In-Reply-To: <75698E3D-ED28-434A-94B5-ED99481C4D06@rice.edu> References: <75698E3D-ED28-434A-94B5-ED99481C4D06@rice.edu> Message-ID: <1759D124-633F-454C-9562-813001C2CEAE@apple.com> On May 5, 2010, at 1:01 PM, Rajkishore Barik wrote: > Hi, > > I found out that Auto-Vectorization was implemented as a part of GSoC > 2009. > Can someone point me to the code repository including any > documentation available? > I would also like to know if there is any progress/future plans to > include this > in the main trunk? Unfortunately, nothing came of this project AFAIK, maybe Devang knows more. -Chris From clattner at apple.com Wed May 5 23:38:18 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 5 May 2010 21:38:18 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: <15F4FDD1-2764-433D-A7CA-70165A49B64D@apple.com> Message-ID: On May 5, 2010, at 6:44 PM, Nathan Jeffords wrote: > ... > Thanks, applied in r103150! llvm-mc -filetype=obj probably needs a similar patch. > > > cool!, I will make that change and submit it too. Thanks! > Also, w.r.t. section handling stuff, there is this fixme in the asmprinter: > > } else if (const char *LinkOnce = MAI->getLinkOnceDirective()) { > // .globl _foo > OutStreamer.EmitSymbolAttribute(GVSym, MCSA_Global); > // FIXME: linkonce should be a section attribute, handled by COFF Section > // assignment. > // http://sourceware.org/binutils/docs-2.20/as/Linkonce.html#Linkonce > // .linkonce discard > // FIXME: It would be nice to use .linkonce samesize for non-common > // globals. > OutStreamer.EmitRawText(StringRef(LinkOnce)); > } else { > > Basically, it seems like the MCSectionCOFF implementation should get the linkonce bit. I'm not an expert on COFF, but I think that's the right place for it. ".linkonce" will also have to be added as a new MCStreamer api, which would set the bit. > > > linkonce is one option for COFF COMDAT sections. I think that this call should not exist at all, instead, when the AsmPrinter asks the TLOF what section to use for the global, TLOF should create a new unique section with the bit set already. Yeah, I completely agree. That's what I was thinking when I wrote that comment :). However, doing it that way would break .s emission, which is "bad" :) Also, to implement a COFF assembler, we'd need to support the .linkonce directive. To me, it seems most straight-forward to just support .linkonce as a MCStreamer callback. > One thing that I don't understand is why common symbols do not get sections assigned to them. I ended up assigning them to the '.bss' section in my streamer (which I now know was wrong) but it still seems like they should be part of some section. At least in COFF, they will be handled as a COMDAT just like symbols with the linkonce linkage type. > > I guess this all goes back to the assembly language view of things. I think I have enough information to handle these things correctly now. I'm not sure (all I know about COFF is what's on this page: http://www.nondot.org/sabre/os/articles/ExecutableFileFormats/) but you can find out by making a .s file, running it through a coff assembler (like gas) and seeing what bits it produces. When working on the macho assembler, we found it very very useful to produce bitwise identical output to the system assembler, allowing us to just diff the .o files. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/2872c911/attachment.html From yuri at tsoft.com Thu May 6 01:02:09 2010 From: yuri at tsoft.com (Yuri) Date: Wed, 05 May 2010 23:02:09 -0700 Subject: [LLVMdev] Failure to compile llvm-gcc-4.2-2.7 on FreeBSD on sparc machine Message-ID: <4BE25B61.8000905@tsoft.com> llvm itself compiles fine. gcc frontend has the error, see below. I applied the attached patch, since the name of architecture on FreeBSD is sparc64, not sparc. There is also one more replacement sparc -> spaarc64 was made in gcc/Makefile in llvm-gcc. FreeBSD -8.0-STABLE gcc-4.5.0 sunblade 100 Yuri gmake[2]: Leaving directory `/tmp/llvm-build/2.7/llvm-gcc-4.2-objects/libdecnumber' gmake[2]: Entering directory `/tmp/llvm-build/2.7/llvm-gcc-4.2-objects/gcc' /tmp/llvm-build/2.7/llvm-gcc-4.2-objects/./gcc/xgcc -B/tmp/llvm-build/2.7/llvm-gcc-4.2-objects/./gcc/ -B/usr/local/llvm/2.7/sparc64-unknown-freebsd8.0/bin/ -B/usr/local/llvm/2.7/sparc64-unknown-freebsd8.0/lib/ -isystem /usr/local/llvm/2.7/sparc64-unknown-freebsd8.0/include -isystem /usr/local/llvm/2.7/sparc64-unknown-freebsd8.0/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc-4.2/gcc -I../../llvm-gcc-4.2/gcc/. -I../../llvm-gcc-4.2/gcc/../include -I./../intl -I../../llvm-gcc-4.2/gcc/../libcpp/include -I/usr/local/include -I../../llvm-gcc-4.2/gcc/../libdecnumber -I../libdecnumber -I/tmp/llvm-build/2.7/llvm-gcc-4.2-objects/../llvm-objects/include -I/tmp/llvm-build/2.7/llvm/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder \ -c ../../llvm-gcc-4.2/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o GCC: > public unsigned DI size constant invariant 64> unit size constant invariant 8> align 64 symtab 0 alias set -1 pointer_to_this > LLVM: i8* (32 bits) LLVM type size doesn't match GCC type size!../../llvm-gcc-4.2/gcc/crtstuff.c:267: internal compiler error: in llvm_set_type, at llvm-types.cpp:89 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: llvm-patch-sparc64.diff Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/a0d2b132/attachment-0001.pl From blunted2night at gmail.com Thu May 6 01:19:37 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 5 May 2010 23:19:37 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: <15F4FDD1-2764-433D-A7CA-70165A49B64D@apple.com> Message-ID: On Wed, May 5, 2010 at 9:38 PM, Chris Lattner wrote: > On May 5, 2010, at 6:44 PM, Nathan Jeffords wrote: > > ... >> Thanks, applied in r103150! llvm-mc -filetype=obj probably needs a >> similar patch. >> >> > cool!, I will make that change and submit it too. > > > Thanks! > > After looking into this, I have found that AsmParser is hard coded to use MachO sections which causes my code to segfault, reworking this code to use TargetLoweringObjectFile or some equivalent is a larger change than I am comfortable with at the moment. On the other hand, llc, clang, and (according to Aaron) llvm-gcc all work with my COFF backend, so I will continue to work on it using one of those to test it. > - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/f40371e6/attachment.html From clattner at apple.com Thu May 6 01:29:07 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 5 May 2010 23:29:07 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: <15F4FDD1-2764-433D-A7CA-70165A49B64D@apple.com> Message-ID: On May 5, 2010, at 11:19 PM, Nathan Jeffords wrote: > > > On Wed, May 5, 2010 at 9:38 PM, Chris Lattner wrote: > On May 5, 2010, at 6:44 PM, Nathan Jeffords wrote: >> ... >> Thanks, applied in r103150! llvm-mc -filetype=obj probably needs a similar patch. >> >> >> cool!, I will make that change and submit it too. > > Thanks! > > > After looking into this, I have found that AsmParser is hard coded to use MachO sections which causes my code to segfault, reworking this code to use TargetLoweringObjectFile or some equivalent is a larger change than I am comfortable with at the moment. > > On the other hand, llc, clang, and (according to Aaron) llvm-gcc all work with my COFF backend, so I will continue to work on it using one of those to test it. Ok, sounds reasonable. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100505/1febb6dc/attachment.html From anton at korobeynikov.info Thu May 6 01:46:31 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 6 May 2010 10:46:31 +0400 Subject: [LLVMdev] Failure to compile llvm-gcc-4.2-2.7 on FreeBSD on sparc machine In-Reply-To: <4BE25B61.8000905@tsoft.com> References: <4BE25B61.8000905@tsoft.com> Message-ID: Hello > I applied the attached patch, since the name of architecture on FreeBSD is > sparc64, not sparc. There is also one more replacement sparc -> spaarc64 was > made in gcc/Makefile in llvm-gcc. The patch is incorrect and the problems you're seeing are caused by your patch, since sparc != sparc64. In LLVM sense "sparc" means "sparc with ILP32 architecture model", llvm does not support anything 64 bit in sparc world. > ? size > constant invariant 64> > ? unit size unsigned int> constant invariant 8> > ? align 64 symtab 0 alias set -1 > ? pointer_to_this > > LLVM: i8* (32 bits) > LLVM type size doesn't match GCC type Indeed, LLVM assumes that pointer size is 32 bits (since it's 32 bit sparc), but gcc - definitely not. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From nicholas at mxc.ca Thu May 6 01:38:21 2010 From: nicholas at mxc.ca (Nick Lewycky) Date: Wed, 05 May 2010 23:38:21 -0700 Subject: [LLVMdev] Unreachable code executed crash In-Reply-To: References: Message-ID: <4BE263DD.1030907@mxc.ca> Adarsh Yoga wrote: > Yes. Intially the pass was crashing when the module when the module > verifier was running. I was able to solve that and now it is crashing > when the bit writer pass is running. The output is wrong in @thread_pool_init: :44:27: error: '%4' defined with type 'i1' %5 = getelementptr i32* %4, i64 %indvar ; [#uses=1] ^ where %4 = icmp slt i32 %threadnumber, 1 ; [#uses=2] meaning that %4 is an i1 not an i32*. I'm not sure how you managed to do this, and how the verifier didn't catch it. Maybe the %4 operand is actually an instruction in another function? I'll try to reproduce this and fix the verifier to catch it. Nick > On Wed, May 5, 2010 at 8:39 PM, Nick Lewycky > wrote: > > On 5 May 2010 17:12, Adarsh Yoga > wrote: > > Hi, > > I've written a pass that basically does some code > transformations to enable parallel execution of loops. After the > transformation llvm runs BitCode Writer pass , which is aborting > with Unreachable Executed error. > I have attached the input llvm code and the output llvm code for > reference. I am stuck at this problem for a few days now. Please > let me know if you are able to find anything unusual. > > > Have you tried running the module verifier after your transform, > before writing out to bitcode? > > Nick > > Regards, > Adarsh > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington > > > > _______________________________________________ > 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 Thu May 6 02:19:30 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 6 May 2010 11:19:30 +0400 Subject: [LLVMdev] Failure to compile llvm-gcc-4.2-2.7 on FreeBSD on sparc machine In-Reply-To: <4BE266D9.6000606@tsoft.com> References: <4BE25B61.8000905@tsoft.com> <4BE266D9.6000606@tsoft.com> Message-ID: > So LLVM support for sparc64 has to be implemented I guess. Yes. > Is this work started? I am not aware about any significant sparc-related works during past few years. So, the answer is most probably "no". -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From yuri at tsoft.com Thu May 6 02:20:17 2010 From: yuri at tsoft.com (Yuri) Date: Thu, 06 May 2010 00:20:17 -0700 Subject: [LLVMdev] Failure to compile llvm-gcc-4.2-2.7 on FreeBSD on sparc machine In-Reply-To: References: <4BE25B61.8000905@tsoft.com> Message-ID: <4BE26DB1.1040101@tsoft.com> Anton Korobeynikov wrote: > The patch is incorrect and the problems you're seeing are caused by > your patch, since sparc != sparc64. > In LLVM sense "sparc" means "sparc with ILP32 architecture model", > llvm does not support anything 64 bit in sparc world SparcTargetMachine.h file lists SparcV9TargetMachine as 64-bit machine and SparcV8TargetMachine as 32-bit machine. And SparcInstrInfo.td seems to contain some of the V9-only instructions. Are you sure 64-bit sparc isn't supported at all? Yuri From anton at korobeynikov.info Thu May 6 02:29:00 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 6 May 2010 11:29:00 +0400 Subject: [LLVMdev] Failure to compile llvm-gcc-4.2-2.7 on FreeBSD on sparc machine In-Reply-To: <4BE26DB1.1040101@tsoft.com> References: <4BE25B61.8000905@tsoft.com> <4BE26DB1.1040101@tsoft.com> Message-ID: > SparcTargetMachine.h file lists SparcV9TargetMachine as 64-bit machine and > SparcV8TargetMachine as 32-bit machine. > And SparcInstrInfo.td seems to contain some of the V9-only instructions. > > Are you sure 64-bit sparc isn't supported at all? Ah, sorry, I was looking into wrong sources - too much different LLVM trees around :) It seems that someone already provided 64 bit target data. In this case you probably need to add proper "sparc64" target triple recognition code, then make sure that 64 bit subtarget is selected and fix all the sparc codegen bugs you'll see on the way (I'd expect plenty of them since sparc backend is unmaintained). -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From rengolin at systemcall.org Thu May 6 03:32:57 2010 From: rengolin at systemcall.org (Renato Golin) Date: Thu, 6 May 2010 09:32:57 +0100 Subject: [LLVMdev] How to cast an integer array to an integer pointer? (user question) In-Reply-To: <4BE1F9B9.3070100@tsoft.com> References: <4BE1F9B9.3070100@tsoft.com> Message-ID: On 6 May 2010 00:05, Yuri wrote: > ?GetElementPtrInst *gepi = GetElementPtrInst::CreateInBounds( > ? ?GGV, > ? ?ConstantInt::get(Type::getInt32Ty(Context), 0), > ? ?"zzz", > ? ?BB > ? ?); Try using the IRBuilder: IRBuilder<> irb(BB); Value* gepi = irb.CreateInBoundsGEP(GGV, ConstantInt::get(Type::getInt32Ty(Context), 0), "zzz"); Keeping your pointers as Value* makes it easier to deal with using (or returning) them later. > ?// func call > ?CallInst::Create(PutsF, (Value* const*)&gepi, (Value* > const*)(&gepi)+1, "", BB); Since the return type is void, you can't use Twine, since you only have one argument, IRBuilder makes it easier for you just to call: irb.CreateCall(PutsF, gepi); You can still pass args via pointer/offset, vector or use the helpers CreateCall[2-4](). See include/llvm/Support/IRBuilder.h for more info. cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From rengolin at systemcall.org Thu May 6 03:40:46 2010 From: rengolin at systemcall.org (Renato Golin) Date: Thu, 6 May 2010 09:40:46 +0100 Subject: [LLVMdev] Auto-Vectorization in LLVM In-Reply-To: <1759D124-633F-454C-9562-813001C2CEAE@apple.com> References: <75698E3D-ED28-434A-94B5-ED99481C4D06@rice.edu> <1759D124-633F-454C-9562-813001C2CEAE@apple.com> Message-ID: On 6 May 2010 05:34, Chris Lattner wrote: > On May 5, 2010, at 1:01 PM, Rajkishore Barik wrote: >> I would also like to know if there is any progress/future plans to >> include this >> in the main trunk? > > Unfortunately, nothing came of this project AFAIK, maybe Devang knows more. I looked for it and couldn't find any, too. I found some alias/dependency analysis inside loops, but nothing actively trying to merge instructions. WRT progress/plans, there is the Poly project (http://wiki.llvm.org/Polyhedral_optimization_framework) that is an external representation to LLVM and could make much easier to map dependencies and leave the road open for auto-vec, but again, nothing on that direction has been done, too. Tobias and Ether should know more on that. cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From baldrick at free.fr Thu May 6 04:05:25 2010 From: baldrick at free.fr (Duncan Sands) Date: Thu, 06 May 2010 11:05:25 +0200 Subject: [LLVMdev] Another bad binutils? In-Reply-To: <147506.66777.qm@web62005.mail.re1.yahoo.com> References: <147506.66777.qm@web62005.mail.re1.yahoo.com> Message-ID: <4BE28655.5010605@free.fr> Hi Samuel, > After waiting through about 2 hours of hard drive spinning for Clang to link under my Xubuntu Lucid Lynx Linux setup on VirtualBox, ld finally just gave up trying to link it. I was using CMake's build scripts on version 2.7 release of LLVM and Clang. The version of ld is (GNU Binutils for Ubuntu) 2.20.1-system.20100303. Can anyone confirm this problem? If needed I'll cross-post this to the Ubuntu forums. Thanks for your time. if you build without optimization then clang is huge and takes forever to link. Try building with optimization. Ciao, Duncan. From baldrick at free.fr Thu May 6 04:03:06 2010 From: baldrick at free.fr (Duncan Sands) Date: Thu, 06 May 2010 11:03:06 +0200 Subject: [LLVMdev] emit after gvn pass? In-Reply-To: <201005051436.42321.dag@cray.com> References: <28462901.post@talk.nabble.com> <201005051436.42321.dag@cray.com> Message-ID: <4BE285CA.9040505@free.fr> > I don't know if the options are linked into llvm-gcc but with opt > you can do "-debug -print-after=gvn." You'll get a lot more output > than just the IR but it will be there. With llvm-gcc you can pass -mllvm -print-after=gvn on the command line. Ciao, Duncan. From xuzhongxing at gmail.com Thu May 6 04:33:27 2010 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Thu, 6 May 2010 17:33:27 +0800 Subject: [LLVMdev] Another bad binutils? In-Reply-To: <147506.66777.qm@web62005.mail.re1.yahoo.com> References: <147506.66777.qm@web62005.mail.re1.yahoo.com> Message-ID: I build llvm+clang almost every day with Ubuntu 10.04. Everything goes fine. I guess it's your VirtualBox has too little memory. On Thu, May 6, 2010 at 4:12 AM, Samuel Crow wrote: > After waiting through about 2 hours of hard drive spinning for Clang to > link under my Xubuntu Lucid Lynx Linux setup on VirtualBox, ld finally just > gave up trying to link it. I was using CMake's build scripts on version 2.7 > release of LLVM and Clang. The version of ld is (GNU Binutils for Ubuntu) > 2.20.1-system.20100303. Can anyone confirm this problem? If needed I'll > cross-post this to the Ubuntu forums. Thanks for your time. > > > > > _______________________________________________ > 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/20100506/caab191b/attachment.html From proljc at gmail.com Thu May 6 04:41:05 2010 From: proljc at gmail.com (Liu) Date: Thu, 6 May 2010 17:41:05 +0800 Subject: [LLVMdev] Another bad binutils? In-Reply-To: <147506.66777.qm@web62005.mail.re1.yahoo.com> References: <147506.66777.qm@web62005.mail.re1.yahoo.com> Message-ID: I've tried lots of times. Ubuntu 10.04 on both x86 and x64, nothing wrong. 2010/5/6 Samuel Crow > After waiting through about 2 hours of hard drive spinning for Clang to > link under my Xubuntu Lucid Lynx Linux setup on VirtualBox, ld finally just > gave up trying to link it. I was using CMake's build scripts on version 2.7 > release of LLVM and Clang. The version of ld is (GNU Binutils for Ubuntu) > 2.20.1-system.20100303. Can anyone confirm this problem? If needed I'll > cross-post this to the Ubuntu forums. Thanks for your time. > > > > > _______________________________________________ > 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/20100506/8f7b9fdf/attachment.html From etherzhhb at gmail.com Thu May 6 04:50:44 2010 From: etherzhhb at gmail.com (ether zhhb) Date: Thu, 6 May 2010 17:50:44 +0800 Subject: [LLVMdev] Back-edge taken count of loops Message-ID: hi all, i am have a project need to compute the back-edge taken count of a loop, and the "getBackedgeTakenCount" function of ScalarEvolution could do this for me. but later i found that ScalarEvolution could not compute loops with test expression containing a "=", such as: void scop_func(long A[], long n) { long i; for (i = 1; i<= n; i++) A[i] = 1; } after have a look at the code that computing the back-edge taken count, i found that ScalarEvolution could only compute back-edge taken count if the exit condition is ICMP_NE/ICMP_EQ/ICMP_SLT/ICMP_SGT/ICMP_ULT/ICMP_UGT (ignoring "ComputeBackedgeTakenCountExhaustively"), and the function "SimplifyICmpOperands" will try to convert other conditions to the conditions listed above, by doing something like "i <= n" to "i < n+1", but it refuse to do that unless it could prove "n + 1" will not cause a overflow. So, could us just set "n + 1" to the Exact field of BackedgeTakenInfo, and set something like SCEVInfinite to the Max field of BackedgeTakenInfo? thanks ether -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100506/af11583b/attachment.html From andreas.bolka at gmx.net Thu May 6 10:26:17 2010 From: andreas.bolka at gmx.net (Andreas Bolka) Date: Thu, 06 May 2010 17:26:17 +0200 Subject: [LLVMdev] Auto-Vectorization in LLVM In-Reply-To: <75698E3D-ED28-434A-94B5-ED99481C4D06@rice.edu> References: <75698E3D-ED28-434A-94B5-ED99481C4D06@rice.edu> Message-ID: <1273159151-sup-3079@strider> On Wed May 05 22:01:38 +0200 2010, Rajkishore Barik wrote: > I found out that Auto-Vectorization was implemented as a part of GSoC > 2009. Can someone point me to the code repository including any > documentation available? I would also like to know if there is any > progress/future plans to include this in the main trunk? Unfortunately I did not get around to do actual auto-vectorisation in my 2009 GSoC project. I've since continued to work on autovectorisation but switched to an unrolling-based approach instead of the dependence-based approach planned for the GSoC 2009 project. I have a basic unrolling-based autovectoriser working, and plan to start getting this work merged into mainline LLVM somewhen in mid July. As the vectorisation pass is pretty stand-alone and only needs a few minor changes to the loop unroller, I expect merging to be pretty straightforward. -- Regards, Andreas From samuraileumas at yahoo.com Thu May 6 10:59:04 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Thu, 6 May 2010 08:59:04 -0700 (PDT) Subject: [LLVMdev] Another bad binutils? In-Reply-To: References: <147506.66777.qm@web62005.mail.re1.yahoo.com> Message-ID: <631860.97914.qm@web62001.mail.re1.yahoo.com> You're right, it was a memory issue. Today I'll start cleaning out my native toolchains so that I can build natively on my Mac without the virtual machine getting in the way. > >From: Zhongxing Xu >To: Samuel Crow >Cc: LLVM Developers Mailing List >Sent: Thu, May 6, 2010 4:33:27 AM >Subject: Re: [LLVMdev] Another bad binutils? > >I build llvm+clang almost every day with Ubuntu 10.04. Everything goes fine. I guess it's your VirtualBox has too little memory. > > >On Thu, May 6, 2010 at 4:12 AM, Samuel Crow wrote: > >After waiting through about 2 hours of hard drive spinning for Clang to link under my Xubuntu Lucid Lynx Linux setup on VirtualBox, ld finally just gave up trying to link it. I was using CMake's build scripts on version 2.7 release of LLVM and Clang. The version of ld is (GNU Binutils for Ubuntu) 2.20.1-system.20100303. Can anyone confirm this problem? If needed I'll cross-post this to the Ubuntu forums. Thanks for your time. >> >> >> >> >>_______________________________________________ >>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/20100506/0a03a061/attachment.html From gohman at apple.com Thu May 6 11:23:22 2010 From: gohman at apple.com (Dan Gohman) Date: Thu, 6 May 2010 09:23:22 -0700 Subject: [LLVMdev] Back-edge taken count of loops In-Reply-To: References: Message-ID: <27DA4450-2D85-45D2-BAE8-9AB59B64E9CC@apple.com> I recently added support for <= loops on trunk. ScalarEvolution now uses the nsw flag to prove that it doesn't need to consider the infinite-loop case. Dan On May 6, 2010, at 2:50 AM, ether zhhb wrote: > hi all, > > i am have a project need to compute the back-edge taken count of a loop, and the "getBackedgeTakenCount" function of ScalarEvolution could do this for me. > > but later i found that ScalarEvolution could not compute loops with test expression containing a "=", such as: > > void scop_func(long A[], long n) { > long i; > > for (i = 1; i<= n; i++) > A[i] = 1; > } > > after have a look at the code that computing the back-edge taken count, i found that ScalarEvolution could only compute back-edge taken count if the exit condition is ICMP_NE/ICMP_EQ/ICMP_SLT/ICMP_SGT/ICMP_ULT/ICMP_UGT (ignoring "ComputeBackedgeTakenCountExhaustively"), and the function "SimplifyICmpOperands" will try to convert other conditions to the conditions listed above, by doing something like "i <= n" to "i < n+1", but it refuse to do that unless it could prove "n + 1" will not cause a overflow. > > So, could us just set "n + 1" to the Exact field of BackedgeTakenInfo, and set something like SCEVInfinite to the Max field of BackedgeTakenInfo? > > thanks > ether > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From devang.patel at gmail.com Thu May 6 11:45:42 2010 From: devang.patel at gmail.com (Devang Patel) Date: Thu, 6 May 2010 09:45:42 -0700 Subject: [LLVMdev] Auto-Vectorization in LLVM In-Reply-To: <1759D124-633F-454C-9562-813001C2CEAE@apple.com> References: <75698E3D-ED28-434A-94B5-ED99481C4D06@rice.edu> <1759D124-633F-454C-9562-813001C2CEAE@apple.com> Message-ID: On Wed, May 5, 2010 at 9:34 PM, Chris Lattner wrote: > > On May 5, 2010, at 1:01 PM, Rajkishore Barik wrote: > >> Hi, >> >> I found out that Auto-Vectorization was implemented as a part of GSoC >> 2009. >> Can someone point me to the code repository including any >> documentation available? >> I would also like to know if there is any progress/future plans to >> include this >> in the main trunk? > > Unfortunately, nothing came of this project AFAIK, maybe Devang knows more. Pretty much. Andreas did contribute initial basic code for loop dependence analysis and has promised to merge more improvements to this area. - Devang From ojomojo at gmail.com Thu May 6 11:51:51 2010 From: ojomojo at gmail.com (John Mosby) Date: Thu, 6 May 2010 10:51:51 -0600 Subject: [LLVMdev] doxygen redux In-Reply-To: <0245A926-D3C7-4363-BA1A-4BF42BE89E1B@gmail.com> References: <0245A926-D3C7-4363-BA1A-4BF42BE89E1B@gmail.com> Message-ID: Excellent work, this greatly improves the clarity of the generated docs. I would love it if the inheritance diagrams were kept as they are and the collaboration diagrams were hidden under a knob. Thanks, John On Fri, Apr 30, 2010 at 8:54 AM, mike-m wrote: > Hi, I'm working on a patch to overhaul docs+doxygen builds for both llvm > and clang source trees. > > Here's a sample of what it looks like for class clang::driver::Action > (sorry, llvm API docs are a bigger set so only clang has been posted at this > free webhost). Basically the output is a bump to latest doxygen plus custom > css; the wins (IMHO) are the new style doesn't waste so much vertical page > space, and uses slightly smaller fonts for both diagrams and html. > > NEW: http://kona.zzl.org/clang/api/classclang_1_1driver_1_1Action.html > OLD: http://clang.llvm.org/doxygen/classclang_1_1driver_1_1Action.html > > class with more inheritance: > http://kona.zzl.org/clang/api/classclang_1_1Decl.html > class with a rather large collaboration diagram: > http://kona.zzl.org/clang/api/classclang_1_1ASTContext.html > > I'm not sure how the project/community feels about collab-diagrams. I find > them exceedingly large and rarely useful. There are a couple of options if > changes in that area are desired: (1) disable collab-diagrams. (2) make both > class-inheritance and collab-diagrams hidden under a javascript-knob which > users can click to expand each diagram. > > Comments and suggestions are solicited! > > (patches for this are being tracked with pr6613). > > --mike-m > > > _______________________________________________ > 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/20100506/9cb80190/attachment.html From mikem.llvm at gmail.com Thu May 6 11:59:22 2010 From: mikem.llvm at gmail.com (mike-m) Date: Thu, 6 May 2010 12:59:22 -0400 Subject: [LLVMdev] doxygen redux In-Reply-To: References: <0245A926-D3C7-4363-BA1A-4BF42BE89E1B@gmail.com> Message-ID: Unfortunately Doxygen (latest vers) doesn't have per-diagram javascript-knob options. --mike-m On 2010-05-06, at 12:51 PM, John Mosby wrote: > Excellent work, this greatly improves the clarity of the generated docs. > > I would love it if the inheritance diagrams were kept as they are and > the collaboration diagrams were hidden under a knob. > > Thanks, > John From diegoiast at gmail.com Thu May 6 16:19:19 2010 From: diegoiast at gmail.com (Diego Iastrubni) Date: Fri, 7 May 2010 00:19:19 +0300 Subject: [LLVMdev] [cfe-dev] Living on Clang In-Reply-To: <87zl0z5z3h.fsf@telefonica.net> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> <87zl0z5z3h.fsf@telefonica.net> Message-ID: On Mon, Apr 19, 2010 at 4:52 PM, ?scar Fuentes wrote: > The third stage is for comparing the output of clang (as compiled by > gcc) against clang (as compiled by clang). The whole process is: > > Stage 1: build clang with gcc > > Stage 2: build clang with the clang created by gcc > > Stage 3: build clang with the clang created by clang. > > Final test: compare the object files geneated on Stage 2 with the object > files generated on Stage 3. > This is the first time stage3 has been built, I am happy (up until now, stage3 was failing at the first compilation): [elcuco at pinky ~/src/llvm] ls -l bootstrap-stage-*/bin/clang -rwxrwxr-x. 1 elcuco elcuco 23594232 2010-05-06 22:56 bootstrap-stage-1/bin/clang -rwxrwxr-x. 1 elcuco elcuco 24391566 2010-05-06 23:10 bootstrap-stage-2/bin/clang -rwxrwxr-x. 1 elcuco elcuco 24395343 2010-05-06 23:32 bootstrap-stage-3/bin/clang I already know that stage2 and stage3 are different, which means something is not really working. Does anyone have a clue about this? Is this a known issue, or should I report this? Now lets test if bash compiles. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/73a33693/attachment.html From dgregor at apple.com Thu May 6 16:34:08 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 6 May 2010 14:34:08 -0700 Subject: [LLVMdev] [cfe-dev] Living on Clang In-Reply-To: References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> <87zl0z5z3h.fsf@telefonica.net> Message-ID: On May 6, 2010, at 2:19 PM, Diego Iastrubni wrote: > On Mon, Apr 19, 2010 at 4:52 PM, ?scar Fuentes wrote: > The third stage is for comparing the output of clang (as compiled by > gcc) against clang (as compiled by clang). The whole process is: > > Stage 1: build clang with gcc > > Stage 2: build clang with the clang created by gcc > > Stage 3: build clang with the clang created by clang. > > Final test: compare the object files geneated on Stage 2 with the object > files generated on Stage 3. > > This is the first time stage3 has been built, I am happy (up until now, stage3 was failing at the first compilation): > > [elcuco at pinky ~/src/llvm] ls -l bootstrap-stage-*/bin/clang > -rwxrwxr-x. 1 elcuco elcuco 23594232 2010-05-06 22:56 bootstrap-stage-1/bin/clang > -rwxrwxr-x. 1 elcuco elcuco 24391566 2010-05-06 23:10 bootstrap-stage-2/bin/clang > -rwxrwxr-x. 1 elcuco elcuco 24395343 2010-05-06 23:32 bootstrap-stage-3/bin/clang > > > I already know that stage2 and stage3 are different, which means something is not really working. Does anyone have a clue about this? Is this a known issue, or should I report this? It's known that we differ, but nobody has investigated why. Please go ahead and file a Bugzilla. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100506/ff0eb3f0/attachment.html From ayoga at umail.iu.edu Thu May 6 18:06:52 2010 From: ayoga at umail.iu.edu (Adarsh Yoga) Date: Thu, 6 May 2010 19:06:52 -0400 Subject: [LLVMdev] Unreachable code executed crash In-Reply-To: <4BE263DD.1030907@mxc.ca> References: <4BE263DD.1030907@mxc.ca> Message-ID: I was able to solve that but still crashing with the same error saying "Unreachable executed". I have attached the output with this mail. Thanks in advance. On Thu, May 6, 2010 at 2:38 AM, Nick Lewycky wrote: > Adarsh Yoga wrote: > >> Yes. Intially the pass was crashing when the module when the module >> verifier was running. I was able to solve that and now it is crashing >> when the bit writer pass is running. >> > > The output is wrong in @thread_pool_init: > > :44:27: error: '%4' defined with type 'i1' > %5 = getelementptr i32* %4, i64 %indvar ; [#uses=1] > ^ > where > > %4 = icmp slt i32 %threadnumber, 1 ; [#uses=2] > > meaning that %4 is an i1 not an i32*. I'm not sure how you managed to do > this, and how the verifier didn't catch it. Maybe the %4 operand is actually > an instruction in another function? > > I'll try to reproduce this and fix the verifier to catch it. > > Nick > > On Wed, May 5, 2010 at 8:39 PM, Nick Lewycky > > wrote: >> >> On 5 May 2010 17:12, Adarsh Yoga > > wrote: >> >> Hi, >> >> I've written a pass that basically does some code >> transformations to enable parallel execution of loops. After the >> transformation llvm runs BitCode Writer pass , which is aborting >> with Unreachable Executed error. >> I have attached the input llvm code and the output llvm code for >> reference. I am stuck at this problem for a few days now. Please >> let me know if you are able to find anything unusual. >> >> >> Have you tried running the module verifier after your transform, >> before writing out to bitcode? >> >> Nick >> >> Regards, >> Adarsh >> >> -- >> Adarsh Yoga >> Graduate Student, Computer Science >> Indiana University, Bloomington >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu >> >> http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> >> >> -- >> Adarsh Yoga >> Graduate Student, Computer Science >> Indiana University, Bloomington >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -- Adarsh Yoga Graduate Student, Computer Science Indiana University, Bloomington -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100506/dcfbb94d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: new-output Type: application/octet-stream Size: 4836 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100506/dcfbb94d/attachment.obj From yuri at tsoft.com Thu May 6 19:21:32 2010 From: yuri at tsoft.com (Yuri) Date: Thu, 06 May 2010 17:21:32 -0700 Subject: [LLVMdev] Failure building 2.7 with debug info and expensive checks Message-ID: <4BE35D0C.40509@tsoft.com> I am trying to build 2.7 on FreeBSD with all debugging options "on": CXX=/usr/local/gcc/4.5.0/bin/g++ CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ../llvm/configure --prefix=/usr/local/llvm/2.7 --enable-assertions --enable-shared --enable-libffi --enable-debug-runtime --enable-expensive-checks --enable-debug-symbols Here is the error message I got from the build: <...skipped...> gmake[1]: Entering directory `/tmp/llvm-build/2.7/llvm-objects/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td Stack dump: 0. Program arguments: /tmp/llvm-build/2.7/llvm-objects/Release+Debug+Checks/bin/tblgen -I /tmp/llvm-build/2.7/llvm/lib/VMCore -I /tmp/llvm-build/2.7/llvm/include -I /tmp/llvm-build/2.7/llvm/include -I /tmp/llvm-build/2.7/llvm/lib/Target /tmp/llvm-build/2.7/llvm/include/llvm/Intrinsics.td -o /tmp/llvm-build/2.7/llvm-objects/lib/VMCore/Release+Debug+Checks/Intrinsics.gen.tmp -gen-intrinsic gmake[1]: *** [/tmp/llvm-build/2.7/llvm-objects/lib/VMCore/Release+Debug+Checks/Intrinsics.gen.tmp] Segmentation fault: 11 gmake[1]: Leaving directory `/tmp/llvm-build/2.7/llvm-objects/lib/VMCore' gmake: *** [all] Error 1 Yuri From Trevor.W.Harmon at nasa.gov Thu May 6 19:59:17 2010 From: Trevor.W.Harmon at nasa.gov (Trevor Harmon) Date: Thu, 6 May 2010 17:59:17 -0700 Subject: [LLVMdev] getTripCount requires which optimization passes? Message-ID: <0D1A6E16-0987-489A-8E34-A5A2F62CEDC5@nasa.gov> Hi, For me, getTripCount always returns null, even for trivial loops such as: void simple(int j) { for (int i = 0; i < 10; i++) { j++; } } Looking through the mailing list archive, it appears that getTripCount requires certain optimization passes to run first, but it's not clear which ones. There doesn't seem to be any documentation on this. Does anybody know exactly which passes must run in order for getTripCount to work? Thanks, Trevor From etherzhhb at gmail.com Thu May 6 20:26:08 2010 From: etherzhhb at gmail.com (ether zhhb) Date: Fri, 7 May 2010 09:26:08 +0800 Subject: [LLVMdev] Back-edge taken count of loops In-Reply-To: <27DA4450-2D85-45D2-BAE8-9AB59B64E9CC@apple.com> References: <27DA4450-2D85-45D2-BAE8-9AB59B64E9CC@apple.com> Message-ID: hi Dan, On Fri, May 7, 2010 at 12:23 AM, Dan Gohman wrote: > I recently added support for <= loops on trunk. thanks very much, that will help us a lot :) > ScalarEvolution now > uses the nsw flag to prove that it doesn't need to consider the > infinite-loop case. > > Dan > > best regards --ether -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/f20a1c0d/attachment.html From etherzhhb at gmail.com Thu May 6 20:32:41 2010 From: etherzhhb at gmail.com (ether zhhb) Date: Fri, 7 May 2010 09:32:41 +0800 Subject: [LLVMdev] getTripCount requires which optimization passes? In-Reply-To: <0D1A6E16-0987-489A-8E34-A5A2F62CEDC5@nasa.gov> References: <0D1A6E16-0987-489A-8E34-A5A2F62CEDC5@nasa.gov> Message-ID: hi, On Fri, May 7, 2010 at 8:59 AM, Trevor Harmon wrote: > Hi, > > For me, getTripCount always returns null, even for trivial loops such > as: > > void simple(int j) { > for (int i = 0; i < 10; i++) { > j++; > } > } > > Looking through the mailing list archive, it appears that getTripCount > requires certain optimization passes to run first, but it's not clear > which ones. There doesn't seem to be any documentation on this. Does > anybody know exactly which passes must run in order for getTripCount > to work? > As the comment said: /// The IndVarSimplify pass transforms loops to have a form that this /// function easily understands. you could try -indvars. > > Thanks, > > Trevor > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > best regards ether -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/1b26a0b9/attachment.html From nicholas at mxc.ca Thu May 6 23:02:55 2010 From: nicholas at mxc.ca (Nick Lewycky) Date: Thu, 06 May 2010 21:02:55 -0700 Subject: [LLVMdev] Unreachable code executed crash In-Reply-To: References: <4BE263DD.1030907@mxc.ca> Message-ID: <4BE390EF.9090503@mxc.ca> Adarsh Yoga wrote: > I was able to solve that What was wrong? I wasn't able to reproduce it and would still like to teach the verifier whatever it missed. but still crashing with the same error saying > "Unreachable executed". I have attached the output with this mail. This time you've got: %1 = load i32** getelementptr inbounds ({ i32* }* @structobj, i64 0, i32 0) in @temp0 but @structobj is nowhere in the file, which implies that you created the GlobalValue but never inserted it. You can figure this out for yourself by taking the module dump (be sure to remove "The Module: " from the beginning) and running llvm-as on it. It finds these errors. Nick > > Thanks in advance. > > On Thu, May 6, 2010 at 2:38 AM, Nick Lewycky > wrote: > > Adarsh Yoga wrote: > > Yes. Intially the pass was crashing when the module when the module > verifier was running. I was able to solve that and now it is > crashing > when the bit writer pass is running. > > > The output is wrong in @thread_pool_init: > > :44:27: error: '%4' defined with type 'i1' > %5 = getelementptr i32* %4, i64 %indvar ; [#uses=1] > ^ > where > > %4 = icmp slt i32 %threadnumber, 1 ; [#uses=2] > > meaning that %4 is an i1 not an i32*. I'm not sure how you managed > to do this, and how the verifier didn't catch it. Maybe the %4 > operand is actually an instruction in another function? > > I'll try to reproduce this and fix the verifier to catch it. > > Nick > > On Wed, May 5, 2010 at 8:39 PM, Nick Lewycky > > >> wrote: > > On 5 May 2010 17:12, Adarsh Yoga > >> wrote: > > Hi, > > I've written a pass that basically does some code > transformations to enable parallel execution of loops. > After the > transformation llvm runs BitCode Writer pass , which is > aborting > with Unreachable Executed error. > I have attached the input llvm code and the output llvm > code for > reference. I am stuck at this problem for a few days > now. Please > let me know if you are able to find anything unusual. > > > Have you tried running the module verifier after your transform, > before writing out to bitcode? > > Nick > > Regards, > Adarsh > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu > > > > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington From blunted2night at gmail.com Fri May 7 00:01:43 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Thu, 6 May 2010 22:01:43 -0700 Subject: [LLVMdev] AsmPrinter behavior Message-ID: I compile these two lines in llc @tst1 = internal global [4 x i8] zeroinitializer; @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; @tst1 is emited via MCStreamer::EmitCommonSymbol while the other is emited via MCStreamer::EmitLabel followed by MCStreamer::EmitBytes from what I can tell, only symbols with common linkage should me emitted by MCStreamer::EmitCommonSymbol, is this the expected behavior or should I fix it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100506/095f4cb0/attachment.html From housel at acm.org Fri May 7 01:12:13 2010 From: housel at acm.org (Peter S. Housel) Date: Thu, 06 May 2010 23:12:13 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> Message-ID: <1273212733.26912.5.camel@expression.housel.dyndns.org> On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > The important point here is that the COFF MCSection needs to > have the right level of semantic information. In fact, > MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > proven somewhat problematic, mostly due to my lack of understanding. > I guess MCSectionXXX was meant to provide communication between them. > Should the same be true of MCSymbol, and their data counterparts? I'm enclosing my patch for reforming MCSectionCOFF to match the implementation strategy of the other two MCSection classes. You may find it useful as a starting point. It seems to be complete and correct, and worked for what I tried with it, but I didn't find time to test it fully (e.g., by bootstrapping clang under Cygwin). Cheers, -Peter- -------------- next part -------------- A non-text attachment was scrubbed... Name: mcsectioncoff.diff Type: text/x-patch Size: 24420 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100506/9b09aebb/attachment.bin From blunted2night at gmail.com Fri May 7 01:22:15 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Thu, 6 May 2010 23:22:15 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: <1273212733.26912.5.camel@expression.housel.dyndns.org> References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <1273212733.26912.5.camel@expression.housel.dyndns.org> Message-ID: Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal with the PrintSwitchToSection function without needing the IsDirective flag. On Thu, May 6, 2010 at 11:12 PM, Peter S. Housel wrote: > On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > > > > The important point here is that the COFF MCSection needs to > > have the right level of semantic information. In fact, > > MCSection is the place that I'd start for COFF bringup. > > > > OK, I see that now. The current isolation > > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > > proven somewhat problematic, mostly due to my lack of understanding. > > I guess MCSectionXXX was meant to provide communication between them. > > Should the same be true of MCSymbol, and their data counterparts? > > I'm enclosing my patch for reforming MCSectionCOFF to match the > implementation strategy of the other two MCSection classes. You may find > it useful as a starting point. It seems to be complete and correct, and > worked for what I tried with it, but I didn't find time to test it fully > (e.g., by bootstrapping clang under Cygwin). > > Cheers, > -Peter- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100506/169d6339/attachment.html From clattner at apple.com Fri May 7 02:03:42 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 May 2010 00:03:42 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: Message-ID: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> On May 6, 2010, at 10:01 PM, Nathan Jeffords wrote: > I compile these two lines in llc > > @tst1 = internal global [4 x i8] zeroinitializer; > @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; > > @tst1 is emited via MCStreamer::EmitCommonSymbol > while the other is emited via MCStreamer::EmitLabel followed by MCStreamer::EmitBytes > > from what I can tell, only symbols with common linkage should me emitted by MCStreamer::EmitCommonSymbol, > > is this the expected behavior or should I fix it? This is expected behavior. tst1 should be emitted with something like: .local _tst1 .comm _tst1, ... based on the exact syntax of your target. If your target supports .lcomm, you can also enable that. -Chris From clattner at apple.com Fri May 7 02:05:03 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 May 2010 00:05:03 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <1273212733.26912.5.camel@expression.housel.dyndns.org> Message-ID: On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal with the PrintSwitchToSection function without needing the IsDirective flag. I prefer to merge in small independent patches as they are built. Please review Peter's patch (since you know COFF :). I'll take a look tomorrow and apply it if you think it is forward progress, and if there aren't other issues. Thanks! -Chris > > On Thu, May 6, 2010 at 11:12 PM, Peter S. Housel wrote: > On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > > > > The important point here is that the COFF MCSection needs to > > have the right level of semantic information. In fact, > > MCSection is the place that I'd start for COFF bringup. > > > > OK, I see that now. The current isolation > > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > > proven somewhat problematic, mostly due to my lack of understanding. > > I guess MCSectionXXX was meant to provide communication between them. > > Should the same be true of MCSymbol, and their data counterparts? > > I'm enclosing my patch for reforming MCSectionCOFF to match the > implementation strategy of the other two MCSection classes. You may find > it useful as a starting point. It seems to be complete and correct, and > worked for what I tried with it, but I didn't find time to test it fully > (e.g., by bootstrapping clang under Cygwin). > > Cheers, > -Peter- > > > _______________________________________________ > 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/20100507/b7c96a0f/attachment-0001.html From blunted2night at gmail.com Fri May 7 02:15:30 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Fri, 7 May 2010 00:15:30 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <1273212733.26912.5.camel@expression.housel.dyndns.org> Message-ID: On Fri, May 7, 2010 at 12:05 AM, Chris Lattner wrote: > > On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > > Thanks! Funny, I was just preparing a patch to submit for my changes to > MCSectionCOFF. My changes look to be fairly independent of yours, my change > was to deal with COMDAT's. I had dealt with the characteristics flags in the > object writer, but I like this. If you don't mind I would like to merge my > changes into this patch and submit it. I was just pondering how to deal with > the PrintSwitchToSection function without needing the IsDirective flag. > > > I prefer to merge in small independent patches as they are built. Please > review Peter's patch (since you know COFF :). I'll take a look tomorrow and > apply it if you think it is forward progress, and if there aren't other > issues. > > Thanks! > > -Chris > > > On Thu, May 6, 2010 at 11:12 PM, Peter S. Housel wrote: > >> On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: >> >> > >> > The important point here is that the COFF MCSection needs to >> > have the right level of semantic information. In fact, >> > MCSection is the place that I'd start for COFF bringup. >> > >> > OK, I see that now. The current isolation >> > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has >> > proven somewhat problematic, mostly due to my lack of understanding. >> > I guess MCSectionXXX was meant to provide communication between them. >> > Should the same be true of MCSymbol, and their data counterparts? >> >> I'm enclosing my patch for reforming MCSectionCOFF to match the >> implementation strategy of the other two MCSection classes. You may find >> it useful as a starting point. It seems to be complete and correct, and >> worked for what I tried with it, but I didn't find time to test it fully >> (e.g., by bootstrapping clang under Cygwin). >> >> Cheers, >> -Peter- >> >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > I have looked over this patch, and do think its forward progress. I was planning additional changes, but I can wait to submit them until this is committed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/0cdc4922/attachment.html From proljc at gmail.com Fri May 7 02:37:49 2010 From: proljc at gmail.com (Liu) Date: Fri, 7 May 2010 15:37:49 +0800 Subject: [LLVMdev] How to build a cross llvm-gcc compiler for Arm Cortex-A8 Message-ID: hi My host is Linux on x86, and I want llvm-gcc generate code for Arm Cortex-A8. I saw that in LLVM 2.7 Release Notes, but I can't find step to build it. Anyone tell me? llvm-gcc now has complete support for the ARM v7 NEON instruction set. This support differs slightly from the GCC implementation. Please see the ARM Advanced SIMD (NEON) Intrinsics and Types in LLVM Blog Post for helpful information if migrating code from GCC to LLVM-GCC Thank you all -Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/d4319f24/attachment.html From baldrick at free.fr Fri May 7 03:59:34 2010 From: baldrick at free.fr (Duncan Sands) Date: Fri, 07 May 2010 10:59:34 +0200 Subject: [LLVMdev] Failure building 2.7 with debug info and expensive checks In-Reply-To: <4BE35D0C.40509@tsoft.com> References: <4BE35D0C.40509@tsoft.com> Message-ID: <4BE3D676.9080908@free.fr> Hi Yuri, > I am trying to build 2.7 on FreeBSD with all debugging options "on": > CXX=/usr/local/gcc/4.5.0/bin/g++ CPPFLAGS=-I/usr/local/include > LDFLAGS=-L/usr/local/lib ../llvm/configure --prefix=/usr/local/llvm/2.7 > --enable-assertions --enable-shared --enable-libffi > --enable-debug-runtime --enable-expensive-checks --enable-debug-symbols I can't reproduce this on x86-64 linux with g++-4.5 and --disable-optimized --enable-assertions --enable-expensive-checks --disable-threads --enable-libffi Ciao, Duncan. From ayoga at umail.iu.edu Fri May 7 04:22:48 2010 From: ayoga at umail.iu.edu (Adarsh Yoga) Date: Fri, 7 May 2010 05:22:48 -0400 Subject: [LLVMdev] Unreachable code executed crash In-Reply-To: <4BE390EF.9090503@mxc.ca> References: <4BE263DD.1030907@mxc.ca> <4BE390EF.9090503@mxc.ca> Message-ID: Initially, tt was not a problem with the verifier, we were just inserting a wrong instruction in our pass. Also we were able to figure out the error you pointed out and our pass is running as intended!!! Thanks a lot. On Fri, May 7, 2010 at 12:02 AM, Nick Lewycky wrote: > Adarsh Yoga wrote: > >> I was able to solve that >> > > What was wrong? I wasn't able to reproduce it and would still like to teach > the verifier whatever it missed. > > > but still crashing with the same error saying > >> "Unreachable executed". I have attached the output with this mail. >> > > This time you've got: > > %1 = load i32** getelementptr inbounds ({ i32* }* @structobj, i64 0, i32 > 0) > > in @temp0 but @structobj is nowhere in the file, which implies that you > created the GlobalValue but never inserted it. > > You can figure this out for yourself by taking the module dump (be sure to > remove "The Module: " from the beginning) and running llvm-as on it. It > finds these errors. > > Nick > > >> Thanks in advance. >> >> On Thu, May 6, 2010 at 2:38 AM, Nick Lewycky > > wrote: >> >> Adarsh Yoga wrote: >> >> Yes. Intially the pass was crashing when the module when the module >> verifier was running. I was able to solve that and now it is >> crashing >> when the bit writer pass is running. >> >> >> The output is wrong in @thread_pool_init: >> >> :44:27: error: '%4' defined with type 'i1' >> %5 = getelementptr i32* %4, i64 %indvar ; [#uses=1] >> ^ >> where >> >> %4 = icmp slt i32 %threadnumber, 1 ; [#uses=2] >> >> meaning that %4 is an i1 not an i32*. I'm not sure how you managed >> to do this, and how the verifier didn't catch it. Maybe the %4 >> operand is actually an instruction in another function? >> >> I'll try to reproduce this and fix the verifier to catch it. >> >> Nick >> >> On Wed, May 5, 2010 at 8:39 PM, Nick Lewycky >> >> >> wrote: >> >> On 5 May 2010 17:12, Adarsh Yoga > >> >> wrote: >> >> Hi, >> >> I've written a pass that basically does some code >> transformations to enable parallel execution of loops. >> After the >> transformation llvm runs BitCode Writer pass , which is >> aborting >> with Unreachable Executed error. >> I have attached the input llvm code and the output llvm >> code for >> reference. I am stuck at this problem for a few days >> now. Please >> let me know if you are able to find anything unusual. >> >> >> Have you tried running the module verifier after your >> transform, >> before writing out to bitcode? >> >> Nick >> >> Regards, >> Adarsh >> >> -- >> Adarsh Yoga >> Graduate Student, Computer Science >> Indiana University, Bloomington >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu >> > >> >> >> http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> >> >> -- >> Adarsh Yoga >> Graduate Student, Computer Science >> Indiana University, Bloomington >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu >> http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> >> >> -- >> Adarsh Yoga >> Graduate Student, Computer Science >> Indiana University, Bloomington >> > > -- Adarsh Yoga Graduate Student, Computer Science Indiana University, Bloomington -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/3deb26cf/attachment.html From aaronngray.lists at googlemail.com Fri May 7 05:10:55 2010 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Fri, 7 May 2010 11:10:55 +0100 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <1273212733.26912.5.camel@expression.housel.dyndns.org> Message-ID: On 7 May 2010 08:15, Nathan Jeffords wrote: > > > On Fri, May 7, 2010 at 12:05 AM, Chris Lattner wrote: > >> >> On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: >> >> Thanks! Funny, I was just preparing a patch to submit for my changes to >> MCSectionCOFF. My changes look to be fairly independent of yours, my change >> was to deal with COMDAT's. I had dealt with the characteristics flags in the >> object writer, but I like this. If you don't mind I would like to merge my >> changes into this patch and submit it. I was just pondering how to deal with >> the PrintSwitchToSection function without needing the IsDirective flag. >> >> >> I prefer to merge in small independent patches as they are built. Please >> review Peter's patch (since you know COFF :). I'll take a look tomorrow and >> apply it if you think it is forward progress, and if there aren't other >> issues. >> >> Thanks! >> >> -Chris >> >> >> On Thu, May 6, 2010 at 11:12 PM, Peter S. Housel wrote: >> >>> On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: >>> >>> > >>> > The important point here is that the COFF MCSection needs to >>> > have the right level of semantic information. In fact, >>> > MCSection is the place that I'd start for COFF bringup. >>> > >>> > OK, I see that now. The current isolation >>> > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has >>> > proven somewhat problematic, mostly due to my lack of understanding. >>> > I guess MCSectionXXX was meant to provide communication between them. >>> > Should the same be true of MCSymbol, and their data counterparts? >>> >>> I'm enclosing my patch for reforming MCSectionCOFF to match the >>> implementation strategy of the other two MCSection classes. You may find >>> it useful as a starting point. It seems to be complete and correct, and >>> worked for what I tried with it, but I didn't find time to test it fully >>> (e.g., by bootstrapping clang under Cygwin). >>> >>> Cheers, >>> >> Looks fine except its 'Emit' not 'Omit'. Aaron > -Peter- >>> >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> > I have looked over this patch, and do think its forward progress. I was > planning additional changes, but I can wait to submit them until this is > committed. > > > _______________________________________________ > 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/20100507/f763d908/attachment.html From anton at korobeynikov.info Fri May 7 09:17:38 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Fri, 7 May 2010 18:17:38 +0400 Subject: [LLVMdev] How to build a cross llvm-gcc compiler for Arm Cortex-A8 In-Reply-To: References: Message-ID: Hello > My host is Linux on x86, and I want llvm-gcc generate code for Arm > Cortex-A8. > I saw that in LLVM 2.7 Release Notes, but I can't find step to build > it. Anyone tell me? Build llvm-gcc exactly the same way you're building the cross gcc for your target. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From housel at acm.org Fri May 7 09:24:01 2010 From: housel at acm.org (Peter S. Housel) Date: Fri, 07 May 2010 07:24:01 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <1273212733.26912.5.camel@expression.housel.dyndns.org> Message-ID: <1273242241.26912.10.camel@expression.housel.dyndns.org> On Fri, 2010-05-07 at 11:10 +0100, Aaron Gray wrote: > > > Looks fine except its 'Emit' not 'Omit'. 'Omit' is what is intended here; it refers to omitting the '.section' keyword when switching to '.text'/'.data'/'.bss'. Similar code appears in MCSectionELF.cpp. -Peter- From daniel at zuster.org Fri May 7 10:43:44 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Fri, 7 May 2010 08:43:44 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: <15F4FDD1-2764-433D-A7CA-70165A49B64D@apple.com> Message-ID: On Wed, May 5, 2010 at 11:19 PM, Nathan Jeffords wrote: > > > On Wed, May 5, 2010 at 9:38 PM, Chris Lattner wrote: >> >> On May 5, 2010, at 6:44 PM, Nathan Jeffords wrote: >>> >>> ... >>> Thanks, applied in r103150! ?llvm-mc -filetype=obj probably needs a >>> similar patch. >> >> cool!, I will make that change and submit it too. >> >> Thanks! > > After looking into this, I have found that AsmParser is hard coded to use > MachO sections which causes my code to segfault, reworking this code to use > TargetLoweringObjectFile or some?equivalent?is a larger change than I am > comfortable with at the moment. This is a bug. Feel free to file a PR for it, I will *try* to get to it, but it may take me a while (>1 month). - Daniel > On the other hand, llc, clang, and (according?to Aaron) llvm-gcc all work > with my COFF backend, so I will continue to work on it using one of those to > test it. > > - Nathan > _______________________________________________ > 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 May 7 10:52:28 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Fri, 7 May 2010 08:52:28 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <62912497-D064-41C0-8B79-783D2333981F@apple.com> Message-ID: On Wed, May 5, 2010 at 5:53 PM, Chris Lattner wrote: > > On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: >> >> The logic to handle this has to go somewhere, putting it in the MCStreamer >> *implementation* that needs it is the most logical place. ?We also aim to >> implement an assembler, it doesn't make sense to duplicate this logic in the >> compiler and the assembler parser. > > Assembly language has?often?been *the* intermediate form for between > compilers and object files/executables, but I don't think its the most > effective form. That said I have limited experience writing code > generators?so my opinions do not bear the wisdom of you and other developers > of this library on this topic. > > I completely agree, but it is a very important and effective form of > communication :) > One nice fallout of the MCStreamer design is that once the COFF writer is > available, we'll have a stand-alone coff assembler mostly "for free". ?In > fact, developing this as a coff assembler (which can be accessed with > 'llvm-mc foo.s -o foo.obj -filetype=obj') is easier in a lot of ways than > dealing with the compiler! >> >> Yes somewhat. ?Currently, the COFF implementation of the assembler backend >> should maintain a DenseMap from MCSymbol* to whatever data you need to >> associate with a symbol. ?This is equivalent to embedding per-symbol stuff >> in the MCSymbol itself. ?MCSection should be subclassed and you should put >> COFF specific stuff in MCSectionCOFF. > > I think this is an important detail I was missing. I can already see how > this will help with COMDAT sections. Is there any reason for the difference > between symbol and section in this respect? > > You'd have to ask Daniel about this. ?I don't recall if this is a short term > thing that he'd like to fix or if this is an important design decision. The reason for MCSectionCOFF etc., is that they are shared between the MC and CodeGen interfaces. They have semantics that apply to both .s files and object files, and even the frontend has some interest in them. OTOH, things like MCSymbolData, MCSectionData, are private to the assembler backend, and so only the assembler and object writer need to know about them (they are unused when writing to a .s file, for example). MCAssembler already maintains its own association of these data structures, and there are a few bits available for the object file backends inside MCSymbolData. I would be fine adding a few more for use by specific object writers, if it simplifies your implementation. I'm sorry I have had time to be very present on this thread, but please feel free to mail me / ping me if there is a something about the assembler backend you have questions on. I'm very excited to see COFF support coming up! - Daniel >> As others have pointed out, this is one of the many horrors of C :) > > Another reason why I am attempting to develop my own language. :) > p.s. I posted my coff backend patch to llvm-commit, but that apears to be > the wrong place, where should I have posted it? > > llvm-commits is a great place for it! > -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 Fri May 7 11:01:56 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 May 2010 09:01:56 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> Message-ID: On May 7, 2010, at 12:39 AM, Nathan Jeffords wrote: > On Fri, May 7, 2010 at 12:03 AM, Chris Lattner wrote: > > On May 6, 2010, at 10:01 PM, Nathan Jeffords wrote: > > > I compile these two lines in llc > > > > @tst1 = internal global [4 x i8] zeroinitializer; > > @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; > > > > @tst1 is emited via MCStreamer::EmitCommonSymbol > > while the other is emited via MCStreamer::EmitLabel followed by MCStreamer::EmitBytes > > > > from what I can tell, only symbols with common linkage should me emitted by MCStreamer::EmitCommonSymbol, > > > > is this the expected behavior or should I fix it? > > This is expected behavior. tst1 should be emitted with something like: > > .local _tst1 > .comm _tst1, ... > > based on the exact syntax of your target. If your target supports .lcomm, you can also enable that. > > -Chris > > This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage attribute to get that behavior. Nothing in the llvm language reference indicates the behavior of a global with the 'internal' linkage attribute should change based of the values used to initialize it. I don't follow. The object file format provides a means for efficiently zero filling a local symbol. The compiler is just using it. What is the problem you're trying to solve here? Since it is not exported out of the .o file (it is local) there whether it is "common" or not is undetectable, we just get a storage optimization. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/3c45b7db/attachment.html From blunted2night at gmail.com Fri May 7 11:51:55 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Fri, 7 May 2010 09:51:55 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> Message-ID: On Fri, May 7, 2010 at 9:01 AM, Chris Lattner wrote: > > On May 7, 2010, at 12:39 AM, Nathan Jeffords wrote: > > On Fri, May 7, 2010 at 12:03 AM, Chris Lattner wrote: > >> >> On May 6, 2010, at 10:01 PM, Nathan Jeffords wrote: >> >> > I compile these two lines in llc >> > >> > @tst1 = internal global [4 x i8] zeroinitializer; >> > @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; >> > >> > @tst1 is emited via MCStreamer::EmitCommonSymbol >> > while the other is emited via MCStreamer::EmitLabel followed by >> MCStreamer::EmitBytes >> > >> > from what I can tell, only symbols with common linkage should me emitted >> by MCStreamer::EmitCommonSymbol, >> > >> > is this the expected behavior or should I fix it? >> >> This is expected behavior. tst1 should be emitted with something like: >> >> .local _tst1 >> .comm _tst1, ... >> >> based on the exact syntax of your target. If your target supports .lcomm, >> you can also enable that. >> >> -Chris > > > This seems counter intuitive to me, I can understand that C assigned that > behavior somewhat arbitrarily to uninitialized global variables, but in LLVM > there is explicitly a common linkage attribute to get that behavior. Nothing > in the llvm language reference indicates the behavior of a global with the > 'internal' linkage attribute should change based of the values used to > initialize it. > > > I don't follow. The object file format provides a means for efficiently > zero filling a local symbol. The compiler is just using it. What is the > problem you're trying to solve here? Since it is not exported out of the .o > file (it is local) there whether it is "common" or not is undetectable, we > just get a storage optimization. > > I don't know, I see common and it makes me think that things are getting merged together, but as you say it is local so the fact that its also common becomes irrelevant. In MachO do you just put these into the .bss section? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/2f076dfa/attachment.html From clattner at apple.com Fri May 7 11:53:42 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 May 2010 09:53:42 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> Message-ID: <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage attribute to get that behavior. Nothing in the llvm language reference indicates the behavior of a global with the 'internal' linkage attribute should change based of the values used to initialize it. > > I don't follow. The object file format provides a means for efficiently zero filling a local symbol. The compiler is just using it. What is the problem you're trying to solve here? Since it is not exported out of the .o file (it is local) there whether it is "common" or not is undetectable, we just get a storage optimization. > > > I don't know, I see common and it makes me think that things are getting merged together, but as you say it is local so the fact that its also common becomes irrelevant. In MachO do you just put these into the .bss section? > Macho has a special zerofill directive (targeted at the BSS section) for this. You can see this by running your example like this: $ llc t.ll -o - -mtriple=i386-apple-darwin10 .section __TEXT,__text,regular,pure_instructions .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 .section __DATA,__data _tst2: ## @tst2 .ascii "\000\001\002\003" -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/9015a36a/attachment.html From aaronngray.lists at googlemail.com Fri May 7 12:02:39 2010 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Fri, 7 May 2010 18:02:39 +0100 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> Message-ID: On 7 May 2010 17:53, Chris Lattner wrote: > > On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: > > This seems counter intuitive to me, I can understand that C assigned that >> behavior somewhat arbitrarily to uninitialized global variables, but in LLVM >> there is explicitly a common linkage attribute to get that behavior. Nothing >> in the llvm language reference indicates the behavior of a global with the >> 'internal' linkage attribute should change based of the values used to >> initialize it. >> >> >> I don't follow. The object file format provides a means for efficiently >> zero filling a local symbol. The compiler is just using it. What is the >> problem you're trying to solve here? Since it is not exported out of the .o >> file (it is local) there whether it is "common" or not is undetectable, we >> just get a storage optimization. >> >> > I don't know, I see common and it makes me think that things are getting > merged together, but as you say it is local so the fact that its also common > becomes irrelevant. In MachO do you just put these into the .bss section? > > > Macho has a special zerofill directive (targeted at the BSS section) for > this. You can see this by running your example like this: > > $ llc t.ll -o - -mtriple=i386-apple-darwin10 > .section __TEXT,__text,regular,pure_instructions > .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 > .section __DATA,__data > _tst2: ## @tst2 > .ascii "\000\001\002\003" > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports in ' lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. We also need to sort out COFF TLOF, and get rid of the directive stuff. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/b624435f/attachment.html From clattner at apple.com Fri May 7 12:14:48 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 May 2010 10:14:48 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> Message-ID: On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > On 7 May 2010 17:53, Chris Lattner wrote: > > On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: > >>> This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage attribute to get that behavior. Nothing in the llvm language reference indicates the behavior of a global with the 'internal' linkage attribute should change based of the values used to initialize it. >> >> I don't follow. The object file format provides a means for efficiently zero filling a local symbol. The compiler is just using it. What is the problem you're trying to solve here? Since it is not exported out of the .o file (it is local) there whether it is "common" or not is undetectable, we just get a storage optimization. >> >> >> I don't know, I see common and it makes me think that things are getting merged together, but as you say it is local so the fact that its also common becomes irrelevant. In MachO do you just put these into the .bss section? >> > > Macho has a special zerofill directive (targeted at the BSS section) for this. You can see this by running your example like this: > > $ llc t.ll -o - -mtriple=i386-apple-darwin10 > .section __TEXT,__text,regular,pure_instructions > .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 > .section __DATA,__data > _tst2: ## @tst2 > .ascii "\000\001\002\003" > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports in 'lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. It looks to me that you should have an Emit method for the .scl, .def, .type, .endef directives. One callback each. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/55a24b87/attachment.html From blunted2night at gmail.com Fri May 7 12:19:06 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Fri, 7 May 2010 10:19:06 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <62912497-D064-41C0-8B79-783D2333981F@apple.com> Message-ID: > > > The reason for MCSectionCOFF etc., is that they are shared between the > MC and CodeGen interfaces. They have semantics that apply to both .s > files and object files, and even the frontend has some interest in > them. > > OTOH, things like MCSymbolData, MCSectionData, are private to the > assembler backend, and so only the assembler and object writer need to > know about them (they are unused when writing to a .s file, for > example). > > MCAssembler already maintains its own association of these data > structures, and there are a few bits available for the object file > backends inside MCSymbolData. I would be fine adding a few more for > use by specific object writers, if it simplifies your implementation. > > would it make sense to allow the object file streamer/writer code to provide custom derivations of MCSymbolData/MCSectionData so that its is free to define and interpret that data without other object file formats being aware of it? something like struct MCAssemblyDataFactory { virtual MCSymbolData * createSectionData (MCSection* Symbol) = 0; virtual MCSymbolData * createSymbolData (MCSymbol* Symbol) = 0; }; which would then me given to the assembler when created. I had started down a different road, that if acceptable, might provide a more general solution. I have added some API's to MCContext to allow me to associate arbitrary data with section's & symbol's. template void setSectionData (MCSection const * Section, value_type const & Value); template bool getSectionData (MCSection const * Section, value_type & Value) const; template void setSymbolData (MCSymbol const * Symbol, value_type const & Value); template bool getSymbolData (MCSymbol const * Symbol, value_type & Value) const; I can implement these with in a completely type safe manner without using virtual functions or virtual function tables and no dynamic runtime type information. With some extra work, they can use a single allocation per data item, currently their is two. I do rely on the typeid to return a typeinfo object for value_type, but I do this at compile time, not runtime. I'm sorry I have had time to be very present on this thread, but > please feel free to mail me / ping me if there is a something about > the assembler backend you have questions on. I'm very excited to see > COFF support coming up! > Hopefully, I will have something people can look at pretty soon here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/b16cc2fd/attachment.html From clattner at apple.com Fri May 7 12:19:11 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 May 2010 10:19:11 -0700 Subject: [LLVMdev] MCStreamer interface In-Reply-To: <1273212733.26912.5.camel@expression.housel.dyndns.org> References: <88D4D147-5C1E-4123-A7F9-9EE4AD884C7A@apple.com> <1273212733.26912.5.camel@expression.housel.dyndns.org> Message-ID: <8BBA1909-AC53-4D48-BFC7-CB59383D1DF3@apple.com> On May 6, 2010, at 11:12 PM, Peter S. Housel wrote: > On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > >> >> The important point here is that the COFF MCSection needs to >> have the right level of semantic information. In fact, >> MCSection is the place that I'd start for COFF bringup. >> >> OK, I see that now. The current isolation >> between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has >> proven somewhat problematic, mostly due to my lack of understanding. >> I guess MCSectionXXX was meant to provide communication between them. >> Should the same be true of MCSymbol, and their data counterparts? > > I'm enclosing my patch for reforming MCSectionCOFF to match the > implementation strategy of the other two MCSection classes. You may find > it useful as a starting point. It seems to be complete and correct, and > worked for what I tried with it, but I didn't find time to test it fully > (e.g., by bootstrapping clang under Cygwin). Looks really great to me, applied in r103267, thanks! One thing: +++ include/llvm/CodeGen/TargetLoweringObjectFileImpl.h (working copy) @@ -161,13 +161,15 @@ ... + virtual const MCSection *getDrectveSection() const { return DrectveSection; } This shouldn't need to be virtual? -Chris From aaronngray.lists at googlemail.com Fri May 7 12:48:20 2010 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Fri, 7 May 2010 18:48:20 +0100 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> Message-ID: On 7 May 2010 18:14, Chris Lattner wrote: > > On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > > On 7 May 2010 17:53, Chris Lattner wrote: > >> >> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> >> This seems counter intuitive to me, I can understand that C assigned that >>> behavior somewhat arbitrarily to uninitialized global variables, but in LLVM >>> there is explicitly a common linkage attribute to get that behavior. Nothing >>> in the llvm language reference indicates the behavior of a global with the >>> 'internal' linkage attribute should change based of the values used to >>> initialize it. >>> >>> >>> I don't follow. The object file format provides a means for efficiently >>> zero filling a local symbol. The compiler is just using it. What is the >>> problem you're trying to solve here? Since it is not exported out of the .o >>> file (it is local) there whether it is "common" or not is undetectable, we >>> just get a storage optimization. >>> >>> >> I don't know, I see common and it makes me think that things are getting >> merged together, but as you say it is local so the fact that its also common >> becomes irrelevant. In MachO do you just put these into the .bss section? >> >> >> Macho has a special zerofill directive (targeted at the BSS section) for >> this. You can see this by running your example like this: >> >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream > methods, the latter to deal with dllexports in ' > lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. > > > It looks to me that you should have an Emit method for the .scl, .def, > .type, .endef directives. One callback each. > There is already a MCStreamer::EmitZerofill() is seems to be MachO specific ? 'MCStreamer::EmitCOFFStabs()' ? 'MCStreamer:: EmitASCII()' ? Shall I do these as two separate patches ? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/bba5420b/attachment.html From aaronngray.lists at googlemail.com Fri May 7 13:03:33 2010 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Fri, 7 May 2010 19:03:33 +0100 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> Message-ID: > > 'MCStreamer::EmitCOFFStabs()' ? > Sorry, its not STABS, something more like, 'MCStreamer:: EmitCOFFType(uint8_t storageClass, uint8_t type)' > 'MCStreamer:: EmitASCII()' ? > And 'MCStreamer:: EmitASCII(uint8_t *string)' or should we use Twine ? Shall I do these as two separate patches ? > Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/ad17ab73/attachment.html From blunted2night at gmail.com Fri May 7 13:08:55 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Fri, 7 May 2010 11:08:55 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> Message-ID: On Fri, May 7, 2010 at 10:02 AM, Aaron Gray wrote: > On 7 May 2010 17:53, Chris Lattner wrote: > >> >> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> >> This seems counter intuitive to me, I can understand that C assigned that >>> behavior somewhat arbitrarily to uninitialized global variables, but in LLVM >>> there is explicitly a common linkage attribute to get that behavior. Nothing >>> in the llvm language reference indicates the behavior of a global with the >>> 'internal' linkage attribute should change based of the values used to >>> initialize it. >>> >>> >>> I don't follow. The object file format provides a means for efficiently >>> zero filling a local symbol. The compiler is just using it. What is the >>> problem you're trying to solve here? Since it is not exported out of the .o >>> file (it is local) there whether it is "common" or not is undetectable, we >>> just get a storage optimization. >>> >>> >> I don't know, I see common and it makes me think that things are getting >> merged together, but as you say it is local so the fact that its also common >> becomes irrelevant. In MachO do you just put these into the .bss section? >> >> >> Macho has a special zerofill directive (targeted at the BSS section) for >> this. You can see this by running your example like this: >> >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream > methods, the latter to deal with dllexports in ' > lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > I agree, I was going to put EmitASCII in, not sure about the zero fill, though I use the zero fill fragment when handling common symbols. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. > I think this Peter's patch takes care of this nicely. -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/510c839d/attachment.html From trevor.w.harmon at nasa.gov Fri May 7 13:17:33 2010 From: trevor.w.harmon at nasa.gov (Trevor Harmon) Date: Fri, 7 May 2010 11:17:33 -0700 Subject: [LLVMdev] getTripCount requires which optimization passes? In-Reply-To: References: <0D1A6E16-0987-489A-8E34-A5A2F62CEDC5@nasa.gov> Message-ID: <3AE154C9-9EE0-42A2-BD9E-27BA3DD54874@nasa.gov> On May 6, 2010, at 6:32 PM, ether zhhb wrote: > As the comment said: > /// The IndVarSimplify pass transforms loops to have a form that > this > /// function easily understands. > > you could try -indvars. After adding -indvars to the opt command, getTripCount still returns null. I suppose it's possible, depending on the scheduling of the pass manager, that indvars is running after my pass runs. I could force it to run first by adding it to my pass's getAnalysisUsage: void MyPass::getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired(); } But this isn't possible because for some reason there's no IndVarSimplify.h header file. The IndVarSimplify pass is defined only in its IndVarSimplify.cpp, so my pass can't use it. Not sure where to go from here. Should I post a test case illustrating the problem? Trevor From blunted2night at gmail.com Fri May 7 13:42:14 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Fri, 7 May 2010 11:42:14 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> Message-ID: On Fri, May 7, 2010 at 10:14 AM, Chris Lattner wrote: > > On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > > On 7 May 2010 17:53, Chris Lattner wrote: > >> >> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> >> This seems counter intuitive to me, I can understand that C assigned that >>> behavior somewhat arbitrarily to uninitialized global variables, but in LLVM >>> there is explicitly a common linkage attribute to get that behavior. Nothing >>> in the llvm language reference indicates the behavior of a global with the >>> 'internal' linkage attribute should change based of the values used to >>> initialize it. >>> >>> >>> I don't follow. The object file format provides a means for efficiently >>> zero filling a local symbol. The compiler is just using it. What is the >>> problem you're trying to solve here? Since it is not exported out of the .o >>> file (it is local) there whether it is "common" or not is undetectable, we >>> just get a storage optimization. >>> >>> >> I don't know, I see common and it makes me think that things are getting >> merged together, but as you say it is local so the fact that its also common >> becomes irrelevant. In MachO do you just put these into the .bss section? >> >> >> Macho has a special zerofill directive (targeted at the BSS section) for >> this. You can see this by running your example like this: >> >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream > methods, the latter to deal with dllexports in ' > lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. > > > It looks to me that you should have an Emit method for the .scl, .def, > .type, .endef directives. One callback each. > > -Chris > I've had included a EmitCOFFSymbolDef in MCStreamer to replace the EmitRawText that was handling this, seem to me it would be easier to have a single call given the restrictions on their use. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/5050ce6b/attachment.html From ambika at cse.iitb.ac.in Fri May 7 14:04:28 2010 From: ambika at cse.iitb.ac.in (ambika) Date: Sat, 08 May 2010 00:34:28 +0530 Subject: [LLVMdev] Error while running my pass with opt Message-ID: <4BE4643C.7000201@cse.iitb.ac.in> Hi, When I try to run my pass with opt , I get the following error : opt: /home/ambika/llvm_3/llvm-2.6/include/llvm/PassAnalysisSupport.h:203: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = llvm::DominatorTree]: Assertion `ResultPass && "getAnalysis*() called on an analysis that was not " "'required' by pass!"' failed. Can anybody tell as to why this error comes? regards, Ambika From clattner at apple.com Fri May 7 14:58:49 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 May 2010 12:58:49 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> Message-ID: <24477C99-2E6A-4116-BFF0-EA693470B778@apple.com> On May 7, 2010, at 11:42 AM, Nathan Jeffords wrote: >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> >> I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports in 'lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. >> >> We also need to sort out COFF TLOF, and get rid of the directive stuff. > > It looks to me that you should have an Emit method for the .scl, .def, .type, .endef directives. One callback each. > > -Chris > > I've had included a EmitCOFFSymbolDef in MCStreamer to replace the EmitRawText that was handling this, seem to me it would be easier to have a single call given the restrictions on their use. Sure, whatever you guys think is best. It is also very reasonable to add new enums to MCSymbolAttr if EmitSymbolAttribute is the right callback for these. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/8d9511ce/attachment.html From blunted2night at gmail.com Fri May 7 15:00:57 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Fri, 7 May 2010 13:00:57 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: <24477C99-2E6A-4116-BFF0-EA693470B778@apple.com> References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> <24477C99-2E6A-4116-BFF0-EA693470B778@apple.com> Message-ID: On Fri, May 7, 2010 at 12:58 PM, Chris Lattner wrote: > > On May 7, 2010, at 11:42 AM, Nathan Jeffords wrote: > > $ llc t.ll -o - -mtriple=i386-apple-darwin10 >>> .section __TEXT,__text,regular,pure_instructions >>> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >>> .section __DATA,__data >>> _tst2: ## @tst2 >>> .ascii "\000\001\002\003" >>> >> >> I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream >> methods, the latter to deal with dllexports in ' >> lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. >> >> We also need to sort out COFF TLOF, and get rid of the directive stuff. >> >> >> It looks to me that you should have an Emit method for the .scl, .def, >> .type, .endef directives. One callback each. >> >> -Chris >> > > I've had included a EmitCOFFSymbolDef in MCStreamer to replace the > EmitRawText that was handling this, seem to me it would be easier to have a > single call given the restrictions on their use. > > > Sure, whatever you guys think is best. It is also very reasonable to add > new enums to MCSymbolAttr if EmitSymbolAttribute is the right callback for > these. > > -Chris > I could see that working for the object file exporter, but I think it would be tricky to get the write assembly output. -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/539b2b0f/attachment.html From clattner at apple.com Fri May 7 15:01:59 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 May 2010 13:01:59 -0700 Subject: [LLVMdev] AsmPrinter behavior In-Reply-To: References: <3D7C79C0-655B-4BE3-B952-1E6357FDDA7A@apple.com> <3E249D55-2F2B-45D9-AA45-D58A45D0FB79@apple.com> <24477C99-2E6A-4116-BFF0-EA693470B778@apple.com> Message-ID: On May 7, 2010, at 1:00 PM, Nathan Jeffords wrote: > Sure, whatever you guys think is best. It is also very reasonable to add new enums to MCSymbolAttr if EmitSymbolAttribute is the right callback for these. > > -Chris > > I could see that working for the object file exporter, but I think it would be tricky to get the write assembly output. Ok, whatever you think is best. We need both paths to work :-) and adding new virtual methods is cheap. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/61473c66/attachment.html From aran at 100acres.us Fri May 7 16:41:37 2010 From: aran at 100acres.us (Aran Clauson) Date: Fri, 7 May 2010 14:41:37 -0700 Subject: [LLVMdev] Missuse of xmm register on X86-64 Message-ID: <201005071441.37926.aran@100acres.us> All, I've been working on a new scheduler and have somehow affected register selection. My problem is that an xmm register is being used as an index expression. Specifically, addss (%xmm1,%rax,4), %xmm0 I like the idea of a floating-point index, but, like the assembler, I don't know what that means. Any suggestions on where I should look for a solution to my problem? Aran -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/f870088b/attachment.bin From yuri at tsoft.com Fri May 7 18:29:40 2010 From: yuri at tsoft.com (Yuri) Date: Fri, 07 May 2010 16:29:40 -0700 Subject: [LLVMdev] Is the option --enable-shared discontinued in 2.7? In-Reply-To: References: <4BD76DF8.7040205@tsoft.com> <4BD7F50C.6060007@tsoft.com> <4BD874E9.9060206@tsoft.com> <4BE0BC76.8050400@tsoft.com> Message-ID: <4BE4A264.1090905@tsoft.com> Jeffrey Yasskin wrote: > That's odd. On Linux, g++ adds -lc to the end of the link line itself. > It must be adding -lstdc++ for you too, or you'd have more missing > symbols. If you run that command with "-v", it'll show you the actual > link line, but given your errors it does seem like -lc is missing. I > don't think it'll hurt anyone else to add that, so I'll try it. > > I assume builds without --enable-shared do work for you? If so, I > wonder why g++ would omit -lc for shared links but not executable > links? > Jeffrey, There is one more thing: there is no complete debug info in libLLVM-2.7.so when built with flags: --enable-assertions --enable-shared --enable-libffi --enable-debug-runtime --enable-debug-symbols --disable-optimized, at least not on FreeBSD. I use, as we discussed before, two attached patches to make shared lib build on FreeBSD. Resulting library has the size ~22MB. Same size as the Release one. Debugger refuses to enter functions: no debug info. libLLVM-2.7.so with the full debug info is ~158MB. I don't know why this command would loose debug info. Yuri --- command that makefile runs to build debug libLLVM-2.7.so --- /usr/local/gcc/4.5.0/bin/g++ -I/tmp/llvm-build/2.7/llvm-objects/include -I/tmp/llvm-build/2.7/llvm-objects/tools/llvm-shlib -I/tmp/llvm-build/2.7/llvm/include -I/tmp/llvm-build/2.7/llvm/tools/llvm-shlib -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -fno-exceptions -fno-rtti -fPIC -Woverloaded-virtual -L/usr/local/lib -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -g -Wl,-R -Wl,/tmp/llvm-build/2.7/llvm-objects/Debug/lib -L/tmp/llvm-build/2.7/llvm-objects/Debug/lib -L/tmp/llvm-build/2.7/llvm-objects/Debug/lib -shared -lc -o /tmp/llvm-build/2.7/llvm-objects/Debug/lib/libLLVM-2.7.so \ -Wl,--whole-archive -lLLVMARMAsmParser -lLLVMARMAsmPrinter -lLLVMARMCodeGen -lLLVMARMInfo -lLLVMAlphaAsmPrinter -lLLVMAlphaCodeGen -lLLVMAlphaInfo -lLLVMAnalysis -lLLVMArchive -lLLVMAsmParser -lLLVMAsmPrinter -lLLVMBitReader -lLLVMBitWriter -lLLVMBlackfinAsmPrinter -lLLVMBlackfinCodeGen -lLLVMBlackfinInfo -lLLVMCBackend -lLLVMCBackendInfo -lLLVMCellSPUAsmPrinter -lLLVMCellSPUCodeGen -lLLVMCellSPUInfo -lLLVMCodeGen -lLLVMCore -lLLVMCppBackend -lLLVMCppBackendInfo -lLLVMExecutionEngine -lLLVMInstCombine -lLLVMInstrumentation -lLLVMInterpreter -lLLVMJIT -lLLVMLinker -lLLVMMBlazeAsmPrinter -lLLVMMBlazeCodeGen -lLLVMMBlazeInfo -lLLVMMC -lLLVMMCParser -lLLVMMSIL -lLLVMMSILInfo -lLLVMMSP430AsmPrinter -lLLVMMSP430CodeGen -lLLVMMSP430Info -lLLVMMipsAsmPrinter -lLLVMMipsCodeGen -lLLVMMipsInfo -lLLVMPIC16AsmPrinter -lLLVMPIC16CodeGen -lLLVMPIC16Info -lLLVMPowerPCAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCInfo -lLLVMScalarOpts -lLLVMSelectionDAG -lLLVMSparcAsmPrinter -lLLVMSparcCodeGen -lLLVMSparcInfo -lLLVMSupport -lLLVMSystem -lLLVMSystemZAsmPrinter -lLLVMSystemZCodeGen -lLLVMSystemZInfo -lLLVMTarget -lLLVMTransformUtils -lLLVMX86AsmParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen -lLLVMX86Disassembler -lLLVMX86Info -lLLVMXCoreAsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreInfo -lLLVMipa -lLLVMipo -lLLVMpic16passes -Wl,--no-whole-archive -Wl,--no-undefined -lpthread -lffi -lm -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: llvm-patch-so.diff Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/0d650843/attachment-0002.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: issue968046_1.diff Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/0d650843/attachment-0003.pl From lhames at gmail.com Fri May 7 19:33:54 2010 From: lhames at gmail.com (Lang Hames) Date: Sat, 8 May 2010 10:33:54 +1000 Subject: [LLVMdev] Regarding LLVM Compiler In-Reply-To: References: Message-ID: Hi Kameshwar, You're best off sending emails such as this to the LLVM developers mailing list (llvmdev at cs.uiuc.edu). You'll reach a much wider audience. The PBQPRegAlloc::buildInterferenceMatrix method constructs a PBQP cost matrix representing a single interference constraint, which doesn't sound like what you want. It is only used by the PBQP allocator (-regalloc=pbqp), whereas LLVM uses linear scan by default (-regalloc=linscan). That's why you're not seeing it called. LLVM does not currently have an interference graph as such, because we do not have a graph coloring register allocator. You can get the same information from the LiveIntervals pass though. The LiveIntervals pass holds a set of LiveInterval objects, one for each register (both virtual and physical) that is live in the function. Each LiveInterval object describes the set of instructions for which its register is live. The LiveInterval::overlaps method will tell you whether or not two intervals overlap, which means the registers for those intervals interfere. (One caution: LiveInterval::overlaps currently triggers an assertion if the interval passed as a parameter is empty. You'll want to explicitly skip testing of empty intervals. They can just be treated as non-interfering.) To sum up, you probably want something like this: LiveIntervals *li_ = &getAnalysis(); for (LiveIntervals::iterator liItr = li_->begin(), liEnd = li_->end(); liItr != liEnd; ++liItr) { LiveInterval *li = liItr->second; if (li->empty()) continue; for (LiveIntervals::iterator li2Itr = llvm::next(liItr); li2Itr != liEnd; ++liItr) { LiveInterval *li2 = li2Itr->second; if (li2->empty()) continue; if (li->overlaps(*li2)) { // li->reg interferes with li2->reg. // Handle this however you need to. } } } Cheers, Lang. On Fri, May 7, 2010 at 9:59 PM, kameshwar nayak wrote: > Dear Sir, > > I am Kameshwar Nayak from India. I am in Final year Engineering. > We are working on Code-Optimization in a Compiler. We chose LLVM in order to > test our approach. But we are finding it difficult to access the > interference graph generated. > > We initially assumed PBQPRegAlloc::buildInterferenceMatrix() function > defined in "lib/CodeGen/RegAllocPBQP.cpp" builds interference graph. But we > discovered that the function is not being called during the course of > compilation > Could you please help us to access the interference graph generated.? > > Waiting for your reply > > -- > Regards, > > Kameshwar > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100508/75cc4b05/attachment.html From lhames at gmail.com Fri May 7 19:58:37 2010 From: lhames at gmail.com (Lang Hames) Date: Sat, 8 May 2010 10:58:37 +1000 Subject: [LLVMdev] Register allocation questions In-Reply-To: <4BE1B0C4.8020800@etinternational.com> References: <4BE1B0C4.8020800@etinternational.com> Message-ID: Hi Sam, - What exactly is the SpillIs parameter for this function? > My understanding is that it tells addIntervalsForSpills not to attempt to rematerialize instructions which use the registers for those intervals (since they're about to be spilled themselves). I've been passing in an empty set in the PBQP allocator with no correctness issues (that I've seen). I'm not sure what omitting it does to the quality of the generated code though. > - The return value is a vector of LiveIntervals, but it looks like they > have all been added to the LiveIntervals object already. Is this correct? > Yes - that's correct. > - Is the Spiller class functional? Using the -new-spill-framework option > with the linearscan allocator is giving me crashes. > Spiller is just an interface. TrivialSpiller, the default implementation for LLVM 2.6, was experimental. These days the default implementation just forwards spilling calls to addIntervalsForSpills anyway. Cheers, Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100508/370e9e55/attachment.html From rkistler at arxan.com Fri May 7 20:03:46 2010 From: rkistler at arxan.com (Robb Kistler) Date: Fri, 7 May 2010 18:03:46 -0700 Subject: [LLVMdev] Question about maturity of various ARM instruction sets in llvm 2.6 Message-ID: Thanks in advance, Are all of the ARM instruction sets that can be specified with -mattr stable? I'm specifically interested in -mattr=+v5te. I'm attempting to build a cross-compiling llvm-gcc to build for Android. The Android native toolchain builds for ARMv5te. --Robb From yuri at tsoft.com Fri May 7 20:24:56 2010 From: yuri at tsoft.com (Yuri) Date: Fri, 07 May 2010 18:24:56 -0700 Subject: [LLVMdev] Should the function operand flag 'sret' match the flag in function declaration? Message-ID: <4BE4BD68.9050104@tsoft.com> I have these two instructions, first one inside some procedure, second one is an outside declaration. Code verification passes and it runs, but incorrectly. Every time I saw such situation coming from c++ compiler, attributes 'noalias sret' appear on both call and declaration. Does such situation make sense, or (as I guess it is) a bug in verifier? I think verifier should match at least 'sret' flag in call and declaration. ... call void @_Z7returnsi(%struct.MyString* %z, i32 %1) nounwind ... declare void @_Z7returnsi(%struct.MyString* noalias sret, i32) ... Yuri From computerhenu at gmail.com Fri May 7 21:23:06 2010 From: computerhenu at gmail.com (Jiandong Wang) Date: Sat, 8 May 2010 10:23:06 +0800 Subject: [LLVMdev] Cannot Compile through an LLVM Pass Message-ID: hey guys. Now I am following the "Writing an LLVM Pass", but can't work it out. See what I have done. After completing the exact Makefile and source code under lib/Transforms/Hello, I typed the command "make" instead of "gmake" , then it generated silently "Hello.o" in Debug. But, next, when I tried to generate "hello.bc" by the command "llvm-g++ -O3 -emit-llvm Hello.cpp -c -o hello.bc", errors arose like that: In file included from /usr/local/include/llvm/Pass.h:32, from Hello.cpp:16: /usr/local/include/llvm/System/DataTypes.h:45:3: error: #error "Must #define __STDC_LIMIT_MACROS before #including System/DataTypes.h" /usr/local/include/llvm/System/DataTypes.h:49:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including System/DataTypes.h" In file included from /usr/local/include/llvm/Attributes.h:18, from /usr/local/include/llvm/Argument.h:18, from /usr/local/include/llvm/Function.h:24, from Hello.cpp:17: /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: /usr/local/include/llvm/Support/MathExtras.h:57: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available /usr/local/include/llvm/Support/MathExtras.h:57: error: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) /usr/local/include/llvm/Support/MathExtras.h:57: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUint(uint64_t)?: /usr/local/include/llvm/Support/MathExtras.h:62: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available your any piece of words will be appreciated greatly. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100508/11c3fbee/attachment.html From ttoole9 at gmail.com Fri May 7 22:26:31 2010 From: ttoole9 at gmail.com (Gang.Yao) Date: Fri, 7 May 2010 22:26:31 -0500 Subject: [LLVMdev] does llvm have some way to get the size of data type Message-ID: Hi: just like the c function sizeof(). I would avoid the usage of the c function call, and expect something like llvm intrinsic or some class providing this functionality. Does someone have experience in this? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100507/056bae50/attachment.html From etherzhhb at gmail.com Fri May 7 22:31:56 2010 From: etherzhhb at gmail.com (ether zhhb) Date: Sat, 8 May 2010 11:31:56 +0800 Subject: [LLVMdev] Auto-Vectorization in LLVM In-Reply-To: References: <75698E3D-ED28-434A-94B5-ED99481C4D06@rice.edu> <1759D124-633F-454C-9562-813001C2CEAE@apple.com> Message-ID: hi, On Thu, May 6, 2010 at 4:40 PM, Renato Golin wrote: > On 6 May 2010 05:34, Chris Lattner wrote: > > On May 5, 2010, at 1:01 PM, Rajkishore Barik wrote: > >> I would also like to know if there is any progress/future plans to > >> include this > >> in the main trunk? > > > > Unfortunately, nothing came of this project AFAIK, maybe Devang knows > more. > > I looked for it and couldn't find any, too. I found some > alias/dependency analysis inside loops, but nothing actively trying to > merge instructions. > > WRT progress/plans, there is the Poly project > (http://wiki.llvm.org/Polyhedral_optimization_framework) that is an > external representation to LLVM and could make much easier to map > dependencies and leave the road open for auto-vec, but again, nothing > on that direction has been done, too. Yep, we are only translate LLVM IR to Polyhedral Represent (or Polly IR) and translate them back to LLVM IR at this moment. After this is stage, we export the Polly IRs with openscop library (INRIA will public this in soon), and do something like auto-vectorization on (exported) Polly IR, then import them into llvm and translate them back to LLVM IR. But as i had discuss with tobi, we may not generate the "vectorized" or "parallelized " LLVM IR directly from Polly IR, instead, we may annotate the information such as "this loop is a parallel loop", or "dependence distance of this loop is 8" to LLVM IR in the form of metadata. Or, we will provide a analysis pass to hold such information. Then we can write passes that use these metadata (or analysis pass) to transform LLVM IR to do vectorization and parallelization for SIMD architecture, OpenMP, OpenCL and so on. Any comment or suggestion is welcome :) best regards ether Tobias and Ether should know > more on that. > > cheers, > --renato > > http://systemcall.org/ > > 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/20100508/9fbc9291/attachment.html From jyasskin at google.com Fri May 7 22:47:37 2010 From: jyasskin at google.com (Jeffrey Yasskin) Date: Fri, 7 May 2010 20:47:37 -0700 Subject: [LLVMdev] does llvm have some way to get the size of data type In-Reply-To: References: Message-ID: Try http://llvm.org/doxygen/classllvm_1_1ConstantExpr.html#a2ea738dfa37ea93c71756be89ba8d92 or http://llvm.org/doxygen/classllvm_1_1TargetData.html#64c154a7844026e76e18f792ee4ad4b3 On Fri, May 7, 2010 at 8:26 PM, Gang.Yao wrote: > Hi: > > just like the c function sizeof(). I would avoid the usage of the c > function call, and expect something like llvm > intrinsic or some class providing this functionality. > > Does someone have experience in this? > Thanks > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From shreyas76 at gmail.com Fri May 7 22:50:26 2010 From: shreyas76 at gmail.com (shreyas krishnan) Date: Fri, 7 May 2010 20:50:26 -0700 Subject: [LLVMdev] llvm-ld question Message-ID: Hi If I am linking a large library with my app, is there a way I can eliminate all the unused functions used in the library as part of the linking ? thanks shrey From yuri at tsoft.com Fri May 7 23:23:17 2010 From: yuri at tsoft.com (Yuri) Date: Fri, 07 May 2010 21:23:17 -0700 Subject: [LLVMdev] llvm-ld question In-Reply-To: References: Message-ID: <4BE4E735.10002@tsoft.com> shreyas krishnan wrote: > Hi > If I am linking a large library with my app, is there a way I can > eliminate all the unused functions used in the library as part of the > linking ? > If you are talking about static libraries (.a), this is done automatically by linker. You shouldn't have to worry about this. If you are talking about the shared library (.so) -- it will be loaded into memory unchanged. Not much you can do to reduce it's size. Yuri From mikem.llvm at gmail.com Sat May 8 00:19:46 2010 From: mikem.llvm at gmail.com (mike-m) Date: Sat, 8 May 2010 01:19:46 -0400 Subject: [LLVMdev] docs build (doxygen redux) Message-ID: Need review on new docs build. The directory layout has changed, and the changes propagate through source, build, install and possible website levels. What follows is an overview of the changes and some reasoning behind them. [patch can be found under pr6613; you will need doxygen.sh, doxygen.patch, doxygen.txt] [read: doxygen.txt for full instructions] A build diagram is also available; left-half is llvm, right is clang: http://llvm.org/bugs/attachment.cgi?id=4866 LIGHT-GREEN --> source files GREEN --> build files (ie: make) ORANGE --> install files (ie: make install) RED --> possible new mapping for build-to-website (ie: svn hook scripts) === SOURCE TREE Lots has changed, with intent to clean things up and promote build modularity. In the same fashion which SOURCE/lib/ tree places libraries adjacent to one another, irrespective of their inter-dependencies, this overhaul splits SOURCE/docs/ into two subdirs { main, api } where api/ is specifically for API documentation generated by doxygen. And main/ is everything else. By splitting the tree, we now how the ability for automagical recursive pickup of files for main/ docs. And the hierarchy is preserved. Files picked up are { .html .css .txt .png .jpg .gif }. For future file extensions we simply need to edit makefile and add to a var. The old system cannot do this, and required nested Makefiles for each directory level. Thus api/ was placed adjacent to main/ given the aforementioned recursive nature. SUMMARY LAYOUT CHANGE: SOURCE/docs/ -> SOURCE/docs/main/ SOURCE/docs/ -> SOURCE/docs/api/ SOURCE/tools/clang/docs/ -> SOURCE/tools/clang/docs/main/ SOURCE/tools/clang/docs/ -> SOURCE/tools/clang/docs/api/ === BUILD TREE (objdir) Build tree is consistent with SOURCE TREE changes. This layout will, if ever desired, easily accommodate M4 or other processing of html files during builds. The old layout, and processes, made too many assumptions that the checked-in files can be used verbatim during install or website update processes. This patch stages everything in a manner that all files and/or tarballs are available for install/website purposes. Tarballs are a product of 'make' and/or 'make install' and have been named 'html.tar' and 'html-api.tar' for main/ and api/, respectively. The tarball content include prefix pathnames of 'html/' and 'html/api/' for easy extraction by users, distro makers, and the 'make install' process. Pod files convert to man, html, ps and pdf (new!) files for both build and install situations and the files are suitable for both install and website purposes. Prepatch, the html files generated were unsuitable for install purposes - hardcoded links to root of webserver. SUMMARY LAYOUT CHANGE: mirrors SOURCE TREE changes === INSTALL TREE Prior to this patch, a 'make install' was unreliable for doxygen (eg: clang failed when gendoc from objdir) and even more confusingly, both llvm and clang would target the same locations in PREFIX dir specified by configure and files would mix-in and overwrite. Many unnecessary files were installed. This is all now fixed. The most notable change here is that except for man pages, llvm and clang will install docs to completely separate points in the tree. The new product points are INSTALL/share/doc/llvm/ and INSTALL/share/doc/clang/ for their respective docs. Naturally, both products still use place man pages into INSTALL/share/man/ as appropriate. Man-page placement honours configure --mandir option. The other placement honours --datarootdir option for the time being. --docdir may prove more appropriate but will require some configure.ac reworking which has yet to be done. Other targets like 'make uninstall' are useful again. Hint, 'make help' inside main/ or api/ will provide a list of useful targets available. Once nice add is that if you have a objdir already configured, it's possible now to build API docs without reconfiguring --enable-doxygen. You just need to use special target names like 'make docs' instead of 'make'; all documented under 'make help'. SUMMARY LAYOUT CHANGE: INSTALL/share/doc -> INSTALL/share/doc/llvm/ INSTALL/share/doc -> INSTALL/share/doc/clang/ === WEBSITE TREE I don't have visibility into all the details of automatic processes and directory layouts on the webserver. But *all* the files that are needed by those processes are present. This patch does not remove any files (if it does that's a bug), but it does change the src/build/install layouts. We have a couple of choices here, but I'll offer right up front to enhance the build system with tailored targets for use by any automatic processes. Optionally, stick with the same scripts but update them to work with the new build layout. === I realize these layout changes may seem heavy handed, but before passing judgement, I invite reviewers to try the patch. Try building API docs; install them. uninstall them. for your collaborative diagram likers, tune doxygen.cfg.in to your liking, generate again. Switch to clang's docs/ tree. build there. Then try something useful like adding doxygen comments to source code and regenerating the docs to see if doxygen outputs your API doc changes as expected. Hint: 'make help' in any of the OBJDIR docs/ subdirs. --mike-m From grosser at fim.uni-passau.de Sat May 8 04:04:05 2010 From: grosser at fim.uni-passau.de (Tobias Grosser) Date: Sat, 08 May 2010 11:04:05 +0200 Subject: [LLVMdev] Auto-Vectorization in LLVM In-Reply-To: <7500_1273136552_4BE285A8_7500_1719_1_k2zd9b9d95f1005060140v3c3fb940hef0ca0837c882be1@mail.gmail.com> References: <75698E3D-ED28-434A-94B5-ED99481C4D06@rice.edu> <1759D124-633F-454C-9562-813001C2CEAE@apple.com> <7500_1273136552_4BE285A8_7500_1719_1_k2zd9b9d95f1005060140v3c3fb940hef0ca0837c882be1@mail.gmail.com> Message-ID: <4BE52905.2000802@fim.uni-passau.de> On 05/06/10 10:40, Renato Golin wrote: > On 6 May 2010 05:34, Chris Lattner wrote: >> On May 5, 2010, at 1:01 PM, Rajkishore Barik wrote: >>> I would also like to know if there is any progress/future plans to >>> include this >>> in the main trunk? >> >> Unfortunately, nothing came of this project AFAIK, maybe Devang knows more. > > I looked for it and couldn't find any, too. I found some > alias/dependency analysis inside loops, but nothing actively trying to > merge instructions. > > WRT progress/plans, there is the Poly project > (http://wiki.llvm.org/Polyhedral_optimization_framework) that is an > external representation to LLVM and could make much easier to map > dependencies and leave the road open for auto-vec, but again, nothing > on that direction has been done, too. Tobias and Ether should know > more on that. Yes, as ether said we believe polly will simplify auto-vectorization a lot. With the help of polyhedral transformations it will be possible to generate and annotate vector parallel loops. These can afterwords be vectorized easily. I put an example on the wiki: http://wiki.llvm.org/Polyhedral_optimization_framework#2.3._Vectorization At the moment polly starts to become useful, but needs probably this summer to become mature. During the last weeks the first very simple tests started to work. At the moment we can detect matrix multiplication, create polyhedral information and code generate it again. Exporting the test case, optimizing it, and importing will be done in the next weeks. As soon as this is done, we can show impressive results for matmult and we compile the llvm-testsuite without crashing I will write a mail on the mailing list. Anybody who wants try polly earlier will probably trigger some unimplemented stuff. However you could try anyways. ;-) I will glad to help you with it. @Andreas: Do you believe your vectorization would work on dependence free loops? In that case, I would love to try your pass later. Scheduling it after polly (that created the vector parallel loops), should create vectorized loops easily. Tobi From idadesub at users.sourceforge.net Sat May 8 04:20:58 2010 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sat, 8 May 2010 02:20:58 -0700 Subject: [LLVMdev] does llvm have some way to get the size of data type In-Reply-To: References: Message-ID: Hello! You can do this: http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt On Fri, May 7, 2010 at 8:26 PM, Gang.Yao wrote: > Hi: > > just like the c function sizeof(). I would avoid the usage of the c > function call, and expect something like llvm > intrinsic or some class providing this functionality. > > Does someone have experience in this? > 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/20100508/1b8c58e6/attachment.html From nicholas at mxc.ca Sat May 8 05:14:38 2010 From: nicholas at mxc.ca (Nick Lewycky) Date: Sat, 08 May 2010 03:14:38 -0700 Subject: [LLVMdev] Unreachable code executed crash In-Reply-To: References: <4BE263DD.1030907@mxc.ca> <4BE390EF.9090503@mxc.ca> Message-ID: <4BE5398E.8090300@mxc.ca> Adarsh Yoga wrote: > Initially, tt was not a problem with the verifier, we were just > inserting a wrong instruction in our pass. Of course the verifier wasn't causing your problems. I want to find out why the verifier did not catch and error on the invalid module. Also we were able to figure > out the error you pointed out and our pass is running as intended!!! That's great to hear! Could you explain, briefly, what your bug was? Something more specific than 'inserting a wrong instruction'? Nick > Thanks a lot. > > On Fri, May 7, 2010 at 12:02 AM, Nick Lewycky > wrote: > > Adarsh Yoga wrote: > > I was able to solve that > > > What was wrong? I wasn't able to reproduce it and would still like > to teach the verifier whatever it missed. > > > but still crashing with the same error saying > > "Unreachable executed". I have attached the output with this mail. > > > This time you've got: > > %1 = load i32** getelementptr inbounds ({ i32* }* @structobj, i64 > 0, i32 0) > > in @temp0 but @structobj is nowhere in the file, which implies that > you created the GlobalValue but never inserted it. > > You can figure this out for yourself by taking the module dump (be > sure to remove "The Module: " from the beginning) and running > llvm-as on it. It finds these errors. > > Nick > > > Thanks in advance. > > On Thu, May 6, 2010 at 2:38 AM, Nick Lewycky > >> wrote: > > Adarsh Yoga wrote: > > Yes. Intially the pass was crashing when the module when > the module > verifier was running. I was able to solve that and now it is > crashing > when the bit writer pass is running. > > > The output is wrong in @thread_pool_init: > > :44:27: error: '%4' defined with type 'i1' > %5 = getelementptr i32* %4, i64 %indvar ; > [#uses=1] > ^ > where > > %4 = icmp slt i32 %threadnumber, 1 ; > [#uses=2] > > meaning that %4 is an i1 not an i32*. I'm not sure how you > managed > to do this, and how the verifier didn't catch it. Maybe the %4 > operand is actually an instruction in another function? > > I'll try to reproduce this and fix the verifier to catch it. > > Nick > > On Wed, May 5, 2010 at 8:39 PM, Nick Lewycky > > > > > >>> wrote: > > On 5 May 2010 17:12, Adarsh Yoga > > > > >>> wrote: > > Hi, > > I've written a pass that basically does some code > transformations to enable parallel execution of > loops. > After the > transformation llvm runs BitCode Writer pass , > which is > aborting > with Unreachable Executed error. > I have attached the input llvm code and the > output llvm > code for > reference. I am stuck at this problem for a few days > now. Please > let me know if you are able to find anything > unusual. > > > Have you tried running the module verifier after > your transform, > before writing out to bitcode? > > Nick > > Regards, > Adarsh > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu > > > > >> > > > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu > > > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington > > > > > > -- > Adarsh Yoga > Graduate Student, Computer Science > Indiana University, Bloomington From ambika at cse.iitb.ac.in Sat May 8 07:55:07 2010 From: ambika at cse.iitb.ac.in (ambika) Date: Sat, 08 May 2010 18:25:07 +0530 Subject: [LLVMdev] [Fwd: Error while running my pass with opt] Message-ID: <4BE55F2B.5020500@cse.iitb.ac.in> -------------- next part -------------- An embedded message was scrubbed... From: ambika Subject: [LLVMdev] Error while running my pass with opt Date: Sat, 08 May 2010 00:34:28 +0530 Size: 4743 Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100508/3f516ab1/attachment.eml From criswell at ad.uiuc.edu Sat May 8 08:13:28 2010 From: criswell at ad.uiuc.edu (Criswell, John T) Date: Sat, 8 May 2010 08:13:28 -0500 Subject: [LLVMdev] does llvm have some way to get the size of data type In-Reply-To: References: Message-ID: <32AC7D48FD55284CB56FE956E7F9FCD2210CBC191F@DSMAILBOX.ad.uiuc.edu> Look at the getABITypeSize() method (or some method with a name like that) of the TargetData class. Note that TargetData is an LLVM analysis pass; you have to declare it as a prerequisite pass in your pass's getAnalysisUsage() method. -- John T. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Gang.Yao [ttoole9 at gmail.com] Sent: Friday, May 07, 2010 10:26 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] does llvm have some way to get the size of data type Hi: just like the c function sizeof(). I would avoid the usage of the c function call, and expect something like llvm intrinsic or some class providing this functionality. Does someone have experience in this? Thanks From r3831110n at gmail.com Sat May 8 08:21:19 2010 From: r3831110n at gmail.com (Rebel Lion) Date: Sat, 8 May 2010 21:21:19 +0800 Subject: [LLVMdev] SSA failed on alias Message-ID: Hi guys, I'm new to LLVM and trying demo with the following C code: int main() { int a = 65535; *(1+(char *)a) = 0; return a; } unfortunately it generates the wrong IR: define i32 @main() nounwind { entry: store i8 0, i8* inttoptr (i64 65536 to i8*), align 65536 ret i32 65535 } seems SSA not applied on memory but incorrectly 'acrossed' by scalar values. Is it a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100508/7bb8dfac/attachment.html From grosser at fim.uni-passau.de Sat May 8 08:37:16 2010 From: grosser at fim.uni-passau.de (Tobias Grosser) Date: Sat, 08 May 2010 15:37:16 +0200 Subject: [LLVMdev] [Fwd: Error while running my pass with opt] In-Reply-To: <32584_1273325028_4BE565E4_32584_5318_1_4BE55F2B.5020500@cse.iitb.ac.in> References: <32584_1273325028_4BE565E4_32584_5318_1_4BE55F2B.5020500@cse.iitb.ac.in> Message-ID: <4BE5690C.3080307@fim.uni-passau.de> Hi, you need something like this in your pass: void YourPass::getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired(); } because you need to specify which analysis you are using. Tobi From eltoder at gmail.com Sat May 8 08:48:42 2010 From: eltoder at gmail.com (Eugene Toder) Date: Sat, 8 May 2010 14:48:42 +0100 Subject: [LLVMdev] SSA failed on alias In-Reply-To: References: Message-ID: Did you mean (char*)&a ? On Sat, May 8, 2010 at 2:21 PM, Rebel Lion wrote: > Hi guys, I'm new to LLVM and trying demo with the following C code: > int main() > { > ??int a = 65535; > ??*(1+(char *)a) = 0; > ??return a; > } > unfortunately it generates the wrong IR: > define i32 @main() nounwind { > entry: > ??store i8 0, i8* inttoptr (i64 65536 to i8*), align 65536 > ??ret i32 65535 > } > seems SSA not applied on memory but incorrectly 'acrossed' by scalar values. > Is it a bug? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From blunted2night at gmail.com Sat May 8 10:39:10 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Sat, 8 May 2010 08:39:10 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: Hi All, After a week of working with several people on this forum, I have a much more functional version of my Win32 COFF object file support. I believe this should cover most use cases. Attached is a patch file against r103336. Feedback is welcome. Thanks, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100508/e2d91ca0/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: changes.patch Type: application/octet-stream Size: 64935 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100508/e2d91ca0/attachment-0001.obj From hriener at student.tugraz.at Sat May 8 10:48:36 2010 From: hriener at student.tugraz.at (Heinz Riener) Date: Sat, 08 May 2010 17:48:36 +0200 Subject: [LLVMdev] Remove identical or redundant basic blocks? Message-ID: <4BE587D4.9040104@student.tugraz.at> Dear all, after optimizing a small LLVM example program (i.e., with opt -O3), the resulting code contains several basic blocks, which I consider identical or redundant. For instance, return: ; preds = %min.exit ret i32 0 bb15: ; preds = %min.exit ret i32 0 or, bb7.i: ; preds = %bb1.i br label %bb3.i bb9.i: ; preds = %bb1.i br label %bb3.i I think it is safe to remove the blocks bb7.i, bb9.i, bb15 while replacing each jump to bb15 with return and jumps to bb7.i, bb9.i with bb3.i. Is there any opt pass I can apply to the code to merge or remove these blocks? Heinz From dalej at apple.com Sat May 8 11:15:36 2010 From: dalej at apple.com (Dale Johannesen) Date: Sat, 8 May 2010 09:15:36 -0700 Subject: [LLVMdev] Remove identical or redundant basic blocks? In-Reply-To: <4BE587D4.9040104@student.tugraz.at> References: <4BE587D4.9040104@student.tugraz.at> Message-ID: <6F4A2896-69C8-435E-BE32-8AE8375F9A9A@apple.com> The branch folding pass does this, but it operates later, on the target-dependent form in llc. On May 8, 2010, at 8:48 AM, Heinz Riener wrote: > Dear all, > > after optimizing a small LLVM example program (i.e., with opt -O3), > the > resulting code contains several basic blocks, which I consider > identical > or redundant. For instance, > > return: ; preds = %min.exit > ret i32 0 > > bb15: ; preds = %min.exit > ret i32 0 > > or, > > bb7.i: ; preds = %bb1.i > br label %bb3.i > > bb9.i: ; preds = %bb1.i > br label %bb3.i > > I think it is safe to remove the blocks bb7.i, bb9.i, bb15 while > replacing each jump to bb15 with return and jumps to bb7.i, bb9.i with > bb3.i. > > Is there any opt pass I can apply to the code to merge or remove these > blocks? > > Heinz > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From jyasskin at google.com Sat May 8 11:53:10 2010 From: jyasskin at google.com (Jeffrey Yasskin) Date: Sat, 8 May 2010 09:53:10 -0700 Subject: [LLVMdev] does llvm have some way to get the size of data type In-Reply-To: References: Message-ID: mike-m, is there any way to configure doxygen to produce human-readable anchors? They might have avoided the duplication on this thread, since Erick and John could have seen that I was linking to their suggestions. On Fri, May 7, 2010 at 8:47 PM, Jeffrey Yasskin wrote: > Try http://llvm.org/doxygen/classllvm_1_1ConstantExpr.html#a2ea738dfa37ea93c71756be89ba8d92 > or http://llvm.org/doxygen/classllvm_1_1TargetData.html#64c154a7844026e76e18f792ee4ad4b3 > > On Fri, May 7, 2010 at 8:26 PM, Gang.Yao wrote: >> Hi: >> >> just like the c function sizeof(). I would avoid the usage of the c >> function call, and expect something like llvm >> intrinsic or some class providing this functionality. >> >> Does someone have experience in this? >> Thanks >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > From mikem.llvm at gmail.com Sat May 8 12:16:45 2010 From: mikem.llvm at gmail.com (mike-m) Date: Sat, 8 May 2010 13:16:45 -0400 Subject: [LLVMdev] does llvm have some way to get the size of data type In-Reply-To: References: Message-ID: No anchor naming options that I can find. But I'll keep an eye out for things that may improve anchor readability. --mike-m On 2010-05-08, at 12:53 PM, Jeffrey Yasskin wrote: > mike-m, is there any way to configure doxygen to produce > human-readable anchors? They might have avoided the duplication on > this thread, since Erick and John could have seen that I was linking > to their suggestions. > > On Fri, May 7, 2010 at 8:47 PM, Jeffrey Yasskin wrote: >> Try http://llvm.org/doxygen/classllvm_1_1ConstantExpr.html#a2ea738dfa37ea93c71756be89ba8d92 >> or http://llvm.org/doxygen/classllvm_1_1TargetData.html#64c154a7844026e76e18f792ee4ad4b3 >> >> On Fri, May 7, 2010 at 8:26 PM, Gang.Yao wrote: >>> Hi: >>> >>> just like the c function sizeof(). I would avoid the usage of the c >>> function call, and expect something like llvm >>> intrinsic or some class providing this functionality. >>> >>> Does someone have experience in this? >>> Thanks From jyasskin at google.com Sat May 8 12:18:50 2010 From: jyasskin at google.com (Jeffrey Yasskin) Date: Sat, 8 May 2010 10:18:50 -0700 Subject: [LLVMdev] does llvm have some way to get the size of data type In-Reply-To: References: Message-ID: Thanks! On Sat, May 8, 2010 at 10:16 AM, mike-m wrote: > No anchor naming options that I can find. But I'll keep an eye out for things that may improve anchor readability. > > --mike-m > > On 2010-05-08, at 12:53 PM, Jeffrey Yasskin wrote: > >> mike-m, is there any way to configure doxygen to produce >> human-readable anchors? They might have avoided the duplication on >> this thread, since Erick and John could have seen that I was linking >> to their suggestions. >> >> On Fri, May 7, 2010 at 8:47 PM, Jeffrey Yasskin wrote: >>> Try http://llvm.org/doxygen/classllvm_1_1ConstantExpr.html#a2ea738dfa37ea93c71756be89ba8d92 >>> or http://llvm.org/doxygen/classllvm_1_1TargetData.html#64c154a7844026e76e18f792ee4ad4b3 >>> >>> On Fri, May 7, 2010 at 8:26 PM, Gang.Yao wrote: >>>> Hi: >>>> >>>> just like the c function sizeof(). I would avoid the usage of the c >>>> function call, and expect something like llvm >>>> intrinsic or some class providing this functionality. >>>> >>>> Does someone have experience in this? >>>> Thanks > > From kuba at gcc.gnu.org Sat May 8 12:20:18 2010 From: kuba at gcc.gnu.org (Jakub Staszak) Date: Sat, 8 May 2010 15:20:18 -0200 Subject: [LLVMdev] PR7052 Message-ID: Hello, This patch fixes PR7052. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr7052.patch Type: application/octet-stream Size: 3223 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100508/4648de5a/attachment.obj From clattner at apple.com Sat May 8 12:31:44 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 8 May 2010 10:31:44 -0700 Subject: [LLVMdev] Should the function operand flag 'sret' match the flag in function declaration? In-Reply-To: <4BE4BD68.9050104@tsoft.com> References: <4BE4BD68.9050104@tsoft.com> Message-ID: On May 7, 2010, at 6:24 PM, Yuri wrote: > I have these two instructions, first one inside some procedure, second > one is an outside declaration. > Code verification passes and it runs, but incorrectly. Right, this code has undefined behavior. > Every time I saw such situation coming from c++ compiler, attributes > 'noalias sret' appear on both call and declaration. > > Does such situation make sense, or (as I guess it is) a bug in verifier? > I think verifier should match at least 'sret' flag in call and declaration. > > ... > call void @_Z7returnsi(%struct.MyString* %z, i32 %1) nounwind > ... > declare void @_Z7returnsi(%struct.MyString* noalias sret, i32) > ... The verifier flags and rejects *invalid* IR, not IR with undefined behavior. Dan has been working on a pass (in lib/Analysis/Lint.cpp) that should catch this sort of thing. If it doesn't already, please send in a patch to make it catch it. Thanks! -Chris From ambika at cse.iitb.ac.in Sat May 8 13:03:25 2010 From: ambika at cse.iitb.ac.in (ambika) Date: Sat, 08 May 2010 23:33:25 +0530 Subject: [LLVMdev] [Fwd: Error while running my pass with opt] In-Reply-To: <4BE5690C.3080307@fim.uni-passau.de> References: <32584_1273325028_4BE565E4_32584_5318_1_4BE55F2B.5020500@cse.iitb.ac.in> <4BE5690C.3080307@fim.uni-passau.de> Message-ID: <4BE5A76D.7050703@cse.iitb.ac.in> But this is already present in my pass. And I am not able to understand the cause for the error: opt: /home/ambika/llvm_3/llvm-2.6/include/llvm/PassAnalysisSupport.h:203: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = llvm::DominatorTree]: Assertion `ResultPass && "getAnalysis*() called on an analysis that was not " "'required' by pass!"' failed. What can possibly cause this. Any ideas will also help. Tobias Grosser wrote: > Hi, > > you need something like this in your pass: > > void YourPass::getAnalysisUsage(AnalysisUsage &AU) const { > AU.addRequired(); > } > > because you need to specify which analysis you are using. > > Tobi From eli.friedman at gmail.com Sat May 8 14:19:40 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 8 May 2010 12:19:40 -0700 Subject: [LLVMdev] PR7052 In-Reply-To: References: Message-ID: On Sat, May 8, 2010 at 10:20 AM, Jakub Staszak wrote: > Hello, > > This patch fixes PR7052. This should use TargetData::getTypeStoreSize instead; looks fine otherwise. -Eli From yuri at tsoft.com Sat May 8 14:45:04 2010 From: yuri at tsoft.com (Yuri) Date: Sat, 08 May 2010 12:45:04 -0700 Subject: [LLVMdev] Scope of JIT implementation for the target? Message-ID: <4BE5BF40.2070002@tsoft.com> I see that JIT isn't supported for the Sparc targets for example. What is the scope of the change to add JIT support. I see, for example, that for X86 target class X86JITInfo is defined with 10 methods. It's only used in one place: setPICBase. Also createX86JITCodeEmitterPass creates JIT pass -- very simple. So is implementing these steps enough to add JIT, or there are some hidden difficulties that aren't obvious? Yuri From clattner at apple.com Sat May 8 14:59:46 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 8 May 2010 12:59:46 -0700 Subject: [LLVMdev] Scope of JIT implementation for the target? In-Reply-To: <4BE5BF40.2070002@tsoft.com> References: <4BE5BF40.2070002@tsoft.com> Message-ID: On May 8, 2010, at 12:45 PM, Yuri wrote: > I see that JIT isn't supported for the Sparc targets for example. > What is the scope of the change to add JIT support. > > I see, for example, that for X86 target class X86JITInfo is defined with > 10 methods. It's only used in one place: setPICBase. Also > createX86JITCodeEmitterPass creates JIT pass -- very simple. > > So is implementing these steps enough to add JIT, or there are some > hidden difficulties that aren't obvious? The biggest piece is adding hooks for instruction encoding. Sparc should be mostly autogenerated from the .td files like the PPC backend, so take a look at lib/Target/PowerPC/PPCCodeEmitter.cpp. However, in the mid-term, we're planning on eliminating the JIT target interfaces as they are now and replacing them with an MC implementation. If you're interested in getting the JIT up, I'd strongly suggest working on converting the sparc backend to start using the MC interfaces (e.g. switch SparcAsmPrinter.cpp to print instructions by lowering them to MCInst, then add a new SparcMCInstPrinter interface). There is some information about MC here: http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html and I'm happy to answer any questions about it. -Chris From clattner at apple.com Sat May 8 15:03:23 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 8 May 2010 13:03:23 -0700 Subject: [LLVMdev] PR7052 In-Reply-To: References: Message-ID: <479AF980-554A-4BF4-B9CB-B392133CA953@apple.com> Applied in r103347 with Eli's suggested tweak. Please close the PR when you get a chance, thanks! -Chris On May 8, 2010, at 10:20 AM, Jakub Staszak wrote: > Hello, > > This patch fixes PR7052. > > Regards > -- > Jakub Staszak_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From eltoder at gmail.com Sat May 8 17:50:23 2010 From: eltoder at gmail.com (Eugene Toder) Date: Sat, 8 May 2010 23:50:23 +0100 Subject: [LLVMdev] [Fwd: Error while running my pass with opt] In-Reply-To: <4BE5A76D.7050703@cse.iitb.ac.in> References: <32584_1273325028_4BE565E4_32584_5318_1_4BE55F2B.5020500@cse.iitb.ac.in> <4BE5690C.3080307@fim.uni-passau.de> <4BE5A76D.7050703@cse.iitb.ac.in> Message-ID: Try setting breakpoint in your getAnalysisUsage() and see if it's actually called. Maybe there's a subtle difference in signature. Failing that, try breaking on assertion failure and examining it more closely. On Sat, May 8, 2010 at 7:03 PM, ambika wrote: > But this is already present in my pass. > And I am not able to understand the cause for the error: > > opt: /home/ambika/llvm_3/llvm-2.6/include/llvm/PassAnalysisSupport.h:203: > AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const > [with AnalysisType = llvm::DominatorTree]: Assertion `ResultPass && > "getAnalysis*() called on an analysis that was not " "'required' by > pass!"' failed. > > What can possibly cause this. Any ideas will also help. > > Tobias Grosser wrote: >> Hi, >> >> you need something like this in your pass: >> >> void YourPass::getAnalysisUsage(AnalysisUsage &AU) const { >> ? AU.addRequired(); >> } >> >> because you need to specify which analysis you are using. >> >> Tobi > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From eltoder at gmail.com Sat May 8 17:55:06 2010 From: eltoder at gmail.com (Eugene Toder) Date: Sat, 8 May 2010 23:55:06 +0100 Subject: [LLVMdev] Remove identical or redundant basic blocks? In-Reply-To: <6F4A2896-69C8-435E-BE32-8AE8375F9A9A@apple.com> References: <4BE587D4.9040104@student.tugraz.at> <6F4A2896-69C8-435E-BE32-8AE8375F9A9A@apple.com> Message-ID: Would it make sense to have a similar pass that operates on llvm main IR? On Sat, May 8, 2010 at 5:15 PM, Dale Johannesen wrote: > The branch folding pass does this, but it operates later, on the > target-dependent form in llc. > > On May 8, 2010, at 8:48 AM, Heinz Riener wrote: > >> Dear all, >> >> after optimizing a small LLVM example program (i.e., with opt -O3), >> the >> resulting code contains several basic blocks, which I consider >> identical >> or redundant. ?For instance, >> >> return: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; preds = %min.exit >> ? ret i32 0 >> >> bb15: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; preds = %min.exit >> ? ret i32 0 >> >> or, >> >> bb7.i: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; preds = %bb1.i >> ? br label %bb3.i >> >> bb9.i: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; preds = %bb1.i >> ? br label %bb3.i >> >> I think it is safe to remove the blocks bb7.i, bb9.i, bb15 while >> replacing each jump to bb15 with return and jumps to bb7.i, bb9.i with >> bb3.i. >> >> Is there any opt pass I can apply to the code to merge or remove these >> blocks? >> >> Heinz >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From criswell at illinois.edu Sun May 9 06:36:31 2010 From: criswell at illinois.edu (John Criswell) Date: Sun, 09 May 2010 05:36:31 -0600 Subject: [LLVMdev] Remove identical or redundant basic blocks? In-Reply-To: References: <4BE587D4.9040104@student.tugraz.at> <6F4A2896-69C8-435E-BE32-8AE8375F9A9A@apple.com> Message-ID: <4BE69E3F.2040905@illinois.edu> Eugene Toder wrote: > Would it make sense to have a similar pass that operates on llvm main IR? > The unify exit return node (-mergereturn?) pass should take care of the first example. The -simplifycfg option might take care of the second example. Both work on LLVM IR. -- John T. > On Sat, May 8, 2010 at 5:15 PM, Dale Johannesen wrote: > >> The branch folding pass does this, but it operates later, on the >> target-dependent form in llc. >> >> On May 8, 2010, at 8:48 AM, Heinz Riener wrote: >> >> >>> Dear all, >>> >>> after optimizing a small LLVM example program (i.e., with opt -O3), >>> the >>> resulting code contains several basic blocks, which I consider >>> identical >>> or redundant. For instance, >>> >>> return: ; preds = %min.exit >>> ret i32 0 >>> >>> bb15: ; preds = %min.exit >>> ret i32 0 >>> >>> or, >>> >>> bb7.i: ; preds = %bb1.i >>> br label %bb3.i >>> >>> bb9.i: ; preds = %bb1.i >>> br label %bb3.i >>> >>> I think it is safe to remove the blocks bb7.i, bb9.i, bb15 while >>> replacing each jump to bb15 with return and jumps to bb7.i, bb9.i with >>> bb3.i. >>> >>> Is there any opt pass I can apply to the code to merge or remove these >>> blocks? >>> >>> Heinz >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From criswell at illinois.edu Sun May 9 06:47:49 2010 From: criswell at illinois.edu (John Criswell) Date: Sun, 09 May 2010 05:47:49 -0600 Subject: [LLVMdev] [Fwd: Error while running my pass with opt] In-Reply-To: <4BE5A76D.7050703@cse.iitb.ac.in> References: <32584_1273325028_4BE565E4_32584_5318_1_4BE55F2B.5020500@cse.iitb.ac.in> <4BE5690C.3080307@fim.uni-passau.de> <4BE5A76D.7050703@cse.iitb.ac.in> Message-ID: <4BE6A0E5.1050301@illinois.edu> ambika wrote: > But this is already present in my pass. > And I am not able to understand the cause for the error: > Can you send a copy of your getAnalysisUsage() method for your pass? There are some funny errors that can occur when you do things that the PassManager cannot handle. For example, if you're requiring a transform pass, that can cause strange assertions from the PassManager. Requiring a BasicBlock pass from a FunctionPass might also hit assertions within PassManager (I think). If you post your getAnalysisUsage() method, I can take a quick look to see if you're doing something that I know is unsupported by PassManager. -- John T. > opt: /home/ambika/llvm_3/llvm-2.6/include/llvm/PassAnalysisSupport.h:203: > AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const > [with AnalysisType = llvm::DominatorTree]: Assertion `ResultPass && > "getAnalysis*() called on an analysis that was not " "'required' by > pass!"' failed. > > What can possibly cause this. Any ideas will also help. > > Tobias Grosser wrote: > >> Hi, >> >> you need something like this in your pass: >> >> void YourPass::getAnalysisUsage(AnalysisUsage &AU) const { >> AU.addRequired(); >> } >> >> because you need to specify which analysis you are using. >> >> Tobi >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From lhames at gmail.com Sun May 9 07:27:16 2010 From: lhames at gmail.com (Lang Hames) Date: Sun, 9 May 2010 22:27:16 +1000 Subject: [LLVMdev] Machine Verifier question. Message-ID: Running the following command, llc -asm-verbose=false -O3 Output/ReedSolomon.llvm.bc -o Output/ReedSolomon.llc.s -verify-machineinstrs in llvm-test/SingleSource/Benchmarks/Misc currently yields seven errors, all of the form *** Bad machine code: PHI operand is not live-out from predecessor *** - function: main - basic block: bb2.i.preheader 0x1ba7680 (BB#5) - instruction: %reg1032 = PHI %reg1280, , %reg1287, - operand 1: %reg1280 The code seems to run ok though. Is this something that's worth looking in to, or just over zealous reporting by the machine verifier? Cheers, Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100509/6529bd36/attachment.html From ambika at cse.iitb.ac.in Sun May 9 08:07:08 2010 From: ambika at cse.iitb.ac.in (ambika) Date: Sun, 09 May 2010 18:37:08 +0530 Subject: [LLVMdev] [Fwd: Error while running my pass with opt] In-Reply-To: <4BE6A0E5.1050301@illinois.edu> References: <32584_1273325028_4BE565E4_32584_5318_1_4BE55F2B.5020500@cse.iitb.ac.in> <4BE5690C.3080307@fim.uni-passau.de> <4BE5A76D.7050703@cse.iitb.ac.in> <4BE6A0E5.1050301@illinois.edu> Message-ID: <4BE6B37C.3010203@cse.iitb.ac.in> Here is getAnalysisUsage() i am using, void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll(); AU.addRequired(); } and then I use it as, bool ptrTest::runOnModule(Module &M) { DominatorTree &DT = getAnalysis(); ...... } John Criswell wrote: > ambika wrote: >> But this is already present in my pass. >> And I am not able to understand the cause for the error: >> > > Can you send a copy of your getAnalysisUsage() method for your pass? > There are some funny errors that can occur when you do things that the > PassManager cannot handle. > > For example, if you're requiring a transform pass, that can cause > strange assertions from the PassManager. Requiring a BasicBlock pass > from a FunctionPass might also hit assertions within PassManager (I > think). > > If you post your getAnalysisUsage() method, I can take a quick look to > see if you're doing something that I know is unsupported by PassManager. > > -- John T. > >> opt: >> /home/ambika/llvm_3/llvm-2.6/include/llvm/PassAnalysisSupport.h:203: >> AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const >> [with AnalysisType = llvm::DominatorTree]: Assertion `ResultPass && >> "getAnalysis*() called on an analysis that was not " "'required' by >> pass!"' failed. >> >> What can possibly cause this. Any ideas will also help. >> >> Tobias Grosser wrote: >> >>> Hi, >>> >>> you need something like this in your pass: >>> >>> void YourPass::getAnalysisUsage(AnalysisUsage &AU) const { >>> AU.addRequired(); >>> } >>> >>> because you need to specify which analysis you are using. >>> >>> Tobi >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > From luoyonggang at gmail.com Sun May 9 08:28:41 2010 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Sun, 9 May 2010 21:28:41 +0800 Subject: [LLVMdev] Dead ELFRelocation.h file in include\llvm\CodeGen Message-ID: -- ?? ? ??? Yours sincerely, Yonggang Luo From luoyonggang at gmail.com Sun May 9 08:31:01 2010 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Sun, 9 May 2010 21:31:01 +0800 Subject: [LLVMdev] Dead ELFRelocation.h file in include\llvm\CodeGen In-Reply-To: References: Message-ID: Class ELFRelocation is already moved to llvm/lib/CodeGen/ELF.h ?? ? ??? Yours sincerely, Yonggang Luo From hriener at student.tugraz.at Sun May 9 09:17:53 2010 From: hriener at student.tugraz.at (Heinz Riener) Date: Sun, 09 May 2010 16:17:53 +0200 Subject: [LLVMdev] Remove identical or redundant basic blocks? In-Reply-To: <4BE69E3F.2040905@illinois.edu> References: <4BE587D4.9040104@student.tugraz.at> <6F4A2896-69C8-435E-BE32-8AE8375F9A9A@apple.com> <4BE69E3F.2040905@illinois.edu> Message-ID: <4BE6C411.6020102@student.tugraz.at> Dale is totally right, all of these blocks disappear in later target-dependent optimizations. I have not thought about that since eliminating these blocks requires no target-dependent information. However, I guess it is not worth eliminating them earlier. John, I tried your advice and executed opt (after -O3) again with -mergereturn and -simplifycfg: The -mergereturn pass introduces another basic block, called UnifiedReturnBlock, and replaces ret instructions with jumps to UnifiedReturnBlock. So, it does not eliminates any block but it creates one. (I think its task is to merge the ret instructions (and not the blocks).) The -simplifycfg pass does not affect my code at all. Moreover, according to 'StandardPasses.h' I guess the pass already runs (about 4 times) as a part of -O3. I have yet not looked at the actual code of simplifycfg but the comment in 'StandarPasses.h' says it should merge and eliminate basic blocks. include/llvm/Support/StandardPasses.h, line 129 (SVN-97366): PM->add(createCFGSimplificationPass()); // Merge & remove BBs Heinz On 05/09/2010 01:36 PM, John Criswell wrote: > Eugene Toder wrote: >> Would it make sense to have a similar pass that operates on llvm main IR? >> > > The unify exit return node (-mergereturn?) pass should take care of the > first example. The -simplifycfg option might take care of the second > example. Both work on LLVM IR. > > -- John T. >> On Sat, May 8, 2010 at 5:15 PM, Dale Johannesen wrote: >> >>> The branch folding pass does this, but it operates later, on the >>> target-dependent form in llc. >>> >>> On May 8, 2010, at 8:48 AM, Heinz Riener wrote: >>> >>> >>>> Dear all, >>>> >>>> after optimizing a small LLVM example program (i.e., with opt -O3), >>>> the >>>> resulting code contains several basic blocks, which I consider >>>> identical >>>> or redundant. For instance, >>>> >>>> return: ; preds = %min.exit >>>> ret i32 0 >>>> >>>> bb15: ; preds = %min.exit >>>> ret i32 0 >>>> >>>> or, >>>> >>>> bb7.i: ; preds = %bb1.i >>>> br label %bb3.i >>>> >>>> bb9.i: ; preds = %bb1.i >>>> br label %bb3.i >>>> >>>> I think it is safe to remove the blocks bb7.i, bb9.i, bb15 while >>>> replacing each jump to bb15 with return and jumps to bb7.i, bb9.i with >>>> bb3.i. >>>> >>>> Is there any opt pass I can apply to the code to merge or remove these >>>> blocks? >>>> >>>> Heinz >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dalej at apple.com Sun May 9 11:41:12 2010 From: dalej at apple.com (Dale Johannesen) Date: Sun, 9 May 2010 09:41:12 -0700 Subject: [LLVMdev] Remove identical or redundant basic blocks? In-Reply-To: <4BE6C411.6020102@student.tugraz.at> References: <4BE587D4.9040104@student.tugraz.at> <6F4A2896-69C8-435E-BE32-8AE8375F9A9A@apple.com> <4BE69E3F.2040905@illinois.edu> <4BE6C411.6020102@student.tugraz.at> Message-ID: On May 9, 2010, at 7:17 AM, Heinz Riener wrote: > Dale is totally right, all of these blocks disappear in later > target-dependent optimizations. I have not thought about that since > eliminating these blocks requires no target-dependent information. > However, I guess it is not worth eliminating them earlier. Branches have sufficient target-dependent aspects that you really need to deal with them at that level. For example: ret might expand to a single instruction, a lengthy epilog, or a tail call many targets have limits on how far a conditional branch can reach; sometimes intermediate unconditional branches are needed as steppingstones not all targets can support all conditional branches that appear in the IR; some of them expand to multiple instructions Since targets need to deal with this stuff in any case, it's not worth it to try to be too clever at the target-independent level. In some cases the target would have to undo whatever you did anyway. From clattner at apple.com Sun May 9 12:35:31 2010 From: clattner at apple.com (Chris Lattner) Date: Sun, 9 May 2010 10:35:31 -0700 Subject: [LLVMdev] Dead ELFRelocation.h file in include\llvm\CodeGen In-Reply-To: References: Message-ID: Thanks, zapped! On May 9, 2010, at 6:31 AM, ???(Yonggang Luo) wrote: > Class ELFRelocation is already moved to llvm/lib/CodeGen/ELF.h > ?? > ? > ??? > 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 edwintorok at gmail.com Wed May 5 15:26:00 2010 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Wed, 05 May 2010 23:26:00 +0300 Subject: [LLVMdev] Another bad binutils? In-Reply-To: <147506.66777.qm@web62005.mail.re1.yahoo.com> References: <147506.66777.qm@web62005.mail.re1.yahoo.com> Message-ID: <4BE1D458.1010507@gmail.com> On 05/05/2010 11:12 PM, Samuel Crow wrote: > After waiting through about 2 hours of hard drive spinning for Clang to link under my Xubuntu Lucid Lynx Linux setup on VirtualBox, ld finally just gave up trying to link it. How much memory? Debug or Release build? > I was using CMake's build scripts on version 2.7 release of LLVM and Clang. The version of ld is (GNU Binutils for Ubuntu) 2.20.1-system.20100303. Can anyone confirm this problem? FWIW I use the Debian version of it, GNU ld (GNU Binutils for Debian) 2.20.1-system.20100303, and never had problems with it. Best regards, --Edwin From baldrick at free.fr Sun May 9 23:30:40 2010 From: baldrick at free.fr (Duncan Sands) Date: Mon, 10 May 2010 06:30:40 +0200 Subject: [LLVMdev] How can I remove Intrinsic Functions during llvm-gcc compilation? In-Reply-To: References: Message-ID: <4BE78BF0.3010307@free.fr> Hi Hao Shen, > I am using llvm-gcc --emit-llvm to generate byte code. With llvm > readable ll format, I found some standard C library function such as > llvm.memset. this is not a C library function, it is an LLVM intrinsic. An intrinsic is analogous to a builtin in gcc. An intrinsic may be expanded out into a code sequence by the compiler, or may get turned into a library call (which sounds like is what you are seeing). > In fact, I'm trying to compile newlibc with llvm, I do not need this > kind of llvm functions. How can I remove them during the compilation? You can't avoid them. The same problem exists with gcc: you can't always avoid having gcc use the gcc memset builtin. However it has to be said that gcc generates its memset builtin less often than llvm-gcc generates llvm.memset, so this is not as visible. Also (I'm not sure about this) it may be that on some platforms gcc always expands builtin_memset into a code sequence rather than generating a call to the library memset function. However, gcc is not obliged to use a code sequence even in a freestanding environment. The environment is always required to provide memset. Here's what the gcc docs say: GCC requires the freestanding environment provide `memcpy', `memmove', `memset' and `memcmp'. Ciao, Duncan. From baldrick at free.fr Sun May 9 23:56:29 2010 From: baldrick at free.fr (Duncan Sands) Date: Mon, 10 May 2010 06:56:29 +0200 Subject: [LLVMdev] [Patch] Bufer overrun in getValueTypeList() In-Reply-To: References: <4BD47791.4090008@jmartinez.org> <4BD6D376.2040801@free.fr> Message-ID: <4BE791FD.9090309@free.fr> Hi Javier, > The attached patch is to add an assert to getValueTypeList() to verify that for simple value types their value is NOT between MAX_ALLOWED_VALUETYPE and LastSimpleValueType (inclusive) as this causes a buffer overrun. thanks for the patch. I applied a variant in commit 103391. Ciao, Duncan. From proljc at gmail.com Mon May 10 00:54:27 2010 From: proljc at gmail.com (Liu) Date: Mon, 10 May 2010 13:54:27 +0800 Subject: [LLVMdev] How to build a cross llvm-gcc compiler for Arm Cortex-A8 In-Reply-To: References: Message-ID: I do it like this: export PATH=/opt/arm-2010q1/bin/:$PATH ../llvm-gcc-4.2-2.7.source/configure --prefix=/opt/llvm --enable-languages=c,c++ --enable-checking --enable-llvm=/root/llvm-obj --disable-bootstrap --disable-multilib --target=arm-none-linux-gnueabi --enable-cross --with-as=/opt/arm-2010q1/arm-none-linux-gnueabi/bin/as --with-ld=/opt/arm-2010q1/arm-none-linux-gnueabi/bin/ld make it gets error: /opt/arm-2010q1/arm-none-linux-gnueabi/bin/ld: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status I copy arm-linux's crti.o and crtn.o there. It gets another error: /root/llvm-gcc-obj/./gcc/crti.o: In function `_init': /home/oe/stuff/workspace/work/armv7a-angstrom-linux-gnueabi/glibc-2.9-r36.3/build-arm-angstrom-linux-gnueabi/nptl/crti.S:37: undefined reference to `__pthread_initialize_minimal_internal' /opt/arm-2010q1/arm-none-linux-gnueabi/bin/ld: ./libgcc_s.so.1.tmp: hidden symbol `__pthread_initialize_minimal_internal' isn't defined /opt/arm-2010q1/arm-none-linux-gnueabi/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status 2010/5/7 Anton Korobeynikov > Hello > > > My host is Linux on x86, and I want llvm-gcc generate code for Arm > > Cortex-A8. > > I saw that in LLVM 2.7 Release Notes, but I can't find step to > build > > it. Anyone tell me? > Build llvm-gcc exactly the same way you're building the cross gcc for > your target. > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100510/0714a437/attachment.html From yuri at tsoft.com Mon May 10 06:20:43 2010 From: yuri at tsoft.com (Yuri) Date: Mon, 10 May 2010 04:20:43 -0700 Subject: [LLVMdev] Can the structure, having few integers and 'opaque', be manipulated upon? Message-ID: <4BE7EC0B.8000902@tsoft.com> { i32, i32, opaque } When I try running through JIT the code, incrementing the field in such structure, I am getting an assert: Assertion failed: (Ty->isSized() && "`!"), function getAlignment, file /tmp/llvm-build/2.7/llvm/lib/Target/TargetData.cpp, line 498. I understand that C/C++ can't possibly produce such structure due to their language limitations. But llvm is supposed to be more generic. There should be no problem manipulating such structure, since opaque is only in the end. llvm-2.7 Yuri From hao.shen at imag.fr Mon May 10 10:18:16 2010 From: hao.shen at imag.fr (SHEN Hao) Date: Mon, 10 May 2010 17:18:16 +0200 Subject: [LLVMdev] How can I remove Intrinsic Functions during llvm-gcc compilation? In-Reply-To: <4BE78BF0.3010307@free.fr> References: <4BE78BF0.3010307@free.fr> Message-ID: Thanks a lot for your answer. As what you said, I can not have any options to avoid generating this kind of intrinsic for byte code. Is it possible to modify gcc and ask it take all memset liked functions as a general function call? I know this solution is less performance efficient, but I would like to have it for my llvm assembly level modification works. But anyway, thanks for you help. Hao On Mon, May 10, 2010 at 6:30 AM, Duncan Sands wrote: > Hi Hao Shen, > >> I am using llvm-gcc --emit-llvm to generate byte code. With llvm >> readable ll format, I found some standard C library function such as >> llvm.memset. > > this is not a C library function, it is an LLVM intrinsic. ?An intrinsic is > analogous to a builtin in gcc. ?An intrinsic may be expanded out into a code > sequence by the compiler, or may get turned into a library call (which sounds > like is what you are seeing). > >> In fact, I'm trying to compile newlibc with llvm, I do not need this >> kind of llvm functions. How can I remove them during the compilation? > > You can't avoid them. ?The same problem exists with gcc: you can't always > avoid having gcc use the gcc memset builtin. ?However it has to be said > that gcc generates its memset builtin less often than llvm-gcc generates > llvm.memset, so this is not as visible. ?Also (I'm not sure about this) > it may be that on some platforms gcc always expands builtin_memset into a > code sequence rather than generating a call to the library memset function. > However, gcc is not obliged to use a code sequence even in a freestanding > environment. ?The environment is always required to provide memset. ?Here's > what the gcc docs say: > > ? GCC requires the freestanding environment provide `memcpy', `memmove', > ?`memset' and `memcmp'. > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Hao Shen From xinfinity_a at yahoo.com Mon May 10 10:43:36 2010 From: xinfinity_a at yahoo.com (Xinfinity) Date: Mon, 10 May 2010 08:43:36 -0700 (PDT) Subject: [LLVMdev] Separate loop condition and loop body Message-ID: <28512281.post@talk.nabble.com> Hi, Is it possible to get the list of BasicBlocks building the condition of a loop and the list of BasicBlocks that form the body? My first approach was to iterate over the list of all Basicblocks of a loop and separate the header as the condition and the remaining as the body of the loop. However, this is not correct for instance in the case of a while loop in the form: while( A & B) do { body } My aim is to manipulate for loops, while and do-while loops unitary, but I did not find an easy way to do this. I tried also to apply passes like "Canonicalize natural loops", "Canonicalize Induction Variables" or "Natural Loop Construction" such that the loops were represented in the same form. Still I do not find a one-to-one link between the loop condition, body and end, and the BasicBlocks returned by the getHeader, getLoopLatch etc. My next strategy would be to modify the front-end, clang, and attach metadata to indicate whether the BasicBlock is part of the condition or of the body of the loop. I would very much appreciate if you could suggest an easier way to differentiate between the parts of the loop. Thank you, Alexandra -- View this message in context: http://old.nabble.com/Separate-loop-condition-and-loop-body-tp28512281p28512281.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From stoklund at 2pi.dk Mon May 10 11:56:31 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Mon, 10 May 2010 09:56:31 -0700 Subject: [LLVMdev] Machine Verifier question. In-Reply-To: References: Message-ID: <450FF384-F134-4E77-9BA0-9E1EB8F7B2E0@2pi.dk> On May 9, 2010, at 5:27 AM, Lang Hames wrote: > Running the following command, > > llc -asm-verbose=false -O3 Output/ReedSolomon.llvm.bc -o Output/ReedSolomon.llc.s -verify-machineinstrs > > in llvm-test/SingleSource/Benchmarks/Misc currently yields seven errors, all of the form > > *** Bad machine code: PHI operand is not live-out from predecessor *** > - function: main > - basic block: bb2.i.preheader 0x1ba7680 (BB#5) > - instruction: %reg1032 = PHI %reg1280, , %reg1287, > - operand 1: %reg1280 > > The code seems to run ok though. > > Is this something that's worth looking in to, or just over zealous reporting by the machine verifier? That sounds like a proper bug. Can you tell why %reg1280 is not live-out from BB#3? /jakob From stoklund at 2pi.dk Mon May 10 12:13:10 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Mon, 10 May 2010 10:13:10 -0700 Subject: [LLVMdev] Missuse of xmm register on X86-64 In-Reply-To: <201005071441.37926.aran@100acres.us> References: <201005071441.37926.aran@100acres.us> Message-ID: <50F8FB73-9BB1-4E2D-AF2D-CB89CBD926E4@2pi.dk> On May 7, 2010, at 2:41 PM, Aran Clauson wrote: > All, > I've been working on a new scheduler and have > somehow affected register selection. My problem is that an > xmm register is being used as an index expression. > Specifically, > > addss (%xmm1,%rax,4), %xmm0 > > I like the idea of a floating-point index, but, like the > assembler, I don't know what that means. Any suggestions > on where I should look for a solution to my problem? What does llc -verify-machineinstrs say? From criswell at uiuc.edu Mon May 10 12:19:21 2010 From: criswell at uiuc.edu (John Criswell) Date: Mon, 10 May 2010 12:19:21 -0500 Subject: [LLVMdev] How can I remove Intrinsic Functions during llvm-gcc compilation? In-Reply-To: References: <4BE78BF0.3010307@free.fr> Message-ID: <4BE84019.5020301@uiuc.edu> SHEN Hao wrote: > Thanks a lot for your answer. > As what you said, I can not have any options to avoid generating this kind > of intrinsic for byte code. Is it possible to modify gcc and ask it take > all memset liked functions as a general function call? I know this solution > is less performance efficient, but I would like to have it for my llvm > assembly level modification works. > It's possible to write an LLVM pass that converts calls to llvm.memset() into calls to an external memset() function. You could then modify your version of llvm-gcc to run this pass. However, is there really a problem with letting llvm-gcc use the intrinsic, even if you're compiling a C library? If the code generator replaces llvm.memset() with inline assembly code that does the same thing, then you get the correct behavior. If it modifies the llvm.memset() call to call an external memset() function, then the program ends up using the implementation of memset() from the C library that you're compiling. Either way, I'd think you'd get correct behavior. -- John T. > But anyway, thanks for you help. > Hao > > On Mon, May 10, 2010 at 6:30 AM, Duncan Sands wrote: > >> Hi Hao Shen, >> >> >>> I am using llvm-gcc --emit-llvm to generate byte code. With llvm >>> readable ll format, I found some standard C library function such as >>> llvm.memset. >>> >> this is not a C library function, it is an LLVM intrinsic. An intrinsic is >> analogous to a builtin in gcc. An intrinsic may be expanded out into a code >> sequence by the compiler, or may get turned into a library call (which sounds >> like is what you are seeing). >> >> >>> In fact, I'm trying to compile newlibc with llvm, I do not need this >>> kind of llvm functions. How can I remove them during the compilation? >>> >> You can't avoid them. The same problem exists with gcc: you can't always >> avoid having gcc use the gcc memset builtin. However it has to be said >> that gcc generates its memset builtin less often than llvm-gcc generates >> llvm.memset, so this is not as visible. Also (I'm not sure about this) >> it may be that on some platforms gcc always expands builtin_memset into a >> code sequence rather than generating a call to the library memset function. >> However, gcc is not obliged to use a code sequence even in a freestanding >> environment. The environment is always required to provide memset. Here's >> what the gcc docs say: >> >> GCC requires the freestanding environment provide `memcpy', `memmove', >> `memset' and `memcmp'. >> >> 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 criswell at uiuc.edu Mon May 10 12:29:11 2010 From: criswell at uiuc.edu (John Criswell) Date: Mon, 10 May 2010 12:29:11 -0500 Subject: [LLVMdev] [Fwd: Error while running my pass with opt] In-Reply-To: <4BE6B37C.3010203@cse.iitb.ac.in> References: <32584_1273325028_4BE565E4_32584_5318_1_4BE55F2B.5020500@cse.iitb.ac.in> <4BE5690C.3080307@fim.uni-passau.de> <4BE5A76D.7050703@cse.iitb.ac.in> <4BE6A0E5.1050301@illinois.edu> <4BE6B37C.3010203@cse.iitb.ac.in> Message-ID: <4BE84267.4090108@uiuc.edu> ambika wrote: > Here is getAnalysisUsage() i am using, > > void getAnalysisUsage(AnalysisUsage &AU) const { > AU.setPreservesAll(); > AU.addRequired(); > } > > and then I use it as, > > > bool ptrTest::runOnModule(Module &M) { > > DominatorTree &DT = getAnalysis(); > ...... > > } > Weird. There is nothing unusual about your getAnalysisUsage() method at all. I assume ptrTest is either a ModulePass or FunctionPass, correct? A few other questions: 1) Is ptrTest part of an analysis group? 2) Does ptrTest has a static ID member whose address is passed into its constructor as a default parameter? The code should look something like this: public : static char ID; ptrTest () : FunctionPass ((intptr_t) &ID) { } -- John T. > John Criswell wrote: > >> ambika wrote: >> >>> But this is already present in my pass. >>> And I am not able to understand the cause for the error: >>> >>> >> Can you send a copy of your getAnalysisUsage() method for your pass? >> There are some funny errors that can occur when you do things that the >> PassManager cannot handle. >> >> For example, if you're requiring a transform pass, that can cause >> strange assertions from the PassManager. Requiring a BasicBlock pass >> from a FunctionPass might also hit assertions within PassManager (I >> think). >> >> If you post your getAnalysisUsage() method, I can take a quick look to >> see if you're doing something that I know is unsupported by PassManager. >> >> -- John T. >> >> >>> opt: >>> /home/ambika/llvm_3/llvm-2.6/include/llvm/PassAnalysisSupport.h:203: >>> AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const >>> [with AnalysisType = llvm::DominatorTree]: Assertion `ResultPass && >>> "getAnalysis*() called on an analysis that was not " "'required' by >>> pass!"' failed. >>> >>> What can possibly cause this. Any ideas will also help. >>> >>> Tobias Grosser wrote: >>> >>> >>>> Hi, >>>> >>>> you need something like this in your pass: >>>> >>>> void YourPass::getAnalysisUsage(AnalysisUsage &AU) const { >>>> AU.addRequired(); >>>> } >>>> >>>> because you need to specify which analysis you are using. >>>> >>>> Tobi >>>> >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> > > From anton at korobeynikov.info Mon May 10 12:47:40 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 10 May 2010 21:47:40 +0400 Subject: [LLVMdev] Question about maturity of various ARM instruction sets in llvm 2.6 In-Reply-To: References: Message-ID: Hello > Are all of the ARM instruction sets that can be specified with -mattr stable? What do you mean as "stable"? Do you mean compiler support for them? PS: I'd really suggest using LLVM 2.7 for any ARM stuff, not 2.6 -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From Trevor.W.Harmon at nasa.gov Mon May 10 12:55:23 2010 From: Trevor.W.Harmon at nasa.gov (Trevor Harmon) Date: Mon, 10 May 2010 10:55:23 -0700 Subject: [LLVMdev] Cannot Compile through an LLVM Pass In-Reply-To: References: Message-ID: <25BC43DA-5E5C-4798-8D09-51CEC7FB7C78@nasa.gov> On May 7, 2010, at 7:23 PM, Jiandong Wang wrote: > hey guys. Now I am following the "Writing an LLVM Pass", but can't > work it out. See what I have done. Can you post your complete project as an attachment? Trevor From Trevor.W.Harmon at nasa.gov Mon May 10 13:05:07 2010 From: Trevor.W.Harmon at nasa.gov (Trevor Harmon) Date: Mon, 10 May 2010 11:05:07 -0700 Subject: [LLVMdev] Separate loop condition and loop body In-Reply-To: <28512281.post@talk.nabble.com> References: <28512281.post@talk.nabble.com> Message-ID: <02240EFC-8FD1-4EF1-82A0-9E8EEF784590@nasa.gov> On May 10, 2010, at 8:43 AM, Xinfinity wrote: > Is it possible to get the list of BasicBlocks building the condition > of a > loop and the list of BasicBlocks that form the body? Based on my (limited) experience with Loop and LoopInfo, this isn't possible. (But don't take my word for it.) > My aim is to manipulate for loops, while and do-while loops unitary, > but I > did not find an easy way to do this. I think the problem here is that LLVM's CFG is low-level enough such that the distinction between the loop header expression and the loop body is lost. Why exactly do you need to identify the blocks that form the loop header expression? I'm wondering if you could find some workaround that doesn't require this... Trevor From bboissin+llvm at gmail.com Mon May 10 13:35:08 2010 From: bboissin+llvm at gmail.com (Benoit Boissinot) Date: Mon, 10 May 2010 20:35:08 +0200 Subject: [LLVMdev] Separate loop condition and loop body In-Reply-To: <02240EFC-8FD1-4EF1-82A0-9E8EEF784590@nasa.gov> References: <28512281.post@talk.nabble.com> <02240EFC-8FD1-4EF1-82A0-9E8EEF784590@nasa.gov> Message-ID: On Mon, May 10, 2010 at 8:05 PM, Trevor Harmon wrote: > On May 10, 2010, at 8:43 AM, Xinfinity wrote: > >> Is it possible to get the list of BasicBlocks building the condition >> of a loop and the list of BasicBlocks that form the body? > > Based on my (limited) experience with Loop and LoopInfo, this isn't > possible. (But don't take my word for it.) > >> My aim is to manipulate for loops, while and do-while loops unitary, >> but I did not find an easy way to do this. > > I think the problem here is that LLVM's CFG is low-level enough such > that the distinction between the loop header expression and the loop > body is lost. > > Why exactly do you need to identify the blocks that form the loop > header expression? I'm wondering if you could find some workaround > that doesn't require this... > To me it looks like any basic block from the loop body with a successor not in the loop body is a BB "building the condition" (an "exit" block). If you already have the loop body, it should be pretty easy to find out about those nodes. cheers, Benoit From gohman at apple.com Mon May 10 13:40:07 2010 From: gohman at apple.com (Dan Gohman) Date: Mon, 10 May 2010 11:40:07 -0700 Subject: [LLVMdev] does llvm have some way to get the size of data type In-Reply-To: References: Message-ID: On May 8, 2010, at 2:20 AM, Erick Tryzelaar wrote: > Hello! You can do this: > > http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt Also, the ConstantExpr class has getSizeOf, getOffsetOf, and getAlignOf utility functions which make this easy. Dan From gohman at apple.com Mon May 10 13:42:14 2010 From: gohman at apple.com (Dan Gohman) Date: Mon, 10 May 2010 11:42:14 -0700 Subject: [LLVMdev] Should the function operand flag 'sret' match the flag in function declaration? In-Reply-To: References: <4BE4BD68.9050104@tsoft.com> Message-ID: <45AA0CED-A4F4-459C-9331-D70C00DB7E1D@apple.com> On May 8, 2010, at 10:31 AM, Chris Lattner wrote: > > On May 7, 2010, at 6:24 PM, Yuri wrote: > >> I have these two instructions, first one inside some procedure, second >> one is an outside declaration. >> Code verification passes and it runs, but incorrectly. > > Right, this code has undefined behavior. > >> Every time I saw such situation coming from c++ compiler, attributes >> 'noalias sret' appear on both call and declaration. >> >> Does such situation make sense, or (as I guess it is) a bug in verifier? >> I think verifier should match at least 'sret' flag in call and declaration. >> >> ... >> call void @_Z7returnsi(%struct.MyString* %z, i32 %1) nounwind >> ... >> declare void @_Z7returnsi(%struct.MyString* noalias sret, i32) >> ... > > The verifier flags and rejects *invalid* IR, not IR with undefined behavior. Dan has been working on a pass (in lib/Analysis/Lint.cpp) that should catch this sort of thing. If it doesn't already, please send in a patch to make it catch it. Thanks! The lint pass currently just does this: // TODO: Check sret attribute. So yes, please send a patch :-). Thanks, Dan From gohman at apple.com Mon May 10 13:45:48 2010 From: gohman at apple.com (Dan Gohman) Date: Mon, 10 May 2010 11:45:48 -0700 Subject: [LLVMdev] getTripCount requires which optimization passes? In-Reply-To: <3AE154C9-9EE0-42A2-BD9E-27BA3DD54874@nasa.gov> References: <0D1A6E16-0987-489A-8E34-A5A2F62CEDC5@nasa.gov> <3AE154C9-9EE0-42A2-BD9E-27BA3DD54874@nasa.gov> Message-ID: On May 7, 2010, at 11:17 AM, Trevor Harmon wrote: > On May 6, 2010, at 6:32 PM, ether zhhb wrote: > >> As the comment said: >> /// The IndVarSimplify pass transforms loops to have a form that >> this >> /// function easily understands. >> >> you could try -indvars. > > After adding -indvars to the opt command, getTripCount still returns > null. Code coming from C front-ends typically also needs -loop-rotate, in addition to all the usual stuff (mem2reg, instcombine, simplifycfg, etc). It depends a fair amount on the front-end; take a look at what opt -O2 does and experiment with it. > > I suppose it's possible, depending on the scheduling of the pass > manager, that indvars is running after my pass runs. I could force it > to run first by adding it to my pass's getAnalysisUsage: > > void MyPass::getAnalysisUsage(AnalysisUsage &AU) const { > AU.addRequired(); > } > > But this isn't possible because for some reason there's no > IndVarSimplify.h header file. The IndVarSimplify pass is defined only > in its IndVarSimplify.cpp, so my pass can't use it. The design idea here is that you should write your pass to be conservatively correct in the case that indvars and whatever else hasn't run, and then just make your front-ends add -indvars before adding your pass. Dan From trevor.w.harmon at nasa.gov Mon May 10 14:32:06 2010 From: trevor.w.harmon at nasa.gov (Trevor Harmon) Date: Mon, 10 May 2010 12:32:06 -0700 Subject: [LLVMdev] Separate loop condition and loop body In-Reply-To: References: <28512281.post@talk.nabble.com> <02240EFC-8FD1-4EF1-82A0-9E8EEF784590@nasa.gov> Message-ID: On May 10, 2010, at 11:35 AM, Benoit Boissinot wrote: > To me it looks like any basic block from the loop body with a > successor not in the loop body is a BB "building the condition" (an > "exit" block). I assume you mean "any basic block from the loop header". I don't think your rule will work. Consider this counterexample: while (j < 10 && j > 5 && j % 2 == 0) { j++; } This will give you the attached CFG. bb1 is the loop header; bb2 and bb3 are the other loop conditionals; bb is the loop body. Note that bb3 is part of the condition but is not a basic block from the loop header. Trevor -------------- next part -------------- A non-text attachment was scrubbed... Name: cfg._Z6simplei.dot Type: application/octet-stream Size: 2002 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100510/2b9c3c70/attachment.obj -------------- next part -------------- From bboissin+llvm at gmail.com Mon May 10 14:48:41 2010 From: bboissin+llvm at gmail.com (Benoit Boissinot) Date: Mon, 10 May 2010 21:48:41 +0200 Subject: [LLVMdev] Separate loop condition and loop body In-Reply-To: References: <28512281.post@talk.nabble.com> <02240EFC-8FD1-4EF1-82A0-9E8EEF784590@nasa.gov> Message-ID: <20100510194841.GF18804@pirzuine> On Mon, May 10, 2010 at 12:32:06PM -0700, Trevor Harmon wrote: > On May 10, 2010, at 11:35 AM, Benoit Boissinot wrote: > > >To me it looks like any basic block from the loop body with a > >successor not in the loop body is a BB "building the condition" (an > >"exit" block). > > I assume you mean "any basic block from the loop header". No really, loop body. > > I don't think your rule will work. Consider this counterexample: > > while (j < 10 && j > 5 && j % 2 == 0) { > j++; > } > > This will give you the attached CFG. bb1 is the loop header; bb2 and > bb3 are the other loop conditionals; bb is the loop body. > > Note that bb3 is part of the condition but is not a basic block from > the loop header. At least in the CFG/graph theory I know, the loop body is the set of nodes which form the strongly connected component (it contains the headers). In this case that would be {bb1, bb2, bb3, bb}, with bb1 as header. (the header is un-ambiguous in this case since the CFG is natural/reducible there is only one possible header for the loop). >From this set, bb1, bb2 and bb3 have exit edges, those are the conditional blocks. cheers, Benoit -- :wq From trevor.w.harmon at nasa.gov Mon May 10 15:44:53 2010 From: trevor.w.harmon at nasa.gov (Trevor Harmon) Date: Mon, 10 May 2010 13:44:53 -0700 Subject: [LLVMdev] Separate loop condition and loop body In-Reply-To: <20100510194841.GF18804@pirzuine> References: <28512281.post@talk.nabble.com> <02240EFC-8FD1-4EF1-82A0-9E8EEF784590@nasa.gov> <20100510194841.GF18804@pirzuine> Message-ID: On May 10, 2010, at 11:05 AM, Trevor Harmon wrote: >>> To me it looks like any basic block from the loop body with a >>> successor not in the loop body is a BB "building the condition" (an >>> "exit" block). >> >> I assume you mean "any basic block from the loop header". > > No really, loop body. In that case, what does it mean for a block to be "from" the loop body? Perhaps you meant "of" or "in" the loop body, but then I'm still confused. Consider break statements (CFG attached): while (j < 10 && j > 5 && j % 2 == 0) { j++; if (j == 9) break; } In this example, block bb is in the loop body, has a successor not in the loop body, but is not building the condition. This appears to be a violation of your rule. Trevor -------------- next part -------------- A non-text attachment was scrubbed... Name: cfg._Z6simplei.dot Type: application/octet-stream Size: 2180 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100510/6b17f2c6/attachment.obj -------------- next part -------------- From trevor.w.harmon at nasa.gov Mon May 10 16:20:24 2010 From: trevor.w.harmon at nasa.gov (Trevor Harmon) Date: Mon, 10 May 2010 14:20:24 -0700 Subject: [LLVMdev] getTripCount requires which optimization passes? In-Reply-To: References: <0D1A6E16-0987-489A-8E34-A5A2F62CEDC5@nasa.gov> <3AE154C9-9EE0-42A2-BD9E-27BA3DD54874@nasa.gov> Message-ID: <1F0847FB-08E3-41F7-9380-0487251419A9@nasa.gov> On May 10, 2010, at 11:45 AM, Dan Gohman wrote: > just make your front-ends add -indvars before > adding your pass. Sorry, I don't have a clue how to do this, and I can't find any docs about it. I'm using llvm-gcc; how can I tell it to add a pass? Trevor From tjablin at cs.princeton.edu Mon May 10 19:28:09 2010 From: tjablin at cs.princeton.edu (Thomas B. Jablin) Date: Mon, 10 May 2010 20:28:09 -0400 (EDT) Subject: [LLVMdev] All CallInsts mayHaveSideEffects In-Reply-To: <1633494069.719791273537603488.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <213533278.719811273537689366.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Hi, All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write to memory will be dead code eliminated when the Inliner runs. Here is a simple example of how things can go horribly wrong: #include #include void inf(void) { while(1); } int main(int argc, char **argv) { inf(); return 0; } void foo(void) { printf("Hello world!\n"); exit(0); } For recent versions of clang (svn rev 102637) when compiled with -O1 or higher the result is: Hello world! The reason is that LLVM annotates inf as noreturn, so the ret instruction at the end of main is replaced with unreachable. Then the inf function is dead-code eliminated by the Inliner pass. Thus main will consist of a single unreachable instruction, which allows control to fall through to the foo function. My suggested patch is as follows: Index: include/llvm/Instruction.h =================================================================== --- include/llvm/Instruction.h (revision 102637) +++ include/llvm/Instruction.h (working copy) @@ -245,7 +245,9 @@ /// instructions which don't used the returned value. For cases where this /// matters, isSafeToSpeculativelyExecute may be more appropriate. bool mayHaveSideEffects() const { - return mayWriteToMemory() || mayThrow(); + const unsigned opcode = getOpcode(); + return mayWriteToMemory() || mayThrow() || + opcode == Call || opcode == Invoke; } /// isSafeToSpeculativelyExecute - Return true if the instruction does not Sincerely yours, Tom From rnk at mit.edu Mon May 10 20:38:47 2010 From: rnk at mit.edu (Reid Kleckner) Date: Mon, 10 May 2010 21:38:47 -0400 Subject: [LLVMdev] All CallInsts mayHaveSideEffects In-Reply-To: <213533278.719811273537689366.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> References: <1633494069.719791273537603488.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> <213533278.719811273537689366.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: This is a known bug: http://llvm.org/bugs/show_bug.cgi?id=965 There has been some discussion about it and similar problems, and the desire is to perform some analysis on functions to determine if they are known to halt trivially, ie they have no loops and call no other functions that are not known to halt. LLVM still wants to be able to delete calls to trivial read-only functions. Reid On Mon, May 10, 2010 at 8:28 PM, Thomas B. Jablin wrote: > Hi, > > All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. > > Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write to memory will be dead code eliminated when the Inliner runs. > > Here is a simple example of how things can go horribly wrong: > > #include > #include > > void inf(void) { > ?while(1); > } > > int main(int argc, char **argv) { > ?inf(); > ?return 0; > } > > void foo(void) { > ?printf("Hello world!\n"); > ?exit(0); > } > > For recent versions of clang (svn rev 102637) when compiled with -O1 or higher the result is: > Hello world! > > The reason is that LLVM annotates inf as noreturn, so the ret instruction at the end of main is replaced with unreachable. Then the inf function is dead-code eliminated by the Inliner pass. Thus main will consist of a single unreachable instruction, which allows control to fall through to the foo function. > > My suggested patch is as follows: > > Index: include/llvm/Instruction.h > =================================================================== > --- include/llvm/Instruction.h ?(revision 102637) > +++ include/llvm/Instruction.h ?(working copy) > @@ -245,7 +245,9 @@ > ? /// instructions which don't used the returned value. ?For cases where this > ? /// matters, isSafeToSpeculativelyExecute may be more appropriate. > ? bool mayHaveSideEffects() const { > - ? ?return mayWriteToMemory() || mayThrow(); > + ? ?const unsigned opcode = getOpcode(); > + ? ?return mayWriteToMemory() || mayThrow() || > + ? ? ?opcode == Call || opcode == Invoke; > ? } > > ? /// isSafeToSpeculativelyExecute - Return true if the instruction does not > > Sincerely yours, > Tom > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From blunted2night at gmail.com Mon May 10 20:46:12 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Mon, 10 May 2010 18:46:12 -0700 Subject: [LLVMdev] AsmPrinter::EmitLinkage Message-ID: I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF). Would it make sense to delegate the implementation to a specialized object from current the object file format? I am tempted to make it the MCAsmInfo implementation for the specific target. Currently MCAsmInfo looks just to hold useful information about the target, and not any target specific code. TargetLoweringObjectFile looks to perform a similar function as MCAsmInfo, though this doesn't look to be responsible for directing the AsmPrinter, its only responsibility appears to be providing section assignment logic. Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer. Another approach would be to further subdivide X86AsmPrinter to have object file format specific variants that could implement the required logic. The problems I am trying to solve are processor independent so I don't think this would be the right approach, but it could potentially be useful in other situations. Finally, a new object could be created that is specialized by the different object file formats. There are already a number of specialized objects, and seems like at would make things confusing. I think there are other places that could benefit from a similar transformation. On example would be the handling of the X86AsmPrinter::EmitEndOfAsmFile which has three separate blocks of code dedicated to the different object file formats. At least in the case of COFF, the operations being performed are not specific to X86. -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100510/8b21b663/attachment.html From tjablin at cs.princeton.edu Mon May 10 21:01:09 2010 From: tjablin at cs.princeton.edu (Thomas B. Jablin) Date: Mon, 10 May 2010 22:01:09 -0400 (EDT) Subject: [LLVMdev] All CallInsts mayHaveSideEffects In-Reply-To: <246994677.720591273543217016.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <1759598367.720631273543269306.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Does any real code benefit from dead code eliminating read-only functions? Tom ----- Original Message ----- From: "Reid Kleckner" To: "Thomas B. Jablin" Cc: "LLVM Developers Mailing List" Sent: Monday, May 10, 2010 9:38:47 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] All CallInsts mayHaveSideEffects This is a known bug: http://llvm.org/bugs/show_bug.cgi?id=965 There has been some discussion about it and similar problems, and the desire is to perform some analysis on functions to determine if they are known to halt trivially, ie they have no loops and call no other functions that are not known to halt. LLVM still wants to be able to delete calls to trivial read-only functions. Reid On Mon, May 10, 2010 at 8:28 PM, Thomas B. Jablin wrote: > Hi, > > All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. > > Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write to memory will be dead code eliminated when the Inliner runs. > > Here is a simple example of how things can go horribly wrong: > > #include > #include > > void inf(void) { > ?while(1); > } > > int main(int argc, char **argv) { > ?inf(); > ?return 0; > } > > void foo(void) { > ?printf("Hello world!\n"); > ?exit(0); > } > > For recent versions of clang (svn rev 102637) when compiled with -O1 or higher the result is: > Hello world! > > The reason is that LLVM annotates inf as noreturn, so the ret instruction at the end of main is replaced with unreachable. Then the inf function is dead-code eliminated by the Inliner pass. Thus main will consist of a single unreachable instruction, which allows control to fall through to the foo function. > > My suggested patch is as follows: > > Index: include/llvm/Instruction.h > =================================================================== > --- include/llvm/Instruction.h ?(revision 102637) > +++ include/llvm/Instruction.h ?(working copy) > @@ -245,7 +245,9 @@ > ? /// instructions which don't used the returned value. ?For cases where this > ? /// matters, isSafeToSpeculativelyExecute may be more appropriate. > ? bool mayHaveSideEffects() const { > - ? ?return mayWriteToMemory() || mayThrow(); > + ? ?const unsigned opcode = getOpcode(); > + ? ?return mayWriteToMemory() || mayThrow() || > + ? ? ?opcode == Call || opcode == Invoke; > ? } > > ? /// isSafeToSpeculativelyExecute - Return true if the instruction does not > > Sincerely yours, > Tom > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From samuraileumas at yahoo.com Mon May 10 21:36:25 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Mon, 10 May 2010 19:36:25 -0700 (PDT) Subject: [LLVMdev] All CallInsts mayHaveSideEffects In-Reply-To: <1759598367.720631273543269306.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> References: <1759598367.720631273543269306.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <316917.22152.qm@web62003.mail.re1.yahoo.com> I'd imagine every get method in any C++ program would benefit from that sort of dead-code elimination. Although simply inlining it might might be all that's really needed. ----- Original Message ---- > From: Thomas B. Jablin > To: LLVM Developers Mailing List > Sent: Mon, May 10, 2010 9:01:09 PM > Subject: Re: [LLVMdev] All CallInsts mayHaveSideEffects > > Does any real code benefit from dead code eliminating read-only > functions? Tom ----- Original Message ----- From: "Reid Kleckner" > < > href="mailto:rnk at mit.edu">rnk at mit.edu> To: "Thomas B. Jablin" < > ymailto="mailto:tjablin at CS.Princeton.EDU" > href="mailto:tjablin at CS.Princeton.EDU">tjablin at CS.Princeton.EDU> Cc: > "LLVM Developers Mailing List" < > href="mailto:llvmdev at cs.uiuc.edu">llvmdev at cs.uiuc.edu> Sent: Monday, > May 10, 2010 9:38:47 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] > All CallInsts mayHaveSideEffects This is a known > bug: http://llvm.org/bugs/show_bug.cgi?id=965 There has been some > discussion about it and similar problems, and the desire is to perform some > analysis on functions to determine if they are known to halt trivially, ie > they have no loops and call no other functions that are not known to > halt. LLVM still wants to be able to delete calls to trivial read-only > functions. Reid On Mon, May 10, 2010 at 8:28 PM, Thomas B. > Jablin < > href="mailto:tjablin at cs.princeton.edu">tjablin at cs.princeton.edu> > wrote: > Hi, > > All CallInsts should return true for > Instruction::mayHaveSideEffects() because functions are not guaranteed to > halt. > > Inliner::runOnSCC calls isInstructionTriviallyDead to > determine whether code can be dead code eliminated. isInstructionTriviallyDead > returns true if Instruction::mayHaveSideEffects() returns false. A function that > potentially runs forever based on its input but does not write to memory will be > dead code eliminated when the Inliner runs. > > Here is a simple > example of how things can go horribly wrong: > > #include > > #include > > void inf(void) > { > while(1); > } > > int main(int argc, char **argv) > { > inf(); > return 0; > } > > void foo(void) > { > printf("Hello world!\n"); > exit(0); > } > > > For recent versions of clang (svn rev 102637) when compiled with -O1 or higher > the result is: > Hello world! > > The reason is that LLVM > annotates inf as noreturn, so the ret instruction at the end of main is replaced > with unreachable. Then the inf function is dead-code eliminated by the Inliner > pass. Thus main will consist of a single unreachable instruction, which allows > control to fall through to the foo function. > > My suggested patch > is as follows: > > Index: include/llvm/Instruction.h > > =================================================================== > --- > include/llvm/Instruction.h (revision 102637) > +++ > include/llvm/Instruction.h (working copy) > @@ -245,7 +245,9 @@ > > /// instructions which don't used the returned value. For cases where > this > /// matters, isSafeToSpeculativelyExecute may be more > appropriate. > bool mayHaveSideEffects() const { > - return > mayWriteToMemory() || mayThrow(); > + const unsigned opcode = > getOpcode(); > + return mayWriteToMemory() || mayThrow() || > + > opcode == Call || opcode == Invoke; > } > > /// > isSafeToSpeculativelyExecute - Return true if the instruction does > not > > Sincerely yours, > Tom > > _______________________________________________ > LLVM Developers mailing > list > > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu > http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ LLVM > Developers mailing list > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu > > >http://llvm.cs.uiuc.edu > href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target=_blank > >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From nicholas at mxc.ca Mon May 10 22:29:53 2010 From: nicholas at mxc.ca (Nick Lewycky) Date: Mon, 10 May 2010 20:29:53 -0700 Subject: [LLVMdev] [Fwd: Error while running my pass with opt] In-Reply-To: <4BE84267.4090108@uiuc.edu> References: <32584_1273325028_4BE565E4_32584_5318_1_4BE55F2B.5020500@cse.iitb.ac.in> <4BE5690C.3080307@fim.uni-passau.de> <4BE5A76D.7050703@cse.iitb.ac.in> <4BE6A0E5.1050301@illinois.edu> <4BE6B37C.3010203@cse.iitb.ac.in> <4BE84267.4090108@uiuc.edu> Message-ID: <4BE8CF31.5020807@mxc.ca> John Criswell wrote: > ambika wrote: >> Here is getAnalysisUsage() i am using, >> >> void getAnalysisUsage(AnalysisUsage&AU) const { >> AU.setPreservesAll(); >> AU.addRequired(); >> } >> >> and then I use it as, >> >> >> bool ptrTest::runOnModule(Module&M) { >> >> DominatorTree&DT = getAnalysis(); DominatorTree is per-function. In a ModulePass you need to pass a Function in order for it to know which function you want the DominatorTree for. Nick >> ...... >> >> } >> > > Weird. There is nothing unusual about your getAnalysisUsage() method at > all. > > I assume ptrTest is either a ModulePass or FunctionPass, correct? > > A few other questions: > > 1) Is ptrTest part of an analysis group? > > 2) Does ptrTest has a static ID member whose address is passed into its > constructor as a default parameter? The code should look something like > this: > > public : > static char ID; > ptrTest () : FunctionPass ((intptr_t)&ID) { } > > > -- John T. > >> John Criswell wrote: >> >>> ambika wrote: >>> >>>> But this is already present in my pass. >>>> And I am not able to understand the cause for the error: >>>> >>>> >>> Can you send a copy of your getAnalysisUsage() method for your pass? >>> There are some funny errors that can occur when you do things that the >>> PassManager cannot handle. >>> >>> For example, if you're requiring a transform pass, that can cause >>> strange assertions from the PassManager. Requiring a BasicBlock pass >>> from a FunctionPass might also hit assertions within PassManager (I >>> think). >>> >>> If you post your getAnalysisUsage() method, I can take a quick look to >>> see if you're doing something that I know is unsupported by PassManager. >>> >>> -- John T. >>> >>> >>>> opt: >>>> /home/ambika/llvm_3/llvm-2.6/include/llvm/PassAnalysisSupport.h:203: >>>> AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const >>>> [with AnalysisType = llvm::DominatorTree]: Assertion `ResultPass&& >>>> "getAnalysis*() called on an analysis that was not " "'required' by >>>> pass!"' failed. >>>> >>>> What can possibly cause this. Any ideas will also help. >>>> >>>> Tobias Grosser wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> you need something like this in your pass: >>>>> >>>>> void YourPass::getAnalysisUsage(AnalysisUsage&AU) const { >>>>> AU.addRequired(); >>>>> } >>>>> >>>>> because you need to specify which analysis you are using. >>>>> >>>>> Tobi >>>>> >>>>> >>>> _______________________________________________ >>>> 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 geek4civic at gmail.com Mon May 10 23:07:44 2010 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Tue, 11 May 2010 13:07:44 +0900 Subject: [LLVMdev] How does SSEDomainFix work? Message-ID: Hello. This is my 1st post. I have tried SSE execution domain fixup pass. But I am not able to see any improvements. I expect for the example below to use MOVDQA, PAND &c. (On nehalem, ANDPS is extremely slower than PAND) Please tell me if something would be wrong for me. Thank you. Takumi Host: i386-mingw32 Build: trunk at 103373 foo.ll: define <4 x i32> @foo(<4 x i32> %x, <4 x i32> %y, <4 x i32> %z) nounwind readnone { entry: %0 = and <4 x i32> %x, %z %not = xor <4 x i32> %z, %1 = and <4 x i32> %not, %y %2 = xor <4 x i32> %0, %1 ret <4 x i32> %2 } define <2 x i64> @bar(<2 x i64> %x, <2 x i64> %y, <2 x i64> %z) nounwind readnone { entry: %0 = and <2 x i64> %x, %z %not = xor <2 x i64> %z, %1 = and <2 x i64> %not, %y %2 = xor <2 x i64> %0, %1 ret <2 x i64> %2 } $ llc -mcpu=nehalem -debug-pass=Structure foo.bc -o foo.s (snip) Code Placement Optimizater SSE execution domain fixup Machine Natural Loop Construction X86 AT&T-Style Assembly Printer Delete Garbage Collector Information foo.s: (edited) _foo: movaps %xmm0, %xmm3 andps %xmm2, %xmm3 andnps %xmm1, %xmm2 movaps %xmm2, %xmm0 xorps %xmm3, %xmm0 ret _bar: movaps %xmm0, %xmm3 andps %xmm2, %xmm3 andnps %xmm1, %xmm2 movaps %xmm2, %xmm0 xorps %xmm3, %xmm0 ret From clattner at apple.com Mon May 10 23:43:58 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 10 May 2010 21:43:58 -0700 Subject: [LLVMdev] AsmPrinter::EmitLinkage In-Reply-To: References: Message-ID: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> On May 10, 2010, at 6:46 PM, Nathan Jeffords wrote: > I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF). > Would it make sense to delegate the implementation to a specialized object from current the object file format? Why? It is AsmPrinter's job to handle the lowering of MachineInstrs and LLVM IR (for globals etc) to the MC level primitives. AsmPrinter should really be renamed MCLowering at some point. > I am tempted to make it the MCAsmInfo implementation for the specific target. Currently MCAsmInfo looks just to hold useful information about the target, and not any target specific code. Right. MCAsmInfo has been designed to be filled in by targets but not subclassed. This implies that it can't have virtual methods. > TargetLoweringObjectFile looks to perform a similar function as MCAsmInfo, though this doesn't look to be responsible for directing the AsmPrinter, its only responsibility appears to be providing section assignment logic. TLOF is designed to be specific to the object file, but ideally not target specific. This means we should have TLOFMacho but not TLOFX86Macho. > Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer. Right, that is the actual implementation of the object writer for a specific target. > Another approach would be to further subdivide X86AsmPrinter to have object file format specific variants that could implement the required logic. The problems I am trying to solve are processor independent so I don't think this would be the right approach, but it could potentially be useful in other situations. > > Finally, a new object could be created that is specialized by the different object file formats. There are already a number of specialized objects, and seems like at would make things confusing. > > I think there are other places that could benefit from a similar transformation. On example would be the handling of the X86AsmPrinter::EmitEndOfAsmFile which has three separate blocks of code dedicated to the different object file formats. At least in the case of COFF, the operations being performed are not specific to X86. What problem are you trying to solve here? I'm pretty sure that AsmPrinter is emitting valid COFF output already, no? > -Chris From subbu.pur at gmail.com Mon May 10 23:51:36 2010 From: subbu.pur at gmail.com (subramanyam) Date: Mon, 10 May 2010 21:51:36 -0700 (PDT) Subject: [LLVMdev] How to create Global Variables using LLVM API? Message-ID: <28519938.post@talk.nabble.com> I am new to LLVM API. and I am experimenting with it. I want to create Global Variables in a module. I am able to create local variables using IRBuilder class. I tried using GlobalVariable class to create global variables. but it doesn't work. my code looks like this: Module* mod = new Module("test", getGlobalContext()); Constant* c = mod->getOrInsertFunction("main", IntegerType::get(getGlobalContext(), 32), NULL); Function* main = cast (c); main->setCallingConv(CallingConv::C); Twine s("foo"); StringRef s1("foo"); Constant *cons = ConstantArray::get(getGlobalContext(),s1, true); GlobalVariable val(*mod, (Type*) ArrayType::get(Type::getInt8Ty(getGlobalContext()), 4), true,GlobalValue::ExternalLinkage, cons, s); Application stops running after reaching the last line. can somebody help me out here? -- View this message in context: http://old.nabble.com/How-to-create-Global-Variables-using-LLVM-API--tp28519938p28519938.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From nicholas at mxc.ca Tue May 11 00:11:00 2010 From: nicholas at mxc.ca (Nick Lewycky) Date: Mon, 10 May 2010 22:11:00 -0700 Subject: [LLVMdev] How to create Global Variables using LLVM API? In-Reply-To: <28519938.post@talk.nabble.com> References: <28519938.post@talk.nabble.com> Message-ID: <4BE8E6E4.5070604@mxc.ca> subramanyam wrote: > > I am new to LLVM API. and I am experimenting with it. > I want to create Global Variables in a module. > I am able to create local variables using IRBuilder class. I tried using > GlobalVariable class to create global variables. > but it doesn't work. my code looks like this: > > Module* mod = new Module("test", getGlobalContext()); > Constant* c = mod->getOrInsertFunction("main", > IntegerType::get(getGlobalContext(), 32), NULL); > Function* main = cast (c); > main->setCallingConv(CallingConv::C); > Twine s("foo"); > StringRef s1("foo"); > Constant *cons = ConstantArray::get(getGlobalContext(),s1, true); > GlobalVariable val(*mod, (Type*) > ArrayType::get(Type::getInt8Ty(getGlobalContext()), 4), > true,GlobalValue::ExternalLinkage, cons, s); Firstly, don't cast to Type*. You need to #include "llvm/DerivedTypes.h" instead. But that's not your bug. Don't allocate GlobalVariable val on the stack. You need to 'new' it, ala. 'GlobalVariable *val = new GlobalVariable(...);' I haven't tried running your code, but give that a shot! Nick > > > Application stops running after reaching the last line. can somebody help me > out here? > > From blunted2night at gmail.com Tue May 11 02:17:32 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Tue, 11 May 2010 00:17:32 -0700 Subject: [LLVMdev] AsmPrinter::EmitLinkage In-Reply-To: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> References: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> Message-ID: On Mon, May 10, 2010 at 9:43 PM, Chris Lattner wrote: > > On May 10, 2010, at 6:46 PM, Nathan Jeffords wrote: > > > I have been looking over AsmPrinter::EmitLinkage (around line 195 of > lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation > will vary quite a bit depending on what object file format is in use (MachO, > ELF, or COFF). > > Would it make sense to delegate the implementation to a specialized > object from current the object file format? > > Why? It is AsmPrinter's job to handle the lowering of MachineInstrs and > LLVM IR (for globals etc) to the MC level primitives. AsmPrinter should > really be renamed MCLowering at some point. > > > I am tempted to make it the MCAsmInfo implementation for the specific > target. Currently MCAsmInfo looks just to hold useful information about the > target, and not any target specific code. > > Right. MCAsmInfo has been designed to be filled in by targets but not > subclassed. This implies that it can't have virtual methods. > > > TargetLoweringObjectFile looks to perform a similar function as > MCAsmInfo, though this doesn't look to be responsible for directing the > AsmPrinter, its only responsibility appears to be providing section > assignment logic. > > TLOF is designed to be specific to the object file, but ideally not target > specific. This means we should have TLOFMacho but not TLOFX86Macho. > > In the context I am looking at, it would be specific to the object file. I was just pointing out that as it stands, it appears to only be responsible for section assignment, and not any logic that would affect the AsmPrinter's decision on what to emit. I don't know what the exact intent of this object is other that the functionality it already implements, but it seems it would make a good candidate to work with AsmPrinter (MCLower) to produce ouput for a specific object file. > > Another candidate I considered what TargetAsmBackend, but that appears to > be meant to sit behind MCStreamer. > > Right, that is the actual implementation of the object writer for a > specific target. > > > Another approach would be to further subdivide X86AsmPrinter to have > object file format specific variants that could implement the required > logic. The problems I am trying to solve are processor independent so I > don't think this would be the right approach, but it could potentially be > useful in other situations. > > > > Finally, a new object could be created that is specialized by the > different object file formats. There are already a number of specialized > objects, and seems like at would make things confusing. > > > > I think there are other places that could benefit from a similar > transformation. On example would be the handling of the > X86AsmPrinter::EmitEndOfAsmFile which has three separate blocks of code > dedicated to the different object file formats. At least in the case of > COFF, the operations being performed are not specific to X86. > > > What problem are you trying to solve here? I'm pretty sure that AsmPrinter > is emitting valid COFF output already, no? > > I think it emits valid output, but I don't think it handles weak symbols correctly, as COFF supports true weak symbols, but this code appears to turn them into a linkonce section which is not quite the same thing. In my opinion, the body of this function should be different for each object file type (at least for COFF). It could be handled in place as a large if-then-else block, but when I see that type of code, which is the same in the X86AsmPrinter::EmitEndOfAsmFile it seems to me that they should be encapsulated somehow. Perhaps, AsmPrinter itself could be specialized for the object file format in use? > > > > -Chris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/208f57bf/attachment.html From anton at korobeynikov.info Tue May 11 04:03:40 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 11 May 2010 13:03:40 +0400 Subject: [LLVMdev] AsmPrinter::EmitLinkage In-Reply-To: References: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> Message-ID: > I think it emits valid output, but I don't think it handles weak symbols > correctly, as COFF supports true weak symbols, but this code appears to turn > them into a linkonce section which is not quite the same thing. Yes. This was intentional, since: 1. At the time of writing the code binutils did not support weak stuff 2. It was my feeling, that weak (especially external weak stuff) on COFF differs in some details from e.g. weak on MachO/ELF. I might be wrong, however... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From xinfinity_a at yahoo.com Tue May 11 05:08:32 2010 From: xinfinity_a at yahoo.com (Xinfinity) Date: Tue, 11 May 2010 03:08:32 -0700 (PDT) Subject: [LLVMdev] Separate loop condition and loop body Message-ID: <28521641.post@talk.nabble.com> >>> To me it looks like any basic block from the loop body with a >>> successor not in the loop body is a BB "building the condition" (an >>> "exit" block). >> Consider break statements (CFG attached): while (j < 10 && j > 5 && j % 2 == 0) { j++; if (j == 9) break; } In this example, block bb is in the loop body, has a successor not in the loop body, but is not building the condition. This appears to be a violation of your rule. Trevor Hi, I agree that not all exiting blocks are part of the condition. Maybe your suggestion of trying a workaround would be easier. What I want is to modify the structure of the loop by adding an extra condition before its execution: |------ extra.cond <-------| | | | | | | | v | | |-loop.cond | | | | | | | v | | | CALL(body) ___| | | | |---> loop.end | |____>exit This condition has to be checked in the beginning of each iteration, that means, the loop body should branch to this extra condition instead of the loop condition. So I want to eliminate the branch from loop.body to loop.cond and to insert a branch from loop.body to extra.cond . Also, I need to delimit the BBs building the body of the loop, in order to extract them in a new function. I hope my explanations are not too vague. Thanks for your help. Alexandra -- View this message in context: http://old.nabble.com/Separate-loop-condition-and-loop-body-tp28512281p28521641.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From georg.troxler at staila.com Tue May 11 02:19:52 2010 From: georg.troxler at staila.com (Georg Troxler) Date: Tue, 11 May 2010 09:19:52 +0200 Subject: [LLVMdev] LLVMGetPointerToFunction Message-ID: Hi, Is there such a function (or a similar one) which is callable using the c-binding llvm? Many thanks, Georg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/d49c75d2/attachment.html From prasu.kothinti at gmail.com Tue May 11 05:56:34 2010 From: prasu.kothinti at gmail.com (prasad dp) Date: Tue, 11 May 2010 16:26:34 +0530 Subject: [LLVMdev] Need help for my PBQP regAlloc proj in llvm.... Message-ID: Hello, we are currently working on my project that aims at improving the register allocation scheme by identifying if the interference graphs are chordal or not. we are working on the llvm compiler .we are forcing the compiler to use PBQP register allocation scheme by an option of ' ' regalloc=pbqp ' during the execution of prgm. we have been succesfull in accessing the interference graph information and creating our version of interference matrix depicting the same information. we then use the same matrix to inspect for its chordal nature. and we are looking for colouring the chordal graph in a linear time using available algorithms. I am looking for material that is related to the above mentioned work that would help me to prepare my report. Particularly i am looking for the information about Linear scan algorithm and PBQP scheme. PLZ do help me out. Thanks, Durga Prasad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/ab81226e/attachment.html From xinfinity_a at yahoo.com Tue May 11 04:01:12 2010 From: xinfinity_a at yahoo.com (Xinfinity) Date: Tue, 11 May 2010 02:01:12 -0700 (PDT) Subject: [LLVMdev] Separate loop condition and loop body In-Reply-To: References: <28512281.post@talk.nabble.com> <02240EFC-8FD1-4EF1-82A0-9E8EEF784590@nasa.gov> <20100510194841.GF18804@pirzuine> Message-ID: <28521641.post@talk.nabble.com> >>> To me it looks like any basic block from the loop body with a >>> successor not in the loop body is a BB "building the condition" (an >>> "exit" block). >> Consider break statements (CFG attached): while (j < 10 && j > 5 && j % 2 == 0) { j++; if (j == 9) break; } In this example, block bb is in the loop body, has a successor not in the loop body, but is not building the condition. This appears to be a violation of your rule. Trevor Hi, I agree that not all exiting blocks are part of the condition. Maybe your suggestion of trying a workaround would be easier. What I want is to modify the structure of the loop by adding an extra condition before its execution: |------ extra.cond <-------| | | | | | | | v | | |-loop.cond | | | | | | | v | | | CALL(body) ___| | | | |---> loop.end | |____>exit This condition has to be checked in the beginning of each iteration, that means, the loop body should branch to this extra condition instead of the loop condition. So I want to eliminate the branch from loop.body to loop.cond and to insert a branch from loop.body to extra.cond . Also, I need to delimit the BBs building the body of the loop, in order to extract them in a new function. I hope my explanations are not too vague. Thanks for your help. Alexandra -- View this message in context: http://old.nabble.com/Separate-loop-condition-and-loop-body-tp28512281p28521641.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From bboissin+llvm at gmail.com Tue May 11 08:08:11 2010 From: bboissin+llvm at gmail.com (Benoit Boissinot) Date: Tue, 11 May 2010 15:08:11 +0200 Subject: [LLVMdev] Separate loop condition and loop body In-Reply-To: <28521641.post@talk.nabble.com> References: <28512281.post@talk.nabble.com> <02240EFC-8FD1-4EF1-82A0-9E8EEF784590@nasa.gov> <20100510194841.GF18804@pirzuine> <28521641.post@talk.nabble.com> Message-ID: <20100511130811.GA2128@pirzuine> On Tue, May 11, 2010 at 02:01:12AM -0700, Xinfinity wrote: > >>> To me it looks like any basic block from the loop body with a > >>> successor not in the loop body is a BB "building the condition" (an > >>> "exit" block). > >> > Consider break statements (CFG attached): > > while (j < 10 && j > 5 && j % 2 == 0) { > j++; > if (j == 9) > break; > } > > In this example, block bb is in the loop body, has a successor not in > the loop body, but is not building the condition. This appears to be a > violation of your rule. In this case, the if statement could be considered part of the condition (the exit of the loop depends on it, you can even rewrite the while statement to include the condition). It really depends what you want to achieve. > > Hi, > > I agree that not all exiting blocks are part of the condition. > Maybe your suggestion of trying a workaround would be easier. What I want is > to modify the structure of the loop by adding an extra condition before its > execution: > > |------ extra.cond <-------| > | | | > | | | > | v | > | |-loop.cond | > | | | | > | | v | > | | CALL(body) ___| > | | > | |---> loop.end > | > |____>exit > > This condition has to be checked in the beginning of each iteration, that > means, the loop body should branch to this extra condition instead of the > loop condition. So I want to eliminate the branch from loop.body to > loop.cond and to insert a branch from loop.body to extra.cond . Also, I > need to delimit the BBs building the body of the loop, in order to extract > them in a new function. Can't you achieve the same thing by just adding new headers with your extra condition. transforming the following CFG: | v bb1<---+ / | | / v | | bb2 | | / \ | | | bb3-+ \ / v loop.exit into extra<--+ / | | / v | / bb1 | | / | | | / v | | | bb2 | | | / \ | | | | bb3-+ | \ / | v | loop.exit | exit Defining which nodes are part of the loop body is more difficult since, at least for C language, computation and the condition can be mixed. Cheers, Benoit -- :wq From khaledhamidouche at gmail.com Tue May 11 08:29:38 2010 From: khaledhamidouche at gmail.com (khaled hamidouche) Date: Tue, 11 May 2010 15:29:38 +0200 Subject: [LLVMdev] determine the basic_block inside if and else Message-ID: Hello I used a functionPass to count the number of bloks ? so for each BBlock I check if it is a loop or BB ... and I'm wandring How can I determine if a BB is a conditional block (if) ?? and How can I separate between the BBs inside the if and those inside the else ?? Thank you so much K.H -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/e62588be/attachment.html From stoklund at 2pi.dk Tue May 11 10:08:53 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Tue, 11 May 2010 08:08:53 -0700 Subject: [LLVMdev] How does SSEDomainFix work? In-Reply-To: References: Message-ID: On May 10, 2010, at 9:07 PM, NAKAMURA Takumi wrote: > Hello. This is my 1st post. ????? > I have tried SSE execution domain fixup pass. > But I am not able to see any improvements. Did you actually measure runtime, or did you look at assembly? > I expect for the example below to use MOVDQA, PAND &c. > (On nehalem, ANDPS is extremely slower than PAND) Are you sure? The andps and pand instructions are actually the same speed, but on Nehalem there is a latency penalty for moving data between the int and float domains. The SSE execution domain pass tries to minimize the extra latency by switching instructions. In your examples, all the operations are available as either int or float instructions. The instruction selector chooses the float instructions because they are smaller. The SSE execution domain pass does not change them because there are zero domain crossings, zero extra latency. Everything takes place in the float domain which is just as fast. If you use operations that are only available in one domain, the SSE execution domain pass kicks in: define <4 x i32> @intfoo(<4 x i32> %x, <4 x i32> %y, <4 x i32> %z) nounwind readnone { entry: %0 = add <4 x i32> %x, %z %not = xor <4 x i32> %z, %1 = and <4 x i32> %not, %y %2 = xor <4 x i32> %0, %1 ret <4 x i32> %2 } _intfoo: movdqa %xmm0, %xmm3 paddd %xmm2, %xmm3 pandn %xmm1, %xmm2 movdqa %xmm2, %xmm0 pxor %xmm3, %xmm0 ret All the instructions moved to the int domain because the add forced them. > Please tell me if something would be wrong for me. You should measure if LLVM's code is actually slower that the code you want. If it is, I would like to hear. Our weakness is the shufflevector instruction. It is selected into shufps/pshufd/palign/... only by looking at patterns. The instruction selector does not consider execution domains. This can be a problem because these instructions cannot be freely interchanged by the SSE execution domain pass. > foo.ll: > define <4 x i32> @foo(<4 x i32> %x, <4 x i32> %y, <4 x i32> %z) > nounwind readnone { > entry: > %0 = and <4 x i32> %x, %z > %not = xor <4 x i32> %z, > %1 = and <4 x i32> %not, %y > %2 = xor <4 x i32> %0, %1 > ret <4 x i32> %2 > } > $ llc -mcpu=nehalem -debug-pass=Structure foo.bc -o foo.s > (snip) > Code Placement Optimizater > SSE execution domain fixup > Machine Natural Loop Construction > X86 AT&T-Style Assembly Printer > Delete Garbage Collector Information > > foo.s: (edited) > _foo: > movaps %xmm0, %xmm3 > andps %xmm2, %xmm3 > andnps %xmm1, %xmm2 > movaps %xmm2, %xmm0 > xorps %xmm3, %xmm0 > ret From blunted2night at gmail.com Tue May 11 11:25:49 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Tue, 11 May 2010 09:25:49 -0700 Subject: [LLVMdev] AsmPrinter::EmitLinkage In-Reply-To: References: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> Message-ID: On Tue, May 11, 2010 at 2:03 AM, Anton Korobeynikov wrote: > > I think it emits valid output, but I don't think it handles weak symbols > > correctly, as COFF supports true weak symbols, but this code appears to > turn > > them into a linkonce section which is not quite the same thing. > Yes. This was intentional, since: > 1. At the time of writing the code binutils did not support weak stuff > 2. It was my feeling, that weak (especially external weak stuff) on > COFF differs in some details from e.g. weak on MachO/ELF. I might be > wrong, however... > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University > It is my understanding that weak symbols are symbols that can be overridden (i.e. library provides a default implementation, and the application may override it). Whereas linkonce (or COMDAT) is for symbol that might show up in multiple object file but are effectively the same so its not particularly important which one is selected. According to Microsoft's COFF documentation, weak linkage is supported. From what I can gather from the documentation, only one symbol may be defined as weak, and the overriding symbol if present would be define normally. Perhaps this is the difference in detail you speak of. -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/f50cbd14/attachment.html From anton at korobeynikov.info Tue May 11 11:47:52 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 11 May 2010 20:47:52 +0400 Subject: [LLVMdev] AsmPrinter::EmitLinkage In-Reply-To: References: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> Message-ID: Hello, Nathan > It is my understanding that weak symbols are symbols that can be overridden > (i.e. library provides a default implementation, and the application may > override it). Right > documentation,?weak?linkage is supported. From what I can gather from the > documentation, only one symbol may be defined as weak, and the overriding > symbol if present would be define normally. Perhaps this is the difference > in detail you speak of. What if there will be two weak symbols? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From anton at korobeynikov.info Tue May 11 12:04:15 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 11 May 2010 21:04:15 +0400 Subject: [LLVMdev] AsmPrinter::EmitLinkage In-Reply-To: References: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> Message-ID: > For the windows sub-target is it safe to assume Microsoft's linker is the being targeted? I'd really appreciate if both ms link and gnu ld will be tested, if this is possible. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From geek4civic at gmail.com Tue May 11 12:05:49 2010 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Wed, 12 May 2010 02:05:49 +0900 Subject: [LLVMdev] How does SSEDomainFix work? In-Reply-To: References: Message-ID: Dear Jakob-san, > ????? :D Thank you for reply. At first, I have to apologize you. I misunderstood aim of SSEdomainfix. Now I see what the pass does. But anyway, the point that I would like to mention is "throughput" rather than (inter-domain) latency. In fact, FP operations are 3x slower than SI ops on Nehalem by my measurement. It would be needed to prefer SI ops on Nehalem(and generic sse2), I think. (Shorter instructions may be taken with -Os) The attachment includes a simple(but stupid bogus) asm-C source and a Win32 executable. $ mingw32-gcc -msse2 -O4 -Wall -funroll-all-loops foo.c It must be compiled on other x86 hosts. But it would be needed to constrain processor's affinity to single ; ) Counts below are Cycles by million iteration on Core i7 982270 xorps 982231 movaps 371671 pxor 342628 movdqa SI ops can be issued by 3-way but FP ops by only single way. (as we know, they are nearly same on Conroe, Penryn) Excuse me, loads by movdqa and movaps are not measured. : ( See also; - Intel optimization manual http://www.intel.com/assets/pdf/manual/248966.pdf - Agner's works http://agner.org/optimize/ Thank you, Takumi 2010/5/12 Jakob Stoklund Olesen : > > On May 10, 2010, at 9:07 PM, NAKAMURA Takumi wrote: > >> Hello. This is my 1st post. > > ????? > >> I have tried SSE execution domain fixup pass. >> But I am not able to see any improvements. > > Did you actually measure runtime, or did you look at assembly? > >> I expect for the example below to use MOVDQA, PAND &c. >> (On nehalem, ANDPS is extremely slower than PAND) > > Are you sure? The andps and pand instructions are actually the same speed, but on Nehalem there is a latency penalty for moving data between the int and float domains. > > The SSE execution domain pass tries to minimize the extra latency by switching instructions. > > In your examples, all the operations are available as either int or float instructions. The instruction selector chooses the float instructions because they are smaller. The SSE execution domain pass does not change them because there are zero domain crossings, zero extra latency. Everything takes place in the float domain which is just as fast. > > If you use operations that are only available in one domain, the SSE execution domain pass kicks in: > > define <4 x i32> @intfoo(<4 x i32> %x, <4 x i32> %y, <4 x i32> %z) > nounwind readnone { > entry: > %0 = add <4 x i32> %x, %z > %not = xor <4 x i32> %z, > %1 = and <4 x i32> %not, %y > %2 = xor <4 x i32> %0, %1 > ret <4 x i32> %2 > } > > _intfoo: > movdqa %xmm0, %xmm3 > paddd %xmm2, %xmm3 > pandn %xmm1, %xmm2 > movdqa %xmm2, %xmm0 > pxor %xmm3, %xmm0 > ret > > All the instructions moved to the int domain because the add forced them. > >> Please tell me if something would be wrong for me. > > You should measure if LLVM's code is actually slower that the code you want. If it is, I would like to hear. > > Our weakness is the shufflevector instruction. It is selected into shufps/pshufd/palign/... only by looking at patterns. The instruction selector does not consider execution domains. This can be a problem because these instructions cannot be freely interchanged by the SSE execution domain pass. > > >> foo.ll: >> define <4 x i32> @foo(<4 x i32> %x, <4 x i32> %y, <4 x i32> %z) >> nounwind readnone { >> entry: >> %0 = and <4 x i32> %x, %z >> %not = xor <4 x i32> %z, >> %1 = and <4 x i32> %not, %y >> %2 = xor <4 x i32> %0, %1 >> ret <4 x i32> %2 >> } >> $ llc -mcpu=nehalem -debug-pass=Structure foo.bc -o foo.s >> (snip) >> Code Placement Optimizater >> SSE execution domain fixup >> Machine Natural Loop Construction >> X86 AT&T-Style Assembly Printer >> Delete Garbage Collector Information >> >> foo.s: (edited) >> _foo: >> movaps %xmm0, %xmm3 >> andps %xmm2, %xmm3 >> andnps %xmm1, %xmm2 >> movaps %xmm2, %xmm0 >> xorps %xmm3, %xmm0 >> ret > > -------------- next part -------------- A non-text attachment was scrubbed... Name: xmm.zip Type: application/zip Size: 2911 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/d9715376/attachment.zip From astifter-llvm at gmx.at Tue May 11 12:06:16 2010 From: astifter-llvm at gmx.at (Andreas Neustifter) Date: Tue, 11 May 2010 19:06:16 +0200 Subject: [LLVMdev] Master Thesis about Profiling in LLVM Message-ID: Hi all! I recently finished my master studies with the thesis' title being "Efficient Profiling in the LLVM Compiler Infrastructure". For anyone interested it can be downloaded at http://astifter.com/storage/diplomarbeit.pdf. I wanted to thank all of you who helped me with suggestions, reviews and comments about LLVM and related topics. As discussed in http://article.gmane.org/gmane.comp.compilers.llvm.devel/28845/match= I'm not sure how to proceed with the changes I have still not checked in, can anyone comment on this? Thanks, Andi From ambika at cse.iitb.ac.in Tue May 11 12:07:30 2010 From: ambika at cse.iitb.ac.in (ambika) Date: Tue, 11 May 2010 22:37:30 +0530 Subject: [LLVMdev] [Fwd: Error while running my pass with opt] In-Reply-To: <4BE8CF31.5020807@mxc.ca> References: <32584_1273325028_4BE565E4_32584_5318_1_4BE55F2B.5020500@cse.iitb.ac.in> <4BE5690C.3080307@fim.uni-passau.de> <4BE5A76D.7050703@cse.iitb.ac.in> <4BE6A0E5.1050301@illinois.edu> <4BE6B37C.3010203@cse.iitb.ac.in> <4BE84267.4090108@uiuc.edu> <4BE8CF31.5020807@mxc.ca> Message-ID: <4BE98ED2.5080403@cse.iitb.ac.in> Yaah Dominator tree is generated per function. It worked out when I used it as AU.addRequired(F); Thanks to all for helping me. Nick Lewycky wrote: > John Criswell wrote: >> ambika wrote: >>> Here is getAnalysisUsage() i am using, >>> >>> void getAnalysisUsage(AnalysisUsage&AU) const { >>> AU.setPreservesAll(); >>> AU.addRequired(); >>> } >>> >>> and then I use it as, >>> >>> >>> bool ptrTest::runOnModule(Module&M) { >>> >>> DominatorTree&DT = getAnalysis(); > > DominatorTree is per-function. In a ModulePass you need to pass a > Function in order for it to know which function you want the > DominatorTree for. > > Nick > >>> ...... >>> >>> } >>> >> >> Weird. There is nothing unusual about your getAnalysisUsage() method at >> all. >> >> I assume ptrTest is either a ModulePass or FunctionPass, correct? >> >> A few other questions: >> >> 1) Is ptrTest part of an analysis group? >> >> 2) Does ptrTest has a static ID member whose address is passed into its >> constructor as a default parameter? The code should look something like >> this: >> >> public : >> static char ID; >> ptrTest () : FunctionPass ((intptr_t)&ID) { } >> >> >> -- John T. >> >>> John Criswell wrote: >>> >>>> ambika wrote: >>>> >>>>> But this is already present in my pass. >>>>> And I am not able to understand the cause for the error: >>>>> >>>>> >>>> Can you send a copy of your getAnalysisUsage() method for your pass? >>>> There are some funny errors that can occur when you do things that the >>>> PassManager cannot handle. >>>> >>>> For example, if you're requiring a transform pass, that can cause >>>> strange assertions from the PassManager. Requiring a BasicBlock pass >>>> from a FunctionPass might also hit assertions within PassManager (I >>>> think). >>>> >>>> If you post your getAnalysisUsage() method, I can take a quick look to >>>> see if you're doing something that I know is unsupported by >>>> PassManager. >>>> >>>> -- John T. >>>> >>>> >>>>> opt: >>>>> /home/ambika/llvm_3/llvm-2.6/include/llvm/PassAnalysisSupport.h:203: >>>>> AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const >>>>> [with AnalysisType = llvm::DominatorTree]: Assertion `ResultPass&& >>>>> "getAnalysis*() called on an analysis that was not " "'required' by >>>>> pass!"' failed. >>>>> >>>>> What can possibly cause this. Any ideas will also help. >>>>> >>>>> Tobias Grosser wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> you need something like this in your pass: >>>>>> >>>>>> void YourPass::getAnalysisUsage(AnalysisUsage&AU) const { >>>>>> AU.addRequired(); >>>>>> } >>>>>> >>>>>> because you need to specify which analysis you are using. >>>>>> >>>>>> Tobi >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 aaronngray.lists at googlemail.com Tue May 11 12:49:46 2010 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Tue, 11 May 2010 18:49:46 +0100 Subject: [LLVMdev] AsmPrinter::EmitLinkage In-Reply-To: References: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> Message-ID: On 11 May 2010 18:04, Anton Korobeynikov wrote: > > For the windows sub-target is it safe to assume Microsoft's linker is the > being targeted? > I'd really appreciate if both ms link and gnu ld will be tested, if > this is possible. I have done some tests with Cygwin, and most things seem okay, e.g. Static Constructors...Virtual Destructors. I did try building llvm-gcc on Cygwin with some hacks, but llvm-gcc requires some inline assembly, I may try and hack that through as assembly code. This involved linking and xgcc ran okay, so things are looking good :) Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/912dd092/attachment.html From blunted2night at gmail.com Tue May 11 13:07:12 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Tue, 11 May 2010 11:07:12 -0700 Subject: [LLVMdev] AsmPrinter::EmitLinkage In-Reply-To: References: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> Message-ID: On Tue, May 11, 2010 at 10:49 AM, Aaron Gray < aaronngray.lists at googlemail.com> wrote: > On 11 May 2010 18:04, Anton Korobeynikov wrote: > >> > For the windows sub-target is it safe to assume Microsoft's linker is >> the being targeted? >> I'd really appreciate if both ms link and gnu ld will be tested, if >> this is possible. > > > I have done some tests with Cygwin, and most things seem okay, e.g. Static > Constructors...Virtual Destructors. > > I did try building llvm-gcc on Cygwin with some hacks, but llvm-gcc > requires some inline assembly, I may try and hack that through as assembly > code. > > This involved linking and xgcc ran okay, so things are looking good :) > > Aaron > > For dllexport support, there are differences between GNU's and Microsoft's linkers. I thought the the subtarget was their to differentiate what tool-set was being targeted. I used that assumption on my patch to update the support for dllexport. -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/c53812ba/attachment.html From rob at monochromeindustries.com Tue May 11 15:39:40 2010 From: rob at monochromeindustries.com (Rob Rix) Date: Tue, 11 May 2010 16:39:40 -0400 Subject: [LLVMdev] LLVMGetPointerToFunction In-Reply-To: References: Message-ID: <3CC28C34-18E6-4CBA-A801-FA763F3FD52B@monochromeindustries.com> I?m not aware of whether one exists in 2.7 (it didn?t in 2.6 IIRC), but it?s pretty easy to write one up for yourself if necessary. I did something like this using 2.6: void *LLVMGetPointerToFunction(LLVMExecutionEngineRef compiler, LLVMValueRef function) { llvm::ExecutionEngine *cppCompiler = llvm::unwrap(compiler); llvm::Function *cppFunction = llvm::unwrap(function); return cppCompiler->getPointerToFunction(cppFunction); } Rob On 2010-05-11, at 3:19 AM, Georg Troxler wrote: > Hi, > > Is there such a function (or a similar one) which is callable using the c-binding llvm? > > Many thanks, > > Georg > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Rob Rix, Unknown Quantity Monochrome Industries -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/8897be01/attachment.html From clattner at apple.com Tue May 11 15:43:21 2010 From: clattner at apple.com (Chris Lattner) Date: Tue, 11 May 2010 13:43:21 -0700 Subject: [LLVMdev] New libc++ LLVM Subproject Message-ID: Hi All, LLVM now includes a C++ standard library, written by Howard Hinnant. You can read about it here: http://blog.llvm.org/2010/05/new-libc-c-standard-library.html Or get the code here: svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx If you have questions or comments, please direct them to one of the clang mailing lists. Thanks! -Chris From joe at alacatialabs.com Tue May 11 15:46:42 2010 From: joe at alacatialabs.com (Joe Ranieri) Date: Tue, 11 May 2010 16:46:42 -0400 Subject: [LLVMdev] New libc++ LLVM Subproject In-Reply-To: References: Message-ID: <4BE9C232.9090006@alacatialabs.com> On 5/11/10 4:43 PM, Chris Lattner wrote: > Hi All, > > LLVM now includes a C++ standard library, written by Howard Hinnant. You can read about it here: > http://blog.llvm.org/2010/05/new-libc-c-standard-library.html > > Or get the code here: > svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx > > If you have questions or comments, please direct them to one of the clang mailing lists. Thanks! > > -Chris Awesome news! The links to 'Browse SVN' and 'Browse ViewVC' seem to be pointing to compiler-rt instead of libcxx though... -- Joe Ranieri From hhinnant at apple.com Tue May 11 15:53:49 2010 From: hhinnant at apple.com (Howard Hinnant) Date: Tue, 11 May 2010 16:53:49 -0400 Subject: [LLVMdev] New libc++ LLVM Subproject In-Reply-To: <4BE9C232.9090006@alacatialabs.com> References: <4BE9C232.9090006@alacatialabs.com> Message-ID: On May 11, 2010, at 4:46 PM, Joe Ranieri wrote: > On 5/11/10 4:43 PM, Chris Lattner wrote: >> Hi All, >> >> LLVM now includes a C++ standard library, written by Howard Hinnant. You can read about it here: >> http://blog.llvm.org/2010/05/new-libc-c-standard-library.html >> >> Or get the code here: >> svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx >> >> If you have questions or comments, please direct them to one of the clang mailing lists. Thanks! >> >> -Chris > > Awesome news! The links to 'Browse SVN' and 'Browse ViewVC' seem to be > pointing to compiler-rt instead of libcxx though... Thanks Joe. Try now. -Howard From Michael.Smith at synopsys.com Tue May 11 17:48:06 2010 From: Michael.Smith at synopsys.com (Michael Smith) Date: Tue, 11 May 2010 15:48:06 -0700 Subject: [LLVMdev] Machine Code, JIT, and Windows Message-ID: I'm writing an application that generates LLVM byte code and executes it at runtime. The options I'm looking at are to use the LLVM ExecutionEngine for JIT execution, or to write an assembly file, link it as a DLL using gcc/mingw, and load the DLL. It has to work on Linux and Windows. I've been testing it on Windows, and found that the JIT execution, and executing functions from a DLL are equally fast. Can anyone explain why? When I test JIT, I don't have MinGW's GCC in the path, so I wouldn't expect it to be compiling to native code. Regards, Michael Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/9e335016/attachment.html From dberlin at dberlin.org Tue May 11 18:13:50 2010 From: dberlin at dberlin.org (Daniel Berlin) Date: Tue, 11 May 2010 19:13:50 -0400 Subject: [LLVMdev] Machine Code, JIT, and Windows In-Reply-To: References: Message-ID: On Tue, May 11, 2010 at 6:48 PM, Michael Smith wrote: > I?m writing an application that generates LLVM byte code and executes it at > runtime. The options I?m looking at are to use the LLVM ExecutionEngine for > JIT execution, or to write an assembly file, link it as a DLL using > gcc/mingw, and load the DLL. It has to work on Linux and Windows. > > > > I?ve been testing it on Windows, and found that the JIT execution, and > executing functions from a DLL are equally fast. Can anyone explain why? > When I test JIT, I don?t have MinGW?s GCC in the path, so I wouldn?t expect > it to be compiling to native code. Why? LLVM does not require an external application to compile to native code. The JIT is in fact compiling to native code. > > > > Regards, > > Michael Smith > > _______________________________________________ > 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 May 11 18:26:19 2010 From: dag at cray.com (David Greene) Date: Tue, 11 May 2010 18:26:19 -0500 Subject: [LLVMdev] New libc++ LLVM Subproject In-Reply-To: References: Message-ID: <201005111826.20194.dag@cray.com> On Tuesday 11 May 2010 15:43:21 Chris Lattner wrote: > Hi All, > > LLVM now includes a C++ standard library, written by Howard Hinnant. You > can read about it here: > http://blog.llvm.org/2010/05/new-libc-c-standard-library.html > > Or get the code here: > svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx > > If you have questions or comments, please direct them to one of the clang > mailing lists. Thanks! This looks cool, but I can't help wondering about the motivation. libstdc++ has a ton of useful functionality (debug mode, profile mode, etc.). Does libc++ plan to reproduce that? What's driving libc++? -Dave From matt at console-pimps.org Tue May 11 18:48:03 2010 From: matt at console-pimps.org (Matt Fleming) Date: Wed, 12 May 2010 00:48:03 +0100 Subject: [LLVMdev] MC ELF support Message-ID: <871vdiuhjg.fsf@linux-g6p1.site> A non-text attachment was scrubbed... Name: 0001-target-asm-backend-add-reloc-info.patch Type: text/x-patch Size: 2378 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/e803a54c/attachment-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-mcelfstreamer.patch Type: text/x-patch Size: 46288 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/e803a54c/attachment-0005.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-hookup-x86-elf-writer.patch Type: text/x-patch Size: 1336 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/e803a54c/attachment-0006.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-type-asm-directive.patch Type: text/x-patch Size: 3952 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/e803a54c/attachment-0007.bin From Michael.Smith at synopsys.com Tue May 11 18:49:52 2010 From: Michael.Smith at synopsys.com (Michael Smith) Date: Tue, 11 May 2010 16:49:52 -0700 Subject: [LLVMdev] Machine Code, JIT, and Windows In-Reply-To: References: Message-ID: My understanding was that compiling directly to native code wasn't supported on Windows yet. At least Clang seems to require having GCC in the path on Windows. -----Original Message----- From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Tuesday, May 11, 2010 4:14 PM To: Michael Smith Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Machine Code, JIT, and Windows On Tue, May 11, 2010 at 6:48 PM, Michael Smith wrote: > I'm writing an application that generates LLVM byte code and executes it at > runtime. The options I'm looking at are to use the LLVM ExecutionEngine for > JIT execution, or to write an assembly file, link it as a DLL using > gcc/mingw, and load the DLL. It has to work on Linux and Windows. > > > > I've been testing it on Windows, and found that the JIT execution, and > executing functions from a DLL are equally fast. Can anyone explain why? > When I test JIT, I don't have MinGW's GCC in the path, so I wouldn't expect > it to be compiling to native code. Why? LLVM does not require an external application to compile to native code. The JIT is in fact compiling to native code. > > > > Regards, > > Michael Smith > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From hhinnant at apple.com Tue May 11 19:07:50 2010 From: hhinnant at apple.com (Howard Hinnant) Date: Tue, 11 May 2010 20:07:50 -0400 Subject: [LLVMdev] New libc++ LLVM Subproject In-Reply-To: <201005111826.20194.dag@cray.com> References: <201005111826.20194.dag@cray.com> Message-ID: <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> On May 11, 2010, at 7:26 PM, David Greene wrote: > On Tuesday 11 May 2010 15:43:21 Chris Lattner wrote: >> Hi All, >> >> LLVM now includes a C++ standard library, written by Howard Hinnant. You >> can read about it here: >> http://blog.llvm.org/2010/05/new-libc-c-standard-library.html >> >> Or get the code here: >> svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx >> >> If you have questions or comments, please direct them to one of the clang >> mailing lists. Thanks! > > This looks cool, but I can't help wondering about the motivation. libstdc++ > has a ton of useful functionality (debug mode, profile mode, etc.). Does > libc++ plan to reproduce that? debug mode yes. It isn't there yet. And I would like to limit it to being ABI compatible with release mode. This will entail significant debug functionality curtailment, but also eliminate numerous errors I've seen when debug mode and release mode get accidentally mixed. > What's driving libc++? The possibility of being a superior solution. ---------------- // Container overhead example #include #include #include int main() { typedef std::map M; typedef std::deque C; std::cout << "sizeof map = " << sizeof(M)/sizeof(void*) << '\n'; std::cout << "sizeof deque = " << sizeof(C)/sizeof(void*) << '\n'; } libc++: sizeof map = 3 sizeof deque = 6 libstdc++: sizeof map = 6 sizeof deque = 10 (smaller is better) ---------------- // Adding a few items to a sorted sequence and resorting // (a real world use case) #include #include #include #include int main() { typedef std::vector V; V v; const int N = 100000000; for (int i = 0; i < N; ++i) v.push_back(i); for (int i = N; i > 0;) { i -= N/10; int j = v[i]; v.erase(v.begin() + i); v.push_back(j); } std::random_shuffle(v.begin() + 9 * v.size() / 10, v.end()); // How long does it take to resort a vector when // only the last 90% is unsorted? std::time_t t0 = std::time(0); std::sort(v.begin(), v.end()); std::time_t t1 = std::time(0); std::cout << difftime(t1, t0) << " seconds\n"; } libc++: 5 seconds libstdc++: 22 seconds (smaller is better) ---------------- This being said, clang will continue to be std::lib neutral. If libstdc++ meets your needs better than libc++, then you should use it. libc++ will have to earn its place. -Howard From samuraileumas at yahoo.com Tue May 11 20:03:46 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Tue, 11 May 2010 18:03:46 -0700 (PDT) Subject: [LLVMdev] Machine Code, JIT, and Windows In-Reply-To: References: Message-ID: <937124.91472.qm@web62004.mail.re1.yahoo.com> Hello Michael, That's for the final linkage. Since the JIT does linking at the bitcode level, it doesn't need to access an external linker AFAIK. --Sam ----- Original Message ---- > From: Michael Smith > To: Daniel Berlin > Cc: "llvmdev at cs.uiuc.edu" > Sent: Tue, May 11, 2010 6:49:52 PM > Subject: Re: [LLVMdev] Machine Code, JIT, and Windows > > My understanding was that compiling directly to native code wasn't supported on > Windows yet. At least Clang seems to require having GCC in the path on > Windows. -----Original Message----- From: Daniel Berlin [mailto: > ymailto="mailto:dberlin at dberlin.org" > href="mailto:dberlin at dberlin.org">dberlin at dberlin.org] Sent: Tuesday, > May 11, 2010 4:14 PM To: Michael Smith Cc: > ymailto="mailto:llvmdev at cs.uiuc.edu" > href="mailto:llvmdev at cs.uiuc.edu">llvmdev at cs.uiuc.edu Subject: Re: > [LLVMdev] Machine Code, JIT, and Windows On Tue, May 11, 2010 at 6:48 PM, > Michael Smith < > href="mailto:Michael.Smith at synopsys.com">Michael.Smith at synopsys.com> > wrote: > I'm writing an application that generates LLVM byte code and > executes it at > runtime. The options I'm looking at are to use the LLVM > ExecutionEngine for > JIT execution, or to write an assembly file, link it > as a DLL using > gcc/mingw, and load the DLL. It has to work on Linux and > Windows. > > > > I've been testing it on Windows, and > found that the JIT execution, and > executing functions from a DLL are > equally fast. Can anyone explain why? > When I test JIT, I don't have > MinGW's GCC in the path, so I wouldn't expect > it to be compiling to > native code. Why? LLVM does not require an external application to > compile to native code. The JIT is in fact compiling to native > code. > > > > Regards, > > Michael > Smith > > _______________________________________________ > > LLVM Developers mailing list > > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu > http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ LLVM > Developers mailing list > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu > > >http://llvm.cs.uiuc.edu > href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target=_blank > >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From hhinnant at apple.com Tue May 11 20:32:06 2010 From: hhinnant at apple.com (Howard Hinnant) Date: Tue, 11 May 2010 21:32:06 -0400 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: References: <201005111826.20194.dag@cray.com> <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> Message-ID: <38261765-DADA-44C3-83BD-8C13CB68753B@apple.com> On May 11, 2010, at 8:40 PM, Andrew Sutton wrote: > > What's driving libc++? > > The possibility of being a superior solution. > > I thought "to support Apple applications" from the previous post was sufficient motivation :) Either way, I'm excited about a new library. Plus, it looks a little easier to read (from the tiny amount of code that I've looked at). > > libc++: > > 5 seconds > > libstdc++: > > 22 seconds > > (smaller is better) > > Is this libstdc++ with or without rvalue references? This was compiled with g++-4.-2 -O3 (without rvalue references, which would have no effect on sorting ints anyway). -Howard From leimy2k at gmail.com Tue May 11 20:32:58 2010 From: leimy2k at gmail.com (David Leimbach) Date: Tue, 11 May 2010 18:32:58 -0700 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: References: <201005111826.20194.dag@cray.com> <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> Message-ID: On Tue, May 11, 2010 at 5:40 PM, Andrew Sutton wrote: > > What's driving libc++? >> >> The possibility of being a superior solution. >> > > I thought "to support Apple applications" from the previous post was > sufficient motivation :) Either way, I'm excited about a new library. Plus, > it looks a little easier to read (from the tiny amount of code that I've > looked at). > Just two throw 2 more motivators in... Sometimes to re-implement after learning from work done before by others is a reason to try it in itself. Also a lot of LLVM is C++ isn't it? Wouldn't it be nice if it were 100% self hosting at some point? (I think so.) Not having to depend on anyone else to make your stuff work is, well, liberating. Dave > > >> libc++: >> >> 5 seconds >> >> libstdc++: >> >> 22 seconds >> >> (smaller is better) >> > > Is this libstdc++ with or without rvalue references? > How about compile times? Having used Go a bit, I've been quite fond of how short the code, compile, test loop ends up being. Dave > > Andrew Sutton > andrew.n.sutton at gmail.com > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100511/16738ee3/attachment.html From daniel at zuster.org Tue May 11 21:03:27 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Tue, 11 May 2010 19:03:27 -0700 Subject: [LLVMdev] MC ELF support In-Reply-To: <871vdiuhjg.fsf@linux-g6p1.site> References: <871vdiuhjg.fsf@linux-g6p1.site> Message-ID: Hi Matt, Awesome! This is excellent progress, and it is great to see someone working on this. High level comments: (1) The order of patches is odd, to me. It would be great to start by adding the AsmParser support, then the MCStreamer support, so that we can have test cases in the 'llvm-mc cat' mode, where it just parses and prints out again. On 0001: - What is hasRelocationAddend? It doesn't seem to be needed to me, and I'm not sure why it would be. If this is a private detail to ELF, it shouldn't go in TargetAsmBackend, but rather be an argument to the object writer constructor. - Feel free to submit a patch to split out ELFX86_{32,64}AsmBackend, if you want me to apply it. Little / obvious patches like that are great ones to get in first, and make subsequent patches easier to read. On 0002: - Looks great, overall! - WriteSymbolEntry isn't endianness neutral. I would find it easier to read if Is64Bit weren't the top level branch but was only used where it matters, but that is me. - LLVM style is to use assert(... && "Message to include in the assert"). - Please use array_pod_sort (from ADT/STLExtras.h) instead of std::sort. - WriteSecHdrEntry would be easier to read if it just used WriteWord instead of Is64Bit. - The changes to MCSectionELF shouldn't be needed. These should go in MCSectionData instead, or in private maps if possible. I can give you extra target dependent fields if need be. This enforces layering between the parts CodeGen can access and the parts that are private to the assembler backend. On 0003: - Might as well merge this with 0002. On 0004: - This looks good, might as well bring it in first. - You could use ADT/StringSwitch for this sequence, if you like: -- + if (Type.equals(StringRef("function"))) { + Attr = MCSA_ELF_TypeFunction; + } else if (Type.equals(StringRef("object"))) { + Attr = MCSA_ELF_TypeObject; -- I recommend optimizing for getting the obvious parts or stub implementations in first, so it is easy to review subsequent patches. - Daniel On Tue, May 11, 2010 at 4:48 PM, Matt Fleming wrote: > > Hi guys, > > attached are a couple of work in progress patches for ELF support in the > MC module. I'm sending this email to gather some general feedback on the > code. Applying these patches doesn't get you a fully working llvm-mc > that understands ELF; it's just the ground work. I've got a couple more > small patches that fixup some places that assume Mach-O object format > which I'll send later in the week. > > 0001-target-asm-backend-add-reloc-info.patch: > > This patch adds information to allow MC to handle ELF relocations. > > 0002-mcelfstreamer.patch: > > This is the largest patch. It fleshes out the ELF support. > > 0003-hookup-x86-elf-writer.patch: > > Code to get the ELF writer working with x86. > > 0004-type-asm-directive.patch: > > This patch allows the assembler to handle the .type directive. > > Comments? > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From rnk at mit.edu Tue May 11 21:04:02 2010 From: rnk at mit.edu (Reid Kleckner) Date: Tue, 11 May 2010 22:04:02 -0400 Subject: [LLVMdev] Machine Code, JIT, and Windows In-Reply-To: <937124.91472.qm@web62004.mail.re1.yahoo.com> References: <937124.91472.qm@web62004.mail.re1.yahoo.com> Message-ID: Before MC, which changes this, LLVM didn't have the ability to assemble its own output into an object file. There is a special code path for the JIT, though, which allows the JIT to encode instructions in memory. It's the difference between being able to make "native code" and being able to make an object file or executable. The plan for the future (maybe this summer?) is to switch the JIT over to the new MC-based instruction encoders. Reid On Tue, May 11, 2010 at 9:03 PM, Samuel Crow wrote: > Hello Michael, > > That's for the final linkage. ?Since the JIT does linking at the bitcode level, it doesn't need to access an external linker AFAIK. > > --Sam > > > > ----- Original Message ---- >> From: Michael Smith >> To: Daniel Berlin >> Cc: "llvmdev at cs.uiuc.edu" >> Sent: Tue, May 11, 2010 6:49:52 PM >> Subject: Re: [LLVMdev] Machine Code, JIT, and Windows >> >> My understanding was that compiling directly to native code wasn't supported on >> Windows yet. At least Clang seems to require having GCC in the path on >> Windows. > > -----Original Message----- > From: Daniel Berlin [mailto: >> ymailto="mailto:dberlin at dberlin.org" >> href="mailto:dberlin at dberlin.org">dberlin at dberlin.org] > Sent: Tuesday, >> May 11, 2010 4:14 PM > To: Michael Smith > Cc: >> ymailto="mailto:llvmdev at cs.uiuc.edu" >> href="mailto:llvmdev at cs.uiuc.edu">llvmdev at cs.uiuc.edu > Subject: Re: >> [LLVMdev] Machine Code, JIT, and Windows > > On Tue, May 11, 2010 at 6:48 PM, >> Michael Smith > < >> href="mailto:Michael.Smith at synopsys.com">Michael.Smith at synopsys.com> >> wrote: >> I'm writing an application that generates LLVM byte code and >> executes it at >> runtime. The options I'm looking at are to use the LLVM >> ExecutionEngine for >> JIT execution, or to write an assembly file, link it >> as a DLL using >> gcc/mingw, and load the DLL. It has to work on Linux and >> Windows. >> >> >> >> I've been testing it on Windows, and >> found that the JIT execution, and >> executing functions from a DLL are >> equally fast. Can anyone explain why? >> When I test JIT, I don't have >> MinGW's GCC in the path, so I wouldn't expect >> it to be compiling to >> native code. > > Why? > LLVM does not require an external application to >> compile to native code. > The JIT is in fact compiling to native >> code. >> >> >> >> Regards, >> >> Michael >> Smith >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu >> http://llvm.cs.uiuc.edu >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM >> Developers mailing list > >> href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu >> >> >http://llvm.cs.uiuc.edu > >> href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target=_blank >> >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 hhinnant at apple.com Tue May 11 21:24:47 2010 From: hhinnant at apple.com (Howard Hinnant) Date: Tue, 11 May 2010 22:24:47 -0400 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: References: <201005111826.20194.dag@cray.com> <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> Message-ID: <3ED983F5-899B-4E46-926E-A159FCDC39C2@apple.com> On May 11, 2010, at 9:32 PM, David Leimbach wrote: > > libc++: > > 5 seconds > > libstdc++: > > 22 seconds > > (smaller is better) > > Is this libstdc++ with or without rvalue references? > > How about compile times? Having used Go a bit, I've been quite fond of how short the code, compile, test loop ends up being. Tonight compile times look worse. This isn't completely unexpected as the code size of the libc++ sort is larger than the libstdc++ sort. Here is a matrix of times. Each time represents seconds and a median of 3 measurements: compile time run time ---------------- ---------------- libstdc++ libc++ libstdc++ libc++ g++-4.2 -O3 0.62 0.96 23 5 clang++ -O3 0.66 0.80 21 5 Since compile times are usually more important with non-opitimzed builds I computed the same table at -O0: compile time run time ---------------- ---------------- libstdc++ libc++ libstdc++ libc++ g++-4.2 -O0 0.48 .76 186 5 clang++ -O0 0.46 .70 261 5 -Howard From lhames at gmail.com Tue May 11 21:40:01 2010 From: lhames at gmail.com (Lang Hames) Date: Wed, 12 May 2010 12:40:01 +1000 Subject: [LLVMdev] Need help for my PBQP regAlloc proj in llvm.... In-Reply-To: References: Message-ID: Hi Prasad, The comments at the beginning of RegAllocPBQP.cpp list the two most relevant papers for PBQP register allocation. // (1) Hames, L. and Scholz, B. 2006. Nearly optimal register allocation with // PBQP. In Proceedings of the 7th Joint Modular Languages Conference // (JMLC'06). LNCS, vol. 4228. Springer, New York, NY, USA. 346-361. // // (2) Scholz, B., Eckstein, E. 2002. Register allocation for irregular // architectures. In Proceedings of the Joint Conference on Languages, // Compilers and Tools for Embedded Systems (LCTES'02), ACM Press, New York, // NY, USA, 139-148. The basics of the linear scan algorithm are described in the paper "Linear Scan Register Allocation" by Poletto and Sarkar. However, LLVM's "linear scan" differs significantly from the behaviour described in that paper. In particular when LLVM's linear scan allocator spills a live interval it backtracks to the start of that interval to continue allocation. This means that LLVM's "linear scan" isn't actually linear. I'm not sure whether there's any reference material that describes the behaviour of LLVM's linear scan apart from the code itself. Do any other register allocation people have a better answer to the linear scan question? Cheers, Lang. On Tue, May 11, 2010 at 8:56 PM, prasad dp wrote: > Hello, > we are currently working on my project that aims at improving the register > allocation scheme by identifying if the interference graphs are chordal or > not. > we are working on the llvm compiler .we are forcing the compiler to use > PBQP register allocation scheme by an option of ' ' regalloc=pbqp ' during > the execution of prgm. we have been succesfull in accessing the interference > graph information and creating our version of interference matrix depicting > the same information. we then use the same matrix to inspect for its chordal > nature. and we are looking for colouring the chordal graph in a linear time > using available algorithms. > I am looking for material that is related to the above mentioned work that > would help me to prepare my report. Particularly i am looking for the > information about Linear scan algorithm and PBQP scheme. PLZ do help me out. > > Thanks, > Durga Prasad > > _______________________________________________ > 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/20100512/0524a64b/attachment.html From ofv at wanadoo.es Tue May 11 22:01:15 2010 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Wed, 12 May 2010 05:01:15 +0200 Subject: [LLVMdev] Machine Code, JIT, and Windows References: <937124.91472.qm@web62004.mail.re1.yahoo.com> Message-ID: <87ljbp6cxw.fsf@telefonica.net> Reid Kleckner writes: [snip] > The plan for the future (maybe this summer?) is to switch the JIT over > to the new MC-based instruction encoders. Would this change something on the performance of the JIT? (the time it requires for creating the native code) From dag at cray.com Tue May 11 23:47:03 2010 From: dag at cray.com (David Greene) Date: Tue, 11 May 2010 23:47:03 -0500 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> References: <201005111826.20194.dag@cray.com> <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> Message-ID: <201005112347.03564.dag@cray.com> On Tuesday 11 May 2010 19:07:50 Howard Hinnant wrote: > > This looks cool, but I can't help wondering about the motivation. > > libstdc++ has a ton of useful functionality (debug mode, profile mode, > > etc.). Does libc++ plan to reproduce that? > > debug mode yes. It isn't there yet. And I would like to limit it to being > ABI compatible with release mode. This will entail significant debug > functionality curtailment, but also eliminate numerous errors I've seen > when debug mode and release mode get accidentally mixed. Ouch. I hope libc++ doesn't give up any debug functionality. It's indispensable. I think the ABI compatibility is worth it, but then I've never run into significant problems where I've been forced to mix debug and non-debug mode code. > > What's driving libc++? > > The possibility of being a superior solution. Ok, but could that be done by improving libstdc++? > ---------------- > > // Container overhead example > libc++: > > sizeof map = 3 > sizeof deque = 6 > > libstdc++: > > sizeof map = 6 > sizeof deque = 10 > > (smaller is better) Well, that depends, doesn't it? Why is libstdc++ larger? Is any functionality being given up by libc++? If not, why not improve libstdc++? > ---------------- > > // Adding a few items to a sorted sequence and resorting > // (a real world use case) > > libc++: > > 5 seconds > > libstdc++: > > 22 seconds > > (smaller is better) Again, what prevents someone from improving libstdc++ here? Numbers are good, but context and analysis are even better. > ---------------- > > This being said, clang will continue to be std::lib neutral. If libstdc++ > meets your needs better than libc++, then you should use it. libc++ will > have to earn its place. Of course. That will require some pretty comprehensive analysis. Right now I don't know which meets my needs better because we don't yet have an explanation of what the trade-offs are. I understand libc++ is new and you're probably not at that point yet, but a motivating document would help. Is there are document somewhere that explains why the project was started in the first place? -Dave From dag at cray.com Tue May 11 23:53:21 2010 From: dag at cray.com (David Greene) Date: Tue, 11 May 2010 23:53:21 -0500 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: References: Message-ID: <201005112353.21866.dag@cray.com> On Tuesday 11 May 2010 20:32:58 David Leimbach wrote: > Just two throw 2 more motivators in... > > Sometimes to re-implement after learning from work done before by others is > a reason to try it in itself. Also a lot of LLVM is C++ isn't it? Yes... > Wouldn't it be nice if it were 100% self hosting at some point? (I think > so.) Define self-hosting. LLVM is already self-hosting in the sense that it compiles itself. > Not having to depend on anyone else to make your stuff work is, well, > liberating. Yikes! To me that is the scariest scenario I can imagine. The best technical interview question I've ever been asked is, "what code would you never write?" Standard library functionality is at the top of my list. Why would anyone replace rigorously tested code with something not as widely tested that one has to maintain oneself? It reminds me of an interview lunch at which the developers constantly regaled me with tales of their wonderful custom data structures library. And then I asked about where they spend most of their time debugging. Guess where? Suffice to say, I didn't take that job. :) Again, I'm not dismissing libc++. I'm making a general point about reusing hardened code. If libc++ is demonstrably better than other solutions, I'll be the first on board. But I do wonder why libstdc++ could not be improved in the same way while retaining is enormous testing base. And what about libstdc++ doesn't work for Apple applications? -Dave From greened at obbligato.org Tue May 11 23:56:18 2010 From: greened at obbligato.org (David Greene) Date: Tue, 11 May 2010 23:56:18 -0500 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: <201005112347.03564.dag@cray.com> References: <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> <201005112347.03564.dag@cray.com> Message-ID: <201005112356.18615.greened@obbligato.org> On Tuesday 11 May 2010 23:47:03 David Greene wrote: > Ouch. I hope libc++ doesn't give up any debug functionality. It's > indispensable. I think the ABI compatibility is worth it, but then I've s/compatibility/incompatibility/ -Dave From clattner at apple.com Wed May 12 00:19:24 2010 From: clattner at apple.com (Chris Lattner) Date: Tue, 11 May 2010 22:19:24 -0700 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: <201005112353.21866.dag@cray.com> References: <201005112353.21866.dag@cray.com> Message-ID: <0D21AE4F-7F7E-4FB9-9322-19994D7705C0@apple.com> FYI, there is no reason for this thread to exist on both llvmdev and cfe-dev. Please move it to cfe-dev. -Chris From criswell at illinois.edu Wed May 12 01:23:28 2010 From: criswell at illinois.edu (John Criswell) Date: Wed, 12 May 2010 00:23:28 -0600 Subject: [LLVMdev] Need help for my PBQP regAlloc proj in llvm.... In-Reply-To: References: Message-ID: <4BEA4960.2000900@illinois.edu> Lang Hames wrote: > Hi Prasad, > > The comments at the beginning of RegAllocPBQP.cpp list the two most > relevant papers for PBQP register allocation. > > // (1) Hames, L. and Scholz, B. 2006. Nearly optimal register > allocation with > > > // PBQP. In Proceedings of the 7th Joint Modular Languages > Conference > > > // (JMLC'06). LNCS, vol. 4228. Springer, New York, NY, USA. 346-361. > > > > // > > > > // (2) Scholz, B., Eckstein, E. 2002. Register allocation for > irregular > > > // architectures. In Proceedings of the Joint Conference on > Languages, > > > // Compilers and Tools for Embedded Systems (LCTES'02), ACM Press, > New York, > > > // NY, USA, 139-148. > > The basics of the linear scan algorithm are described in the paper > "Linear Scan Register Allocation" by Poletto and Sarkar. However, > LLVM's "linear scan" differs significantly from the behaviour > described in that paper. In particular when LLVM's linear scan > allocator spills a live interval it backtracks to the start of that > interval to continue allocation. This means that LLVM's "linear scan" > isn't actually linear. I'm not sure whether there's any reference > material that describes the behaviour of LLVM's linear scan apart from > the code itself. I believe the linear scan register allocator was first written by Alkis (a former student in our research group). If the deviation from the original linear scan paper is due to his work, his report (http://llvm.org/ProjectsWithLLVM/#linearscan) may explain the differences and their motivations. -- John T. From subbu.pur at gmail.com Wed May 12 00:45:23 2010 From: subbu.pur at gmail.com (subramanyam) Date: Tue, 11 May 2010 22:45:23 -0700 (PDT) Subject: [LLVMdev] How to create Global Variables using LLVM API? In-Reply-To: <4BE8E6E4.5070604@mxc.ca> References: <28519938.post@talk.nabble.com> <4BE8E6E4.5070604@mxc.ca> Message-ID: <28532205.post@talk.nabble.com> Thanks. It works. Actually, the signature of the constructor given in the online documentation is different from the actual source code. Nick Lewycky wrote: > > subramanyam wrote: >> >> I am new to LLVM API. and I am experimenting with it. >> I want to create Global Variables in a module. >> I am able to create local variables using IRBuilder class. I tried using >> GlobalVariable class to create global variables. >> but it doesn't work. my code looks like this: >> >> Module* mod = new Module("test", getGlobalContext()); >> Constant* c = mod->getOrInsertFunction("main", >> IntegerType::get(getGlobalContext(), 32), NULL); >> Function* main = cast (c); >> main->setCallingConv(CallingConv::C); >> Twine s("foo"); >> StringRef s1("foo"); >> Constant *cons = ConstantArray::get(getGlobalContext(),s1, true); >> GlobalVariable val(*mod, (Type*) >> ArrayType::get(Type::getInt8Ty(getGlobalContext()), 4), >> true,GlobalValue::ExternalLinkage, cons, s); > > Firstly, don't cast to Type*. You need to #include "llvm/DerivedTypes.h" > instead. But that's not your bug. > > Don't allocate GlobalVariable val on the stack. You need to 'new' it, > ala. 'GlobalVariable *val = new GlobalVariable(...);' > > I haven't tried running your code, but give that a shot! > > Nick > > > >> >> >> Application stops running after reaching the last line. can somebody help >> me >> out here? >> >> > > _______________________________________________ > 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://old.nabble.com/How-to-create-Global-Variables-using-LLVM-API--tp28519938p28532205.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From anton at korobeynikov.info Wed May 12 01:51:11 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 12 May 2010 10:51:11 +0400 Subject: [LLVMdev] AsmPrinter::EmitLinkage In-Reply-To: References: <26574E66-8760-40BE-A5AD-2E160B161F09@apple.com> Message-ID: > For dllexport support, there are differences between GNU's and Microsoft's > linkers. I thought the the subtarget was their to differentiate what > tool-set was being targeted. I used that assumption on my patch to update > the support for dllexport. Yes, surely, since dllexport support is just adding extra stuff to linker cmdline. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From baldrick at free.fr Wed May 12 02:25:35 2010 From: baldrick at free.fr (Duncan Sands) Date: Wed, 12 May 2010 09:25:35 +0200 Subject: [LLVMdev] How to create Global Variables using LLVM API? In-Reply-To: <28532205.post@talk.nabble.com> References: <28519938.post@talk.nabble.com> <4BE8E6E4.5070604@mxc.ca> <28532205.post@talk.nabble.com> Message-ID: <4BEA57EF.90300@free.fr> Hi subramanyam, > Actually, the signature of the constructor given in the online documentation > is different from the actual source code. which bit of the documentation? Any chance of a patch that fixes it? Ciao, Duncan. From matt at console-pimps.org Wed May 12 03:18:40 2010 From: matt at console-pimps.org (Matt Fleming) Date: Wed, 12 May 2010 09:18:40 +0100 Subject: [LLVMdev] MC ELF support In-Reply-To: References: <871vdiuhjg.fsf@linux-g6p1.site> Message-ID: <87eihhr0rj.fsf@linux-g6p1.site> On Tue, 11 May 2010 19:03:27 -0700, Daniel Dunbar wrote: > > High level comments: > (1) The order of patches is odd, to me. It would be great to start by > adding the AsmParser support, then the MCStreamer support, so that we > can have test cases in the 'llvm-mc cat' mode, where it just parses > and prints out again. The order of the patches is a result of me trying to not break the build. I can certainly rework them if you'd prefer. > On 0001: > - What is hasRelocationAddend? It doesn't seem to be needed to me, > and I'm not sure why it would be. If this is a private detail to ELF, > it shouldn't go in TargetAsmBackend, but rather be an argument to the > object writer constructor. The reason I put it in TargetAsmBackend is because the concept of a relocation addend isn't specific to ELF; ELF is just the only object format that uses it ;-) I'll make this an argument to the object writer constructor. > - Feel free to submit a patch to split out ELFX86_{32,64}AsmBackend, > if you want me to apply it. Little / obvious patches like that are > great ones to get in first, and make subsequent patches easier to > read. Sure. I'll write a patch for that. > On 0002: > - Looks great, overall! > - WriteSymbolEntry isn't endianness neutral. I would find it easier > to read if Is64Bit weren't the top level branch but was only used > where it matters, but that is me. D'oh! Yeah, the endianness is broken. I'll fix that. Changing the branching will complicate this code quite a bit as not only are the sizes of the fields different for 64-bit and 32-bit, the layout of the fields is different also. > - LLVM style is to use assert(... && "Message to include in the assert"). > - Please use array_pod_sort (from ADT/STLExtras.h) instead of std::sort. > - WriteSecHdrEntry would be easier to read if it just used WriteWord > instead of Is64Bit. Good points. I'll fix these up. > - The changes to MCSectionELF shouldn't be needed. These should go > in MCSectionData instead, or in private maps if possible. I can give > you extra target dependent fields if need be. This enforces layering > between the parts CodeGen can access and the parts that are private to > the assembler backend. OK. I'll move this into MCSectionData, which will allow us to handle the .align directive. > On 0003: > - Might as well merge this with 0002. Will do! > On 0004: > - This looks good, might as well bring it in first. > - You could use ADT/StringSwitch for this sequence, if you like: Will do! > I recommend optimizing for getting the obvious parts or stub > implementations in first, so it is easy to review subsequent patches. Sure, sounds sensible. Thanks very much for the review! From baldrick at free.fr Wed May 12 03:58:36 2010 From: baldrick at free.fr (Duncan Sands) Date: Wed, 12 May 2010 10:58:36 +0200 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: <3ED983F5-899B-4E46-926E-A159FCDC39C2@apple.com> References: <201005111826.20194.dag@cray.com> <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> <3ED983F5-899B-4E46-926E-A159FCDC39C2@apple.com> Message-ID: <4BEA6DBC.6090600@free.fr> Hi Howard > compile time run time > ---------------- ---------------- > libstdc++ libc++ libstdc++ libc++ > > g++-4.2 -O3 0.62 0.96 23 5 > clang++ -O3 0.66 0.80 21 5 > > Since compile times are usually more important with non-opitimzed builds I computed the same table at -O0: > > compile time run time > ---------------- ---------------- > libstdc++ libc++ libstdc++ libc++ > > g++-4.2 -O0 0.48 .76 186 5 > clang++ -O0 0.46 .70 261 5 it seems odd that the libc++ runtime does not change when compiling at -O0. Why is that? Best wishes, Duncan. From eric.schweitz at gmail.com Wed May 12 08:41:49 2010 From: eric.schweitz at gmail.com (Eric Schweitz) Date: Wed, 12 May 2010 06:41:49 -0700 Subject: [LLVMdev] Adding a halting function attribute? In-Reply-To: References: <20100501171938.80516312800A@llvm.org> <3C5E4CAF-E189-4BBD-BAB9-B1AB61BC7C90@mac.com> <9A0BC3E3-58D1-4461-A942-8DBD344EF13F@apple.com> <5AAB0F42-04FF-4872-9CCB-77F275655D2B@apple.com> Message-ID: On Sun, May 2, 2010 at 9:32 AM, John Regehr wrote: > > On reflection, perhaps this isn't so bad. This really only matters when > > the compiler is able to infer readnone/readonly, which typically doesn't > > include cases with indirect calls. Per #2, I think it could be handled > > by making the GCC-style pure/const attributes imply both > > readonly/readnone *and* halting. > > This sounds right to me. > > John > > Isn't a noreturn attribute (i.e., not "halting") a property of the control-flow whereas pure/const describe the class of effects of the function? Why merge these distinct properties? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/c40283ad/attachment.html From hao.shen at imag.fr Wed May 12 08:53:16 2010 From: hao.shen at imag.fr (SHEN Hao) Date: Wed, 12 May 2010 15:53:16 +0200 Subject: [LLVMdev] How can I remove Intrinsic Functions during llvm-gcc compilation? In-Reply-To: <4BE84019.5020301@uiuc.edu> References: <4BE78BF0.3010307@free.fr> <4BE84019.5020301@uiuc.edu> Message-ID: On Mon, May 10, 2010 at 7:19 PM, John Criswell wrote: > SHEN Hao wrote: >> Thanks a lot for your answer. >> As what you said, I can not have any options to avoid generating this kind >> of intrinsic for byte code. Is it possible to modify gcc and ask it take >> all memset liked functions as a general function call? I know this solution >> is less performance efficient, but I would like to have it for my llvm >> assembly level modification works. >> > > It's possible to write an LLVM pass that converts calls to llvm.memset() > into calls to an external memset() function. ?You could then modify your > version of llvm-gcc to run this pass. > > However, is there really a problem with letting llvm-gcc use the > intrinsic, even if you're compiling a C library? ?If the code generator > replaces llvm.memset() with inline assembly code that does the same > thing, then you get the correct behavior. ?If it modifies the > llvm.memset() call to call an external memset() function, then the > program ends up using the implementation of memset() from the C library > that you're compiling. ?Either way, I'd think you'd get correct behavior. Thanks for your suggestion. I am using the LLVM for a simulator related research project. I need to modify all memory address related instructions such as load/store, br and call. As I should modify all the call related instructions, I can only support general functional calls. That's why I do not like all these intrinsic instructions. I like your suggestion of adding a LLVM pass. I think it's a good way to solve this problem with some works. Now I am now taking a look of existing LLVM code and I wish I can solve it ASAP. Best regards, Hao > > -- John T. > >> But anyway, thanks for you help. >> Hao >> >> On Mon, May 10, 2010 at 6:30 AM, Duncan Sands wrote: >> >>> Hi Hao Shen, >>> >>> >>>> I am using llvm-gcc --emit-llvm to generate byte code. With llvm >>>> readable ll format, I found some standard C library function such as >>>> llvm.memset. >>>> >>> this is not a C library function, it is an LLVM intrinsic. ?An intrinsic is >>> analogous to a builtin in gcc. ?An intrinsic may be expanded out into a code >>> sequence by the compiler, or may get turned into a library call (which sounds >>> like is what you are seeing). >>> >>> >>>> In fact, I'm trying to compile newlibc with llvm, I do not need this >>>> kind of llvm functions. How can I remove them during the compilation? >>>> >>> You can't avoid them. ?The same problem exists with gcc: you can't always >>> avoid having gcc use the gcc memset builtin. ?However it has to be said >>> that gcc generates its memset builtin less often than llvm-gcc generates >>> llvm.memset, so this is not as visible. ?Also (I'm not sure about this) >>> it may be that on some platforms gcc always expands builtin_memset into a >>> code sequence rather than generating a call to the library memset function. >>> However, gcc is not obliged to use a code sequence even in a freestanding >>> environment. ?The environment is always required to provide memset. ?Here's >>> what the gcc docs say: >>> >>> ? GCC requires the freestanding environment provide `memcpy', `memmove', >>> ?`memset' and `memcmp'. >>> >>> 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 > -- Hao Shen From arplynn at gmail.com Wed May 12 09:13:40 2010 From: arplynn at gmail.com (Alistair Lynn) Date: Wed, 12 May 2010 15:13:40 +0100 Subject: [LLVMdev] Adding a halting function attribute? In-Reply-To: References: <20100501171938.80516312800A@llvm.org> <3C5E4CAF-E189-4BBD-BAB9-B1AB61BC7C90@mac.com> <9A0BC3E3-58D1-4461-A942-8DBD344EF13F@apple.com> <5AAB0F42-04FF-4872-9CCB-77F275655D2B@apple.com> Message-ID: Hello- I don't believe noreturn implies non-halting - not returning does not imply not unwinding. Alistair On 12 May 2010, at 14:41, Eric Schweitz wrote: > On Sun, May 2, 2010 at 9:32 AM, John Regehr wrote: > > On reflection, perhaps this isn't so bad. This really only matters when > > the compiler is able to infer readnone/readonly, which typically doesn't > > include cases with indirect calls. Per #2, I think it could be handled > > by making the GCC-style pure/const attributes imply both > > readonly/readnone *and* halting. > > This sounds right to me. > > John > > > Isn't a noreturn attribute (i.e., not "halting") a property of the control-flow whereas pure/const describe the class of effects of the function? Why merge these distinct properties? > > -- > Eric > > _______________________________________________ > 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/20100512/7d3e5bf5/attachment.html From hao.shen at imag.fr Wed May 12 09:45:12 2010 From: hao.shen at imag.fr (SHEN Hao) Date: Wed, 12 May 2010 16:45:12 +0200 Subject: [LLVMdev] How can I remove Intrinsic Functions during llvm-gcc compilation? In-Reply-To: References: <4BE78BF0.3010307@free.fr> <4BE84019.5020301@uiuc.edu> Message-ID: On Wed, May 12, 2010 at 3:53 PM, SHEN Hao wrote: > On Mon, May 10, 2010 at 7:19 PM, John Criswell wrote: >> SHEN Hao wrote: >>> Thanks a lot for your answer. >>> As what you said, I can not have any options to avoid generating this kind >>> of intrinsic for byte code. Is it possible to modify gcc and ask it take >>> all memset liked functions as a general function call? I know this solution >>> is less performance efficient, but I would like to have it for my llvm >>> assembly level modification works. >>> >> >> It's possible to write an LLVM pass that converts calls to llvm.memset() >> into calls to an external memset() function. ?You could then modify your >> version of llvm-gcc to run this pass. >> >> However, is there really a problem with letting llvm-gcc use the >> intrinsic, even if you're compiling a C library? ?If the code generator >> replaces llvm.memset() with inline assembly code that does the same >> thing, then you get the correct behavior. ?If it modifies the >> llvm.memset() call to call an external memset() function, then the >> program ends up using the implementation of memset() from the C library >> that you're compiling. ?Either way, I'd think you'd get correct behavior. > > Thanks for your suggestion. I am using the LLVM for a simulator related > research project. I need to modify all memory address related instructions > such as load/store, br and call. As I should modify all the call related > instructions, I can only support general functional calls. That's why I do not > like all these intrinsic instructions. > > I like your suggestion of adding a LLVM pass. I think it's a good way to solve > this problem with some works. Now I am now taking a look of existing > LLVM code and I wish I can solve it ASAP. > Fortunately, in the lib/Target/CBackend/CBackend.cpp, I found the CWriter::lowerIntrinsics function which is a good example for my work. The LLVM pass can be realized based on this example. > Best regards, > Hao > >> >> -- John T. >> >>> But anyway, thanks for you help. >>> Hao >>> >>> On Mon, May 10, 2010 at 6:30 AM, Duncan Sands wrote: >>> >>>> Hi Hao Shen, >>>> >>>> >>>>> I am using llvm-gcc --emit-llvm to generate byte code. With llvm >>>>> readable ll format, I found some standard C library function such as >>>>> llvm.memset. >>>>> >>>> this is not a C library function, it is an LLVM intrinsic. ?An intrinsic is >>>> analogous to a builtin in gcc. ?An intrinsic may be expanded out into a code >>>> sequence by the compiler, or may get turned into a library call (which sounds >>>> like is what you are seeing). >>>> >>>> >>>>> In fact, I'm trying to compile newlibc with llvm, I do not need this >>>>> kind of llvm functions. How can I remove them during the compilation? >>>>> >>>> You can't avoid them. ?The same problem exists with gcc: you can't always >>>> avoid having gcc use the gcc memset builtin. ?However it has to be said >>>> that gcc generates its memset builtin less often than llvm-gcc generates >>>> llvm.memset, so this is not as visible. ?Also (I'm not sure about this) >>>> it may be that on some platforms gcc always expands builtin_memset into a >>>> code sequence rather than generating a call to the library memset function. >>>> However, gcc is not obliged to use a code sequence even in a freestanding >>>> environment. ?The environment is always required to provide memset. ?Here's >>>> what the gcc docs say: >>>> >>>> ? GCC requires the freestanding environment provide `memcpy', `memmove', >>>> ?`memset' and `memcmp'. >>>> >>>> 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 >> > > > > -- > Hao Shen > -- Hao Shen From dberlin at dberlin.org Wed May 12 09:52:45 2010 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 12 May 2010 10:52:45 -0400 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: <38261765-DADA-44C3-83BD-8C13CB68753B@apple.com> References: <201005111826.20194.dag@cray.com> <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> <38261765-DADA-44C3-83BD-8C13CB68753B@apple.com> Message-ID: > > This was compiled with g++-4.-2 -O3 (without rvalue references, which would have no effect on sorting ints anyway). Errr, that is a pretty old version at this point. Also this was before significant performance improvements were target at libstdc++ *and* g++. It seems a bit strange to compare something from today to something that is now 3 release versions old. From tan4ik at gmail.com Wed May 12 09:55:17 2010 From: tan4ik at gmail.com (Tan4ik) Date: Wed, 12 May 2010 09:55:17 -0500 Subject: [LLVMdev] would like to contribute Message-ID: Hello everyone! I'm new to open-source in general and to LLVM in particular. I'd like to contribute and was thinking of starting from http://llvm.org/bugs/show_bug.cgi?id=5639 What the next step should be? Should I register somewhere? Thanks, Tami -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/261df9a0/attachment.html From chris at bubblescope.net Wed May 12 10:03:02 2010 From: chris at bubblescope.net (Christopher Jefferson) Date: Wed, 12 May 2010 16:03:02 +0100 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: References: <201005111826.20194.dag@cray.com> <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> <38261765-DADA-44C3-83BD-8C13CB68753B@apple.com> Message-ID: <0B941676-308B-4FAA-BDD4-84D950AE1F8D@bubblescope.net> On 12 May 2010, at 15:52, Daniel Berlin wrote: >> >> This was compiled with g++-4.-2 -O3 (without rvalue references, which would have no effect on sorting ints anyway). > > Errr, that is a pretty old version at this point. > Also this was before significant performance improvements were target > at libstdc++ *and* g++. > It seems a bit strange to compare something from today to something > that is now 3 release versions old. I believe this std::sort implementation is better, taking a few good ideas, especially with regards already most-sorted lists. Of course the libc++ could easily be lifted out and dropped into libstdc++ with very minor mangling-related changes without breaking anything. The container changes are more fundamental, and in particular would (obviously) break the ABI, which libstdc++ has avoided for some time, even when there are known better implementation techniques (issues in std::string, and small object allocation, occur in particular). Chris From ofv at wanadoo.es Wed May 12 10:22:28 2010 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Wed, 12 May 2010 17:22:28 +0200 Subject: [LLVMdev] would like to contribute References: Message-ID: <87hbmd5emj.fsf@telefonica.net> Welcome Tami. Tan4ik writes: > I'm new to open-source in general and to LLVM in particular. > I'd like to contribute and was thinking of starting from > http://llvm.org/bugs/show_bug.cgi?id=5639 > What the next step should be? Should I register somewhere? No need to register. Be sure to carefully read http://www.llvm.org/docs/DeveloperPolicy.html then go ahead with your task, make a patch as described on the above mentioned document, and send it to the llvm-commits mailing list for review. Happy LLVM hacking! From brukman at gmail.com Wed May 12 10:26:38 2010 From: brukman at gmail.com (Misha Brukman) Date: Wed, 12 May 2010 11:26:38 -0400 Subject: [LLVMdev] would like to contribute In-Reply-To: References: Message-ID: On Wed, May 12, 2010 at 10:55 AM, Tan4ik wrote: > I'm new to open-source in general and to LLVM in particular. > I'd like to contribute and was thinking of starting from > http://llvm.org/bugs/show_bug.cgi?id=5639 > What the next step should be? Should I register somewhere? > 1. Register for an account at the LLVM Bugzilla (the link you sent above). 2. Find a bug to work on (as you've done already) 3. Accept the bug to show that you're working on it, so that effort isn't duplicated 4. Post a patch (and test case, if applicable) that fixes the bug 5. Respond to feedback and iterate to revise your patch as needed, until someone accepts and submits your patch 6. Mark bug as "fixed" 7. Repeat from step 2 Misha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/4637a99b/attachment.html From tan4ik at gmail.com Wed May 12 10:29:33 2010 From: tan4ik at gmail.com (Tan4ik) Date: Wed, 12 May 2010 10:29:33 -0500 Subject: [LLVMdev] would like to contribute In-Reply-To: References: Message-ID: Great! Thank you Tami On Wed, May 12, 2010 at 10:26 AM, Misha Brukman wrote: > On Wed, May 12, 2010 at 10:55 AM, Tan4ik wrote: > >> I'm new to open-source in general and to LLVM in particular. >> I'd like to contribute and was thinking of starting from >> http://llvm.org/bugs/show_bug.cgi?id=5639 >> What the next step should be? Should I register somewhere? >> > > 1. Register for an account at the LLVM Bugzilla (the link you sent above). > 2. Find a bug to work on (as you've done already) > 3. Accept the bug to show that you're working on it, so that effort isn't > duplicated > 4. Post a patch (and test case, if applicable) that fixes the bug > 5. Respond to feedback and iterate to revise your patch as needed, until > someone accepts and submits your patch > 6. Mark bug as "fixed" > 7. Repeat from step 2 > > Misha > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/6d218d7c/attachment.html From anton at korobeynikov.info Wed May 12 10:34:13 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 12 May 2010 19:34:13 +0400 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: References: <201005111826.20194.dag@cray.com> <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> <38261765-DADA-44C3-83BD-8C13CB68753B@apple.com> Message-ID: > Errr, that is a pretty old version at this point. > Also this was before significant performance improvements were target > at libstdc++ *and* g++. Because this is the last version of gcc "oficially" available for darwin? Noone cares about newer gcc / libstdc++ there. I consider this pretty strange as well :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From dberlin at dberlin.org Wed May 12 10:39:12 2010 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 12 May 2010 11:39:12 -0400 Subject: [LLVMdev] [cfe-dev] New libc++ LLVM Subproject In-Reply-To: References: <201005111826.20194.dag@cray.com> <3AE117BA-876E-4AC0-A583-25D182B9C118@apple.com> <38261765-DADA-44C3-83BD-8C13CB68753B@apple.com> Message-ID: On Wed, May 12, 2010 at 11:34 AM, Anton Korobeynikov wrote: >> Errr, that is a pretty old version at this point. >> Also this was before significant performance improvements were target >> at libstdc++ *and* g++. > Because this is the last version of gcc "oficially" available for > darwin? Noone cares about newer gcc / libstdc++ there. > I consider this pretty strange as well :) When you are trying to make at least a reasonably fair comparison between two sets of libraries and compilers, you shouldn't use significantly old versions of one and the latest of the other, and then say "see the new hotness is faster and better". It may indeed be so, but when presented as justification, you should take the time to do it right. *Especially* when the likelihood of something like this getting copied and pasted all over the web is pretty high. --Dan From blunted2night at gmail.com Wed May 12 11:07:01 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 12 May 2010 09:07:01 -0700 Subject: [LLVMdev] debug macros Message-ID: Their are a pair of debug macros I use in almost every project I work on and I would like to add them to LLVM if acceptable. The existing DEBUG macro is good for a lot of things, but inadequate for certain situations. The may be cases where you wan't to run calculations in the debug version that lead up to assertions. In a scenario like this, you will likely need a temporary variable, and you calculations need to execute unconditionally. For this type of scenario I use the _dbg macro: #ifndef NDEBUG #define _dbg(x) x #else #define _dbg(x) #endif The other macro is just a slight variation on the existing DEBUG macro, but for the common case of printing something out to the debug console, its simpler to write, and in my opinion easier to read. #define dbgout(x) DEBUG(dbgs()< Hi everyone, I have questions about relocations. - "normal" relocation (current global mapping of the JIT ?) needs to be patch in code and relatively to the address of the code. - .LJTI are emitted because of a "switch"-like construct : this is the jumping table, the address of this table (in "data" section) needs to be patch in code section. - .LBB are emitted because of a "switch"-like construct : They need to be patch with code address but in the "data" section. (I understand BB as address of "Basic Block") - .LCPI : It seems to be related to "constant pool entry" but I have no clue on what they are for. Anyone ? - .Ltmp : No clue on what it is used for, but it seems safe to ignore them ? Are you aware of other "special" relocations, of their meaning and on how to patch them ? Perhaps someone has a good link on a documentation/code/explanation ? Thanks ! Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/8bb085de/attachment.html From rb5 at rice.edu Wed May 12 17:26:39 2010 From: rb5 at rice.edu (Rajkishore Barik) Date: Wed, 12 May 2010 17:26:39 -0500 Subject: [LLVMdev] Graph Utilities Message-ID: <934BDC79-545D-4977-96ED-F37255EA3CB8@rice.edu> Hi, I am wondering if there is any generic graph data structure along with its traversal routines already available in LLVM-2.7. In particular, I am looking for creating both directed and undirected graphs and be able to perform dfs, topsort, and scc on them. Best regards, Raj From billtohara at gmail.com Wed May 12 18:02:54 2010 From: billtohara at gmail.com (Bill O'Hara) Date: Wed, 12 May 2010 16:02:54 -0700 Subject: [LLVMdev] Linking problems with llvm-2.7, release 64b build with vs2010 Message-ID: Hello, Following some recent messages about building with Visual Studio 2010, I have gotten most things to compile in release mode on 64b windows 7. (Mainly the few errors with 0 -> nullptr in the second argument of the pair constructor, and making an ECValue constructor public). I'm falling at the last hurdle though when it comes to the final link: 1>------ Build started: Project: Fibonacci, Configuration: Release x64 ------ 1> Creating library C:/llvm-2.7-src/build/lib/Release/Fibonacci.lib and object C:/llvm-2.7-src/build/lib/Release/Fibonacci.exp 1>LLVMX86CodeGen.lib(X86JITInfo.obj) : error LNK2019: unresolved external symbol X86CompilationCallback referenced in function "public: virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void * (__cdecl*)(void *)))(void)" (?getLazyResolverFunction at X86JITInfo@llvm@@UEAAP6AXXZP6APEAXPEAX at Z@Z) 1>C:\llvm-2.7-src\build\bin\Release\Fibonacci.exe : fatal error LNK1120: 1 unresolved externals ========== Build: 0 succeeded, 1 failed, 22 up-to-date, 0 skipped ========== I'm not entirely convinced that lib/Target/X86/X86CompilationCallback_Win64.asm is being assembled and linked into that library - has anyone gotten this to link properly? thanks b From ofv at wanadoo.es Wed May 12 18:37:46 2010 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Thu, 13 May 2010 01:37:46 +0200 Subject: [LLVMdev] Linking problems with llvm-2.7, release 64b build with vs2010 References: Message-ID: <878w7o669h.fsf@telefonica.net> "Bill O'Hara" writes: > 1>LLVMX86CodeGen.lib(X86JITInfo.obj) : error LNK2019: unresolved > external symbol X86CompilationCallback referenced in function "public: > virtual void (__cdecl*__cdecl > llvm::X86JITInfo::getLazyResolverFunction(void * (__cdecl*)(void > *)))(void)" (?getLazyResolverFunction at X86JITInfo@llvm@@UEAAP6AXXZP6APEAXPEAX at Z@Z) > 1>C:\llvm-2.7-src\build\bin\Release\Fibonacci.exe : fatal error > LNK1120: 1 unresolved externals > ========== Build: 0 succeeded, 1 failed, 22 up-to-date, 0 skipped ========== > > I'm not entirely convinced that > lib/Target/X86/X86CompilationCallback_Win64.asm is being assembled and > linked into that library - has anyone gotten this to link properly? See if this bug report helps you to work around the problem: http://www.llvm.org/bugs/show_bug.cgi?id=4936 Please report your results. From subbu.pur at gmail.com Wed May 12 22:23:02 2010 From: subbu.pur at gmail.com (subramanyam) Date: Wed, 12 May 2010 20:23:02 -0700 (PDT) Subject: [LLVMdev] How to create Global Variables using LLVM API? In-Reply-To: <4BEA57EF.90300@free.fr> References: <28519938.post@talk.nabble.com> <4BE8E6E4.5070604@mxc.ca> <28532205.post@talk.nabble.com> <4BEA57EF.90300@free.fr> Message-ID: <28543259.post@talk.nabble.com> I am using llvm-2.6. In the online documentation, the signature is GlobalVariable::GlobalVariable ( const Type * Ty, bool isConstant, LinkageTypes Linkage, Constant * Initializer = 0, const Twine & Name = "", bool ThreadLocal = false, unsigned AddressSpace = 0 ) the link to the documenation is http://llvm.org/doxygen/classllvm_1_1GlobalVariable.html There are two constructors given. Second constructor signature is same as the source code. The first one differs though. In the source code the prototype of the constructor is at line 53 in GlobalVariable.h file. The signature is GlobalVariable(LLVMContext &Context, const Type *Ty, bool isConstant, LinkageTypes Linkage, Constant *Initializer = 0, const Twine &Name = "", bool ThreadLocal = false, unsigned AddressSpace = 0); Duncan Sands wrote: > > Hi subramanyam, > >> Actually, the signature of the constructor given in the online >> documentation >> is different from the actual source code. > > which bit of the documentation? Any chance of a patch that fixes it? > > Ciao, > > Duncan. > _______________________________________________ > 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://old.nabble.com/How-to-create-Global-Variables-using-LLVM-API--tp28519938p28543259.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From criswell at illinois.edu Wed May 12 23:22:44 2010 From: criswell at illinois.edu (John Criswell) Date: Wed, 12 May 2010 22:22:44 -0600 Subject: [LLVMdev] How to create Global Variables using LLVM API? In-Reply-To: <28543259.post@talk.nabble.com> References: <28519938.post@talk.nabble.com> <4BE8E6E4.5070604@mxc.ca> <28532205.post@talk.nabble.com> <4BEA57EF.90300@free.fr> <28543259.post@talk.nabble.com> Message-ID: <4BEB7E94.3060803@illinois.edu> subramanyam wrote: > I am using llvm-2.6. > In the online documentation, the signature is > GlobalVariable::GlobalVariable ( const Type * Ty, > bool isConstant, > LinkageTypes Linkage, > Constant * Initializer = 0, > const Twine & Name = "", > bool ThreadLocal = false, > unsigned AddressSpace = 0 > ) > the link to the documenation is > http://llvm.org/doxygen/classllvm_1_1GlobalVariable.html > The doxygen docs on the web page are updated every evening to reflect new changes in mainline LLVM. If the API for GlobalVariables has changed, then there will be a mismatch between LLVM 2.6 and what is on the web. Thankfully, API changes aren't *that* frequent (although when they do occur, they are not always timed to my liking). It has been recommended to me to use the IRBuilder class to create LLVM IR instead of using the various IR classes directly. I've been told that IRBuilder is less likely to change from release to release. I haven't tried it myself yet, but you may want to consider it for your project. -- John T. > There are two constructors given. Second constructor signature is same as > the source code. The first one differs though. > > In the source code the prototype of the constructor is at line 53 in > GlobalVariable.h file. > The signature is > GlobalVariable(LLVMContext &Context, const Type *Ty, bool isConstant, > LinkageTypes Linkage, > Constant *Initializer = 0, const Twine &Name = "", > bool ThreadLocal = false, unsigned AddressSpace = 0); > > > > Duncan Sands wrote: > >> Hi subramanyam, >> >> >>> Actually, the signature of the constructor given in the online >>> documentation >>> is different from the actual source code. >>> >> which bit of the documentation? Any chance of a patch that fixes it? >> >> 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 Micah.Villmow at amd.com Wed May 12 22:28:43 2010 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 12 May 2010 22:28:43 -0500 Subject: [LLVMdev] determining if the signness of a integer pointer Message-ID: Is there a way to determine via API calls whether a pointer to an int points to a signed integer or an unsigned integer? Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100512/4acff2f1/attachment.html From me22.ca at gmail.com Wed May 12 22:45:32 2010 From: me22.ca at gmail.com (me22) Date: Thu, 13 May 2010 05:45:32 +0200 Subject: [LLVMdev] determining if the signness of a integer pointer In-Reply-To: References: Message-ID: On 13 May 2010 05:28, Villmow, Micah wrote: > Is there a way to determine via API calls whether a pointer to an int points > to a signed integer or an unsigned integer? > Since LLVM doesn't have signed or unsigned integer types, I'm not sure what you're asking. I suppose you could look for additions done with values loaded from or stored to the pointer... From Micah.Villmow at amd.com Wed May 12 22:49:08 2010 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 12 May 2010 22:49:08 -0500 Subject: [LLVMdev] determining if the signness of a integer pointer In-Reply-To: References: Message-ID: Since the frontend knows that a int pointer is signed or unsigned, I was hoping that this bit was set somewhere in a header file that I couldn't find when it was creating the LLVM integer. Micah -----Original Message----- From: me22 [mailto:me22.ca at gmail.com] Sent: Wednesday, May 12, 2010 8:46 PM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] determining if the signness of a integer pointer On 13 May 2010 05:28, Villmow, Micah wrote: > Is there a way to determine via API calls whether a pointer to an int points > to a signed integer or an unsigned integer? > Since LLVM doesn't have signed or unsigned integer types, I'm not sure what you're asking. I suppose you could look for additions done with values loaded from or stored to the pointer... From clattner at apple.com Wed May 12 23:40:40 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 12 May 2010 21:40:40 -0700 Subject: [LLVMdev] determining if the signness of a integer pointer In-Reply-To: References: Message-ID: <822CC7E1-A7A4-44B3-B180-C4F6268E1212@apple.com> On May 12, 2010, at 8:49 PM, Villmow, Micah wrote: > Since the frontend knows that a int pointer is signed or unsigned, I was hoping that this bit was set somewhere in a header file that I couldn't find when it was creating the LLVM integer. Nope, the conversion to LLVM IR loses this information. -Chris From o.j.sivart at gmail.com Wed May 12 23:53:51 2010 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Thu, 13 May 2010 14:23:51 +0930 Subject: [LLVMdev] Handling of thread_local globals by llc -march=cpp Message-ID: Hi all, I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise? Thanks in advance. Details are as follows. The llvm bc I'm using (which clang produced from a simple c source file, thread_local.c, that has a __thread global, a, and a single function, f, which returns the value of the thread local global) is: ; ModuleID = 'thread_local.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-n8:16:32" target triple = "i386-pc-linux-gnu" @a = thread_local global i32 1, align 4 ; [#uses=1] define i32 @f() nounwind { entry: %retval = alloca i32, align 4 ; [#uses=2] %tmp = load i32* @a ; [#uses=1] store i32 %tmp, i32* %retval %0 = load i32* %retval ; [#uses=1] ret i32 %0 } Within the cpp file the relevant code to create and initialise the global is: GlobalVariable* gvar_int32_a = new GlobalVariable(/*Module=*/*mod, /*Type=*/IntegerType::get(mod->getContext(), 32), /*isConstant=*/false, /*Linkage=*/GlobalValue::ExternalLinkage, /*Initializer=*/0, // has initializer, specified below /*Name=*/"a"); gvar_int32_a->setAlignment(4); // Constant Definitions ConstantInt* const_int32_2 = ConstantInt::get(mod->getContext(), APInt(32, StringRef("1"), 10)); // Global Variable Definitions gvar_int32_a->setInitializer(const_int32_2); As you can see no actual parameter is provided for the optional formal ThreadLocal parameter of the GlobalVariable constructor; it instead then gets the default value of false. Compiling the cpp file and executing it to check the output of running the createPrintModulePass confirms that the llvm IR produced does not create a thread local global variable: ; ModuleID = 'thread_local.s' 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-n8:16:32" target triple = "i386-pc-linux-gnu" @a = global i32 1, align 4 ; [#uses=1] define i32 @f() nounwind { entry: %retval = alloca i32, align 4 ; [#uses=2] %tmp = load i32* @a ; [#uses=1] store i32 %tmp, i32* %retval %0 = load i32* %retval ; [#uses=1] ret i32 %0 } From chayan.ju at gmail.com Thu May 13 01:10:18 2010 From: chayan.ju at gmail.com (Chayan Sarkar) Date: Thu, 13 May 2010 11:40:18 +0530 Subject: [LLVMdev] How to insert phi Message-ID: Hi, I am new to llvm. I have project in llvm. For that I need SSA form, which is already implemented in llvm. Basically I want to know which pass insert phi and converts it to SSA form in llvm . Regards, Chayan From nicholas at mxc.ca Thu May 13 01:14:11 2010 From: nicholas at mxc.ca (Nick Lewycky) Date: Wed, 12 May 2010 23:14:11 -0700 Subject: [LLVMdev] How to insert phi In-Reply-To: References: Message-ID: <4BEB98B3.4000405@mxc.ca> Chayan Sarkar wrote: > Hi, > I am new to llvm. I have project in llvm. For that I need SSA form, > which is already implemented in llvm. Basically I want to know which > pass insert phi and converts it to SSA form in llvm . http://llvm.org/docs/Passes.html#mem2reg which is lib/Transforms/Utils/PromoteMemoryToRegister.cpp. Nick From chayan.ju at gmail.com Thu May 13 02:06:21 2010 From: chayan.ju at gmail.com (Chayan Sarkar) Date: Thu, 13 May 2010 12:36:21 +0530 Subject: [LLVMdev] How to insert phi In-Reply-To: <4BEB98B3.4000405@mxc.ca> References: <4BEB98B3.4000405@mxc.ca> Message-ID: Thanks a lot. Chayan On Thu, May 13, 2010 at 11:44 AM, Nick Lewycky wrote: > Chayan Sarkar wrote: >> >> Hi, >> I am new to llvm. I have project in llvm. For that I need SSA form, >> which is already implemented in llvm. Basically I want to know which >> pass insert phi and converts it to SSA form in llvm . > > http://llvm.org/docs/Passes.html#mem2reg which is > lib/Transforms/Utils/PromoteMemoryToRegister.cpp. > > Nick > From anton at korobeynikov.info Thu May 13 02:43:44 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 13 May 2010 11:43:44 +0400 Subject: [LLVMdev] Handling of thread_local globals by llc -march=cpp In-Reply-To: References: Message-ID: Hello > I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise? Thanks for the report. Should be fixed in r103702 -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From o.j.sivart at gmail.com Thu May 13 04:05:02 2010 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Thu, 13 May 2010 18:35:02 +0930 Subject: [LLVMdev] Handling of thread_local globals by llc -march=cpp In-Reply-To: References: Message-ID: Thanks for the quick reply and fix. Now it just means I have to hunt further in exploring why, in my simple test program, replacing the following line of code: GlobalVariable* global = new GlobalVariable(*MyModule, IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global"); with the following line of code: GlobalVariable* global = new GlobalVariable(*MyModule, IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global", 0, true); in order to create a thread local global variable instead of a standard global variable causes the function (which uses the global) produced by the following line of code: void *FPtr = MyExecutionEngine->getPointerToFunction(MyFunction); to segfault when I call it in the following sequence of code: int (*FP)() = (int (*)())FPtr; int res = FP(); when the function executes correctly in the case of instead having created a standard global variable. Doh! As far as I got with this was to note that the machine code produced for the function is attempting to still do a move from a memory location (and an inaccessible one at that: 0xfffffffc) instead of doing a move from an offset from the segment register. On 13/05/2010, at 5:13 PM, Anton Korobeynikov wrote: > Hello > >> I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise? > Thanks for the report. Should be fixed in r103702 > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University From anton at korobeynikov.info Thu May 13 06:55:17 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 13 May 2010 15:55:17 +0400 Subject: [LLVMdev] Handling of thread_local globals by llc -march=cpp In-Reply-To: References: Message-ID: > int (*FP)() = (int (*)())FPtr; > int res = FP(); > > when the function executes correctly in the case of instead having created a standard global variable. What is the platform you're running the code on? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From o.j.sivart at gmail.com Thu May 13 06:56:29 2010 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Thu, 13 May 2010 21:26:29 +0930 Subject: [LLVMdev] Handling of thread_local globals by llc -march=cpp In-Reply-To: References: Message-ID: <12289A08-7EC8-4DC0-AF27-6297D46AA2C4@gmail.com> target triple = "i386-pc-linux-gnu" On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote: >> int (*FP)() = (int (*)())FPtr; >> int res = FP(); >> >> when the function executes correctly in the case of instead having created a standard global variable. > What is the platform you're running the code on? > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University From dimitry at andric.com Thu May 13 09:10:04 2010 From: dimitry at andric.com (Dimitry Andric) Date: Thu, 13 May 2010 16:10:04 +0200 Subject: [LLVMdev] Linking problems with llvm-2.7, release 64b build with vs2010 In-Reply-To: <878w7o669h.fsf@telefonica.net> References: <878w7o669h.fsf@telefonica.net> Message-ID: <4BEC083C.3030909@andric.com> On 2010-05-13 01:37, ?scar Fuentes wrote: >> lib/Target/X86/X86CompilationCallback_Win64.asm is being assembled and >> linked into that library - has anyone gotten this to link properly? > > See if this bug report helps you to work around the problem: > > http://www.llvm.org/bugs/show_bug.cgi?id=4936 It indeed looks like a CMake issue; see this report: http://public.kitware.com/Bug/view.php?id=8170 As far as I can see, none of the code posted in that report has yet made it to the CMake git repository, though. From o.j.sivart at gmail.com Thu May 13 09:35:35 2010 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Fri, 14 May 2010 00:05:35 +0930 Subject: [LLVMdev] Handling of thread_local globals by llc -march=cpp In-Reply-To: <12289A08-7EC8-4DC0-AF27-6297D46AA2C4@gmail.com> References: <12289A08-7EC8-4DC0-AF27-6297D46AA2C4@gmail.com> Message-ID: <950DAF02-355E-4514-A020-255A356783E8@gmail.com> I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and machine code that has segment register offset addressing. On 13/05/2010, at 9:26 PM, o.j.sivart at gmail.com wrote: > target triple = "i386-pc-linux-gnu" > > On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote: > >>> int (*FP)() = (int (*)())FPtr; >>> int res = FP(); >>> >>> when the function executes correctly in the case of instead having created a standard global variable. >> What is the platform you're running the code on? >> >> -- >> With best regards, Anton Korobeynikov >> Faculty of Mathematics and Mechanics, Saint Petersburg State University > From ed at 80386.nl Thu May 13 12:07:28 2010 From: ed at 80386.nl (Ed Schouten) Date: Thu, 13 May 2010 19:07:28 +0200 Subject: [LLVMdev] libSystem, __clear_cache(), FreeBSD and ARM Message-ID: <20100513170728.GJ56080@hoeg.nl> Hi folks, I just tried to build LLVM on FreeBSD/arm. It looks like libSystem doesn't build and requires the following hack: --- lib/System/Memory.cpp +++ lib/System/Memory.cpp @@ -61,7 +61,7 @@ for (intptr_t Line = StartLine; Line < EndLine; Line += LineSize) asm volatile("icbi 0, %0" : : "r"(Line)); asm volatile("isync"); -# elif defined(__arm__) && defined(__GNUC__) +# elif defined(__arm__) && defined(__GNUC__) && !defined(__FreeBSD__) // FIXME: Can we safely always call this for __GNUC__ everywhere? char *Start = (char*) Addr; char *End = Start + Len; I don't know anything about ARM, but isn't there a way we can do this using some inline asm instead of calling a glibc-function? Greetings, -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100513/03f19f3e/attachment.bin From Edmund.Grimley-Evans at arm.com Thu May 13 12:03:40 2010 From: Edmund.Grimley-Evans at arm.com (Edmund Grimley-Evans) Date: Thu, 13 May 2010 18:03:40 +0100 Subject: [LLVMdev] Returning big vectors on ARM broke in rev 103411 Message-ID: <39E9E98DF632C2469FF2FC07853B70C60560E0E8@ZIPPY.Emea.Arm.com> I think this test case demonstrates it: ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { ; CHECK: vadd.i64 %y = add <4 x i64> %a, %b ret <4 x i64> %y } (I hope I got that right.) -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From gohman at apple.com Thu May 13 13:28:21 2010 From: gohman at apple.com (Dan Gohman) Date: Thu, 13 May 2010 11:28:21 -0700 Subject: [LLVMdev] getTripCount requires which optimization passes? In-Reply-To: <1F0847FB-08E3-41F7-9380-0487251419A9@nasa.gov> References: <0D1A6E16-0987-489A-8E34-A5A2F62CEDC5@nasa.gov> <3AE154C9-9EE0-42A2-BD9E-27BA3DD54874@nasa.gov> <1F0847FB-08E3-41F7-9380-0487251419A9@nasa.gov> Message-ID: <0D2E37B2-8FA0-445E-ABF1-6AC066A869CD@apple.com> On May 10, 2010, at 2:20 PM, Trevor Harmon wrote: > On May 10, 2010, at 11:45 AM, Dan Gohman wrote: > >> just make your front-ends add -indvars before >> adding your pass. > > Sorry, I don't have a clue how to do this, and I can't find any docs about it. I'm using llvm-gcc; how can I tell it to add a pass? llvm-gcc uses include/llvm/Support/StandardPasses.h. It already includes indvars and others. Dan From Trevor.W.Harmon at nasa.gov Thu May 13 13:28:45 2010 From: Trevor.W.Harmon at nasa.gov (Trevor Harmon) Date: Thu, 13 May 2010 11:28:45 -0700 Subject: [LLVMdev] Graph Utilities In-Reply-To: <934BDC79-545D-4977-96ED-F37255EA3CB8@rice.edu> References: <934BDC79-545D-4977-96ED-F37255EA3CB8@rice.edu> Message-ID: <991D7E40-37B8-4292-B40F-E0FF93C0436C@nasa.gov> On May 12, 2010, at 3:26 PM, Rajkishore Barik wrote: > I am wondering if there is any generic graph data structure along with > its traversal routines > already available in LLVM-2.7. In particular, I am looking for > creating both directed and undirected > graphs and be able to perform dfs, topsort, and scc on them. Not in LLVM. I use Boost Graph for this. Trevor From wendling at apple.com Thu May 13 13:59:02 2010 From: wendling at apple.com (Bill Wendling) Date: Thu, 13 May 2010 11:59:02 -0700 Subject: [LLVMdev] Attention: About to Break SystemZ and possibly other Back Ends Message-ID: <8F062016-11A3-4B95-B41F-CAEC071EC6ED@apple.com> Hi, Attached is a patch I'm testing. It changes how "MachineFrameInfo::HasCalls" is calculated. Basically, the way it's calculated now is in PEI. And it only looks for frame adjustments (or inline ASM) to determine if the function has a call or not. This way is much more accurate and occurs much sooner. But it breaks this test: test/CodeGen/SystemZ/2009-07-10-BadIncomingArgOffset.ll (See below for the output with this patch.) The problem is that SystemZ is using "hasCalls()" in the back end to determine if a frame pointer is needed or not. My guess is that several of the places where it calls hasCalls() should really be hasFP(). I don't have enough expertise in all of the back ends to determine if the call should be "hasFP" or "hasCalls". I need the respective back end owners to perform an audit of their code. This can be done even before my patch goes in (it's not ready yet). Please look at all calls to hasCalls() in the back end and determine if it should remain that or should be changed to hasFP() instead, given that hasCalls() is more accurate and not just indicating that there's a frame in the function. -bw Here is the new output: .file "/Volumes/Sandbox/llvm/llvm.src/test/CodeGen/SystemZ/2009-07-10-BadIncomingArgOffset.ll" .text .globl mp_mul_radix_test_bb3 .align 2 .type mp_mul_radix_test_bb3, at function mp_mul_radix_test_bb3: # @mp_mul_radix_test_bb3 # BB#0: # %newFuncRoot stmg %r6, %r15, 48(%r15) aghi %r15, -160 # kill: R3W R3D lr %r12, %r2 lg %r11, 328(%r15) lg %r1, 320(%r15) lgr %r10, %r4 lgfr %r9, %r3 lghi %r3, -1 lgr %r2, %r9 lgr %r4, %r1 brasl %r14, rdft lgfr %r2, %r12 lgr %r3, %r9 lgr %r4, %r10 brasl %r14, mp_mul_d2i_test std %f0, 0(%r11) lmg %r6, %r15, 208(%r15) br %r14 .Ltmp0: .size mp_mul_radix_test_bb3, .Ltmp0-mp_mul_radix_test_bb3 .section .note.GNU-stack,"", at progbits -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p.txt Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100513/53f2a6f6/attachment.txt -------------- next part -------------- From mailtome200420032002 at yahoo.com Thu May 13 14:28:30 2010 From: mailtome200420032002 at yahoo.com (john blair) Date: Thu, 13 May 2010 12:28:30 -0700 (PDT) Subject: [LLVMdev] Building llvm using non-system gcc/binutils Message-ID: <779932.92988.qm@web53101.mail.re2.yahoo.com> I am trying to build llvm-2.7 using non-system gcc/binutils. My gcc version is 4.1.2, and binutils is 2.17.50.0.15. I get the following errors `.L2438' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) .... .... make[1]: *** [/build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVM-2.7.so] Error 1 make[1]: Leaving directory `/build/toolchain/src/llvm-2.7/objdir/tools/llvm-shlib' make: *** [all] Error 1 I configure it using export PATH=/build/toolchain/lin32/binutils-2.17.50.0.15/bin:$PATH LDFLAGS=-L"/build/toolchain/lin32/gcc-4.1.2-8/lib" CC=/build/toolchain/lin32/gcc-4.1.2/bin/gcc CXX=/build/toolchain/lin32/gcc-4.1.2/bin/g++ ../llvm-2.7/configure This works with 2.6. From anton at korobeynikov.info Thu May 13 14:42:03 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 13 May 2010 23:42:03 +0400 Subject: [LLVMdev] Attention: About to Break SystemZ and possibly other Back Ends In-Reply-To: <8F062016-11A3-4B95-B41F-CAEC071EC6ED@apple.com> References: <8F062016-11A3-4B95-B41F-CAEC071EC6ED@apple.com> Message-ID: Hi, Bill > Please look at all calls to hasCalls() in the back end and determine if it should remain that or should be changed to hasFP() instead, given that hasCalls() is more accurate and not just indicating that there's a frame in the function. It looks like hasCalls() returns false with your change, right? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From anton at korobeynikov.info Thu May 13 14:53:20 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 13 May 2010 23:53:20 +0400 Subject: [LLVMdev] Handling of thread_local globals by llc -march=cpp In-Reply-To: <950DAF02-355E-4514-A020-255A356783E8@gmail.com> References: <12289A08-7EC8-4DC0-AF27-6297D46AA2C4@gmail.com> <950DAF02-355E-4514-A020-255A356783E8@gmail.com> Message-ID: > I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and machine code that has segment register offset addressing. Maybe TLS stuff is just broken inside JIT? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From eli.friedman at gmail.com Thu May 13 15:00:42 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 13 May 2010 13:00:42 -0700 Subject: [LLVMdev] Building llvm using non-system gcc/binutils In-Reply-To: <779932.92988.qm@web53101.mail.re2.yahoo.com> References: <779932.92988.qm@web53101.mail.re2.yahoo.com> Message-ID: On Thu, May 13, 2010 at 12:28 PM, john blair wrote: > I am trying to build llvm-2.7 using non-system gcc/binutils. My gcc version is 4.1.2, and binutils is 2.17.50.0.15. I get the following errors That version of gcc is known to have issues building LLVM; see http://llvm.org/docs/GettingStarted.html#brokengcc . Try upgrading your gcc version. -Eli > `.L2438' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) > .... > .... > make[1]: *** [/build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVM-2.7.so] Error 1 > make[1]: Leaving directory `/build/toolchain/src/llvm-2.7/objdir/tools/llvm-shlib' > make: *** [all] Error 1 > > I configure it using > export PATH=/build/toolchain/lin32/binutils-2.17.50.0.15/bin:$PATH > LDFLAGS=-L"/build/toolchain/lin32/gcc-4.1.2-8/lib" CC=/build/toolchain/lin32/gcc-4.1.2/bin/gcc CXX=/build/toolchain/lin32/gcc-4.1.2/bin/g++ ../llvm-2.7/configure > > This works with 2.6. > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From dimitry at andric.com Thu May 13 15:15:34 2010 From: dimitry at andric.com (Dimitry Andric) Date: Thu, 13 May 2010 22:15:34 +0200 Subject: [LLVMdev] libSystem, __clear_cache(), FreeBSD and ARM In-Reply-To: <20100513170728.GJ56080@hoeg.nl> References: <20100513170728.GJ56080@hoeg.nl> Message-ID: <4BEC5DE6.6020903@andric.com> On 2010-05-13 19:07, Ed Schouten wrote: > --- lib/System/Memory.cpp > +++ lib/System/Memory.cpp > @@ -61,7 +61,7 @@ > for (intptr_t Line = StartLine; Line < EndLine; Line += LineSize) > asm volatile("icbi 0, %0" : : "r"(Line)); > asm volatile("isync"); > -# elif defined(__arm__) && defined(__GNUC__) > +# elif defined(__arm__) && defined(__GNUC__) && !defined(__FreeBSD__) > // FIXME: Can we safely always call this for __GNUC__ everywhere? > char *Start = (char*) Addr; > char *End = Start + Len; > > I don't know anything about ARM, but isn't there a way we can do this > using some inline asm instead of calling a glibc-function? If you are talking about __clear_cache(), it is defined in libgcc, not glibc. This should also be available on FreeBSD, though I can only find the required libgcc2.h header in the gcc source directory... The function is at least available on FreeBSD/i386-CURRENT: $ readelf -a /lib/libgcc_s.so.1 | grep __clear_cache 51: 000046b0 5 FUNC GLOBAL DEFAULT 11 __clear_cache@@GCC_3.0 From mailtome200420032002 at yahoo.com Thu May 13 15:28:31 2010 From: mailtome200420032002 at yahoo.com (john blair) Date: Thu, 13 May 2010 13:28:31 -0700 (PDT) Subject: [LLVMdev] Building llvm using non-system gcc/binutils In-Reply-To: Message-ID: <248083.44339.qm@web53104.mail.re2.yahoo.com> Thanks for the reply Eli. I have the same version of gcc/binutils as my system gcc/binutils And it gets built without any errors with them. --- On Thu, 5/13/10, Eli Friedman wrote: > From: Eli Friedman > Subject: Re: [LLVMdev] Building llvm using non-system gcc/binutils > To: "john blair" > Cc: llvmdev at cs.uiuc.edu > Date: Thursday, May 13, 2010, 1:00 PM > On Thu, May 13, 2010 at 12:28 PM, > john blair > > wrote: > > I am trying to build llvm-2.7 using non-system > gcc/binutils. My gcc version is 4.1.2, and binutils is > 2.17.50.0.15. I get the following errors > > That version of gcc is known to have issues building LLVM; > see > http://llvm.org/docs/GettingStarted.html#brokengcc > .? Try upgrading > your gcc version. > > -Eli > > > `.L2438' referenced in section > `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' > of > /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): > defined in discarded section > `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' > of > /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) > > .... > > .... > > make[1]: *** > [/build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVM-2.7.so] > Error 1 > > make[1]: Leaving directory > `/build/toolchain/src/llvm-2.7/objdir/tools/llvm-shlib' > > make: *** [all] Error 1 > > > > I configure it using > > export > PATH=/build/toolchain/lin32/binutils-2.17.50.0.15/bin:$PATH > > LDFLAGS=-L"/build/toolchain/lin32/gcc-4.1.2-8/lib" > CC=/build/toolchain/lin32/gcc-4.1.2/bin/gcc > CXX=/build/toolchain/lin32/gcc-4.1.2/bin/g++ > ../llvm-2.7/configure > > > > This works with 2.6. > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu > ? ? ? ? http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > From kecheng at cecs.pdx.edu Thu May 13 15:47:47 2010 From: kecheng at cecs.pdx.edu (Kecheng) Date: Thu, 13 May 2010 13:47:47 -0700 Subject: [LLVMdev] How to get the variable mapping between the source and llvm bytecode Message-ID: <201005131347419526312@cecs.pdx.edu> Hi, I want to know the variable mapping between the source and llvm bytecode. It seems that current llvm debugging information cannot provide this mapping directly. Here is my examples (llvm 2.7). In this exmaple, I want to know the mapping: tmp<--->%4. But current llvm's debugging information can only provide that the instruction "%4 = add nsw i32 %3, 2" is at line 3 in the C source. But since there're two "+" at line 3, I don't have a direct way to know which "+" is mapped to this "add". Is there any way I can derive the mapping based on current ddg infor? Thanks. ************** C source ************** int h (int j, int i) { int tmp; tmp = j+i+2; return tmp; } ************** .ll file ************** ; ModuleID = 'simplecase.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" define i32 @h(i32 %j, i32 %i) nounwind { entry: %j_addr = alloca i32 ; [#uses=2] %i_addr = alloca i32 ; [#uses=2] %retval = alloca i32 ; [#uses=2] %0 = alloca i32 ; [#uses=2] %tmp = alloca i32 ; [#uses=2] %"alloca point" = bitcast i32 0 to i32 ; [#uses=0] call void @llvm.dbg.declare(metadata !{i32* %j_addr}, metadata !0), !dbg !6 store i32 %j, i32* %j_addr call void @llvm.dbg.declare(metadata !{i32* %i_addr}, metadata !7), !dbg !6 store i32 %i, i32* %i_addr call void @llvm.dbg.declare(metadata !{i32* %tmp}, metadata !8), !dbg !10 %1 = load i32* %j_addr, align 4, !dbg !11 ; [#uses=1] %2 = load i32* %i_addr, align 4, !dbg !11 ; [#uses=1] %3 = add nsw i32 %1, %2, !dbg !11 ; [#uses=1] %4 = add nsw i32 %3, 2, !dbg !11 ; [#uses=1] store i32 %4, i32* %tmp, align 4, !dbg !11 %5 = load i32* %tmp, align 4, !dbg !12 ; [#uses=1] store i32 %5, i32* %0, align 4, !dbg !12 %6 = load i32* %0, align 4, !dbg !12 ; [#uses=1] store i32 %6, i32* %retval, align 4, !dbg !12 br label %return, !dbg !12 return: ; preds = %entry %retval1 = load i32* %retval, !dbg !12 ; [#uses=1] ret i32 %retval1, !dbg !12 } declare void @llvm.dbg.declare(metadata, metadata) nounwind readnone !0 = metadata !{i32 459009, metadata !1, metadata !"j", metadata !2, i32 1, metadata !5} ; [ DW_TAG_arg_variable ] !1 = metadata !{i32 458798, i32 0, metadata !2, metadata !"h", metadata !"h", metadata !"h", metadata !2, i32 1, metadata !3, i1 false, i1 true, i32 0, i32 0, null, i1 false} ; [ DW_TAG_subprogram ] !2 = metadata !{i32 458769, i32 0, i32 1, metadata !"simplecase.c", metadata !"/home/kecheng/cases/v2.7/simplecase/", metadata !"4.2.1 (Based on Apple Inc. build 5658) (LLVM build)", i1 true, i1 false, metadata !"", i32 0} ; [ DW_TAG_compile_unit ] !3 = metadata !{i32 458773, metadata !2, metadata !"", metadata !2, i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !4, i32 0, null} ; [ DW_TAG_subroutine_type ] !4 = metadata !{metadata !5, metadata !5, metadata !5} !5 = metadata !{i32 458788, metadata !2, metadata !"int", metadata !2, i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] !6 = metadata !{i32 1, i32 0, metadata !1, null} !7 = metadata !{i32 459009, metadata !1, metadata !"i", metadata !2, i32 1, metadata !5} ; [ DW_TAG_arg_variable ] !8 = metadata !{i32 459008, metadata !9, metadata !"tmp", metadata !2, i32 2, metadata !5} ; [ DW_TAG_auto_variable ] !9 = metadata !{i32 458763, metadata !1, i32 1, i32 0} ; [ DW_TAG_lexical_block ] !10 = metadata !{i32 1, i32 0, metadata !9, null} !11 = metadata !{i32 3, i32 0, metadata !9, null} !12 = metadata !{i32 4, i32 0, metadata !9, null} Best, Kecheng 2010-05-13 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100513/485be9ba/attachment.html From eli.friedman at gmail.com Thu May 13 17:34:57 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 13 May 2010 15:34:57 -0700 Subject: [LLVMdev] Building llvm using non-system gcc/binutils In-Reply-To: <248083.44339.qm@web53104.mail.re2.yahoo.com> References: <248083.44339.qm@web53104.mail.re2.yahoo.com> Message-ID: On Thu, May 13, 2010 at 1:28 PM, john blair wrote: > Thanks for the reply Eli. > I have the same version of gcc/binutils as my system gcc/binutils And it gets built without any errors with them. Using a non-system gcc/binutils almost certainly isn't causing your issues; this looks like an internal gcc bug. Are you sure you're using precisely the same version? It might not be the same even if gcc --version returns the same version number; some systems using gcc backport fixes. -Eli > --- On Thu, 5/13/10, Eli Friedman wrote: > >> From: Eli Friedman >> Subject: Re: [LLVMdev] Building llvm using non-system gcc/binutils >> To: "john blair" >> Cc: llvmdev at cs.uiuc.edu >> Date: Thursday, May 13, 2010, 1:00 PM >> On Thu, May 13, 2010 at 12:28 PM, >> john blair >> >> wrote: >> > I am trying to build llvm-2.7 using non-system >> gcc/binutils. My gcc version is 4.1.2, and binutils is >> 2.17.50.0.15. I get the following errors >> >> That version of gcc is known to have issues building LLVM; >> see >> http://llvm.org/docs/GettingStarted.html#brokengcc >> .? Try upgrading >> your gcc version. >> >> -Eli >> >> > `.L2438' referenced in section >> `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' >> of >> /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): >> defined in discarded section >> `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' >> of >> /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) >> > .... >> > .... >> > make[1]: *** >> [/build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVM-2.7.so] >> Error 1 >> > make[1]: Leaving directory >> `/build/toolchain/src/llvm-2.7/objdir/tools/llvm-shlib' >> > make: *** [all] Error 1 >> > >> > I configure it using >> > export >> PATH=/build/toolchain/lin32/binutils-2.17.50.0.15/bin:$PATH >> > LDFLAGS=-L"/build/toolchain/lin32/gcc-4.1.2-8/lib" >> CC=/build/toolchain/lin32/gcc-4.1.2/bin/gcc >> CXX=/build/toolchain/lin32/gcc-4.1.2/bin/g++ >> ../llvm-2.7/configure >> > >> > This works with 2.6. >> > >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu >> ? ? ? ? http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> > > > > > From eli.friedman at gmail.com Thu May 13 17:38:30 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 13 May 2010 15:38:30 -0700 Subject: [LLVMdev] How to get the variable mapping between the source and llvm bytecode In-Reply-To: <201005131347419526312@cecs.pdx.edu> References: <201005131347419526312@cecs.pdx.edu> Message-ID: On Thu, May 13, 2010 at 1:47 PM, Kecheng wrote: > Hi, > > I want to know the variable mapping between the source and llvm bytecode. It > seems that current llvm debugging information cannot provide this mapping > directly. > > Here is my examples (llvm 2.7). In this exmaple, I want to know the mapping: > tmp<--->%4. But current llvm's debugging information can only provide that > the instruction "%4?=?add?nsw?i32?%3,?2" is at line 3 in the C source. But > since there're two "+" at line 3, I don't have a direct way to know which > "+" is mapped to this "add". Is there any way I can derive the mapping based > on current ddg infor? Thanks. You want to map the "+" in the source to a specific "add" instruction? clang does provide column number info, though, which might help a bit. In general, though, debug info isn't rich enough to provide that sort of mapping. What are you trying to do? -Eli > ************** > C source > ************** > int?h?(int?j,?int?i)?{ > ????int?tmp; > ????tmp?=?j+i+2; > ????return?tmp; > } > > ************** > .ll file > ************** > ;?ModuleID?=?'simplecase.c' > target?datalayout?=?"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" > target?triple?=?"x86_64-unknown-linux-gnu" > define?i32?@h(i32?%j,?i32?%i)?nounwind?{ > entry: > ??%j_addr?=?alloca?i32????????????????????????????;??[#uses=2] > ??%i_addr?=?alloca?i32????????????????????????????;??[#uses=2] > ??%retval?=?alloca?i32????????????????????????????;??[#uses=2] > ??%0?=?alloca?i32?????????????????????????????????;??[#uses=2] > ??%tmp?=?alloca?i32???????????????????????????????;??[#uses=2] > ??%"alloca?point"?=?bitcast?i32?0?to?i32??????????;??[#uses=0] > ??call?void?@llvm.dbg.declare(metadata?!{i32*?%j_addr},?metadata?!0),?!dbg?!6 > ??store?i32?%j,?i32*?%j_addr > ??call?void?@llvm.dbg.declare(metadata?!{i32*?%i_addr},?metadata?!7),?!dbg?!6 > ??store?i32?%i,?i32*?%i_addr > ??call?void?@llvm.dbg.declare(metadata?!{i32*?%tmp},?metadata?!8),?!dbg?!10 > ??%1?=?load?i32*?%j_addr,?align?4,?!dbg?!11???????;??[#uses=1] > ??%2?=?load?i32*?%i_addr,?align?4,?!dbg?!11???????;??[#uses=1] > ??%3?=?add?nsw?i32?%1,?%2,?!dbg?!11???????????????;??[#uses=1] > ??%4?=?add?nsw?i32?%3,?2,?!dbg?!11????????????????;??[#uses=1] > ??store?i32?%4,?i32*?%tmp,?align?4,?!dbg?!11 > ??%5?=?load?i32*?%tmp,?align?4,?!dbg?!12??????????;??[#uses=1] > ??store?i32?%5,?i32*?%0,?align?4,?!dbg?!12 > ??%6?=?load?i32*?%0,?align?4,?!dbg?!12????????????;??[#uses=1] > ??store?i32?%6,?i32*?%retval,?align?4,?!dbg?!12 > ??br?label?%return,?!dbg?!12 > return:???????????????????????????????????????????;?preds?=?%entry > ??%retval1?=?load?i32*?%retval,?!dbg?!12??????????;??[#uses=1] > ??ret?i32?%retval1,?!dbg?!12 > } > declare?void?@llvm.dbg.declare(metadata,?metadata)?nounwind?readnone > !0?=?metadata?!{i32?459009,?metadata?!1,?metadata?!"j",?metadata?!2,?i32?1,?metadata?!5}?;?[?DW_TAG_arg_variable?] > !1?=?metadata?!{i32?458798,?i32?0,?metadata?!2,?metadata?!"h",?metadata?!"h",?metadata?!"h",?metadata?!2,?i32?1,?metadata?!3,?i1?false,?i1?true,?i32?0,?i32?0,?null,?i1?false}?;?[?DW_TAG_subprogram?] > !2?=?metadata?!{i32?458769,?i32?0,?i32?1,?metadata?!"simplecase.c",?metadata?!"/home/kecheng/cases/v2.7/simplecase/",?metadata?!"4.2.1?(Based?on?Apple?Inc.?build?5658)?(LLVM?build)",?i1?true,?i1?false,?metadata?!"",?i32?0}?;?[?DW_TAG_compile_unit?] > !3?=?metadata?!{i32?458773,?metadata?!2,?metadata?!"",?metadata?!2,?i32?0,?i64?0,?i64?0,?i64?0,?i32?0,?null,?metadata?!4,?i32?0,?null}?;?[?DW_TAG_subroutine_type?] > !4?=?metadata?!{metadata?!5,?metadata?!5,?metadata?!5} > !5?=?metadata?!{i32?458788,?metadata?!2,?metadata?!"int",?metadata?!2,?i32?0,?i64?32,?i64?32,?i64?0,?i32?0,?i32?5}?;?[?DW_TAG_base_type?] > !6?=?metadata?!{i32?1,?i32?0,?metadata?!1,?null} > !7?=?metadata?!{i32?459009,?metadata?!1,?metadata?!"i",?metadata?!2,?i32?1,?metadata?!5}?;?[?DW_TAG_arg_variable?] > !8?=?metadata?!{i32?459008,?metadata?!9,?metadata?!"tmp",?metadata?!2,?i32?2,?metadata?!5}?;?[?DW_TAG_auto_variable?] > !9?=?metadata?!{i32?458763,?metadata?!1,?i32?1,?i32?0}?;?[?DW_TAG_lexical_block?] > !10?=?metadata?!{i32?1,?i32?0,?metadata?!9,?null} > !11?=?metadata?!{i32?3,?i32?0,?metadata?!9,?null} > !12?=?metadata?!{i32?4,?i32?0,?metadata?!9,?null} > > Best, > > Kecheng > 2010-05-13 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From kecheng at cecs.pdx.edu Thu May 13 18:00:32 2010 From: kecheng at cecs.pdx.edu (Kecheng) Date: Thu, 13 May 2010 16:00:32 -0700 Subject: [LLVMdev] How to get the variable mapping between the source andllvm bytecode References: <201005131347419526312@cecs.pdx.edu> Message-ID: <201005131600270468874@cecs.pdx.edu> Hi, I want to get the mapping between C source's variables and bytecode variables. It seems that llvm doesn't provide this mapping, so I think a walk-around method is to get the instruction's mapping. I have to use llvm-gcc, not clang. Any advice? Thanks. Best, Kecheng 2010-05-13 From: Eli Friedman Date: 2010-05-13 15:38:36 To: Kecheng Cc: llvmdev Subject: Re: [LLVMdev] How to get the variable mapping between the source andllvm bytecode On Thu, May 13, 2010 at 1:47 PM, Kecheng wrote: > Hi, > > I want to know the variable mapping between the source and llvm bytecode. It > seems that current llvm debugging information cannot provide this mapping > directly. > > Here is my examples (llvm 2.7). In this exmaple, I want to know the mapping: > tmp<--->%4. But current llvm's debugging information can only provide that > the instruction "%4 = add nsw i32 %3, 2" is at line 3 in the C source. But > since there're two "+" at line 3, I don't have a direct way to know which > "+" is mapped to this "add". Is there any way I can derive the mapping based > on current ddg infor? Thanks. You want to map the "+" in the source to a specific "add" instruction? clang does provide column number info, though, which might help a bit. In general, though, debug info isn't rich enough to provide that sort of mapping. What are you trying to do? -Eli > ************** > C source > ************** > int h (int j, int i) { > int tmp; > tmp = j+i+2; > return tmp; > } > > ************** > .ll file > ************** > ; ModuleID = 'simplecase.c' > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" > target triple = "x86_64-unknown-linux-gnu" > define i32 @h(i32 %j, i32 %i) nounwind { > entry: > %j_addr = alloca i32 ; [#uses=2] > %i_addr = alloca i32 ; [#uses=2] > %retval = alloca i32 ; [#uses=2] > %0 = alloca i32 ; [#uses=2] > %tmp = alloca i32 ; [#uses=2] > %"alloca point" = bitcast i32 0 to i32 ; [#uses=0] > call void @llvm.dbg.declare(metadata !{i32* %j_addr}, metadata !0), !dbg !6 > store i32 %j, i32* %j_addr > call void @llvm.dbg.declare(metadata !{i32* %i_addr}, metadata !7), !dbg !6 > store i32 %i, i32* %i_addr > call void @llvm.dbg.declare(metadata !{i32* %tmp}, metadata !8), !dbg !10 > %1 = load i32* %j_addr, align 4, !dbg !11 ; [#uses=1] > %2 = load i32* %i_addr, align 4, !dbg !11 ; [#uses=1] > %3 = add nsw i32 %1, %2, !dbg !11 ; [#uses=1] > %4 = add nsw i32 %3, 2, !dbg !11 ; [#uses=1] > store i32 %4, i32* %tmp, align 4, !dbg !11 > %5 = load i32* %tmp, align 4, !dbg !12 ; [#uses=1] > store i32 %5, i32* %0, align 4, !dbg !12 > %6 = load i32* %0, align 4, !dbg !12 ; [#uses=1] > store i32 %6, i32* %retval, align 4, !dbg !12 > br label %return, !dbg !12 > return: ; preds = %entry > %retval1 = load i32* %retval, !dbg !12 ; [#uses=1] > ret i32 %retval1, !dbg !12 > } > declare void @llvm.dbg.declare(metadata, metadata) nounwind readnone > !0 = metadata !{i32 459009, metadata !1, metadata !"j", metadata !2, i32 1, metadata !5} ; [ DW_TAG_arg_variable ] > !1 = metadata !{i32 458798, i32 0, metadata !2, metadata !"h", metadata !"h", metadata !"h", metadata !2, i32 1, metadata !3, i1 false, i1 true, i32 0, i32 0, null, i1 false} ; [ DW_TAG_subprogram ] > !2 = metadata !{i32 458769, i32 0, i32 1, metadata !"simplecase.c", metadata !"/home/kecheng/cases/v2.7/simplecase/", metadata !"4.2.1 (Based on Apple Inc. build 5658) (LLVM build)", i1 true, i1 false, metadata !"", i32 0} ; [ DW_TAG_compile_unit ] > !3 = metadata !{i32 458773, metadata !2, metadata !"", metadata !2, i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !4, i32 0, null} ; [ DW_TAG_subroutine_type ] > !4 = metadata !{metadata !5, metadata !5, metadata !5} > !5 = metadata !{i32 458788, metadata !2, metadata !"int", metadata !2, i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] > !6 = metadata !{i32 1, i32 0, metadata !1, null} > !7 = metadata !{i32 459009, metadata !1, metadata !"i", metadata !2, i32 1, metadata !5} ; [ DW_TAG_arg_variable ] > !8 = metadata !{i32 459008, metadata !9, metadata !"tmp", metadata !2, i32 2, metadata !5} ; [ DW_TAG_auto_variable ] > !9 = metadata !{i32 458763, metadata !1, i32 1, i32 0} ; [ DW_TAG_lexical_block ] > !10 = metadata !{i32 1, i32 0, metadata !9, null} > !11 = metadata !{i32 3, i32 0, metadata !9, null} > !12 = metadata !{i32 4, i32 0, metadata !9, null} > > Best, > > Kecheng > 2010-05-13 > _______________________________________________ > 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/20100513/e28a70d7/attachment.html From evan.cheng at apple.com Thu May 13 18:53:19 2010 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 13 May 2010 16:53:19 -0700 Subject: [LLVMdev] Returning big vectors on ARM broke in rev 103411 In-Reply-To: <39E9E98DF632C2469FF2FC07853B70C60560E0E8@ZIPPY.Emea.Arm.com> References: <39E9E98DF632C2469FF2FC07853B70C60560E0E8@ZIPPY.Emea.Arm.com> Message-ID: <8DE1686D-6922-4E95-B0F8-CD71E00A3E45@apple.com> I don't think this has ever worked. Evan On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: > I think this test case demonstrates it: > > ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s > > define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { > ; CHECK: vadd.i64 > %y = add <4 x i64> %a, %b > ret <4 x i64> %y > } > > (I hope I got that right.) > > > > -- > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From eli.friedman at gmail.com Thu May 13 18:58:00 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 13 May 2010 16:58:00 -0700 Subject: [LLVMdev] How to get the variable mapping between the source andllvm bytecode In-Reply-To: <201005131600270468874@cecs.pdx.edu> References: <201005131347419526312@cecs.pdx.edu> <201005131600270468874@cecs.pdx.edu> Message-ID: On Thu, May 13, 2010 at 4:00 PM, Kecheng wrote: > Hi, > > I want to get the mapping between C?source's variables and bytecode > variables.??It seems that llvm doesn't provide this mapping, so I think a > walk-around method is to get the instruction's mapping. I have to use > llvm-gcc, not clang. Any advice? Thanks. "int tmp;" corresponds to "%tmp = alloca i32" in the IR. You can pull that mapping out of the appropriate llvm.dbg.declare call. To find assignments to the variable, look for store instructions which store into "%tmp". I fail to see what the addition has to do with anything in this context. -Eli > Best, > > ________________________________ > Kecheng > 2010-05-13 > ________________________________ > From? Eli Friedman > Date? 2010-05-13?15:38:36 > To? Kecheng > Cc? llvmdev > Subject? Re: [LLVMdev] How to get the variable mapping between the source > andllvm bytecode > > On?Thu,?May?13,?2010?at?1:47?PM,?Kecheng??wrote: >>?Hi, >> >>?I?want?to?know?the?variable?mapping?between?the?source?and?llvm?bytecode.?It >>?seems?that?current?llvm?debugging?information?cannot?provide?this?mapping >>?directly. >> >>?Here?is?my?examples?(llvm?2.7).?In?this?exmaple,?I?want?to?know?the?mapping: >>?tmp<--->%4.?But?current?llvm's?debugging?information?can?only?provide?that >>?the?instruction?"%4?=?add?nsw?i32?%3,?2"?is?at?line?3?in?the?C?source.?But >>?since?there're?two?"+"?at?line?3,?I?don't?have?a?direct?way?to?know?which >>?"+"?is?mapped?to?this?"add".?Is?there?any?way?I?can?derive?the?mapping?based >>?on?current?ddg?infor??Thanks. > You?want?to?map?the?"+"?in?the?source?to?a?specific?"add"?instruction? > ?clang?does?provide?column?number?info,?though,?which?might?help?a > bit.??In?general,?though,?debug?info?isn't?rich?enough?to?provide?that > sort?of?mapping.??What?are?you?trying?to?do? > -Eli >>?************** >>?C?source >>?************** >>?int?h?(int?j,?int?i)?{ >>?????int?tmp; >>?????tmp?=?j+i+2; >>?????return?tmp; >>?} >> >>?************** >>?.ll?file >>?************** >>?;?ModuleID?=?'simplecase.c' >>?target?datalayout?=?"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" >>?target?triple?=?"x86_64-unknown-linux-gnu" >>?define?i32?@h(i32?%j,?i32?%i)?nounwind?{ >>?entry: >>???%j_addr?=?alloca?i32????????????????????????????;??[#uses=2] >>???%i_addr?=?alloca?i32????????????????????????????;??[#uses=2] >>???%retval?=?alloca?i32????????????????????????????;??[#uses=2] >>???%0?=?alloca?i32?????????????????????????????????;??[#uses=2] >>???%tmp?=?alloca?i32???????????????????????????????;??[#uses=2] >>???%"alloca?point"?=?bitcast?i32?0?to?i32??????????;??[#uses=0] >>???call?void?@llvm.dbg.declare(metadata?!{i32*?%j_addr},?metadata?!0),?!dbg?!6 >>???store?i32?%j,?i32*?%j_addr >>???call?void?@llvm.dbg.declare(metadata?!{i32*?%i_addr},?metadata?!7),?!dbg?!6 >>???store?i32?%i,?i32*?%i_addr >>???call?void?@llvm.dbg.declare(metadata?!{i32*?%tmp},?metadata?!8),?!dbg?!10 >>???%1?=?load?i32*?%j_addr,?align?4,?!dbg?!11???????;??[#uses=1] >>???%2?=?load?i32*?%i_addr,?align?4,?!dbg?!11???????;??[#uses=1] >>???%3?=?add?nsw?i32?%1,?%2,?!dbg?!11???????????????;??[#uses=1] >>???%4?=?add?nsw?i32?%3,?2,?!dbg?!11????????????????;??[#uses=1] >>???store?i32?%4,?i32*?%tmp,?align?4,?!dbg?!11 >>???%5?=?load?i32*?%tmp,?align?4,?!dbg?!12??????????;??[#uses=1] >>???store?i32?%5,?i32*?%0,?align?4,?!dbg?!12 >>???%6?=?load?i32*?%0,?align?4,?!dbg?!12????????????;??[#uses=1] >>???store?i32?%6,?i32*?%retval,?align?4,?!dbg?!12 >>???br?label?%return,?!dbg?!12 >>?return:???????????????????????????????????????????;?preds?=?%entry >>???%retval1?=?load?i32*?%retval,?!dbg?!12??????????;??[#uses=1] >>???ret?i32?%retval1,?!dbg?!12 >>?} >>?declare?void?@llvm.dbg.declare(metadata,?metadata)?nounwind?readnone >>?!0?=?metadata?!{i32?459009,?metadata?!1,?metadata?!"j",?metadata?!2,?i32?1,?metadata?!5}?;?[?DW_TAG_arg_variable?] >>?!1?=?metadata?!{i32?458798,?i32?0,?metadata?!2,?metadata?!"h",?metadata?!"h",?metadata?!"h",?metadata?!2,?i32?1,?metadata?!3,?i1?false,?i1?true,?i32?0,?i32?0,?null,?i1?false}?;?[?DW_TAG_subprogram?] >>?!2?=?metadata?!{i32?458769,?i32?0,?i32?1,?metadata?!"simplecase.c",?metadata?!"/home/kecheng/cases/v2.7/simplecase/",?metadata?!"4.2.1?(Based?on?Apple?Inc.?build?5658)?(LLVM?build)",?i1?true,?i1?false,?metadata?!"",?i32?0}?;?[?DW_TAG_compile_unit?] >>?!3?=?metadata?!{i32?458773,?metadata?!2,?metadata?!"",?metadata?!2,?i32?0,?i64?0,?i64?0,?i64?0,?i32?0,?null,?metadata?!4,?i32?0,?null}?;?[?DW_TAG_subroutine_type?] >>?!4?=?metadata?!{metadata?!5,?metadata?!5,?metadata?!5} >>?!5?=?metadata?!{i32?458788,?metadata?!2,?metadata?!"int",?metadata?!2,?i32?0,?i64?32,?i64?32,?i64?0,?i32?0,?i32?5}?;?[?DW_TAG_base_type?] >>?!6?=?metadata?!{i32?1,?i32?0,?metadata?!1,?null} >>?!7?=?metadata?!{i32?459009,?metadata?!1,?metadata?!"i",?metadata?!2,?i32?1,?metadata?!5}?;?[?DW_TAG_arg_variable?] >>?!8?=?metadata?!{i32?459008,?metadata?!9,?metadata?!"tmp",?metadata?!2,?i32?2,?metadata?!5}?;?[?DW_TAG_auto_variable?] >>?!9?=?metadata?!{i32?458763,?metadata?!1,?i32?1,?i32?0}?;?[?DW_TAG_lexical_block?] >>?!10?=?metadata?!{i32?1,?i32?0,?metadata?!9,?null} >>?!11?=?metadata?!{i32?3,?i32?0,?metadata?!9,?null} >>?!12?=?metadata?!{i32?4,?i32?0,?metadata?!9,?null} >> >>?Best, >> >>?Kecheng >>?2010-05-13 >>?_______________________________________________ >>?LLVM?Developers?mailing?list >>?LLVMdev at cs.uiuc.edu?????????http://llvm.cs.uiuc.edu >>?http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> From o.j.sivart at gmail.com Thu May 13 19:02:46 2010 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Fri, 14 May 2010 09:32:46 +0930 Subject: [LLVMdev] Thread local global support in ExecutionEngine::getPointerToFunction() [was Re: Handling of thread_local globals by llc -march=cpp] In-Reply-To: References: <12289A08-7EC8-4DC0-AF27-6297D46AA2C4@gmail.com> <950DAF02-355E-4514-A020-255A356783E8@gmail.com> Message-ID: Hi all, Following on from "Handling of thread_local globals by llc -march=cpp" I thought I'd repost queries that lead on from this under a more appropriate new title. My query now is does ExecutionEngine::getPointerToFunction() and related support thread local global storage. Thread local storage is supported by clang, both in bc generation, assembly generation, and machine code, thus LLVM clearly has working support for thread local global storage. However in the case of On 14/05/2010, at 5:23 AM, Anton Korobeynikov wrote: >> I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and machine code that has segment register offset addressing. > Maybe TLS stuff is just broken inside JIT? > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University From kecheng at cecs.pdx.edu Thu May 13 20:18:42 2010 From: kecheng at cecs.pdx.edu (=?utf-8?B?S2VjaGVuZw==?=) Date: Thu, 13 May 2010 17:18:42 -0800 Subject: [LLVMdev] =?utf-8?q?How_to_get_the_variable_mapping_between_the_s?= =?utf-8?q?ourceandllvm_bytecode?= References: <201005131347419526312@cecs.pdx.edu>, <201005131600270468874@cecs.pdx.edu> Message-ID: <201005131718376241914@cecs.pdx.edu> Eli, Thanks very much for your reply. That's what I want to know. It works for this example. But I usually have to deal with the optimized bytecode with "-O". See the example: ************** C source ************** int h (int j, int i) { int tmp; tmp = j+i+2; return tmp; } +++++++++++++++++++++++++++++++++++++ .ll file: ; ModuleID = 'simplecase.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" define i32 @h(i32 %j, i32 %i) nounwind readnone { entry: %0 = add nsw i32 %j, 2, !dbg !0 ; [#uses=1] %1 = add nsw i32 %0, %i, !dbg !0 ; [#uses=1] ret i32 %1, !dbg !7 } !0 = metadata !{i32 3, i32 0, metadata !1, null} !1 = metadata !{i32 458763, metadata !2, i32 1, i32 0} ; [ DW_TAG_lexical_block ] !2 = metadata !{i32 458798, i32 0, metadata !3, metadata !"h", metadata !"h", metadata !"h", metadata !3, i32 1, metadata !4, i1 false, i1 true, i32 0, i32 0, null, i1 false} ; [ DW_TAG_subprogram ] !3 = metadata !{i32 458769, i32 0, i32 1, metadata !"simplecase.c", metadata !"/home/kecheng/cases/v2.7/simplecase/", metadata !"4.2.1 (Based on Apple Inc. build 5658) (LLVM build)", i1 true, i1 true, metadata !"", i32 0} ; [ DW_TAG_compile_unit ] !4 = metadata !{i32 458773, metadata !3, metadata !"", metadata !3, i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !5, i32 0, null} ; [ DW_TAG_subroutine_type ] !5 = metadata !{metadata !6, metadata !6, metadata !6} !6 = metadata !{i32 458788, metadata !3, metadata !"int", metadata !3, i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] !7 = metadata !{i32 4, i32 0, metadata !1, null} +++++++++++++++++++++++++++++++++++++ Now the mapping will be tmp <---->%1. We can't derive the mapping based on "alloca/store" instruction. Best, Kecheng 2010-05-13 From? Eli Friedman Date? 2010-05-13 16:58:05 To? Kecheng Cc? llvmdev Subject? Re: Re: [LLVMdev] How to get the variable mapping between the sourceandllvm bytecode On Thu, May 13, 2010 at 4:00 PM, Kecheng wrote: > Hi, > > I want to get the mapping between C source's variables and bytecode > variables. It seems that llvm doesn't provide this mapping, so I think a > walk-around method is to get the instruction's mapping. I have to use > llvm-gcc, not clang. Any advice? Thanks. "int tmp;" corresponds to "%tmp = alloca i32" in the IR. You can pull that mapping out of the appropriate llvm.dbg.declare call. To find assignments to the variable, look for store instructions which store into "%tmp". I fail to see what the addition has to do with anything in this context. -Eli > Best, > > ________________________________ > Kecheng > 2010-05-13 > ________________________________ > From? Eli Friedman > Date? 2010-05-13 15:38:36 > To? Kecheng > Cc? llvmdev > Subject? Re: [LLVMdev] How to get the variable mapping between the source > andllvm bytecode > > On Thu, May 13, 2010 at 1:47 PM, Kecheng wrote: >> Hi, >> >> I want to know the variable mapping between the source and llvm bytecode. It >> seems that current llvm debugging information cannot provide this mapping >> directly. >> >> Here is my examples (llvm 2.7). In this exmaple, I want to know the mapping: >> tmp<--->%4. But current llvm's debugging information can only provide that >> the instruction "%4 = add nsw i32 %3, 2" is at line 3 in the C source. But >> since there're two "+" at line 3, I don't have a direct way to know which >> "+" is mapped to this "add". Is there any way I can derive the mapping based >> on current ddg infor? Thanks. > You want to map the "+" in the source to a specific "add" instruction? > clang does provide column number info, though, which might help a > bit. In general, though, debug info isn't rich enough to provide that > sort of mapping. What are you trying to do? > -Eli >> ************** >> C source >> ************** >> int h (int j, int i) { >> int tmp; >> tmp = j+i+2; >> return tmp; >> } >> >> ************** >> .ll file >> ************** >> ; ModuleID = 'simplecase.c' >> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" >> target triple = "x86_64-unknown-linux-gnu" >> define i32 @h(i32 %j, i32 %i) nounwind { >> entry: >> %j_addr = alloca i32 ; [#uses=2] >> %i_addr = alloca i32 ; [#uses=2] >> %retval = alloca i32 ; [#uses=2] >> %0 = alloca i32 ; [#uses=2] >> %tmp = alloca i32 ; [#uses=2] >> %"alloca point" = bitcast i32 0 to i32 ; [#uses=0] >> call void @llvm.dbg.declare(metadata !{i32* %j_addr}, metadata !0), !dbg !6 >> store i32 %j, i32* %j_addr >> call void @llvm.dbg.declare(metadata !{i32* %i_addr}, metadata !7), !dbg !6 >> store i32 %i, i32* %i_addr >> call void @llvm.dbg.declare(metadata !{i32* %tmp}, metadata !8), !dbg !10 >> %1 = load i32* %j_addr, align 4, !dbg !11 ; [#uses=1] >> %2 = load i32* %i_addr, align 4, !dbg !11 ; [#uses=1] >> %3 = add nsw i32 %1, %2, !dbg !11 ; [#uses=1] >> %4 = add nsw i32 %3, 2, !dbg !11 ; [#uses=1] >> store i32 %4, i32* %tmp, align 4, !dbg !11 >> %5 = load i32* %tmp, align 4, !dbg !12 ; [#uses=1] >> store i32 %5, i32* %0, align 4, !dbg !12 >> %6 = load i32* %0, align 4, !dbg !12 ; [#uses=1] >> store i32 %6, i32* %retval, align 4, !dbg !12 >> br label %return, !dbg !12 >> return: ; preds = %entry >> %retval1 = load i32* %retval, !dbg !12 ; [#uses=1] >> ret i32 %retval1, !dbg !12 >> } >> declare void @llvm.dbg.declare(metadata, metadata) nounwind readnone >> !0 = metadata !{i32 459009, metadata !1, metadata !"j", metadata !2, i32 1, metadata !5} ; [ DW_TAG_arg_variable ] >> !1 = metadata !{i32 458798, i32 0, metadata !2, metadata !"h", metadata !"h", metadata !"h", metadata !2, i32 1, metadata !3, i1 false, i1 true, i32 0, i32 0, null, i1 false} ; [ DW_TAG_subprogram ] >> !2 = metadata !{i32 458769, i32 0, i32 1, metadata !"simplecase.c", metadata !"/home/kecheng/cases/v2.7/simplecase/", metadata !"4.2.1 (Based on Apple Inc. build 5658) (LLVM build)", i1 true, i1 false, metadata !"", i32 0} ; [ DW_TAG_compile_unit ] >> !3 = metadata !{i32 458773, metadata !2, metadata !"", metadata !2, i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !4, i32 0, null} ; [ DW_TAG_subroutine_type ] >> !4 = metadata !{metadata !5, metadata !5, metadata !5} >> !5 = metadata !{i32 458788, metadata !2, metadata !"int", metadata !2, i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] >> !6 = metadata !{i32 1, i32 0, metadata !1, null} >> !7 = metadata !{i32 459009, metadata !1, metadata !"i", metadata !2, i32 1, metadata !5} ; [ DW_TAG_arg_variable ] >> !8 = metadata !{i32 459008, metadata !9, metadata !"tmp", metadata !2, i32 2, metadata !5} ; [ DW_TAG_auto_variable ] >> !9 = metadata !{i32 458763, metadata !1, i32 1, i32 0} ; [ DW_TAG_lexical_block ] >> !10 = metadata !{i32 1, i32 0, metadata !9, null} >> !11 = metadata !{i32 3, i32 0, metadata !9, null} >> !12 = metadata !{i32 4, i32 0, metadata !9, null} >> >> Best, >> >> Kecheng >> 2010-05-13 >> _______________________________________________ >> 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/20100513/19ad8619/attachment.html From o.j.sivart at gmail.com Thu May 13 19:21:06 2010 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Fri, 14 May 2010 09:51:06 +0930 Subject: [LLVMdev] Thread local global support in ExecutionEngine::getPointerToFunction() [was Re: Handling of thread_local globals by llc -march=cpp] In-Reply-To: <950DAF02-355E-4514-A020-255A356783E8@gmail.com> References: <12289A08-7EC8-4DC0-AF27-6297D46AA2C4@gmail.com> <950DAF02-355E-4514-A020-255A356783E8@gmail.com> Message-ID: <4ED814C4-D3AE-45D3-A9F6-4C19C0A2C496@gmail.com> Hi all, Following on from "Handling of thread_local globals by llc -march=cpp" I thought I'd repost queries that lead on from this under a more appropriate new title. My query now is does ExecutionEngine::getPointerToFunction(), and related, support thread local global storage? Thread local storage is supported by clang, both in bc generation (it produces thread_local syntax), assembly generation (it produces segment register offset addressing), and machine code, thus LLVM clearly has working support for thread local global storage. However in the case of creating IR directly via calls into the LLVM api it appears that ExecutionEngine::getPointerToFunction() and related may not handle functions that reference thread local global storage. The reason I say this is captured in the details of one of my previous emails which are as follows. In my simple test program, replacing the following line of code: GlobalVariable* global = new GlobalVariable(*MyModule, IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global"); with the following line of code: GlobalVariable* global = new GlobalVariable(*MyModule, IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global", 0, true); in order to create a thread local global variable instead of a standard global variable causes the function (which uses the global) produced by the following line of code: void *FPtr = MyExecutionEngine->getPointerToFunction(MyFunction); to segfault when I call it in the following sequence of code: int (*FP)() = (int (*)())FPtr; int res = FP(); when the function executes correctly in the case of instead having created a standard global variable. On 14/05/2010, at 12:05 AM, o.j.sivart at gmail.com wrote: > I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and machine code that has segment register offset addressing. > > On 13/05/2010, at 9:26 PM, o.j.sivart at gmail.com wrote: > >> target triple = "i386-pc-linux-gnu" >> >> On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote: >> >>>> int (*FP)() = (int (*)())FPtr; >>>> int res = FP(); >>>> >>>> when the function executes correctly in the case of instead having created a standard global variable. >>> What is the platform you're running the code on? >>> >>> -- >>> With best regards, Anton Korobeynikov >>> Faculty of Mathematics and Mechanics, Saint Petersburg State University >> > From rnk at mit.edu Thu May 13 19:41:01 2010 From: rnk at mit.edu (Reid Kleckner) Date: Thu, 13 May 2010 20:41:01 -0400 Subject: [LLVMdev] How to get the variable mapping between the sourceandllvm bytecode In-Reply-To: <201005131718376241914@cecs.pdx.edu> References: <201005131347419526312@cecs.pdx.edu> <201005131600270468874@cecs.pdx.edu> <201005131718376241914@cecs.pdx.edu> Message-ID: The current situation is that LLVM's optimizations don't go out of their way to preserve debug info, so you are only going to be able to create the variable mapping with unoptimized IR. Reid On Thu, May 13, 2010 at 9:18 PM, Kecheng wrote: > Eli, > > Thanks very much?for your reply. That's what I want to know. It works for > this example. But I usually?have to deal with the optimized?bytecode with > "-O". > See the example: > > > ************** > C?source > ************** > int?h?(int?j,?int?i)?{ > ????int?tmp; > ????tmp?=?j+i+2; > ????return?tmp; > } > > +++++++++++++++++++++++++++++++++++++ > .ll file: > > > ;?ModuleID?=?'simplecase.c' > target?datalayout?=?"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" > target?triple?=?"x86_64-unknown-linux-gnu" > define?i32?@h(i32?%j,?i32?%i)?nounwind?readnone?{ > entry: > ??%0?=?add?nsw?i32?%j,?2,?!dbg?!0?????????????????;??[#uses=1] > ??%1?=?add?nsw?i32?%0,?%i,?!dbg?!0????????????????;??[#uses=1] > ??ret?i32?%1,?!dbg?!7 > } > !0?=?metadata?!{i32?3,?i32?0,?metadata?!1,?null} > !1?=?metadata?!{i32?458763,?metadata?!2,?i32?1,?i32?0}?;?[?DW_TAG_lexical_block?] > !2?=?metadata?!{i32?458798,?i32?0,?metadata?!3,?metadata?!"h",?metadata?!"h",?metadata?!"h",?metadata?!3,?i32?1,?metadata?!4,?i1?false,?i1?true,?i32?0,?i32?0,?null,?i1?false}?;?[?DW_TAG_subprogram?] > !3?=?metadata?!{i32?458769,?i32?0,?i32?1,?metadata?!"simplecase.c",?metadata?!"/home/kecheng/cases/v2.7/simplecase/",?metadata?!"4.2.1?(Based?on?Apple?Inc.?build?5658)?(LLVM?build)",?i1?true,?i1?true,?metadata?!"",?i32?0}?;?[?DW_TAG_compile_unit?] > !4?=?metadata?!{i32?458773,?metadata?!3,?metadata?!"",?metadata?!3,?i32?0,?i64?0,?i64?0,?i64?0,?i32?0,?null,?metadata?!5,?i32?0,?null}?;?[?DW_TAG_subroutine_type?] > !5?=?metadata?!{metadata?!6,?metadata?!6,?metadata?!6} > !6?=?metadata?!{i32?458788,?metadata?!3,?metadata?!"int",?metadata?!3,?i32?0,?i64?32,?i64?32,?i64?0,?i32?0,?i32?5}?;?[?DW_TAG_base_type?] > !7?=?metadata?!{i32?4,?i32?0,?metadata?!1,?null} > +++++++++++++++++++++++++++++++++++++ > > Now the mapping will be tmp <---->%1. We can't derive the mapping based on > "alloca/store" instruction. > > > > Best, > > > > ________________________________ > Kecheng > 2010-05-13 > ________________________________ > From? Eli Friedman > Date? 2010-05-13?16:58:05 > To? Kecheng > Cc? llvmdev > Subject? Re: Re: [LLVMdev] How to get the variable mapping between the > sourceandllvm bytecode > > On?Thu,?May?13,?2010?at?4:00?PM,?Kecheng??wrote: >>?Hi, >> >>?I?want?to?get?the?mapping?between?C?source's?variables?and?bytecode >>?variables.??It?seems?that?llvm?doesn't?provide?this?mapping,?so?I?think?a >>?walk-around?method?is?to?get?the?instruction's?mapping.?I?have?to?use >>?llvm-gcc,?not?clang.?Any?advice??Thanks. > "int?tmp;"?corresponds?to?"%tmp?=?alloca?i32"?in?the?IR.??You?can?pull > that?mapping?out?of?the?appropriate?llvm.dbg.declare?call.??To?find > assignments?to?the?variable,?look?for?store?instructions?which?store > into?"%tmp".??I?fail?to?see?what?the?addition?has?to?do?with?anything > in?this?context. > -Eli >>?Best, >> >>?________________________________ >>?Kecheng >>?2010-05-13 >>?________________________________ >>?From??Eli?Friedman >>?Date??2010-05-13?15:38:36 >>?To??Kecheng >>?Cc??llvmdev >>?Subject??Re:?[LLVMdev]?How?to?get?the?variable?mapping?between?the?source >>?andllvm?bytecode >> >>?On?Thu,?May?13,?2010?at?1:47?PM,?Kecheng??wrote: >>>?Hi, >>> >>>?I?want?to?know?the?variable?mapping?between?the?source?and?llvm?bytecode.?It >>>?seems?that?current?llvm?debugging?information?cannot?provide?this?mapping >>>?directly. >>> >>>?Here?is?my?examples?(llvm?2.7).?In?this?exmaple,?I?want?to?know?the?mapping: >>>?tmp<--->%4.?But?current?llvm's?debugging?information?can?only?provide?that >>>?the?instruction?"%4?=?add?nsw?i32?%3,?2"?is?at?line?3?in?the?C?source.?But >>>?since?there're?two?"+"?at?line?3,?I?don't?have?a?direct?way?to?know?which >>>?"+"?is?mapped?to?this?"add".?Is?there?any?way?I?can?derive?the?mapping?based >>>?on?current?ddg?infor??Thanks. >>?You?want?to?map?the?"+"?in?the?source?to?a?specific?"add"?instruction? >>??clang?does?provide?column?number?info,?though,?which?might?help?a >>?bit.??In?general,?though,?debug?info?isn't?rich?enough?to?provide?that >>?sort?of?mapping.??What?are?you?trying?to?do? >>?-Eli >>>?************** >>>?C?source >>>?************** >>>?int?h?(int?j,?int?i)?{ >>>?????int?tmp; >>>?????tmp?=?j+i+2; >>>?????return?tmp; >>>?} >>> >>>?************** >>>?.ll?file >>>?************** >>>?;?ModuleID?=?'simplecase.c' >>>?target?datalayout?=?"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" >>>?target?triple?=?"x86_64-unknown-linux-gnu" >>>?define?i32?@h(i32?%j,?i32?%i)?nounwind?{ >>>?entry: >>>???%j_addr?=?alloca?i32????????????????????????????;??[#uses=2] >>>???%i_addr?=?alloca?i32????????????????????????????;??[#uses=2] >>>???%retval?=?alloca?i32????????????????????????????;??[#uses=2] >>>???%0?=?alloca?i32?????????????????????????????????;??[#uses=2] >>>???%tmp?=?alloca?i32???????????????????????????????;??[#uses=2] >>>???%"alloca?point"?=?bitcast?i32?0?to?i32??????????;??[#uses=0] >>>???call?void?@llvm.dbg.declare(metadata?!{i32*?%j_addr},?metadata?!0),?!dbg?!6 >>>???store?i32?%j,?i32*?%j_addr >>>???call?void?@llvm.dbg.declare(metadata?!{i32*?%i_addr},?metadata?!7),?!dbg?!6 >>>???store?i32?%i,?i32*?%i_addr >>>???call?void?@llvm.dbg.declare(metadata?!{i32*?%tmp},?metadata?!8),?!dbg?!10 >>>???%1?=?load?i32*?%j_addr,?align?4,?!dbg?!11???????;??[#uses=1] >>>???%2?=?load?i32*?%i_addr,?align?4,?!dbg?!11???????;??[#uses=1] >>>???%3?=?add?nsw?i32?%1,?%2,?!dbg?!11???????????????;??[#uses=1] >>>???%4?=?add?nsw?i32?%3,?2,?!dbg?!11????????????????;??[#uses=1] >>>???store?i32?%4,?i32*?%tmp,?align?4,?!dbg?!11 >>>???%5?=?load?i32*?%tmp,?align?4,?!dbg?!12??????????;??[#uses=1] >>>???store?i32?%5,?i32*?%0,?align?4,?!dbg?!12 >>>???%6?=?load?i32*?%0,?align?4,?!dbg?!12????????????;??[#uses=1] >>>???store?i32?%6,?i32*?%retval,?align?4,?!dbg?!12 >>>???br?label?%return,?!dbg?!12 >>>?return:???????????????????????????????????????????;?preds?=?%entry >>>???%retval1?=?load?i32*?%retval,?!dbg?!12??????????;??[#uses=1] >>>???ret?i32?%retval1,?!dbg?!12 >>>?} >>>?declare?void?@llvm.dbg.declare(metadata,?metadata)?nounwind?readnone >>>?!0?=?metadata?!{i32?459009,?metadata?!1,?metadata?!"j",?metadata?!2,?i32?1,?metadata?!5}?;?[?DW_TAG_arg_variable?] >>>?!1?=?metadata?!{i32?458798,?i32?0,?metadata?!2,?metadata?!"h",?metadata?!"h",?metadata?!"h",?metadata?!2,?i32?1,?metadata?!3,?i1?false,?i1?true,?i32?0,?i32?0,?null,?i1?false}?;?[?DW_TAG_subprogram?] >>>?!2?=?metadata?!{i32?458769,?i32?0,?i32?1,?metadata?!"simplecase.c",?metadata?!"/home/kecheng/cases/v2.7/simplecase/",?metadata?!"4.2.1?(Based?on?Apple?Inc.?build?5658)?(LLVM?build)",?i1?true,?i1?false,?metadata?!"",?i32?0}?;?[?DW_TAG_compile_unit?] >>>?!3?=?metadata?!{i32?458773,?metadata?!2,?metadata?!"",?metadata?!2,?i32?0,?i64?0,?i64?0,?i64?0,?i32?0,?null,?metadata?!4,?i32?0,?null}?;?[?DW_TAG_subroutine_type?] >>>?!4?=?metadata?!{metadata?!5,?metadata?!5,?metadata?!5} >>>?!5?=?metadata?!{i32?458788,?metadata?!2,?metadata?!"int",?metadata?!2,?i32?0,?i64?32,?i64?32,?i64?0,?i32?0,?i32?5}?;?[?DW_TAG_base_type?] >>>?!6?=?metadata?!{i32?1,?i32?0,?metadata?!1,?null} >>>?!7?=?metadata?!{i32?459009,?metadata?!1,?metadata?!"i",?metadata?!2,?i32?1,?metadata?!5}?;?[?DW_TAG_arg_variable?] >>>?!8?=?metadata?!{i32?459008,?metadata?!9,?metadata?!"tmp",?metadata?!2,?i32?2,?metadata?!5}?;?[?DW_TAG_auto_variable?] >>>?!9?=?metadata?!{i32?458763,?metadata?!1,?i32?1,?i32?0}?;?[?DW_TAG_lexical_block?] >>>?!10?=?metadata?!{i32?1,?i32?0,?metadata?!9,?null} >>>?!11?=?metadata?!{i32?3,?i32?0,?metadata?!9,?null} >>>?!12?=?metadata?!{i32?4,?i32?0,?metadata?!9,?null} >>> >>>?Best, >>> >>>?Kecheng >>>?2010-05-13 >>>?_______________________________________________ >>>?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 deeppatel1987 at gmail.com Thu May 13 20:23:09 2010 From: deeppatel1987 at gmail.com (Sandeep Patel) Date: Fri, 14 May 2010 01:23:09 +0000 Subject: [LLVMdev] Returning big vectors on ARM broke in rev 103411 In-Reply-To: <8DE1686D-6922-4E95-B0F8-CD71E00A3E45@apple.com> References: <39E9E98DF632C2469FF2FC07853B70C60560E0E8@ZIPPY.Emea.Arm.com> <8DE1686D-6922-4E95-B0F8-CD71E00A3E45@apple.com> Message-ID: It used to. I just checked with r90370. deep On Thu, May 13, 2010 at 11:53 PM, Evan Cheng wrote: > I don't think this has ever worked. > > Evan > > On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: > >> I think this test case demonstrates it: >> >> ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s >> >> define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { >> ; CHECK: vadd.i64 >> ?%y = add <4 x i64> %a, %b >> ?ret <4 x i64> %y >> } >> >> (I hope I got that right.) >> >> >> >> -- >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. ?Thank you. >> >> _______________________________________________ >> 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 noviceup at gmail.com Thu May 13 22:18:42 2010 From: noviceup at gmail.com (lucefe) Date: Fri, 14 May 2010 11:18:42 +0800 Subject: [LLVMdev] How to get a constant of some type? Message-ID: How to get a constant of some type? For exmple, get a constant 10 of Int32Ty. Perhaps it's a stupid question. Thank you very much in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100514/1da48d4e/attachment.html From criswell at illinois.edu Thu May 13 23:32:20 2010 From: criswell at illinois.edu (John Criswell) Date: Thu, 13 May 2010 22:32:20 -0600 Subject: [LLVMdev] How to get a constant of some type? In-Reply-To: References: Message-ID: <4BECD254.3060101@illinois.edu> lucefe wrote: > How to get a constant of some type? > > For exmple, get a constant 10 of Int32Ty. > > Perhaps it's a stupid question. Thank you very much in advance. Look at the documentation for the ConstantInt class. It should have a method to do this. -- John T. From evan.cheng at apple.com Fri May 14 02:30:09 2010 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 14 May 2010 00:30:09 -0700 Subject: [LLVMdev] Returning big vectors on ARM broke in rev 103411 In-Reply-To: References: <39E9E98DF632C2469FF2FC07853B70C60560E0E8@ZIPPY.Emea.Arm.com> <8DE1686D-6922-4E95-B0F8-CD71E00A3E45@apple.com> Message-ID: <921DD2FA-E08E-46F4-ADE7-0B34645BEB1A@apple.com> Ok, please file a bug. Evan On May 13, 2010, at 6:23 PM, Sandeep Patel wrote: > It used to. I just checked with r90370. > > deep > > On Thu, May 13, 2010 at 11:53 PM, Evan Cheng wrote: >> I don't think this has ever worked. >> >> Evan >> >> On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: >> >>> I think this test case demonstrates it: >>> >>> ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s >>> >>> define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { >>> ; CHECK: vadd.i64 >>> %y = add <4 x i64> %a, %b >>> ret <4 x i64> %y >>> } >>> >>> (I hope I got that right.) >>> >>> >>> >>> -- >>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. >>> >>> _______________________________________________ >>> 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 j.wilhelmy at arcor.de Fri May 14 07:58:57 2010 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Fri, 14 May 2010 14:58:57 +0200 Subject: [LLVMdev] vector optimization Message-ID: <4BED4911.2020505@arcor.de> Hi! Is there a pass that optimizes vector operations? If I have for examle a sequence of shufflevector instructions that optimizes them? (in opencl notation e.g. a.xyzw.wzyx.xxxx -> a.wwww) -Jochen From jason.wangz at gmail.com Fri May 14 09:21:16 2010 From: jason.wangz at gmail.com (Zheng Wang) Date: Fri, 14 May 2010 15:21:16 +0100 Subject: [LLVMdev] type of the store operand Message-ID: Hiya, I want to know what's the type of the operand (value) along with the store instruction. For example, the following instruction store the content in an integer type pointer scevgep99.1 to the address another integer pointer points to. *"store i8* %scevgep99.1, i8** %scevgep92.1, align 4"* It seems there is no APIs in StoreInst can do this. Is there any way to figure the type of the operand of the store instruction? ----------------------------------- %scevgep92.1 = bitcast i8* %scevgep.1 to i8** ; [#uses=1] %tmp96.1 = mul i32 %36, %41 ; [#uses=1] %tmp97.1 = add i32 %tmp96.1, 32 ; [#uses=1] %tmp98.1 = add i32 %tmp97.1, %61 ; [#uses=1] %scevgep99.1 = getelementptr i8* %56, i32 %tmp98.1 ; [#uses=1] store i8* %scevgep99.1, i8** %scevgep92.1, align 4 %scevgep.2 = getelementptr i8* %0, i32 112 ; [#uses=1] %scevgep92.2 = bitcast i8* %scevgep.2 to i8** ; [#uses=1] Cheers, Zheng From criswell at uiuc.edu Fri May 14 09:33:57 2010 From: criswell at uiuc.edu (John Criswell) Date: Fri, 14 May 2010 09:33:57 -0500 Subject: [LLVMdev] type of the store operand In-Reply-To: References: Message-ID: <4BED5F55.5000308@uiuc.edu> Zheng Wang wrote: > Hiya, > > I want to know what's the type of the operand (value) along with the > store instruction. For example, the following instruction store the > content in an integer type pointer scevgep99.1 to the address another > integer pointer points to. > > *"store i8* %scevgep99.1, i8** %scevgep92.1, align 4"* > > It seems there is no APIs in StoreInst can do this. > > Is there any way to figure the type of the operand of the store instruction? > You can do this by first using getOperand() to get the operand of the store instruction which interests you and then calling getType() on the resulting Value * to get the type of the value being stored. It'll look something like this if SI is a pointer to a StoreInst object and i is the index of the operand being stored to memory: SI->getOperand(i)->getType(); -- John T. > > ----------------------------------- > > %scevgep92.1 = bitcast i8* %scevgep.1 to i8** ; [#uses=1] > %tmp96.1 = mul i32 %36, %41 ; [#uses=1] > %tmp97.1 = add i32 %tmp96.1, 32 ; [#uses=1] > %tmp98.1 = add i32 %tmp97.1, %61 ; [#uses=1] > %scevgep99.1 = getelementptr i8* %56, i32 %tmp98.1 ; [#uses=1] > store i8* %scevgep99.1, i8** %scevgep92.1, align 4 > %scevgep.2 = getelementptr i8* %0, i32 112 ; [#uses=1] > %scevgep92.2 = bitcast i8* %scevgep.2 to i8** ; [#uses=1] > > Cheers, > Zheng > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From jason.wangz at gmail.com Fri May 14 10:50:10 2010 From: jason.wangz at gmail.com (Zheng Wang) Date: Fri, 14 May 2010 16:50:10 +0100 Subject: [LLVMdev] type of the store operand In-Reply-To: <4BED5F55.5000308@uiuc.edu> References: <4BED5F55.5000308@uiuc.edu> Message-ID: Hi John, Thanks. In this case, if I call getType(), it will return a pointer type. So, how do I know whether this is an pointer points to an integer address? On 14 May 2010 15:33, John Criswell wrote: > Zheng Wang wrote: >> >> Hiya, >> >> I want to know what's the type of the operand (value) along with the >> store instruction. For example, the following instruction store the >> content in an integer type pointer scevgep99.1 to the address another >> integer pointer points to. >> >> *"store i8* %scevgep99.1, i8** %scevgep92.1, align 4"* >> >> It seems there is no APIs in StoreInst can do this. >> >> Is there any way to figure the type of the operand of the store >> instruction? >> > > You can do this by first using getOperand() to get the operand of the store > instruction which interests you and then calling getType() on the resulting > Value * to get the type of the value being stored. > > It'll look something like this if SI is a pointer to a StoreInst object and > i is the index of the operand being stored to memory: > > SI->getOperand(i)->getType(); > > -- John T. > >> >> ----------------------------------- >> >> ?%scevgep92.1 = bitcast i8* %scevgep.1 to i8** ? ; [#uses=1] >> ?%tmp96.1 = mul i32 %36, %41 ? ? ? ? ? ? ? ? ? ? ; [#uses=1] >> ?%tmp97.1 = add i32 %tmp96.1, 32 ? ? ? ? ? ? ? ? ; [#uses=1] >> ?%tmp98.1 = add i32 %tmp97.1, %61 ? ? ? ? ? ? ? ?; [#uses=1] >> ?%scevgep99.1 = getelementptr i8* %56, i32 %tmp98.1 ; [#uses=1] >> ?store i8* %scevgep99.1, i8** %scevgep92.1, align 4 >> ?%scevgep.2 = getelementptr i8* %0, i32 112 ? ? ?; [#uses=1] >> ?%scevgep92.2 = bitcast i8* %scevgep.2 to i8** ? ; [#uses=1] >> >> Cheers, >> Zheng >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -- Best regards, WANG Zheng From anton at korobeynikov.info Fri May 14 11:19:00 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Fri, 14 May 2010 20:19:00 +0400 Subject: [LLVMdev] Returning big vectors on ARM broke in rev 103411 In-Reply-To: <921DD2FA-E08E-46F4-ADE7-0B34645BEB1A@apple.com> References: <39E9E98DF632C2469FF2FC07853B70C60560E0E8@ZIPPY.Emea.Arm.com> <8DE1686D-6922-4E95-B0F8-CD71E00A3E45@apple.com> <921DD2FA-E08E-46F4-ADE7-0B34645BEB1A@apple.com> Message-ID: > Ok, please file a bug. I'm bisecting -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From clattner at apple.com Fri May 14 11:21:55 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 14 May 2010 09:21:55 -0700 Subject: [LLVMdev] vector optimization In-Reply-To: <4BED4911.2020505@arcor.de> References: <4BED4911.2020505@arcor.de> Message-ID: <3D0B4E6D-CBC7-4BC8-A360-AE1ED5CFB137@apple.com> Instcombine does of this, late codegen also does some of it. -Chris On May 14, 2010, at 5:58 AM, Jochen Wilhelmy wrote: > Hi! > > Is there a pass that optimizes vector operations? > If I have for examle a sequence of shufflevector instructions > that optimizes them? > (in opencl notation e.g. a.xyzw.wzyx.xxxx -> a.wwww) > > -Jochen > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From mailtome200420032002 at yahoo.com Fri May 14 13:00:09 2010 From: mailtome200420032002 at yahoo.com (john blair) Date: Fri, 14 May 2010 11:00:09 -0700 (PDT) Subject: [LLVMdev] Building llvm using non-system gcc/binutils In-Reply-To: Message-ID: <779405.88553.qm@web53108.mail.re2.yahoo.com> Hi Eli, I tried to build llvm with gcc-4.4.3 and binutils-2.20.1. This time it failed with /build/toolchain/src/llvm-2.7/objdir/Release/bin/tblgen: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /build/toolchain/src/llvm-2.7/objdir/Release/bin/tblgen) make[1]: *** [/build/toolchain/src/llvm-2.7/objdir/lib/VMCore/Release/Intrinsics.gen.tmp] Error 1 make[1]: Leaving directory `/build/toolchain/src/llvm-2.7/objdir/lib/VMCore' make: *** [all] Error 1 Hmm, it shouldn't be looking for libstdc++ in /usr/lib --- On Thu, 5/13/10, Eli Friedman wrote: > From: Eli Friedman > Subject: Re: [LLVMdev] Building llvm using non-system gcc/binutils > To: "john blair" > Cc: llvmdev at cs.uiuc.edu > Date: Thursday, May 13, 2010, 1:00 PM > On Thu, May 13, 2010 at 12:28 PM, > john blair > > wrote: > > I am trying to build llvm-2.7 using non-system > gcc/binutils. My gcc version is 4.1.2, and binutils is > 2.17.50.0.15. I get the following errors > > That version of gcc is known to have issues building LLVM; > see > http://llvm.org/docs/GettingStarted.html#brokengcc > .? Try upgrading > your gcc version. > > -Eli > > > `.L2438' referenced in section > `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' > of > /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): > defined in discarded section > `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' > of > /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) > > .... > > .... > > make[1]: *** > [/build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVM-2.7.so] > Error 1 > > make[1]: Leaving directory > `/build/toolchain/src/llvm-2.7/objdir/tools/llvm-shlib' > > make: *** [all] Error 1 > > > > I configure it using > > export > PATH=/build/toolchain/lin32/binutils-2.17.50.0.15/bin:$PATH > > LDFLAGS=-L"/build/toolchain/lin32/gcc-4.1.2-8/lib" > CC=/build/toolchain/lin32/gcc-4.1.2/bin/gcc > CXX=/build/toolchain/lin32/gcc-4.1.2/bin/g++ > ../llvm-2.7/configure > > > > This works with 2.6. > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu > ? ? ? ? http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > From jvoung at google.com Fri May 14 13:24:40 2010 From: jvoung at google.com (Jan Voung) Date: Fri, 14 May 2010 11:24:40 -0700 Subject: [LLVMdev] selection dag speedups / llc speedups Message-ID: Hello folks, I'm sure this has been asked many times, but is there current work on decreasing the time taken by the DAG-based instruction selector, or the other phases of llc? I am just beginning to dive into LLVM, and I am interested in compile-time reductions that do not reduce code quality dramatically. For example, simply switching on "-fast-isel" (roughly 17% drop in code quality for some of my benchmarks) or "-regalloc=local/fast" (roughly 2x slower for some of my benchmarks) is, unfortunately, not an acceptable option. I noticed that a semi-recent commit added the "STATISTIC(NumDAGIselRetries,"Number of times dag isel has to try another path");" as well as a sorting change in DAGISelEmitter.cpp. This suggests to me that there is work being done. Are there other similar efforts, but perhaps aiming for bigger gains, that I should be aware of? From the other end, are there efforts to make the fast-path produce better quality code? Some small things I've noticed: - LegalizeVectors might not make a single change over an entire input bc file, yet it can take about 6% of the ISel time. Identifying that this can be skipped ahead of time may help? - We can take the Changed flag returned by LegalizeVectors, and pass it on to Legalize so that it can decide not to AssignTopologicalOrder again, since it was already done in the LegalizeVectors pass. However, this is a negligible reduction: 0.2 seconds shaved off a 30+ second compile =). - BuildSchedGraph() can take around 30% of the X% of time taken by Instruction Scheduling. How different is the scheduler graph from the selection graph? - Just as a random guess that this would not affect code quality terribly, I tried dynamically switching on -fast-isel for basic blocks of size one. This can cover about 10% of the basic blocks. The code-quality drop on a few benchmarks is neglible, but for spec's 483.xalancbmk it is quite dramatic. Also, any pointers to documentation, or description of the algorithm used by the Select() -> SelectCode() -> SelectCodeCommon() pass would be very helpful. Sorry for the long email, and many thanks in advance! - Jan Voung -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100514/16e1c9ea/attachment.html From eli.friedman at gmail.com Fri May 14 15:48:47 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 14 May 2010 13:48:47 -0700 Subject: [LLVMdev] Building llvm using non-system gcc/binutils In-Reply-To: <779405.88553.qm@web53108.mail.re2.yahoo.com> References: <779405.88553.qm@web53108.mail.re2.yahoo.com> Message-ID: The dynamic linker is somehow linking against the wrong libstdc++. Not sure why that's happening. Since it looks like the issue is unrelated to LLVM, you might want to try asking on the gcc-help mailing list. -Eli On Fri, May 14, 2010 at 11:00 AM, john blair wrote: > Hi Eli, > > I tried to build llvm with gcc-4.4.3 and binutils-2.20.1. This time it failed with > /build/toolchain/src/llvm-2.7/objdir/Release/bin/tblgen: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /build/toolchain/src/llvm-2.7/objdir/Release/bin/tblgen) > make[1]: *** [/build/toolchain/src/llvm-2.7/objdir/lib/VMCore/Release/Intrinsics.gen.tmp] Error 1 > make[1]: Leaving directory `/build/toolchain/src/llvm-2.7/objdir/lib/VMCore' > make: *** [all] Error 1 > > Hmm, it shouldn't be looking for libstdc++ in /usr/lib > > --- On Thu, 5/13/10, Eli Friedman wrote: > >> From: Eli Friedman >> Subject: Re: [LLVMdev] Building llvm using non-system gcc/binutils >> To: "john blair" >> Cc: llvmdev at cs.uiuc.edu >> Date: Thursday, May 13, 2010, 1:00 PM >> On Thu, May 13, 2010 at 12:28 PM, >> john blair >> >> wrote: >> > I am trying to build llvm-2.7 using non-system >> gcc/binutils. My gcc version is 4.1.2, and binutils is >> 2.17.50.0.15. I get the following errors >> >> That version of gcc is known to have issues building LLVM; >> see >> http://llvm.org/docs/GettingStarted.html#brokengcc >> .? Try upgrading >> your gcc version. >> >> -Eli >> >> > `.L2438' referenced in section >> `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' >> of >> /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): >> defined in discarded section >> `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' >> of >> /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) >> > .... >> > .... >> > make[1]: *** >> [/build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVM-2.7.so] >> Error 1 >> > make[1]: Leaving directory >> `/build/toolchain/src/llvm-2.7/objdir/tools/llvm-shlib' >> > make: *** [all] Error 1 >> > >> > I configure it using >> > export >> PATH=/build/toolchain/lin32/binutils-2.17.50.0.15/bin:$PATH >> > LDFLAGS=-L"/build/toolchain/lin32/gcc-4.1.2-8/lib" >> CC=/build/toolchain/lin32/gcc-4.1.2/bin/gcc >> CXX=/build/toolchain/lin32/gcc-4.1.2/bin/g++ >> ../llvm-2.7/configure >> > >> > This works with 2.6. >> > >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu >> ? ? ? ? http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> > > > > From j.wilhelmy at arcor.de Fri May 14 16:41:52 2010 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Fri, 14 May 2010 23:41:52 +0200 Subject: [LLVMdev] vector optimization In-Reply-To: <3D0B4E6D-CBC7-4BC8-A360-AE1ED5CFB137@apple.com> References: <4BED4911.2020505@arcor.de> <3D0B4E6D-CBC7-4BC8-A360-AE1ED5CFB137@apple.com> Message-ID: <4BEDC3A0.7070400@arcor.de> Hi! I found a "problem" in InstCombiner::visitShuffleVectorInst: The comment says that combining two shufflevectors only takes one of the original shuffles. At the line if (NewMask == LHSMask || NewMask == Mask) { I have NewMask = (1,1,1,1) LHSMask = (1,8,8,8) Mask = (0,0,0) Why is it important not to emit a new mask? If so, why not additionally test for splat masks (in my case (1,1,1,1))? How does the instcompine process work? If e.g. two swizzles get merged is the new one visited immediately again or in a new iteration of instcombine? What is if the instruction that is merged has more than one use? Is it allowed to combine chains of instructions at once (i.e. more than 2)? I'm asking these questions because it should be possible to write a generic combiner for shufflevector, insertelement and extract element that "looks through" all of these instructions to the values that are accessed. For a vector with 4 elements this is always a list with 4 llvm::values with an extractelement-index for each value. This list then can be analyzed again to produce a simpler chain of instructions. I have written such a thing for my virtual machine. The advantage is that I only need one procedure to emit the right thing from the list of value/index pairs. For example I detect if all values are the same and then if the indices are in consecutive order (0,1,2,3) and so on. Undefined values are NULL/-1 in the list. But at this point I can't "look through" instructions with more than one use since this can produce duplicate code. -Jochen From devang.patel at gmail.com Fri May 14 19:23:05 2010 From: devang.patel at gmail.com (Devang Patel) Date: Fri, 14 May 2010 17:23:05 -0700 Subject: [LLVMdev] How to get the variable mapping between the sourceandllvm bytecode In-Reply-To: <201005131718376241914@cecs.pdx.edu> References: <201005131347419526312@cecs.pdx.edu> <201005131600270468874@cecs.pdx.edu> <201005131718376241914@cecs.pdx.edu> Message-ID: > > Now the mapping will be tmp <---->%1. We can't derive the mapping based on > "alloca/store" instruction. If you try llvm-gcc from svn trunk then you'll see llvm.dbg.value intrinsic replacing llvm.dbg.declare intrinsic when alloca is lowered. However, as others have said, the optimizer does not guarantee that it will always be able to preserve variable info accurately. The real question is, why do you want to map tmp to %1 ? - Devang From simmon12 at cs.uiuc.edu Sat May 15 02:20:18 2010 From: simmon12 at cs.uiuc.edu (Patrick Alexander Simmons) Date: Sat, 15 May 2010 01:20:18 -0600 Subject: [LLVMdev] Is it possible to step through LLVM IR with GDB? Message-ID: <4BEE4B32.1080206@cs.uiuc.edu> Is it possible to compile LLVM source in such a way that it's possible to step through it with GDB (and hopefully frontends like DDD as well)? Thanks in advance, --Patrick From lhames at gmail.com Sat May 15 07:00:10 2010 From: lhames at gmail.com (Lang Hames) Date: Sat, 15 May 2010 22:00:10 +1000 Subject: [LLVMdev] Machine Verifier question. In-Reply-To: <450FF384-F134-4E77-9BA0-9E1EB8F7B2E0@2pi.dk> References: <450FF384-F134-4E77-9BA0-9E1EB8F7B2E0@2pi.dk> Message-ID: I just merged the last few days worth of mainline commits into my repo and this bug seems to have disappeared. If it was real it looks like it has been fixed. I'll keep an eye out for it though. - Lang. On Tue, May 11, 2010 at 2:56 AM, Jakob Stoklund Olesen wrote: > > On May 9, 2010, at 5:27 AM, Lang Hames wrote: > >> Running the following command, >> >> llc -asm-verbose=false -O3 Output/ReedSolomon.llvm.bc -o Output/ReedSolomon.llc.s -verify-machineinstrs >> >> in llvm-test/SingleSource/Benchmarks/Misc currently yields seven errors, all of the form >> >> *** Bad machine code: PHI operand is not live-out from predecessor *** >> - function: ? ?main >> - basic block: bb2.i.preheader 0x1ba7680 (BB#5) >> - instruction: %reg1032 = PHI %reg1280, , %reg1287, >> - operand 1: ? %reg1280 >> >> The code seems to run ok though. >> >> Is this something that's worth looking in to, or just over zealous reporting by the machine verifier? > > That sounds like a proper bug. Can you tell why %reg1280 is not live-out from BB#3? > > /jakob > > From baldrick at free.fr Sat May 15 07:22:14 2010 From: baldrick at free.fr (Duncan Sands) Date: Sat, 15 May 2010 14:22:14 +0200 Subject: [LLVMdev] Is it possible to step through LLVM IR with GDB? In-Reply-To: <4BEE4B32.1080206@cs.uiuc.edu> References: <4BEE4B32.1080206@cs.uiuc.edu> Message-ID: <4BEE91F6.3020502@free.fr> On 15/05/10 09:20, Patrick Alexander Simmons wrote: > Is it possible to compile LLVM source in such a way that it's possible > to step through it with GDB (and hopefully frontends like DDD as well)? Configure with --disable-optimized Ciao, Duncan. From prakash.prabhu at gmail.com Sat May 15 12:53:25 2010 From: prakash.prabhu at gmail.com (Prakash Prabhu) Date: Sat, 15 May 2010 13:53:25 -0400 Subject: [LLVMdev] [cfe-dev] Question about UnreachableInst and exit() system call In-Reply-To: References: Message-ID: Hi Chris, Thanks for the reply. Right now, I disabled the doesNotReturn() check in the code for emitting calls in clang (CGCall) and also disabled running simplifycfg/prune-eh passes that introduce UnreachableInst after exit(). The main issue is that the particular transform pass that I am using in our backend does not yet support multiple loop exits and common case where this issue arises is when there are exit() calls inside the loop. With the above change, -loopsimplify is able to transform all loops (that i have tested) that have exit() calls within them to have single loop exits. But, as you said, this kind of change is fragile and also gives up on some scalar optimization opportunities. I guess the right solution in the long term would be to add support for multiple loop exits in the custom transform pass. regards, Prakash On Sat, May 15, 2010 at 1:32 AM, Chris Lattner wrote: > > On May 13, 2010, at 11:48 PM, Prakash Prabhu wrote: > > > Hi, > > > > I have a question about how clang handles exit() calls. It seems that > two instructions (when -emit-llvm is used) are generated : CallInst followed > by UnreachableInst. While this makes perfect sense from > semantics/optimization/correctness perspective, I am curious to know whether > it is possible to treat exit() like any other library call (ie, generate a > BranchInst instead of UnreachableInst) via a compile time switch/option ? > Any pointers to the relevant code (for handling exit()) within clang will > also be very helpful. > > > > I am asking because some of the analysis I am writing in the backend > would be easier if I did not have to deal with exit() as a special case > (mainly to do with structured control flow). > > Hi Prakash, > > It's generally better to send questions about LLVM IR to the llvmdev list. > In this case, I'm not really sure. It sounds like you should handle > general LLVM IR. Trying to special case things is a recipe for fragile > code. > > -Chris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100515/8160edb8/attachment.html From jameswang99 at yahoo.com Sat May 15 23:44:21 2010 From: jameswang99 at yahoo.com (Cong Wang) Date: Sat, 15 May 2010 23:44:21 -0500 Subject: [LLVMdev] How to access the return value of a CallInst Message-ID: Hi all: I am trying to get the return value of a call instruction that I inserted during the optimization pass I wrote. I have something like the following: CallInst *InitCall = CallInst::Create(InitFn, Args.begin(), Args.end(), "log_load_addr_ret", LI); CastInst *InsertedCast = CastInst::CreateTruncOrBitCast(InitCall.getCalledValue(), LI->getType(), "return_load", LI); I assume that getCalledValue() will give me the return value of the InitCall CallInst. This compiles fine. But the CastInst cannot be created. The runtime error is : opt: /panfs/panasas-01.cs.wisc.edu/scratch/wang/LLVM/src/llvm/lib/VMCore/Instructions.cpp:2338: llvm::TruncInst::TruncInst(llvm::Value*, const llvm::Type*, const llvm::Twine&, llvm::Instruction*): Assertion `castIsValid(getOpcode(), S, Ty) && "Illegal Trunc"' failed. 0 opt 0x000000000084e8bf 1 opt 0x000000000084f37a 2 libpthread.so.0 0x000000310ac0e930 3 libc.so.6 0x000000310a030265 gsignal + 53 4 libc.so.6 0x000000310a031d10 abort + 272 5 libc.so.6 0x000000310a0296e6 __assert_fail + 246 6 opt 0x00000000007aad58 7 opt 0x00000000007aae33 llvm::CastInst::Create(llvm::Instruction::CastOps, llvm::Value*, llvm::Type const*, llvm::Twine const&, llvm::Instruction*) + 211 8 opt 0x00000000004f4695 llvm::RSProfilers_std::InstrumentLoadStoreInBlock(llvm::BasicBlock*, llvm::GlobalValue*, llvm::GlobalValue*, llvm::GlobalValue*, llvm::GlobalValue*, llvm::GlobalValue*, llvm::GlobalValue*) + 4101 9 opt 0x00000000004ecb3f 10 opt 0x00000000007d5140 llvm::MPPassManager::runOnModule(llvm::Module&) + 464 11 opt 0x00000000007d76b5 llvm::PassManagerImpl::run(llvm::Module&) + 149 12 opt 0x00000000007d778d llvm::PassManager::run(llvm::Module&) + 13 13 opt 0x000000000049c68b main + 2315 14 libc.so.6 0x000000310a01d994 __libc_start_main + 244 15 opt 0x0000000000492759 __gxx_personality_v0 + 393 The goal of all this is to convert the return value to some other form. The return value is always 64 bit int but I from time to time needs other form, such a 32 bit int. Thanks for any input in advance. -- Regards James Wang .-- .- -. --. @ -.-. ... .-.-.- .-- .. ... -.-. .-.-.- . -.. ..- From criswell at illinois.edu Sun May 16 09:17:17 2010 From: criswell at illinois.edu (John Criswell) Date: Sun, 16 May 2010 08:17:17 -0600 Subject: [LLVMdev] How to access the return value of a CallInst In-Reply-To: References: Message-ID: <4BEFFE6D.1040103@illinois.edu> Cong Wang wrote: > Hi all: > I am trying to get the return value of a call instruction that I > inserted during the optimization pass I wrote. I have something like > the following: > The CallInst is its return value. They are one and the same. Replace "InitCall.getCalledValue()" with "InitCall" in the CastInst::CreateTruncOrBitCast call, and it should work. -- John T. > CallInst *InitCall = CallInst::Create(InitFn, Args.begin(), Args.end(), > "log_load_addr_ret", LI); > CastInst *InsertedCast = > CastInst::CreateTruncOrBitCast(InitCall.getCalledValue(), > LI->getType(), "return_load", LI); > > I assume that getCalledValue() will give me the return value of the > InitCall CallInst. > This compiles fine. > But the CastInst cannot be created. The runtime error is : > opt: /panfs/panasas-01.cs.wisc.edu/scratch/wang/LLVM/src/llvm/lib/VMCore/Instructions.cpp:2338: > llvm::TruncInst::TruncInst(llvm::Value*, const llvm::Type*, const > llvm::Twine&, llvm::Instruction*): Assertion `castIsValid(getOpcode(), > S, Ty) && "Illegal Trunc"' failed. > 0 opt 0x000000000084e8bf > 1 opt 0x000000000084f37a > 2 libpthread.so.0 0x000000310ac0e930 > 3 libc.so.6 0x000000310a030265 gsignal + 53 > 4 libc.so.6 0x000000310a031d10 abort + 272 > 5 libc.so.6 0x000000310a0296e6 __assert_fail + 246 > 6 opt 0x00000000007aad58 > 7 opt 0x00000000007aae33 > llvm::CastInst::Create(llvm::Instruction::CastOps, llvm::Value*, > llvm::Type const*, llvm::Twine const&, llvm::Instruction*) + 211 > 8 opt 0x00000000004f4695 > llvm::RSProfilers_std::InstrumentLoadStoreInBlock(llvm::BasicBlock*, > llvm::GlobalValue*, llvm::GlobalValue*, llvm::GlobalValue*, > llvm::GlobalValue*, llvm::GlobalValue*, llvm::GlobalValue*) + 4101 > 9 opt 0x00000000004ecb3f > 10 opt 0x00000000007d5140 > llvm::MPPassManager::runOnModule(llvm::Module&) + 464 > 11 opt 0x00000000007d76b5 > llvm::PassManagerImpl::run(llvm::Module&) + 149 > 12 opt 0x00000000007d778d > llvm::PassManager::run(llvm::Module&) + 13 > 13 opt 0x000000000049c68b main + 2315 > 14 libc.so.6 0x000000310a01d994 __libc_start_main + 244 > 15 opt 0x0000000000492759 __gxx_personality_v0 + 393 > > > The goal of all this is to convert the return value to some other > form. The return value is always 64 bit int but I from time to time > needs other form, such a 32 bit int. > Thanks for any input in advance. > From javed.absar at gmail.com Sun May 16 11:07:56 2010 From: javed.absar at gmail.com (Javed Absar) Date: Sun, 16 May 2010 21:37:56 +0530 Subject: [LLVMdev] LLVM Valgrind Message-ID: Hi: I have been working on Valgrind [porting it to non-supported architectures] and wanted to know what you guys think of Valgrind for LLVM. I haven't thought through fully myself - so wanted to get your inputs before becoming rigid in my own opinion. Original Valgrind works on object code - translating the asm to its own IR [intermediate representation]. But for LLVM, probably putting the valgrind tool instrumentation [e.g. memcheck] as a pass [[i.e. using LLVM IR itself] probably make more sense.... cheers J. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100516/d7c1f0ec/attachment.html From criswell at illinois.edu Sun May 16 13:06:13 2010 From: criswell at illinois.edu (John Criswell) Date: Sun, 16 May 2010 12:06:13 -0600 Subject: [LLVMdev] LLVM Valgrind In-Reply-To: References: Message-ID: <4BF03415.7060208@illinois.edu> Javed Absar wrote: > Hi: > > I have been working on Valgrind [porting it to non-supported > architectures] and wanted to know what you guys think of Valgrind for > LLVM. > I haven't thought through fully myself - so wanted to get your inputs > before becoming rigid in my own opinion. > > Original Valgrind works on object code - translating the asm to its > own IR [intermediate representation]. But for LLVM, probably putting > the valgrind > tool instrumentation [e.g. memcheck] as a pass [[i.e. using LLVM IR > itself] probably make more sense.... We have done just that in the SAFECode project (http://safecode.cs.illinois.edu). To be more accurate, we took the old SAFECode research code, simplified it a bit (its more advanced features have experienced some bitrot; fixing that is on my TODO list), and enhanced it to use LLVM debugging information to report when a memory safety violation occurs. SAFECode is a bit like a combination of Valgrind's memcheck and exp-ptrcheck tools in that it checks array indexing operations as well as loads and stores. Additionally, SAFECode's array checking should be more accurate that Valgrind's because LLVM passes can determine the start address and size of stack objects and globals accurately whereas Valgrind's ptrcheck tool has to rely upon heuristics to determine this information. SAFECode is also faster since it can employ static analysis and does not do dynamic binary translation. All of that said, Valgrind is a much more mature piece of software. Optimization can weaken SAFECode's ability to provide good debug info when used with LLVM 2.6, and testing with LLVM 2.7's improved debug info API isn't done yet. Valgrind is also easier to use; SAFECode currently requires whole-program analysis, which means that you have to use it either on an LLVM bitcode file or through link-time optimization. If you're interested in SAFECode, please feel free to try it out. SAFECode works with LLVM 2.6 and LLVM 2.7 (although the 2.7 support needs some improvement yet). We have a mailing list (http://safecode.cs.illinois.edu/mailing.html) to which you can post questions. -- John T. > > cheers > J. From carlos.delalama at urjc.es Sun May 16 15:23:52 2010 From: carlos.delalama at urjc.es (=?ISO-8859-1?Q?Carlos_S=E1nchez_de_La_Lama?=) Date: Sun, 16 May 2010 22:23:52 +0200 Subject: [LLVMdev] Fixed register operations Message-ID: Hi all, is it possible to define an instruction as always having a certain register as operand in XXXInstrInfo.td? I know I can do it defining a single-register register class, but I need that register also to be on a broader class for other operations (and it is not possible for a reg to be in several classes AFAIU). Thanks! Carlos From simmon12 at illinois.edu Sun May 16 15:33:27 2010 From: simmon12 at illinois.edu (Patrick Simmons) Date: Sun, 16 May 2010 14:33:27 -0600 Subject: [LLVMdev] Is it possible to step through LLVM IR with GDB? In-Reply-To: <4BEE91F6.3020502@free.fr> References: <4BEE4B32.1080206@cs.uiuc.edu> <4BEE91F6.3020502@free.fr> Message-ID: <4BF05697.8010806@illinois.edu> On 05/15/10 06:22, Duncan Sands wrote: > On 15/05/10 09:20, Patrick Alexander Simmons wrote: > >> Is it possible to compile LLVM source in such a way that it's possible >> to step through it with GDB (and hopefully frontends like DDD as well)? >> > Configure with --disable-optimized > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > Sorry, I should have been more clear. I want to step through the LLVM IR of programs compiled with llc. --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 stoklund at 2pi.dk Sun May 16 15:43:45 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Sun, 16 May 2010 13:43:45 -0700 Subject: [LLVMdev] Fixed register operations In-Reply-To: References: Message-ID: On May 16, 2010, at 1:23 PM, Carlos S?nchez de La Lama wrote: > > is it possible to define an instruction as always having a certain > register as operand in XXXInstrInfo.td? I know I can do it defining a > single-register register class, but I need that register also to be on > a broader class for other operations (and it is not possible for a reg > to be in several classes AFAIU). A register can be in multiple register classes, no problem, but we try to avoid single-register classes. Look at how X86 handles the MUL and DIV instructions. There is some special code in X86DAGToDAGISel::Select as well. /jakob From stoklund at 2pi.dk Sun May 16 15:50:58 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Sun, 16 May 2010 13:50:58 -0700 Subject: [LLVMdev] Is it possible to step through LLVM IR with GDB? In-Reply-To: <4BEE4B32.1080206@cs.uiuc.edu> References: <4BEE4B32.1080206@cs.uiuc.edu> Message-ID: <751DE349-5CFB-4E41-9A7E-117E0C07137D@2pi.dk> On May 15, 2010, at 12:20 AM, Patrick Alexander Simmons wrote: > Is it possible to compile LLVM source in such a way that it's possible > to step through it with GDB (and hopefully frontends like DDD as well)? You would need to have debug info that refers to a .ll file instead of a .c file. That should be entirely possible, but nobody has written the code to generate such debug info yet. /jakob From davidterei at gmail.com Sun May 16 21:43:43 2010 From: davidterei at gmail.com (David Terei) Date: Mon, 17 May 2010 12:43:43 +1000 Subject: [LLVMdev] GHC's LLVM Backend Message-ID: Hi All, The Glasgow Haskell compiler has recently become an external user of LLVM. You can read about it here: http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html If you have any comments, questions or perhaps even advice on solving some of the issues that need to be fixed in the backend going forward then please reply to this email. Cheers, David From andrewl at lenharth.org Sun May 16 23:22:39 2010 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sun, 16 May 2010 23:22:39 -0500 Subject: [LLVMdev] Shadow returns Message-ID: I need to return i128 and f128 via a ptr passed in as the first argument to a function. I am not seeing something in llvm-abi.h to let me do this. How do I make a scalar (not an aggregate) use a shadow return? Similarly I need to pass those types by pointer, (byval arguments?) and don't see an obvious way to do that. Thanks Andrew From pocmatos at gmail.com Mon May 17 05:09:45 2010 From: pocmatos at gmail.com (Paulo J. Matos) Date: Mon, 17 May 2010 11:09:45 +0100 Subject: [LLVMdev] Backend for Harvard Architecture Message-ID: Hello, On a recent discussion on the cfe-dev mailing list[1] it was asked how easy it was to create a backend to an Harvard Arch chip: different data/function pointer sizes and 16 bit chars (main issues of the targeted arch). Ken Dyck has posted a patch (which solved at least the second problem of 16bit char) on which I have been working on and Douglas Gregor said that different pointer sizes are already supported by Clang, but what about llvm? When creating a backend, I have created the DataLayout string but this string only allows me (as far as the docs I found are concerned) to specify a pointer size (not several pointer sizes). Is this something that Clang already supports but has not yet managed to get into llvm or am I missing some configuration? Moreover, I can't find a detailed description of this string anywhere besides whats mentioned on the backend tutorial. Any pointers to this would be excellent! [1] - http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-April/008809.html Cheers, -- PMatos From eli.friedman at gmail.com Mon May 17 06:23:27 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 17 May 2010 04:23:27 -0700 Subject: [LLVMdev] Backend for Harvard Architecture In-Reply-To: References: Message-ID: On Mon, May 17, 2010 at 3:09 AM, Paulo J. Matos wrote: > Hello, > > On a recent discussion on the cfe-dev mailing list[1] it was asked how > easy it was to create a backend to an Harvard Arch chip: different > data/function pointer sizes and 16 bit chars (main issues of the > targeted arch). Ken Dyck has posted a patch (which solved at least the > second problem of 16bit char) on which I have been working on and > Douglas Gregor said that different pointer sizes are already supported > by Clang, but what about llvm? When creating a backend, I have created > the DataLayout string but this string only allows me (as far as the > docs I found are concerned) to specify a pointer size (not several > pointer sizes). Is this something that Clang already supports but has > not yet managed to get into llvm or am I missing some configuration? Not supported at the moment in LLVM. Probably the easiest way to deal with it would be to make pointers the larger of data/function pointers, make the in-memory representation of the smaller an int of the appropriate width, and do some casting to "fix" the pointers. Properly supporting different data/function pointer sizes would require messing with the current system of casts; currently LLVM assumes casting between function and data pointers is lossless (using the "bitcast" instruction). -Eli From jason.wangz at gmail.com Mon May 17 09:02:39 2010 From: jason.wangz at gmail.com (Zheng Wang) Date: Mon, 17 May 2010 15:02:39 +0100 Subject: [LLVMdev] Is this value an integer type? Message-ID: Hello, I have a problem of dumping a value. Here is the llvm assembly code: --- %322 = getelementptr inbounds [76 x [4 x i8]]* @i_tc0_table, i32 0, i32 %305, i32 %321 ; [#uses=1] %323 = load i8* %322, align 1 ; [#uses=1] store i8 %323, i8* %89, align 1 -- I want to dump %323 to a library function whose prototype is: recordStore(const char*, unsigned int, unsigned, int) But my passer stuck at CallInst::init, because llvm complains %323 does not have the same type as the recordStore's is declared. assert((i >= FTy->getNumParams() || FTy->getParamType(i)== Params[i]->getType()) && "Calling a function with a bad signature!"); This is strange because the fourth argument of recordStore has been declared as: "IntegerType::get(getGlobalContext(), 32)" If I somehow replace the assert statement as: assert(... FTy->getParamType(i)->getTypeID() == Params[i]->getType()->getTypeID()) ...); , it passes this line but will fail at some point later on. My questions are: ***** Why %323 is different from the Integer type I has declared? ***** Why two values with the same TypeID are different? The following code is OK for my passer if I want to dump %3. %3 = add i32 %1, -1 ; [#uses=1] store i32 %3, i32* %0, align 4 A final question, how can I dump %323 in the first example? Cheers, Zheng From edwintorok at gmail.com Mon May 17 09:07:39 2010 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Mon, 17 May 2010 17:07:39 +0300 Subject: [LLVMdev] Is this value an integer type? In-Reply-To: References: Message-ID: <4BF14DAB.6030301@gmail.com> On 05/17/2010 05:02 PM, Zheng Wang wrote: > Hello, > > I have a problem of dumping a value. Here is the llvm assembly code: > > --- > %322 = getelementptr inbounds [76 x [4 x i8]]* @i_tc0_table, i32 0, > i32 %305, i32 %321 ; [#uses=1] > %323 = load i8* %322, align 1 ; [#uses=1] > store i8 %323, i8* %89, align 1 > -- > > I want to dump %323 to a library function whose prototype is: > > recordStore(const char*, unsigned int, unsigned, int) To pass an i8 as i32 you need either sign-, or zero-extension, i.e. %324 = zext i8 %323 to i32 call %recordStore(null, %324, i32 0) For example. > ***** Why %323 is different from the Integer type I has declared? i8 and i32 are different types Best regards, --Edwin From baldrick at free.fr Mon May 17 09:36:13 2010 From: baldrick at free.fr (Duncan Sands) Date: Mon, 17 May 2010 16:36:13 +0200 Subject: [LLVMdev] Is this value an integer type? In-Reply-To: References: Message-ID: <4BF1545D.4070700@free.fr> Hi Zheng, > %323 = load i8* %322, align 1 ; [#uses=1] the type of %323 is i8, as noted in the comment at the end of the line. > This is strange because the fourth argument of recordStore has been > declared as: "IntegerType::get(getGlobalContext(), 32)" This type is i32. Since i8 != i32, the types don't match. Ciao, Duncan. From jason.wangz at gmail.com Mon May 17 10:00:54 2010 From: jason.wangz at gmail.com (Zheng Wang) Date: Mon, 17 May 2010 16:00:54 +0100 Subject: [LLVMdev] Is this value an integer type? In-Reply-To: <4BF14DAB.6030301@gmail.com> References: <4BF14DAB.6030301@gmail.com> Message-ID: Thanks all!! Problem Solved. :) 2010/5/17 T?r?k Edwin : > On 05/17/2010 05:02 PM, Zheng Wang wrote: >> Hello, >> >> I have a problem of dumping a value. Here is the llvm assembly code: >> >> --- >> ?%322 = getelementptr inbounds [76 x [4 x i8]]* @i_tc0_table, i32 0, >> i32 %305, i32 %321 ; [#uses=1] >> ?%323 = load i8* %322, align 1 ? ? ? ? ? ? ? ? ? ; [#uses=1] >> ?store i8 %323, i8* %89, align 1 >> -- >> >> I want to dump %323 to a library function whose prototype is: >> >> recordStore(const char*, unsigned int, unsigned, int) > > To pass an i8 as i32 you need either sign-, or zero-extension, i.e. > %324 = zext i8 %323 to i32 > call %recordStore(null, %324, i32 0) > > For example. >> ***** Why %323 ?is different from the Integer type I has declared? > > i8 and i32 are different types > > > Best regards, > --Edwin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Best regards, WANG Zheng From renato.golin at arm.com Mon May 17 12:02:35 2010 From: renato.golin at arm.com (Renato Golin) Date: Mon, 17 May 2010 18:02:35 +0100 Subject: [LLVMdev] ARM EABI Exceptions Message-ID: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> Hi, I was comparing the way LLVM generates the exception table and it looks a bit different from what GCC (arm-none-eabi-g++) generates. Maybe that's because clang is not generating ARM IR when I do: $ clang -c -emit-llvm -march=arm -mcpu=cortex-a8 -mtriple=arm-none-eabi exception.cpp -o exception.clang.bc clang: warning: argument unused during compilation: '-mcpu=cortex-a8' clang: warning: argument unused during compilation: '-mtriple=arm-none-eabi' The IR triple is "x86_64-unknown-linux-gnu". Is there a way I can force the triple? Then I compiled with llc: $ llc -march=arm -mcpu=cortex-a8 -mtriple=arm-none-eabi exception.clang.ll -o exception.clang.s It doesn't generate the tables because ARMELFMCAsmInfo doesn't set ExceptionsType. If I set it to Dwarf and fix the missing lowering operations (EXCEPTIONADDR and EHSELECTION), it does generate a table which is slightly different than what GCC is doing. I've compared the assembly generated and it's close, but not perfect. Some EABI issues (frame pointer, some intrinsics mismatch, EH call table) were present, but the general execution flow seems very similar. If I compile the resulting asm with GCC ("-T generic-hosted.ld") and run, it breaks completely. GCC's run flawlessly. Anyone has any idea on the status of exception handling in clang/LLVM? DwarfException cannot be easily overwritten, and adding target specific code to it seems wrong... Attached is my example compiled with Codesourcery's GCC (2009q3) and clang (2.7). cheers, --renato -------------- next part -------------- A non-text attachment was scrubbed... Name: exception-clang-example.tar.gz Type: application/x-compressed-tar Size: 9630 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100517/ba3d2692/attachment.bin From anton at korobeynikov.info Mon May 17 12:38:33 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 17 May 2010 21:38:33 +0400 Subject: [LLVMdev] ARM EABI Exceptions In-Reply-To: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> References: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> Message-ID: Hello, Renato > Anyone has any idea on the status of exception handling in clang/LLVM? > DwarfException cannot be easily overwritten, and adding target specific > code to it seems wrong... Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, sjlj excheptions on arm/darwin). I have some patched uncommitted for EH on ARM but they are too far from being complete. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From dalej at apple.com Mon May 17 13:04:03 2010 From: dalej at apple.com (Dale Johannesen) Date: Mon, 17 May 2010 11:04:03 -0700 Subject: [LLVMdev] Shadow returns In-Reply-To: References: Message-ID: On May 16, 2010, at 9:22 PMPDT, Andrew Lenharth wrote: > I need to return i128 and f128 via a ptr passed in as the first > argument to a function. I am not seeing something in llvm-abi.h to > let me do this. How do I make a scalar (not an aggregate) use a > shadow return? Similarly I need to pass those types by pointer, > (byval arguments?) and don't see an obvious way to do that. I don't think any calling convention has needed to do that before, so it won't be supported. It shouldn't be too bad to implement by adding some new macros similar to the existing LLVM_SHOULD*. Good luck and test thoroughly; it's easy to break other targets when you touch this stuff. From jianzhou at seas.upenn.edu Mon May 17 13:54:58 2010 From: jianzhou at seas.upenn.edu (Jianzhou Zhao) Date: Mon, 17 May 2010 14:54:58 -0400 Subject: [LLVMdev] Passes ordering Message-ID: Hi LLVM, I have a question about how to ensure one pass runs exactly after another pass. In the implementation of opt.cpp, if the VerifyEach is set, a Verifier from llvm::createVerifierPass() is added after each pass. Is this verifier called after the verified pass immediately? The interfaces of PassManager only allows us to specify which passes the current pass replies on, and if the the current pass breaks any existing passes. PassManager will schedule the pass at the right time w.r.t these constraints. But it doesn't say that a pass added exactly after an old pass will follow this old pass at the compilation time. I looked into the code of PassManager. It seems that PassManager doesn't change the order of passes arbitrarily, but will rerun dependent passes before a pass that requires them. For me, this may affect the following verifier. For example, suppose I have a pass and its verifier, and the verifier checks the correctness of the pass with some information from this pass, if any other passes run between them, the verifier may not check this precisely. As an efficient compilation, PassManager also batches passes for a function or block to run together, without passes the source file once again. Will this ensure not to reorder passes? Thanks a lot. -- Jianzhou From eltoder at gmail.com Mon May 17 14:46:11 2010 From: eltoder at gmail.com (Eugene Toder) Date: Mon, 17 May 2010 20:46:11 +0100 Subject: [LLVMdev] GHC's LLVM Backend In-Reply-To: References: Message-ID: Great stuff! Re tables next to code -- I think this can be done in GNU C without the evil post-processing of assembly code. The idea is to put info table and code into the same section, say .ghc.text., and merge these sections into .text. I can't get GCC to put data and code into the same section and I'm not sure it guarantees it's relative ordering. To work around this we can put info table into .ghc..0 section and code into .ghc..1 then make linker sort by name and merge these sections. This is a fairly standard practice supported at least by Microsoft linker (with a slightly different naming convention) and gnu ld (via a custom linker script). Attached is a toy proof-of-concept example of using this technique that should work with gcc+gnu ld on many platforms. This approach can be used with LLVM directly (it already supports required GNU extensions), delegating the final merging to system linker, or a similar approach can be developed in LLVM. There are a few options: - The simplest thing is to place both table and code into the same section and guarantee that ordering of objects belonging to the same section is preserved by all transformations. - Failing that we'll need a way to mark several objects as being output together in a particular order. This cannot be done via metadata (because dropping this association will break the code) so this has to be done via a special global, a-la @llvm.used. Another thing is that ideally a function should be used by it's info table instead of forced used via @llvm.used. Eugene On Mon, May 17, 2010 at 3:43 AM, David Terei wrote: > Hi All, > > The Glasgow Haskell compiler has recently become an external user of > LLVM. You can read about it here: > > http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html > > If you have any comments, questions or perhaps even advice on solving > some of the issues that need to be fixed in the backend going forward > then please reply to this email. > > Cheers, > David > _______________________________________________ > 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: sec.c Type: application/octet-stream Size: 1092 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100517/191ea903/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: sec.sh Type: application/x-sh Size: 392 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100517/191ea903/attachment.sh From wendling at apple.com Mon May 17 15:23:41 2010 From: wendling at apple.com (Bill Wendling) Date: Mon, 17 May 2010 13:23:41 -0700 Subject: [LLVMdev] ARM EABI Exceptions In-Reply-To: References: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> Message-ID: On May 17, 2010, at 10:38 AM, Anton Korobeynikov wrote: > Hello, Renato > >> Anyone has any idea on the status of exception handling in clang/LLVM? >> DwarfException cannot be easily overwritten, and adding target specific >> code to it seems wrong... > Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, > sjlj excheptions on arm/darwin). I have some patched uncommitted for > EH on ARM but they are too far from being complete. > We do support SJLJ exceptions on ARM for Darwin at least. -bw From gohman at apple.com Mon May 17 15:53:31 2010 From: gohman at apple.com (Dan Gohman) Date: Mon, 17 May 2010 13:53:31 -0700 Subject: [LLVMdev] selection dag speedups / llc speedups In-Reply-To: References: Message-ID: <6D992ABF-4735-4DE3-B134-4F6387FBCE8F@apple.com> On May 14, 2010, at 11:24 AM, Jan Voung wrote: > Hello folks, > > I'm sure this has been asked many times, but is there current work on decreasing the time taken by the DAG-based instruction selector, or the other phases of llc? I am just beginning to dive into LLVM, and I am interested in compile-time reductions that do not reduce code quality dramatically. For example, simply switching on "-fast-isel" (roughly 17% drop in code quality for some of my benchmarks) or "-regalloc=local/fast" (roughly 2x slower for some of my benchmarks) is, unfortunately, not an acceptable option. > > I noticed that a semi-recent commit added the "STATISTIC(NumDAGIselRetries,"Number of times dag isel has to try another path");" as well as a sorting change in DAGISelEmitter.cpp. This suggests to me that there is work being done. Are there other similar efforts, but perhaps aiming for bigger gains, that I should be aware of? From the other end, are there efforts to make the fast-path produce better quality code?\ The specific work you mention was aimed at reducing isel's own code size. Previously, isel used a huge mountain of generated code which took a long time to compile, and consumed a large amount of memory. The new isel fixes these problems, but underneath it's using the same conceptual algorithm, and I believe is about the same speed. SelectionDAG performance is important. It hasn't seen a lot of attention recently, as the "-O0" use case has been where most of the compile-time attention has gone. But speeding up SelectionDAG isel would also be useful for many different purposes. > > Some small things I've noticed: > > - LegalizeVectors might not make a single change over an entire input bc file, yet it can take about 6% of the ISel time. Identifying that this can be skipped ahead of time may help? Sounds reasonable. Perhaps there could be a SelectionDAG-wide flag which indicates whether any vectors are present. Another thing that could be done is avoiding running DAGCombine when it isn't needed. I believe there are a few cases where the code just reruns DAGCombine even if the preceding Legalize pass doesn't make any changes. Longer term, I've also heard some ideas tossed around of merging LegalizeDAG.cpp and now also LegalizeVectorsOps.cpp with the new LegalizeTypes infrastructure so that everything would run as a single pass, which would greatly reduce the amount of "Walk and hash all the nodes" work that these passes currently do. Another thing to look at is the underlying FoldingSet data structure. Right now, node lookup requires a lot of recomputation of hash data. > - We can take the Changed flag returned by LegalizeVectors, and pass it on to Legalize so that it can decide not to AssignTopologicalOrder again, since it was already done in the LegalizeVectors pass. However, this is a negligible reduction: 0.2 seconds shaved off a 30+ second compile =). Ok. > - BuildSchedGraph() can take around 30% of the X% of time taken by Instruction Scheduling. How different is the scheduler graph from the selection graph? The scheduling graph is constructed using the selection graph information, but it does different things. Constants and other nodes which don't correspond to instructions are excluded, nodes which must be scheduled together are merged, extra edges can be added, the schedule graph doesn't do automatic CSE on edge changes, etc. The schedule graph also has data to track node height and depth, and other information used by the scheduler. Dan From stoklund at 2pi.dk Mon May 17 16:52:46 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Mon, 17 May 2010 14:52:46 -0700 Subject: [LLVMdev] selection dag speedups / llc speedups In-Reply-To: References: Message-ID: On May 14, 2010, at 11:24 AM, Jan Voung wrote: > I'm sure this has been asked many times, but is there current work on decreasing the time taken by the DAG-based instruction selector, or the other phases of llc? I am just beginning to dive into LLVM, and I am interested in compile-time reductions that do not reduce code quality dramatically. For example, simply switching on "-fast-isel" (roughly 17% drop in code quality for some of my benchmarks) or "-regalloc=local/fast" (roughly 2x slower for some of my benchmarks) is, unfortunately, not an acceptable option. The fast and local register allocators are meant to be used on unoptimized code, a 'Debug build'. While they do work on optimized code, they do not give good results. Their primary goal is compile time, not code quality. /jakob From jianzhou at seas.upenn.edu Mon May 17 17:36:11 2010 From: jianzhou at seas.upenn.edu (Jianzhou Zhao) Date: Mon, 17 May 2010 18:36:11 -0400 Subject: [LLVMdev] How to copy a Function Message-ID: Hi, I wanted to backup a Function before it is optimized. The Function class disallows assignment operations as it comments: Function(const Function&); // DO NOT IMPLEMENT void operator=(const Function&); // DO NOT IMPLEMENT Is there a way to construct a copy from an existing Function? Thanks. -- Jianzhou From grosbach at apple.com Mon May 17 18:29:10 2010 From: grosbach at apple.com (Jim Grosbach) Date: Mon, 17 May 2010 16:29:10 -0700 Subject: [LLVMdev] How to copy a Function In-Reply-To: References: Message-ID: <122BC2E0-6741-4FF2-8A05-35B11D5679D5@apple.com> On May 17, 2010, at 3:36 PM, Jianzhou Zhao wrote: > Hi, > > I wanted to backup a Function before it is optimized. The Function > class disallows assignment operations as it comments: > Function(const Function&); // DO NOT IMPLEMENT > void operator=(const Function&); // DO NOT IMPLEMENT > Is there a way to construct a copy from an existing Function? > CloneFunction() may do what you want. See: llvm/include/llvm/Transforms/Utils/Cloning.h > Thanks. > -- > Jianzhou > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From jianzhou at seas.upenn.edu Mon May 17 18:41:42 2010 From: jianzhou at seas.upenn.edu (Jianzhou Zhao) Date: Mon, 17 May 2010 19:41:42 -0400 Subject: [LLVMdev] How to copy a Function In-Reply-To: <122BC2E0-6741-4FF2-8A05-35B11D5679D5@apple.com> References: <122BC2E0-6741-4FF2-8A05-35B11D5679D5@apple.com> Message-ID: On Mon, May 17, 2010 at 7:29 PM, Jim Grosbach wrote: > > On May 17, 2010, at 3:36 PM, Jianzhou Zhao wrote: > >> Hi, >> >> I wanted to backup a Function before it is optimized. The Function >> class disallows assignment operations as it comments: >> ?Function(const Function&); // DO NOT IMPLEMENT >> ?void operator=(const Function&); // DO NOT IMPLEMENT >> Is there a way to construct a copy from an existing Function? >> > > CloneFunction() may do what you want. See: > llvm/include/llvm/Transforms/Utils/Cloning.h Thanks! This exactly implemented what I need. > > >> Thanks. >> -- >> Jianzhou >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- Jianzhou From tabloid.adroit at gmail.com Mon May 17 19:08:47 2010 From: tabloid.adroit at gmail.com (Yuanfang Chen) Date: Mon, 17 May 2010 20:08:47 -0400 Subject: [LLVMdev] suggestion: add a member in llvm::CodeMetrics Message-ID: Is it worthwhile to add a void analyzeInstRange(InstIter begin, InstIter end) {} which estimate code metrics of any instruction range in a basic block. Or we are good with analyzeBasicBlock as an upperbound? thanks yuanfang From stoklund at 2pi.dk Mon May 17 19:43:13 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Mon, 17 May 2010 17:43:13 -0700 Subject: [LLVMdev] Fast register allocation Message-ID: As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. Both allocators use a local allocation strategy. Each basic block is scanned from top to bottom, and virtual registers are assigned to physical registers as they appear. There are no live registers between blocks. Everything is spilled at the end of each block. This strategy works well for unoptimized code where live ranges are short. The fast allocator uses a few tricks to run faster than the local allocator while producing slightly better code. When RALocal allocates a physical register, it first checks if any aliases are in use to avoid clobbering a subregister. RAFast uses a working set strategy where recently killed registers are kept around for quick allocation without the alias scan. RALocal uses a least-recently-used algorithm for allocating registers. RAFast uses a whatever-I-can-get-my-hands-on-quickly algorithm. RALocal folds spills and restores into other instructions. RAFast doesn't bother because debug builds have very few spills. RAFast uses more aggressive hinting by peeking at future instructions. This helps reduce the number of register copies when setting up parameters for a call: %reg1028 = MOV32rm , 1, %reg0, 0, %reg0 %reg1029 = MOV32rm , 1, %reg0, 4, %reg0 ADJCALLSTACKDOWN64 0, %RSP, %EFLAGS, %RSP %reg1030 = LEA64r %RIP, 1, %reg0, %reg1031 = MOV8r0 %EFLAGS %RDI = MOV64rr %reg1030 %ESI = MOV32rr %reg1028 %EDX = MOV32rr %reg1029 %AL = MOV8rr %reg1031 CALL64pcrel32 , %RDI, %ESI, %EDX, %AL, %RAX, %RDX, %RSI, %RDI, %RSP, ... When finding a register for %reg1028, RAFast sees that it is later copied to %ESI. It is allocated %ESI and the copy disappears: %ESI = MOV32rm , 1, %reg0, 0, %reg0 %EDX = MOV32rm , 1, %reg0, 4, %reg0 ADJCALLSTACKDOWN64 0, %RSP, %EFLAGS, %RSP %RDI = LEA64r %RIP, 1, %reg0, %AL = MOV8r0 %EFLAGS CALL64pcrel32 , %RDI, %ESI, %EDX, %AL, %RAX, %RDX, %RSI, %RDI, %RSP, ... The aggressive coalescing also reduces register pressure, and there is a lot less spilling. In a debug build of SPECCPU2006/403.gcc it results in 8% less instructions: Local Fast ------- ------- 153623 258567 regalloc - Number of copies coalesced 24975 18381 regalloc - Number of loads added 19361 13864 regalloc - Number of stores added 1109880 1018144 asm-printer - Number of machine instrs printed The fast allocator is about three times faster than the old local allocator. It reduces the overall code generation time from 7.0s to 5.9s for 403.gcc: RALocal: Total Execution Time: 6.9976 seconds (7.1717 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 2.7376 ( 42.1%) 0.2554 ( 51.8%) 2.9931 ( 42.8%) 2.9930 ( 41.7%) X86 DAG->DAG Instruction Selection 1.4644 ( 22.5%) 0.0073 ( 1.5%) 1.4717 ( 21.0%) 1.4714 ( 20.5%) Local Register Allocator 0.5407 ( 8.3%) 0.1298 ( 26.3%) 0.6705 ( 9.6%) 0.8463 ( 11.8%) X86 AT&T-Style Assembly Printer RAFast: Total Execution Time: 5.9255 seconds (6.0734 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 2.7223 ( 50.1%) 0.2574 ( 52.5%) 2.9796 ( 50.3%) 2.9796 ( 49.1%) X86 DAG->DAG Instruction Selection 0.5241 ( 9.6%) 0.1237 ( 25.2%) 0.6479 ( 10.9%) 0.8003 ( 13.2%) X86 AT&T-Style Assembly Printer 0.4526 ( 8.3%) 0.0063 ( 1.3%) 0.4589 ( 7.7%) 0.4584 ( 7.5%) Fast Register Allocator The fast allocator can be enabled for clang -O0 with a small patch: diff --git a/lib/Frontend/CodeGenAction.cpp b/lib/Frontend/CodeGenAction.cpp index 86005f2..cd2d2f0 100644 --- a/lib/Frontend/CodeGenAction.cpp +++ b/lib/Frontend/CodeGenAction.cpp @@ -322,7 +322,7 @@ bool BackendConsumer::AddEmitPasses() { // Set register scheduler & allocation policy. RegisterScheduler::setDefault(createDefaultScheduler); - RegisterRegAlloc::setDefault(Fast ? createLocalRegisterAllocator : + RegisterRegAlloc::setDefault(Fast ? createFastRegisterAllocator : createLinearScanRegisterAllocator); // Create the code generator passes. I have tested clang self hosting on x86-64 and x64 with this patch. On the nightly test suite, -regalloc=fast performs as well as -regalloc=local. See PR7154. I expect we may see some problems with the register scavenger on ARM because -regalloc=fast doesn't currently add flags on call clobbered registers. That increases register pressure quite a bit as seen by the scavenger. Share and Enjoy! /jakob From clattner at apple.com Mon May 17 20:21:03 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 17 May 2010 18:21:03 -0700 Subject: [LLVMdev] Fast register allocation In-Reply-To: References: Message-ID: On May 17, 2010, at 5:43 PM, Jakob Stoklund Olesen wrote: > As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. This is great work Jakob! What is required and when do you think you'll be killing off the local allocator? -Chris From Rob.Grapes at ur.co.nz Mon May 17 20:27:39 2010 From: Rob.Grapes at ur.co.nz (Rob Grapes) Date: Tue, 18 May 2010 13:27:39 +1200 Subject: [LLVMdev] Possible memory leak in LLVM 2.5 Message-ID: <3D26A6E9AD90AC4285B7D65DC10A298D0131AA2874C7@exchange.ur.local> Hi, I'm current using LLVM 2.5 to JIT code in a event driven language running on a game engine. Haven't updated to 2.7 yet, but I do intend to. When checking for memory leaks I found that each time I was calling EE->runFunction after creating a stub function to execute an event, all the pass information was being repeatedly added to PMDataManager. I have changed addAnalysisImplsPair to the following, which seems to have no side effects with what I am doing. Prior to that, AnalysisImpls contained thousands of entries and each time the vector gets realloced to accommodate more entries we lose a bigger chunk of memory. void addAnalysisImplsPair(const PassInfo *PI, Pass *P) { for (std::vector >::iterator I = AnalysisImpls.begin(); (I!=AnalysisImpls.end()); ++I) { if (I->first==PI && I->second==P) { // Return, if PassInfo and Pass are already in AnalysisImpls. return; } } std::pair pir = std::make_pair(PI,P); AnalysisImpls.push_back(pir); } I'm probably doing something funny, or not as intended, but your comments would be appreciated. Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100518/c02cf9b3/attachment.html From rnk at mit.edu Mon May 17 21:53:09 2010 From: rnk at mit.edu (Reid Kleckner) Date: Mon, 17 May 2010 22:53:09 -0400 Subject: [LLVMdev] Possible memory leak in LLVM 2.5 In-Reply-To: <3D26A6E9AD90AC4285B7D65DC10A298D0131AA2874C7@exchange.ur.local> References: <3D26A6E9AD90AC4285B7D65DC10A298D0131AA2874C7@exchange.ur.local> Message-ID: I'm unfamiliar with the leak you've just described, but Jeffrey Yasskin has done a lot of work cleaning up leaks for 2.7 and trunk. I was just going to mention that unless the function you are calling via runFunction has a simple prototype that's special cased in runFunction, it will generate its own stub function for every call. If you don't want to worry about that, you can call getPointerToFunction and cast it to the appropriate function pointer type before calling it yourself. Reid On Mon, May 17, 2010 at 9:27 PM, Rob Grapes wrote: > Hi, > > > > I?m current using LLVM 2.5 to JIT code in a event driven language running on > a game engine.? Haven?t updated to 2.7 yet, but I do intend to. > > > > When checking for memory leaks I found that each time I was calling > EE->runFunction after creating a stub function to execute an event, all the > pass information was being repeatedly added to PMDataManager. > > > > I have changed addAnalysisImplsPair to the following, which seems to have no > side effects with what I am doing.? Prior to that, AnalysisImpls contained > thousands of entries and each time the vector gets realloced to accommodate > more entries we lose a bigger chunk of memory. > > > > ? void addAnalysisImplsPair(const PassInfo *PI, Pass *P) { > > ???? for (std::vector >::iterator I = > > ??????? AnalysisImpls.begin(); (I!=AnalysisImpls.end()); ++I) > > ???? { > > ??????? if (I->first==PI && I->second==P) > > ??????? { > > ?????????? // Return, if PassInfo and Pass are already in AnalysisImpls. > > ?????????? return; > > ??????? } > > ???? } > > ??? std::pair pir = std::make_pair(PI,P); > > ??? AnalysisImpls.push_back(pir); > > ? } > > > > I?m probably doing something funny, or not as intended, but your comments > would be appreciated. > > > > Rob. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From Rob.Grapes at ur.co.nz Mon May 17 22:13:38 2010 From: Rob.Grapes at ur.co.nz (Rob Grapes) Date: Tue, 18 May 2010 15:13:38 +1200 Subject: [LLVMdev] Possible memory leak in LLVM 2.5 In-Reply-To: References: <3D26A6E9AD90AC4285B7D65DC10A298D0131AA2874C7@exchange.ur.local> Message-ID: <3D26A6E9AD90AC4285B7D65DC10A298D0131AA2874DF@exchange.ur.local> Hi Reid, I guess it's not so much a memory leak, as unexpected behaviour, resulting in excessive memory use. I also call the following after EE->runFunction, which seems to clean up pretty nicely. EE->freeMachineCodeForFunction(stub); // Delete functions and IR. stub->deleteBody(); stub->eraseFromParent(); Rob. -----Original Message----- From: reid.kleckner at gmail.com [mailto:reid.kleckner at gmail.com] On Behalf Of Reid Kleckner Sent: Tuesday, 18 May 2010 2:53 p.m. To: Rob Grapes Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Possible memory leak in LLVM 2.5 I'm unfamiliar with the leak you've just described, but Jeffrey Yasskin has done a lot of work cleaning up leaks for 2.7 and trunk. I was just going to mention that unless the function you are calling via runFunction has a simple prototype that's special cased in runFunction, it will generate its own stub function for every call. If you don't want to worry about that, you can call getPointerToFunction and cast it to the appropriate function pointer type before calling it yourself. Reid On Mon, May 17, 2010 at 9:27 PM, Rob Grapes wrote: > Hi, > > > > I'm current using LLVM 2.5 to JIT code in a event driven language running on > a game engine.? Haven't updated to 2.7 yet, but I do intend to. > > > > When checking for memory leaks I found that each time I was calling > EE->runFunction after creating a stub function to execute an event, all the > pass information was being repeatedly added to PMDataManager. > > > > I have changed addAnalysisImplsPair to the following, which seems to have no > side effects with what I am doing.? Prior to that, AnalysisImpls contained > thousands of entries and each time the vector gets realloced to accommodate > more entries we lose a bigger chunk of memory. > > > > ? void addAnalysisImplsPair(const PassInfo *PI, Pass *P) { > > ???? for (std::vector >::iterator I = > > ??????? AnalysisImpls.begin(); (I!=AnalysisImpls.end()); ++I) > > ???? { > > ??????? if (I->first==PI && I->second==P) > > ??????? { > > ?????????? // Return, if PassInfo and Pass are already in AnalysisImpls. > > ?????????? return; > > ??????? } > > ???? } > > ??? std::pair pir = std::make_pair(PI,P); > > ??? AnalysisImpls.push_back(pir); > > ? } > > > > I'm probably doing something funny, or not as intended, but your comments > would be appreciated. > > > > Rob. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From espindola at google.com Mon May 17 23:09:19 2010 From: espindola at google.com (Rafael Espindola) Date: Tue, 18 May 2010 00:09:19 -0400 Subject: [LLVMdev] selection dag speedups / llc speedups In-Reply-To: References: Message-ID: > The fast and local register allocators are meant to be used on unoptimized code, a 'Debug build'. While they do work on optimized code, they do not give good results. Their primary goal is compile time, not code quality. Yes, we have a somewhat uncommon use case. It is fine to spend time optimizing bitcode (LTO is a OK), but we want to make the final IL -> Executable translation as fast as possible. > /jakob Cheers, -- Rafael ?vila de Esp?ndola From stoklund at 2pi.dk Mon May 17 23:33:18 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Mon, 17 May 2010 21:33:18 -0700 Subject: [LLVMdev] selection dag speedups / llc speedups In-Reply-To: References: Message-ID: <18C9B7A6-1A2D-44A8-BB00-835E1F9637AA@2pi.dk> On May 17, 2010, at 9:09 PM, Rafael Espindola wrote: >> The fast and local register allocators are meant to be used on unoptimized code, a 'Debug build'. While they do work on optimized code, they do not give good results. Their primary goal is compile time, not code quality. > > Yes, we have a somewhat uncommon use case. It is fine to spend time > optimizing bitcode (LTO is a OK), but we want to make the final IL -> > Executable translation as fast as possible. Do you know how the fast allocator performs in these conditions? Have you compared it to the local allocator? I really focused my efforts on unoptimized code. /jakob From jyasskin at google.com Tue May 18 00:22:58 2010 From: jyasskin at google.com (Jeffrey Yasskin) Date: Mon, 17 May 2010 22:22:58 -0700 Subject: [LLVMdev] Possible memory leak in LLVM 2.5 In-Reply-To: <3D26A6E9AD90AC4285B7D65DC10A298D0131AA2874DF@exchange.ur.local> References: <3D26A6E9AD90AC4285B7D65DC10A298D0131AA2874C7@exchange.ur.local> <3D26A6E9AD90AC4285B7D65DC10A298D0131AA2874DF@exchange.ur.local> Message-ID: On Mon, May 17, 2010 at 8:13 PM, Rob Grapes wrote: > Hi Reid, > > I guess it's not so much a memory leak, as unexpected behaviour, resulting in excessive memory use. Yeah, it sounds like a Java-leak rather than the kind of leak valgrind would find. We fixed all the valgrind-detected leaks shortly after 2.7 branched, but I don't think I touched this file. I'm not going to have time to look at this in the near future, but if you can write a small program that compiles against llvm trunk (2.5 is too old, and 2.7 is nearly so, unfortunately) and uses increasing amounts of memory over time just from calling runFunction repeatedly, you should file a bug at llvm.org/bugs From Renato.Golin at arm.com Tue May 18 04:39:53 2010 From: Renato.Golin at arm.com (Renato Golin) Date: Tue, 18 May 2010 10:39:53 +0100 Subject: [LLVMdev] ARM EABI Exceptions In-Reply-To: References: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> Message-ID: > -----Original Message----- > From: Anton Korobeynikov [mailto:anton at korobeynikov.info] > > Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, > sjlj excheptions on arm/darwin). I have some patched uncommitted for > EH on ARM but they are too far from being complete. Hi Anton, Are you actively working in that area? I did some experiments and managed to understand how LLVM does the exception handling, but my changes are also far from working. My main concern is that DwarfException is not extensible at all. I can't inherit from it (DwarfWriter creates it directly) and there are no call backs to target-specific code (nor registration of such mechanism). To change that in line with AsmWriter would be a major change and passing a ARMException reference through AsmWriter would pass the object through many places that are not concerned with it. A simple registration mechanism (DE->registerTargetCode-thingy) would be the least change and more direct approach, but it's damn ugly. ;) Apart from that, the format of the table and the calls to intrinsic functions are quite close. About Sj/Lj exceptions, that's not ARM EHABI compliant. EABI GCC won't compile that, I guess. Not to mention it hampers normal execution... Thanks, --renato -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From jason.wangz at gmail.com Tue May 18 05:26:52 2010 From: jason.wangz at gmail.com (Zheng Wang) Date: Tue, 18 May 2010 11:26:52 +0100 Subject: [LLVMdev] DEBUG INFO at the bytecode level Message-ID: Hello, Could I get some debug info at the byte code level? I am writing a passer and if will be nice if I can know which line in the source an instruction (or value) corresponds to. I found a document online: http://llvm.org/docs/SourceLevelDebugging.html, but I can't find an example of doing it at the byte code level. Cheers, Zheng From edwintorok at gmail.com Tue May 18 05:30:07 2010 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Tue, 18 May 2010 13:30:07 +0300 Subject: [LLVMdev] DEBUG INFO at the bytecode level In-Reply-To: References: Message-ID: <4BF26C2F.8080401@gmail.com> On 05/18/2010 01:26 PM, Zheng Wang wrote: > Hello, > > Could I get some debug info at the byte code level? I am writing a > passer and if will be nice if I can know which line in the source an > instruction (or value) corresponds to. > > I found a document online: > http://llvm.org/docs/SourceLevelDebugging.html, but I can't find an > example of doing it at the byte code level. -print-dbginfo should print the source lines, at least the one in 2.6, the one in 2.7 seems to have the source line printing removed. I'll add it back when I get some time. Best regards, --Edwin From jason.wangz at gmail.com Tue May 18 06:08:27 2010 From: jason.wangz at gmail.com (Zheng Wang) Date: Tue, 18 May 2010 12:08:27 +0100 Subject: [LLVMdev] DEBUG INFO at the bytecode level In-Reply-To: <4BF26C2F.8080401@gmail.com> References: <4BF26C2F.8080401@gmail.com> Message-ID: Thanks Edwin. I found DebugInfo.cpp may be useful. Could you tell me which function I should call inorder to know the source file name and the line number for a particular instruction? Cheers, Zheng 2010/5/18 T?r?k Edwin : > On 05/18/2010 01:26 PM, Zheng Wang wrote: >> Hello, >> >> Could I get some debug info at the byte code level? I am writing a >> passer and if will be nice if I can know which line in the source an >> instruction (or value) corresponds to. >> >> I found a document online: >> http://llvm.org/docs/SourceLevelDebugging.html, but I can't find an >> example of doing it at the byte code level. > > -print-dbginfo should print the source lines, at least the one in 2.6, > the one in 2.7 seems to have the source line printing removed. > > I'll add it back when I get some time. > > Best regards, > --Edwin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Best regards, WANG Zheng From edwintorok at gmail.com Tue May 18 06:10:20 2010 From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=) Date: Tue, 18 May 2010 14:10:20 +0300 Subject: [LLVMdev] DEBUG INFO at the bytecode level In-Reply-To: References: <4BF26C2F.8080401@gmail.com> Message-ID: <4BF2759C.5030001@gmail.com> On 05/18/2010 02:08 PM, Zheng Wang wrote: > Thanks Edwin. > > I found DebugInfo.cpp may be useful. Could you tell me which function > I should call inorder to know the source file name and the line number > for a particular instruction? Which version of LLVM? There was a major change between 2.6 and 2.7 so my answer depends on that. > > Cheers, > Zheng > > 2010/5/18 T?r?k Edwin : >> On 05/18/2010 01:26 PM, Zheng Wang wrote: >>> Hello, >>> >>> Could I get some debug info at the byte code level? I am writing a >>> passer and if will be nice if I can know which line in the source an >>> instruction (or value) corresponds to. >>> >>> I found a document online: >>> http://llvm.org/docs/SourceLevelDebugging.html, but I can't find an >>> example of doing it at the byte code level. >> >> -print-dbginfo should print the source lines, at least the one in 2.6, >> the one in 2.7 seems to have the source line printing removed. >> >> I'll add it back when I get some time. >> >> Best regards, >> --Edwin >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > From jason.wangz at gmail.com Tue May 18 06:22:07 2010 From: jason.wangz at gmail.com (Zheng Wang) Date: Tue, 18 May 2010 12:22:07 +0100 Subject: [LLVMdev] DEBUG INFO at the bytecode level In-Reply-To: <4BF27727.6010500@gmail.com> References: <4BF26C2F.8080401@gmail.com> <4BF2759C.5030001@gmail.com> <4BF27727.6010500@gmail.com> Message-ID: Thanks Edwin, I will check it out. Cheers, Zheng 2010/5/18 T?r?k Edwin : > On 05/18/2010 02:13 PM, Zheng Wang wrote: >> Got it. >> >> I am using LLVM 2.6. I guess ?bool getLocationInfo(const Value *V, >> std::string &DisplayName,...) has everything I need.\ > > Yes, for variables. > For instructions see what printStopPoint() does in DbgInfoPrinter.cpp. > > However I'd suggest upgrading to llvm 2.7 and doing your development > there directly. > First of all llvm 2.7 has much better debuginfo support (in 2.6 applying > any optimization would most likely destroy line number debug info) > Also 2.7 has a new way of representing debug info (Metadata instead of > intrinsics), so it'll be less work to implement it for 2.7 right now > instead of implementing for 2.6, and then reimplementing for 2.7 > >> >> Thanks a lot!! >> >> Cheers, >> Zheng >> >> 2010/5/18 T?r?k Edwin : >>> On 05/18/2010 02:08 PM, Zheng Wang wrote: >>>> Thanks Edwin. >>>> >>>> I found DebugInfo.cpp may be useful. Could you tell me which function >>>> I should call inorder to know the source file name and the line number >>>> for a particular instruction? >>> >>> Which version of LLVM? >>> There was a major change between 2.6 and 2.7 so my answer depends on that. >>> >>>> >>>> Cheers, >>>> Zheng >>>> >>>> 2010/5/18 T?r?k Edwin : >>>>> On 05/18/2010 01:26 PM, Zheng Wang wrote: >>>>>> Hello, >>>>>> >>>>>> Could I get some debug info at the byte code level? I am writing a >>>>>> passer and if will be nice if I can know which line in the source an >>>>>> instruction (or value) corresponds to. >>>>>> >>>>>> I found a document online: >>>>>> http://llvm.org/docs/SourceLevelDebugging.html, but I can't find an >>>>>> example of doing it at the byte code level. >>>>> >>>>> -print-dbginfo should print the source lines, at least the one in 2.6, >>>>> the one in 2.7 seems to have the source line printing removed. >>>>> >>>>> I'll add it back when I get some time. >>>>> >>>>> Best regards, >>>>> --Edwin >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > > -- Best regards, WANG Zheng From dshong at sdgroup.snu.ac.kr Tue May 18 02:38:22 2010 From: dshong at sdgroup.snu.ac.kr (=?ks_c_5601-1987?B?yKu1tbyx?=) Date: Tue, 18 May 2010 16:38:22 +0900 Subject: [LLVMdev] when compiling the IR api codes, "g++ internal error" occurred. Message-ID: <002b01caf65d$184be960$48e3bc20$@snu.ac.kr> Hello~! I?m beginner about LLVM. My purpose is inserting a function call to basic block, which is composed of IR codes. For this, I did following works. 1) Generate bytecodes from c++ codes 2) Generate the C++ codes, composed of LLVM APIs. $ llc -march=cpp main.bc -o=main_irgen.cpp 3) Insert function call APIs to the generated C++ codes from step 2) 4) Compile the functional call inserted codes. $ g++ -O2 main_irgen.cpp `llvm-config --cxxflags --ldflags --libs core` -o main_irgen.cpp -> In this step, an error occurred. The messages are as follows g++: Internal error: segmentation fault (program cc1plus) When the generated ?main_irgen.cpp? file had 3000~4000 code lines, no error occurred. But, the file had over 30000 code lines, internal error occurred. It was likely that the memory was lacking. But the computer memory is 4G. If you know, give me the way to solve or solution. Thank?U. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100518/617e5930/attachment.html From criswell at illinois.edu Tue May 18 09:21:22 2010 From: criswell at illinois.edu (John Criswell) Date: Tue, 18 May 2010 08:21:22 -0600 Subject: [LLVMdev] DEBUG INFO at the bytecode level In-Reply-To: References: Message-ID: <4BF2A262.7020203@illinois.edu> Zheng Wang wrote: > Hello, > > Could I get some debug info at the byte code level? I am writing a > passer and if will be nice if I can know which line in the source an > instruction (or value) corresponds to. > SAFECode has an example of using debug info for LLVM 2.6 in lib/DebugInstrumentation/DebugInstrumentation.cpp. Mainline SAFECode also works with LLVM 2.7, but the debug info usage may not be working quite right yet. -- John T. > I found a document online: > http://llvm.org/docs/SourceLevelDebugging.html, but I can't find an > example of doing it at the byte code level. > > Cheers, > Zheng > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From stoklund at 2pi.dk Tue May 18 09:49:28 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Tue, 18 May 2010 07:49:28 -0700 Subject: [LLVMdev] Fast register allocation In-Reply-To: References: Message-ID: <65B22F08-991D-45D1-9073-14452A6075B1@2pi.dk> On May 17, 2010, at 6:21 PM, Chris Lattner wrote: > > On May 17, 2010, at 5:43 PM, Jakob Stoklund Olesen wrote: > >> As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. > > This is great work Jakob! What is required and when do you think you'll be killing off the local allocator? I think we should switch clang -O0 to the fast allocator right away. It is the only way of smoking out the remaining bugs. I am not sure if or when llvm-gcc wants to switch, but when there are no more clients in the tree, we can kill off the local allocator. /jakob From daniel at zuster.org Tue May 18 10:23:10 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Tue, 18 May 2010 08:23:10 -0700 Subject: [LLVMdev] Fast register allocation In-Reply-To: <65B22F08-991D-45D1-9073-14452A6075B1@2pi.dk> References: <65B22F08-991D-45D1-9073-14452A6075B1@2pi.dk> Message-ID: You mention some potential issues on ARM, should we sort those out before we enable it in Clang? It's somewhat more convenient to have things be consistent. I propose that at some point you just replace the old local register allocator with the new one, and rename the old one. Then clients don't need to change, and we can keep the old one available for a little while if we want, for testing. - Daniel On Tue, May 18, 2010 at 7:49 AM, Jakob Stoklund Olesen wrote: > > On May 17, 2010, at 6:21 PM, Chris Lattner wrote: > >> >> On May 17, 2010, at 5:43 PM, Jakob Stoklund Olesen wrote: >> >>> As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. >> >> This is great work Jakob! ?What is required and when do you think you'll be killing off the local allocator? > > I think we should switch clang -O0 to the fast allocator right away. It is the only way of smoking out the remaining bugs. > > I am not sure if or when llvm-gcc wants to switch, but when there are no more clients in the tree, we can kill off the local allocator. > > /jakob > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From stoklund at 2pi.dk Tue May 18 11:03:50 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Tue, 18 May 2010 09:03:50 -0700 Subject: [LLVMdev] Fast register allocation In-Reply-To: References: <65B22F08-991D-45D1-9073-14452A6075B1@2pi.dk> Message-ID: <9F40ACAB-CCB3-4D25-B928-94F71DA44CD4@2pi.dk> On May 18, 2010, at 8:23 AM, Daniel Dunbar wrote: > You mention some potential issues on ARM, should we sort those out > before we enable it in Clang? It's somewhat more convenient to have > things be consistent. Sure, I'll be testing some ARM code today. There is also Evan's new REG_SEQUENCE instruction to verify. > I propose that at some point you just replace the old local register > allocator with the new one, and rename the old one. Then clients don't > need to change, and we can keep the old one available for a little > while if we want, for testing. I am not a big fan of renaming - it can easily cause confusion. Besides, fast-alloc goes with fast-isel. But perhaps we could take this opportunity to let LLVMTargetMachine choose a register allocator based on the optimization level? It is already enabling fast-isel that way, and -O0 -regalloc=linearscan (which is the default) doesn't really make sense. LLVMTargetMachine::addCommonCodeGenPasses does a decent job of building a codegen pipeline, except it needs help picking a register allocator. There is no good reason for that. /jakob From clattner at apple.com Tue May 18 11:19:43 2010 From: clattner at apple.com (Chris Lattner) Date: Tue, 18 May 2010 09:19:43 -0700 Subject: [LLVMdev] Fast register allocation In-Reply-To: <65B22F08-991D-45D1-9073-14452A6075B1@2pi.dk> References: <65B22F08-991D-45D1-9073-14452A6075B1@2pi.dk> Message-ID: On May 18, 2010, at 7:49 AM, Jakob Stoklund Olesen wrote: > > On May 17, 2010, at 6:21 PM, Chris Lattner wrote: > >> >> On May 17, 2010, at 5:43 PM, Jakob Stoklund Olesen wrote: >> >>> As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. >> >> This is great work Jakob! What is required and when do you think you'll be killing off the local allocator? > > I think we should switch clang -O0 to the fast allocator right away. It is the only way of smoking out the remaining bugs. > > I am not sure if or when llvm-gcc wants to switch, but when there are no more clients in the tree, we can kill off the local allocator. Ok, but we should switch both clang and llvm-gcc at the same time. -Chris From devang.patel at gmail.com Tue May 18 11:28:57 2010 From: devang.patel at gmail.com (Devang Patel) Date: Tue, 18 May 2010 09:28:57 -0700 Subject: [LLVMdev] DEBUG INFO at the bytecode level In-Reply-To: References: <4BF26C2F.8080401@gmail.com> Message-ID: 2010/5/18 Zheng Wang : > > I found DebugInfo.cpp may be useful. Could you tell me which function > I should call inorder to know the source file name and the line number > for a particular instruction? > See http://llvm.org/docs/SourceLevelDebugging.html#ccxx_frontend At the end of "C/C++ source file information" section, there is a small code snippet this describes how to extract this information. - Devang From sebastien.bourdeauducq at lekernel.net Tue May 18 11:38:41 2010 From: sebastien.bourdeauducq at lekernel.net (=?iso-8859-1?q?S=E9bastien_Bourdeauducq?=) Date: Tue, 18 May 2010 18:38:41 +0200 Subject: [LLVMdev] LatticeMico32 (LM32) backend Message-ID: <201005181838.41946.sebastien.bourdeauducq@lekernel.net> Hi, Would anyone be interested in developing a LatticeMico32 backend in LLVM? LatticeMico32 [1] is an open source microprocessor core designed by Lattice Semiconductor and typically used in FPGAs. It is comparable to the Microblaze processor that you already support. It is already supported by GNU Binutils and GCC (4.5+). It is used by the Milkymist [2] and RTEMS [3] projects. The Milkymist project would like to use the LLVM compiler toolchain as an alternative to GCC, which requires developing a LM32 backend. Thanks, S?bastien Bourdeauducq [1] http://www.latticesemi.com/mico32 [2] http://www.milkymist.org [3] http://www.rtems.org From ambika at cse.iitb.ac.in Tue May 18 12:43:45 2010 From: ambika at cse.iitb.ac.in (ambika) Date: Tue, 18 May 2010 23:13:45 +0530 Subject: [LLVMdev] Question regarding value being loaded in some load instruction Message-ID: <4BF2D1D1.3040302@cse.iitb.ac.in> Hi, I am trying to perform some kind of PRE. SO I have collected available and anticipable sets, in form of instructions, ie my sets are in form < opcode, (Value *)operand 1, (Value *) operand 2> Now my question is: Suppose at entry of some block my available set has entry: < ADD, %1 = load i32* %a, align 4 , %2 = load i32* %b, align 4 > and anticipable set has entry : < ADD, %3 = load i32* %a, align 4 , %4 = load i32* %b, align 4 > Now if suppose before %3 and %4 neither a nor b has been modified, then I want to know that %3 is equivalent to %1 and %4 is equivalent to %2. How can I do this. Any Ideas will help. Thanks a lot !! regards, Ambika From evan.cheng at apple.com Tue May 18 13:48:44 2010 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 18 May 2010 11:48:44 -0700 Subject: [LLVMdev] Fast register allocation In-Reply-To: <9F40ACAB-CCB3-4D25-B928-94F71DA44CD4@2pi.dk> References: <65B22F08-991D-45D1-9073-14452A6075B1@2pi.dk> <9F40ACAB-CCB3-4D25-B928-94F71DA44CD4@2pi.dk> Message-ID: <76B48915-D1CE-4C9A-BFCE-A2431E94E3CB@apple.com> On May 18, 2010, at 9:03 AM, Jakob Stoklund Olesen wrote: > > On May 18, 2010, at 8:23 AM, Daniel Dunbar wrote: > >> You mention some potential issues on ARM, should we sort those out >> before we enable it in Clang? It's somewhat more convenient to have >> things be consistent. > > Sure, I'll be testing some ARM code today. There is also Evan's new REG_SEQUENCE instruction to verify. > >> I propose that at some point you just replace the old local register >> allocator with the new one, and rename the old one. Then clients don't >> need to change, and we can keep the old one available for a little >> while if we want, for testing. > > I am not a big fan of renaming - it can easily cause confusion. Besides, fast-alloc goes with fast-isel. > > But perhaps we could take this opportunity to let LLVMTargetMachine choose a register allocator based on the optimization level? It is already enabling fast-isel that way, and -O0 -regalloc=linearscan (which is the default) doesn't really make sense. > > LLVMTargetMachine::addCommonCodeGenPasses does a decent job of building a codegen pipeline, except it needs help picking a register allocator. There is no good reason for that. Agreed. Evan > > /jakob > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From eli.friedman at gmail.com Tue May 18 14:03:34 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 18 May 2010 12:03:34 -0700 Subject: [LLVMdev] when compiling the IR api codes, "g++ internal error" occurred. In-Reply-To: <002b01caf65d$184be960$48e3bc20$@snu.ac.kr> References: <002b01caf65d$184be960$48e3bc20$@snu.ac.kr> Message-ID: 2010/5/18 ??? : > Hello~! > > > > I'm beginner about LLVM. > > > > My purpose is inserting a function call to basic block, which is composed of > IR codes. > > For this, I did following works. > > > > 1) Generate bytecodes from c++ codes > > 2) Generate the C++ codes, composed of LLVM APIs. > > $ llc -march=cpp main.bc -o=main_irgen.cpp > > 3) Insert function call APIs to the generated C++ codes from step 2) > > 4) Compile the functional call inserted codes. > > $ g++ -O2 main_irgen.cpp `llvm-config --cxxflags --ldflags --libs core` -o > main_irgen.cpp > > -> In this step, an error occurred. The messages are as follows > > g++: Internal error: segmentation fault (program cc1plus) > > > > When the generated "main_irgen.cpp" file had 3000~4000 code lines, no error > occurred. But, the file had over 30000 code lines, internal error occurred. If you need to import a IR file that large, you should use the bitcode reader instead of compiling it into your program with "llc -march=cpp". The relevant call is llvm::ParseBitcodeFile. -Eli From jvoung at google.com Tue May 18 14:07:31 2010 From: jvoung at google.com (Jan Voung) Date: Tue, 18 May 2010 12:07:31 -0700 Subject: [LLVMdev] selection dag speedups / llc speedups In-Reply-To: <18C9B7A6-1A2D-44A8-BB00-835E1F9637AA@2pi.dk> References: <18C9B7A6-1A2D-44A8-BB00-835E1F9637AA@2pi.dk> Message-ID: Here are some recent stats of the fast vs local vs linear scan at O0 on "opt -std-compile-opts" processed bitcode files. The fast regalloc is still certainly faster at codegen than local with such bitcode files. Let me know if the link doesn't work: https://spreadsheets.google.com/a/google.com/ccc?key=0At5EJFcCBf-wdDgtd2FoZjU4bFBzcFBtT25rQkgzMEE&hl=en Misc stuff: I ran into an "UNREACHABLE executed" using linear scan on revision 104021, so I used an older version for that. 0 llc.hg 0x0000000000af4d7f 1 llc.hg 0x0000000000af54fa 2 libpthread.so.0 0x00007fb1734b67d0 3 libc.so.6 0x00007fb1725d2095 gsignal + 53 4 libc.so.6 0x00007fb1725d3af0 abort + 272 5 llc.hg 0x0000000000ad4932 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 370 6 llc.hg 0x0000000000886426 llvm::LiveIntervals::handleVirtualRegisterDef(llvm::MachineBasicBlock*, llvm::ilist_iterator, llvm::SlotIndex, llvm::MachineOperand&, unsigned int, llvm::LiveInterval&) + 3910 7 llc.hg 0x0000000000888429 llvm::LiveIntervals::handleRegisterDef(llvm::MachineBasicBlock*, llvm::ilist_iterator, llvm::SlotIndex, llvm::MachineOperand&, unsigned int) + 409 8 llc.hg 0x000000000088ade0 llvm::LiveIntervals::computeIntervals() + 2496 9 llc.hg 0x000000000088b56f llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&) + 447 10 llc.hg 0x00000000007b3493 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 115 11 llc.hg 0x0000000000a79ec0 llvm::FPPassManager::runOnFunction(llvm::Function&) + 688 12 llc.hg 0x0000000000a79f13 llvm::FPPassManager::runOnModule(llvm::Module&) + 67 13 llc.hg 0x0000000000a79a63 llvm::MPPassManager::runOnModule(llvm::Module&) + 515 14 llc.hg 0x0000000000a79b42 llvm::PassManagerImpl::run(llvm::Module&) + 114 15 llc.hg 0x0000000000a79bdd llvm::PassManager::run(llvm::Module&) + 13 16 llc.hg 0x00000000004d3112 main + 2802 17 libc.so.6 0x00007fb1725be1c4 __libc_start_main + 244 18 llc.hg 0x00000000004d0b09 Stack dump: 0. Program arguments: llc.hg -asm-verbose=false -O0 32/403.gcc/403.gcc.linked.bc -o 32/403.gcc/output/403.gcc.linked.bc.llc_O0.s 1. Running pass 'Function Pass Manager' on module '32/403.gcc/403.gcc.linked.bc'. 2. Running pass 'Live Interval Analysis' on function '@nonlocal_mentioned_p' - Jan On Mon, May 17, 2010 at 9:33 PM, Jakob Stoklund Olesen wrote: > > On May 17, 2010, at 9:09 PM, Rafael Espindola wrote: > > >> The fast and local register allocators are meant to be used on > unoptimized code, a 'Debug build'. While they do work on optimized code, > they do not give good results. Their primary goal is compile time, not code > quality. > > > > Yes, we have a somewhat uncommon use case. It is fine to spend time > > optimizing bitcode (LTO is a OK), but we want to make the final IL -> > > Executable translation as fast as possible. > > Do you know how the fast allocator performs in these conditions? Have you > compared it to the local allocator? I really focused my efforts on > unoptimized code. > > /jakob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100518/c8ad5349/attachment.html From nicholas at mxc.ca Wed May 19 00:44:46 2010 From: nicholas at mxc.ca (Nick Lewycky) Date: Tue, 18 May 2010 22:44:46 -0700 Subject: [LLVMdev] selection dag speedups / llc speedups In-Reply-To: References: <18C9B7A6-1A2D-44A8-BB00-835E1F9637AA@2pi.dk> Message-ID: <4BF37ACE.2020707@mxc.ca> Jan Voung wrote: > Here are some recent stats of the fast vs local vs linear scan at O0 on > "opt -std-compile-opts" processed bitcode files. The fast regalloc is > still certainly faster at codegen than local with such bitcode files. > Let me know if the link doesn't work: > > https://spreadsheets.google.com/a/google.com/ccc?key=0At5EJFcCBf-wdDgtd2FoZjU4bFBzcFBtT25rQkgzMEE&hl=en > Hi Jan, See the "/a/google.com/" part of the URL? Yeah, people without google.com logins can't read that. There's no way to use docs to produce a document with your work account that is readable to the outside world, I've complained about it before. Export it instead. Nick > Misc stuff: I ran into an "UNREACHABLE executed" using linear scan on > revision 104021, so I used an older version for that. > > 0 llc.hg 0x0000000000af4d7f > 1 llc.hg 0x0000000000af54fa > 2 libpthread.so.0 0x00007fb1734b67d0 > 3 libc.so.6 0x00007fb1725d2095 gsignal + 53 > 4 libc.so.6 0x00007fb1725d3af0 abort + 272 > 5 llc.hg 0x0000000000ad4932 > llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) > + 370 > 6 llc.hg 0x0000000000886426 > llvm::LiveIntervals::handleVirtualRegisterDef(llvm::MachineBasicBlock*, > llvm::ilist_iterator, llvm::SlotIndex, > llvm::MachineOperand&, unsigned int, llvm::LiveInterval&) + 3910 > 7 llc.hg 0x0000000000888429 > llvm::LiveIntervals::handleRegisterDef(llvm::MachineBasicBlock*, > llvm::ilist_iterator, llvm::SlotIndex, > llvm::MachineOperand&, unsigned int) + 409 > 8 llc.hg 0x000000000088ade0 > llvm::LiveIntervals::computeIntervals() + 2496 > 9 llc.hg 0x000000000088b56f > llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&) + 447 > 10 llc.hg 0x00000000007b3493 > llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 115 > 11 llc.hg 0x0000000000a79ec0 > llvm::FPPassManager::runOnFunction(llvm::Function&) + 688 > 12 llc.hg 0x0000000000a79f13 > llvm::FPPassManager::runOnModule(llvm::Module&) + 67 > 13 llc.hg 0x0000000000a79a63 > llvm::MPPassManager::runOnModule(llvm::Module&) + 515 > 14 llc.hg 0x0000000000a79b42 > llvm::PassManagerImpl::run(llvm::Module&) + 114 > 15 llc.hg 0x0000000000a79bdd > llvm::PassManager::run(llvm::Module&) + 13 > 16 llc.hg 0x00000000004d3112 main + 2802 > 17 libc.so.6 0x00007fb1725be1c4 __libc_start_main + 244 > 18 llc.hg 0x00000000004d0b09 > > > Stack dump: > 0. Program arguments: llc.hg -asm-verbose=false -O0 > 32/403.gcc/403.gcc.linked.bc -o > 32/403.gcc/output/403.gcc.linked.bc.llc_O0.s > 1. Running pass 'Function Pass Manager' on module > '32/403.gcc/403.gcc.linked.bc'. > 2. Running pass 'Live Interval Analysis' on function > '@nonlocal_mentioned_p' > > - Jan > > On Mon, May 17, 2010 at 9:33 PM, Jakob Stoklund Olesen > wrote: > > > On May 17, 2010, at 9:09 PM, Rafael Espindola wrote: > > >> The fast and local register allocators are meant to be used on > unoptimized code, a 'Debug build'. While they do work on optimized > code, they do not give good results. Their primary goal is compile > time, not code quality. > > > > Yes, we have a somewhat uncommon use case. It is fine to spend time > > optimizing bitcode (LTO is a OK), but we want to make the final IL -> > > Executable translation as fast as possible. > > Do you know how the fast allocator performs in these conditions? > Have you compared it to the local allocator? I really focused my > efforts on unoptimized code. > > /jakob > > > > > _______________________________________________ > 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 May 19 04:06:54 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 19 May 2010 13:06:54 +0400 Subject: [LLVMdev] ARM EABI Exceptions In-Reply-To: References: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> Message-ID: Hello, Renato > Are you actively working in that area? No, I started to experiment with ARM EH ~year ago, but never had anything complete, unfortunately > My main concern is that DwarfException is not extensible at all. I can't inherit from it (DwarfWriter creates it directly) and there are no call backs to target-specific code (nor registration of such mechanism). Why do you need this? My feeling that this will not be required. I might be mistaken though. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From renato.golin at arm.com Wed May 19 04:37:41 2010 From: renato.golin at arm.com (Renato Golin) Date: Wed, 19 May 2010 10:37:41 +0100 Subject: [LLVMdev] ARM EABI Exceptions In-Reply-To: References: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> Message-ID: <000501caf736$edbf43b0$c93dcb10$@golin@arm.com> > -----Original Message----- > > My main concern is that DwarfException is not extensible at all. I > > can't inherit from it (DwarfWriter creates it directly) and there are > > no call backs to target-specific code (nor registration of such > > mechanism). > > Why do you need this? My feeling that this will not be required. I > might be mistaken though. Hi Anton, Maybe I'm following the wrong path, then. When trying to make llc print the EH table for clang-compiled IR, I noticed that there was none. If I turn on the Dwarf exception in ARMMCAsmInfo, I could see a table that looks like GCC's. ARM EHABI tables are quite different and the idea is not to produce them now, but to make clang generated asm/objects to be compiled/linked with arm-none-eabi-gcc. In that area, I was trying to make LLVM DwarfException more like GCC's, and for that I had to make some changes in the order things appear (the table is inside the function instead of in a new section, thus the size has to appear after the table), and add new things (.fnstart, .fnend, .personality, etc), and make sure all Actions are in conformance with GCC's intrinsics. Also, looks like gcc doesn't produce the CIE nor any of the FDEs, so maybe I have to suppress that as well. For all those changes, the only place I can implement, AFAIK, is DwarfException. Now, as a local hack, I have added a new ExceptionABI { None, ARM }; enum to MCAsmInfo to if/else inside DwarfException, but that's far from ideal. I'd like to be able to have with DwarfException the same we have with AsmPrinter, calling target-implemented functions (like EmitFunctionBodyStart, etc), so one could customise the particular differences of a target. But this change is a bit wide-spread, since DwarfWriter will also have to be changed to create a target-specific exception writer rather than the generic one. But again, maybe the whole thing is pointless, and clang already generates exception tables compatible with eabi-gcc and I was not able to make it work. Cheers, --renato From o.j.sivart at gmail.com Wed May 19 09:07:07 2010 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Wed, 19 May 2010 23:37:07 +0930 Subject: [LLVMdev] Intrinsics and dead instruction/code elimination Message-ID: <925848B4-69AB-49AE-ACF9-AA3CB792D892@gmail.com> Hi all, I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. If I have some sequence (> 1) of llvm.*.with.overflow.* intrinsics, as in the form of: @global = global i32 0 define void @fun() { entry: %res1 = call {i32, i1} @llvm.*.with.overflow.i32(i32 %a, i32 %b) %sum1 = extractvalue {i32, i1} %res, 0 %obit1 = extractvalue {i32, i1} %res, 1 store i32 %obit1, i32* @global ... %res2 = call {i32, i1} @llvm.*.with.overflow.i32(i32 %a, i32 %b) %sum2 = extractvalue {i32, i1} %res, 0 %obit2 = extractvalue {i32, i1} %res, 1 store i32 %obit2, i32* @global } then I assume an optimisation pass is able to eliminate the store i32 %obit1, i32* @global, since store i32 %obit2, i32* @global clearly clobbers the global without any interleaving load/access. However, my question is whether representing code as an intrinsic limits further dead instruction/code elimination. In this case, the intrinsic will produce an arithmetic operation followed by a setcc on overflow on x86. Given the first store is dead, the first setcc on overflow instruction is also dead and can be eliminated. Is LLVM capable of such elimination with intrinsics, or is the expectation that an optimisation pass replace llvm.*.with.overflow.* intrinsics with their corresponding non-intrinsic arithmetics operations in order to achieve the same result, or is there another solution? Thanks in advance From asger at area9.dk Wed May 19 09:06:25 2010 From: asger at area9.dk (Asger Ottar Alstrup) Date: Wed, 19 May 2010 16:06:25 +0200 Subject: [LLVMdev] First proof of concept of a LLVM driven backend for the neko virtual machine Message-ID: Hi, Vadim Atlygin has been working on a LLVM backend for Neko, and we are happy to announce that "Hello world" works now. For LLVM readers, Neko is a tight virtual machine, which is primarily targetted by haXe. haXe is a statically typed programming language that has targets to JavaScript, Flash, as well as Neko. Both haXe and Neko are developed by Nicolas Cannasse, with contributions from many others. You can read more about haXe and Neko at www.haxe.org and www.nekovm.org. The current neko vm has a x86 JIT. The aim of this work is to get the Neko VM to run fast on 64 bit machines, and hopefully improve performance on 32 bit targets as well. You can get the code from this repository: http://github.com/vava/neko_llvm_jit The work is still incomplete - only the first 10 opcodes out of 66 are implemented, but there is enough to get "Hello world" and simple arithmetic to work. The current port is still slower than the existing VM, but that is expected.?The next steps are to implement the rest of the opcodes. At first, we will just plug them up to use c callbacks, and then as a next step, convert them to real LLVM bytecodes later. Until we have real LLVM produced for the opcodes, it will be slower than the original VM. If you want to help out, you can contribute test cases for opcodes, implement c callback implementations for some of the opcodes, or even better optimized code for opcodes. We propose to use the Neko mailing list for discussion on this. Regards, Vadim Atlygin & Asger Ottar Alstrup From franco.ponticelli at gmail.com Wed May 19 09:33:54 2010 From: franco.ponticelli at gmail.com (Franco Ponticelli) Date: Wed, 19 May 2010 15:33:54 +0100 Subject: [LLVMdev] [Neko] First proof of concept of a LLVM driven backend for the neko virtual machine In-Reply-To: References: Message-ID: Great and very appreaciated news! Out of curiosity, why have you decided to translate Neko to LLVM instead of creating a new target for haXe? This project is awesome ;) Franco. On Wed, May 19, 2010 at 3:06 PM, Asger Ottar Alstrup wrote: > Hi, > > Vadim Atlygin has been working on a LLVM backend for Neko, and we are > happy to announce that "Hello world" works now. > > For LLVM readers, Neko is a tight virtual machine, which is primarily > targetted by haXe. haXe is a statically typed programming language > that has targets to JavaScript, Flash, as well as Neko. Both haXe and > Neko are developed by Nicolas Cannasse, with contributions from many > others. You can read more about haXe and Neko at www.haxe.org and > www.nekovm.org. > > The current neko vm has a x86 JIT. The aim of this work is to get the > Neko VM to run fast on 64 bit machines, and hopefully improve > performance on 32 bit targets as well. > > You can get the code from this repository: > http://github.com/vava/neko_llvm_jit > > The work is still incomplete - only the first 10 opcodes out of 66 are > implemented, but there is enough to get "Hello world" and simple > arithmetic to work. The current port is still slower than the existing > VM, but that is expected. The next steps are to implement the rest of > the opcodes. At first, we will just plug them up to use c callbacks, > and then as a next step, convert them to real LLVM bytecodes later. > Until we have real LLVM produced for the opcodes, it will be slower > than the original VM. > > If you want to help out, you can contribute test cases for opcodes, > implement c callback implementations for some of the opcodes, or even > better optimized code for opcodes. We propose to use the Neko mailing > list for discussion on this. > > Regards, > Vadim Atlygin & Asger Ottar Alstrup > > -- > Neko : One VM to run them all > (http://nekovm.org) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100519/bb0fcb43/attachment.html From lee at designrealm.co.uk Wed May 19 09:37:06 2010 From: lee at designrealm.co.uk (Lee McColl Sylvester) Date: Wed, 19 May 2010 15:37:06 +0100 Subject: [LLVMdev] [Neko] First proof of concept of a LLVM driven backend for the neko virtual machine In-Reply-To: References: Message-ID: <4BF3F792.1030303@designrealm.co.uk> Excellent work. This is a very cool idea. Do you have any clue as to the kind of overall speed increases we'll likely expect when this project reaches its target milestone? Cheers, Lee Asger Ottar Alstrup wrote: > Hi, > > Vadim Atlygin has been working on a LLVM backend for Neko, and we are > happy to announce that "Hello world" works now. > > For LLVM readers, Neko is a tight virtual machine, which is primarily > targetted by haXe. haXe is a statically typed programming language > that has targets to JavaScript, Flash, as well as Neko. Both haXe and > Neko are developed by Nicolas Cannasse, with contributions from many > others. You can read more about haXe and Neko at www.haxe.org and > www.nekovm.org. > > The current neko vm has a x86 JIT. The aim of this work is to get the > Neko VM to run fast on 64 bit machines, and hopefully improve > performance on 32 bit targets as well. > > You can get the code from this repository: > http://github.com/vava/neko_llvm_jit > > The work is still incomplete - only the first 10 opcodes out of 66 are > implemented, but there is enough to get "Hello world" and simple > arithmetic to work. The current port is still slower than the existing > VM, but that is expected. The next steps are to implement the rest of > the opcodes. At first, we will just plug them up to use c callbacks, > and then as a next step, convert them to real LLVM bytecodes later. > Until we have real LLVM produced for the opcodes, it will be slower > than the original VM. > > If you want to help out, you can contribute test cases for opcodes, > implement c callback implementations for some of the opcodes, or even > better optimized code for opcodes. We propose to use the Neko mailing > list for discussion on this. > > Regards, > Vadim Atlygin & Asger Ottar Alstrup > > From stoklund at 2pi.dk Wed May 19 10:58:22 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Wed, 19 May 2010 08:58:22 -0700 Subject: [LLVMdev] selection dag speedups / llc speedups In-Reply-To: References: <18C9B7A6-1A2D-44A8-BB00-835E1F9637AA@2pi.dk> Message-ID: <3D055A6A-BF62-4852-8CD6-6F93837B18A8@2pi.dk> On May 18, 2010, at 12:07 PM, Jan Voung wrote: > Here are some recent stats of the fast vs local vs linear scan at O0 on "opt -std-compile-opts" processed bitcode files. The fast regalloc is still certainly faster at codegen than local with such bitcode files. Let me know if the link doesn't work: > > https://spreadsheets.google.com/a/google.com/ccc?key=0At5EJFcCBf-wdDgtd2FoZjU4bFBzcFBtT25rQkgzMEE&hl=en Sorry, can't read that. > Misc stuff: I ran into an "UNREACHABLE executed" using linear scan on revision 104021, so I used an older version for that. Please use bugpoint to reduce the test case and then submit a PR. bugpoint -run-llc 403.gcc.linked.bc -tool-args -asm-verbose=false -O0 Thanks, /jakob From grosbach at apple.com Wed May 19 11:03:20 2010 From: grosbach at apple.com (Jim Grosbach) Date: Wed, 19 May 2010 09:03:20 -0700 Subject: [LLVMdev] ARM EABI Exceptions In-Reply-To: <000501caf736$edbf43b0$c93dcb10$%golin@arm.com> References: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> <000501caf736$edbf43b0$c93dcb10$%golin@arm.com> Message-ID: <8B8FC372-CCFC-459F-8868-0B01032FB3BD@apple.com> On May 19, 2010, at 2:37 AM, Renato Golin wrote: >> -----Original Message----- >>> My main concern is that DwarfException is not extensible at all. I >>> can't inherit from it (DwarfWriter creates it directly) and there are >>> no call backs to target-specific code (nor registration of such >>> mechanism). >> >> Why do you need this? My feeling that this will not be required. I >> might be mistaken though. > > Hi Anton, > > Maybe I'm following the wrong path, then. > > When trying to make llc print the EH table for clang-compiled IR, I noticed that there was none. If I turn on the Dwarf exception in ARMMCAsmInfo, I could see a table that looks like GCC's. ARM EHABI tables are quite different and the idea is not to produce them now, but to make clang generated asm/objects to be compiled/linked with arm-none-eabi-gcc. > > In that area, I was trying to make LLVM DwarfException more like GCC's, and for that I had to make some changes in the order things appear (the table is inside the function instead of in a new section, thus the size has to appear after the table), and add new things (.fnstart, .fnend, .personality, etc), and make sure all Actions are in conformance with GCC's intrinsics. Also, looks like gcc doesn't produce the CIE nor any of the FDEs, so maybe I have to suppress that as well. > > For all those changes, the only place I can implement, AFAIK, is DwarfException. Now, as a local hack, I have added a new ExceptionABI { None, ARM }; enum to MCAsmInfo to if/else inside DwarfException, but that's far from ideal. > > I'd like to be able to have with DwarfException the same we have with AsmPrinter, calling target-implemented functions (like EmitFunctionBodyStart, etc), so one could customise the particular differences of a target. But this change is a bit wide-spread, since DwarfWriter will also have to be changed to create a target-specific exception writer rather than the generic one. > > But again, maybe the whole thing is pointless, and clang already generates exception tables compatible with eabi-gcc and I was not able to make it work. > It's likely there will be some work to get DWARF EH working for ARM. That said, keep in mind that the goal is to get the code to conform to the ABI, not to produce code and tables that look the same as what GCC produces. The former is reasonable, the latter is going to feel like tilting at windmills, as the internal EH representations in gcc are very different than what llvm IR represents. GCC uses a side-table of EH "regions" that it references to determine call sites and such, for example. LLVM doesn't have that concept and uses the invoke instruction instead. One result of this is that the tables that come out often look quite different. So long as they adhere to the spec, though, the code will interoperate correctly. Regards, Jim From jvoung at google.com Wed May 19 11:13:20 2010 From: jvoung at google.com (Jan Voung) Date: Wed, 19 May 2010 09:13:20 -0700 Subject: [LLVMdev] selection dag speedups / llc speedups In-Reply-To: <3D055A6A-BF62-4852-8CD6-6F93837B18A8@2pi.dk> References: <18C9B7A6-1A2D-44A8-BB00-835E1F9637AA@2pi.dk> <3D055A6A-BF62-4852-8CD6-6F93837B18A8@2pi.dk> Message-ID: Ah ok, thanks for the tip Nick. Here's another try: http://spreadsheets.google.com/ccc?key=0AjRrJHQc4_bddDhwWEhRajNDbWozZjk1YUVMWnZKVFE&hl=en > > Misc stuff: I ran into an "UNREACHABLE executed" using linear scan on > revision 104021, so I used an older version for that. > > Please use bugpoint to reduce the test case and then submit a PR. > > bugpoint -run-llc 403.gcc.linked.bc -tool-args -asm-verbose=false -O0 > > Ok. - Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100519/842b1edd/attachment.html From renato.golin at arm.com Wed May 19 11:49:50 2010 From: renato.golin at arm.com (Renato Golin) Date: Wed, 19 May 2010 17:49:50 +0100 Subject: [LLVMdev] ARM EABI Exceptions In-Reply-To: <8B8FC372-CCFC-459F-8868-0B01032FB3BD@apple.com> References: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> <000501caf736$edbf43b0$c93dcb10$%golin@arm.com> <8B8FC372-CCFC-459F-8868-0B01032FB3BD@apple.com> Message-ID: <000001caf773$4c52e080$e4f8a180$@golin@arm.com> Hi Jim, > -----Original Message----- > It's likely there will be some work to get DWARF EH working for ARM. Tell me about it! ;) > That said, keep in mind that the goal is to get the code to conform to > the ABI, not to produce code and tables that look the same as what GCC > produces. Absolutely. I'm only trying to get exception handling working on ARM. Right now, I'm linking with eabi-gcc, and because clang's table is similar, I thought I could adapt it. Unfortunately, the testability is nil and the end goal is not good, so the task is probably not worth it. > The former is reasonable, the latter is going to feel like > tilting at windmills, as the internal EH representations in gcc are > very different than what llvm IR represents. GCC uses a side-table of > EH "regions" that it references to determine call sites and such, for > example. LLVM doesn't have that concept and uses the invoke instruction > instead. One result of this is that the tables that come out often look > quite different. As I gathered, the invoke calls were populating the call site table, similar to the .LEH regions GCC does, and the call site table of both look quite similar, to me. I noticed more differences around the call table, for instance, the headers, the type info actions and the relocation information. Also, the normal flow (try/catch blocks, with cleanup regions and intrinsic calls) didn't seem that different. > So long as they adhere to the spec, though, the code > will interoperate correctly. The spec is quite vague when expressing the personality routines, AFAICT. If the tables are different, when you link code compiled with Clang and GCC, both using the same personality routine (GCC's or Clang's, but not both), how do you expect them to work together? Nevertheless, I digress. I may have started it the wrong way, but my immediate goal is to compile a simple exception example to ARM. Do you know a better path? Cheers, --renato From aran at 100acres.us Wed May 19 12:13:57 2010 From: aran at 100acres.us (Aran Clauson) Date: Wed, 19 May 2010 10:13:57 -0700 Subject: [LLVMdev] Scheduled Instructions go missing Message-ID: <201005191014.07799.aran@100acres.us> All, I'm working on a new scheduler. I have a basic block for which my scheduler generates bad code. The C code looks like int j, *p; if ((j = *p++) != 0) {...} My scheduler emits (x86, AT&T) mov p, %rax mov (%rax), %rax mov %rax, j addq $0x04, p je ... Notice there is no test instruction. The default list scheduler generates mov p, %rax mov (%rax), %rax mov %rax, j addq $0x04, p test %rax je ... The sequence generated by both schedulers after scheduling and before emission and they are the same. Specifically, the test instruction is present in both sequences at the same point. I'm thinking that there is something I set in the SUnits, but I don't know what that would be. Any ideas? Aran -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100519/641d8988/attachment.bin From anton at korobeynikov.info Wed May 19 12:31:06 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 19 May 2010 21:31:06 +0400 Subject: [LLVMdev] ARM EABI Exceptions In-Reply-To: <-3083918327517067516@unknownmsgid> References: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> <000501caf736$edbf43b0$c93dcb10$%golin@arm.com> <8B8FC372-CCFC-459F-8868-0B01032FB3BD@apple.com> <-3083918327517067516@unknownmsgid> Message-ID: Hello, Renato > If the tables are different, when you link code compiled with Clang and GCC, > both using the same personality routine (GCC's or Clang's, but not both), > how do you expect them to work together? Because both tables are "standard" ? > Nevertheless, I digress. I may have started it the wrong way, but my > immediate goal is to compile a simple exception example to ARM. Do you know > a better path? Here is how EH was implemented first for x86: 1. LLVM was made to emit tables for some "easy" examples, this involves some low-level stuff like register moves, encoding, etc. At this point one can use LLVM-generated .s files with gcc-provided unwinding library. 2. Necessary EH intrinsics was implemented 3. More refinements (PIC mode, etc.) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From clattner at apple.com Wed May 19 12:31:50 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 19 May 2010 10:31:50 -0700 Subject: [LLVMdev] Intrinsics and dead instruction/code elimination In-Reply-To: <925848B4-69AB-49AE-ACF9-AA3CB792D892@gmail.com> References: <925848B4-69AB-49AE-ACF9-AA3CB792D892@gmail.com> Message-ID: <7EA4BA36-77B8-4275-871B-B0647E21DA9C@apple.com> On May 19, 2010, at 7:07 AM, o.j.sivart at gmail.com wrote: > Hi all, > > I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. > > If I have some sequence (> 1) of llvm.*.with.overflow.* intrinsics, as in the form of: > > @global = global i32 0 > > define void @fun() { > entry: > %res1 = call {i32, i1} @llvm.*.with.overflow.i32(i32 %a, i32 %b) > %sum1 = extractvalue {i32, i1} %res, 0 > %obit1 = extractvalue {i32, i1} %res, 1 > store i32 %obit1, i32* @global > ... > %res2 = call {i32, i1} @llvm.*.with.overflow.i32(i32 %a, i32 %b) > %sum2 = extractvalue {i32, i1} %res, 0 > %obit2 = extractvalue {i32, i1} %res, 1 > store i32 %obit2, i32* @global > } > > then I assume an optimisation pass is able to eliminate the store i32 %obit1, i32* @global, since store i32 %obit2, i32* @global clearly clobbers the global without any interleaving load/access. However, my question is whether representing code as an intrinsic limits further dead instruction/code elimination. In this case, the intrinsic will produce an arithmetic operation followed by a setcc on overflow on x86. Given the first store is dead, the first setcc on overflow instruction is also dead and can be eliminated. Is LLVM capable of such elimination with intrinsics, or is the expectation that an optimisation pass replace llvm.*.with.overflow.* intrinsics with their corresponding non-intrinsic arithmetics operations in order to achieve the same result, or is there another solution? Intrinsics should be optimized as well as instructions. In this specific case, these intrinsics should be marked readnone, which means that load/store optimization will ignore them. Dead code elimination will delete the intrinsic if it is dead etc. Are you seeing this fail on a specific testcase? -Chris From jayasnair at gmail.com Wed May 19 14:01:41 2010 From: jayasnair at gmail.com (JayaSus) Date: Wed, 19 May 2010 12:01:41 -0700 (PDT) Subject: [LLVMdev] hexcode from llvm Message-ID: <28612686.post@talk.nabble.com> Hi all, I am doing emulation on a custom processor. For this I need hexcode for the C application program . Is there any llvm command/function that can spit out the hexcode just like objdump in gcc? Thanks -- View this message in context: http://old.nabble.com/hexcode-from-llvm-tp28612686p28612686.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From jgu222 at gmail.com Wed May 19 16:38:15 2010 From: jgu222 at gmail.com (Junjie Gu) Date: Wed, 19 May 2010 14:38:15 -0700 Subject: [LLVMdev] Support for per-loop pragma Message-ID: Many compilers support per-loop pragma, such as loop unrolling (ie #pragma unroll=2). Is there any LLVM project/effort going on in this area ? What is the expected way for implementing per-loop pragma, or general pragma ? Suggestions/comments ? Thanks Junjie From aran at 100acres.us Wed May 19 16:41:07 2010 From: aran at 100acres.us (Aran Clauson) Date: Wed, 19 May 2010 14:41:07 -0700 Subject: [LLVMdev] Scheduled Instructions go missing In-Reply-To: <201005191014.07799.aran@100acres.us> References: <201005191014.07799.aran@100acres.us> Message-ID: <201005191441.11428.aran@100acres.us> All, Please dissreguard. Aran On Wednesday 19 May 2010 10:13:57 Aran Clauson wrote: > All, > I'm working on a new scheduler. I have a basic block > for which my scheduler generates bad code. The C code > looks like > > int j, *p; > if ((j = *p++) != 0) {...} > > My scheduler emits (x86, AT&T) > mov p, %rax > mov (%rax), %rax > mov %rax, j > addq $0x04, p > je ... > > Notice there is no test instruction. The default list > scheduler generates > > mov p, %rax > mov (%rax), %rax > mov %rax, j > addq $0x04, p > test %rax > je ... > > The sequence generated by both schedulers after > scheduling and before emission and they are the same. > Specifically, the test instruction is present in both > sequences at the same point. > I'm thinking that there is something I set in the > SUnits, but I don't know what that would be. Any ideas? > > Aran -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100519/6713322f/attachment.bin From wendling at apple.com Wed May 19 16:53:57 2010 From: wendling at apple.com (Bill Wendling) Date: Wed, 19 May 2010 14:53:57 -0700 Subject: [LLVMdev] hexcode from llvm In-Reply-To: <28612686.post@talk.nabble.com> References: <28612686.post@talk.nabble.com> Message-ID: <623A32D0-B36B-4020-B098-C44A59B1BC99@apple.com> On May 19, 2010, at 12:01 PM, JayaSus wrote: > > Hi all, > > I am doing emulation on a custom processor. For this I need hexcode for the > C application program . Is there any llvm command/function that can spit out > the hexcode just like objdump in gcc? > Hi JayaSus, I'm confused by your question. Do you mean the LLVM IR "object code" or the resulting native object code generated by the assembler (after code generation) for the target platform? If the latter, then your objdump tools should work with that. -bw From o.j.sivart at gmail.com Wed May 19 17:13:59 2010 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Thu, 20 May 2010 07:43:59 +0930 Subject: [LLVMdev] Intrinsics and dead instruction/code elimination In-Reply-To: <7EA4BA36-77B8-4275-871B-B0647E21DA9C@apple.com> References: <925848B4-69AB-49AE-ACF9-AA3CB792D892@gmail.com> <7EA4BA36-77B8-4275-871B-B0647E21DA9C@apple.com> Message-ID: On 20/05/2010, at 3:01 AM, Chris Lattner wrote: > > On May 19, 2010, at 7:07 AM, o.j.sivart at gmail.com wrote: > >> Hi all, >> >> I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. >> >> If I have some sequence (> 1) of llvm.*.with.overflow.* intrinsics, as in the form of: >> >> @global = global i32 0 >> >> define void @fun() { >> entry: >> %res1 = call {i32, i1} @llvm.*.with.overflow.i32(i32 %a, i32 %b) >> %sum1 = extractvalue {i32, i1} %res, 0 >> %obit1 = extractvalue {i32, i1} %res, 1 >> store i32 %obit1, i32* @global >> ... >> %res2 = call {i32, i1} @llvm.*.with.overflow.i32(i32 %a, i32 %b) >> %sum2 = extractvalue {i32, i1} %res, 0 >> %obit2 = extractvalue {i32, i1} %res, 1 >> store i32 %obit2, i32* @global >> } >> >> then I assume an optimisation pass is able to eliminate the store i32 %obit1, i32* @global, since store i32 %obit2, i32* @global clearly clobbers the global without any interleaving load/access. However, my question is whether representing code as an intrinsic limits further dead instruction/code elimination. In this case, the intrinsic will produce an arithmetic operation followed by a setcc on overflow on x86. Given the first store is dead, the first setcc on overflow instruction is also dead and can be eliminated. Is LLVM capable of such elimination with intrinsics, or is the expectation that an optimisation pass replace llvm.*.with.overflow.* intrinsics with their corresponding non-intrinsic arithmetics operations in order to achieve the same result, or is there another solution? > > Intrinsics should be optimized as well as instructions. In this specific case, these intrinsics should be marked readnone, which means that load/store optimization will ignore them. Dead code elimination will delete the intrinsic if it is dead etc. I understand that dead code elimination is able to delete the intrinsic if it is dead. What I'm interested in is whether or not, despite the entire intrinsic not being dead, anything is able to eliminate the setcc on overflow instruction part of the first intrinsic given that the store of obit1 is dead, thus obit1 is not needed, thus extracting the overflow bit from the CFLAGS register via a setcc instruction is no longer needed. I assume nothing is able to perform such optimisation on intrinsics and my guess is that the only option is, as I said, a pass which rewrites the first intrinsic to just its corresponding arithmetic instruction once a pass has dead store eliminated the first store. Is this the case? > Are you seeing this fail on a specific testcase? No I don't yet have code for the particular testcases I have in mind. I'm just exploring the limitations of intrinsics over instructions. > -Chris From clattner at apple.com Wed May 19 17:45:37 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 19 May 2010 15:45:37 -0700 Subject: [LLVMdev] Support for per-loop pragma In-Reply-To: References: Message-ID: <3C4E8193-369F-4D76-8E14-C23B79D243CE@apple.com> On May 19, 2010, at 2:38 PM, Junjie Gu wrote: > Many compilers support per-loop pragma, such as loop unrolling (ie > #pragma unroll=2). Is there any LLVM project/effort going on > in this area ? What is the expected way for implementing per-loop > pragma, or general pragma ? Suggestions/comments ? Hi Junjie, I don't know of anyone working on it, but it seems like a natural application of the metadata support in mainline: http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html We'd want to tag something, perhaps the backedge branches with metadata, then have the loop canonicalization passes preserve them. -Chris From clattner at apple.com Wed May 19 17:46:17 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 19 May 2010 15:46:17 -0700 Subject: [LLVMdev] Intrinsics and dead instruction/code elimination In-Reply-To: References: <925848B4-69AB-49AE-ACF9-AA3CB792D892@gmail.com> <7EA4BA36-77B8-4275-871B-B0647E21DA9C@apple.com> Message-ID: <93B940A4-6479-4DDE-803A-BD44C7958EFC@apple.com> On May 19, 2010, at 3:13 PM, o.j.sivart at gmail.com wrote: >> >> Intrinsics should be optimized as well as instructions. In this specific case, these intrinsics should be marked readnone, which means that load/store optimization will ignore them. Dead code elimination will delete the intrinsic if it is dead etc. > > I understand that dead code elimination is able to delete the intrinsic if it is dead. What I'm interested in is whether or not, despite the entire intrinsic not being dead, anything is able to eliminate the setcc on overflow instruction part of the first intrinsic given that the store of obit1 is dead, thus obit1 is not needed, thus extracting the overflow bit from the CFLAGS register via a setcc instruction is no longer needed. I assume nothing is able to perform such optimisation on intrinsics and my guess is that the only option is, as I said, a pass which rewrites the first intrinsic to just its corresponding arithmetic instruction once a pass has dead store eliminated the first store. Is this the case? I believe so, but you should write a testcase and see for yourself. -Chris From o.j.sivart at gmail.com Wed May 19 18:25:48 2010 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Thu, 20 May 2010 08:55:48 +0930 Subject: [LLVMdev] Intrinsics and dead instruction/code elimination In-Reply-To: <93B940A4-6479-4DDE-803A-BD44C7958EFC@apple.com> References: <925848B4-69AB-49AE-ACF9-AA3CB792D892@gmail.com> <7EA4BA36-77B8-4275-871B-B0647E21DA9C@apple.com> <93B940A4-6479-4DDE-803A-BD44C7958EFC@apple.com> Message-ID: <0C61977F-1AD7-43BC-A667-21437588BD89@gmail.com> On 20/05/2010, at 8:16 AM, Chris Lattner wrote: > > On May 19, 2010, at 3:13 PM, o.j.sivart at gmail.com wrote: > >>> >>> Intrinsics should be optimized as well as instructions. In this specific case, these intrinsics should be marked readnone, which means that load/store optimization will ignore them. Dead code elimination will delete the intrinsic if it is dead etc. >> >> I understand that dead code elimination is able to delete the intrinsic if it is dead. What I'm interested in is whether or not, despite the entire intrinsic not being dead, anything is able to eliminate the setcc on overflow instruction part of the first intrinsic given that the store of obit1 is dead, thus obit1 is not needed, thus extracting the overflow bit from the CFLAGS register via a setcc instruction is no longer needed. I assume nothing is able to perform such optimisation on intrinsics and my guess is that the only option is, as I said, a pass which rewrites the first intrinsic to just its corresponding arithmetic instruction once a pass has dead store eliminated the first store. Is this the case? > > I believe so, but you should write a testcase and see for yourself. I'll certainly do that before I start implementing additional intrinsics, since the llvm.*.with.overflow.* intrinsics are a simple subset of the overall optimisations I'm interested in exploring. The reason I'm interested in whether or not the setcc on overflow instruction part of the first intrinsic is able to be eliminated directly, instead of being eliminated indirectly via a pass which replaces llvm.*.with.overflow.* intrinsics with their corresponding non-intrinsic arithmetic operations, is because I'm interested in an intrinsic of the form lvm.*.with.carry.overflow.zero.sign.* which enables the extraction of the CF, OF, ZF, and SF values from the FLAGS register, where any combination of the extraction may not be needed, since at in the general case most will be clobbered. If it is the case that the indirect approach to elimination is the only approach, this means I need to write all 14 subsets of the intrinsic. At this point it's probably worth instead considering just writing some instructions and supporting a limited set of passes. From jgu222 at gmail.com Wed May 19 18:31:58 2010 From: jgu222 at gmail.com (Junjie Gu) Date: Wed, 19 May 2010 16:31:58 -0700 Subject: [LLVMdev] Support for per-loop pragma In-Reply-To: <3C4E8193-369F-4D76-8E14-C23B79D243CE@apple.com> References: <3C4E8193-369F-4D76-8E14-C23B79D243CE@apple.com> Message-ID: Hi Chris, Thanks. I will see what I can do for this. Junjie On Wed, May 19, 2010 at 3:45 PM, Chris Lattner wrote: > > On May 19, 2010, at 2:38 PM, Junjie Gu wrote: > >> Many compilers support per-loop pragma, such as loop unrolling (ie >> #pragma unroll=2). ?Is there any LLVM project/effort going on >> in this area ? What is the expected way for implementing per-loop >> pragma, or general pragma ? ?Suggestions/comments ? > > Hi Junjie, > > I don't know of anyone working on it, but it seems like a natural application of the metadata support in mainline: > http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html > > We'd want to tag something, perhaps the backedge branches with metadata, then have the loop canonicalization passes preserve them. > > -Chris From nhowell at ebay.com Wed May 19 19:59:08 2010 From: nhowell at ebay.com (Howell, Nathan) Date: Wed, 19 May 2010 18:59:08 -0600 Subject: [LLVMdev] crash in 2.7: SCCPSolver::ResolvedUndefsIn Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEA83EE4A76@DEN-MEXMS-001.corp.ebay.com> Are there any known issues with the ResolvedUndefsIn in 2.7? We've hit this particular stack a couple times now in the JIT. I've copied the failing bitcode to disk and doesn't crash opt or llc. It doesn't repro easily in the JIT either, but the stack is always the same... hoping it's a known issue. Thanks! TerminatorInst *TI = BB->getTerminator(); >>>>if (BranchInst *BI = dyn_cast(TI)) { if (!BI->isConditional()) continue; #0 llvm::Value::getValueID (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/include/llvm/Value.h:247 #1 llvm::Instruction::getOpcode (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/include/llvm/Instruction.h:80 #2 llvm::BranchInst::classof (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/include/llvm/Instructions.h:2083 #3 isa_impl (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/include/llvm/Support/Casting.h:54 #4 llvm::isa_impl_wrap::doit (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/include/llvm/Support/Casting.h:71 #5 isa (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/include/llvm/Support/Casting.h:83 #6 isa (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/include/llvm/Support/Casting.h:101 #7 isa (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/include/llvm/Support/Casting.h:116 #8 dyn_cast (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/include/llvm/Support/Casting.h:226 #9 ResolvedUndefsIn (this=0xfffffd7fecbef3c0, F=) at ./llvm-2.7/lib/Transforms/Scalar/SCCP.cpp:1525 #10 0xfffffd7ffd5b5b26 in runOnModule (this=, M=) at ./llvm-2.7/lib/Transforms/Scalar/SCCP.cpp:1781 #11 0xfffffd7ffd73a558 in llvm::MPPassManager::runOnModule (this=0x6f6dff00, M=...) at ./llvm-2.7/lib/VMCore/PassManager.cpp:1424 #12 0xfffffd7ffd73a67b in llvm::PassManagerImpl::run (this=0x98d417c0, M=...) at ./llvm-2.7/lib/VMCore/PassManager.cpp:1506 From rnk at mit.edu Wed May 19 23:16:29 2010 From: rnk at mit.edu (Reid Kleckner) Date: Thu, 20 May 2010 00:16:29 -0400 Subject: [LLVMdev] hexcode from llvm In-Reply-To: <623A32D0-B36B-4020-B098-C44A59B1BC99@apple.com> References: <28612686.post@talk.nabble.com> <623A32D0-B36B-4020-B098-C44A59B1BC99@apple.com> Message-ID: Wild guess from microcontroller-land: Do you mean you need an Intel HEX file? LLVM doesn't know anything about that. Reid On Wed, May 19, 2010 at 5:53 PM, Bill Wendling wrote: > On May 19, 2010, at 12:01 PM, JayaSus wrote: > >> >> Hi all, >> >> I am doing emulation on a custom processor. For this I need hexcode for the >> C application program . Is there any llvm command/function that can spit out >> the hexcode just like objdump in gcc? >> > Hi JayaSus, > > I'm confused by your question. Do you mean the LLVM IR "object code" or the resulting native object code generated by the assembler (after code generation) for the target platform? If the latter, then your objdump tools should work with that. > > -bw > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From blunted2night at gmail.com Thu May 20 00:31:27 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 19 May 2010 22:31:27 -0700 Subject: [LLVMdev] Win32 COFF Support Message-ID: Hi guys, I have attached my patch to support generating win32 COFF object files. I would have posted earlier, but my system drive crashed and I had to rebuild my system; Luckily, my source code was on a secondary drive. I think this would be a good beginning for ongoing support of the COFF object file format and was hoping for some feedback as to whether it was commit worthy or what was needed to be done to get it their. Thanks, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100519/273d1b9f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: changes.patch Type: application/octet-stream Size: 46845 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100519/273d1b9f/attachment-0001.obj From eli.friedman at gmail.com Thu May 20 02:28:50 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 20 May 2010 00:28:50 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: On Wed, May 19, 2010 at 10:31 PM, Nathan Jeffords wrote: > Hi guys, > I have attached my patch to support generating win32 COFF object files. I > would have posted earlier, but my system drive crashed and I had to rebuild > my system; Luckily, my source code was on a secondary drive. I think this > would be a good beginning for ongoing support of the COFF object file format > and was hoping for some feedback as to whether it was commit worthy or what > was needed to be done to get it their. The line for commit-worthy is a round of reviews and some tests showing that basic functionality works. Minor comments: 1. Is it possible to allocate extra memory with coff::symbol instead of using std::string and std::vector as class members? The extra allocations can add up. 2. For the following bit: + reinterpret_cast (Section->Symbol->Aux [0]) = Section->Header.SizeOfRawData; + reinterpret_cast (Section->Symbol->Aux [4]) = Section->Header.NumberOfRelocations; + reinterpret_cast (Section->Symbol->Aux [6]) = Section->Header.PointerToLineNumbers; This isn't endian-safe; I'd suggest expanding it to 8 assignments. Same issues with the write_le functions. We need endian safety not only so that cross-compiling, for example, from PPC Linux to MingW works, but also so that tests work cross-platform. 3. For the following bit: + typedef std::list symbols; + typedef std::list sections; Avoid std::list; see http://llvm.org//docs/ProgrammersManual.html#dss_list . 4. For the following bit: + typedef StringMap name_symbol_map; + typedef StringMap name_section_map; Unused typedefs? 5. For the following bit (and a few others in the same function): + for (i = Sections.begin(), j = Asm.begin(); + (i != Sections.end()) && (j != Asm.end()); + i++, j++) { http://llvm.org//docs/CodingStandards.html#ll_end 6. +namespace llvm { MCObjectWriter * createWinCOFFObjectWriter (raw_ostream & OS); } If you need a function to be visible across files, use a header; shortcuts like this make the code more difficult to read. -Eli From renato.golin at arm.com Thu May 20 03:55:49 2010 From: renato.golin at arm.com (Renato Golin) Date: Thu, 20 May 2010 09:55:49 +0100 Subject: [LLVMdev] ARM EABI Exceptions In-Reply-To: References: <1274115755.15868.7.camel@e102138-lin.cambridge.arm.com> <000501caf736$edbf43b0$c93dcb10$%golin@arm.com> <8B8FC372-CCFC-459F-8868-0B01032FB3BD@apple.com> <-3083918327517067516@unknownmsgid> Message-ID: <000101caf7fa$3ec39450$bc4abcf0$@golin@arm.com> Hi Anton, > Because both tables are "standard" ? Ok, we're in different pages, I think. I trust that LLVM is binary compatible with GCC, including the exception tables, for x86. What I was referring to is about the LLVM's x86 EH table compatibility with ARM GCC's personality routine. I'm not an expert in exception handling, so I don't know all the idiosyncrasies of both standards, but I guessed that hoping ARM PRs to understand x86 tables was a bit too far. As far as I read and dug, both standards are very similar, but I can't yet guarantee that all PRs will read all tables, not without spending months reading and testing every combination. > Here is how EH was implemented first for x86: > 1. LLVM was made to emit tables for some "easy" examples, this > involves some low-level stuff like register moves, encoding, etc. At > this point one can use LLVM-generated .s files with gcc-provided > unwinding library. That's my road... Just by turning on Dwarf debugging and lowering exception address and selection, I could get an ARM assembly with the default exception table. I've investigated the assembly code and it seems that clang is preparing the intrinsics the same way arm-gcc does, which is good. Up until __cxa_throw, everything is fine. The parameters are the same, in the same registers and the table header is similar. The failures come when getting into __cxa_begin_catch, when the PR recognizes the type thrown ('int') but still calls terminate. I'm guessing the action table is different, but there is no documentation on neither LLVM nor GCC intrinsics I could find. Does LLVM have implementations of __cxa_* intrinsics? If so, where are they? > 2. Necessary EH intrinsics was implemented > 3. More refinements (PIC mode, etc.) I didn't want to go that far, for now. Cheers, --renato From jason.wangz at gmail.com Thu May 20 05:05:09 2010 From: jason.wangz at gmail.com (Zheng Wang) Date: Thu, 20 May 2010 11:05:09 +0100 Subject: [LLVMdev] Remove debug info from the byte code? Message-ID: Hiya, Is there any easy way to remove the debug info from the LLVM byte code once I have collected all the debug info I needed? It is because the debug info seems to slow down the program significantly. I may be able to go through each basic block and delete the debug info in my pass. But, is there any elegant way to do it? Cheers, Zheng From baldrick at free.fr Thu May 20 06:26:04 2010 From: baldrick at free.fr (Duncan Sands) Date: Thu, 20 May 2010 13:26:04 +0200 Subject: [LLVMdev] Remove debug info from the byte code? In-Reply-To: References: Message-ID: <4BF51C4C.3060704@free.fr> Hi Zheng, > Is there any easy way to remove the debug info from the LLVM byte code > once I have collected all the debug info I needed? It is because the > debug info seems to slow down the program significantly. I may be able > to go through each basic block and delete the debug info in my pass. > But, is there any elegant way to do it? the opt tool has an option called -strip-debug, so presumably there is already a pass or utility that does this. Best wishes, Duncan. From blunted2night at gmail.com Thu May 20 11:43:30 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Thu, 20 May 2010 09:43:30 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: Thanks for the feedback. The line for commit-worthy is a round of reviews and some tests > showing that basic functionality works. > Regarding tests, I would like to have some form of automated regression testing, but am not sure how to go about doing so. My current testing involves running through my compilers regression test (compiles links and executes a number of test sources) and running a couple of .ll files and manually inspecting the results of Microsoft's dumpbin utility. > > Minor comments: > 1. Is it possible to allocate extra memory with coff::symbol instead > of using std::string and std::vector as class members? The extra > allocations can add up. > Yes, I believe ShortString & ShortVector are the appropriate alternative for these types of cases. > > 2. For the following bit: > + reinterpret_cast (Section->Symbol->Aux [0]) = > Section->Header.SizeOfRawData; > + reinterpret_cast (Section->Symbol->Aux [4]) = > Section->Header.NumberOfRelocations; > + reinterpret_cast (Section->Symbol->Aux [6]) = > Section->Header.PointerToLineNumbers; > > This isn't endian-safe; I'd suggest expanding it to 8 assignments. > Same issues with the write_le functions. We need endian safety not > only so that cross-compiling, for example, from PPC Linux to MingW > works, but also so that tests work cross-platform. > OK, I had put the write_le functions so that I could address this later. I should have used them, or something similar for the auxiliary symbols. I will rework the aux symbol stuff & the write_le functions to be cross platform safe. > > 3. For the following bit: > + typedef std::list symbols; > + typedef std::list sections; > > Avoid std::list; see http://llvm.org//docs/ProgrammersManual.html#dss_list. > Good catch, I would normally not do that. I must have had a list of objects, then changed it to pointers to objects and didn't rethink what type of container I was using. > > 4. For the following bit: > + typedef StringMap name_symbol_map; > + typedef StringMap name_section_map; > > Unused typedefs? > Left over from previous version of the implementation, will remove. > > 5. For the following bit (and a few others in the same function): > + for (i = Sections.begin(), j = Asm.begin(); > + (i != Sections.end()) && (j != Asm.end()); > + i++, j++) { > > http://llvm.org//docs/CodingStandards.html#ll_end > > I will recode those statements. > 6. > +namespace llvm { MCObjectWriter * createWinCOFFObjectWriter > (raw_ostream & OS); } > > If you need a function to be visible across files, use a header; > shortcuts like this make the code more difficult to read. > > On this one, it didn't seem appropriate to include WinCOFFObjectWriters header into X86AsmBackend, it also seems to be overkill to add a header to contain a single function. I would like some more feedback on what the sanctioned course of action should be here. - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100520/356470dc/attachment.html From devang.patel at gmail.com Thu May 20 11:47:53 2010 From: devang.patel at gmail.com (Devang Patel) Date: Thu, 20 May 2010 09:47:53 -0700 Subject: [LLVMdev] Remove debug info from the byte code? In-Reply-To: <4BF51C4C.3060704@free.fr> References: <4BF51C4C.3060704@free.fr> Message-ID: On Thu, May 20, 2010 at 4:26 AM, Duncan Sands wrote: > Hi Zheng, > >> Is there any easy way to remove the debug info from the LLVM byte code >> once I have collected all the debug info I needed? It is because the >> debug info seems to slow down the program significantly. I may be able >> to go through each basic block and delete the debug info in my pass. >> But, is there any elegant way to do it? > > the opt tool has an option called -strip-debug, so presumably there is > already a pass or utility that does this. Yup, see StripDebugInfo() in StripSymbols.cpp. - Devang From charlie at cs.umass.edu Thu May 20 13:12:22 2010 From: charlie at cs.umass.edu (Charlie Curtsinger) Date: Thu, 20 May 2010 14:12:22 -0400 Subject: [LLVMdev] function and stack size constants Message-ID: I'm looking to add a ConstantArray of function and stack sizes to a module in an opt pass, but obviously these values aren't available until code generation. As far as I can tell, the only way to go about this would be to add two new constants, FunctionSize and StackSize, both taking a function as a parameter and then lower these somewhere in the target-specific code. Does this sound reasonable? I'm not sure where to start with the creation of these constants. Any pointers on adding the constants or an alternative approach would be greatly appreciated. Thanks, - Charlie From aeyakovenko at gmail.com Thu May 20 15:04:46 2010 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Thu, 20 May 2010 13:04:46 -0700 Subject: [LLVMdev] trying to build llvm-gcc for arm, error: 'V1DI_pointer_node' undeclared (first use in this function) Message-ID: i am getting this compilation error: gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -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. -I. -I../../llvm-gcc-4.2-2.7.source/gcc -I../../llvm-gcc-4.2-2.7.source/gcc/. -I../../llvm-gcc-4.2-2.7.source/gcc/../include -I../../llvm-gcc-4.2-2.7.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.7.source/gcc/../libdecnumber -I../libdecnumber \ ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c -o arm.o In file included from ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:59: ../../llvm-gcc-4.2-2.7.source/gcc/../libcpp/include/../../libcpp/internal.h: In function 'ufputs': ../../llvm-gcc-4.2-2.7.source/gcc/../libcpp/include/../../libcpp/internal.h:693: warning: implicit declaration of function 'fputs_unlocked' ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c: In function 'arm_init_neon_builtins': ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:17355: error: 'V1DI_pointer_node' undeclared (first use in this function) ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:17355: error: (Each undeclared identifier is reported only once ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:17355: error: for each function it appears in.) make[3]: *** [arm.o] Error 1 make[3]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc' make[2]: *** [all-gcc] Error 2 make[2]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' make: *** [/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/arm-elf/bin/arm-elf-gcc] Error 2 this is how i've configured llvm-gcc, this configuration has worked for me for gcc 4.2 - 4.5 ./configure --enable-multilib --enable-target-optspace --enable-interwork --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --target=arm-elf --prefix=$(installdir) Any ideas? From bob.wilson at apple.com Thu May 20 15:15:59 2010 From: bob.wilson at apple.com (Bob Wilson) Date: Thu, 20 May 2010 13:15:59 -0700 Subject: [LLVMdev] trying to build llvm-gcc for arm, error: 'V1DI_pointer_node' undeclared (first use in this function) In-Reply-To: References: Message-ID: <0AEE5B1C-6A01-40A2-961C-6113C706E7C6@apple.com> You need to configure with --enable-llvm. (It would still be nice if V1DI_pointer_node was defined; I'll take a look at that.) On May 20, 2010, at 1:04 PM, Anatoly Yakovenko wrote: > i am getting this compilation error: > > > gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -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. -I. -I../../llvm-gcc-4.2-2.7.source/gcc > -I../../llvm-gcc-4.2-2.7.source/gcc/. > -I../../llvm-gcc-4.2-2.7.source/gcc/../include > -I../../llvm-gcc-4.2-2.7.source/gcc/../libcpp/include > -I../../llvm-gcc-4.2-2.7.source/gcc/../libdecnumber -I../libdecnumber > \ > ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c -o arm.o > In file included from ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:59: > ../../llvm-gcc-4.2-2.7.source/gcc/../libcpp/include/../../libcpp/internal.h: > In function 'ufputs': > ../../llvm-gcc-4.2-2.7.source/gcc/../libcpp/include/../../libcpp/internal.h:693: > warning: implicit declaration of function 'fputs_unlocked' > ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c: In function > 'arm_init_neon_builtins': > ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:17355: error: > 'V1DI_pointer_node' undeclared (first use in this function) > ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:17355: error: (Each > undeclared identifier is reported only once > ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:17355: error: for > each function it appears in.) > make[3]: *** [arm.o] Error 1 > make[3]: Leaving directory > `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc' > make[2]: *** [all-gcc] Error 2 > make[2]: Leaving directory > `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' > make: *** [/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/arm-elf/bin/arm-elf-gcc] > Error 2 > > > this is how i've configured llvm-gcc, this configuration has worked > for me for gcc 4.2 - 4.5 > > ./configure --enable-multilib --enable-target-optspace > --enable-interwork --with-newlib --with-gnu-as --with-gnu-ld > --enable-languages=c,c++ --target=arm-elf --prefix=$(installdir) > > Any ideas? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From housel at acm.org Thu May 20 15:32:21 2010 From: housel at acm.org (Peter S. Housel) Date: Thu, 20 May 2010 13:32:21 -0700 Subject: [LLVMdev] [PATCH] More BitCodeFormat.html improvements Message-ID: The enclosed patch adds documentation for the PARAMATTR_BLOCK, TYPE_BLOCK, and TYPE_SYMTAB_BLOCK records in the LLVM IR bitcode format. I have started documenting CONSTANTS_BLOCK and FUNCTION_BLOCK and will send patches when they are complete. -Peter- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100520/39b61edf/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: BitCodeFormat.diff Type: application/octet-stream Size: 12418 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100520/39b61edf/attachment.obj From rengolin at systemcall.org Thu May 20 15:52:46 2010 From: rengolin at systemcall.org (Renato Golin) Date: Thu, 20 May 2010 21:52:46 +0100 Subject: [LLVMdev] Flash player with LLVM backend Message-ID: http://lightspark.sourceforge.net/ ActionScript 3 being JITed by LLVM, OpenGL acceleration... Rumours say it's going to beta in the near future... -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From aeyakovenko at gmail.com Thu May 20 15:52:51 2010 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Thu, 20 May 2010 13:52:51 -0700 Subject: [LLVMdev] trying to build llvm-gcc for arm, error: 'V1DI_pointer_node' undeclared (first use in this function) In-Reply-To: <0AEE5B1C-6A01-40A2-961C-6113C706E7C6@apple.com> References: <0AEE5B1C-6A01-40A2-961C-6113C706E7C6@apple.com> Message-ID: Thanks, i got a little farther, but i am getting a bunch of linker errors now: libbackend.a(llvm-convert.o): In function `getPointerAlignment': llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:142: undefined reference to `get_pointer_alignment' On Thu, May 20, 2010 at 1:15 PM, Bob Wilson wrote: > You need to configure with --enable-llvm. > > (It would still be nice if V1DI_pointer_node was defined; I'll take a look at that.) > > On May 20, 2010, at 1:04 PM, Anatoly Yakovenko wrote: > >> i am getting this compilation error: >> >> >> gcc -c ? -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE ?-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. -I. -I../../llvm-gcc-4.2-2.7.source/gcc >> -I../../llvm-gcc-4.2-2.7.source/gcc/. >> -I../../llvm-gcc-4.2-2.7.source/gcc/../include >> -I../../llvm-gcc-4.2-2.7.source/gcc/../libcpp/include >> -I../../llvm-gcc-4.2-2.7.source/gcc/../libdecnumber -I../libdecnumber >> ?\ >> ? ? ? ? ? ? ? ?../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c -o arm.o >> In file included from ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:59: >> ../../llvm-gcc-4.2-2.7.source/gcc/../libcpp/include/../../libcpp/internal.h: >> In function 'ufputs': >> ../../llvm-gcc-4.2-2.7.source/gcc/../libcpp/include/../../libcpp/internal.h:693: >> warning: implicit declaration of function 'fputs_unlocked' >> ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c: In function >> 'arm_init_neon_builtins': >> ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:17355: error: >> 'V1DI_pointer_node' undeclared (first use in this function) >> ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:17355: error: (Each >> undeclared identifier is reported only once >> ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/arm.c:17355: error: for >> each function it appears in.) >> make[3]: *** [arm.o] Error 1 >> make[3]: Leaving directory >> `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc' >> make[2]: *** [all-gcc] Error 2 >> make[2]: Leaving directory >> `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory >> `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' >> make: *** [/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/arm-elf/bin/arm-elf-gcc] >> Error 2 >> >> >> this is how i've configured llvm-gcc, this configuration has worked >> for me for gcc 4.2 - 4.5 >> >> ./configure --enable-multilib --enable-target-optspace >> --enable-interwork --with-newlib --with-gnu-as --with-gnu-ld >> --enable-languages=c,c++ --target=arm-elf --prefix=$(installdir) >> >> Any ideas? >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From jayasnair at gmail.com Thu May 20 20:18:33 2010 From: jayasnair at gmail.com (JayaSus) Date: Thu, 20 May 2010 18:18:33 -0700 (PDT) Subject: [LLVMdev] hexcode from llvm In-Reply-To: <623A32D0-B36B-4020-B098-C44A59B1BC99@apple.com> References: <28612686.post@talk.nabble.com> <623A32D0-B36B-4020-B098-C44A59B1BC99@apple.com> Message-ID: <28628721.post@talk.nabble.com> Hi Bill Wendling. I am trying to get a hexcode as shown below for mips processor using llvm Disassembly of section .text: 00000000
: 0: 27bdffe8 addiu sp,sp,-24 4: afbe0010 sw s8,16(sp) 8: 03a0f021 move s8,sp c: 24020004 li v0,4 10: afc20008 sw v0,8(s8) 14: 24020005 li v0,5 18: afc20004 sw v0,4(s8) 1c: 8fc30008 lw v1,8(s8) 20: 8fc20004 lw v0,4(s8) 24: 00000000 nop 28: 00621021 addu v0,v1,v0 2c: afc20000 sw v0,0(s8) 30: 03c0e821 move sp,s8 .... Is there any pass or buildin command for llvm to generate this. llvm-dis will only generate the assembly code and not the hexcode. Moreover how can I compile c code for mips using llvm-gcc? llvm-gcc -b mips t.c complains it wouldn't know the -b option. Thanks Bill Wendling-2 wrote: > > On May 19, 2010, at 12:01 PM, JayaSus wrote: > >> >> Hi all, >> >> I am doing emulation on a custom processor. For this I need hexcode for >> the >> C application program . Is there any llvm command/function that can spit >> out >> the hexcode just like objdump in gcc? >> > Hi JayaSus, > > I'm confused by your question. Do you mean the LLVM IR "object code" or > the resulting native object code generated by the assembler (after code > generation) for the target platform? If the latter, then your objdump > tools should work with that. > > -bw > > > _______________________________________________ > 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://old.nabble.com/hexcode-from-llvm-tp28612686p28628721.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From plmdvy at gmail.com Thu May 20 20:46:21 2010 From: plmdvy at gmail.com (Paul Davey) Date: Fri, 21 May 2010 13:46:21 +1200 Subject: [LLVMdev] Fwd: hexcode from llvm In-Reply-To: References: <28612686.post@talk.nabble.com> <623A32D0-B36B-4020-B098-C44A59B1BC99@apple.com> <28628721.post@talk.nabble.com> Message-ID: sorry keep forgetting to send to list instead of last person who replied :( On Fri, May 21, 2010 at 1:18 PM, JayaSus wrote: > > Hi Bill Wendling. > I am trying to get a hexcode as shown below for mips processor using llvm > > Disassembly of section .text: > > 00000000
: > ? 0: ? 27bdffe8 ? ? ? ?addiu ? sp,sp,-24 > ? 4: ? afbe0010 ? ? ? ?sw ? ? ?s8,16(sp) > ? 8: ? 03a0f021 ? ? ? ?move ? ?s8,sp > ? c: ? 24020004 ? ? ? ?li ? ? ?v0,4 > ?10: ? afc20008 ? ? ? ?sw ? ? ?v0,8(s8) > ?14: ? 24020005 ? ? ? ?li ? ? ?v0,5 > ?18: ? afc20004 ? ? ? ?sw ? ? ?v0,4(s8) > ?1c: ? 8fc30008 ? ? ? ?lw ? ? ?v1,8(s8) > ?20: ? 8fc20004 ? ? ? ?lw ? ? ?v0,4(s8) > ?24: ? 00000000 ? ? ? ?nop > ?28: ? 00621021 ? ? ? ?addu ? ?v0,v1,v0 > ?2c: ? afc20000 ? ? ? ?sw ? ? ?v0,0(s8) > ?30: ? 03c0e821 ? ? ? ?move ? ?sp,s8 > .... > > Is there any pass or buildin command for llvm to generate this. llvm-dis > will only generate the assembly code and not the hexcode. This is not done by llvm, you create native assembly from the llvm IR then assemble that and then you can use objdump to get your hexcode just like from gcc. LLVM does not deal with native code, it uses llvm IR, llvm-dis is simply a converter from the bitcode format of the IR to the human readable assembly text format of the IR. > > Moreover how can I compile c code for mips using llvm-gcc? llvm-gcc -b mips > t.c complains it wouldn't know the -b option. > You might want -march or other -m options... From redcurbs at yahoo.com Thu May 20 20:49:19 2010 From: redcurbs at yahoo.com (Bob Grandish) Date: Thu, 20 May 2010 18:49:19 -0700 (PDT) Subject: [LLVMdev] Hello example plugin has unresolved symbol in llvm 2.7 Message-ID: <463648.57902.qm@web33602.mail.mud.yahoo.com> I built llvm-2.7 from source on FreeBSD-i386 with: ./configure --prefix=/opt && gmake It builds fine, but the Hello plugin fails to load with an unresolved symbol. $ opt -load /opt/lib/libLLVMHello.so -help Error opening '/opt/lib/libLLVMHello.so': /opt/lib/libLLVMHello.so: Undefined symbol "_ZNK4llvm4Pass5printERNS_11raw_ostreamEPKNS_6ModuleE" -load request ignored. OVERVIEW: llvm .bc -> .bc modular optimizer and analysis printer [...] I edited the lib/Transforms/Hello/Makefile with various forms of LLVMLIBS, USEDLIBS, and LINK_COMPONENTS. Basically, I needed to include "LLVMCore.a LLVMSupport.a LLVMSystem.a" in order to get rid of all 3 unresolved symbols. However, when I tried to load that library with opt, I got the dreaded "pass loaded multiple times" assert. This is the Release build. I have not tried a debug build. However, it's clear that the stock Hello plugin is broken in llvm-2.7. Please advise on how to fix the above. Sincerely, Bob From dalej at apple.com Thu May 20 22:29:56 2010 From: dalej at apple.com (Dale Johannesen) Date: Thu, 20 May 2010 20:29:56 -0700 Subject: [LLVMdev] hexcode from llvm In-Reply-To: <28628721.post@talk.nabble.com> References: <28612686.post@talk.nabble.com> <623A32D0-B36B-4020-B098-C44A59B1BC99@apple.com> <28628721.post@talk.nabble.com> Message-ID: On May 20, 2010, at 6:18 PM, JayaSus wrote: > > Hi Bill Wendling. > I am trying to get a hexcode as shown below for mips processor using > llvm > > Disassembly of section .text: > > 00000000
: > 0: 27bdffe8 addiu sp,sp,-24 > 4: afbe0010 sw s8,16(sp) > 8: 03a0f021 move s8,sp > c: 24020004 li v0,4 > 10: afc20008 sw v0,8(s8) > 14: 24020005 li v0,5 > 18: afc20004 sw v0,4(s8) > 1c: 8fc30008 lw v1,8(s8) > 20: 8fc20004 lw v0,4(s8) > 24: 00000000 nop > 28: 00621021 addu v0,v1,v0 > 2c: afc20000 sw v0,0(s8) > 30: 03c0e821 move sp,s8 > .... > > Is there any pass or buildin command for llvm to generate this. llvm- > dis > will only generate the assembly code and not the hexcode. I think what you want is to generate object code (.o file) and simultaneously produce a dump of the assembly code and the corresponding object code in hex; I've seen compilers that do that. llvm does not currently generate object code directly; it only generates assembly. There are people working on generating object code directly. I don't know of anybody working on generating the dump you want, but it should be easy enough once direct object code generation is in place. The usual toolchain for what you want is llvm-gcc -S -> assembler source (.s) assembler source -> as -> object file (.o) object file -> disassembler This can be conveniently hidden in a script. I don't know what the disassembler is called on mips, though. llvm-gcc -c generates an object file, but it does this by generating an assembler source file and invoking the assembler. > Moreover how can I compile c code for mips using llvm-gcc? llvm-gcc - > b mips > t.c complains it wouldn't know the -b option. Neither do I:) You need to build llvm-gcc so it targets mips. From samuraileumas at yahoo.com Fri May 21 08:32:28 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Fri, 21 May 2010 06:32:28 -0700 (PDT) Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: Message-ID: <78525.49897.qm@web62008.mail.re1.yahoo.com> Hi Nathan, According to http://llvm.org//docs/CodingStandards.html#hl_dontinclude you seem to be right on this one. If this isn't what the team leaders meant, they shouldn't have written it as it is. --Sam > >From: Nathan Jeffords >To: Eli Friedman >Cc: LLVM Dev >Sent: Thu, May 20, 2010 11:43:30 AM >Subject: Re: [LLVMdev] Win32 COFF Support > > > > >>>6. >>>>+namespace llvm { MCObjectWriter * createWinCOFFObjectWriter >>>>(raw_ostream & OS); } >> >>>>If you need a function to be visible across files, use a header; >>>>shortcuts like this make the code more difficult to read. >> >> > >On this one, it didn't seem appropriate to include WinCOFFObjectWriters header into X86AsmBackend, it also seems to be overkill to add a header to contain a single function. I would like some more feedback on what the sanctioned course of action should be here. > >- Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100521/865f55fe/attachment.html From clattner at apple.com Fri May 21 17:22:32 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 21 May 2010 15:22:32 -0700 Subject: [LLVMdev] [PATCH] More BitCodeFormat.html improvements In-Reply-To: References: Message-ID: Looks great, applied in r104391, thanks! -Chris On May 20, 2010, at 1:32 PM, Peter S. Housel wrote: > The enclosed patch adds documentation for the PARAMATTR_BLOCK, TYPE_BLOCK, and TYPE_SYMTAB_BLOCK records in the LLVM IR bitcode format. > > > I have started documenting CONSTANTS_BLOCK and FUNCTION_BLOCK and will send patches when they are complete. > > -Peter- > > > <<...>> > > > _______________________________________________ > 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/20100521/11c86ed2/attachment.html From redcurbs at yahoo.com Fri May 21 19:23:25 2010 From: redcurbs at yahoo.com (Bob Grandish) Date: Fri, 21 May 2010 17:23:25 -0700 (PDT) Subject: [LLVMdev] Hello example plugin has unresolved symbol in llvm 2.7 In-Reply-To: <463648.57902.qm@web33602.mail.mud.yahoo.com> Message-ID: <614113.36513.qm@web33603.mail.mud.yahoo.com> --- On Thu, 5/20/10, Bob Grandish wrote: > I built llvm-2.7 from source on > FreeBSD-i386 with: > ? ./configure --prefix=/opt && gmake > > It builds fine, but the Hello plugin fails to load with an > unresolved symbol. > > $ opt -load /opt/lib/libLLVMHello.so -help? ? > ? ? ??? > Error opening '/opt/lib/libLLVMHello.so': > /opt/lib/libLLVMHello.so: Undefined symbol > "_ZNK4llvm4Pass5printERNS_11raw_ostreamEPKNS_6ModuleE" > ? -load request ignored. > OVERVIEW: llvm .bc -> .bc modular optimizer and analysis > printer > [...] > > I edited the lib/Transforms/Hello/Makefile with various > forms of LLVMLIBS, USEDLIBS, and LINK_COMPONENTS. Basically, > I needed to include "LLVMCore.a LLVMSupport.a LLVMSystem.a" > in order to get rid of all 3 unresolved symbols. However, > when I tried to load that library with opt, I got the > dreaded "pass loaded multiple times" assert. > > This is the Release build. I have not tried a debug build. > However, it's clear that the stock Hello plugin is broken in > llvm-2.7. Please advise on how to fix the above. I found the problem. There was another version of llvm that had been installed by the ports system. It was coming before my build of opt in the path. It seems there is some conflict between the build options used in the FreeBSD port of llvm and the normal "./configure && gmake" route. I suspect it is --enable-optimized, although I have not verified this yet. So if you get that unresolved symbol error, check that your opt and .so library were built with the same configure settings. Thanks, Bob From sebastien.bourdeauducq at lekernel.net Mon May 24 04:11:31 2010 From: sebastien.bourdeauducq at lekernel.net (=?iso-8859-1?q?S=E9bastien_Bourdeauducq?=) Date: Mon, 24 May 2010 11:11:31 +0200 Subject: [LLVMdev] LatticeMico32 (LM32) backend In-Reply-To: <201005181838.41946.sebastien.bourdeauducq@lekernel.net> References: <201005181838.41946.sebastien.bourdeauducq@lekernel.net> Message-ID: <201005241111.31286.sebastien.bourdeauducq@lekernel.net> Just bringing that up as I did not get any reply so far. Thanks, S?bastien On Tuesday 18 May 2010 18:38:41 S?bastien Bourdeauducq wrote: > Hi, > > Would anyone be interested in developing a LatticeMico32 backend in LLVM? > > LatticeMico32 [1] is an open source microprocessor core designed by Lattice > Semiconductor and typically used in FPGAs. It is comparable to the > Microblaze processor that you already support. > > It is already supported by GNU Binutils and GCC (4.5+). It is used by the > Milkymist [2] and RTEMS [3] projects. The Milkymist project would like to > use the LLVM compiler toolchain as an alternative to GCC, which requires > developing a LM32 backend. > > Thanks, > S?bastien Bourdeauducq > > [1] http://www.latticesemi.com/mico32 > [2] http://www.milkymist.org > [3] http://www.rtems.org > From eli.friedman at gmail.com Mon May 24 07:32:19 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 24 May 2010 05:32:19 -0700 Subject: [LLVMdev] LatticeMico32 (LM32) backend In-Reply-To: <201005241111.31286.sebastien.bourdeauducq@lekernel.net> References: <201005181838.41946.sebastien.bourdeauducq@lekernel.net> <201005241111.31286.sebastien.bourdeauducq@lekernel.net> Message-ID: On Mon, May 24, 2010 at 2:11 AM, S?bastien Bourdeauducq wrote: > Just bringing that up as I did not get any reply so far. Resending the email isn't really productive; for the given question, the lack of a reply should answer your question. Was there something else you wanted to ask? -Eli > Thanks, > S?bastien > > > On Tuesday 18 May 2010 18:38:41 S?bastien Bourdeauducq wrote: >> Hi, >> >> Would anyone be interested in developing a LatticeMico32 backend in LLVM? >> >> LatticeMico32 [1] is an open source microprocessor core designed by Lattice >> Semiconductor and typically used in FPGAs. It is comparable to the >> ?Microblaze processor that you already support. >> >> It is already supported by GNU Binutils and GCC (4.5+). It is used by the >> Milkymist [2] and RTEMS [3] projects. The Milkymist project would like to >> ?use the LLVM compiler toolchain as an alternative to GCC, which requires >> ?developing a LM32 backend. >> >> Thanks, >> S?bastien Bourdeauducq >> >> [1] http://www.latticesemi.com/mico32 >> [2] http://www.milkymist.org >> [3] http://www.rtems.org >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From sebastien.bourdeauducq at lekernel.net Mon May 24 08:09:17 2010 From: sebastien.bourdeauducq at lekernel.net (=?iso-8859-1?q?S=E9bastien_Bourdeauducq?=) Date: Mon, 24 May 2010 15:09:17 +0200 Subject: [LLVMdev] LatticeMico32 (LM32) backend In-Reply-To: References: <201005181838.41946.sebastien.bourdeauducq@lekernel.net> <201005241111.31286.sebastien.bourdeauducq@lekernel.net> Message-ID: <201005241509.17197.sebastien.bourdeauducq@lekernel.net> On Monday 24 May 2010 14:32:19 Eli Friedman wrote: > Resending the email isn't really productive; for the given question, > the lack of a reply should answer your question. Was there something > else you wanted to ask? I find this message unhelpful at best, if not purely arrogant. You are making an open source compiler, I am making an open source processor: we are fighting for the same cause, aren't we? I would have hoped for something else than such a troll-ish attitude. S?bastien From edwintorok at gmail.com Mon May 24 08:31:17 2010 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Mon, 24 May 2010 16:31:17 +0300 Subject: [LLVMdev] LatticeMico32 (LM32) backend In-Reply-To: <201005241509.17197.sebastien.bourdeauducq@lekernel.net> References: <201005181838.41946.sebastien.bourdeauducq@lekernel.net> <201005241111.31286.sebastien.bourdeauducq@lekernel.net> <201005241509.17197.sebastien.bourdeauducq@lekernel.net> Message-ID: <4BFA7FA5.3000100@gmail.com> On 2010-05-24 16:09, S?bastien Bourdeauducq wrote: > On Monday 24 May 2010 14:32:19 Eli Friedman wrote: >> Resending the email isn't really productive; for the given question, >> the lack of a reply should answer your question. Was there something >> else you wanted to ask? > > I find this message unhelpful at best Try contacting the author of the Microblaze backend off-list (See CREDITS.TXT) and see if he's interested. Maybe he is, but he wasn't following LLVMdev lately. >, if not purely arrogant. You are making > an open source compiler, I am making an open source processor I don't think anyone would reject a LatticeMico32 backend if you were to submit it to LLVM when it is ready (assuming the license is compatible). Best regards, --Edwin From samuraileumas at yahoo.com Mon May 24 08:32:41 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Mon, 24 May 2010 06:32:41 -0700 (PDT) Subject: [LLVMdev] LatticeMico32 (LM32) backend In-Reply-To: <201005241509.17197.sebastien.bourdeauducq@lekernel.net> References: <201005181838.41946.sebastien.bourdeauducq@lekernel.net> <201005241111.31286.sebastien.bourdeauducq@lekernel.net> <201005241509.17197.sebastien.bourdeauducq@lekernel.net> Message-ID: <305980.85637.qm@web62002.mail.re1.yahoo.com> Hello S?bastien, Making backends to LLVM is a significant amount of work. If you want somebody to do it for you, either offer some payment or do your own coding. Keep in mind that the bread-and-butter support for LLVM comes from Apple computer so unless the next iPad will start using softcores, be prepared to pursue the other courses of action I laid out. I may be having to write a backend to the N68050 softcore soon but am busy writing my own LLVM-based compiler at the moment so don't expect me to jump up and down with excitement just because there is a new softcore that doesn't have a compiler for it. That is my perspective. Now for the good news: LLVM is not just a compiler, it is a compiler framework. There are dozens of programming languages being based on LLVM. If you still decide to make an LLVM backend for your softcore, you can certainly find help here with your programming questions and TableGen problems. --Sam ----- Original Message ---- > From: S?bastien Bourdeauducq > To: Eli Friedman > Cc: llvmdev at cs.uiuc.edu > Sent: Mon, May 24, 2010 8:09:17 AM > Subject: Re: [LLVMdev] LatticeMico32 (LM32) backend > > On Monday 24 May 2010 14:32:19 Eli Friedman wrote: > Resending the email > isn't really productive; for the given question, > the lack of a reply > should answer your question. Was there something > else you wanted > to ask? I find this message unhelpful at best, if not purely arrogant. > You are making an open source compiler, I am making an open source > processor: we are fighting for the same cause, aren't we? I would have hoped > for something else than such a troll-ish > attitude. S?bastien From tianshuo9 at gmail.com Mon May 24 08:55:32 2010 From: tianshuo9 at gmail.com (=?GB2312?B?zO/Ltg==?=) Date: Mon, 24 May 2010 21:55:32 +0800 Subject: [LLVMdev] obtain programer-defined structure name. Message-ID: Hi, I intend to trace the Use instructions of a variable object in its lifecycle, so, the first step is to obtain the type of the object. However, the datastructure object is complicated typed value, such as "struct file *f" in linux kernel. The problerm is what operations should be taken to obtain the type of Value "struct *file", and locate or such type Value*s *in a procedure. Have I made myself clear? thanks. Tian Shuo 2010-5-24 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100524/5b67b05a/attachment.html From anton at korobeynikov.info Mon May 24 09:07:30 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 24 May 2010 18:07:30 +0400 Subject: [LLVMdev] LatticeMico32 (LM32) backend In-Reply-To: <305980.85637.qm@web62002.mail.re1.yahoo.com> References: <201005181838.41946.sebastien.bourdeauducq@lekernel.net> <201005241111.31286.sebastien.bourdeauducq@lekernel.net> <201005241509.17197.sebastien.bourdeauducq@lekernel.net> <305980.85637.qm@web62002.mail.re1.yahoo.com> Message-ID: > Making backends to LLVM is a significant amount of work. ?If you want somebody to do it for you, either offer some payment or do your own coding. ?Keep in mind that the bread-and-butter support for LLVM comes from Apple computer so unless the next iPad will start using softcores, be prepared to pursue the other courses of action I laid out. Just to clarify the stuff: the building of the backend itself is only half of the job. Another half is maintaining the backend, which should be performed continuosly. Otherwise the backend will quickly become of pretty "poor quality" and can be considered as a candiate for removal. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From aeyakovenko at gmail.com Mon May 24 14:06:55 2010 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Mon, 24 May 2010 12:06:55 -0700 Subject: [LLVMdev] linker errors when trying to link llvm-gcc Message-ID: any ideas what library has these symbols lang_eh_catch_all get_pointer_alignment validate_arglist i get these linker errors when trying to link llvm-gcc: make[1]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' make[2]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/build-x86_64-unknown-linux-gnu/libiberty' make[2]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/intl' make[2]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/libiberty' make[2]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/libdecnumber' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/libdecnumber' make[3]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/build-x86_64-unknown-linux-gnu/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/build-x86_64-unknown-linux-gnu/libiberty/testsuite' make[2]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/build-x86_64-unknown-linux-gnu/libiberty' make[3]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/libiberty/testsuite' make[2]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/build-x86_64-unknown-linux-gnu/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/build-x86_64-unknown-linux-gnu/fixincludes' make[2]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/libiberty' make[2]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[2]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/fixincludes' make[2]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/libcpp' make[2]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc' c++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -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 -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ llvm-main.o libbackend.a ../libcpp/libcpp.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMBitReader.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMipo.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMBitWriter.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMARMAsmParser.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMMCParser.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMARMAsmPrinter.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMARMCodeGen.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMSelectionDAG.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMAsmPrinter.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMCodeGen.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMScalarOpts.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMInstCombine.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMTransformUtils.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMipa.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMAnalysis.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMTarget.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMMC.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMCore.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMARMInfo.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMSupport.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMSystem.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib -lpthread -ldl -lm c++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -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 -o cc1plus-dummy \ cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o c-pretty-print.o c-opts.o c-pch.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o c-omp.o tree-inline.o dummy-checksum.o llvm-main.o libbackend.a ../libcpp/libcpp.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMBitReader.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMipo.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMBitWriter.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMARMAsmParser.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMMCParser.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMARMAsmPrinter.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMARMCodeGen.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMSelectionDAG.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMAsmPrinter.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMCodeGen.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMScalarOpts.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMInstCombine.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMTransformUtils.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMipa.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMAnalysis.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMTarget.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMMC.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMCore.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMARMInfo.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMSupport.a /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib/libLLVMSystem.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7/Release/lib -lpthread -ldl -lm \ cp/except.o: In function `init_exception_processing': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/cp/except.c:121: undefined reference to `lang_eh_catch_all' libbackend.a(llvm-convert.o): In function `getPointerAlignment': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:142: undefined reference to `get_pointer_alignment' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinDwarfSPColumn(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6318: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinEHReturnDataRegno(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6331: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinDwarfCFA(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6304: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinUnwindInit(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6446: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinStackSave(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6268: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o):/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6556: more undefined references to `validate_arglist' follow libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitPostPads()': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2181: undefined reference to `get_eh_region' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2184: undefined reference to `classify_eh_handler' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2185: undefined reference to `get_eh_type_list' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2204: undefined reference to `get_eh_type_list' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2208: undefined reference to `lookup_type_for_runtime' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2226: undefined reference to `get_eh_next_catch' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2227: undefined reference to `get_eh_next_catch' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitLandingPads()': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2099: undefined reference to `classify_eh_handler' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2114: undefined reference to `get_eh_type_list' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2124: undefined reference to `lookup_type_for_runtime' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2102: undefined reference to `get_eh_type_list' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2109: undefined reference to `lookup_type_for_runtime' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinCall(tree_node*, tree_node*, MemRef const*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:5944: undefined reference to `validate_arglist' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:5131: undefined reference to `validate_arglist' collect2: ld returned 1 exit status make[2]: *** [cc1plus-dummy] Error 1 make[2]: *** Waiting for unfinished jobs.... libbackend.a(llvm-convert.o): In function `getPointerAlignment': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:142: undefined reference to `get_pointer_alignment' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinDwarfSPColumn(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6318: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinEHReturnDataRegno(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6331: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinDwarfCFA(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6304: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinUnwindInit(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6446: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinStackSave(tree_node*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6268: undefined reference to `validate_arglist' libbackend.a(llvm-convert.o):/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:6556: more undefined references to `validate_arglist' follow libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitPostPads()': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2181: undefined reference to `get_eh_region' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2184: undefined reference to `classify_eh_handler' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2185: undefined reference to `get_eh_type_list' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2204: undefined reference to `get_eh_type_list' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2208: undefined reference to `lookup_type_for_runtime' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2226: undefined reference to `get_eh_next_catch' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2227: undefined reference to `get_eh_next_catch' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitLandingPads()': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2099: undefined reference to `classify_eh_handler' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2114: undefined reference to `get_eh_type_list' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2124: undefined reference to `lookup_type_for_runtime' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2102: undefined reference to `get_eh_type_list' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2109: undefined reference to `lookup_type_for_runtime' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinCall(tree_node*, tree_node*, MemRef const*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:5944: undefined reference to `validate_arglist' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:5131: undefined reference to `validate_arglist' collect2: ld returned 1 exit status make[2]: *** [cc1-dummy] Error 1 make[2]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' make: *** [all] Error 2 From baldrick at free.fr Mon May 24 14:52:42 2010 From: baldrick at free.fr (Duncan Sands) Date: Mon, 24 May 2010 21:52:42 +0200 Subject: [LLVMdev] linker errors when trying to link llvm-gcc In-Reply-To: References: Message-ID: <4BFAD90A.8040708@free.fr> Hi Anatoly, > any ideas what library has these symbols > > lang_eh_catch_all > get_pointer_alignment > validate_arglist it sounds like you are trying to build a version of llvm-gcc without LLVM enabled. Did you specify --enable-llvm=path_to_llvm_build_directory when configuring llvm-gcc? These symbols are all defined in llvm-gcc itself, but only when ENABLE_LLVM is defined. This suggests to me that you somehow configured llvm-gcc wrong. Ciao, Duncan. From ambika at cse.iitb.ac.in Mon May 24 14:58:25 2010 From: ambika at cse.iitb.ac.in (ambika) Date: Tue, 25 May 2010 01:28:25 +0530 Subject: [LLVMdev] Basic doubt related to Module::iterator Message-ID: <4BFADA61.5060807@cse.iitb.ac.in> Hi, I believe that Module::iterator iterates through all the functions in a program. Am i wrong somewhere? I run this for different files, each having one function each ie main(), but for one it loops twice, and for another it loops thrice. for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I) Can someone explain this behavior. regards, Ambika From blunted2night at gmail.com Mon May 24 19:49:14 2010 From: blunted2night at gmail.com (Nathan Jeffords) Date: Mon, 24 May 2010 17:49:14 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: <78525.49897.qm@web62008.mail.re1.yahoo.com> References: <78525.49897.qm@web62008.mail.re1.yahoo.com> Message-ID: Hi all, Here is the latest revision of my Win32 COFF Support patch. This version includes changes based on Eli's feedback, and an implementation of weak reference symbols (COFF weak externals). If there is nothing major wrong with it, I would like to commit it. I can understand the lack of automated regression testing being one of those reasons. If so, can I have some guidance on how to approach that. Aaron had suggested using a object file dumping utility to generate a text representation and then diffing that against the expected output. I think that is a good idea but don't know where to put this utility, and I have no experience with the automated testing system currently in use. Thanks, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100524/9c197a68/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: changes.patch Type: application/octet-stream Size: 49644 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100524/9c197a68/attachment.obj From eli.friedman at gmail.com Mon May 24 20:20:47 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 24 May 2010 18:20:47 -0700 Subject: [LLVMdev] Win32 COFF Support In-Reply-To: References: <78525.49897.qm@web62008.mail.re1.yahoo.com> Message-ID: On Mon, May 24, 2010 at 5:49 PM, Nathan Jeffords wrote: > ?Hi all, > Here is the latest revision of my Win32 COFF Support patch. This version > includes changes based on Eli's feedback, and an?implementation?of weak > reference symbols (COFF weak externals). If there is nothing major wrong > with it, I would like to commit it. > I can understand the lack of automated regression testing being one of those > reasons. If so, can I have some guidance on how to approach that. Aaron > had?suggested?using a object file dumping utility to generate a > text?representation?and then diffing that against the expected output. I > think that is a good idea but don't know where to put this utility, and I > have no experience with the automated testing system currently in use. Essentially, the idea is to write something like test/Scripts/macho-dump (a primitive object dumper), call it from tests to get a textual representation, and check that you get what you expect. Look at the tests in test/MC/MachO for example tests; hopefully, it's relatively intuitive. -Eli From ofv at wanadoo.es Mon May 24 20:30:54 2010 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Tue, 25 May 2010 03:30:54 +0200 Subject: [LLVMdev] Win32 COFF Support References: <78525.49897.qm@web62008.mail.re1.yahoo.com> Message-ID: <87pr0klqcx.fsf@telefonica.net> Nathan Jeffords writes: > Here is the latest revision of my Win32 COFF Support patch. This version > includes changes based on Eli's feedback, and an implementation of weak > reference symbols (COFF weak externals). If there is nothing major wrong > with it, I would like to commit it. > > I can understand the lack of automated regression testing being one of those > reasons. [snip] I hope that the lack of regression tests will not constitute a blocker for the patch. Not having the feature is worse than having the feature with some occassional regression. From lyudalev at gmail.com Tue May 25 10:19:05 2010 From: lyudalev at gmail.com (Lev Yudalevich) Date: Tue, 25 May 2010 18:19:05 +0300 Subject: [LLVMdev] backend question Message-ID: Hello, I'm just starting to work on a backend for a custom cpu. For some instructions this cpu has two flavors: first performs an operation, and the second performs an operation and updates condition codes (carry, zero, overflow, negative etc) based on the outcome. For example: add rd,rs instruction adds the contents of register rs to register rd and places the result in rd; add.cc rd, rs does the same and updates the condition codes. Can anybody point out an example of how such instructions should be defined in a corresponding xxInstrInfo.td file please? Sincerely, -- Lev. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100525/54f3a4e1/attachment.html From stoklund at 2pi.dk Tue May 25 10:49:51 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Tue, 25 May 2010 08:49:51 -0700 Subject: [LLVMdev] backend question In-Reply-To: References: Message-ID: On May 25, 2010, at 8:19 AM, Lev Yudalevich wrote: > Hello, > > I'm just starting to work on a backend for a custom cpu. For some instructions this cpu has two flavors: first performs an operation, and the second performs an operation and updates condition codes (carry, zero, overflow, negative etc) based on the outcome. For example: add rd,rs instruction adds the contents of register rs to register rd and places the result in rd; add.cc rd, rs does the same and updates the condition codes. Can anybody point out an example of how such instructions should be defined in a corresponding xxInstrInfo.td file please? ARM has similar instruction pairs, look at ADD/ADDS, SUB/SUBS in ARMInstrInfo.td /jakob From aeyakovenko at gmail.com Tue May 25 13:12:35 2010 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Tue, 25 May 2010 11:12:35 -0700 Subject: [LLVMdev] linker errors when trying to link llvm-gcc In-Reply-To: <4BFAD90A.8040708@free.fr> References: <4BFAD90A.8040708@free.fr> Message-ID: I am trying to build a cross compiler for arm on linux, here is how i have configured it cd llvm-gcc-4.2-2.7.source-objtree ../llvm-gcc-4.2-2.7.source/configure --enable-llvm=/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7 --enable-multilib --enable-target-optspace --enable-interwork --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --target=arm-elf --prefix=/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/arm-elf i've been able to build vanila gcc 4.2 to 4.5 using this configuration for arm, but not llvm. So i deleted my tree and tried again and i got these errors now: ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/lib1funcs.asm: Assembler messages: ../../llvm-gcc-4.2-2.7.source/gcc/config/arm/lib1funcs.asm:1004: Error: backward ref to unknown label "8:" Thanks, Anatoly On Mon, May 24, 2010 at 12:52 PM, Duncan Sands wrote: > Hi Anatoly, > >> any ideas what library has these symbols >> >> lang_eh_catch_all >> get_pointer_alignment >> validate_arglist > > it sounds like you are trying to build a version of llvm-gcc without LLVM > enabled. ?Did you specify --enable-llvm=path_to_llvm_build_directory when > configuring llvm-gcc? ?These symbols are all defined in llvm-gcc itself, > but only when ENABLE_LLVM is defined. ?This suggests to me that you somehow > configured llvm-gcc wrong. > > 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 Trevor.W.Harmon at nasa.gov Tue May 25 14:31:28 2010 From: Trevor.W.Harmon at nasa.gov (Trevor Harmon) Date: Tue, 25 May 2010 12:31:28 -0700 Subject: [LLVMdev] Basic doubt related to Module::iterator In-Reply-To: <4BFADA61.5060807@cse.iitb.ac.in> References: <4BFADA61.5060807@cse.iitb.ac.in> Message-ID: <22AA3D2E-5EEF-4CC2-AFC5-743084436795@nasa.gov> On May 24, 2010, at 12:58 PM, ambika wrote: > I run this for different files, each having one function each ie > main(), > but for one it loops twice, and for another it loops thrice. > for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I) It might be iterating over the LLVM intrinsic functions as well as the user-defined functions. Try printing out the function names on each iteration and see what you get. Trevor From anton at korobeynikov.info Tue May 25 14:46:57 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 25 May 2010 23:46:57 +0400 Subject: [LLVMdev] linker errors when trying to link llvm-gcc In-Reply-To: References: <4BFAD90A.8040708@free.fr> Message-ID: > ../llvm-gcc-4.2-2.7.source/configure > --enable-llvm=/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7 > --enable-multilib --enable-target-optspace --enable-interwork > --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ > --target=arm-elf This means that the compiler is built for ARMv4 which is not pretty good supported. Try to switch to ARMv7, e.g. adding --with-cpu=cortex-a8. Also, LLVM might not support interworking yet, so it's worth to remove this option as well. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From dag at cray.com Tue May 25 15:07:05 2010 From: dag at cray.com (David Greene) Date: Tue, 25 May 2010 15:07:05 -0500 Subject: [LLVMdev] Cray is Hiring! Message-ID: <201005251507.06419.dag@cray.com> Cray is hiring! Cray is looking for talented and motivated engineers to help develop compilers and other programming tools for state-of-the-art supercomputing platforms. Cray is a leader in designing and implementing supercomputers using future custom and commodity architectures. As system complexity grows, programming tools are a critical part of the Cray ecosystem to provide excellent usability and productivity to customers. Our tools are used around the world to help scientists and engineers solve the most challenging problems of our time, including climate modeling, weather prediction, life/bio sciences and atomic research. The Cray compiler team is a friendly, collaborative environment and individuals work in a self-directed fashion. Candidates should be able to deliver large projects and work with other team members toward solutions. Compiler experience is a big plus, but not strictly required. We are located in St. Paul, Minnesota in the heart of the Lowertown business and entertainment district. Interested candidates can browse job postings and submit an application at http://cray.com/About/Careers.aspx. Some specific postings are copied below, with many more viewable at the above website. Feel free to contact me at dag at cray.com for more information. -Dave --------------------- Software Engineer - Compiler Optimization Overview: Cray has an opening for a motivated and skilled software developer to join its Compiler group. Responsibilities: The Compiler Optimization Engineer will work on improving the optimization and parallelization phases of the Cray Fortran, C, and C++ compilers. This includes both significant research and product development activities, as Cray continues to advance the state of the art with automatic parallelization capabilities across dissimilar architectures. This work includes the design and implementation of new compiler-based optimizations, enhancing existing optimizations, the implementation of new high-level language features, adapting evolving programming models to Cray architectures, and working to improve the overall quality of the compiler. Qualifications: B.S. Computer Science or similar discipline is required. Advanced degrees are welcome. Experience in compiler development, particularly with regard to optimization and code generation is highly desired, but not essential for the right candidate. A good understanding of high performance computing (HPC) architectures, including multiprocessors, distributed memory systems, and GPU accelerators, is beneficial. Proficiency writing in C is critical, and familiarity with C++ is useful. Knowledge of Fortran is a plus, but not required. Commitment to sound software engineering principles, outstanding problem solving skills, ability to work well in a cooperative development environment, both within and across teams, and good written and verbal communications skills. Experience in working with large projects, or an advanced thesis in an appropriate area. --------------------- Performance Tools Development Engineer Overview: Cray has an opening for a motivated and skilled software engineer to join its team of performance analysis tools developers. Responsibilities: This position includes both significant research and product development activities. The selected candidate will develop and implement scalable data management techniques; combine analytic and simulation modeling techniques with performance measurements to help users identify problem areas; and help bring application optimization knowledge to a wider set of users, as Cray continues to advance the state of the art in performance analysis tools for Cray's current and future supercomputers. Qualifications: M.S. or Ph.D. in Computer Science or similar discipline. Three years experience in system software development or equivalent combination of education and experience, particularly with performance tools development. Background in high performance computing (HPC) architectures, including multiprocessors, distributed memory systems, and GPU accelerators, with understanding of scientific applications is highly desired. Proficiency in C, C++, or Java is required. Working knowledge of Fortran is a plus. Background in creating user-interfaces and data visualization is a plus. Experience with SQL query optimization is a plus. Experience with performance analysis of applications on large-scale systems is a plus. Experience in working with large projects, or an advanced thesis in an appropriate area is required. Commitment to sound software engineering principles, outstanding problem solving skills, ability to work well in a cooperative development environment, both within and across teams, and good written and verbal communications skills. Must be motivated to have an impact on our products, our company, and the state of the art. --------------------- Software Engineer - Compiler Test Writer Overview: Cray has an opening for a motivated and skilled software engineer to join its Programming Environments team of testers and performance engineers Responsibilities: Responsibilities include writing Fortran, C, C++ and hybrid programs to tests optimization and functionality of the Cray compilers; maintaining and updating existing tests, and reviewing compiler features requirements and design documents. Qualifications: B.S. in Computer Science or equivalent degree. Advanced degree is preferred. At least 5years experience writing test programs that find faults and deficiencies in the compilers and libraries. Strong knowledge of C, C++, and Fortran programming languages is required. Familiarity with CUDA, assembly language and compiler standards is a plus. Background in high performance computing (HPC) architectures, including multiprocessors, distributed memory systems, and GPU accelerators, including working knowledge of parallel programming -- MPT, OpenMP, and PGAS languages, is highly desired. understand compiler architecture (frontend, optimizer, code generator, etc) and understanding of test harnesses and automated test systems is needed. Experience in working with large projects, or an advanced thesis in an appropriate area. Commitment to sound software engineering principles, outstanding problem solving skills, ability to work well in a cooperative development environment, both within and across teams, and good written and verbal. Flexible work schedule. From aeyakovenko at gmail.com Tue May 25 15:25:04 2010 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Tue, 25 May 2010 13:25:04 -0700 Subject: [LLVMdev] linker errors when trying to link llvm-gcc In-Reply-To: References: <4BFAD90A.8040708@free.fr> Message-ID: thanks, that worked, also interworking built without problems. i haven't tested an elf with it yet though. On Tue, May 25, 2010 at 12:46 PM, Anton Korobeynikov wrote: >> ../llvm-gcc-4.2-2.7.source/configure >> --enable-llvm=/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7 >> --enable-multilib --enable-target-optspace --enable-interwork >> --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ >> --target=arm-elf > This means that the compiler is built for ARMv4 which is not pretty > good supported. > Try to switch to ARMv7, e.g. adding --with-cpu=cortex-a8. Also, LLVM > might not support interworking yet, so it's worth to remove this > option as well. > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University > From tim at bioware.com Tue May 25 16:58:32 2010 From: tim at bioware.com (Smith, Tim) Date: Tue, 25 May 2010 14:58:32 -0700 Subject: [LLVMdev] MSVC iterator debugging exception and RegReductionPriorityQueue V2.6 Message-ID: <9FF8D2C30ABB344A8E66DD17EE4FDEC6DABB5B4E88@NA-MAIL-2-3.rws.ad.ea.com> We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will abort if it isn't. Recently, we have started to see this error in the DAG. Call Stack: SelectionDAGISel::runOnMachineFunction:339 SelectionDAGISel::SelectAllBasicBlocks:401 SelectionDAGISel::CodeGenAndEmitDAG:603 ScheduleDAGSDNodes::Run:36 ScheduleDAG::Run:61 ScheduleDAGRRList::Schedule::185 ScheduleDAGRRList::ListScheduleBottomUp:736 RegReductionPriorityQueue::pop:1061 <-- exception here I haven't reported this as a bug because first I want to find out that in LLVM's usage of the std::priority_queue, could the relative priorities get changed after they are inserted in the queue thus causing the order to change? Has this been fixed in 2.7? Thanks --- Tim Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100525/44113ada/attachment.html From nbg2k7 at gmail.com Tue May 25 17:41:51 2010 From: nbg2k7 at gmail.com (Nehal) Date: Tue, 25 May 2010 22:41:51 +0000 (UTC) Subject: [LLVMdev] DEBUG INFO at the bytecode level References: <4BF26C2F.8080401@gmail.com> Message-ID: Devang Patel gmail.com> writes: > > 2010/5/18 Zheng Wang gmail.com>: > > > > I found DebugInfo.cpp may be useful. Could you tell me which function > > I should call inorder to know the source file name and the line number > > for a particular instruction? > > > > See http://llvm.org/docs/SourceLevelDebugging.html#ccxx_frontend > At the end of "C/C++ source file information" section, there is a > small code snippet this describes how to extract this information. > > - > Devang > Hi Devang, I think the link you provided above is for LLVM 2.7. Is there any way to get source line number from bitcode in LLVM 2.5/2.6? Thanks, Nehal. From ehsanamiri at gmail.com Tue May 25 19:16:10 2010 From: ehsanamiri at gmail.com (Ehsan Amiri) Date: Tue, 25 May 2010 17:16:10 -0700 Subject: [LLVMdev] i256 for x86_64 Message-ID: Hello all I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. Best Ehsan Input File: target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128" target triple = "x86_64-unknown-linux-gnu" define i32 @main(i32 %argc, i8** nocapture %argv) nounwind { entry: %0 = tail call i256 (...)* @get_num() nounwind ;comment here ret i32 0 } declare i256 @get_num(...) --------------------------------------------- First line of error: Call result #2 has unhandled type i64UNREACHABLE executed at CallingConvLower.cpp:148! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100525/5ba9a2bf/attachment.html From clattner at apple.com Tue May 25 19:25:52 2010 From: clattner at apple.com (Chris Lattner) Date: Tue, 25 May 2010 17:25:52 -0700 Subject: [LLVMdev] i256 for x86_64 In-Reply-To: References: Message-ID: On May 25, 2010, at 5:16 PM, Ehsan Amiri wrote: > Hello all > > I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. This works for me on mainline. Are you using an old version of llvm? -Chris > > Best > Ehsan > > Input File: > > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128" > target triple = "x86_64-unknown-linux-gnu" > > define i32 @main(i32 %argc, i8** nocapture %argv) nounwind { > entry: > > %0 = tail call i256 (...)* @get_num() nounwind ;comment here > ret i32 0 > } > > declare i256 @get_num(...) > > --------------------------------------------- > > First line of error: > > Call result #2 has unhandled type i64UNREACHABLE executed at CallingConvLower.cpp:148! > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ehsanamiri at gmail.com Tue May 25 19:29:36 2010 From: ehsanamiri at gmail.com (Ehsan Amiri) Date: Tue, 25 May 2010 17:29:36 -0700 Subject: [LLVMdev] i256 for x86_64 In-Reply-To: References: Message-ID: Yes I use 2.6 as my OS seems to be too old for 2.7. Are there any restrictions on integer types for x86_64? On Tue, May 25, 2010 at 5:25 PM, Chris Lattner wrote: > > On May 25, 2010, at 5:16 PM, Ehsan Amiri wrote: > > > Hello all > > > > I have a very simple handwritten .ll file that can be translated to > native assembly on x86_64 when I use i128. But if I use i256 I get an error. > see the file and the first line of the error below. Any help is appreciated! > I played a little bit with target datalayout but it didn't help. > > This works for me on mainline. Are you using an old version of llvm? > > -Chris > > > > > > Best > > Ehsan > > > > Input File: > > > > target datalayout = > "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128" > > target triple = "x86_64-unknown-linux-gnu" > > > > define i32 @main(i32 %argc, i8** nocapture %argv) nounwind { > > entry: > > > > %0 = tail call i256 (...)* @get_num() nounwind ;comment here > > ret i32 0 > > } > > > > declare i256 @get_num(...) > > > > --------------------------------------------- > > > > First line of error: > > > > Call result #2 has unhandled type i64UNREACHABLE executed at > CallingConvLower.cpp:148! > > _______________________________________________ > > 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/20100525/f87cf286/attachment.html From willdtz at gmail.com Tue May 25 19:53:48 2010 From: willdtz at gmail.com (Will Dietz) Date: Tue, 25 May 2010 19:53:48 -0500 Subject: [LLVMdev] AliasAnalysis as a Loadable Module, Possible 2.6->2.7 issue Message-ID: Hi all, First time posting to llvmdev, be gentle :). I'm working on an AliasAnalysis implementation and running into an issue on 2.7, that doesn't exist in 2.6 as far as I can tell. Short version: has anyone been able to load an AliasAnalysis module into 2.7's opt? Longer version: Even with a dummy pass implementation (just returns MayAlias for everything), I'm getting very strange behavior: All calls to FooAA::alias go to FooAA::print, resulting in understandably painful failure thereafter, generally a segfault. Example stack trace: ==25630== by 0xB2752F: llvm::Pass::print(llvm::raw_ostream&, llvm::Module const*) const (Pass.cpp:94) ==25630== by 0x9B2769: llvm::MemoryDependenceAnalysis::getPointerDependencyFrom(llvm::Value*, unsigned long, bool, llvm::ilist_iterator, llvm::BasicBlock*) (MemoryDependenceAnalysis.cpp:282) And the related lines from MemDep: 282 if (AccessPtr == Inst || 283 AA->alias(Inst, 1, AccessPtr, 1) == AliasAnalysis::MustAlias) The way I make this happen is to run: opt -load fooAA.so -foo-aa -dse (where "-foo-aa" is the AA pass defined in the module fooAA.so, and dse makes use of the aa results through memdep) Finally a short bit about my build env: GCC 4.4.3, Debug build, Linux x86_64. I'd be happy to provide any more information required/desired, but hopefully that covers the basics. Any thoughts? Is this a bug, or am I potentially doing something silly? Thanks for your time, ~Will From eli.friedman at gmail.com Tue May 25 22:11:33 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 25 May 2010 20:11:33 -0700 Subject: [LLVMdev] i256 for x86_64 In-Reply-To: References: Message-ID: On Tue, May 25, 2010 at 5:29 PM, Ehsan Amiri wrote: > Yes I use 2.6 as my OS seems to be too old for 2.7. > > Are there any restrictions on integer types for x86_64? There was a longstanding bug involving directly returning types too large to fit in registers. AFAIK, this was fixed for 2.7. If you need to use 2.6, generate code that returns the value by reference. -Eli From eli.friedman at gmail.com Tue May 25 22:13:07 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 25 May 2010 20:13:07 -0700 Subject: [LLVMdev] AliasAnalysis as a Loadable Module, Possible 2.6->2.7 issue In-Reply-To: References: Message-ID: On Tue, May 25, 2010 at 5:53 PM, Will Dietz wrote: > Hi all, > > First time posting to llvmdev, be gentle :). > > I'm working on an AliasAnalysis implementation and running into an > issue on 2.7, that doesn't exist in 2.6 as far as I can tell. > > Short version: has anyone been able to load an AliasAnalysis module > into 2.7's opt? > > Longer version: > > Even with a dummy pass implementation (just returns MayAlias for > everything), I'm getting very strange behavior: > > All calls to FooAA::alias go to FooAA::print, resulting in > understandably painful failure thereafter, generally a segfault. Are you sure you built your module against LLVM 2.7 headers? -Eli From hkultala at cs.tut.fi Wed May 26 02:08:06 2010 From: hkultala at cs.tut.fi (Heikki Kultala) Date: Wed, 26 May 2010 10:08:06 +0300 Subject: [LLVMdev] How to handle predicate registers which can also work inverted way. Message-ID: In our architecture (TCE) we have predicate registers, not flags. But our predicates work in a way that in the predicated instruction do not contain only the predicate register, but a predicate register and boolean value pair, the boolean value stating if the instruction is to be executed only if the register is true(normal behavior of predicate regs) or only if the predicate reg is false("inverted behaviour") So, for eample if we have a machine without "not equal"(ne) operation and we have a code where we would have an "ne" comparison followed by predicated jump, it is possible to do this with "eq" comparison followed by a inverted-predicate predicated jump. The problem is that we have not found a way to use those inverted guard, we don't know how to create the patterns/register classes which would allow us to do this, and currently we just do extra xor 1 operation to get a positive boolean value, "emulate ne with eq and xor" and then jump with normal predicate. This makes the code run slower. One idea is to introduce our boolean register twice to llvm, and make them aliases to each others, and then just create double patterns for all comparison operations, so that "eq" could be selected as "eq" to normal predicate reg class, or "ne" to inverted predicate class, and then having two predicated jump instructions, one reading the value from ordinary predicate reg, another from inverted predicate reg, creating usage of the inverted predicate. Could this work? Is it allowed to have multiple register classes working as predicate register class in llvm? and would the aliasing work without problems? And if this does not work, could someone give idea about some other solution that might work? From baldrick at free.fr Wed May 26 02:12:16 2010 From: baldrick at free.fr (Duncan Sands) Date: Wed, 26 May 2010 09:12:16 +0200 Subject: [LLVMdev] i256 for x86_64 In-Reply-To: References: Message-ID: <4BFCC9D0.7000102@free.fr> > Are there any restrictions on integer types for x86_64? You won't be able to return anything larger than i128 if you are using LLVM 2.6. Ciao, Duncan. From willdtz at gmail.com Wed May 26 03:41:10 2010 From: willdtz at gmail.com (Will Dietz) Date: Wed, 26 May 2010 03:41:10 -0500 Subject: [LLVMdev] AliasAnalysis as a Loadable Module, Possible 2.6->2.7 issue In-Reply-To: References: Message-ID: Thanks for the response, Eli. The header suggestion could certainly cause this issue (I panicked for a second), but unfortunately as far as I can tell the headers are in fact from LLVM 2.7. The pass is built as a project configured by llvm, so hopefully that would make things right, but also: --include paths look legit (make VERBOSE=1, etc) --strace on the build process for the project confirms no headers outside the llvm 2.7 tree are read, and 'svn diff' confirms I haven't managed to botch those. The code is from the "release_27" branch, for what it's worth. I'm not at all convinced I haven't somehow broken my build environment, but it's not clear to me how. Thoughts on anything else I could look into? For what it's worth, attached is the project triggering the issue, if someone gets bored and either wants to try it or tell me what I'm doing wrong :). Thanks for your time, ~Will On Tue, May 25, 2010 at 10:13 PM, Eli Friedman wrote: > On Tue, May 25, 2010 at 5:53 PM, Will Dietz wrote: >> Hi all, >> >> First time posting to llvmdev, be gentle :). >> >> I'm working on an AliasAnalysis implementation and running into an >> issue on 2.7, that doesn't exist in 2.6 as far as I can tell. >> >> Short version: has anyone been able to load an AliasAnalysis module >> into 2.7's opt? >> >> Longer version: >> >> Even with a dummy pass implementation (just returns MayAlias for >> everything), I'm getting very strange behavior: >> >> All calls to FooAA::alias go to FooAA::print, resulting in >> understandably painful failure thereafter, generally a segfault. > > Are you sure you built your module against LLVM 2.7 headers? > > -Eli > -------------- next part -------------- A non-text attachment was scrubbed... Name: test-aa.tar.bz2 Type: application/x-bzip2 Size: 32891 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100526/9be28e73/attachment-0001.bz2 From lyudalev at gmail.com Wed May 26 03:57:48 2010 From: lyudalev at gmail.com (Lev Yudalevich) Date: Wed, 26 May 2010 11:57:48 +0300 Subject: [LLVMdev] backend question In-Reply-To: References: Message-ID: Thank you very very much for your answer! Am I correct in my understanding that "let Defs = [CPSR]" in the definition of AI1_bin_s_irs multiclass explains the effect of setting conditional codes to the TableGen in ARM's case? Sincerely, -- Lev. On Tue, May 25, 2010 at 6:49 PM, Jakob Stoklund Olesen wrote: > > On May 25, 2010, at 8:19 AM, Lev Yudalevich wrote: > > > Hello, > > > > I'm just starting to work on a backend for a custom cpu. For some > instructions this cpu has two flavors: first performs an operation, and the > second performs an operation and updates condition codes (carry, zero, > overflow, negative etc) based on the outcome. For example: add rd,rs > instruction adds the contents of register rs to register rd and places the > result in rd; add.cc rd, rs does the same and updates the condition codes. > Can anybody point out an example of how such instructions should be defined > in a corresponding xxInstrInfo.td file please? > > ARM has similar instruction pairs, look at ADD/ADDS, SUB/SUBS in > ARMInstrInfo.td > > /jakob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100526/31bc0ece/attachment.html From jason.wangz at gmail.com Wed May 26 05:11:46 2010 From: jason.wangz at gmail.com (Zheng Wang) Date: Wed, 26 May 2010 11:11:46 +0100 Subject: [LLVMdev] DEBUG INFO at the bytecode level In-Reply-To: References: <4BF26C2F.8080401@gmail.com> Message-ID: Check out DebugInfo.cpp in lib/Analysis On 25 May 2010 23:41, Nehal wrote: > Devang Patel gmail.com> writes: > >> >> 2010/5/18 Zheng Wang gmail.com>: >> > >> > I found DebugInfo.cpp may be useful. Could you tell me which function >> > I should call inorder to know the source file name and the line number >> > for a particular instruction? >> > >> >> See http://llvm.org/docs/SourceLevelDebugging.html#ccxx_frontend >> At the end of ?"C/C++ source file information" section, there is a >> small code snippet this describes how to extract this information. >> >> - >> Devang >> > > Hi Devang, > > I think the link you provided above is for LLVM 2.7. Is there any way to get > source line number from bitcode in LLVM 2.5/2.6? > > Thanks, > Nehal. > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Best regards, WANG Zheng From criswell at illinois.edu Wed May 26 09:09:09 2010 From: criswell at illinois.edu (John Criswell) Date: Wed, 26 May 2010 08:09:09 -0600 Subject: [LLVMdev] AliasAnalysis as a Loadable Module, Possible 2.6->2.7 issue In-Reply-To: References: Message-ID: <4BFD2B85.4060704@illinois.edu> Dear Will, If you're seeing the wrong method executed, it's probably because you're using multiple inheritance in your analysis group (which is a very common thing to do). LLVM 2.7 made a change which alleviated the need for RTTI or some other undesirable C++ feature. However, it also broke multiple inheritance with analysis group passes. To fix it, your analysis group needs to implement a getAdjustedAnalysisPointer() method. The implementation should look something like this: /// When chaining analyses, changing the pointer to the correct pass virtual void *getAdjustedAnalysisPointer(const PassInfo *PI) { if (PI->isPassID(&ArrayBoundsCheckGroup::ID)) return (ArrayBoundsCheckGroup*)this; return this; } Just replace "ArrayBoundsCheckGroup" with whatever the name of your analysis group is, and it should work. -- John T. Will Dietz wrote: > Thanks for the response, Eli. > > The header suggestion could certainly cause this issue (I panicked for > a second), but unfortunately as far as I can tell the headers are in > fact from LLVM 2.7. > > The pass is built as a project configured by llvm, so hopefully that > would make things right, but also: > --include paths look legit (make VERBOSE=1, etc) > --strace on the build process for the project confirms no headers > outside the llvm 2.7 tree are read, and 'svn diff' confirms I haven't > managed to botch those. > > The code is from the "release_27" branch, for what it's worth. > > I'm not at all convinced I haven't somehow broken my build > environment, but it's not clear to me how. > > Thoughts on anything else I could look into? > > For what it's worth, attached is the project triggering the issue, if > someone gets bored and either wants to try it or tell me what I'm > doing wrong :). > > Thanks for your time, > > ~Will > > On Tue, May 25, 2010 at 10:13 PM, Eli Friedman wrote: > >> On Tue, May 25, 2010 at 5:53 PM, Will Dietz wrote: >> >>> Hi all, >>> >>> First time posting to llvmdev, be gentle :). >>> >>> I'm working on an AliasAnalysis implementation and running into an >>> issue on 2.7, that doesn't exist in 2.6 as far as I can tell. >>> >>> Short version: has anyone been able to load an AliasAnalysis module >>> into 2.7's opt? >>> >>> Longer version: >>> >>> Even with a dummy pass implementation (just returns MayAlias for >>> everything), I'm getting very strange behavior: >>> >>> All calls to FooAA::alias go to FooAA::print, resulting in >>> understandably painful failure thereafter, generally a segfault. >>> >> Are you sure you built your module against LLVM 2.7 headers? >> >> -Eli >> > > From willdtz at gmail.com Wed May 26 10:09:17 2010 From: willdtz at gmail.com (Will Dietz) Date: Wed, 26 May 2010 10:09:17 -0500 Subject: [LLVMdev] AliasAnalysis as a Loadable Module, Possible 2.6->2.7 issue In-Reply-To: <4BFD2B85.4060704@illinois.edu> References: <4BFD2B85.4060704@illinois.edu> Message-ID: Hi John, Thank you very much for your reply and explanation. This was indeed my issue and fixes it nicely. Have a good one, ~Will On Wed, May 26, 2010 at 9:09 AM, John Criswell wrote: > Dear Will, > > If you're seeing the wrong method executed, it's probably because you're > using multiple inheritance in your analysis group (which is a very common > thing to do). > > LLVM 2.7 made a change which alleviated the need for RTTI or some other > undesirable C++ feature. ?However, it also broke multiple inheritance with > analysis group passes. ?To fix it, your analysis group needs to implement a > getAdjustedAnalysisPointer() method. ?The implementation should look > something like this: > > /// When chaining analyses, changing the pointer to the correct pass > virtual void *getAdjustedAnalysisPointer(const PassInfo *PI) { > ? if (PI->isPassID(&ArrayBoundsCheckGroup::ID)) > ? ? ? return (ArrayBoundsCheckGroup*)this; > ? return this; > } > > Just replace "ArrayBoundsCheckGroup" with whatever the name of your analysis > group is, and it should work. > > -- John T. > > > Will Dietz wrote: >> >> Thanks for the response, Eli. >> >> The header suggestion could certainly cause this issue (I panicked for >> a second), but unfortunately as far as I can tell the headers are in >> fact from LLVM 2.7. >> >> The pass is built as a project configured by llvm, so hopefully that >> would make things right, but also: >> --include paths look legit (make VERBOSE=1, etc) >> --strace on the build process for the project confirms no headers >> outside the llvm 2.7 tree are read, and 'svn diff' confirms I haven't >> managed to botch those. >> >> The code is from the "release_27" branch, for what it's worth. >> >> I'm not at all convinced I haven't somehow broken my build >> environment, but it's not clear to me how. >> >> Thoughts on anything else I could look into? >> >> For what it's worth, attached is the project triggering the issue, if >> someone gets bored and either wants to try it or tell me what I'm >> doing wrong :). >> >> Thanks for your time, >> >> ~Will >> >> On Tue, May 25, 2010 at 10:13 PM, Eli Friedman >> wrote: >> >>> >>> On Tue, May 25, 2010 at 5:53 PM, Will Dietz wrote: >>> >>>> >>>> Hi all, >>>> >>>> First time posting to llvmdev, be gentle :). >>>> >>>> I'm working on an AliasAnalysis implementation and running into an >>>> issue on 2.7, that doesn't exist in 2.6 as far as I can tell. >>>> >>>> Short version: has anyone been able to load an AliasAnalysis module >>>> into 2.7's opt? >>>> >>>> Longer version: >>>> >>>> Even with a dummy pass implementation (just returns MayAlias for >>>> everything), I'm getting very strange behavior: >>>> >>>> All calls to FooAA::alias go to FooAA::print, resulting in >>>> understandably painful failure thereafter, generally a segfault. >>>> >>> >>> Are you sure you built your module against LLVM 2.7 headers? >>> >>> -Eli >>> >> >> > > > From stoklund at 2pi.dk Wed May 26 11:11:57 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Wed, 26 May 2010 09:11:57 -0700 Subject: [LLVMdev] backend question In-Reply-To: References: Message-ID: <0032E95B-53DE-492C-972B-40CC6A27AB3F@2pi.dk> On May 26, 2010, at 1:57 AM, Lev Yudalevich wrote: > Thank you very very much for your answer! > > Am I correct in my understanding that "let Defs = [CPSR]" in the definition of AI1_bin_s_irs multiclass explains the effect of setting conditional codes to the TableGen in ARM's case? Yes, that tells the instruction selector and scheduler that the CPSR register is clobbered by this instruction. From stoklund at 2pi.dk Wed May 26 11:23:56 2010 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Wed, 26 May 2010 09:23:56 -0700 Subject: [LLVMdev] How to handle predicate registers which can also work inverted way. In-Reply-To: References: Message-ID: On May 26, 2010, at 12:08 AM, Heikki Kultala wrote: > In our architecture (TCE) we have predicate registers, not flags. The old IA64 backend had a similar architecture. The code was removed because nobody was maintaining it. > But our predicates work in a way that in the predicated instruction do not contain only the predicate register, > but a predicate register and boolean value pair, the boolean value stating if the instruction is to be executed > only if the register is true(normal behavior of predicate regs) or only if the predicate reg is false("inverted behaviour") > > So, for eample if we have a machine without "not equal"(ne) operation and we have a code where we would have an > "ne" comparison followed by predicated jump, it is possible to do this with "eq" comparison followed by a inverted-predicate predicated jump. The Blackfin processor does the same. It has only half of the SETCC conditions, and "if cc jump" and "if !cc jump" instructions. > The problem is that we have not found a way to use those inverted guard, we don't know how to create the patterns/register classes which would allow us to do this, and currently we just do extra xor 1 operation to get a positive boolean value, "emulate ne with eq and xor" and then jump with normal predicate. This makes the code run slower. > > One idea is to introduce our boolean register twice to llvm, and make them aliases to each others, and then just create double patterns for all comparison operations, so that "eq" could be selected as "eq" to normal predicate reg class, or "ne" to inverted predicate class, and then having two predicated jump instructions, one reading the value from ordinary predicate reg, another from inverted predicate reg, creating usage of the inverted predicate. This is exactly what the Blackfin backend does. Look at the CC and NCC registers. > Could this work? Is it allowed to have multiple register classes working as predicate register class in llvm? and would the aliasing work without problems? The aliasing should not cause any problems. You may run into issues with having legal i1 registers. The IA64 backend never fully worked, causing weird DAG combiner assertions on i1 arithmetic. Aim to fix the DAG combiner - it should work. /jakob From yuri at tsoft.com Wed May 26 14:16:03 2010 From: yuri at tsoft.com (Yuri) Date: Wed, 26 May 2010 12:16:03 -0700 Subject: [LLVMdev] Why llvm values can't start with %1? Message-ID: <4BFD7373.5000303@tsoft.com> After I manually modified .ll file deleting %0 I am getting this error from llvm-as: lvm-as: my.ll:43:3: error: instruction expected to be numbered '%0' %1 = tail call noalias i8* @malloc(i32 8) nounwind ; [#uses=1] ^ So now I have to also rename all other % variables? Why llvm is so strict with naming? I think it should just accept whatever names are there as long as they make a valid .ll file. Yuri From samuraileumas at yahoo.com Wed May 26 14:27:13 2010 From: samuraileumas at yahoo.com (Samuel Crow) Date: Wed, 26 May 2010 12:27:13 -0700 (PDT) Subject: [LLVMdev] Fw: Why llvm values can't start with %1? In-Reply-To: <4BFD7373.5000303@tsoft.com> References: <4BFD7373.5000303@tsoft.com> Message-ID: <450186.69746.qm@web62006.mail.re1.yahoo.com> Whoops! Forgot to send it to the list! ----- Forwarded Message ---- > From: Samuel Crow > To: Yuri > Sent: Wed, May 26, 2010 2:26:05 PM > Subject: Re: [LLVMdev] Why llvm values can't start with %1? > > Hi Yuri If you want to, you can name the registers with %r1 or some other > string with a number after it. My guess about the reason it's so strict > with the numbered SSA registers is that it automatically numbers unnamed > registers internally without registering a name in memory. If you do give > it a name, it will take more memory but will be more flexible in the conventions > used to name the registers. --Sam ----- Original > Message ---- > From: Yuri < > href="mailto:yuri at tsoft.com">yuri at tsoft.com> > To: LLVM Developers > Mailing List < > href="mailto:llvmdev at cs.uiuc.edu">llvmdev at cs.uiuc.edu> > Sent: Wed, > May 26, 2010 2:16:03 PM > Subject: [LLVMdev] Why llvm values can't start > with %1? > > After I manually modified .ll file deleting %0 I am > getting this error from > llvm-as: lvm-as: my.ll:43:3: error: > instruction expected to be numbered > '%0' %1 = tail call > noalias i8* @malloc(i32 8) nounwind ; > [#uses=1] > ^ So now I have to also rename all other % > variables? > Why llvm is so strict with naming? I think it should just accept > > whatever names are there as long as they make a valid .ll > > file. Yuri _______________________________________________ LLVM > > Developers mailing list > href="mailto: > ymailto="mailto:LLVMdev at cs.uiuc.edu" > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu"> > ymailto="mailto:LLVMdev at cs.uiuc.edu" > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu > > > > http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From arplynn at gmail.com Wed May 26 16:20:24 2010 From: arplynn at gmail.com (Alistair Lynn) Date: Wed, 26 May 2010 22:20:24 +0100 Subject: [LLVMdev] [llvm-commits] [llvm] r104737 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp In-Reply-To: <39292977-DC9E-44B0-9885-E622125C3392@apple.com> References: <20100526203900.6D697312800A@llvm.org> <2A330469-BF29-4E25-A6BD-933B290390BF@apple.com> <39292977-DC9E-44B0-9885-E622125C3392@apple.com> Message-ID: Hello- Shouldn't this catch swapcontext as well? Alistair On 26 May 2010, at 22:14, Dale Johannesen wrote: > > On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: > >> vfork and getcontext have wildly platform-dependent semantics. >> Handling >> them conservatively is reasonable, even if some platforms don't need >> it. >> >> Dan > > Agreed. Also, the performance of code in the area of a vfork call is > not going to be critical. > >> On May 26, 2010, at 1:48 PM, Evan Cheng wrote: >> >>> Definitely not vfork. That's unnecessary. gcc is mistaken, we >>> shouldn't follow it. Also, getcontext is such a generic name. It's >>> a really bad idea to look for it. > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From wendling at apple.com Wed May 26 17:02:32 2010 From: wendling at apple.com (Bill Wendling) Date: Wed, 26 May 2010 15:02:32 -0700 Subject: [LLVMdev] [llvm-commits] [llvm] r104737 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp In-Reply-To: References: <20100526203900.6D697312800A@llvm.org> <2A330469-BF29-4E25-A6BD-933B290390BF@apple.com> <39292977-DC9E-44B0-9885-E622125C3392@apple.com> Message-ID: I didn't see swapcontext in the list in gcc's special_function_p function... -bw On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > Hello- > > Shouldn't this catch swapcontext as well? > > Alistair > > On 26 May 2010, at 22:14, Dale Johannesen wrote: > >> >> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >> >>> vfork and getcontext have wildly platform-dependent semantics. >>> Handling >>> them conservatively is reasonable, even if some platforms don't need >>> it. >>> >>> Dan >> >> Agreed. Also, the performance of code in the area of a vfork call is >> not going to be critical. >> >>> On May 26, 2010, at 1:48 PM, Evan Cheng wrote: >>> >>>> Definitely not vfork. That's unnecessary. gcc is mistaken, we >>>> shouldn't follow it. Also, getcontext is such a generic name. It's >>>> a really bad idea to look for it. >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > _______________________________________________ > 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 Wed May 26 17:26:42 2010 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 26 May 2010 15:26:42 -0700 Subject: [LLVMdev] MSVC iterator debugging exception and RegReductionPriorityQueue V2.6 In-Reply-To: <9FF8D2C30ABB344A8E66DD17EE4FDEC6DABB5B4E88@NA-MAIL-2-3.rws.ad.ea.com> References: <9FF8D2C30ABB344A8E66DD17EE4FDEC6DABB5B4E88@NA-MAIL-2-3.rws.ad.ea.com> Message-ID: <3344400A-6E47-4C7B-93DA-A6C905F6889A@apple.com> On May 25, 2010, at 2:58 PM, Smith, Tim wrote: > We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. > > When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will abort if it isn?t. > > Recently, we have started to see this error in the DAG. > > Call Stack: > > SelectionDAGISel::runOnMachineFunction:339 > SelectionDAGISel::SelectAllBasicBlocks:401 > SelectionDAGISel::CodeGenAndEmitDAG:603 > ScheduleDAGSDNodes::Run:36 > ScheduleDAG::Run:61 > ScheduleDAGRRList::Schedule::185 > ScheduleDAGRRList::ListScheduleBottomUp:736 > RegReductionPriorityQueue::pop:1061 <-- exception here > > I haven?t reported this as a bug because first I want to find out that in LLVM?s usage of the std::priority_queue, could the relative priorities get changed after they are inserted in the queue thus causing the order to change? I believe that's precisely the problem. > > Has this been fixed in 2.7? No. Evan > > Thanks > > --- > Tim Smith > _______________________________________________ > 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/20100526/22ec24aa/attachment.html From evan.cheng at apple.com Wed May 26 17:31:00 2010 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 26 May 2010 15:31:00 -0700 Subject: [LLVMdev] MSVC iterator debugging exception and RegReductionPriorityQueue V2.6 In-Reply-To: <3344400A-6E47-4C7B-93DA-A6C905F6889A@apple.com> References: <9FF8D2C30ABB344A8E66DD17EE4FDEC6DABB5B4E88@NA-MAIL-2-3.rws.ad.ea.com> <3344400A-6E47-4C7B-93DA-A6C905F6889A@apple.com> Message-ID: <7CC197B9-EA89-487A-AC56-83F04A2658A4@apple.com> On May 26, 2010, at 3:26 PM, Evan Cheng wrote: > > On May 25, 2010, at 2:58 PM, Smith, Tim wrote: > >> We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. >> >> When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will abort if it isn?t. >> >> Recently, we have started to see this error in the DAG. >> >> Call Stack: >> >> SelectionDAGISel::runOnMachineFunction:339 >> SelectionDAGISel::SelectAllBasicBlocks:401 >> SelectionDAGISel::CodeGenAndEmitDAG:603 >> ScheduleDAGSDNodes::Run:36 >> ScheduleDAG::Run:61 >> ScheduleDAGRRList::Schedule::185 >> ScheduleDAGRRList::ListScheduleBottomUp:736 >> RegReductionPriorityQueue::pop:1061 <-- exception here >> >> I haven?t reported this as a bug because first I want to find out that in LLVM?s usage of the std::priority_queue, could the relative priorities get changed after they are inserted in the queue thus causing the order to change? > > I believe that's precisely the problem. > >> >> Has this been fixed in 2.7? > > No. I should mention Dan has fixed this as of r104718. Evan > > Evan > >> >> Thanks >> >> --- >> Tim Smith >> _______________________________________________ >> 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/20100526/c81f7a23/attachment.html From tim at bioware.com Wed May 26 17:51:15 2010 From: tim at bioware.com (Smith, Tim) Date: Wed, 26 May 2010 15:51:15 -0700 Subject: [LLVMdev] MSVC iterator debugging exception and RegReductionPriorityQueue V2.6 In-Reply-To: <7CC197B9-EA89-487A-AC56-83F04A2658A4@apple.com> References: <9FF8D2C30ABB344A8E66DD17EE4FDEC6DABB5B4E88@NA-MAIL-2-3.rws.ad.ea.com> <3344400A-6E47-4C7B-93DA-A6C905F6889A@apple.com> <7CC197B9-EA89-487A-AC56-83F04A2658A4@apple.com> Message-ID: <9FF8D2C30ABB344A8E66DD17EE4FDEC6DABB927FB8@NA-MAIL-2-3.rws.ad.ea.com> Huge thanks for a quick response and patch. From: Evan Cheng [mailto:evan.cheng at apple.com] Sent: Wednesday, May 26, 2010 4:31 PM To: Evan Cheng Cc: Smith, Tim; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MSVC iterator debugging exception and RegReductionPriorityQueue V2.6 On May 26, 2010, at 3:26 PM, Evan Cheng wrote: On May 25, 2010, at 2:58 PM, Smith, Tim wrote: We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will abort if it isn't. Recently, we have started to see this error in the DAG. Call Stack: SelectionDAGISel::runOnMachineFunction:339 SelectionDAGISel::SelectAllBasicBlocks:401 SelectionDAGISel::CodeGenAndEmitDAG:603 ScheduleDAGSDNodes::Run:36 ScheduleDAG::Run:61 ScheduleDAGRRList::Schedule::185 ScheduleDAGRRList::ListScheduleBottomUp:736 RegReductionPriorityQueue::pop:1061 <-- exception here I haven't reported this as a bug because first I want to find out that in LLVM's usage of the std::priority_queue, could the relative priorities get changed after they are inserted in the queue thus causing the order to change? I believe that's precisely the problem. Has this been fixed in 2.7? No. I should mention Dan has fixed this as of r104718. Evan Evan Thanks --- Tim Smith _______________________________________________ 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/20100526/825ef2c0/attachment.html From arplynn at gmail.com Wed May 26 18:02:31 2010 From: arplynn at gmail.com (Alistair Lynn) Date: Thu, 27 May 2010 00:02:31 +0100 Subject: [LLVMdev] [llvm-commits] [llvm] r104737 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp In-Reply-To: References: <20100526203900.6D697312800A@llvm.org> <2A330469-BF29-4E25-A6BD-933B290390BF@apple.com> <39292977-DC9E-44B0-9885-E622125C3392@apple.com> Message-ID: Hi- Then that, surely, is a bug in gcc? swapcontext saves the context (via getcontext) in its first argument - there is nothing to prevent subsequently calling setcontext on that first argument more than once, which would result in multiple returns? Alistair On 26 May 2010, at 23:02, Bill Wendling wrote: > I didn't see swapcontext in the list in gcc's special_function_p function... > > -bw > > On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > >> Hello- >> >> Shouldn't this catch swapcontext as well? >> >> Alistair >> >> On 26 May 2010, at 22:14, Dale Johannesen wrote: >> >>> >>> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >>> >>>> vfork and getcontext have wildly platform-dependent semantics. >>>> Handling >>>> them conservatively is reasonable, even if some platforms don't need >>>> it. >>>> >>>> Dan >>> >>> Agreed. Also, the performance of code in the area of a vfork call is >>> not going to be critical. >>> >>>> On May 26, 2010, at 1:48 PM, Evan Cheng wrote: >>>> >>>>> Definitely not vfork. That's unnecessary. gcc is mistaken, we >>>>> shouldn't follow it. Also, getcontext is such a generic name. It's >>>>> a really bad idea to look for it. >>> _______________________________________________ >>> llvm-commits mailing list >>> llvm-commits at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From kdubb at me.com Wed May 26 19:20:21 2010 From: kdubb at me.com (kdubb) Date: Wed, 26 May 2010 17:20:21 -0700 (PDT) Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 Message-ID: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> We are looking at using Objective-C/C++ in a new game engine. ?Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. This means that we will need a way to compile it on all platforms our games will target. ?Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. ?Now the PC, Mac, iPhone and PS3 are fairly simple. ?If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. ?This leaves us with the XBox 360. The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). ?I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries.?So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. ?Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. ?So... is this feasible? ?If so... how do I get LLVM to output C code? Thanks, Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100526/b3c82db8/attachment.html From dalej at apple.com Wed May 26 20:19:04 2010 From: dalej at apple.com (Dale Johannesen) Date: Wed, 26 May 2010 18:19:04 -0700 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> Message-ID: <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> llvm can output C code, but that target has bitrotted severely over the last few months and nobody seems to be interested in fixing it. You may need to do some work there. Alternatively you could implement the PPC ABI that you need. There are several examples of supporting multiple ABIs on the same hardware, x86 being the most obvious. A lot of simple stuff will probably Just Work with the existing PPC ABI, more complicated stuff may not. (Only 32-bit PPC is really maintained, though, there are probably lots of problems with 64-bit.) Objective C in llvm, AFAIK, is only used on the MacOSX targets and only tested there. There are sufficient secret handshakes between the compiler and the ObjC runtime that it is unlikely to Just Work in an untested environment. OpenStep has a familial relationship to MacOSX ObjC runtime, but they aren't the same and are unlikely to still be binary compatible at this point. You may need to do some work there also. Summary, you can probably get this approach to work, but it's not as easy as you're hoping. On May 26, 2010, at 5:20 PMPDT, kdubb wrote: > We are looking at using Objective-C/C++ in a new game engine. Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. > > This means that we will need a way to compile it on all platforms our games will target. Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. This leaves us with the XBox 360. > > The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries. So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. > > If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. So... is this feasible? If so... how do I get LLVM to output C code? > > Thanks, > Kevin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sherief at mganin.com Wed May 26 22:08:02 2010 From: sherief at mganin.com (Sherief Farouk) Date: Wed, 26 May 2010 23:08:02 -0400 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> Message-ID: I'm slightly confused here, just to be clear: you're planning to go ObjC -> LLVM (via Clang or whatever) -> C, then use the 360 SDK compiler to build that, right? If that's the case, I think it'd be a better option than to use LLVM to directly generate XEXs, and you won't give the TCR guys fits (I checked the BAS TCRs, none of them say you can't do that, but the platform has some requirements regarding binary code that I doubt you'll get right without a lot of effort). If that is the pipeline you had in mind, have you attempted to run a Hello World app yet? Ran into any errors? - Sherief On May 26, 2010, at 8:20 PM, kdubb wrote: > We are looking at using Objective-C/C++ in a new game engine. Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. > > This means that we will need a way to compile it on all platforms our games will target. Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. This leaves us with the XBox 360. > > The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries. So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. > > If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. So... is this feasible? If so... how do I get LLVM to output C code? > > Thanks, > Kevin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From kdubb at me.com Thu May 27 01:48:43 2010 From: kdubb at me.com (Kevin Wooten) Date: Wed, 26 May 2010 23:48:43 -0700 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> Message-ID: This is certainly an option... but keeping up an LLVM backend for the 360 seems like a bit much work. Using Clang's rewriter requires no real low-level maintenance, just creating and maintaining a C library for support functions emitted by the compiler (e.g. objc_msgSend). It seems to create a backend for LLVM targeting the 360 I wouldn't need to create something that outputs XEX's anyway. My custom backend would effectively create object files that the 360's linker would have to be able to recognize. This would mean not only outputting all the correct ABI conforming code but the correct PDB debugging information as well. It seems much less, and easier, work to implement the support functions and run it through the standard xbox compiler as the ABI and debugging information are taken care of. On May 26, 2010, at 8:08 PM, Sherief Farouk wrote: > I'm slightly confused here, just to be clear: you're planning to go ObjC -> LLVM (via Clang or whatever) -> C, then use the 360 SDK compiler to build that, right? If that's the case, I think it'd be a better option than to use LLVM to directly generate XEXs, and you won't give the TCR guys fits (I checked the BAS TCRs, none of them say you can't do that, but the platform has some requirements regarding binary code that I doubt you'll get right without a lot of effort). If that is the pipeline you had in mind, have you attempted to run a Hello World app yet? Ran into any errors? > > - Sherief > > On May 26, 2010, at 8:20 PM, kdubb wrote: > >> We are looking at using Objective-C/C++ in a new game engine. Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. >> >> This means that we will need a way to compile it on all platforms our games will target. Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. This leaves us with the XBox 360. >> >> The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries. So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. >> >> If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. So... is this feasible? If so... how do I get LLVM to output C code? >> >> Thanks, >> Kevin >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From kdubb at me.com Thu May 27 02:15:08 2010 From: kdubb at me.com (Kevin Wooten) Date: Thu, 27 May 2010 00:15:08 -0700 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> Message-ID: <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> Implementing the backend (or editing the current PPC backend as needed) is a definite option. This seems to be the real question... which is easier... maintaining the PPC backend or maintaining the rewriter. Currently (in admittedly trivial tests) I have gotten the rewriter to work and output C code. There are some outstanding issues to do with linking and accessing the reflection information objective-c provides (and the rewriter properly outputs) but I am sure the person/people who wrote the rewriter can answer those fairly simply (or else the rewriter would be fairly useless). As far as the runtime goes there is an implementation for windows, linux and most likely the PS3 (since it is already a linux derivative using GCC as mentioned). If we have to create a runtime for PS3 and XBox that seems trivial as the functions are very basic in nature. My comments on OpenStep were more meant to point to the fact that we would write our own library; really just throwing all notion of OpenStep away. Instead of NSObject we would create our own base DObject or something along with a DString, DAarry, DSet, DMap, etc. Truthfully this would be our plan anyway because we want to follow the lead of OSX and provide these objects "toll free bridged"... meaning we would implement them using a std c++ library object (e.g. std::basic_string or std::vector) as the first member of the object which will allow us to cast a DString to std::string or DArray to std::vector without any manual or automatic marshaling. As mentioned this is how OSX implements its NS classes, by using the equivalent CF version which again allows casting between the objects. On May 26, 2010, at 6:19 PM, Dale Johannesen wrote: > llvm can output C code, but that target has bitrotted severely over the last few months and nobody seems to be interested in fixing it. You may need to do some work there. Alternatively you could implement the PPC ABI that you need. There are several examples of supporting multiple ABIs on the same hardware, x86 being the most obvious. A lot of simple stuff will probably Just Work with the existing PPC ABI, more complicated stuff may not. (Only 32-bit PPC is really maintained, though, there are probably lots of problems with 64-bit.) > > Objective C in llvm, AFAIK, is only used on the MacOSX targets and only tested there. There are sufficient secret handshakes between the compiler and the ObjC runtime that it is unlikely to Just Work in an untested environment. OpenStep has a familial relationship to MacOSX ObjC runtime, but they aren't the same and are unlikely to still be binary compatible at this point. You may need to do some work there also. > > Summary, you can probably get this approach to work, but it's not as easy as you're hoping. > > On May 26, 2010, at 5:20 PMPDT, kdubb wrote: > >> We are looking at using Objective-C/C++ in a new game engine. Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. >> >> This means that we will need a way to compile it on all platforms our games will target. Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. This leaves us with the XBox 360. >> >> The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries. So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. >> >> If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. So... is this feasible? If so... how do I get LLVM to output C code? >> >> Thanks, >> Kevin >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From devlists at shadowlab.org Thu May 27 02:54:21 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 27 May 2010 09:54:21 +0200 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> Message-ID: <112287E7-7A71-45F1-A0E5-9D1D9F9DDB02@shadowlab.org> Le 27 mai 2010 ? 08:48, Kevin Wooten a ?crit : > This is certainly an option... but keeping up an LLVM backend for the 360 seems like a bit much work. Using Clang's rewriter requires no real low-level maintenance, just creating and maintaining a C library for support functions emitted by the compiler (e.g. objc_msgSend). > The clang rewriter is not the same than LLVM C backend. AFAIK, clang rewriter don't use llvm at all (as it does not perform codegen). It is just a source to source conversion. I don't know how it work yet, but if it is design to output code for the NeXT Runtime, you may have to tweak it to output code compatible with your runtim. > It seems to create a backend for LLVM targeting the 360 I wouldn't need to create something that outputs XEX's anyway. My custom backend would effectively create object files that the 360's linker would have to be able to recognize. This would mean not only outputting all the correct ABI conforming code but the correct PDB debugging information as well. It seems much less, and easier, work to implement the support functions and run it through the standard xbox compiler as the ABI and debugging information are taken care of. > > On May 26, 2010, at 8:08 PM, Sherief Farouk wrote: > >> I'm slightly confused here, just to be clear: you're planning to go ObjC -> LLVM (via Clang or whatever) -> C, then use the 360 SDK compiler to build that, right? If that's the case, I think it'd be a better option than to use LLVM to directly generate XEXs, and you won't give the TCR guys fits (I checked the BAS TCRs, none of them say you can't do that, but the platform has some requirements regarding binary code that I doubt you'll get right without a lot of effort). If that is the pipeline you had in mind, have you attempted to run a Hello World app yet? Ran into any errors? >> >> - Sherief >> >> On May 26, 2010, at 8:20 PM, kdubb wrote: >> >>> We are looking at using Objective-C/C++ in a new game engine. Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. >>> >>> This means that we will need a way to compile it on all platforms our games will target. Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. This leaves us with the XBox 360. >>> >>> The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries. So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. >>> >>> If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. So... is this feasible? If so... how do I get LLVM to output C code? >>> >>> Thanks, >>> Kevin >>> -- Jean-Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100527/debb8116/attachment-0001.html From devlists at shadowlab.org Thu May 27 03:18:32 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 27 May 2010 10:18:32 +0200 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> Message-ID: <16620639-957B-4A8E-A1DF-FEFB02F8FE7B@shadowlab.org> Le 27 mai 2010 ? 09:15, Kevin Wooten a ?crit : > Implementing the backend (or editing the current PPC backend as needed) is a definite option. This seems to be the real question... which is easier... maintaining the PPC backend or maintaining the rewriter. Currently (in admittedly trivial tests) I have gotten the rewriter to work and output C code. There are some outstanding issues to do with linking and accessing the reflection information objective-c provides (and the rewriter properly outputs) but I am sure the person/people who wrote the rewriter can answer those fairly simply (or else the rewriter would be fairly useless). > > As far as the runtime goes there is an implementation for windows, linux and most likely the PS3 (since it is already a linux derivative using GCC as mentioned). If we have to create a runtime for PS3 and XBox that seems trivial as the functions are very basic in nature. > > My comments on OpenStep were more meant to point to the fact that we would write our own library; really just throwing all notion of OpenStep away. Instead of NSObject we would create our own base DObject or something along with a DString, DAarry, DSet, DMap, etc. Truthfully this would be our plan anyway because we want to follow the lead of OSX and provide these objects "toll free bridged"... meaning we would implement them using a std c++ library object (e.g. std::basic_string or std::vector) as the first member of the object which will allow us to cast a DString to std::string or DArray to std::vector without any manual or automatic marshaling. As mentioned this is how OSX implements its NS classes, by using the equivalent CF version which again allows casting between the objects. This is not how the CFBridge works. Actually, the first member of an object MUST be a pointer to its Class (the isa pointer). If you want to be able to put something else, you will have to rewrite the runtime to support it. You can read this great article about the bridge here: http://ridiculousfish.com/blog/archives/2006/09/09/bridge/#fish_made_a_mess and an other one here: http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html And you can also have a look at the stripped down version of the CoreFoundation sources to get some other clues about how it works now. http://www.opensource.apple.com/source/CF/CF-550.13/ -- Jean-Daniel > On May 26, 2010, at 6:19 PM, Dale Johannesen wrote: > >> llvm can output C code, but that target has bitrotted severely over the last few months and nobody seems to be interested in fixing it. You may need to do some work there. Alternatively you could implement the PPC ABI that you need. There are several examples of supporting multiple ABIs on the same hardware, x86 being the most obvious. A lot of simple stuff will probably Just Work with the existing PPC ABI, more complicated stuff may not. (Only 32-bit PPC is really maintained, though, there are probably lots of problems with 64-bit.) >> >> Objective C in llvm, AFAIK, is only used on the MacOSX targets and only tested there. There are sufficient secret handshakes between the compiler and the ObjC runtime that it is unlikely to Just Work in an untested environment. OpenStep has a familial relationship to MacOSX ObjC runtime, but they aren't the same and are unlikely to still be binary compatible at this point. You may need to do some work there also. >> >> Summary, you can probably get this approach to work, but it's not as easy as you're hoping. >> >> On May 26, 2010, at 5:20 PMPDT, kdubb wrote: >> >>> We are looking at using Objective-C/C++ in a new game engine. Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. >>> >>> This means that we will need a way to compile it on all platforms our games will target. Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. This leaves us with the XBox 360. >>> >>> The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries. So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. >>> >>> If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. So... is this feasible? If so... how do I get LLVM to output C code? >>> >>> Thanks, >>> Kevin >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100527/d61d3994/attachment.html From kdubb at me.com Thu May 27 04:01:40 2010 From: kdubb at me.com (Kevin Wooten) Date: Thu, 27 May 2010 02:01:40 -0700 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <16620639-957B-4A8E-A1DF-FEFB02F8FE7B@shadowlab.org> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> <16620639-957B-4A8E-A1DF-FEFB02F8FE7B@shadowlab.org> Message-ID: Thanks for the articles! There is definitely some stuff in there I hadn't thought of; also, it quite obviously points out that it's actually not "toll free" at all but "very low cost"! This won't affect us too much though since we will be creating our own objective-c classes from scratch and we are not trying to maintain backward compatibility. A simple solution would just be to have a method that returns our underlying implementation object (e.g. a std::basic_string for GString) and/or make the ivar implementation object public and let anybody access it. On May 27, 2010, at 1:18 AM, Jean-Daniel Dupas wrote: > > Le 27 mai 2010 ? 09:15, Kevin Wooten a ?crit : > >> Implementing the backend (or editing the current PPC backend as needed) is a definite option. This seems to be the real question... which is easier... maintaining the PPC backend or maintaining the rewriter. Currently (in admittedly trivial tests) I have gotten the rewriter to work and output C code. There are some outstanding issues to do with linking and accessing the reflection information objective-c provides (and the rewriter properly outputs) but I am sure the person/people who wrote the rewriter can answer those fairly simply (or else the rewriter would be fairly useless). >> >> As far as the runtime goes there is an implementation for windows, linux and most likely the PS3 (since it is already a linux derivative using GCC as mentioned). If we have to create a runtime for PS3 and XBox that seems trivial as the functions are very basic in nature. >> >> My comments on OpenStep were more meant to point to the fact that we would write our own library; really just throwing all notion of OpenStep away. Instead of NSObject we would create our own base DObject or something along with a DString, DAarry, DSet, DMap, etc. Truthfully this would be our plan anyway because we want to follow the lead of OSX and provide these objects "toll free bridged"... meaning we would implement them using a std c++ library object (e.g. std::basic_string or std::vector) as the first member of the object which will allow us to cast a DString to std::string or DArray to std::vector without any manual or automatic marshaling. As mentioned this is how OSX implements its NS classes, by using the equivalent CF version which again allows casting between the objects. > > > This is not how the CFBridge works. Actually, the first member of an object MUST be a pointer to its Class (the isa pointer). If you want to be able to put something else, you will have to rewrite the runtime to support it. > > You can read this great article about the bridge here: > > http://ridiculousfish.com/blog/archives/2006/09/09/bridge/#fish_made_a_mess > > and an other one here: > > http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html > > And you can also have a look at the stripped down version of the CoreFoundation sources to get some other clues about how it works now. > > http://www.opensource.apple.com/source/CF/CF-550.13/ > > -- Jean-Daniel > >> On May 26, 2010, at 6:19 PM, Dale Johannesen wrote: >> >>> llvm can output C code, but that target has bitrotted severely over the last few months and nobody seems to be interested in fixing it. You may need to do some work there. Alternatively you could implement the PPC ABI that you need. There are several examples of supporting multiple ABIs on the same hardware, x86 being the most obvious. A lot of simple stuff will probably Just Work with the existing PPC ABI, more complicated stuff may not. (Only 32-bit PPC is really maintained, though, there are probably lots of problems with 64-bit.) >>> >>> Objective C in llvm, AFAIK, is only used on the MacOSX targets and only tested there. There are sufficient secret handshakes between the compiler and the ObjC runtime that it is unlikely to Just Work in an untested environment. OpenStep has a familial relationship to MacOSX ObjC runtime, but they aren't the same and are unlikely to still be binary compatible at this point. You may need to do some work there also. >>> >>> Summary, you can probably get this approach to work, but it's not as easy as you're hoping. >>> >>> On May 26, 2010, at 5:20 PMPDT, kdubb wrote: >>> >>>> We are looking at using Objective-C/C++ in a new game engine. Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. >>>> >>>> This means that we will need a way to compile it on all platforms our games will target. Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. This leaves us with the XBox 360. >>>> >>>> The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries. So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. >>>> >>>> If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. So... is this feasible? If so... how do I get LLVM to output C code? >>>> >>>> Thanks, >>>> Kevin >>>> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100527/0a4da536/attachment.html From kdubb at me.com Thu May 27 04:10:09 2010 From: kdubb at me.com (Kevin Wooten) Date: Thu, 27 May 2010 02:10:09 -0700 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <112287E7-7A71-45F1-A0E5-9D1D9F9DDB02@shadowlab.org> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <112287E7-7A71-45F1-A0E5-9D1D9F9DDB02@shadowlab.org> Message-ID: <11393242-2D72-4A66-B458-55D459709977@me.com> I believe you are correct, the Clang rewriter seems to stay completely inside the Clang universe. Although, I think you can argue whether or not Clang is part of LLVM (it is listed on the main page as a primary sub-project). Either way my point was to compare the "ease" of the two methods, the Clang rewriter or modifying LLVM's PPC backend to output object code. On May 27, 2010, at 12:54 AM, Jean-Daniel Dupas wrote: > > Le 27 mai 2010 ? 08:48, Kevin Wooten a ?crit : > >> This is certainly an option... but keeping up an LLVM backend for the 360 seems like a bit much work. Using Clang's rewriter requires no real low-level maintenance, just creating and maintaining a C library for support functions emitted by the compiler (e.g. objc_msgSend). >> > > The clang rewriter is not the same than LLVM C backend. AFAIK, clang rewriter don't use llvm at all (as it does not perform codegen). It is just a source to source conversion. > I don't know how it work yet, but if it is design to output code for the NeXT Runtime, you may have to tweak it to output code compatible with your runtim. > >> It seems to create a backend for LLVM targeting the 360 I wouldn't need to create something that outputs XEX's anyway. My custom backend would effectively create object files that the 360's linker would have to be able to recognize. This would mean not only outputting all the correct ABI conforming code but the correct PDB debugging information as well. It seems much less, and easier, work to implement the support functions and run it through the standard xbox compiler as the ABI and debugging information are taken care of. >> >> On May 26, 2010, at 8:08 PM, Sherief Farouk wrote: >> >>> I'm slightly confused here, just to be clear: you're planning to go ObjC -> LLVM (via Clang or whatever) -> C, then use the 360 SDK compiler to build that, right? If that's the case, I think it'd be a better option than to use LLVM to directly generate XEXs, and you won't give the TCR guys fits (I checked the BAS TCRs, none of them say you can't do that, but the platform has some requirements regarding binary code that I doubt you'll get right without a lot of effort). If that is the pipeline you had in mind, have you attempted to run a Hello World app yet? Ran into any errors? >>> >>> - Sherief >>> >>> On May 26, 2010, at 8:20 PM, kdubb wrote: >>> >>>> We are looking at using Objective-C/C++ in a new game engine. Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. >>>> >>>> This means that we will need a way to compile it on all platforms our games will target. Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. This leaves us with the XBox 360. >>>> >>>> The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries. So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. >>>> >>>> If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. So... is this feasible? If so... how do I get LLVM to output C code? >>>> >>>> Thanks, >>>> Kevin >>>> > > -- Jean-Daniel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100527/eb5b2e73/attachment.html From nicolas.capens at gmail.com Thu May 27 08:08:48 2010 From: nicolas.capens at gmail.com (Nicolas Capens) Date: Thu, 27 May 2010 15:08:48 +0200 Subject: [LLVMdev] Deep JIT specialization Message-ID: Hi all, I'm attempting to use LLVM for run-time code specialization, but I'm facing a performance hurdle. I'm currently performing the specialization during the AST to LLVM IR translation, but unfortunately this leads to relatively slow recompiles as LLVM has to perform all the heavy (optimization) passes over and over again. So I was hoping that by first creating unspecialized LLVM IR, optimizing that as much as possible, and then performing the specializations starting from this optimized IR, the recompiles would be significantly faster. Currently the mem2reg and instcombine passes take the majority of compilation time, which could be avoided using "deep" JIT specialization. So my question is how do I get started with this? Currently tracking the specialization parameters and caching the generated specialized functions is done outside of LLVM. So I imagine I'll have to somehow inform LLVM of the semi-constant values of the specialization parameters, without losing the original (optimized) IR. Can I add and remove specialized function instances at run-time? Thanks for any pointers! Kind regards, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100527/2296a76b/attachment.html From alexr at leftfield.org Thu May 27 10:09:11 2010 From: alexr at leftfield.org (Alex Rosenberg) Date: Thu, 27 May 2010 08:09:11 -0700 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> Message-ID: <3B2595AF-E7B5-462D-BAE8-425CFF829C84@leftfield.org> PS3 is not "a Linux derivative." The compilers supplied by SCE for PS3 game development are highly customized and support a customized ABI that will take some time to adjust LLVM and Clang to support. You'd likely also run afoul of a TRC or two, similar to the problems you'll face with Microsoft TCRs mentioned earlier. Alex On May 27, 2010, at 12:15 AM, Kevin Wooten wrote: > Implementing the backend (or editing the current PPC backend as > needed) is a definite option. This seems to be the real question... > which is easier... maintaining the PPC backend or maintaining the > rewriter. Currently (in admittedly trivial tests) I have gotten the > rewriter to work and output C code. There are some outstanding > issues to do with linking and accessing the reflection information > objective-c provides (and the rewriter properly outputs) but I am > sure the person/people who wrote the rewriter can answer those > fairly simply (or else the rewriter would be fairly useless). > > As far as the runtime goes there is an implementation for windows, > linux and most likely the PS3 (since it is already a linux > derivative using GCC as mentioned). If we have to create a runtime > for PS3 and XBox that seems trivial as the functions are very basic > in nature. > > My comments on OpenStep were more meant to point to the fact that we > would write our own library; really just throwing all notion of > OpenStep away. Instead of NSObject we would create our own base > DObject or something along with a DString, DAarry, DSet, DMap, etc. > Truthfully this would be our plan anyway because we want to follow > the lead of OSX and provide these objects "toll free bridged"... > meaning we would implement them using a std c++ library object (e.g. > std::basic_string or std::vector) as the first member of the object > which will allow us to cast a DString to std::string or DArray to > std::vector without any manual or automatic marshaling. As mentioned > this is how OSX implements its NS classes, by using the equivalent > CF version which again allows casting between the objects. > > On May 26, 2010, at 6:19 PM, Dale Johannesen wrote: > >> llvm can output C code, but that target has bitrotted severely over >> the last few months and nobody seems to be interested in fixing >> it. You may need to do some work there. Alternatively you could >> implement the PPC ABI that you need. There are several examples of >> supporting multiple ABIs on the same hardware, x86 being the most >> obvious. A lot of simple stuff will probably Just Work with the >> existing PPC ABI, more complicated stuff may not. (Only 32-bit PPC >> is really maintained, though, there are probably lots of problems >> with 64-bit.) >> >> Objective C in llvm, AFAIK, is only used on the MacOSX targets and >> only tested there. There are sufficient secret handshakes between >> the compiler and the ObjC runtime that it is unlikely to Just Work >> in an untested environment. OpenStep has a familial relationship >> to MacOSX ObjC runtime, but they aren't the same and are unlikely >> to still be binary compatible at this point. You may need to do >> some work there also. >> >> Summary, you can probably get this approach to work, but it's not >> as easy as you're hoping. >> >> On May 26, 2010, at 5:20 PMPDT, kdubb wrote: >> >>> We are looking at using Objective-C/C++ in a new game engine. >>> Objective C's duality of being both very dynamic and very "C" >>> gives us exactly what we need to make the SDK and engineering of >>> games simpler. >>> >>> This means that we will need a way to compile it on all platforms >>> our games will target. Currently the major platforms we are >>> concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the >>> PC, Mac, iPhone and PS3 are fairly simple. If we build our own >>> OpenStep libraries we can simply use LLVM to compile directly to >>> these platforms; the PS3 although proprietary uses GCC as a C/C++ >>> compiler so I am assuming Objective-C can be used fairly simply. >>> This leaves us with the XBox 360. >>> >>> The 360 is a special chip (PowerPC based) with, as far as I have >>> researched, a special ABI (Windows derivative). I haven't the >>> faintest clue of whether code from the LLVM PPC backend would even >>> work on the 360, much less interoperate with the system libraries. >>> So my formulated solution has become this: use an LLVM backend to >>> output C code and then compile that code with using MS's XBox 360 >>> compiler. I believe I have read that LLVM has a C backend already >>> but I don't know how to select it. >>> >>> If I can get a proof of concept showing Objective-C code running >>> on the 360 we are off to the races. Any help is appreciated just >>> not sure if all the pieces/parts exist and/or what I am missing. >>> So... is this feasible? If so... how do I get LLVM to output C >>> code? >>> >>> Thanks, >>> Kevin >>> _______________________________________________ >>> 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 renato.golin at arm.com Thu May 27 10:22:36 2010 From: renato.golin at arm.com (Renato Golin) Date: Thu, 27 May 2010 16:22:36 +0100 Subject: [LLVMdev] ARM Relocation Information Message-ID: <000101cafdb0$702a1d00$507e5700$@golin@arm.com> Hi all, Does anyone knows where to add relocation information to assembly data instructions? For instance, ARM GCC generates symbols like: _ZTIi (TARGET2) While Clang doesn't include the TARGET2 relocation information, and that mess up cross-linking. Looking at the AsmPrinter, when emitting the global constant value (EmitGlobalConstant), it calls EmitGlobalConstantImpl, which end up using EmitValue or EmitIntValue, but neither has relocation information on them. Also, searching the code, I couldn't find any reference to relocation or any of the basic relocation types available in Codesourcery's GCC. Is there anything at all in LLVM regarding relocations? If not, what would be the best place to add and link from ARMMC* and ARMAsmPrinter? Thanks, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100527/7e6c24a9/attachment.html From anton at korobeynikov.info Thu May 27 11:14:01 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 27 May 2010 20:14:01 +0400 Subject: [LLVMdev] ARM Relocation Information In-Reply-To: <-8465418086893673538@unknownmsgid> References: <-8465418086893673538@unknownmsgid> Message-ID: Hello, Renato > While Clang doesn?t include the TARGET2 relocation information, and that > mess up cross-linking. Is there any documentation for this stuff? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From kdubb at me.com Thu May 27 11:26:17 2010 From: kdubb at me.com (Kevin Wooten) Date: Thu, 27 May 2010 09:26:17 -0700 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <3B2595AF-E7B5-462D-BAE8-425CFF829C84@leftfield.org> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> <3B2595AF-E7B5-462D-BAE8-425CFF829C84@leftfield.org> Message-ID: <2F03D29A-0355-4965-AF58-8F5759A1350E@me.com> By linux derivative I meant that it borrows the linux GCC ABI... and it does. You can compile with an off the shelf GCC cross compiler and link the resultant object files ones compiled with the PS3 provided version. We have done it. Also, as both an XBox 360 and PS3 developer, there seems to me to be nothing in the TCRs/TRCs that preclude us from using a different compiler. There are rules about symbol inclusion and other resultant binary requirements... but as of yet I have not found specific ones stopping us from using a compiler that works. In either case the LLVM rewriter solves any other these issues as we would be just be compiling C. On May 27, 2010, at 8:09 AM, Alex Rosenberg wrote: > PS3 is not "a Linux derivative." The compilers supplied by SCE for PS3 game development are highly customized and support a customized ABI that will take some time to adjust LLVM and Clang to support. > > You'd likely also run afoul of a TRC or two, similar to the problems you'll face with Microsoft TCRs mentioned earlier. > > Alex > > On May 27, 2010, at 12:15 AM, Kevin Wooten wrote: > >> Implementing the backend (or editing the current PPC backend as needed) is a definite option. This seems to be the real question... which is easier... maintaining the PPC backend or maintaining the rewriter. Currently (in admittedly trivial tests) I have gotten the rewriter to work and output C code. There are some outstanding issues to do with linking and accessing the reflection information objective-c provides (and the rewriter properly outputs) but I am sure the person/people who wrote the rewriter can answer those fairly simply (or else the rewriter would be fairly useless). >> >> As far as the runtime goes there is an implementation for windows, linux and most likely the PS3 (since it is already a linux derivative using GCC as mentioned). If we have to create a runtime for PS3 and XBox that seems trivial as the functions are very basic in nature. >> >> My comments on OpenStep were more meant to point to the fact that we would write our own library; really just throwing all notion of OpenStep away. Instead of NSObject we would create our own base DObject or something along with a DString, DAarry, DSet, DMap, etc. Truthfully this would be our plan anyway because we want to follow the lead of OSX and provide these objects "toll free bridged"... meaning we would implement them using a std c++ library object (e.g. std::basic_string or std::vector) as the first member of the object which will allow us to cast a DString to std::string or DArray to std::vector without any manual or automatic marshaling. As mentioned this is how OSX implements its NS classes, by using the equivalent CF version which again allows casting between the objects. >> >> On May 26, 2010, at 6:19 PM, Dale Johannesen wrote: >> >>> llvm can output C code, but that target has bitrotted severely over the last few months and nobody seems to be interested in fixing it. You may need to do some work there. Alternatively you could implement the PPC ABI that you need. There are several examples of supporting multiple ABIs on the same hardware, x86 being the most obvious. A lot of simple stuff will probably Just Work with the existing PPC ABI, more complicated stuff may not. (Only 32-bit PPC is really maintained, though, there are probably lots of problems with 64-bit.) >>> >>> Objective C in llvm, AFAIK, is only used on the MacOSX targets and only tested there. There are sufficient secret handshakes between the compiler and the ObjC runtime that it is unlikely to Just Work in an untested environment. OpenStep has a familial relationship to MacOSX ObjC runtime, but they aren't the same and are unlikely to still be binary compatible at this point. You may need to do some work there also. >>> >>> Summary, you can probably get this approach to work, but it's not as easy as you're hoping. >>> >>> On May 26, 2010, at 5:20 PMPDT, kdubb wrote: >>> >>>> We are looking at using Objective-C/C++ in a new game engine. Objective C's duality of being both very dynamic and very "C" gives us exactly what we need to make the SDK and engineering of games simpler. >>>> >>>> This means that we will need a way to compile it on all platforms our games will target. Currently the major platforms we are concerned with include... PC, Mac, XBox 360, PS3, iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If we build our own OpenStep libraries we can simply use LLVM to compile directly to these platforms; the PS3 although proprietary uses GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. This leaves us with the XBox 360. >>>> >>>> The 360 is a special chip (PowerPC based) with, as far as I have researched, a special ABI (Windows derivative). I haven't the faintest clue of whether code from the LLVM PPC backend would even work on the 360, much less interoperate with the system libraries. So my formulated solution has become this: use an LLVM backend to output C code and then compile that code with using MS's XBox 360 compiler. I believe I have read that LLVM has a C backend already but I don't know how to select it. >>>> >>>> If I can get a proof of concept showing Objective-C code running on the 360 we are off to the races. Any help is appreciated just not sure if all the pieces/parts exist and/or what I am missing. So... is this feasible? If so... how do I get LLVM to output C code? >>>> >>>> Thanks, >>>> Kevin >>>> _______________________________________________ >>>> 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 renato.golin at arm.com Thu May 27 11:31:22 2010 From: renato.golin at arm.com (Renato Golin) Date: Thu, 27 May 2010 17:31:22 +0100 Subject: [LLVMdev] ARM Relocation Information In-Reply-To: References: <-8465418086893673538@unknownmsgid> Message-ID: <000601cafdba$0b865da0$229318e0$@golin@arm.com> > -----Original Message----- > Is there any documentation for this stuff? Hi Anton, Sure, EABI pdfs. For instance, the EHABI (4.4.2) state that "exception tables should be free of dynamic relocations. A static relocation may be applied to an exception table for the following purposes:" and list them, including RTTI (which is TARGET2). What I couldn't find, however, was a complete list of all cases and their specific relocations. AAELF 4.7.1.2 list (and explain briefly) all supported relocation types. GCC doesn't support all of them, so you can have a look in its source for the most used ones. Digging a bit deeper I saw that MCAsmStreamer is the one printing the values. So I could modify MCExpr to include a MCRelocation that gets printed, if available, following the platform specific relocation types (eg. ARMMCRelocation.print()), with the default being null. Does it seem fair? It's my first dig into MC stuff, might be completely wrong... ;) Cheers, --renato From clattner at apple.com Thu May 27 11:44:44 2010 From: clattner at apple.com (Chris Lattner) Date: Thu, 27 May 2010 09:44:44 -0700 Subject: [LLVMdev] Deep JIT specialization In-Reply-To: References: Message-ID: <331335A5-154F-4DF0-AF44-DC0543039035@apple.com> On May 27, 2010, at 6:08 AM, Nicolas Capens wrote: > Hi all, > > I'm attempting to use LLVM for run-time code specialization, but I'm facing a performance hurdle. I'm currently performing the specialization during the AST to LLVM IR translation, but unfortunately this leads to relatively slow recompiles as LLVM has to perform all the heavy (optimization) passes over and over again. > > So I was hoping that by first creating unspecialized LLVM IR, optimizing that as much as possible, and then performing the specializations starting from this optimized IR, the recompiles would be significantly faster. Currently the mem2reg and instcombine passes take the majority of compilation time, which could be avoided using "deep" JIT specialization. > > So my question is how do I get started with this? Currently tracking the specialization parameters and caching the generated specialized functions is done outside of LLVM. So I imagine I'll have to somehow inform LLVM of the semi-constant values of the specialization parameters, without losing the original (optimized) IR. Can I add and remove specialized function instances at run-time? > Hi Nicolas, Nate Begeman's "building an efficient JIT" talk about the llvm developer meeting last year (or the year before) is a great place to start looking for this sort of thing. -Chris From alexr at leftfield.org Thu May 27 12:15:27 2010 From: alexr at leftfield.org (Alex Rosenberg) Date: Thu, 27 May 2010 10:15:27 -0700 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <2F03D29A-0355-4965-AF58-8F5759A1350E@me.com> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> <3B2595AF-E7B5-462D-BAE8-425CFF829C84@leftfield.org> <2F03D29A-0355-4965-AF58-8F5759A1350E@me.com> Message-ID: Please create a thread on DevNet to discuss this further. Alex On May 27, 2010, at 9:26 AM, Kevin Wooten wrote: > By linux derivative I meant that it borrows the linux GCC ABI... and > it does. You can compile with an off the shelf GCC cross compiler > and link the resultant object files ones compiled with the PS3 > provided version. We have done it. > > Also, as both an XBox 360 and PS3 developer, there seems to me to be > nothing in the TCRs/TRCs that preclude us from using a different > compiler. There are rules about symbol inclusion and other > resultant binary requirements... but as of yet I have not found > specific ones stopping us from using a compiler that works. In > either case the LLVM rewriter solves any other these issues as we > would be just be compiling C. > > On May 27, 2010, at 8:09 AM, Alex Rosenberg wrote: > >> PS3 is not "a Linux derivative." The compilers supplied by SCE for >> PS3 game development are highly customized and support a customized >> ABI that will take some time to adjust LLVM and Clang to support. >> >> You'd likely also run afoul of a TRC or two, similar to the >> problems you'll face with Microsoft TCRs mentioned earlier. >> >> Alex >> >> On May 27, 2010, at 12:15 AM, Kevin Wooten wrote: >> >>> Implementing the backend (or editing the current PPC backend as >>> needed) is a definite option. This seems to be the real >>> question... which is easier... maintaining the PPC backend or >>> maintaining the rewriter. Currently (in admittedly trivial tests) >>> I have gotten the rewriter to work and output C code. There are >>> some outstanding issues to do with linking and accessing the >>> reflection information objective-c provides (and the rewriter >>> properly outputs) but I am sure the person/people who wrote the >>> rewriter can answer those fairly simply (or else the rewriter >>> would be fairly useless). >>> >>> As far as the runtime goes there is an implementation for windows, >>> linux and most likely the PS3 (since it is already a linux >>> derivative using GCC as mentioned). If we have to create a >>> runtime for PS3 and XBox that seems trivial as the functions are >>> very basic in nature. >>> >>> My comments on OpenStep were more meant to point to the fact that >>> we would write our own library; really just throwing all notion of >>> OpenStep away. Instead of NSObject we would create our own base >>> DObject or something along with a DString, DAarry, DSet, DMap, >>> etc. Truthfully this would be our plan anyway because we want to >>> follow the lead of OSX and provide these objects "toll free >>> bridged"... meaning we would implement them using a std c++ >>> library object (e.g. std::basic_string or std::vector) as the >>> first member of the object which will allow us to cast a DString >>> to std::string or DArray to std::vector without any manual or >>> automatic marshaling. As mentioned this is how OSX implements its >>> NS classes, by using the equivalent CF version which again allows >>> casting between the objects. >>> >>> On May 26, 2010, at 6:19 PM, Dale Johannesen wrote: >>> >>>> llvm can output C code, but that target has bitrotted severely >>>> over the last few months and nobody seems to be interested in >>>> fixing it. You may need to do some work there. Alternatively >>>> you could implement the PPC ABI that you need. There are several >>>> examples of supporting multiple ABIs on the same hardware, x86 >>>> being the most obvious. A lot of simple stuff will probably Just >>>> Work with the existing PPC ABI, more complicated stuff may not. >>>> (Only 32-bit PPC is really maintained, though, there are probably >>>> lots of problems with 64-bit.) >>>> >>>> Objective C in llvm, AFAIK, is only used on the MacOSX targets >>>> and only tested there. There are sufficient secret handshakes >>>> between the compiler and the ObjC runtime that it is unlikely to >>>> Just Work in an untested environment. OpenStep has a familial >>>> relationship to MacOSX ObjC runtime, but they aren't the same and >>>> are unlikely to still be binary compatible at this point. You >>>> may need to do some work there also. >>>> >>>> Summary, you can probably get this approach to work, but it's not >>>> as easy as you're hoping. >>>> >>>> On May 26, 2010, at 5:20 PMPDT, kdubb wrote: >>>> >>>>> We are looking at using Objective-C/C++ in a new game engine. >>>>> Objective C's duality of being both very dynamic and very "C" >>>>> gives us exactly what we need to make the SDK and engineering of >>>>> games simpler. >>>>> >>>>> This means that we will need a way to compile it on all >>>>> platforms our games will target. Currently the major platforms >>>>> we are concerned with include... PC, Mac, XBox 360, PS3, >>>>> iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If >>>>> we build our own OpenStep libraries we can simply use LLVM to >>>>> compile directly to these platforms; the PS3 although >>>>> proprietary uses GCC as a C/C++ compiler so I am assuming >>>>> Objective-C can be used fairly simply. This leaves us with the >>>>> XBox 360. >>>>> >>>>> The 360 is a special chip (PowerPC based) with, as far as I have >>>>> researched, a special ABI (Windows derivative). I haven't the >>>>> faintest clue of whether code from the LLVM PPC backend would >>>>> even work on the 360, much less interoperate with the system >>>>> libraries. So my formulated solution has become this: use an >>>>> LLVM backend to output C code and then compile that code with >>>>> using MS's XBox 360 compiler. I believe I have read that LLVM >>>>> has a C backend already but I don't know how to select it. >>>>> >>>>> If I can get a proof of concept showing Objective-C code running >>>>> on the 360 we are off to the races. Any help is appreciated >>>>> just not sure if all the pieces/parts exist and/or what I am >>>>> missing. So... is this feasible? If so... how do I get LLVM to >>>>> output C code? >>>>> >>>>> Thanks, >>>>> Kevin >>>>> _______________________________________________ >>>>> 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 pocmatos at gmail.com Thu May 27 13:02:58 2010 From: pocmatos at gmail.com (Paulo J. Matos) Date: Thu, 27 May 2010 19:02:58 +0100 Subject: [LLVMdev] TargetDescription string documentation Message-ID: Hello, I am trying to find out where the complete documentation for the TargetDescription string documentation is. I am reading the tutorial and looking at the sparc backend at the same time and there are some discrepancies. Therefore the documentation would be extremely valuable but I can't seem to find it. In the tutorial it shows the string "E-p:32:32-f128:128:128", but the real sparc backend has "E-p:32:32:32-i16:16:16-f32:32:32-f128:64:64-n32". The tutorial doesn't explain what the 'n' stands for, or why 'f' shows up twice (I can guess the first might be for floats and the second for doubles, but the tutorial has a different story about doubles. Here's where I am reading it from: http://llvm.org/docs/WritingAnLLVMBackend.html I would be grateful for any explanation or pointers to documentation. Cheers, -- PMatos From criswell at uiuc.edu Thu May 27 13:09:33 2010 From: criswell at uiuc.edu (John Criswell) Date: Thu, 27 May 2010 13:09:33 -0500 Subject: [LLVMdev] TargetDescription string documentation In-Reply-To: References: Message-ID: <4BFEB55D.3080003@uiuc.edu> Paulo J. Matos wrote: > Hello, > > I am trying to find out where the complete documentation for the > TargetDescription string documentation is. > I am reading the tutorial and looking at the sparc backend at the same > time and there are some discrepancies. Therefore the documentation > would be extremely valuable but I can't seem to find it. > > In the tutorial it shows the string "E-p:32:32-f128:128:128", > but the real sparc backend has > "E-p:32:32:32-i16:16:16-f32:32:32-f128:64:64-n32". > > The tutorial doesn't explain what the 'n' stands for, or why 'f' shows > up twice (I can guess the first might be for floats and the second for > doubles, but the tutorial has a different story about doubles. > > Here's where I am reading it from: > http://llvm.org/docs/WritingAnLLVMBackend.html > > I would be grateful for any explanation or pointers to documentation. > > Cheers, > I believe what you want is documented here: http://llvm.org/docs/LangRef.html#datalayout -- John T. From sherief at mganin.com Thu May 27 13:09:57 2010 From: sherief at mganin.com (Sherief Farouk) Date: Thu, 27 May 2010 14:09:57 -0400 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <3B2595AF-E7B5-462D-BAE8-425CFF829C84@leftfield.org> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> <3B2595AF-E7B5-462D-BAE8-425CFF829C84@leftfield.org> Message-ID: <2A82519A-1098-4112-A3A0-6534B88A2AB9@mganin.com> Just to be clear, nothing in the MS TCRs require that you use a certain compiler - it does, however, require that you link with the 360-specific C runtime libraries. That being said, I still believe that direct binary generation is not a feasible option, and the ObjC => C route is preferred. Kevin, hate to be asking this but do you have access to the XDK or are you just "aiming" for it? - Sherief On May 27, 2010, at 11:09 AM, Alex Rosenberg wrote: > PS3 is not "a Linux derivative." The compilers supplied by SCE for PS3 > game development are highly customized and support a customized ABI > that will take some time to adjust LLVM and Clang to support. > > You'd likely also run afoul of a TRC or two, similar to the problems > you'll face with Microsoft TCRs mentioned earlier. > > Alex From sherief at mganin.com Thu May 27 13:12:30 2010 From: sherief at mganin.com (Sherief Farouk) Date: Thu, 27 May 2010 14:12:30 -0400 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> <3B2595AF-E7B5-462D-BAE8-425CFF829C84@leftfield.org> <2F03D29A-0355-4965-AF58-8F5759A1350E@me.com> Message-ID: Why? I think the discussion belongs here, and the topic doesn't seem to include proprietary information - a lot of 360 info has been made public through MS material. Other info can be discussed without much disclosure (we can refer to TCRs by three-letter category and number, etc). - Sherief On May 27, 2010, at 1:15 PM, Alex Rosenberg wrote: > Please create a thread on DevNet to discuss this further. > > Alex > > On May 27, 2010, at 9:26 AM, Kevin Wooten wrote: > >> By linux derivative I meant that it borrows the linux GCC ABI... and >> it does. You can compile with an off the shelf GCC cross compiler >> and link the resultant object files ones compiled with the PS3 >> provided version. We have done it. >> >> Also, as both an XBox 360 and PS3 developer, there seems to me to be >> nothing in the TCRs/TRCs that preclude us from using a different >> compiler. There are rules about symbol inclusion and other >> resultant binary requirements... but as of yet I have not found >> specific ones stopping us from using a compiler that works. In >> either case the LLVM rewriter solves any other these issues as we >> would be just be compiling C. >> >> On May 27, 2010, at 8:09 AM, Alex Rosenberg wrote: >> >>> PS3 is not "a Linux derivative." The compilers supplied by SCE for >>> PS3 game development are highly customized and support a customized >>> ABI that will take some time to adjust LLVM and Clang to support. >>> >>> You'd likely also run afoul of a TRC or two, similar to the >>> problems you'll face with Microsoft TCRs mentioned earlier. >>> >>> Alex >>> >>> On May 27, 2010, at 12:15 AM, Kevin Wooten wrote: >>> >>>> Implementing the backend (or editing the current PPC backend as >>>> needed) is a definite option. This seems to be the real >>>> question... which is easier... maintaining the PPC backend or >>>> maintaining the rewriter. Currently (in admittedly trivial tests) >>>> I have gotten the rewriter to work and output C code. There are >>>> some outstanding issues to do with linking and accessing the >>>> reflection information objective-c provides (and the rewriter >>>> properly outputs) but I am sure the person/people who wrote the >>>> rewriter can answer those fairly simply (or else the rewriter >>>> would be fairly useless). >>>> >>>> As far as the runtime goes there is an implementation for windows, >>>> linux and most likely the PS3 (since it is already a linux >>>> derivative using GCC as mentioned). If we have to create a >>>> runtime for PS3 and XBox that seems trivial as the functions are >>>> very basic in nature. >>>> >>>> My comments on OpenStep were more meant to point to the fact that >>>> we would write our own library; really just throwing all notion of >>>> OpenStep away. Instead of NSObject we would create our own base >>>> DObject or something along with a DString, DAarry, DSet, DMap, >>>> etc. Truthfully this would be our plan anyway because we want to >>>> follow the lead of OSX and provide these objects "toll free >>>> bridged"... meaning we would implement them using a std c++ >>>> library object (e.g. std::basic_string or std::vector) as the >>>> first member of the object which will allow us to cast a DString >>>> to std::string or DArray to std::vector without any manual or >>>> automatic marshaling. As mentioned this is how OSX implements its >>>> NS classes, by using the equivalent CF version which again allows >>>> casting between the objects. >>>> >>>> On May 26, 2010, at 6:19 PM, Dale Johannesen wrote: >>>> >>>>> llvm can output C code, but that target has bitrotted severely >>>>> over the last few months and nobody seems to be interested in >>>>> fixing it. You may need to do some work there. Alternatively >>>>> you could implement the PPC ABI that you need. There are several >>>>> examples of supporting multiple ABIs on the same hardware, x86 >>>>> being the most obvious. A lot of simple stuff will probably Just >>>>> Work with the existing PPC ABI, more complicated stuff may not. >>>>> (Only 32-bit PPC is really maintained, though, there are probably >>>>> lots of problems with 64-bit.) >>>>> >>>>> Objective C in llvm, AFAIK, is only used on the MacOSX targets >>>>> and only tested there. There are sufficient secret handshakes >>>>> between the compiler and the ObjC runtime that it is unlikely to >>>>> Just Work in an untested environment. OpenStep has a familial >>>>> relationship to MacOSX ObjC runtime, but they aren't the same and >>>>> are unlikely to still be binary compatible at this point. You >>>>> may need to do some work there also. >>>>> >>>>> Summary, you can probably get this approach to work, but it's not >>>>> as easy as you're hoping. >>>>> >>>>> On May 26, 2010, at 5:20 PMPDT, kdubb wrote: >>>>> >>>>>> We are looking at using Objective-C/C++ in a new game engine. >>>>>> Objective C's duality of being both very dynamic and very "C" >>>>>> gives us exactly what we need to make the SDK and engineering of >>>>>> games simpler. >>>>>> >>>>>> This means that we will need a way to compile it on all >>>>>> platforms our games will target. Currently the major platforms >>>>>> we are concerned with include... PC, Mac, XBox 360, PS3, >>>>>> iPhone. Now the PC, Mac, iPhone and PS3 are fairly simple. If >>>>>> we build our own OpenStep libraries we can simply use LLVM to >>>>>> compile directly to these platforms; the PS3 although >>>>>> proprietary uses GCC as a C/C++ compiler so I am assuming >>>>>> Objective-C can be used fairly simply. This leaves us with the >>>>>> XBox 360. >>>>>> >>>>>> The 360 is a special chip (PowerPC based) with, as far as I have >>>>>> researched, a special ABI (Windows derivative). I haven't the >>>>>> faintest clue of whether code from the LLVM PPC backend would >>>>>> even work on the 360, much less interoperate with the system >>>>>> libraries. So my formulated solution has become this: use an >>>>>> LLVM backend to output C code and then compile that code with >>>>>> using MS's XBox 360 compiler. I believe I have read that LLVM >>>>>> has a C backend already but I don't know how to select it. >>>>>> >>>>>> If I can get a proof of concept showing Objective-C code running >>>>>> on the 360 we are off to the races. Any help is appreciated >>>>>> just not sure if all the pieces/parts exist and/or what I am >>>>>> missing. So... is this feasible? If so... how do I get LLVM to >>>>>> output C code? >>>>>> >>>>>> Thanks, >>>>>> Kevin >>>>>> _______________________________________________ >>>>>> LLVM Developers mailing list >>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From pocmatos at gmail.com Thu May 27 13:14:09 2010 From: pocmatos at gmail.com (Paulo J. Matos) Date: Thu, 27 May 2010 19:14:09 +0100 Subject: [LLVMdev] TargetDescription string documentation In-Reply-To: <4BFEB55D.3080003@uiuc.edu> References: <4BFEB55D.3080003@uiuc.edu> Message-ID: On Thu, May 27, 2010 at 7:09 PM, John Criswell wrote: > > I believe what you want is documented here: > > http://llvm.org/docs/LangRef.html#datalayout > Yes it is. Thanks. I guess I should have read the document instead of skimming it. :) -- PMatos From pocmatos at gmail.com Thu May 27 13:18:19 2010 From: pocmatos at gmail.com (Paulo J. Matos) Date: Thu, 27 May 2010 19:18:19 +0100 Subject: [LLVMdev] TargetDescription string documentation In-Reply-To: <4BFEB55D.3080003@uiuc.edu> References: <4BFEB55D.3080003@uiuc.edu> Message-ID: On Thu, May 27, 2010 at 7:09 PM, John Criswell wrote: > I believe what you want is documented here: > > http://llvm.org/docs/LangRef.html#datalayout > Just a note, since it might be a bug on the backend or documentation. It says on the documentation that size for f is either 32 or 64, however, sparc has 64 and 128. -- PMatos From kdubb at me.com Thu May 27 13:21:39 2010 From: kdubb at me.com (Kevin Wooten) Date: Thu, 27 May 2010 11:21:39 -0700 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <2A82519A-1098-4112-A3A0-6534B88A2AB9@mganin.com> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> <3B2595AF-E7B5-462D-BAE8-425CFF829C84@leftfield.org> <2A82519A-1098-4112-A3A0-6534B88A2AB9@mganin.com> Message-ID: <428E9CCF-FE9D-4844-9289-5075BE74EE59@me.com> At this point I am thinking, for the PS3 and 360, that the ObjC to C route is preferred also. Yes, as I alluded to, we are an XBox and PlayStation developer so I have both a 360 and a PS3 dev kit. On May 27, 2010, at 11:09 AM, Sherief Farouk wrote: > Just to be clear, nothing in the MS TCRs require that you use a certain compiler - it does, however, require that you link with the 360-specific C runtime libraries. That being said, I still believe that direct binary generation is not a feasible option, and the ObjC => C route is preferred. > > Kevin, hate to be asking this but do you have access to the XDK or are you just "aiming" for it? > > - Sherief > > > On May 27, 2010, at 11:09 AM, Alex Rosenberg wrote: > >> PS3 is not "a Linux derivative." The compilers supplied by SCE for PS3 >> game development are highly customized and support a customized ABI >> that will take some time to adjust LLVM and Clang to support. >> >> You'd likely also run afoul of a TRC or two, similar to the problems >> you'll face with Microsoft TCRs mentioned earlier. >> >> Alex From sherief at mganin.com Thu May 27 13:15:11 2010 From: sherief at mganin.com (Sherief Farouk) Date: Thu, 27 May 2010 14:15:11 -0400 Subject: [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360 In-Reply-To: <2F03D29A-0355-4965-AF58-8F5759A1350E@me.com> References: <4cb75744-e9d9-4326-9baa-fea722331db7@me.com> <7845310F-3F44-4FD8-A1E6-97B829E33433@apple.com> <43F30F05-8440-483D-9E66-EBFDA58001AB@me.com> <3B2595AF-E7B5-462D-BAE8-425CFF829C84@leftfield.org> <2F03D29A-0355-4965-AF58-8F5759A1350E@me.com> Message-ID: <45F02F7F-A13E-48B5-B3EE-01B599E234DC@mganin.com> Kevin, there're some unwritten rules on the 360 that seem to interfere with code generation - pointer load-stores seem to require zeroing the most significant 32 bits, for example - that was one issue that I ran into a while ago while fooling around with code generation on the 360 (and don't blame me if I'm slightly off the mark, it was quite a while ago). I didn't seem to find it mentioned in the XDK docs anywhere. Again, you'll be better off generating C code and using the XDK compiler to compile that. - Sherief On May 27, 2010, at 12:26 PM, Kevin Wooten wrote: > By linux derivative I meant that it borrows the linux GCC ABI... and it does. You can compile with an off the shelf GCC cross compiler and link the resultant object files ones compiled with the PS3 provided version. We have done it. > > Also, as both an XBox 360 and PS3 developer, there seems to me to be nothing in the TCRs/TRCs that preclude us from using a different compiler. There are rules about symbol inclusion and other resultant binary requirements... but as of yet I have not found specific ones stopping us from using a compiler that works. In either case the LLVM rewriter solves any other these issues as we would be just be compiling C. > > On May 27, 2010, at 8:09 AM, Alex Rosenberg wrote: > >> PS3 is not "a Linux derivative." The compilers supplied by SCE for PS3 game development are highly customized and support a customized ABI that will take some time to adjust LLVM and Clang to support. >> >> You'd likely also run afoul of a TRC or two, similar to the problems you'll face with Microsoft TCRs mentioned earlier. >> >> Alex >> >> On May 27, 2010, at 12:15 AM, Kevin Wooten wrote: >> >>> Implementing the backend (or editing the current PPC backend as needed) is a definite option. This seems to be the real question... which is easier... maintaining the PPC backend or maintaining the rewriter. Currently (in admittedly trivial tests) I have gotten the rewriter to work and output C code. There are some outstanding issues to do with linking and accessing the reflection information objective-c provides (and the rewriter properly outputs) but I am sure the person/people who wrote the rewriter can answer those fairly simply (or else the rewriter would be fairly useless). >>> >>> As far as the runtime goes there is an implementation for windows, linux and most likely the PS3 (since it is already a linux derivative using GCC as me