From viridia at gmail.com Tue Feb 1 00:57:26 2011 From: viridia at gmail.com (Talin) Date: Mon, 31 Jan 2011 22:57:26 -0800 Subject: [LLVMdev] Convenience methods in ConstantExpr et al Message-ID: I notice that there's a lot of inconsistency in the various LLVM classes with respect to convenience methods. Here's some examples: For creating GEPS, IRBuilder has: CreateGEP (2 overloads) CreateInBoundsGEP (2 overloads) CreateConstGEP1_32 CreateConstInBoundsGEP1_32 CreateConstGEP2_32 CreateConstInBoundsGEP2_32 CreateConstGEP1_64 CreateConstInBoundsGEP1_64 CreateConstGEP2_64 CreateConstInBoundsGEP2_64 CreateStructGEP All of which are very useful. However, ConstExpression only has: getGetElementPtr getGetElementPtr getInBoundsGetElementPtr getInBoundsGetElementPtr It would be nice if ConstantExpr's GEP-building methods used the same naming convention and had the same convenience methods as IRBuilder. (In fact, the naming convention between IRBuilder and the various Constants.h classes desperately needs to be reconciled, a point which I am sure everyone is painfully aware of.) Another thing I'd like to see is for ConstantArray::get(), ConstantStruct::get() and ConstantVector::get() to have an overload that takes an iterator pair like IRBuilder's CreateGEP and CreateCall methods. Also useful for creating small structs would be overloads for ConstantStruct::get that took 1-4 arguments, instead of having to create a vector every time. Even better would be an "end with null" version, like StructType::get() does. These should be added to FunctionType::get() as well. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110131/d407d9ca/attachment-0001.html From trigan.sda at gmail.com Tue Feb 1 02:04:40 2011 From: trigan.sda at gmail.com (Solovyov Dmitry) Date: Tue, 1 Feb 2011 14:04:40 +0600 Subject: [LLVMdev] checking tool compatibility... configure: error: g++|icc required but not found Message-ID: Hi all. I see this error message (subj) while trying to configure LLVM Build Environment. I follow the instruction given in http://llvm.org/docs/GettingStarted.html What am I doing wrong? Help me, please :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110201/e9a48b8d/attachment.html From ofv at wanadoo.es Tue Feb 1 02:26:14 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Tue, 01 Feb 2011 09:26:14 +0100 Subject: [LLVMdev] checking tool compatibility... configure: error: g++|icc required but not found References: Message-ID: <87sjw8f9eh.fsf@wanadoo.es> Solovyov Dmitry writes: > Hi all. I see this error message (subj) while trying to configure LLVM Build > Environment. > I follow the instruction given in http://llvm.org/docs/GettingStarted.html > What am I doing wrong? You don't have g++ installed or in your PATH. You need a C++ compiler for building LLVM. g++ is the GNU compiler, icc is the Intel compiler. If you type which g++ at the console, what's the output? If you are on Debian Linux or in one of its derivatives (Ubuntu, etc) this should install g++: sudo apt-get install g++ From trigan.sda at gmail.com Tue Feb 1 02:36:56 2011 From: trigan.sda at gmail.com (Solovyov Dmitry) Date: Tue, 1 Feb 2011 14:36:56 +0600 Subject: [LLVMdev] checking tool compatibility... configure: error: g++|icc required but not found In-Reply-To: <87sjw8f9eh.fsf@wanadoo.es> References: <87sjw8f9eh.fsf@wanadoo.es> Message-ID: Thanks, man! I thought it's included to llvm-gcc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110201/391cf9ed/attachment.html From geek4civic at gmail.com Tue Feb 1 04:35:38 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Tue, 1 Feb 2011 19:35:38 +0900 Subject: [LLVMdev] Linking on Windows with LLVM tools In-Reply-To: References: Message-ID: Ruben, 2011/1/30 Ruben Van Boxem : > Can the tools in LLVM create a Win32 exe or dll file? Or does LLVM > still rely on Binutils and GCC for that? Is it > possible/feasable/wanted that the LLVM toolchain could do this? As you know, we need our linker! Please look into the slide in http://llvm.org/devmtg/2010-11/ "Object Files in LLVM" by Michael Spencer aka bigcheese. ...Takumi From vanboxem.ruben at gmail.com Tue Feb 1 05:23:08 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Tue, 1 Feb 2011 12:23:08 +0100 Subject: [LLVMdev] Linking on Windows with LLVM tools In-Reply-To: References: Message-ID: 2011/2/1 NAKAMURA Takumi > Ruben, > > 2011/1/30 Ruben Van Boxem : > > Can the tools in LLVM create a Win32 exe or dll file? Or does LLVM > > still rely on Binutils and GCC for that? Is it > > possible/feasable/wanted that the LLVM toolchain could do this? > > As you know, we need our linker! > > Please look into the slide in http://llvm.org/devmtg/2010-11/ > "Object Files in LLVM" by Michael Spencer aka bigcheese. > > ...Takumi > Takumi, Thanks for the link! (pun intended) What I understand from this presentation, is that bigcheese is working on exactly what I was asking about, ie a replacement for binutils within the LLVM infrastructure. I also take it that he has only made a proof-of-concept implementation of an LLVM "nm" tool, to show that the whole project has merit, which, seemingly, it does very much. The reason I asked is the fact that an LLVM build also has llvm-ld/nm/link/as/... as part of the toolset. I wondered exactly what they were. But I guess they are (or have the ambition to be) much more. bigcheese talks more than once about an "integrated linker"... If I have understood correctly, this is great news! Ruben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110201/a3c56359/attachment.html From eliben at gmail.com Tue Feb 1 05:58:57 2011 From: eliben at gmail.com (Eli Bendersky) Date: Tue, 1 Feb 2011 13:58:57 +0200 Subject: [LLVMdev] reference to %llvm.dbg.variable in source level debug docs In-Reply-To: References: Message-ID: Hello I'm reading http://llvm.org/docs/SourceLevelDebugging.html and some things aren't clear. There are a couple of references made to %llvm.dbg.variable, which isn't defined anywhere. It it an intrinsic? A global? Could it be a relic from the old debug info docs (where it *is* defined?). The same goes for llvm.dbg.derivedtype and llvm.dbg.subrange which are also referenced but not defined. Additionally, there's this definition: """ ?void %llvm.dbg.declare(metadata, metadata) This intrinsic provides information about a local element (ex. variable.) The first argument is metadata holding alloca for the variable.. The second argument is the %llvm.dbg.variable containing the description of the variable. """ I see all uses of llvm.dbg.declare having values/types as first argument, not metadata. What am I missing? Thanks in advance, Eli From gvenn.cfe.dev at gmail.com Tue Feb 1 07:53:28 2011 From: gvenn.cfe.dev at gmail.com (Garrison Venn) Date: Tue, 1 Feb 2011 08:53:28 -0500 Subject: [LLVMdev] Official git mirroring of llvm, clang, lldb, test-suite, etc.? In-Reply-To: References: <16726914-1F05-4648-A6E5-F12727B5434A@shadowlab.org> <87wrlmxlma.fsf@smith.obbligato.org> <87fwsaw3ef.fsf@wanadoo.es> <87vd15gd3p.fsf@wanadoo.es> <87ei7shftb.fsf@wanadoo.es> <871v3sh1ss.fsf@wanadoo.es> Message-ID: <97B4CFEB-9DBF-4CDB-B4A0-E384FAB2B268@gmail.com> lol On Feb 1, 2011, at 0:00, Chris Lattner wrote: > > On Jan 31, 2011, at 7:27 PM, ?scar Fuentes wrote: > >>> >>> If one is not supposed to use svn (the official blessed >>> LLVM SCM) on "our side," pray tell, what _are_ we supposed to use? >> >> Because LLVM chose to use svn at some point on the past (when >> distributed tools were not so mature and undestood as they are now) and >> because there is no enough perception of the advantages associated with >> a change, it is no excuse for you not doing what is most convenient for >> your work. > > We could switch back to CVS... > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dpatel at apple.com Tue Feb 1 11:20:45 2011 From: dpatel at apple.com (Devang Patel) Date: Tue, 1 Feb 2011 09:20:45 -0800 Subject: [LLVMdev] Rolling my own appending linkage In-Reply-To: References: <4D3E8255.6000301@free.fr> Message-ID: <2CEEE349-3071-4F25-86C4-A87B938B9220@apple.com> On Jan 30, 2011, at 8:36 PM, Talin wrote: > So, I spent the better part of a day making sure that each and every static global had a well-formed and unique name. So far so good. > > However, It turns out that what I need is a little different than what I described - I not only need to know which globals should be traced, but I also need to associate with each of these globals a data structure that tells the garbage collector how to trace it. > > Let me describe the setup: For each compiled module, the compiler generates a list of all statically allocated data structures in the module. Each list entry is a 2-tuple containing a pointer to the static global and a pointer to the trace table for that global. Globals that have the same type will share the same trace table. > > OK so what I need to have happen at link time is the following: > > -- Run the dead global elimination pass to determine which globals will be included in the final output. > -- For the globals that remain, find the trace table pointer that was originally associated with that global. > -- Collect the globals and their associated table pointers into a list of tuples, which is given to the garbage collector as a parameter on startup. You could use metadata to hold this list of tuples. If you create this list before running dead global elimination pass then the optimizer won't see this metadata and any globals that are deleted will be turned into null in your tuple. > There are a couple of steps in the above that aren't quite clear to me. The main problem is that I don't want the trace tables themselves to be eliminated by the dead global elimination pass - or conversely, if they are eliminated, I need a way to add them back into the module again. This also includes any function pointers embedded in the trace table structures, which might have been considered dead when the trace table was dead. > > In other words, what I'd like to be able to do is run the dead global elimination pass without considering the trace tables at all, and then once I know which globals are live, go ahead and re-associate the trace table with each global, and then re-run the dead global pass to remove any trace tables that weren't referred to. > > Any suggestions would be welcome. I'm otherwise very close to getting a simple, non-shadow-stack collector working :) > - Devang From dpatel at apple.com Tue Feb 1 11:27:41 2011 From: dpatel at apple.com (Devang Patel) Date: Tue, 1 Feb 2011 09:27:41 -0800 Subject: [LLVMdev] reference to %llvm.dbg.variable in source level debug docs In-Reply-To: References: Message-ID: <50622D55-EA10-4312-8E16-C469E7DBF9A7@apple.com> On Feb 1, 2011, at 3:58 AM, Eli Bendersky wrote: > Hello > I'm reading http://llvm.org/docs/SourceLevelDebugging.html and some > things aren't clear. > > There are a couple of references made to %llvm.dbg.variable, which > isn't defined anywhere. It it an intrinsic? A global? Could it be a > relic from the old debug info docs (where it *is* defined?). The same > goes for llvm.dbg.derivedtype and llvm.dbg.subrange which are also > referenced but not defined. It was a stale reference. I fixed the docs. > > Additionally, there's this definition: > > """ > void %llvm.dbg.declare(metadata, metadata) > > This intrinsic provides information about a local element (ex. > variable.) The first argument is metadata holding alloca for the > variable.. The second argument is the %llvm.dbg.variable containing > the description of the variable. > """ > > I see all uses of llvm.dbg.declare having values/types as first > argument, not metadata. What am I missing? I am seeing call void @llvm.dbg.declare(metadata !{i32* %argc.addr}, metadata !12), !dbg !13 ? - Devang From greened at obbligato.org Tue Feb 1 11:40:48 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 01 Feb 2011 11:40:48 -0600 Subject: [LLVMdev] Official git mirroring of llvm, clang, lldb, test-suite, etc.? In-Reply-To: <871v3sh1ss.fsf@wanadoo.es> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Tue, 01 Feb 2011 04:27:31 +0100") References: <16726914-1F05-4648-A6E5-F12727B5434A@shadowlab.org> <87wrlmxlma.fsf@smith.obbligato.org> <87fwsaw3ef.fsf@wanadoo.es> <87vd15gd3p.fsf@wanadoo.es> <87ei7shftb.fsf@wanadoo.es> <871v3sh1ss.fsf@wanadoo.es> Message-ID: ?scar Fuentes writes: >> I asked about both to the git guys. They said it isn't supported. >> Double-ended git-svn just won't work, period. You can't do it because a >> git branch is still tied to the revision numbering of the first git-svn >> gateway created. Git branches still must relate to each other, they >> can't run independently or one wouldn't get any merging benefit. > > My point is that you can use two git repositories, each one tracking one > svn repo, and move revisions from one to another. I never tried it so No, we can't. Git doesn't work that way. Git uses a set of repositories all cloned fronth each other. One can't simply merge from one arbitrary git repository to another. >>> The difficult part is not on LLVM's using svn, the problem is on you >>> using svn. >> >> Umm...that's more than a bit off-putting, thanks. > > Sorry, thas was not my intention. There was an smiley somewhere around > there. No problem. e-mail is tough to get right. :) >> If it's a problem to >> use svn (and it IS a problem), then it's a problem on BOTH ends. > > I'll say that your svn is creating more trouble than LLVM's svn when you > are ready to send your changes upstream. After all, you are the > developers (working on "feature branches"), while LLVM's svn can be > considered the "master branch". This applies too in case you have a > private branch. As you say, git makes merging an easy task and keeping a > private branch is about merging all the time. I certainly don't want to be using svn. Believe me, if I could dump svn this afternoon, I absolutely would. The problem with svn is there is no "master branch" in the sense of git. One can't easily keep a private repository of LLVM because svn is by nature centralized. > Because LLVM chose to use svn at some point on the past (when > distributed tools were not so mature and undestood as they are now) and > because there is no enough perception of the advantages associated with > a change, it is no excuse for you not doing what is most convenient for > your work. Again, the problem is that there is no convenient solution. Everything involves manual diff+patch at some point. This is entirely because svn is not a distributed SCM. The reasons for using svn in the past were entirely correct. But the technology has advanced far beyond what it was back then. I am not demanding any sort of change, just pointing out what the cost of the current system is. An official git mirror would solve about half of the current problems and that's probably good enough for most people. -Dave From greened at obbligato.org Tue Feb 1 11:42:07 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 01 Feb 2011 11:42:07 -0600 Subject: [LLVMdev] Official git mirroring of llvm, clang, lldb, test-suite, etc.? In-Reply-To: <97B4CFEB-9DBF-4CDB-B4A0-E384FAB2B268@gmail.com> (Garrison Venn's message of "Tue, 1 Feb 2011 08:53:28 -0500") References: <16726914-1F05-4648-A6E5-F12727B5434A@shadowlab.org> <87wrlmxlma.fsf@smith.obbligato.org> <87fwsaw3ef.fsf@wanadoo.es> <87vd15gd3p.fsf@wanadoo.es> <87ei7shftb.fsf@wanadoo.es> <871v3sh1ss.fsf@wanadoo.es> <97B4CFEB-9DBF-4CDB-B4A0-E384FAB2B268@gmail.com> Message-ID: Garrison Venn writes: > lol LOL, yes, but svn is not much better than cvs. It makes doing release branches slightly easier, but that's about it. svn in no way tackles the real development prodcess. -Dave > On Feb 1, 2011, at 0:00, Chris Lattner wrote: > >> >> On Jan 31, 2011, at 7:27 PM, ?scar Fuentes wrote: >> >>>> >>>> If one is not supposed to use svn (the official blessed >>>> LLVM SCM) on "our side," pray tell, what _are_ we supposed to use? >>> >>> Because LLVM chose to use svn at some point on the past (when >>> distributed tools were not so mature and undestood as they are now) and >>> because there is no enough perception of the advantages associated with >>> a change, it is no excuse for you not doing what is most convenient for >>> your work. >> >> We could switch back to CVS... >> >> -Chris >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From rjmccall at apple.com Tue Feb 1 12:42:59 2011 From: rjmccall at apple.com (John McCall) Date: Tue, 1 Feb 2011 10:42:59 -0800 Subject: [LLVMdev] Official git mirroring of llvm, clang, lldb, test-suite, etc.? In-Reply-To: <97B4CFEB-9DBF-4CDB-B4A0-E384FAB2B268@gmail.com> References: <16726914-1F05-4648-A6E5-F12727B5434A@shadowlab.org> <87wrlmxlma.fsf@smith.obbligato.org> <87fwsaw3ef.fsf@wanadoo.es> <87vd15gd3p.fsf@wanadoo.es> <87ei7shftb.fsf@wanadoo.es> <871v3sh1ss.fsf@wanadoo.es> <97B4CFEB-9DBF-4CDB-B4A0-E384FAB2B268@gmail.com> Message-ID: On Feb 1, 2011, at 5:53 AM, Garrison Venn wrote: > lol Please don't make posts like this to the list. John. From edwintorok at gmail.com Tue Feb 1 13:00:14 2011 From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=) Date: Tue, 01 Feb 2011 21:00:14 +0200 Subject: [LLVMdev] Official git mirroring of llvm, clang, lldb, test-suite, etc.? In-Reply-To: References: <16726914-1F05-4648-A6E5-F12727B5434A@shadowlab.org> <87wrlmxlma.fsf@smith.obbligato.org> <87fwsaw3ef.fsf@wanadoo.es> <87vd15gd3p.fsf@wanadoo.es> <87ei7shftb.fsf@wanadoo.es> <871v3sh1ss.fsf@wanadoo.es> Message-ID: <4D48583E.6060104@gmail.com> On 2011-02-01 19:40, David A. Greene wrote: > Again, the problem is that there is no convenient solution. Everything > involves manual diff+patch at some point. This is entirely because svn > is not a distributed SCM. FWIW I used "svk" for a little while, to be able to make local commits on a SVN repository. It was certainly better than manually patching stuff. I think I used it only for a few months though, before switching to 'git' though. Best regards, --Edwin From anton at korobeynikov.info Tue Feb 1 14:20:49 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 1 Feb 2011 23:20:49 +0300 Subject: [LLVMdev] GIT mirroring Message-ID: Hello Everyone, It seems given the decent amount of discussions it's time to make small announcement. So, official git mirrors are available for some subset of LLVM projects. They were used by some LLVM developers for couple of months already and seem to be stable enough. Right now there is a mirroring for LLVM itself and clang. More can be added per requests. The mirrors are made via running of git-svn on llvm.org inside post-commit hook, so they should be in theory as fresh as possible. Also, one can recreate git-svn metadata and enable such nice features like "git svn dcommit". The mirrors track only trunk mostly due to not so git'ish way of doing branches / tags in LLVM repository. The URLs for clone are: http://llvm.org/git/llvm.git http://llvm.org/git/clang.git It's not yet decided whether we'll run e.g. gitweb for mirrors, most probably - there won't be anything like this, viewvc should be enough for almost all purposes. PS: Patches to various sorts of documentation scattered here and there are welcome :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From atrick at apple.com Tue Feb 1 15:08:13 2011 From: atrick at apple.com (Andrew Trick) Date: Tue, 1 Feb 2011 13:08:13 -0800 Subject: [LLVMdev] Non-standard byte sizes In-Reply-To: <4D433BBD.6030003@cowlark.com> References: <4D42A88F.7000308@cowlark.com> <4D433BBD.6030003@cowlark.com> Message-ID: <7DF3D906-C8AD-4CCB-A59A-9FC2EA4BB50F@apple.com> On Jan 28, 2011, at 1:57 PM, David Given wrote: > And I can't find any documentation for clang's -cc1 mode... I hope you've found it by now. If not: clang -cc1 -help From andrew at sidefx.com Tue Feb 1 15:08:20 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Tue, 01 Feb 2011 16:08:20 -0500 Subject: [LLVMdev] Loop simplification Message-ID: <4D487644.3070409@sidefx.com> I have a (non-entry) basic block that contains only PHI nodes and an unconditional branch (that does not branch to itself). Is it always possible to merge this block with it's successor and produce a semantically equivalent program? I'm trying to undo some of the loop optimizations that LLVM has applied to my program to reduce a pair of nested loops to a single loop. llvm::MergeBlockIntoPredecessor does not do what I want since it requires that the the block have a unique predecessor. Andrew From atrick at apple.com Tue Feb 1 15:34:48 2011 From: atrick at apple.com (Andrew Trick) Date: Tue, 1 Feb 2011 13:34:48 -0800 Subject: [LLVMdev] Loop simplification In-Reply-To: <4D487644.3070409@sidefx.com> References: <4D487644.3070409@sidefx.com> Message-ID: <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > I have a (non-entry) basic block that contains only PHI nodes and an > unconditional branch (that does not branch to itself). Is it always > possible to merge this block with it's successor and produce a > semantically equivalent program? I'm trying to undo some of the loop > optimizations that LLVM has applied to my program to reduce a pair of > nested loops to a single loop. > > llvm::MergeBlockIntoPredecessor does not do what I want since it > requires that the the block have a unique predecessor. I didn't notice anything that will do what you want out-of-box, but it should not be hard to write. llvm::FoldSingleEntryPHINodes is an example of phi node replacement. But in this case, you'll need to do one in-place operand replacement for each successor phi use and call PhiNode::addIncoming for the rest. Note that multiple successor phis may use the same predecessor phi, so you should be careful of mutating the phis while iterating their uses. If you cover the trivial case first with llvm::MergeBlockIntoPredecessor, then the predecessor phis should have no uses other than successor phis. That would violate strict SSA (the CFG edge you described is a dominance frontier). -Andy From greened at obbligato.org Tue Feb 1 15:39:03 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 01 Feb 2011 15:39:03 -0600 Subject: [LLVMdev] Official git mirroring of llvm, clang, lldb, test-suite, etc.? In-Reply-To: <4D48583E.6060104@gmail.com> (=?utf-8?B?IlTDtnLDtms=?= Edwin"'s message of "Tue, 01 Feb 2011 21:00:14 +0200") References: <16726914-1F05-4648-A6E5-F12727B5434A@shadowlab.org> <87wrlmxlma.fsf@smith.obbligato.org> <87fwsaw3ef.fsf@wanadoo.es> <87vd15gd3p.fsf@wanadoo.es> <87ei7shftb.fsf@wanadoo.es> <871v3sh1ss.fsf@wanadoo.es> <4D48583E.6060104@gmail.com> Message-ID: T?r?k Edwin writes: > On 2011-02-01 19:40, David A. Greene wrote: >> Again, the problem is that there is no convenient solution. Everything >> involves manual diff+patch at some point. This is entirely because svn >> is not a distributed SCM. > > FWIW I used "svk" for a little while, to be able to make local commits > on a SVN repository. It was certainly better than manually patching stuff. > I think I used it only for a few months though, before switching to > 'git' though. SVK is a band-aid at best. Again, it can't be used to connect two distinct repositories, AFAIK. An official LLVM git mirror that's updated every time there is a commit to svn would help a lot. -Dave From greened at obbligato.org Tue Feb 1 15:41:43 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 01 Feb 2011 15:41:43 -0600 Subject: [LLVMdev] [cfe-dev] GIT mirroring In-Reply-To: (Anton Korobeynikov's message of "Tue, 1 Feb 2011 23:20:49 +0300") References: Message-ID: Anton Korobeynikov writes: > So, official git mirrors are available for some subset of LLVM > projects. They were used by some LLVM developers for couple of months > already and seem to be stable enough. Woo hoo! > as possible. Also, one can recreate git-svn metadata and enable such > nice features like "git svn dcommit". The mirrors track only trunk Yee haw! Is there some documentation on how to set this up for LLVM? Thanks Anton and everyone who worked on this! -Dave From ezengbin at gmail.com Tue Feb 1 15:43:15 2011 From: ezengbin at gmail.com (Bin Zeng) Date: Tue, 01 Feb 2011 16:43:15 -0500 Subject: [LLVMdev] X86 Instructions on LLVM Message-ID: <4D487E73.5020707@gmail.com> Hi all, Just a quick question about X86 instructions inside LLVM. I found it hard to do one-to-one mapping from the instructions in X86GenInstInfo.inc to the instructions in the intel Manual. For example, what instructions are DIVR_F32m and DIVR_F64m mapped to in the intel manual? It would be great if there is some docs about the X86 instructions. Thanks tons! Bin From atrick at apple.com Tue Feb 1 15:47:54 2011 From: atrick at apple.com (Andrew Trick) Date: Tue, 1 Feb 2011 13:47:54 -0800 Subject: [LLVMdev] Loop simplification In-Reply-To: <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> References: <4D487644.3070409@sidefx.com> <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> Message-ID: <14BD199F-9C1A-4513-8138-F4129692BC31@apple.com> On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm trying to undo some of the loop >> optimizations that LLVM has applied to my program to reduce a pair of >> nested loops to a single loop. >> >> llvm::MergeBlockIntoPredecessor does not do what I want since it >> requires that the the block have a unique predecessor. > > I didn't notice anything that will do what you want out-of-box, but it should not be hard to write. llvm::FoldSingleEntryPHINodes is an example of phi node replacement. But in this case, you'll need to do one in-place operand replacement for each successor phi use and call PhiNode::addIncoming for the rest. Note that multiple successor phis may use the same predecessor phi, so you should be careful of mutating the phis while iterating their uses. If you cover the trivial case first with llvm::MergeBlockIntoPredecessor, then the predecessor phis should have no uses other than successor phis. That would violate strict SSA (the CFG edge you described is a dominance frontier). I forgot to ask why you're doing this. If the goal is to remove a branch, that would typically be handled by BranchFolder during codegen after phis have been removed. I don't see a problem forcing the CFG to be more canonical earlier, but if the successor is in a deeper loop, then you could be eliminating a preheader and forcing compensation code into the loop. In fact, I wouldn't be surprised if some loop passes might want a single preheader. -Andy From stoklund at 2pi.dk Tue Feb 1 15:54:31 2011 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Tue, 1 Feb 2011 13:54:31 -0800 Subject: [LLVMdev] GIT mirroring In-Reply-To: References: Message-ID: On Feb 1, 2011, at 12:20 PM, Anton Korobeynikov wrote: > Hello Everyone, > > It seems given the decent amount of discussions it's time to make > small announcement. > > So, official git mirrors are available for some subset of LLVM > projects. They were used by some LLVM developers for couple of months > already and seem to be stable enough. Thank you for setting this up, Anton! This is how I use the Git mirror with git-svn: For the initial clone and setup: $ git clone http://llvm.org/git/llvm.git $ cd llvm $ git config --add remote.origin.fetch '+refs/remotes/git-svn:refs/remotes/git-svn' $ git fetch $ git svn init https://llvm.org/svn/llvm-project/llvm/trunk $ git svn rebase -l This will quickly build the git-svn metadata by using the magical remotes/git-svn branch fetched from the origin. To update I run: $ git fetch $ git svn rebase -l And to commit: $ git svn dcommit $ git fetch $ git svn rebase -l I have sometimes seen git-svn refusing to dcommit, claiming that I have uncommitted files in my tree. I think this happens when I forget to resynchronize the metadata after committing. Anyway, the solution is to wipe away all of .git/svn and rebuild it with "git svn rebase -l" /jakob From atrick at apple.com Tue Feb 1 15:57:08 2011 From: atrick at apple.com (Andrew Trick) Date: Tue, 1 Feb 2011 13:57:08 -0800 Subject: [LLVMdev] Loop simplification In-Reply-To: <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> References: <4D487644.3070409@sidefx.com> <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> Message-ID: On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm trying to undo some of the loop >> optimizations that LLVM has applied to my program to reduce a pair of >> nested loops to a single loop. >> >> llvm::MergeBlockIntoPredecessor does not do what I want since it >> requires that the the block have a unique predecessor. > > I didn't notice anything that will do what you want out-of-box, but it should not be hard to write. llvm::FoldSingleEntryPHINodes is an example of phi node replacement. But in this case, you'll need to do one in-place operand replacement for each successor phi use and call PhiNode::addIncoming for the rest. Note that multiple successor phis may use the same predecessor phi, so you should be careful of mutating the phis while iterating their uses. If you cover the trivial case first with llvm::MergeBlockIntoPredecessor, then the predecessor phis should have no uses other than successor phis. That would violate strict SSA (the CFG edge you described is a dominance frontier). Oops. I just realized you are intentionally doing loop combining. If the only other predecessor edges are back edges, then my statement above is untrue. You would have to replace all other uses of the predecessor phis (that are not successor phis) with a potentially new phi that uses itself on the backedge! -Andy From greened at obbligato.org Tue Feb 1 16:10:38 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 01 Feb 2011 16:10:38 -0600 Subject: [LLVMdev] X86 Instructions on LLVM In-Reply-To: <4D487E73.5020707@gmail.com> (Bin Zeng's message of "Tue, 01 Feb 2011 16:43:15 -0500") References: <4D487E73.5020707@gmail.com> Message-ID: Bin Zeng writes: > Hi all, > > Just a quick question about X86 instructions inside LLVM. I found it > hard to do one-to-one mapping from the instructions in > X86GenInstInfo.inc to the instructions in the intel Manual. For example, > what instructions are DIVR_F32m and DIVR_F64m mapped to in the intel > manual? It would be great if there is some docs about the X86 instructions. Both map to FDIVR. The suffixes indicate the addressing mode for that particular pattern: F32 -> single precision F64 -> double precision r -> register m -> memory rr -> register-to-register rm -> memory-to-register (load) mr -> register-to-memory (store) So DIVR_F32m is a single-precision reverse divide where the dividend is from memory and divisor is the top-of-stack. DIVR_F64m is a double-precision reverse divide with the same addressing mode. The important thing to know about the X86 codegen is that every addressing mode variant of an instruction is a separate MachineInstr/SelectionDAG/etc. opcode. LLVM doesn't have the concept of "addressing mode," _per_se_. Each combination of addressing modes is a separate instruction, so there are something like 40 different instructions for ADD, similar to how they're enumerated in the Intel manual, except r/m16, etc. are two separate LLVM MachineInstr opcodes, one with a register operand and one with a memory operand. -Dave From andrew at sidefx.com Tue Feb 1 16:22:55 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Tue, 01 Feb 2011 17:22:55 -0500 Subject: [LLVMdev] Loop simplification In-Reply-To: References: <4D487644.3070409@sidefx.com> <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> Message-ID: <4D4887BF.3070806@sidefx.com> Here's what I've got so far - it seems to work, aside from the fact that DeleteDeadPHIs is not removing at least one dead PHI in my test program. --------------------- static bool mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ) { if (succ == pred) return false; if (pred->getFirstNonPHI() != pred->getTerminator()) return false; // Delete the terminator in the predecessor block pred->getTerminator()->eraseFromParent(); // Update predecessor PHIs for (BasicBlock::iterator it = pred->begin(); it != pred->end(); ++it) { PHINode *phi = dyn_cast(it); UT_ASSERT(phi); // Adjust the PHI to have the correct incoming block set for (pred_iterator pi = pred_begin(succ); pi != pred_end(succ); ++pi) { // We're a different predecessor than the predecessor block if (*pi != pred) { phi->addIncoming(phi, *pi); } } } // Update successor PHIs for (BasicBlock::iterator it = succ->begin(); succ->getFirstNonPHI() != it; ++it) { PHINode *phi = dyn_cast(it); UT_ASSERT(phi); UT_ASSERT(phi->getBasicBlockIndex(pred) >= 0); Value *val = phi->getIncomingValueForBlock(pred); PHINode *predphi = dyn_cast(val); if (predphi && predphi->getParent() != pred) predphi = 0; phi->removeIncomingValue(pred, false); for (pred_iterator pi = pred_begin(pred); pi != pred_end(pred); ++pi) { // We're a new predecessor if (phi->getBasicBlockIndex(*pi) < 0) { if (predphi) { UT_ASSERT(predphi->getBasicBlockIndex(*pi) >= 0); phi->addIncoming( predphi->getIncomingValueForBlock(*pi), *pi); } else phi->addIncoming(val, *pi); } } } // Move the PHIs into the successor succ->getInstList().splice(succ->begin(), pred->getInstList()); // Remove the predecessor block pred->replaceAllUsesWith(succ); // Simplify conditional branches for (Value::use_iterator ui = succ->use_begin(); ui != succ->use_end(); ++ui) { Instruction *inst = dyn_cast(*ui); if (inst) ConstantFoldTerminator(inst->getParent()); } // Clean out dead PHI nodes DeleteDeadPHIs(succ); return true; } On 02/01/2011 04:57 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > >> On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: >> >>> I have a (non-entry) basic block that contains only PHI nodes and an >>> unconditional branch (that does not branch to itself). Is it always >>> possible to merge this block with it's successor and produce a >>> semantically equivalent program? I'm trying to undo some of the loop >>> optimizations that LLVM has applied to my program to reduce a pair of >>> nested loops to a single loop. >>> >>> llvm::MergeBlockIntoPredecessor does not do what I want since it >>> requires that the the block have a unique predecessor. >> I didn't notice anything that will do what you want out-of-box, but it should not be hard to write. llvm::FoldSingleEntryPHINodes is an example of phi node replacement. But in this case, you'll need to do one in-place operand replacement for each successor phi use and call PhiNode::addIncoming for the rest. Note that multiple successor phis may use the same predecessor phi, so you should be careful of mutating the phis while iterating their uses. If you cover the trivial case first with llvm::MergeBlockIntoPredecessor, then the predecessor phis should have no uses other than successor phis. That would violate strict SSA (the CFG edge you described is a dominance frontier). > Oops. I just realized you are intentionally doing loop combining. If the only other predecessor edges are back edges, then my statement above is untrue. You would have to replace all other uses of the predecessor phis (that are not successor phis) with a potentially new phi that uses itself on the backedge! > > -Andy From andrew at sidefx.com Tue Feb 1 16:29:32 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Tue, 01 Feb 2011 17:29:32 -0500 Subject: [LLVMdev] Loop simplification In-Reply-To: <14BD199F-9C1A-4513-8138-F4129692BC31@apple.com> References: <4D487644.3070409@sidefx.com> <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> <14BD199F-9C1A-4513-8138-F4129692BC31@apple.com> Message-ID: <4D48894C.7050102@sidefx.com> On 02/01/2011 04:47 PM, Andrew Trick wrote: > > I forgot to ask why you're doing this. If the goal is to remove a branch, that would typically be handled by BranchFolder during codegen after phis have been removed. I don't see a problem forcing the CFG to be more canonical earlier, but if the successor is in a deeper loop, then you could be eliminating a preheader and forcing compensation code into the loop. In fact, I wouldn't be surprised if some loop passes might want a single preheader. > > -Andy The goal is to make the LoopInfo pass return a single loop where I expect a single loop (based on an input program that has a loop containing an if statement - which seems to generate an outer loop and an inner loop). The particular block that seems to cause this is a "loop.outer" that presumably gets added by one of the common optimization passes. Andrew From andrew at sidefx.com Tue Feb 1 16:51:35 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Tue, 01 Feb 2011 17:51:35 -0500 Subject: [LLVMdev] Loop simplification In-Reply-To: <4D4887BF.3070806@sidefx.com> References: <4D487644.3070409@sidefx.com> <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> <4D4887BF.3070806@sidefx.com> Message-ID: <4D488E77.2030708@sidefx.com> On 02/01/2011 05:22 PM, Andrew Clinton wrote: > Here's what I've got so far - it seems to work, aside from the fact that > DeleteDeadPHIs is not removing at least one dead PHI in my test program. PHI nodes don't seem to be cleaned up correctly since in llvm::RecursivelyDeleteDeadPHINode the algorithm can only handle single-use PHIs while my dead PHI has 2 uses (both self-references). Andrew From atrick at apple.com Tue Feb 1 16:59:37 2011 From: atrick at apple.com (Andrew Trick) Date: Tue, 1 Feb 2011 14:59:37 -0800 Subject: [LLVMdev] Loop simplification In-Reply-To: <4D4887BF.3070806@sidefx.com> References: <4D487644.3070409@sidefx.com> <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> <4D4887BF.3070806@sidefx.com> Message-ID: <4A1DA878-0001-4BDB-9016-B001320D1F05@apple.com> On Feb 1, 2011, at 2:22 PM, Andrew Clinton wrote: > Here's what I've got so far - it seems to work, aside from the fact that DeleteDeadPHIs is not removing at least one dead PHI in my test program. The hasOneUse check may be failing in your case. Do you need to call SimplifyInstruction first? I'm not sure that will help though. Your design looks mostly adequate for the simple nested loop case. I won't be able to spot all the issues upon inspection. I haven't done anything like this in LLVM either. I can add a couple comments: > --------------------- > > static bool > mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ) > { > if (succ == pred) > return false; > > if (pred->getFirstNonPHI() != pred->getTerminator()) > return false; > > // Delete the terminator in the predecessor block > pred->getTerminator()->eraseFromParent(); Is that sufficient to check for a side-effect free uncondition branch? > > // Update predecessor PHIs > for (BasicBlock::iterator it = pred->begin(); > it != pred->end(); ++it) > { > PHINode *phi = dyn_cast(it); > > UT_ASSERT(phi); > > // Adjust the PHI to have the correct incoming block set > for (pred_iterator pi = pred_begin(succ); > pi != pred_end(succ); ++pi) > { > // We're a different predecessor than the predecessor block > if (*pi != pred) > { > phi->addIncoming(phi, *pi); You need to guarantee pi->succ is a backedge of course. Handling other cases will be more involved. > } > } > } > > // Update successor PHIs > for (BasicBlock::iterator it = succ->begin(); > succ->getFirstNonPHI() != it; ++it) > { > PHINode *phi = dyn_cast(it); > > UT_ASSERT(phi); > UT_ASSERT(phi->getBasicBlockIndex(pred) >= 0); > > Value *val = phi->getIncomingValueForBlock(pred); > PHINode *predphi = dyn_cast(val); > > if (predphi && predphi->getParent() != pred) > predphi = 0; > > phi->removeIncomingValue(pred, false); > > for (pred_iterator pi = pred_begin(pred); > pi != pred_end(pred); ++pi) > { > // We're a new predecessor > if (phi->getBasicBlockIndex(*pi) < 0) > { > if (predphi) > { > UT_ASSERT(predphi->getBasicBlockIndex(*pi) >= 0); > phi->addIncoming( > predphi->getIncomingValueForBlock(*pi), *pi); > } > else > phi->addIncoming(val, *pi); > } > } > } > > // Move the PHIs into the successor > succ->getInstList().splice(succ->begin(), pred->getInstList()); > > // Remove the predecessor block > pred->replaceAllUsesWith(succ); > > // Simplify conditional branches > for (Value::use_iterator ui = succ->use_begin(); > ui != succ->use_end(); ++ui) > { > Instruction *inst = dyn_cast(*ui); > if (inst) > ConstantFoldTerminator(inst->getParent()); > } > > // Clean out dead PHI nodes > DeleteDeadPHIs(succ); > > return true; > } Do you need to worry about updating AliasAnalysis/MemoryDepAnalysis, DominatorTree, LoopInfo...? -Andy From atrick at apple.com Tue Feb 1 17:01:13 2011 From: atrick at apple.com (Andrew Trick) Date: Tue, 1 Feb 2011 15:01:13 -0800 Subject: [LLVMdev] Loop simplification In-Reply-To: <4D48894C.7050102@sidefx.com> References: <4D487644.3070409@sidefx.com> <02E7A5B9-6B69-4B11-A734-63DAFE53AFF1@apple.com> <14BD199F-9C1A-4513-8138-F4129692BC31@apple.com> <4D48894C.7050102@sidefx.com> Message-ID: <8424A199-E0E7-4585-87A6-0B983F49052F@apple.com> On Feb 1, 2011, at 2:29 PM, Andrew Clinton wrote: > On 02/01/2011 04:47 PM, Andrew Trick wrote: >> >> I forgot to ask why you're doing this. If the goal is to remove a branch, that would typically be handled by BranchFolder during codegen after phis have been removed. I don't see a problem forcing the CFG to be more canonical earlier, but if the successor is in a deeper loop, then you could be eliminating a preheader and forcing compensation code into the loop. In fact, I wouldn't be surprised if some loop passes might want a single preheader. >> >> -Andy > > The goal is to make the LoopInfo pass return a single loop where I > expect a single loop (based on an input program that has a loop > containing an if statement - which seems to generate an outer loop and > an inner loop). The particular block that seems to cause this is a > "loop.outer" that presumably gets added by one of the common > optimization passes. That's probably because LoopSimplify split the loop to give it a single backedge. It's a feature. Beyond that I'm not the person to ask about it though. -Andy From fvbommel at gmail.com Tue Feb 1 17:43:49 2011 From: fvbommel at gmail.com (Frits van Bommel) Date: Wed, 2 Feb 2011 00:43:49 +0100 Subject: [LLVMdev] Loop simplification In-Reply-To: <4D487644.3070409@sidefx.com> References: <4D487644.3070409@sidefx.com> Message-ID: On Tue, Feb 1, 2011 at 10:08 PM, Andrew Clinton wrote: > I have a (non-entry) basic block that contains only PHI nodes and an > unconditional branch (that does not branch to itself). ?Is it always > possible to merge this block with it's successor and produce a > semantically equivalent program? I don't think that's always possible. For example: if a phi in the successor has a phi in the predecessor as one of it's incoming values, then the predecessor cases have to be merged into the successor phi. However, if they share a predecessor but have different incoming values for it that can't be done. From andrew at sidefx.com Tue Feb 1 17:58:40 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Tue, 01 Feb 2011 18:58:40 -0500 Subject: [LLVMdev] Loop simplification In-Reply-To: References: <4D487644.3070409@sidefx.com> Message-ID: <4D489E30.2000309@sidefx.com> On 02/01/2011 06:43 PM, Frits van Bommel wrote: > I don't think that's always possible. > For example: if a phi in the successor has a phi in the predecessor as > one of it's incoming values, then the predecessor cases have to be > merged into the successor phi. However, if they share a predecessor > but have different incoming values for it that can't be done. You're right. I think it's possible to avoid this (and all other?) failing cases by ensuring that the predecessor dominates the successor before trying to merge them. If the dominance relationship is not true, it may not be possible to merge them. Andrew From viridia at gmail.com Tue Feb 1 18:19:24 2011 From: viridia at gmail.com (Talin) Date: Tue, 1 Feb 2011 16:19:24 -0800 Subject: [LLVMdev] Rolling my own appending linkage In-Reply-To: <2CEEE349-3071-4F25-86C4-A87B938B9220@apple.com> References: <4D3E8255.6000301@free.fr> <2CEEE349-3071-4F25-86C4-A87B938B9220@apple.com> Message-ID: On Tue, Feb 1, 2011 at 9:20 AM, Devang Patel wrote: > > On Jan 30, 2011, at 8:36 PM, Talin wrote: > > > So, I spent the better part of a day making sure that each and every > static global had a well-formed and unique name. So far so good. > > > > However, It turns out that what I need is a little different than what I > described - I not only need to know which globals should be traced, but I > also need to associate with each of these globals a data structure that > tells the garbage collector how to trace it. > > > > Let me describe the setup: For each compiled module, the compiler > generates a list of all statically allocated data structures in the module. > Each list entry is a 2-tuple containing a pointer to the static global and a > pointer to the trace table for that global. Globals that have the same type > will share the same trace table. > > > > OK so what I need to have happen at link time is the following: > > > > -- Run the dead global elimination pass to determine which globals will > be included in the final output. > > -- For the globals that remain, find the trace table pointer that was > originally associated with that global. > > -- Collect the globals and their associated table pointers into a list of > tuples, which is given to the garbage collector as a parameter on startup. > > You could use metadata to hold this list of tuples. If you create this list > before running dead global elimination pass then the optimizer won't see > this metadata and any globals that are deleted will be turned into null in > your tuple. > > Oooh, I like that. I didn't realize that metadata nodes could point to non-metadata nodes. That would solve a number of problems for me. Now of course there's no "appending linkage" for metadata nodes, so I imagine I'd have to come up with a different method for combining the nodes from each module. I suppose I would have the frontend create a node for each module with some naming convention such as "moduledata." and then in the linker do a search for all metadata nodes that begin with "moduledata" and combine them. This technique would also be useful for annotation indexes. I'll give an example: Let's say someone comes up with a new annotation in my language, let's call it @Configured, which is used to indicate that this class has some configuration data associated with it. At runtime, there's a configuration reader class that needs to find all classes which have this annotation. But we don't want the presence of that annotation to prevent classes from becoming dead if they aren't used. So we could use this technique to create metadata nodes representing the set of classes with the annotation, and at link time the linker builds a global index of the classes that didn't get eliminated. The metadata would probably look something like this: moduledata. { roots: [list of root tuples] annotation-1 [list of globals] annotation-2 [list of globals] ... and so forth } A person who creates a new annotation needs only to iterate through the set of classes in the index: for cls in Annotation.findClassesWith(Configured) { configureClass(cls); } This would be useful for things like command-line arguments (similar to LLVM's command argument system), logging, dependency injection, and a lot of other things. It's like JavaBeans for non-Java languages. Now, one thing that remains is that I don't want the trace tables (the second element in the tuple) to be eliminated by the dead global pass. As you say, referencing a global via a metadata node won't prevent the node from being deleted, and while some of those tables will be referred to by other symbols, many will not be referred to by anything. So I guess the answer is to have some dummy global that refers to all of these tables. Then once we've built the global static roots table, go ahead and delete this dummy global, so that any trace tables that didn't get referred to by some root are now dead. Then go ahead and run the dead global pass a second time. > > There are a couple of steps in the above that aren't quite clear to me. > The main problem is that I don't want the trace tables themselves to be > eliminated by the dead global elimination pass - or conversely, if they are > eliminated, I need a way to add them back into the module again. This also > includes any function pointers embedded in the trace table structures, which > might have been considered dead when the trace table was dead. > > > > In other words, what I'd like to be able to do is run the dead global > elimination pass without considering the trace tables at all, and then once > I know which globals are live, go ahead and re-associate the trace table > with each global, and then re-run the dead global pass to remove any trace > tables that weren't referred to. > > > > Any suggestions would be welcome. I'm otherwise very close to getting a > simple, non-shadow-stack collector working :) > > > > - > Devang -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110201/7709414b/attachment.html From 641 at rudkx.com Tue Feb 1 18:35:36 2011 From: 641 at rudkx.com (Mark Lacey) Date: Tue, 1 Feb 2011 16:35:36 -0800 Subject: [LLVMdev] [cfe-dev] GIT mirroring In-Reply-To: References: Message-ID: On Tue, Feb 1, 2011 at 12:20 PM, Anton Korobeynikov wrote: > So, official git mirrors are available for some subset of LLVM > projects. Thanks so much for setting this up, Anton! I notice that .gitignore in the root has tools/clang. This makes it necessary to use '--force' if using 'git submodule'. I do not know if there are any drawbacks to this - if someone knows, it would be interesting to know what those drawbacks are. One alternative would be for individuals who clone into tools/clone without using submodules to instead add tools/clang explicitly to .git/info/exclude. Thanks again, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110201/8287965e/attachment.html From geek4civic at gmail.com Tue Feb 1 18:42:58 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Wed, 2 Feb 2011 09:42:58 +0900 Subject: [LLVMdev] [cfe-dev] GIT mirroring In-Reply-To: References: Message-ID: To rebuild, it would be enough to remove .git/svn/refs/remotes/git-svn/.rev_map.* My usual way to resync; $ git fetch llvm.org (is remote name) $ git update-ref refs/remotes/git-svn llvm.org/master $ git svn fetch Partial-rebuilding .git/svn/refs/remotes/git-svn/.rev_map.91177308-0d34-0410-b5e6-96231b3b80d8 ... Currently at 124651 = 071d3af0de273b1079d79f7f979264f28d567373 r124653 = cde5a400dbc9655eddf0f383585d3cf67c11c539 ... r124704 = e349d2c61256f11180b7112ab592b4ae700f3dcf Done rebuilding .git/svn/refs/remotes/git-svn/.rev_map.91177308-0d34-0410-b5e6-96231b3b80d8 ...Takumi From peter at pcc.me.uk Tue Feb 1 19:19:15 2011 From: peter at pcc.me.uk (Peter Collingbourne) Date: Wed, 2 Feb 2011 01:19:15 +0000 Subject: [LLVMdev] [cfe-dev] GIT mirroring In-Reply-To: References: Message-ID: <20110202011915.GA20420@pcc.me.uk> On Wed, Feb 02, 2011 at 09:42:58AM +0900, NAKAMURA Takumi wrote: > To rebuild, it would be enough to remove > .git/svn/refs/remotes/git-svn/.rev_map.* > > My usual way to resync; > > $ git fetch llvm.org (is remote name) > > $ git update-ref refs/remotes/git-svn llvm.org/master > > $ git svn fetch > Partial-rebuilding > .git/svn/refs/remotes/git-svn/.rev_map.91177308-0d34-0410-b5e6-96231b3b80d8 > ... > Currently at 124651 = 071d3af0de273b1079d79f7f979264f28d567373 > r124653 = cde5a400dbc9655eddf0f383585d3cf67c11c539 > ... > r124704 = e349d2c61256f11180b7112ab592b4ae700f3dcf > Done rebuilding > .git/svn/refs/remotes/git-svn/.rev_map.91177308-0d34-0410-b5e6-96231b3b80d8 I have a small script (attached) in my $PATH so I can just do: $ git svnmu llvm -- Peter -------------- next part -------------- #!/bin/sh git fetch $1 && git update-ref refs/remotes/git-svn $1/master && git svn fetch From viridia at gmail.com Tue Feb 1 22:18:01 2011 From: viridia at gmail.com (Talin) Date: Tue, 1 Feb 2011 20:18:01 -0800 Subject: [LLVMdev] Question about compiling plugins for LLVM tools In-Reply-To: References: Message-ID: On Thu, Jan 27, 2011 at 1:27 AM, Talin wrote: > When I load my plugin into opt or llc, I get a bunch of warnings: > > llc: CommandLine Error: Argument 'use-unknown-locations' defined more than > once! > llc: CommandLine Error: Argument 'disable-debug-info-print' defined more > than once! > llc: CommandLine Error: Argument 'print-dbgscope' defined more than once! > llc: CommandLine Error: Argument 'disable-sched-hazard' defined more than > once! > llc: CommandLine Error: Argument 'verify-dom-info' defined more than once! > llc: CommandLine Error: Argument 'time-passes' defined more than once! > llc: CommandLine Error: Argument 'print-after-all' defined more than once! > llc: CommandLine Error: Argument 'print-before-all' defined more than once! > llc: CommandLine Error: Argument 'print-after' defined more than once! > llc: CommandLine Error: Argument 'print-before' defined more than once! > llc: CommandLine Error: Argument 'debug-pass' defined more than once! > llc: CommandLine Error: Argument 'version' defined more than once! > llc: CommandLine Error: Argument 'help-hidden' defined more than once! > llc: CommandLine Error: Argument 'help' defined more than once! > llc: CommandLine Error: Argument 'debug-only' defined more than once! > llc: CommandLine Error: Argument 'debug-buffer-size' defined more than > once! > llc: CommandLine Error: Argument 'debug' defined more than once! > llc: CommandLine Error: Argument 'stats' defined more than once! > llc: CommandLine Error: Argument 'info-output-file' defined more than once! > llc: CommandLine Error: Argument 'track-memory' defined more than once! > > I'm guessing the reason this happens is because the plugin is a shared > library that is linking against the LLVM libraries, and so what happens is > that the various command-line objects, which are statically constructed, are > getting loaded twice, once for the tool itself, and once for the plugin. > > However, I'm not sure how to create my plugin any differently. I'm using > cmake's 'add_library(name SHARED ...)' to create the plugin like so: > > add_library(reflector SHARED ${REFLECT_SOURCES} ${COMMON_HEADERS} > ${REFLECT_HEADERS}) > target_link_libraries(reflector > linker_common > ${LLVM_TARGET} > ${LLVM_CORE} > ${LLVM_SUPPORT} > ${LLVM_SYSTEM} > ) > > > Any advice on this? > Still trying to puzzle this one out...what I think I need is to link my plugin such that it doesn't include the LLVM libs in the plugin, but only refer to them as external symbols - but I'm not enough of a unix expert to know how to do that. -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110201/fc7fafe8/attachment-0001.html From atrick at apple.com Tue Feb 1 23:05:15 2011 From: atrick at apple.com (Andrew Trick) Date: Tue, 1 Feb 2011 21:05:15 -0800 Subject: [LLVMdev] Loop simplification In-Reply-To: <4D489E30.2000309@sidefx.com> References: <4D487644.3070409@sidefx.com> <4D489E30.2000309@sidefx.com> Message-ID: <96AE8F10-3878-40DB-AFA8-95B6681048CA@apple.com> On Feb 1, 2011, at 3:58 PM, Andrew Clinton wrote: > On 02/01/2011 06:43 PM, Frits van Bommel wrote: >> I don't think that's always possible. >> For example: if a phi in the successor has a phi in the predecessor as >> one of it's incoming values, then the predecessor cases have to be >> merged into the successor phi. However, if they share a predecessor >> but have different incoming values for it that can't be done. > > You're right. I think it's possible to avoid this (and all other?) > failing cases by ensuring that the predecessor dominates the successor > before trying to merge them. If the dominance relationship is not true, > it may not be possible to merge them. > > Andrew That simplifies your implementation, but it's really unnecessary to handle this case. The CFG+phi transformation is still valid. As long as you avoid creating new critical edges, then the phis will always be representable (leave a single predecessor block on the branch targets). -Andy From sir_johny at seznam.cz Tue Feb 1 20:34:57 2011 From: sir_johny at seznam.cz (Jan) Date: Wed, 2 Feb 2011 02:34:57 +0000 (UTC) Subject: [LLVMdev] LLVMHello example fails with References: Message-ID: Same issue here. Did you find any solution to this? Did I miss something? Jan From eliben at gmail.com Wed Feb 2 00:35:35 2011 From: eliben at gmail.com (Eli Bendersky) Date: Wed, 2 Feb 2011 08:35:35 +0200 Subject: [LLVMdev] reference to %llvm.dbg.variable in source level debug docs In-Reply-To: <50622D55-EA10-4312-8E16-C469E7DBF9A7@apple.com> References: <50622D55-EA10-4312-8E16-C469E7DBF9A7@apple.com> Message-ID: >> There are a couple of references made to %llvm.dbg.variable, which >> isn't defined anywhere. It it an intrinsic? A global? Could it be a >> relic from the old debug info docs (where it *is* defined?). The same >> goes for llvm.dbg.derivedtype and llvm.dbg.subrange which are also >> referenced but not defined. > > It was a stale reference. I fixed the docs. Thanks. Is llvm.dbg.derivedtype.type also a stale reference? It's mentioned in "Derived type descriptors" but isn't described or defined anywhere. >> Additionally, there's this definition: >> >> """ >> ?void %llvm.dbg.declare(metadata, metadata) >> >> This intrinsic provides information about a local element (ex. >> variable.) The first argument is metadata holding alloca for the >> variable.. The second argument is the %llvm.dbg.variable containing >> the description of the variable. >> """ >> >> I see all uses of llvm.dbg.declare having values/types as first >> argument, not metadata. What am I missing? > > I am seeing > ?call void @llvm.dbg.declare(metadata !{i32* %argc.addr}, metadata !12), !dbg !13 In the example IR of http://llvm.org/docs/SourceLevelDebugging.html, section "Object lifetimes and scoping", there is: call void @llvm.dbg.declare({}* %2, metadata !12), !dbg !14 Which isn't exactly like the llvm.dbg.declare intrinsic is defined - in the definition the first argument is also metadata. Indeed, generating IR from C files using trunk clang, I also see: call void @llvm.dbg.declare(metadata !{i32* %a.addr}, metadata !22), !dbg !23 Which is different from what http://llvm.org/docs/SourceLevelDebugging.html shows. Eli From nicolas.geoffray at gmail.com Wed Feb 2 01:32:53 2011 From: nicolas.geoffray at gmail.com (nicolas geoffray) Date: Wed, 2 Feb 2011 08:32:53 +0100 Subject: [LLVMdev] Compile function with limited set of registers? Jump to another function? In-Reply-To: References: Message-ID: Hi James, Joshua is right, what you're trying to accomplish is quite known in the Java VM world ( http://domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.oopsla01.html ). In order to express the "thunk" code in LLVM you need a full control of how registers are used (because otherwise they would mess up with the arguments). I haven't investigated enough to know if that's possible today in LLVM (I think it wasn't a few years ago when I added the optimization). So what I ended up with was a generic IR that walks the interface table of an object and detects collisions. The IR was inline in the caller to make sure that arguments in registers are not overriden. This may not be the best approach today, but I believe it was the easiest way to have something efficient at that point. Cheers, Nicolas On Mon, Jan 31, 2011 at 11:01 PM, James Williams wrote: > Thanks, that's a good idea - I'll have a look through the VMKit source. > > -- James > > > On 31 January 2011 21:39, Joshua Warner wrote: > >> Hi James, >> >> I see the problem now. You might look at VMKit (a Java VM build with the >> LLVM JIT compiler) - I would expect it uses a similar method for resolving >> interface calls (the method, if I understand it correctly, is well-known in >> the Java world). >> >> I've CC'd the main dev behind VMKit - he might be able to lend some >> insight. >> >> --Joshua >> >> On Mon, Jan 31, 2011 at 2:24 PM, James Williams wrote: >> >>> Hi Joshua, >>> >>> Thanks - I was hoping that would be the case. >>> >>> However, I've had a think about this since I posted to the list and I >>> believe the only way to handle these issues safely in LLVM IR would be to >>> define the thunk as varargs. I'm not sure how well LLVM handles varargs but >>> ideally it would all compile down to nothing since the parameters to the the >>> thunk would be in the same registers/stack locations as required by the >>> target method. >>> >>> Unfortunately, varargs has some downsides: there's the additional >>> overhead for the extra hidden parameter to every interface method call for >>> the parameter count plus it doesn't (I don't think) support tail calls. >>> >>> -- James >>> >>> >>> On 27 January 2011 17:37, Joshua Warner wrote: >>> >>>> Hi James, >>>> >>>> I'm no expert in LLVM IR, but I think that just encoding each *actual* >>>> method invocation in the thunk as a tail call would work. This would >>>> require trusting that LLVM passes / code generators will translate down to a >>>> jump, as is normal. If the passes / code generators are smart, I see no >>>> reason that LLVM wouldn't emit code that fits your requirements. Either >>>> way, you know that your thunk will be correct - it just might not be as >>>> efficient as you want. >>>> >>>> I would suggest experimenting with generating a thunk this way, and look >>>> at the resultant target assembly to make sure it's doing what you want. >>>> >>>> -Joshua >>>> >>>> On Tue, Jan 25, 2011 at 2:04 AM, James Williams wrote: >>>> >>>>> Hi, >>>>> >>>>> Can anyone tell me, is it possible to express in LLVM IR: >>>>> - that, for a specific function, register allocator can use only >>>>> limited set of registers? (specifically, cannot touch any registers that >>>>> might contain parameters) >>>>> - that stack can't be touched? (or at least must balance on exit from >>>>> thunk) >>>>> - jump, not call, to another function leaving any received parameters >>>>> unchanged in registers and on stack? >>>>> >>>>> Thanks, >>>>> -- James Williams >>>>> >>>>> Background: >>>>> >>>>> I'm looking for some advice on implementing thunks required by my >>>>> language's interface call mechanism. This is a fairly conventional >>>>> arrangement where method selectors in interfaces are hashed to determine >>>>> their index within a vtable and hash collisions are disambiguated at runtime >>>>> by a thunk, which determines which method to call from a selector id passed >>>>> as the first method parameter. >>>>> >>>>> I'm currently using a single thunk (written in assembly) for all >>>>> collisions that walks a table to determine what method to call. This works >>>>> but it's inefficient and requires the a hand written thunk for each >>>>> supported target. >>>>> >>>>> I'd like to instead generate IR for a specific thunk for each vtable >>>>> collisoin that does a binary search of possible selectors because this will >>>>> avoid some pointer dereferences and an additional indirect call. >>>>> >>>>> The problem is that a thunk may need to decide between methods with >>>>> different signatures without disturbing parameters in registers and on the >>>>> stack and then jump to, rather than call, another function: >>>>> >>>>> interface X: >>>>> method A(a, b) >>>>> >>>>> interface Y: >>>>> method B(c, d, e) >>>>> >>>>> class Z implements X, y: >>>>> method A(a, b) ... >>>>> method B(c, d, e) ... >>>>> >>>>> X.A + Y.B happen to hash to same vtable index, say -3 >>>>> >>>>> This would require a thunk something like: >>>>> >>>>> vtable[-3] = >>>>> thunk_Z_AorB(selector_id, ...) >>>>> // binary search for matching selector id: >>>>> if selector_id <= selector_Z_A then >>>>> Z.A(selector_id, ...) >>>>> else >>>>> Z.B(selector_id, ...) >>>>> fi >>>>> >>>>> which would ideally would compile on x64 to something like: >>>>> >>>>> thunk_Z_AorB: >>>>> cmp $selector_Z_A, %rdi >>>>> jle Z.A >>>>> jmp Z.B >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20110202/daca0361/attachment.html From baldrick at free.fr Wed Feb 2 01:55:09 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 02 Feb 2011 08:55:09 +0100 Subject: [LLVMdev] Question about compiling plugins for LLVM tools In-Reply-To: References: Message-ID: <4D490DDD.8050403@free.fr> Hi Talin, my auto-simplifier uses a plugin (harvest.so) to harvest interesting code sequences from bitcode. You might want to take a look at how it is built. You can get it from svn://topo.math.u-psud.fr/harvest Ciao, Duncan. > On Thu, Jan 27, 2011 at 1:27 AM, Talin > wrote: > > When I load my plugin into opt or llc, I get a bunch of warnings: > > llc: CommandLine Error: Argument 'use-unknown-locations' defined more than once! > llc: CommandLine Error: Argument 'disable-debug-info-print' defined more > than once! > llc: CommandLine Error: Argument 'print-dbgscope' defined more than once! > llc: CommandLine Error: Argument 'disable-sched-hazard' defined more than once! > llc: CommandLine Error: Argument 'verify-dom-info' defined more than once! > llc: CommandLine Error: Argument 'time-passes' defined more than once! > llc: CommandLine Error: Argument 'print-after-all' defined more than once! > llc: CommandLine Error: Argument 'print-before-all' defined more than once! > llc: CommandLine Error: Argument 'print-after' defined more than once! > llc: CommandLine Error: Argument 'print-before' defined more than once! > llc: CommandLine Error: Argument 'debug-pass' defined more than once! > llc: CommandLine Error: Argument 'version' defined more than once! > llc: CommandLine Error: Argument 'help-hidden' defined more than once! > llc: CommandLine Error: Argument 'help' defined more than once! > llc: CommandLine Error: Argument 'debug-only' defined more than once! > llc: CommandLine Error: Argument 'debug-buffer-size' defined more than once! > llc: CommandLine Error: Argument 'debug' defined more than once! > llc: CommandLine Error: Argument 'stats' defined more than once! > llc: CommandLine Error: Argument 'info-output-file' defined more than once! > llc: CommandLine Error: Argument 'track-memory' defined more than once! > > I'm guessing the reason this happens is because the plugin is a shared > library that is linking against the LLVM libraries, and so what happens is > that the various command-line objects, which are statically constructed, are > getting loaded twice, once for the tool itself, and once for the plugin. > > However, I'm not sure how to create my plugin any differently. I'm using > cmake's 'add_library(name SHARED ...)' to create the plugin like so: > > add_library(reflector SHARED ${REFLECT_SOURCES} ${COMMON_HEADERS} > ${REFLECT_HEADERS}) > target_link_libraries(reflector > linker_common > ${LLVM_TARGET} > ${LLVM_CORE} > ${LLVM_SUPPORT} > ${LLVM_SYSTEM} > ) > > > Any advice on this? > > > Still trying to puzzle this one out...what I think I need is to link my plugin > such that it doesn't include the LLVM libs in the plugin, but only refer to them > as external symbols - but I'm not enough of a unix expert to know how to do that. > > -- Talin > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From baldrick at free.fr Wed Feb 2 01:57:44 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 02 Feb 2011 08:57:44 +0100 Subject: [LLVMdev] LLVMHello example fails with "undefined symbol" In-Reply-To: References: Message-ID: <4D490E78.9090309@free.fr> Hi Anatol, does the hello plugin in llvm-2.8/lib/Transforms/Hello work? The online docs refer to the upcoming 2.9 release of LLVM, so may not work correctly with LLVM 2.8. Ciao, Duncan. > I am trying to learn LLVM by following this article > http://llvm.org/docs/WritingAnLLVMPass.html > > I checked 2.8 version from svn, built it and now I am trying to run > Hello world example as > > $ opt -load ./Release/lib/LLVMHello.so -analyze > > but unfortunately it fails: > > Error opening './Release/lib/LLVMHello.so': > ./Release/lib/LLVMHello.so: undefined symbol: > _ZNK4llvm12FunctionPass17createPrinterPassERNS_11raw_ostreamERKSs > -load request ignored. > > Is it a known problem? How I should fix it? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From nowar100 at gmail.com Wed Feb 2 02:24:23 2011 From: nowar100 at gmail.com (Wen-Han Gu) Date: Wed, 2 Feb 2011 16:24:23 +0800 Subject: [LLVMdev] C++ Name mangling Message-ID: Hi all, I had faced a problem. The result from jit cannot feed to c++filt tool decoding correctly. Could they not be the same? BTW, which part of source code can I find the detail? Thanks all. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110202/e07cbf2e/attachment.html From o.j.sivart at gmail.com Wed Feb 2 06:17:18 2011 From: o.j.sivart at gmail.com (o.j.sivart at gmail.com) Date: Wed, 2 Feb 2011 22:47:18 +1030 Subject: [LLVMdev] Target specific intrinsic documentation Message-ID: Hi all, Just looking for any documentation on target specific intrinsics, initially specifically the x86 sse intrinsics. Is there anything outside the source code that provides any documentation of such things -- I couldn't find anything definitive. Cheers From DZivi at nds.com Wed Feb 2 06:33:48 2011 From: DZivi at nds.com (Zivi, David) Date: Wed, 2 Feb 2011 14:33:48 +0200 Subject: [LLVMdev] llvm-gcc-4.2.-2.8 failed on gcc 3.4.6 Message-ID: <6385EF5E30011E42B75895D851412B2A64C12B1011@ILMA1.IL.NDS.COM> Hi, I got the following error message when I try to compile llvm-gcc with gcc 3.4.6: cc1plus: error: unrecognized command line option "-Wno-variadic-macros" make[3]: *** [llvm-main.o] Error 1 Someone have an idea ? thanks ________________________________ This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster at nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. An NDS Group Limited company. www.nds.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110202/1ee9496f/attachment.html From rcsaba at gmail.com Wed Feb 2 07:03:56 2011 From: rcsaba at gmail.com (Csaba Raduly) Date: Wed, 2 Feb 2011 14:03:56 +0100 Subject: [LLVMdev] llvm-gcc-4.2.-2.8 failed on gcc 3.4.6 In-Reply-To: <6385EF5E30011E42B75895D851412B2A64C12B1011@ILMA1.IL.NDS.COM> References: <6385EF5E30011E42B75895D851412B2A64C12B1011@ILMA1.IL.NDS.COM> Message-ID: Hi, On Wed, Feb 2, 2011 at 1:33 PM, Zivi, David wrote: > Hi, > I got the following error message when I try to compile llvm-gcc with gcc > 3.4.6: > > cc1plus: error: unrecognized command line option "-Wno-variadic-macros" > make[3]: *** [llvm-main.o] Error 1 > > Someone have an idea ? -Wno-variadic-macros is only understood by GCC 4.0 and above. Did you switch your compiler without re-running configure? (configure checks that the compiler understands -Wno-variadic-macros, among others) Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds From anton at korobeynikov.info Wed Feb 2 07:20:33 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 2 Feb 2011 16:20:33 +0300 Subject: [LLVMdev] llvm-gcc-4.2.-2.8 failed on gcc 3.4.6 In-Reply-To: <6385EF5E30011E42B75895D851412B2A64C12B1011@ILMA1.IL.NDS.COM> References: <6385EF5E30011E42B75895D851412B2A64C12B1011@ILMA1.IL.NDS.COM> Message-ID: > cc1plus: error: unrecognized command line option "-Wno-variadic-macros" > make[3]: *** [llvm-main.o] Error 1 > > Someone have an idea ? Yes, C++ parts of llvm-gcc are built via your system compiler which does not support this option. Current workaround is either to upgrade compiler or hack the makefiles to remove this option. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From richard at xmos.com Wed Feb 2 12:11:12 2011 From: richard at xmos.com (Richard Osborne) Date: Wed, 2 Feb 2011 18:11:12 +0000 Subject: [LLVMdev] Implementing platform specific library call simplification Message-ID: <4D499E40.20409@xmos.com> The newlib C library provides iprintf(), a restricted version of printf without support for floating-point formatting. I'd like to add an optimization which turns calls to printf() into calls to iprintf() if the format string has no floating point specifiers. At the moment I've got this working locally by adding code to the simplify-libcalls pass. However this will break on targets where iprintf() isn't available. Is there a sensible place to add information about which library functions are available for a particular target? Thanks, Richard -- Richard Osborne | XMOS http://www.xmos.com From yuri at rawbw.com Wed Feb 2 14:06:54 2011 From: yuri at rawbw.com (Yuri) Date: Wed, 02 Feb 2011 12:06:54 -0800 Subject: [LLVMdev] Is llvm correct outputting the same data layout on Solaris i386 as on Linux i386 ? Message-ID: <4D49B95E.9050607@rawbw.com> Solaris-i386 isn't in the list of supported configurations. I have built llvm and am trying to run some code in JIT on Solaris. Same code that runs fine on linux crashes during some external fun function invokation from JIT. My first suspicion is ABI. clang on Solaris outputs the same data layout string as on linux. Is Solaris ABI really the same on i386? Yuri From anton at korobeynikov.info Wed Feb 2 14:40:24 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 2 Feb 2011 23:40:24 +0300 Subject: [LLVMdev] Is llvm correct outputting the same data layout on Solaris i386 as on Linux i386 ? In-Reply-To: <4D49B95E.9050607@rawbw.com> References: <4D49B95E.9050607@rawbw.com> Message-ID: > Is Solaris ABI really the same on i386? Probably not. Also, note that the problem is not ABI alone, the layouts of different C stdlib structs might be different (e.g. FILE), etc. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From viridia at gmail.com Wed Feb 2 14:55:30 2011 From: viridia at gmail.com (Talin) Date: Wed, 2 Feb 2011 12:55:30 -0800 Subject: [LLVMdev] Convenience methods in ConstantExpr et al In-Reply-To: References: Message-ID: On Mon, Jan 31, 2011 at 10:57 PM, Talin wrote: > I notice that there's a lot of inconsistency in the various LLVM classes > with respect to convenience methods. Here's some examples: > > For creating GEPS, IRBuilder has: > > CreateGEP (2 overloads) > CreateInBoundsGEP (2 overloads) > CreateConstGEP1_32 > CreateConstInBoundsGEP1_32 > CreateConstGEP2_32 > CreateConstInBoundsGEP2_32 > CreateConstGEP1_64 > CreateConstInBoundsGEP1_64 > CreateConstGEP2_64 > CreateConstInBoundsGEP2_64 > CreateStructGEP > > All of which are very useful. However, ConstExpression only has: > > getGetElementPtr > getGetElementPtr > getInBoundsGetElementPtr > getInBoundsGetElementPtr > > It would be nice if ConstantExpr's GEP-building methods used the same > naming convention and had the same convenience methods as IRBuilder. (In > fact, the naming convention between IRBuilder and the various Constants.h > classes desperately needs to be reconciled, a point which I am sure everyone > is painfully aware of.) > > Another thing I'd like to see is for ConstantArray::get(), > ConstantStruct::get() and ConstantVector::get() to have an overload that > takes an iterator pair like IRBuilder's CreateGEP and CreateCall methods. > Also useful for creating small structs would be overloads for > ConstantStruct::get that took 1-4 arguments, instead of having to create a > vector every time. Even better would be an "end with null" version, like > StructType::get() does. These should be added to FunctionType::get() as > well. > By the way, the reason I'm asking this is because I thought I might spend some time adding the convenience methods myself - but if there is a plan underway to fix up the APIs or resolve the incompatibilities with the naming conventions I don't want to get in the way of that. > -- > -- Talin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110202/4f19f8ef/attachment.html From yuri at rawbw.com Wed Feb 2 15:01:41 2011 From: yuri at rawbw.com (Yuri) Date: Wed, 02 Feb 2011 13:01:41 -0800 Subject: [LLVMdev] Is llvm correct outputting the same data layout on Solaris i386 as on Linux i386 ? In-Reply-To: References: <4D49B95E.9050607@rawbw.com> Message-ID: <4D49C635.3030804@rawbw.com> On 02/02/2011 12:40, Anton Korobeynikov wrote: >> Is Solaris ABI really the same on i386? >> > Probably not. Also, note that the problem is not ABI alone, the > layouts of different C stdlib structs might be different (e.g. FILE), > etc. > > So how do I figure out what is the correct layout string would be on Solaris-i386? stdlib structures? This depends on the calling code being aware of this. It its C++ code its supposed to know about this by itself from headers. Yuri From anton at korobeynikov.info Wed Feb 2 15:06:23 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 3 Feb 2011 00:06:23 +0300 Subject: [LLVMdev] Is llvm correct outputting the same data layout on Solaris i386 as on Linux i386 ? In-Reply-To: <4D49C635.3030804@rawbw.com> References: <4D49B95E.9050607@rawbw.com> <4D49C635.3030804@rawbw.com> Message-ID: > So how do I figure out what is the correct layout string would be on > Solaris-i386? Read the ABI docs and construct the string. Note also that this is not enough since bunch of stuff was lowered by a frontend in target-specific way. > stdlib structures? This depends on the calling code being aware of this. It > its C++ code its supposed to know about this by itself from headers. Right, but given that headers might be different the code itself might do completely different things on different platforms. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From nicholas at mxc.ca Wed Feb 2 15:29:59 2011 From: nicholas at mxc.ca (Nick Lewycky) Date: Wed, 02 Feb 2011 13:29:59 -0800 Subject: [LLVMdev] Convenience methods in ConstantExpr et al In-Reply-To: References: Message-ID: <4D49CCD7.2000601@mxc.ca> Talin wrote: > On Mon, Jan 31, 2011 at 10:57 PM, Talin > wrote: > > I notice that there's a lot of inconsistency in the various LLVM > classes with respect to convenience methods. Here's some examples: > > For creating GEPS, IRBuilder has: > > CreateGEP (2 overloads) > CreateInBoundsGEP (2 overloads) > CreateConstGEP1_32 > CreateConstInBoundsGEP1_32 > CreateConstGEP2_32 > CreateConstInBoundsGEP2_32 > CreateConstGEP1_64 > CreateConstInBoundsGEP1_64 > CreateConstGEP2_64 > CreateConstInBoundsGEP2_64 > CreateStructGEP > > All of which are very useful. However, ConstExpression only has: > > getGetElementPtr > getGetElementPtr > getInBoundsGetElementPtr > getInBoundsGetElementPtr > > It would be nice if ConstantExpr's GEP-building methods used the > same naming convention and had the same convenience methods as > IRBuilder. (In fact, the naming convention between IRBuilder and the > various Constants.h classes desperately needs to be reconciled, a > point which I am sure everyone is painfully aware of.) It's a matter of layering. IRBuilder will call into ConstantExpr as needed; the ConstantExpr API is at the same level as the llvm::Instruction hierarchy itself. > Another thing I'd like to see is for ConstantArray::get(), > ConstantStruct::get() and ConstantVector::get() to have an overload > that takes an iterator pair like IRBuilder's CreateGEP and > CreateCall methods. Also useful for creating small structs would be > overloads for ConstantStruct::get that took 1-4 arguments, instead > of having to create a vector every time. Even better would be an > "end with null" version, like StructType::get() does. These should > be added to FunctionType::get() as well. Yep! Nick > By the way, the reason I'm asking this is because I thought I might > spend some time adding the convenience methods myself - but if there is > a plan underway to fix up the APIs or resolve the incompatibilities with > the naming conventions I don't want to get in the way of that. From dpatel at apple.com Wed Feb 2 18:26:07 2011 From: dpatel at apple.com (Devang Patel) Date: Wed, 2 Feb 2011 16:26:07 -0800 Subject: [LLVMdev] reference to %llvm.dbg.variable in source level debug docs In-Reply-To: References: <50622D55-EA10-4312-8E16-C469E7DBF9A7@apple.com> Message-ID: <2CFCCA5C-8BBD-4C43-BF11-CF73F35717AB@apple.com> On Feb 1, 2011, at 10:35 PM, Eli Bendersky wrote: >>> There are a couple of references made to %llvm.dbg.variable, which >>> isn't defined anywhere. It it an intrinsic? A global? Could it be a >>> relic from the old debug info docs (where it *is* defined?). The same >>> goes for llvm.dbg.derivedtype and llvm.dbg.subrange which are also >>> referenced but not defined. >> >> It was a stale reference. I fixed the docs. > > Thanks. Is llvm.dbg.derivedtype.type also a stale reference? It's > mentioned in "Derived type descriptors" but isn't described or defined > anywhere. > >>> Additionally, there's this definition: >>> >>> """ >>> void %llvm.dbg.declare(metadata, metadata) >>> >>> This intrinsic provides information about a local element (ex. >>> variable.) The first argument is metadata holding alloca for the >>> variable.. The second argument is the %llvm.dbg.variable containing >>> the description of the variable. >>> """ >>> >>> I see all uses of llvm.dbg.declare having values/types as first >>> argument, not metadata. What am I missing? >> >> I am seeing >> call void @llvm.dbg.declare(metadata !{i32* %argc.addr}, metadata !12), !dbg !13 > > In the example IR of http://llvm.org/docs/SourceLevelDebugging.html, > section "Object lifetimes and scoping", there is: > > call void @llvm.dbg.declare({}* %2, metadata !12), !dbg !14 > > Which isn't exactly like the llvm.dbg.declare intrinsic is defined - > in the definition the first argument is also metadata. > Indeed, generating IR from C files using trunk clang, I also see: > > call void @llvm.dbg.declare(metadata !{i32* %a.addr}, metadata !22), !dbg !23 > > Which is different from what > http://llvm.org/docs/SourceLevelDebugging.html shows. Thanks Eli for finding these. I have fixed these stale references. Please let me know if you find anything else. - Devang From dgregor at apple.com Wed Feb 2 19:12:14 2011 From: dgregor at apple.com (Douglas Gregor) Date: Wed, 2 Feb 2011 17:12:14 -0800 Subject: [LLVMdev] Spell Correction Efficiency In-Reply-To: References: <081AD223-B908-4757-973E-45A57CEDD942@apple.com> Message-ID: <63BC7D07-F7FF-4C1F-910F-DE51F7B69755@apple.com> On Jan 15, 2011, at 8:31 AM, Matthieu Monrocq wrote: > Hello Doug, > > *putting llvmdev in copy since they are concerned too* > > I've finally got around to finish a working implementation of the typical Levenshtein Distance with the diagonal optimization. > > I've tested it against the original llvm implementation and checked it on a set of ~18k by randomly generating a variation of each word and checking that both implementations would return the same result... took me some time to patch the diagonal version, but they now do. Okay. Did you do any performance comparisons? The point of introducing a new algorithm is to improve performance. > I have left the older method in place, especially because I saw that it was used in FileCheck and was a bit wary of any side-effect I might introduce there. > > I have thus created a new method: unsigned StringRef::levenshtein_distance(StringRef other, unsigned maxEditDistance) and replace the two uses of edit_distance in Sema\SemaLookup.cpp with it. I would much rather just replace edit_distance completely. Compiler writers aren't string-savvy enough to pick between the two algorithms :) > I have ditched the "AllowReplace" argument since it further complicated the logic of an already ~150 lines method for no obvious gain (as far as I could see) and I have also explicited the computations a bit by using named temporaries. Okay. I can't imagine why anyone would want to turn off replacement anyway. > Unfortunately I have only a Windows machine at hand for the moment and the tests don't work that well... so I'd appreciate if anyone could check my changes. A bunch of Clang tests failed when I applied your patch, so it's not quite ready yet. These are the failures: Failing Tests (10): Clang :: CXX/class/class.friend/p1.cpp Clang :: FixIt/fixit.cpp Clang :: Parser/objc-quirks.m Clang :: Parser/recovery.c Clang :: Sema/MicrosoftExtensions.c Clang :: SemaCXX/unknown-type-name.cpp Clang :: SemaObjC/category-1.m Clang :: SemaObjC/super.m Clang :: SemaObjC/synth-provisional-ivars.m Clang :: SemaObjCXX/category-lookup.mm I looked at the first one, and for the strings "UndeclaredSoFar" and "_Imaginary" and a maxEditDistance of 5 (= the difference in their lengths, if that matters), the algorithm returns an edit distance of 2. One of the other tests (Parser/objc-quirks.m) is actually a crash. + // maxDistance (aka D) directly influences the width of the strip (2*D+1) + // we arbitrarily restrict it in case the caller did not see fit to do it + // (from clang\lib\Sema\SemaLookup.cpp in TypoCorrectionConsumer::FoundName) + unsigned const maxDistance = std::min(unsigned((otherLength+2)/3), + maxEditDistance); I don't think this belongs here. We can count on the client to supply a reasonable maxEditDistance. If our performance is going to degrade horribly when an unreasonable maxEditDistance is provided (e.g., > the sum of the string lengths), we could just fall back to the simplistic algorithm we currently have. Oh, and please look at the LLVM Coding Standards (http://llvm.org/docs/CodingStandards.html), and reformat your patch accordingly. Thanks! - Doug From jasonwkim at google.com Wed Feb 2 19:57:17 2011 From: jasonwkim at google.com (Jason Kim) Date: Wed, 2 Feb 2011 17:57:17 -0800 Subject: [LLVMdev] Call to non-constant memset() being generated where libc is not available In-Reply-To: <4D4662BA.3070308@mxc.ca> References: <4D4662BA.3070308@mxc.ca> Message-ID: On Sun, Jan 30, 2011 at 11:20 PM, Nick Lewycky wrote: > David Meyer wrote: >> I am compiling something without standard libraries, including no libc. >> >> Somehow, this bitcode is being generated by plain array manipulation code: >> >> ? ?%12 = add i8 %11, -19 >> ? ?%tmp35 = icmp sgt i32 %9, 1 >> ? ?%smax36 = select i1 %tmp35, i32 %9, i32 1 >> ? ?call void @llvm.memset.p0i8.i32(i8* getelementptr inbounds ([100 x >> i8]* @global_array_char, i32 0, i32 0), i8 %12, i32 %smax36, i32 1, i1 >> false) >> >> (global_array_char is an array of length 100, which only partially gets >> used.) > > That's not quite enough to go on. What's the original code, and what is > this? Are we looking at an array initialization here? > >> This gets lowered by LLC to a library call to memset(), which cannot be >> satisfied. >> >> Any advice? Pdox, is this happening on ARM as well? > > As Duncan pointed out, memset may be generated as part of the ABI even > in a freestanding (ie., no libc) environment. I think memcpy is in the > same boat. > > If you have a different target with a different ABI that doesn't provide > memset/memcpy, you could try writing your own generic lowering in > Target/X86. Or you could always link against something native that > provides memset/memcpy, which is what I strongly recommend. > >> Thanks, >> David Meyer From viridia at gmail.com Wed Feb 2 21:27:07 2011 From: viridia at gmail.com (Talin) Date: Wed, 2 Feb 2011 19:27:07 -0800 Subject: [LLVMdev] Convenience methods in ConstantExpr et al In-Reply-To: <4D49CCD7.2000601@mxc.ca> References: <4D49CCD7.2000601@mxc.ca> Message-ID: On Wed, Feb 2, 2011 at 1:29 PM, Nick Lewycky wrote: > Talin wrote: > >> On Mon, Jan 31, 2011 at 10:57 PM, Talin > > wrote: >> >> I notice that there's a lot of inconsistency in the various LLVM >> classes with respect to convenience methods. Here's some examples: >> >> For creating GEPS, IRBuilder has: >> >> CreateGEP (2 overloads) >> CreateInBoundsGEP (2 overloads) >> CreateConstGEP1_32 >> CreateConstInBoundsGEP1_32 >> CreateConstGEP2_32 >> CreateConstInBoundsGEP2_32 >> CreateConstGEP1_64 >> CreateConstInBoundsGEP1_64 >> CreateConstGEP2_64 >> CreateConstInBoundsGEP2_64 >> CreateStructGEP >> >> All of which are very useful. However, ConstExpression only has: >> >> getGetElementPtr >> getGetElementPtr >> getInBoundsGetElementPtr >> getInBoundsGetElementPtr >> >> It would be nice if ConstantExpr's GEP-building methods used the >> same naming convention and had the same convenience methods as >> IRBuilder. (In fact, the naming convention between IRBuilder and the >> various Constants.h classes desperately needs to be reconciled, a >> point which I am sure everyone is painfully aware of.) >> > > It's a matter of layering. IRBuilder will call into ConstantExpr as needed; > the ConstantExpr API is at the same level as the llvm::Instruction hierarchy > itself. I find that I call the static methods in ConstantExpr a *lot* without going through IRBuilder - hundreds of times in my frontend. My language generates a lot of static data - reflection information, trace tables for the garbage collector, dispatch tables, runtime annotations, static object instances, and so on. (In fact there's a special helper class "StructBuilder" that automates a lot of the work of building constant structs, such as adding the standard object header and so on.) I guess what I'm asking is, would there be any *resistance* to adding additional static members to ConstantExpr to make it more convenient to do constant GEPs? > > Another thing I'd like to see is for ConstantArray::get(), >> ConstantStruct::get() and ConstantVector::get() to have an overload >> that takes an iterator pair like IRBuilder's CreateGEP and >> CreateCall methods. Also useful for creating small structs would be >> overloads for ConstantStruct::get that took 1-4 arguments, instead >> of having to create a vector every time. Even better would be an >> "end with null" version, like StructType::get() does. These should >> be added to FunctionType::get() as well. >> > > Yep! > > Nick > > > By the way, the reason I'm asking this is because I thought I might >> spend some time adding the convenience methods myself - but if there is >> a plan underway to fix up the APIs or resolve the incompatibilities with >> the naming conventions I don't want to get in the way of that. >> > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110202/6027272e/attachment.html From lally.singh at gmail.com Wed Feb 2 21:53:41 2011 From: lally.singh at gmail.com (Lally Singh) Date: Wed, 2 Feb 2011 22:53:41 -0500 Subject: [LLVMdev] Bitcode not portable from linux to solaris? In-Reply-To: References: Message-ID: To answer my own question. The problem is that Solaris ships with very old tools, and llvmc was generating assembler that worked with a fresh (gcc-4.5) compile & install. I had them handy, just further down the path. Hopefully anyone with the same problem can find this in the archive. Thanks everyone. On Mon, Jan 31, 2011 at 10:56 AM, Lally Singh wrote: > Hi all. > > ?I made some early experiments --- namely a llvm program that > printf'd "hello world" -- that seemed to indicate that a bitcode file > I generate on linux would work on my solaris box. ?Well, they're > actually the same machine, an amd opteron sun box with a linux vm > running. ? My generating program doesn't run on solaris, but I was > hoping to generate bitcode for it from linux. ?lli crashes pretty > quick (although the same use on linux has been debugged pretty well, > and it's a pretty simple program!). ?llvmc -clang complains quite a > bit about invalid directives (sorry, couldn't get on the machine > before my commute to work, so this is from memory only). > > I read something quite some time ago that perhaps the bitcode wasn't > portable if the machines had different pointer sizes. ?Solaris is > 64bit (almost exclusively). ?I tried generating from both 32 and 64 > bit linux VMs, but perhaps I just didn't configure it properly to > generate 64-bit code? > > I thought it was supposed to be portable? ?Am I wrong? ?llvm-dis works > on it fine. ?Perhaps a llvm-dis -> llvm-as cycle would do the trick? > > I can post the (small) bitcode file and the errors tonight, if that helps. > > Any help is really appreciated. ?Thanks in advance! > From yuri at rawbw.com Wed Feb 2 22:44:27 2011 From: yuri at rawbw.com (Yuri) Date: Wed, 02 Feb 2011 20:44:27 -0800 Subject: [LLVMdev] Bitcode not portable from linux to solaris? In-Reply-To: References: Message-ID: <4D4A32AB.5010008@rawbw.com> On 02/02/2011 19:53, Lally Singh wrote: > To answer my own question. The problem is that Solaris ships with > very old tools, and llvmc was generating assembler that worked with a > fresh (gcc-4.5) compile& install. I had them handy, just further > down the path. Hopefully anyone with the same problem can find this > in the archive. > I think llvm isn't ported to Solaris i386/x86_64 yet. Particularly, clang there prints the same data layout string as on linux assuming ABI is the same when it isn't. So using your approach certain calls to the externally compiled libraries will cause failures. Some simpler examples may work fine. Yuri From lally.singh at gmail.com Wed Feb 2 23:11:43 2011 From: lally.singh at gmail.com (Lally Singh) Date: Thu, 3 Feb 2011 00:11:43 -0500 Subject: [LLVMdev] Bitcode not portable from linux to solaris? In-Reply-To: <4D4A32AB.5010008@rawbw.com> References: <4D4A32AB.5010008@rawbw.com> Message-ID: Well, then I'm royally screwed. What would I have to add to make it work, if only for a very limited subset of cases? On Wed, Feb 2, 2011 at 11:44 PM, Yuri wrote: > On 02/02/2011 19:53, Lally Singh wrote: >> >> To answer my own question. ?The problem is that Solaris ships with >> very old tools, and llvmc was generating assembler that worked with a >> fresh (gcc-4.5) compile& ?install. ?I had them handy, just further >> down the path. ?Hopefully anyone with the same problem can find this >> in the archive. >> > > I think llvm isn't ported to Solaris i386/x86_64 yet. Particularly, clang > there prints the same data layout string as on linux assuming ABI is the > same when it isn't. So using your approach certain calls to the externally > compiled libraries will cause failures. Some simpler examples may work fine. > > Yuri > From ofv at wanadoo.es Wed Feb 2 23:58:32 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Thu, 03 Feb 2011 06:58:32 +0100 Subject: [LLVMdev] Bitcode not portable from linux to solaris? References: <4D4A32AB.5010008@rawbw.com> Message-ID: <87k4hhek1j.fsf@wanadoo.es> Lally Singh writes: >> I think llvm isn't ported to Solaris i386/x86_64 yet. Particularly, clang >> there prints the same data layout string as on linux assuming ABI is the >> same when it isn't. So using your approach certain calls to the externally >> compiled libraries will cause failures. Some simpler examples may work fine. >> > Well, then I'm royally screwed. > > What would I have to add to make it work, if only for a very limited > subset of cases? Fixing the data layout is simple: 1. Read the LLVM Laguage Reference to learn how to format the data layout string. 2. Look up what's the actual data layout for your platform. 3. Implement the string in lib/Target/X86/X86TargetMachine.cpp The last step may require implementing some handling for the triplet of your platform, but if you are on a hurry and don't plan to contribute your changes to LLVM nor to generate code for other platforms an #ifdef will do. From baldrick at free.fr Thu Feb 3 02:53:49 2011 From: baldrick at free.fr (Duncan Sands) Date: Thu, 03 Feb 2011 09:53:49 +0100 Subject: [LLVMdev] Convenience methods in ConstantExpr et al In-Reply-To: References: <4D49CCD7.2000601@mxc.ca> Message-ID: <4D4A6D1D.4080706@free.fr> Hi Talin, > I find that I call the static methods in ConstantExpr a *lot* without going > through IRBuilder - hundreds of times in my frontend. My language generates a > lot of static data - reflection information, trace tables for the garbage > collector, dispatch tables, runtime annotations, static object instances, and so > on. (In fact there's a special helper class "StructBuilder" that automates a lot > of the work of building constant structs, such as adding the standard object > header and so on.) I think it would be better to create a ConstBuilder class rather than add stuff to ConstantExpr. Ciao, Duncan. From siarhei.siamashka at gmail.com Thu Feb 3 04:25:51 2011 From: siarhei.siamashka at gmail.com (Siarhei Siamashka) Date: Thu, 3 Feb 2011 12:25:51 +0200 Subject: [LLVMdev] ARM ELF target and the use of VFP/NEON instructions Message-ID: <201102031226.03668.siarhei.siamashka@gmail.com> Hi, I have submitted a bug some time ago to LLVM bugtracker: http://llvm.org/bugs/show_bug.cgi?id=8931 The problem is that I'm trying to use clang in linux system, running on ARM hardware. And this bug, as trivial as it is, seems to be a major showstopper. I wonder if I'm the only one trying to use LLVM/clang in this configuration or doing something in an unusual way? Anyway, the LLVM sources contain a comment "// FIXME: Emit FPU type", implying that emitting FPU type was actually planned. Would it be possible to fix this problem somehow? Being able to use clang in linux on ARM systems may provide additional testing coverage, so should be beneficial for LLVM project in the long run. Thanks. -- Best regards, Siarhei Siamashka -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110203/538fa816/attachment.bin From renato.golin at arm.com Thu Feb 3 06:14:28 2011 From: renato.golin at arm.com (Renato Golin) Date: Thu, 3 Feb 2011 12:14:28 +0000 Subject: [LLVMdev] ARM ELF target and the use of VFP/NEON instructions In-Reply-To: <201102031226.03668.siarhei.siamashka@gmail.com> References: <201102031226.03668.siarhei.siamashka@gmail.com> Message-ID: On 3 February 2011 10:25, Siarhei Siamashka wrote: > I have submitted a bug some time ago to LLVM bugtracker: > http://llvm.org/bugs/show_bug.cgi?id=8931 Hi Siarhei, This is a really silly bug with a simple fix. We have a similar patch here locally, but as this is part of another set of patches we were waiting for it to stabilise. There are some other build attributes that need to be set when you're using NEON or VFP, but I'll try to get them working without any other modification as a clean cut patch. I'll round it up and submit the patch. Thanks for reminding about it. cheers, --renato From ivop at euronet.nl Thu Feb 3 06:40:37 2011 From: ivop at euronet.nl (Ivo) Date: Thu, 3 Feb 2011 13:40:37 +0100 Subject: [LLVMdev] Target without registers Message-ID: <201102031340.37385.ivop@euronet.nl> Hi, Would it be possible to write a backend for a target without any registers, except for a stack pointer and a program counter (i.e. it only has memory to memory operations) and without simulating registers at fixed memory locations? Best regards, --Ivo From siarhei.siamashka at gmail.com Thu Feb 3 07:38:00 2011 From: siarhei.siamashka at gmail.com (Siarhei Siamashka) Date: Thu, 3 Feb 2011 15:38:00 +0200 Subject: [LLVMdev] ARM ELF target and the use of VFP/NEON instructions In-Reply-To: References: <201102031226.03668.siarhei.siamashka@gmail.com> Message-ID: <201102031538.05577.siarhei.siamashka@gmail.com> On Thursday 03 February 2011 14:14:28 Renato Golin wrote: > On 3 February 2011 10:25, Siarhei Siamashka wrote: > > I have submitted a bug some time ago to LLVM bugtracker: > > http://llvm.org/bugs/show_bug.cgi?id=8931 > > Hi Siarhei, > > This is a really silly bug with a simple fix. > > We have a similar patch here locally, but as this is part of another > set of patches we were waiting for it to stabilise. There are some > other build attributes that need to be set when you're using NEON or > VFP, but I'll try to get them working without any other modification > as a clean cut patch. > > I'll round it up and submit the patch. Thanks for reminding about it. OK, thanks. It's good to know that somebody is working on this. LLVM/clang is making a really good progress with the regards to ARM support and I'm looking forward to the next release. Other than this minor issue, clang 2.8 already looks quite good and can be used to successfully compile some real programs on ARM (and do this correctly enough to pass regression tests). -- Best regards, Siarhei Siamashka -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110203/a03bd65e/attachment.bin From jarkko.niittylahti at atostek.com Thu Feb 3 04:35:35 2011 From: jarkko.niittylahti at atostek.com (Jarkko Niittylahti) Date: Thu, 03 Feb 2011 12:35:35 +0200 Subject: [LLVMdev] Parallel and portable signal processing software by means of LLVM back-end Message-ID: <4D4A84F7.1050504@atostek.com> Dear LLVM developer. you might be interested in the parallel compiler results we have achieved with Nokia. The compiler back-end is LLVM. The compiled code performance is equal to manually optimized C with intrinsics on Intel and ARM platforms. On Cell its 2x slower due to the immature LLVM back-end. Performance is portable: the same source code serves as the functional reference and implementation on all platforms. Check this out: http://www.corentosystems.com/ For performance comparisons, see Nokia's invited presentation: http://www.corentosystems.com/sites/default/files/SoC2010 PortabilityOfSDR.pdf On the site forum, there is a question regarding .NET and LLVM. I wonder if any LLVM developer would be able to make a contribution to the discussion. Sincerely, Jarkko Niittylahti Atostek Ltd, Finland http://www.atostek.com/index.php?l=EN From vmle at ucdavis.edu Thu Feb 3 13:59:39 2011 From: vmle at ucdavis.edu (Vu Le) Date: Thu, 3 Feb 2011 11:59:39 -0800 Subject: [LLVMdev] Preserve RegionInfo after regionsimplify Message-ID: Hi Tobias, My RegionSimplify pass adds new exit node for refined regions to convert them into simple region. However, the RegionInfo pass does not seem to recognize those changes. For example, in the attached file, bb4.region is supposed to be in the first region. My RegionExtractor pass required the extracted region to be simple. Should we modify RegionInfo or is their away to preserve the RegionInfo from RegionSimplify and pass it to RegionExtractor? Thanks. Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110203/09c369ea/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: reg.main.dot.pdf Type: application/pdf Size: 32075 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110203/09c369ea/attachment.pdf From grosser at fim.uni-passau.de Thu Feb 3 14:12:59 2011 From: grosser at fim.uni-passau.de (Tobias Grosser) Date: Thu, 03 Feb 2011 15:12:59 -0500 Subject: [LLVMdev] Preserve RegionInfo after regionsimplify In-Reply-To: References: Message-ID: <4D4B0C4B.8030609@fim.uni-passau.de> On 02/03/2011 02:59 PM, Vu Le wrote: > Hi Tobias, > My RegionSimplify pass adds new exit node for refined regions to convert > them into simple region. > However, the RegionInfo pass does not seem to recognize those changes. > For example, in the attached file, bb4.region is supposed to be in the > first region. > > My RegionExtractor pass required the extracted region to be simple. > Should we modify RegionInfo or is their away to preserve the RegionInfo > from RegionSimplify and pass it to RegionExtractor? RegionInfo only detects canonical regions and the region containing bb4.region is not canonical any more. So if the RegionInfo is recalculated from scratch it might again contain non simple regions. I see two approaches: * Define a RegionInfo pass that detects only simple regions. This can be used to recalculate the region tree from the CFG. If we only take simple regions into account, the region you want to have is canonical. * Preserve the RegionInfo after your RegionSimplify pass. In your RegionSimplify pass you already create a RegionTree that only contains simple regions. Just state that your pass preserves RegionInfo and DominatorTree and there is no need to recalculate RegionInfo. I believe approach two is probably the easiest. Check 'opt -debug-pass=Structure -regionsimplify -regionextractor file..' and see if the RegionInfo is recalulated. Try to not recalculate it. Tobi From yuri at rawbw.com Thu Feb 3 14:16:31 2011 From: yuri at rawbw.com (Yuri) Date: Thu, 03 Feb 2011 12:16:31 -0800 Subject: [LLVMdev] Why 'target datalayout' strings are in .ll modules? Message-ID: <4D4B0D1F.4040705@rawbw.com> What is the meaning of 'target datalayout' being in .ll in addition to 'target triple'? When it can be meaningfully changed having the same 'target triple'? As I understand llvm derives most of architecture-specific information from 'target triple'. For example ABI used by llvm is keyed to 'target triple'. But some parts of ABI are in 'target datalayout'. For example, on MacOS the fact from ABI that all stacks are always 16-aligned during procedure call is defined in 'target datalayout', not by 'target datalayout' like most other parts of ABI. So why 'target datalayout' is exposed in .ll? Yuri From viridia at gmail.com Thu Feb 3 14:41:53 2011 From: viridia at gmail.com (Talin) Date: Thu, 3 Feb 2011 12:41:53 -0800 Subject: [LLVMdev] Convenience methods in ConstantExpr et al In-Reply-To: <4D4A6D1D.4080706@free.fr> References: <4D49CCD7.2000601@mxc.ca> <4D4A6D1D.4080706@free.fr> Message-ID: On Thu, Feb 3, 2011 at 12:53 AM, Duncan Sands wrote: > Hi Talin, > > > I find that I call the static methods in ConstantExpr a *lot* without > going > > through IRBuilder - hundreds of times in my frontend. My language > generates a > > lot of static data - reflection information, trace tables for the garbage > > collector, dispatch tables, runtime annotations, static object instances, > and so > > on. (In fact there's a special helper class "StructBuilder" that > automates a lot > > of the work of building constant structs, such as adding the standard > object > > header and so on.) > > I think it would be better to create a ConstBuilder class rather than add > stuff > to ConstantExpr. > OK I'll do that. A few questions: 1) Capitalize method names or not? I see both styles - the style guide says lower case, but it appears that the newer code is using capitalized method names. 2) Should methods be named "CreateXXX" (like IRBuilder) or "GetXXX" (like ConstantExpr). 3) Should method comments use @brief or repeat the method name - I see both styles in the code. > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110203/f3ede04c/attachment.html From viridia at gmail.com Fri Feb 4 03:10:14 2011 From: viridia at gmail.com (Talin) Date: Fri, 4 Feb 2011 01:10:14 -0800 Subject: [LLVMdev] How to replace a global variable to one with a different type? Message-ID: I'm experimenting with "replaceAllUsesWith" and I see that it requires that the replacement be the same type. Here's what I am trying to do: Say I have a global variable A whose type is [10 x Foo]. The only references to A are via GEPs which get a pointer to the first element: GEP(A, 0, 0), so in other words no user of A knows the length of the array from the type. Now I want to replace A with A', which is exactly the same except that it has a different array length. I want to remove all references to the original A. I can't use replaceAllUsesWith, because A and A' have different types. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110204/5ce9b6b7/attachment.html From baldrick at free.fr Fri Feb 4 04:38:23 2011 From: baldrick at free.fr (Duncan Sands) Date: Fri, 04 Feb 2011 11:38:23 +0100 Subject: [LLVMdev] How to replace a global variable to one with a different type? In-Reply-To: References: Message-ID: <4D4BD71F.3000904@free.fr> Hi Talin, > I'm experimenting with "replaceAllUsesWith" and I see that it requires that the > replacement be the same type. > > Here's what I am trying to do: Say I have a global variable A whose type is [10 > x Foo]. The only references to A are via GEPs which get a pointer to the first > element: GEP(A, 0, 0), so in other words no user of A knows the length of the > array from the type. > > Now I want to replace A with A', which is exactly the same except that it has a > different array length. I want to remove all references to the original A. I > can't use replaceAllUsesWith, because A and A' have different types. first generate a (constexpr) bitcast of A' to [10 x Foo]*, then do RAUW of A with the bitcast. Ciao, Duncan. From junk at giantblob.com Fri Feb 4 05:37:19 2011 From: junk at giantblob.com (James Williams) Date: Fri, 4 Feb 2011 11:37:19 +0000 Subject: [LLVMdev] Fw: Compile function with limited set of registers? Jump to another function? In-Reply-To: <754859.96007.qm@web62004.mail.re1.yahoo.com> References: <754859.96007.qm@web62004.mail.re1.yahoo.com> Message-ID: Hi Sam, Thanks for this + sorry for not replying earlier. I'm afraid I'm not sure I've understood your advice. I have a working implementation for interfaces with inheritance - I use constant negative indexes into class vtables for class methods that implement methods in interfaces. These indexes are allocated at compile time either via graph coloring (if whole program is compiled as a unit) or by hashing method signatures (if parts of program are compiled separately). Any collisions arising from the hashing method are resolved on method call by thunks in any vtable slots hashed to by more than one selector. Advantages of this mechanism are it's as fast as regular virtual method dispatch (except in the method signature hash collision case) and that there is no difference between calls through objects and calls through interfaces (in fact there are no interfaces as such at runtime, only references to regular objects) What I'm looking to do is speed up the thunk that's called when two or more interface method signatures hash to the same slot in the vtable. Currently it just does a linear search over a compile time generated table of selector ids->method address. I think common improvements are using a self ordering list or using a binary search. My conclusion is that I could probably use LLVM to generate a thunk to resolve each vtable collision to do a binary search over the expected method signatures, providing I use varargs calling convention. I'll need to do some profiling to determine if this is worthwhile, given the overhead of adding an additional parameter to both all calls to methods interfaces and methods in classes that implement methods in interfaces. -- James. On 31 January 2011 22:28, Samuel Crow wrote: > Forgot to cc the list. > > > ----- Forwarded Message ---- > *From:* Samuel Crow > *To:* James Williams > *Sent:* Mon, January 31, 2011 4:27:45 PM > *Subject:* Re: [LLVMdev] Compile function with limited set of registers? > Jump to another function? > > Hi James, > > If you're looking for a way to implement interface inheritance, I think the > easiest way is to use double-indirection. It's slow but it does the job. > You just use an array to hold the interface and have each entry point to > the vtable entry for the appropriate functions in the class. Then you can > treat the interface as a read-only class once the constructor is run and the > interface will assign its values when the class is allocated before the > invocation of the actual constructor. > > The faster way to implement interfaces is with generics but that generates > bigger code. > > I hope this answers your question, > > --Sam > > > *From:* James Williams > *To:* joshuawarner32 at gmail.com > *Cc:* llvmdev at cs.uiuc.edu > *Sent:* Mon, January 31, 2011 4:01:24 PM > *Subject:* Re: [LLVMdev] Compile function with limited set of registers? > Jump to another function? > > Thanks, that's a good idea - I'll have a look through the VMKit source. > > -- James > > On 31 January 2011 21:39, Joshua Warner wrote: > >> Hi James, >> >> I see the problem now. You might look at VMKit (a Java VM build with the >> LLVM JIT compiler) - I would expect it uses a similar method for resolving >> interface calls (the method, if I understand it correctly, is well-known in >> the Java world). >> >> I've CC'd the main dev behind VMKit - he might be able to lend some >> insight. >> >> --Joshua >> >> On Mon, Jan 31, 2011 at 2:24 PM, James Williams wrote: >> >>> Hi Joshua, >>> >>> Thanks - I was hoping that would be the case. >>> >>> However, I've had a think about this since I posted to the list and I >>> believe the only way to handle these issues safely in LLVM IR would be to >>> define the thunk as varargs. I'm not sure how well LLVM handles varargs but >>> ideally it would all compile down to nothing since the parameters to the the >>> thunk would be in the same registers/stack locations as required by the >>> target method. >>> >>> Unfortunately, varargs has some downsides: there's the additional >>> overhead for the extra hidden parameter to every interface method call for >>> the parameter count plus it doesn't (I don't think) support tail calls. >>> >>> -- James >>> >>> >>> On 27 January 2011 17:37, Joshua Warner wrote: >>> >>>> Hi James, >>>> >>>> I'm no expert in LLVM IR, but I think that just encoding each *actual* >>>> method invocation in the thunk as a tail call would work. This would >>>> require trusting that LLVM passes / code generators will translate down to a >>>> jump, as is normal. If the passes / code generators are smart, I see no >>>> reason that LLVM wouldn't emit code that fits your requirements. Either >>>> way, you know that your thunk will be correct - it just might not be as >>>> efficient as you want. >>>> >>>> I would suggest experimenting with generating a thunk this way, and look >>>> at the resultant target assembly to make sure it's doing what you want. >>>> >>>> -Joshua >>>> >>>> On Tue, Jan 25, 2011 at 2:04 AM, James Williams wrote: >>>> >>>>> Hi, >>>>> >>>>> Can anyone tell me, is it possible to express in LLVM IR: >>>>> - that, for a specific function, register allocator can use only >>>>> limited set of registers? (specifically, cannot touch any registers that >>>>> might contain parameters) >>>>> - that stack can't be touched? (or at least must balance on exit from >>>>> thunk) >>>>> - jump, not call, to another function leaving any received parameters >>>>> unchanged in registers and on stack? >>>>> >>>>> Thanks, >>>>> -- James Williams >>>>> >>>>> Background: >>>>> >>>>> I'm looking for some advice on implementing thunks required by my >>>>> language's interface call mechanism. This is a fairly conventional >>>>> arrangement where method selectors in interfaces are hashed to determine >>>>> their index within a vtable and hash collisions are disambiguated at runtime >>>>> by a thunk, which determines which method to call from a selector id passed >>>>> as the first method parameter. >>>>> >>>>> I'm currently using a single thunk (written in assembly) for all >>>>> collisions that walks a table to determine what method to call. This works >>>>> but it's inefficient and requires the a hand written thunk for each >>>>> supported target. >>>>> >>>>> I'd like to instead generate IR for a specific thunk for each vtable >>>>> collisoin that does a binary search of possible selectors because this will >>>>> avoid some pointer dereferences and an additional indirect call. >>>>> >>>>> The problem is that a thunk may need to decide between methods with >>>>> different signatures without disturbing parameters in registers and on the >>>>> stack and then jump to, rather than call, another function: >>>>> >>>>> interface X: >>>>> method A(a, b) >>>>> >>>>> interface Y: >>>>> method B(c, d, e) >>>>> >>>>> class Z implements X, y: >>>>> method A(a, b) ... >>>>> method B(c, d, e) ... >>>>> >>>>> X.A + Y.B happen to hash to same vtable index, say -3 >>>>> >>>>> This would require a thunk something like: >>>>> >>>>> vtable[-3] = >>>>> thunk_Z_AorB(selector_id, ...) >>>>> // binary search for matching selector id: >>>>> if selector_id <= selector_Z_A then >>>>> Z.A(selector_id, ...) >>>>> else >>>>> Z.B(selector_id, ...) >>>>> fi >>>>> >>>>> which would ideally would compile on x64 to something like: >>>>> >>>>> thunk_Z_AorB: >>>>> cmp $selector_Z_A, %rdi >>>>> jle Z.A >>>>> jmp Z.B >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20110204/255f0f46/attachment.html From junk at giantblob.com Fri Feb 4 05:43:09 2011 From: junk at giantblob.com (James Williams) Date: Fri, 4 Feb 2011 11:43:09 +0000 Subject: [LLVMdev] Compile function with limited set of registers? Jump to another function? In-Reply-To: References: Message-ID: Hi Nicholas, Yes - that's exactly the paper got the idea from! I suspect it's still not possible to do this in LLVM IR (without using varargs, which adds some overhead). However, it may be possible to use the new machine code stuff although I'd obviously need to recode the binary search generation for each supported target. -- James On 2 February 2011 07:32, nicolas geoffray wrote: > Hi James, > > Joshua is right, what you're trying to accomplish is quite known in the > Java VM world ( > http://domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.oopsla01.html > ). > > In order to express the "thunk" code in LLVM you need a full control of how > registers are used (because otherwise they would mess up with the > arguments). I haven't investigated enough to know if that's possible today > in LLVM (I think it wasn't a few years ago when I added the optimization). > So what I ended up with was a generic IR that walks the interface table of > an object and detects collisions. The IR was inline in the caller to make > sure that arguments in registers are not overriden. > > This may not be the best approach today, but I believe it was the easiest > way to have something efficient at that point. > > Cheers, > Nicolas > > > On Mon, Jan 31, 2011 at 11:01 PM, James Williams wrote: > >> Thanks, that's a good idea - I'll have a look through the VMKit source. >> >> -- James >> >> >> On 31 January 2011 21:39, Joshua Warner wrote: >> >>> Hi James, >>> >>> I see the problem now. You might look at VMKit (a Java VM build with the >>> LLVM JIT compiler) - I would expect it uses a similar method for resolving >>> interface calls (the method, if I understand it correctly, is well-known in >>> the Java world). >>> >>> I've CC'd the main dev behind VMKit - he might be able to lend some >>> insight. >>> >>> --Joshua >>> >>> On Mon, Jan 31, 2011 at 2:24 PM, James Williams wrote: >>> >>>> Hi Joshua, >>>> >>>> Thanks - I was hoping that would be the case. >>>> >>>> However, I've had a think about this since I posted to the list and I >>>> believe the only way to handle these issues safely in LLVM IR would be to >>>> define the thunk as varargs. I'm not sure how well LLVM handles varargs but >>>> ideally it would all compile down to nothing since the parameters to the the >>>> thunk would be in the same registers/stack locations as required by the >>>> target method. >>>> >>>> Unfortunately, varargs has some downsides: there's the additional >>>> overhead for the extra hidden parameter to every interface method call for >>>> the parameter count plus it doesn't (I don't think) support tail calls. >>>> >>>> -- James >>>> >>>> >>>> On 27 January 2011 17:37, Joshua Warner wrote: >>>> >>>>> Hi James, >>>>> >>>>> I'm no expert in LLVM IR, but I think that just encoding each *actual* >>>>> method invocation in the thunk as a tail call would work. This would >>>>> require trusting that LLVM passes / code generators will translate down to a >>>>> jump, as is normal. If the passes / code generators are smart, I see no >>>>> reason that LLVM wouldn't emit code that fits your requirements. Either >>>>> way, you know that your thunk will be correct - it just might not be as >>>>> efficient as you want. >>>>> >>>>> I would suggest experimenting with generating a thunk this way, and >>>>> look at the resultant target assembly to make sure it's doing what you want. >>>>> >>>>> -Joshua >>>>> >>>>> On Tue, Jan 25, 2011 at 2:04 AM, James Williams wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Can anyone tell me, is it possible to express in LLVM IR: >>>>>> - that, for a specific function, register allocator can use only >>>>>> limited set of registers? (specifically, cannot touch any registers that >>>>>> might contain parameters) >>>>>> - that stack can't be touched? (or at least must balance on exit >>>>>> from thunk) >>>>>> - jump, not call, to another function leaving any received >>>>>> parameters unchanged in registers and on stack? >>>>>> >>>>>> Thanks, >>>>>> -- James Williams >>>>>> >>>>>> Background: >>>>>> >>>>>> I'm looking for some advice on implementing thunks required by my >>>>>> language's interface call mechanism. This is a fairly conventional >>>>>> arrangement where method selectors in interfaces are hashed to determine >>>>>> their index within a vtable and hash collisions are disambiguated at runtime >>>>>> by a thunk, which determines which method to call from a selector id passed >>>>>> as the first method parameter. >>>>>> >>>>>> I'm currently using a single thunk (written in assembly) for all >>>>>> collisions that walks a table to determine what method to call. This works >>>>>> but it's inefficient and requires the a hand written thunk for each >>>>>> supported target. >>>>>> >>>>>> I'd like to instead generate IR for a specific thunk for each vtable >>>>>> collisoin that does a binary search of possible selectors because this will >>>>>> avoid some pointer dereferences and an additional indirect call. >>>>>> >>>>>> The problem is that a thunk may need to decide between methods with >>>>>> different signatures without disturbing parameters in registers and on the >>>>>> stack and then jump to, rather than call, another function: >>>>>> >>>>>> interface X: >>>>>> method A(a, b) >>>>>> >>>>>> interface Y: >>>>>> method B(c, d, e) >>>>>> >>>>>> class Z implements X, y: >>>>>> method A(a, b) ... >>>>>> method B(c, d, e) ... >>>>>> >>>>>> X.A + Y.B happen to hash to same vtable index, say -3 >>>>>> >>>>>> This would require a thunk something like: >>>>>> >>>>>> vtable[-3] = >>>>>> thunk_Z_AorB(selector_id, ...) >>>>>> // binary search for matching selector id: >>>>>> if selector_id <= selector_Z_A then >>>>>> Z.A(selector_id, ...) >>>>>> else >>>>>> Z.B(selector_id, ...) >>>>>> fi >>>>>> >>>>>> which would ideally would compile on x64 to something like: >>>>>> >>>>>> thunk_Z_AorB: >>>>>> cmp $selector_Z_A, %rdi >>>>>> jle Z.A >>>>>> jmp Z.B >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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/20110204/92a3626d/attachment-0001.html From stroeder at informatik.rwth-aachen.de Fri Feb 4 08:39:24 2011 From: stroeder at informatik.rwth-aachen.de (=?ISO-8859-15?Q?Thomas_Str=F6der?=) Date: Fri, 04 Feb 2011 15:39:24 +0100 Subject: [LLVMdev] Data layout of structs Message-ID: <4D4C0F9C.8080902@informatik.rwth-aachen.de> Dear all, I'm currently working on the automated program analysis tool AProVE (http://aprove.informatik.rwth-aachen.de/) and would like to use LLVM for analysis of C programs. I have the following example C program dealing with simple lists of integers: ------------ start C example ------------- #include struct list_el { int val; struct list_el * next; }; typedef struct list_el item; void test(int length) { item * curr, * head; int i; head = NULL; for(i=1;i<=length;i++) { curr = (item *)malloc(sizeof(item)); curr->val = i; curr->next = head; head = curr; } curr = head; while(curr) { curr = curr->next; } } ------------ end C example ------------- The output I get from the LLVM web interface is: ------------ start LLVM output ------------- ; ModuleID = '/tmp/webcompile/_27083_0.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-n8:16:32:64" target triple = "x86_64-linux-gnu" %struct.item = type { i32, %struct.item* } define void @test(i32 %length) nounwind { entry: %0 = icmp slt i32 %length, 1 ; [#uses=1] br i1 %0, label %return, label %bb bb: ; preds = %bb, %entry %indvar = phi i32 [ %i.08, %bb ], [ 0, %entry ] ; [#uses=2] %head.07 = phi %struct.item* [ %2, %bb ], [ null, %entry ] ; <%struct.item*> [#uses=1] %i.08 = add i32 %indvar, 1 ; [#uses=2] %1 = tail call noalias i8* @malloc(i64 16) nounwind ; [#uses=3] %2 = bitcast i8* %1 to %struct.item* ; <%struct.item*> [#uses=3] %3 = bitcast i8* %1 to i32* ; [#uses=1] store i32 %i.08, i32* %3, align 8 %4 = getelementptr inbounds i8* %1, i64 8 ; [#uses=1] %5 = bitcast i8* %4 to %struct.item** ; <%struct.item**> [#uses=1] store %struct.item* %head.07, %struct.item** %5, align 8 %tmp = add i32 %indvar, 2 ; [#uses=1] %6 = icmp sgt i32 %tmp, %length ; [#uses=1] br i1 %6, label %bb4.preheader, label %bb bb4.preheader: ; preds = %bb %7 = icmp eq %struct.item* %2, null ; [#uses=1] br i1 %7, label %return, label %bb3 bb3: ; preds = %bb3, %bb4.preheader %curr.06 = phi %struct.item* [ %9, %bb3 ], [ %2, %bb4.preheader ] ; <%struct.item*> [#uses=1] %8 = getelementptr inbounds %struct.item* %curr.06, i64 0, i32 1 ; <%struct.item**> [#uses=1] %9 = load %struct.item** %8, align 8 ; <%struct.item*> [#uses=2] %10 = icmp eq %struct.item* %9, null ; [#uses=1] br i1 %10, label %return, label %bb3 return: ; preds = %bb3, %bb4.preheader, %entry ret void } declare noalias i8* @malloc(i64) nounwind ------------ end LLVM output ------------- Now my problem is as follows. The pointer %4 (pointing to the second field in the list element) is calculated by going 8 byte further in memory. However, i32 only has a size of 4 byte. What is the reason for the struct having the data layout of two times 8 bytes instead of having 4 bytes for the integer and 8 bytes for the pointer to the next element? Is there a general rule for the data layout of structs in LLVM? Thank you, Thomas -- Thomas Str?der mailto:stroeder at informatik.rwth-aachen.de LuFG Informatik 2 http://verify.rwth-aachen.de/stroeder RWTH Aachen phone: +49 241 80-21241 From ofv at wanadoo.es Fri Feb 4 09:00:54 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Fri, 04 Feb 2011 16:00:54 +0100 Subject: [LLVMdev] Data layout of structs References: <4D4C0F9C.8080902@informatik.rwth-aachen.de> Message-ID: <871v3neteh.fsf@wanadoo.es> Thomas Str?der writes: > 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-linux-gnu" [snip] > Now my problem is as follows. The pointer %4 (pointing to the second > field in the list element) is calculated by going 8 byte further in > memory. However, i32 only has a size of 4 byte. What is the reason > for the struct having the data layout of two times 8 bytes instead > of having 4 bytes for the integer and 8 bytes for the pointer to the > next element? See the datalayout string: p:64:64:64 that means that pointers are aligned to 64 bit boundaries. Your struct ends being like this: offset bytes 0-3 : int data member offset bytes 4-7 : padding offset bytes 8-15: pointer data member > Is there a general rule for the data layout of structs in LLVM? LLVM follows the platform's C ABI, in this case x86_64-linux. That's hard-coded. Don't be lured by Module::setDataLayout. From falke at iti.uka.de Fri Feb 4 09:16:34 2011 From: falke at iti.uka.de (Stephan Falke) Date: Fri, 04 Feb 2011 16:16:34 +0100 Subject: [LLVMdev] Data layout of structs In-Reply-To: <4D4C0F9C.8080902@informatik.rwth-aachen.de> References: <4D4C0F9C.8080902@informatik.rwth-aachen.de> Message-ID: <4D4C1852.9030104@iti.uka.de> Hi Thomas, > Now my problem is as follows. The pointer %4 (pointing to the second > field in the list element) is calculated by going 8 byte further in > memory. However, i32 only has a size of 4 byte. What is the reason > for the struct having the data layout of two times 8 bytes instead > of having 4 bytes for the integer and 8 bytes for the pointer to the > next element? Is there a general rule for the data layout of structs > in LLVM? There is no general rule except that the layout is target dependent... TargetData::getStructLayout will give you the StructLayout for a given StructType. StructLayout::getElementOffset then gives you the offset in bytes for an element. In your case, getElementOffset(1) should return 8. The "deeper" reason is that pointers in x86_64 Linux are 8-byte aligned. Hope this helps, Stephan From cafxx at strayorange.com Fri Feb 4 09:57:29 2011 From: cafxx at strayorange.com (Carlo Alberto Ferraris) Date: Fri, 04 Feb 2011 16:57:29 +0100 Subject: [LLVMdev] CPS Message-ID: <4D4C21E9.3000109@strayorange.com> Hi everybody, I'd like to try implementing a pass that transforms all functions (and function calls, returns, etc.) to CPS, so that TCO can get rid of all (or most of) the function calling overhead (because, as you probably know, the side effect of using CPS is that all function calls become tail calls). That being said, and since I'm pretty new to LLVM, I'd like to ask a couple of things to the veterans: 1. Can you see anything really wrong with the general idea of having such a transformation? 2. Has anybody worked on something like this in the past? Are there any starting points you'd suggest I should take a look at? 3. Do you have any advice about which direction should I take? B.R., Carlo Alberto Ferraris From viridia at gmail.com Fri Feb 4 11:57:31 2011 From: viridia at gmail.com (Talin) Date: Fri, 4 Feb 2011 09:57:31 -0800 Subject: [LLVMdev] ConstantBuilder proposal Message-ID: Here's a sketch of what I am proposing for ConstantBuilder. I'd like feedback on naming conventions, doc comments, etc. //===-- llvm/Support/ConstantBuilder.h - Builder for Constants --*- C++ -*-===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // //===----------------------------------------------------------------------===// // // This file defines the ConstantBuilder class, which is used as a convenient // way to create LLVM Constants with a consistent and simplified interface. // //===----------------------------------------------------------------------===// #ifndef LLVM_SUPPORT_CONSTANTBUILDER_H #define LLVM_SUPPORT_CONSTANTBUILDER_H #include "llvm/Constants.h" #include "llvm/DerivedTypes.h" namespace llvm { /// ConstantBuilder - This provides a uniform API for creating constants. class ConstantBuilder { public: //===--------------------------------------------------------------------===// // Constant arrays //===--------------------------------------------------------------------===// /// GetArray - return a constant array given an array type and a vector /// of elements. static Constant *GetArray( const ArrayType *Ty, ///< The type of the array const std::vector &V) { ///< The elements of the array return ConstantArray::get(Ty, V); } /// GetArray - return a constant array given an array type and a POD /// array of elements. static Constant *GetArray( const ArrayType *Ty, ///< The type of the array Constant *const *Vals, ///< The elements of the array unsigned NumVals) { ///< The length of the array return ConstantArray::get(Ty, Vals, NumVals); } /// GetArray - return a constant array given an array type and an /// iterator pair template static Constant *GetArray( const ArrayType *Ty, ///< The type of the array RandomAccessIterator ArgBegin, ///< Iterator for the first element RandomAccessIterator ArgEnd) { ///< The elements of the array return GetArray(Ty, &ArgBegin[0], ArgEnd - ArgBegin); } /// GetArrayOf - return a constant array given an element type and a vector /// of elements. static Constant *GetArrayOf( const Type *ElementTy, ///< The type of the array elements const std::vector &V) { ///< The elements of the array return GetArray(ArrayType::get(ElementTy, (uint64_t) V.size()), V); } /// GetArrayOf - return a constant array given an element type and a POD /// array of elements. static Constant *GetArrayOf( const Type *ElementTy, ///< The type of the array elements Constant *const *Vals, ///< The elements of the array unsigned NumVals) { ///< The length of the array return GetArray(ArrayType::get(ElementTy, NumVals), Vals, NumVals); } /// GetArrayOf - return a constant array given an element type and an /// iterator pair template static Constant *GetArrayOf( const Type *ElementTy, ///< The type of the array elements RandomAccessIterator ArgBegin, ///< Iterator for the first element RandomAccessIterator ArgEnd) { ///< The elements of the array return GetArray( ArrayType::get(ElementTy, ArgEnd - ArgBegin), ArgBegin, ArgEnd); } //===--------------------------------------------------------------------===// // Constant structs //===--------------------------------------------------------------------===// /// GetStruct - return a constant struct given a struct type and a vector /// of elements. static Constant *GetStruct( const StructType *Ty, const std::vector &V) { return ConstantStruct::get(Ty, V); } /// GetStruct - return a constant struct given a context and a vector /// of elements. static Constant *GetStruct( LLVMContext &Context, const std::vector &V, bool Packed = false) { return ConstantStruct::get(Context, V, Packed); } /// GetStruct - return a constant struct given a context and a POD /// array of elements. static Constant *GetStruct( LLVMContext &Context, Constant *const *Vals, unsigned NumVals, bool Packed = false) { return ConstantStruct::get(Context, Vals, NumVals, Packed); } /// GetStruct - return a constant struct given a context and an iterator /// pair. template static Constant *GetStruct( LLVMContext &Context, RandomAccessIterator ArgBegin, ///< Iterator for the first element RandomAccessIterator ArgEnd) { ///< The elements of the array return GetStruct(Context, &ArgBegin[0], ArgEnd - ArgBegin); } /// GetStruct - return a constant struct given a variable number of elements, /// ending with NULL. static Constant *GetStruct( LLVMContext &Context, Constant * Val, ...) END_WITH_NULL; //===--------------------------------------------------------------------===// // Constant expressions //===--------------------------------------------------------------------===// /// GetAlignOf constant expr - computes the alignment of a type in a target /// independent way (Note: the return type is an i64). static Constant *GetAlignOf(const Type* Ty) { return ConstantExpr::getAlignOf(Ty); } /// GetSizeOf constant expr - computes the (alloc) size of a type (in /// address-units, not bits) in a target independent way (Note: the return /// type is an i64). /// static Constant *GetSizeOf(const Type* Ty) { return ConstantExpr::getSizeOf(Ty); } /// GetOffsetOf constant expr - computes the offset of a struct field in a /// target independent way (Note: the return type is an i64). /// static Constant *GetOffsetOf(const StructType* STy, unsigned FieldNo) { return ConstantExpr::getOffsetOf(STy, FieldNo); } /// GetOffsetOf constant expr - This is a generalized form of GetOffsetOf, /// which supports any aggregate type, and any Constant index. /// static Constant *GetOffsetOf(const Type* Ty, Constant *FieldNo) { return ConstantExpr::getOffsetOf(Ty, FieldNo); } static Constant *GetNeg(Constant *C) { return ConstantExpr::getNeg(C); } static Constant *GetFNeg(Constant *C) { return ConstantExpr::getFNeg(C); } static Constant *GetNot(Constant *C) { return ConstantExpr::getNot(C); } static Constant *GetAdd(Constant *C1, Constant *C2) { return ConstantExpr::getAdd(C1, C2); } static Constant *GetFAdd(Constant *C1, Constant *C2) { return ConstantExpr::getFAdd(C1, C2); } static Constant *GetSub(Constant *C1, Constant *C2) { return ConstantExpr::getSub(C1, C2); } static Constant *GetFSub(Constant *C1, Constant *C2) { return ConstantExpr::getFSub(C1, C2); } static Constant *GetMul(Constant *C1, Constant *C2) { return ConstantExpr::getMul(C1, C2); } static Constant *GetFMul(Constant *C1, Constant *C2) { return ConstantExpr::getFMul(C1, C2); } static Constant *GetUDiv(Constant *C1, Constant *C2) { return ConstantExpr::getUDiv(C1, C2); } static Constant *GetSDiv(Constant *C1, Constant *C2) { return ConstantExpr::getSDiv(C1, C2); } static Constant *GetFDiv(Constant *C1, Constant *C2) { return ConstantExpr::getFDiv(C1, C2); } static Constant *GetURem(Constant *C1, Constant *C2) { return ConstantExpr::getURem(C1, C2); } static Constant *GetSRem(Constant *C1, Constant *C2) { return ConstantExpr::getSRem(C1, C2); } static Constant *GetFRem(Constant *C1, Constant *C2) { return ConstantExpr::getFRem(C1, C2); } static Constant *GetAnd(Constant *C1, Constant *C2) { return ConstantExpr::getAnd(C1, C2); } static Constant *GetOr(Constant *C1, Constant *C2) { return ConstantExpr::getOr(C1, C2); } static Constant *GetXor(Constant *C1, Constant *C2) { return ConstantExpr::getXor(C1, C2); } static Constant *GetShl(Constant *C1, Constant *C2) { return ConstantExpr::getShl(C1, C2); } static Constant *GetLShr(Constant *C1, Constant *C2) { return ConstantExpr::getLShr(C1, C2); } static Constant *GetAShr(Constant *C1, Constant *C2) { return ConstantExpr::getAShr(C1, C2); } static Constant *GetTrunc(Constant *C, const Type *Ty) { return ConstantExpr::getTrunc(C, Ty); } static Constant *GetSExt(Constant *C, const Type *Ty) { return ConstantExpr::getSExt(C, Ty); } static Constant *GetZExt(Constant *C, const Type *Ty) { return ConstantExpr::getZExt(C, Ty); } static Constant *GetFPTrunc(Constant *C, const Type *Ty) { return ConstantExpr::getFPTrunc(C, Ty); } static Constant *GetFPExtend(Constant *C, const Type *Ty) { return ConstantExpr::getFPExtend(C, Ty); } static Constant *GetUIToFP(Constant *C, const Type *Ty) { return ConstantExpr::getUIToFP(C, Ty); } static Constant *GetSIToFP(Constant *C, const Type *Ty) { return ConstantExpr::getSIToFP(C, Ty); } static Constant *GetFPToUI(Constant *C, const Type *Ty) { return ConstantExpr::getFPToUI(C, Ty); } static Constant *GetFPToSI(Constant *C, const Type *Ty) { return ConstantExpr::getFPToSI(C, Ty); } static Constant *GetPtrToInt(Constant *C, const Type *Ty) { return ConstantExpr::getPtrToInt(C, Ty); } static Constant *GetIntToPtr(Constant *C, const Type *Ty) { return ConstantExpr::getIntToPtr(C, Ty); } static Constant *GetBitCast(Constant *C, const Type *Ty) { return ConstantExpr::getBitCast(C, Ty); } static Constant *GetNSWNeg(Constant *C) { return ConstantExpr::getNSWNeg(C); } static Constant *GetNUWNeg(Constant *C) { return ConstantExpr::getNUWNeg(C); } static Constant *GetNSWAdd(Constant *C1, Constant *C2) { return ConstantExpr::getNSWAdd(C1, C2); } static Constant *GetNUWAdd(Constant *C1, Constant *C2) { return ConstantExpr::getNUWAdd(C1, C2); } static Constant *GetNSWSub(Constant *C1, Constant *C2) { return ConstantExpr::getNSWSub(C1, C2); } static Constant *GetNUWSub(Constant *C1, Constant *C2) { return ConstantExpr::getNUWSub(C1, C2); } static Constant *GetNSWMul(Constant *C1, Constant *C2) { return ConstantExpr::getNSWMul(C1, C2); } static Constant *GetNUWMul(Constant *C1, Constant *C2) { return ConstantExpr::getNUWMul(C1, C2); } static Constant *GetExactSDiv(Constant *C1, Constant *C2) { return ConstantExpr::getExactSDiv(C1, C2); } // @brief Convenience function for getting one of the casting operations // using a CastOps opcode. static Constant *GetCast( unsigned ops, ///< The opcode for the conversion Constant *C, ///< The constant to be converted const Type *Ty ///< The type to which the constant is converted ) { return ConstantExpr::getCast(ops, C, Ty); } // @brief Create a ZExt or BitCast cast constant expression static Constant *GetZExtOrBitCast( Constant *C, ///< The constant to zext or bitcast const Type *Ty ///< The type to zext or bitcast C to ) { return ConstantExpr::getZExtOrBitCast(C, Ty); } // @brief Create a SExt or BitCast cast constant expression static Constant *GetSExtOrBitCast( Constant *C, ///< The constant to sext or bitcast const Type *Ty ///< The type to sext or bitcast C to ) { return ConstantExpr::getSExtOrBitCast(C, Ty); } // @brief Create a Trunc or BitCast cast constant expression static Constant *GetTruncOrBitCast( Constant *C, ///< The constant to trunc or bitcast const Type *Ty ///< The type to trunc or bitcast C to ) { return ConstantExpr::getTruncOrBitCast(C, Ty); } /// @brief Create a BitCast or a PtrToInt cast constant expression static Constant *GetPointerCast( Constant *C, ///< The pointer value to be casted (operand 0) const Type *Ty ///< The type to which cast should be made ) { return ConstantExpr::getPointerCast(C, Ty); } /// @brief Create a ZExt, Bitcast or Trunc for integer -> integer casts static Constant *GetIntegerCast( Constant *C, ///< The integer constant to be casted const Type *Ty, ///< The integer type to cast to bool isSigned ///< Whether C should be treated as signed or not ) { return ConstantExpr::getIntegerCast(C, Ty, isSigned); } /// @brief Create a FPExt, Bitcast or FPTrunc for fp -> fp casts static Constant *GetFPCast( Constant *C, ///< The integer constant to be casted const Type *Ty ///< The integer type to cast to ) { return ConstantExpr::getFPCast(C, Ty); } /// Select constant expr static Constant *GetSelect(Constant *C, Constant *V1, Constant *V2) { return ConstantExpr::getSelect(C, V1, V2); } /// @brief Return an ICmp or FCmp comparison operator constant expression. static Constant *GetCompare(unsigned short pred, Constant *C1, Constant *C2) { return ConstantExpr::getCompare(pred, C1, C2); } static Constant *GetICmp(unsigned short pred, Constant *C1, Constant *C2) { return ConstantExpr::getICmp(pred, C1, C2); } static Constant *GetFCmp(unsigned short pred, Constant *C1, Constant *C2) { return ConstantExpr::getFCmp(pred, C1, C2); } //===--------------------------------------------------------------------===// // Constant GEPs //===--------------------------------------------------------------------===// static Constant *GetGEP( Constant *C, ///< Pointer to item being indexed Constant *const *IdxList, ///< List of indices unsigned NumIdx) { ///< Number of indices return ConstantExpr::getGetElementPtr(C, IdxList, NumIdx); } template static Constant *GetGEP( Constant *C, ///< Pointer to item being indexed RandomAccessIterator ArgBegin, ///< Iterator for the first element RandomAccessIterator ArgEnd) { ///< The elements of the array return GetGEP(C, &ArgBegin[0], ArgEnd - ArgBegin); } static Constant *GetGEP( Constant *C, ///< Pointer to item being indexed Constant * Idx, ...) END_WITH_NULL; ///< List of indices static Constant *GetGEP1_32( Constant *C, ///< Pointer to item being indexed unsigned Idx0); ///< Index 0 of GEP static Constant *GetGEP2_32( Constant *C, ///< Pointer to item being indexed unsigned Idx0, ///< Index 0 of GEP unsigned Idx1); ///< Index 1 of GEP static Constant *GetGEP1_64( Constant *C, ///< Pointer to item being indexed uint64_t Idx0); ///< Index 0 of GEP static Constant *GetGEP2_64( Constant *C, ///< Pointer to item being indexed uint64_t Idx0, ///< Index 0 of GEP uint64_t Idx1); ///< Index 1 of GEP //===--------------------------------------------------------------------===// // Constant Inbounds GEPs //===--------------------------------------------------------------------===// static Constant *GetInBoundsGEP( Constant *C, ///< Pointer to item being indexed Constant *const *IdxList, ///< POD array of indices unsigned NumIdx) { ///< Number of indices return ConstantExpr::getGetElementPtr(C, IdxList, NumIdx); } template static Constant *GetInBoundsGEP( Constant *C, ///< Pointer to item being indexed RandomAccessIterator ArgBegin, ///< Iterator for the first element RandomAccessIterator ArgEnd) { ///< The elements of the array return GetInBoundsGEP(C, &ArgBegin[0], ArgEnd - ArgBegin); } static Constant *GetInBoundsGEP( Constant *C, ///< Pointer to item being indexed Constant * Idx, ...) END_WITH_NULL; ///< List of indices static Constant *GetInBoundsGEP1_32( Constant *C, ///< Pointer to item being indexed unsigned Idx0); ///< Index 0 of GEP static Constant *GetInBoundsGEP2_32( Constant *C, ///< Pointer to item being indexed unsigned Idx0, ///< Index 0 of GEP unsigned Idx1); ///< Index 1 of GEP static Constant *GetInBoundsGEP1_64( Constant *C, ///< Pointer to item being indexed uint64_t Idx0); ///< Index 0 of GEP static Constant *GetInBoundsGEP2_64( Constant *C, ///< Pointer to item being indexed uint64_t Idx0, ///< Index 0 of GEP uint64_t Idx1); ///< Index 1 of GEP static Constant *GetStructGEP( Constant *C, ///< Pointer to item being indexed uint64_t Idx) { ///< Index of struct field return GetInBoundsGEP2_32(C, 0, Idx); } //===--------------------------------------------------------------------===// // Constant Aggregate Ops //===--------------------------------------------------------------------===// static Constant *GetExtractElement(Constant *Vec, Constant *Idx) { return ConstantExpr::getExtractElement(Vec, Idx); } static Constant *GetInsertElement( Constant *Vec, Constant *Elt, Constant *Idx) { return ConstantExpr::getInsertElement(Vec, Elt, Idx); } static Constant *GetExtractValue( Constant *Agg, const unsigned *IdxList, unsigned NumIdx) { return ConstantExpr::getExtractValue(Agg, IdxList, NumIdx); } static Constant *GetInsertValue( Constant *Agg, Constant *Val, const unsigned *IdxList, unsigned NumIdx) { return ConstantExpr::getInsertValue(Agg, Val, IdxList, NumIdx); } static Constant *GetShuffleVector( Constant *V1, Constant *V2, Constant *Mask) { return ConstantExpr::getShuffleVector(V1, V2, Mask); } }; } #endif -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110204/553f81f1/attachment.html From z_alk at live.concordia.ca Fri Feb 4 14:09:50 2011 From: z_alk at live.concordia.ca (z_alk at live.concordia.ca) Date: Fri, 4 Feb 2011 20:09:50 +0000 Subject: [LLVMdev] PareAssemblyFile returning "expected top-level entity" error message Message-ID: Hello all, I am trying to generate a module object using something like this: (to use for code analysis) Module *topModule; SMDiagnostic error; topModule = ParseAssemblyFile("code.s", error, getGlobalContext()); displayErrorInfo(error); void displayErrorInfo(SMDiagnostic& err) { std::string errFileName = err.getFilename(); std::string errMsg = err.getMessage(); std::string errLineContents = err.getLineContents(); int errLineNo = err.getLineNo(), errColNo = err.getColumnNo(); std::cout << "Error File Name: "<< errFileName << std::endl; std::cout << "Error Message: " << errMsg << std::endl; std::cout << "Error Line number: " << errLineNo << ". Column number: "<< errColNo << std::endl; } and I've been getting the following output: Error File Name: code.s Error Message: error: expected top-level entity Error Line number: 1. Column number: 1 code.s is generated manually using llvm-g++ -S code.cpp where code.cpp is just a hello world application. Any ideas as to the reason for the error ? Thanks !! Zaid -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110204/fb271f10/attachment.html From fvbommel at gmail.com Fri Feb 4 16:12:29 2011 From: fvbommel at gmail.com (Frits van Bommel) Date: Fri, 4 Feb 2011 23:12:29 +0100 Subject: [LLVMdev] ConstantBuilder proposal In-Reply-To: References: Message-ID: If you remove all the 'static's from the member functions, it'd work more like IRBuilder. It would also allow you to take the LLVMContext& as a constructor parameter, so that methods like this: On Fri, Feb 4, 2011 at 6:57 PM, Talin wrote: > ? /// GetStruct - return a constant struct given a context and a vector > ? /// of elements. > ? static Constant *GetStruct( > ??? LLVMContext &Context, > ??? const std::vector &V, > ??? bool Packed = false) { > ??? return ConstantStruct::get(Context, V, Packed); > ? } can remove it from their parameter list. It's probably pretty unlikely a given ConstantBuilder instance would be used with multiple LLVMContexts. Making this a class you need an instance of would likely also allow typing to be reduced a bit because said instance can be given a shorter name than 'ConstantBuilder'. For example: 'cb.GetStruct(...)' instead of 'ConstantBuilder::GetStruct(MyContext, ...)'. From fvbommel at gmail.com Fri Feb 4 16:22:31 2011 From: fvbommel at gmail.com (Frits van Bommel) Date: Fri, 4 Feb 2011 23:22:31 +0100 Subject: [LLVMdev] PareAssemblyFile returning "expected top-level entity" error message In-Reply-To: References: Message-ID: On Fri, Feb 4, 2011 at 9:09 PM, z_alk at live.concordia.ca wrote: > I am trying to generate a module object using something like this: (to use > for code analysis) > > ???? Module *topModule; > ??? SMDiagnostic error; > ??? topModule = ParseAssemblyFile("code.s", error, getGlobalContext()); ... > and I've been getting the following output: > > Error File Name: code.s > Error Message: error: expected top-level entity > Error Line number: 1. Column number: 1 > > code.s is generated manually using > llvm-g++ -S code.cpp > > where code.cpp is just a hello world application. > > Any ideas as to the reason for the error ? 'llvm-g++ -S' generates machine-level asm (for example, x86 asm). Adding '-emit-llvm' should tell it to generate LLVM asm instead. From viridia at gmail.com Fri Feb 4 16:33:56 2011 From: viridia at gmail.com (Talin) Date: Fri, 4 Feb 2011 14:33:56 -0800 Subject: [LLVMdev] ConstantBuilder proposal In-Reply-To: References: Message-ID: On Fri, Feb 4, 2011 at 2:12 PM, Frits van Bommel wrote: > If you remove all the 'static's from the member functions, it'd work > more like IRBuilder. > It would also allow you to take the LLVMContext& as a constructor > parameter, so that methods like this: > > On Fri, Feb 4, 2011 at 6:57 PM, Talin wrote: > > /// GetStruct - return a constant struct given a context and a vector > > /// of elements. > > static Constant *GetStruct( > > LLVMContext &Context, > > const std::vector &V, > > bool Packed = false) { > > return ConstantStruct::get(Context, V, Packed); > > } > > can remove it from their parameter list. It's probably pretty unlikely > a given ConstantBuilder instance would be used with multiple > LLVMContexts. > I thought about that - the only issue is that the only methods that need a context parameter are the ones for building structs, the rest can derive the context from the arguments. (in fact, you could even get the context for the struct-building methods from the arguments except in the case where the struct was empty.) > > Making this a class you need an instance of would likely also allow > typing to be reduced a bit because said instance can be given a > shorter name than 'ConstantBuilder'. For example: 'cb.GetStruct(...)' > instead of 'ConstantBuilder::GetStruct(MyContext, ...)'. > That would make sense if you were going to keep the builder around for creating more than one constant with the same instance. In my own code, I have a StructBuilder class that is specialized for building structs: Constant * foo = StructBuilder(context) .add(ptr) .addNullPtr(type) .addInt32(10) .build(); -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110204/7c29a091/attachment.html From erick.tryzelaar at gmail.com Fri Feb 4 18:01:36 2011 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Fri, 4 Feb 2011 16:01:36 -0800 Subject: [LLVMdev] CPS In-Reply-To: <4D4C21E9.3000109@strayorange.com> References: <4D4C21E9.3000109@strayorange.com> Message-ID: On Fri, Feb 4, 2011 at 7:57 AM, Carlo Alberto Ferraris wrote: > Hi everybody, > I'd like to try implementing a pass that transforms all functions (and > function calls, returns, etc.) to CPS, so that TCO can get rid of all > (or most of) the function calling overhead (because, as you probably > know, the side effect of using CPS is that all function calls become > tail calls). > That being said, and since I'm pretty new to LLVM, I'd like to ask a > couple of things to the veterans: > 1. Can you see anything really wrong with the general idea of having > such a transformation? > 2. Has anybody worked on something like this in the past? Are there any > starting points you'd suggest I should take a look at? > 3. Do you have any advice about which direction should I take? Hi Carlo, I haven't tried implementing CPS with llvm before, but I do know there have been a couple conversations about it in the past. First off, Chris Lattner wrote up about explicitly managed stack frames here: http://www.nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt I'd also suggest googling around for "llvm cps" as perhaps your questions have been answered elsewhere. I hope this helps. From neda8664 at gmail.com Sat Feb 5 00:40:35 2011 From: neda8664 at gmail.com (neda 8664) Date: Sat, 5 Feb 2011 10:10:35 +0330 Subject: [LLVMdev] create function Message-ID: i need split a sequential program to multithread. the first step I am going to assign each basic block of program to a thread, so i want create a function for each basic block and add instruction of basic block into it and assign every function to a thread. how could i do it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110205/3fe1ba00/attachment.html From abhirupju at gmail.com Sat Feb 5 08:49:55 2011 From: abhirupju at gmail.com (Abhirup Ghosh) Date: Sat, 5 Feb 2011 20:19:55 +0530 Subject: [LLVMdev] How to create new local variable Message-ID: Hi, I want to implement a simple common sub expression pass in llvm2.8 which demands replacing the uses of the redundant expressions with a temporary variable. So, to introduce new temporary variable I have inserted an AllocaInst (...) providing the name of the temporary and desired type. But whenever I am going to insert a LoadInst for that variable I am getting segmentation fault. It is telling that llvm::Value::setName(...) fails and that has something to do with llvm::ValueSymbolTable::createValueName(...) method. What should I do to insert the local variable? Thanks and regards, Abhirup Ghosh M. Tech Department of Computer Science & Engg. IIT, Bombay email - abhirupju at gmail.com , abhirup at cse.iitb.ac.in From eschew at gmail.com Sat Feb 5 10:12:15 2011 From: eschew at gmail.com (Ben Karel) Date: Sat, 5 Feb 2011 11:12:15 -0500 Subject: [LLVMdev] CPS In-Reply-To: <4D4C21E9.3000109@strayorange.com> References: <4D4C21E9.3000109@strayorange.com> Message-ID: On Fri, Feb 4, 2011 at 10:57 AM, Carlo Alberto Ferraris < cafxx at strayorange.com> wrote: > Hi everybody, > I'd like to try implementing a pass that transforms all functions (and > function calls, returns, etc.) to CPS, so that TCO can get rid of all > (or most of) the function calling overhead (because, as you probably > know, the side effect of using CPS is that all function calls become > tail calls). > That being said, and since I'm pretty new to LLVM, I'd like to ask a > couple of things to the veterans: > 1. Can you see anything really wrong with the general idea of having > such a transformation? > 2. Has anybody worked on something like this in the past? Are there any > starting points you'd suggest I should take a look at? > 3. Do you have any advice about which direction should I take? > Hello Carlo, I think you might find these two papers very interesting: http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf http://research.microsoft.com/en-us/um/people/akenn/sml/CompilingWithContinuationsContinued.pdf The first is Guy Steele's classic paper Debunking the "Expensive Procedure Call" Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO. The second paper contains a description of a CPS internal language as used by a compiler which targeted .NET intermediate language. It contains a description of a CPS language which has much in common with the core of LLVM's SSA form. As the paper notes, invocations of second-class continuations correspond to jumps between basic blocks. LLVM's br i1 ... corresponds to "case z of k1 [] k2" in the CPS language. You may also find it useful because it contains both an elegant conversion from "direct-style" lambda terms to CPS terms, as well as lists of optimizations to perform on CPS terms. Cheers! -- Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110205/881142dd/attachment.html From baldrick at free.fr Sat Feb 5 12:07:25 2011 From: baldrick at free.fr (Duncan Sands) Date: Sat, 05 Feb 2011 19:07:25 +0100 Subject: [LLVMdev] How to create new local variable In-Reply-To: References: Message-ID: <4D4D91DD.7000205@free.fr> Hi Abhirup, > I want to implement a simple common sub expression pass in > llvm2.8 the development version of LLVM gained exactly such a CSE pass, called EarlyCSE. which demands replacing the uses of the redundant expressions > with a temporary variable. So, to introduce new temporary variable I > have inserted an AllocaInst (...) providing the name of the temporary > and desired type. But whenever I am going to insert a LoadInst for > that variable I am getting segmentation fault. It is telling that > llvm::Value::setName(...) fails and that has something to do with > llvm::ValueSymbolTable::createValueName(...) method. What should I do > to insert the local variable? I suggest you post the code you are using to do this. Ciao, Duncan. From baldrick at free.fr Sat Feb 5 12:09:07 2011 From: baldrick at free.fr (Duncan Sands) Date: Sat, 05 Feb 2011 19:09:07 +0100 Subject: [LLVMdev] Segmentation fault on using get parent of a PHINode In-Reply-To: References: Message-ID: <4D4D9243.3020305@free.fr> Hi Surinder, I don't see anything obviously wrong with your code. I suggest that (1) you build LLVM with assertions enabled, (2) you run the verifier on your bitcode, and (3) run your program under valgrind. Ciao, Duncan. > I am getting a segmentation fault as soon as I touch the Basic block > *b value defined as : > > std::string getPHIAssigns(const PHINode *PH) > { const BasicBlock *b = PH->getParent(); > errs()<< b->size(); > > > where as getPHIAssigns is being called from > > for (BasicBlock::iterator ins=b->begin(), e3=b->end(); > ins!=e3; ++ins, ++l) // get instructions > { if (const PHINode *PH = dyn_cast(&ins)) // Phi > ers()<< getPHIAssigns(PH); > > Can you see what is wrong here? > > The dump is : > > 0 opt 0x0000000000bc9cfa > 1 opt 0x0000000000bca288 > 2 libpthread.so.0 0x00000037ef20e540 > 3 opt 0x0000000000910849 llvm::iplist llvm::ilist_traits >::size() const + 17 > 4 opt 0x00000000009108a5 llvm::BasicBlock::size() const + 25 > 5 dfl.so 0x00002aaaaaaf101d > 6 dfl.so 0x00002aaaaaaf2965 > 7 dfl.so 0x00002aaaaaaf308a > 8 opt 0x0000000000b467fa > llvm::FPPassManager::runOnFunction(llvm::Function&) + 348 > 9 opt 0x0000000000b469cf > llvm::FPPassManager::runOnModule(llvm::Module&) + 81 > 10 opt 0x0000000000b464bd > llvm::MPPassManager::runOnModule(llvm::Module&) + 381 > 11 opt 0x0000000000b478f7 > llvm::PassManagerImpl::run(llvm::Module&) + 111 > 12 opt 0x0000000000b47959 llvm::PassManager::run(llvm::Module&) + 33 > 13 opt 0x00000000007a14a6 main + 3438 > 14 libc.so.6 0x00000037ee61e074 __libc_start_main + 244 > 15 opt 0x00000000007929a9 > Stack dump: > 0. Program arguments: opt -load > /u1/suri/llvm-local/build/x86-64/Debug/llvm/Debug/lib/dfl.so -dfl > /u1/suri/suri/testing/cfgs/test99foo.c.bc > 1. Running pass 'Function Pass Manager' on module > '/u1/suri/suri/testing/cfgs/test99foo.c.bc'. > 2. Running pass 'emit cfg in dfl format' on function '@main' > > Surinder >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From matthieu.monrocq at gmail.com Sat Feb 5 13:30:19 2011 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sat, 5 Feb 2011 20:30:19 +0100 Subject: [LLVMdev] Spell Correction Efficiency In-Reply-To: <63BC7D07-F7FF-4C1F-910F-DE51F7B69755@apple.com> References: <081AD223-B908-4757-973E-45A57CEDD942@apple.com> <63BC7D07-F7FF-4C1F-910F-DE51F7B69755@apple.com> Message-ID: Hello Doug, thanks for the review :) I went ahead and reworked the patches according to your remarks, namely: - I modified edit_distance directly, rather than introducing a new method, dropping the "AllowReplacement" parameter and refactoring the calls - I have changed the "artificial" lowering, a levenshtein cannot be higher than the longer of the two strings (perform "short.length()" replacements and the rest as additions to turn the short into the long) - I checked the 80-columns line - I realized that the K&R brace style was used If there is anything I missed in the Coding Standard, please let met know; I have notably interpreted the "camelCase" guideline as lower camelCase, since otherwise "PascalCase" would have been clearer I guess. The tests still don't work well on windows (exception in clang's lit.cfg, I've tried to fix it but it yielded a fatal error instead so... :/). But I did succeeded in compiling the whole of llvm and clang, from scratch, after wiping out the build directory and reruning CMake (and I do hate VC++ sluggishness, btw). I've tested it in isolation (against the original algorithm), it looks like I had made an error when transposing my implementation to the body of StringRef last time (lost in translation...) so this time I worked directly on StringRef to avoid further issues. It looks like the algo had a bug ('=' instead of '+') and would not report distances greater than 1 or 2... *hum* I have benchmarked the performances using the following method (compiled in Release mode in VC++2010): > pickup a corpus of about ~18,000 distinct words, containing letters, digits and underscore (to match C++ identifiers), with length varying from 1 to 18. > randomly select 100 words in the corpus, and perform up to 5 random alterations on them > for each altered word - initialize max to the altered word length - loop over the corpus, compute the distance between the current word and the altered one (bounded by max), update max if necessary and stop if it reaches 0 - report the "best" score achieved (check that both algorithm report the same score) - rerun 5000 times this search (over the whole corpus) first for the "classic" distance then for the "diagonal" distance > record each "time" (measured from outside the 5000 loop) depending on the "best" score achieved > display the average, per "best" score, as well as the speed-up achieved Distance Brute Diagonal Speedup Distance: 0 0.00234 0.00057 x4.11 Distance: 1 0.00550 0.00150 x3.67 Distance: 2 0.00785 0.00337 x2.33 Distance: 3 0.01003 0.00636 x1.57 Distance: 4 0.01303 0.00993 x1.31 Distance: 5 0.01701 0.01087 x1.56 I don't have any explanation of why 5 would perform better than 4, it looks like an artifact of the tests (and may be due to the distance tightening sooner). The trend should, logically, be decreasing, since the number of computations is directly impacted by the "best distance so far" in the loop. Anyway, it looks like it performs rather well. Note: there are two patches, one for llvm and one for clang. The patches are correlated and cannot be applied separately, because the signature of edit_distance changed (we lost a parameter). 2011/2/3 Douglas Gregor > > On Jan 15, 2011, at 8:31 AM, Matthieu Monrocq wrote: > > > Hello Doug, > > > > *putting llvmdev in copy since they are concerned too* > > > > I've finally got around to finish a working implementation of the typical > Levenshtein Distance with the diagonal optimization. > > > > I've tested it against the original llvm implementation and checked it on > a set of ~18k by randomly generating a variation of each word and checking > that both implementations would return the same result... took me some time > to patch the diagonal version, but they now do. > > Okay. Did you do any performance comparisons? The point of introducing a > new algorithm is to improve performance. > > > I have left the older method in place, especially because I saw that it > was used in FileCheck and was a bit wary of any side-effect I might > introduce there. > > > > I have thus created a new method: unsigned > StringRef::levenshtein_distance(StringRef other, unsigned maxEditDistance) > and replace the two uses of edit_distance in Sema\SemaLookup.cpp with it. > > I would much rather just replace edit_distance completely. Compiler writers > aren't string-savvy enough to pick between the two algorithms :) > > > I have ditched the "AllowReplace" argument since it further complicated > the logic of an already ~150 lines method for no obvious gain (as far as I > could see) and I have also explicited the computations a bit by using named > temporaries. > > Okay. I can't imagine why anyone would want to turn off replacement anyway. > > > Unfortunately I have only a Windows machine at hand for the moment and > the tests don't work that well... so I'd appreciate if anyone could check my > changes. > > A bunch of Clang tests failed when I applied your patch, so it's not quite > ready yet. These are the failures: > > Failing Tests (10): > Clang :: CXX/class/class.friend/p1.cpp > Clang :: FixIt/fixit.cpp > Clang :: Parser/objc-quirks.m > Clang :: Parser/recovery.c > Clang :: Sema/MicrosoftExtensions.c > Clang :: SemaCXX/unknown-type-name.cpp > Clang :: SemaObjC/category-1.m > Clang :: SemaObjC/super.m > Clang :: SemaObjC/synth-provisional-ivars.m > Clang :: SemaObjCXX/category-lookup.mm > > I looked at the first one, and for the strings "UndeclaredSoFar" and > "_Imaginary" and a maxEditDistance of 5 (= the difference in their lengths, > if that matters), the algorithm returns an edit distance of 2. > > One of the other tests (Parser/objc-quirks.m) is actually a crash. > > + // maxDistance (aka D) directly influences the width of the strip > (2*D+1) > + // we arbitrarily restrict it in case the caller did not see fit to do > it > + // (from clang\lib\Sema\SemaLookup.cpp in > TypoCorrectionConsumer::FoundName) > + unsigned const maxDistance = std::min(unsigned((otherLength+2)/3), > + maxEditDistance); > > I don't think this belongs here. We can count on the client to supply a > reasonable maxEditDistance. If our performance is going to degrade horribly > when an unreasonable maxEditDistance is provided (e.g., > the sum of the > string lengths), we could just fall back to the simplistic algorithm we > currently have. > > Oh, and please look at the LLVM Coding Standards ( > http://llvm.org/docs/CodingStandards.html), and reformat your patch > accordingly. Thanks! > > - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110205/c7f889df/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: edit_distance_clang.diff Type: application/octet-stream Size: 1154 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110205/c7f889df/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: edit_distance_llvm.diff Type: application/octet-stream Size: 19816 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110205/c7f889df/attachment-0001.obj From markleone at gmail.com Sun Feb 6 00:37:01 2011 From: markleone at gmail.com (Mark Leone) Date: Sun, 6 Feb 2011 19:37:01 +1300 Subject: [LLVMdev] CPS In-Reply-To: <4D4C21E9.3000109@strayorange.com> References: <4D4C21E9.3000109@strayorange.com> Message-ID: CPS conversion doesn't necessarily get rid of function-calling overhead. A tail call is indeed a jump, but constructing the closure of the continuation is usually more expensive than constructing a stack frame. Having said that, it's an interesting topic. For example, CPS conversion makes the implementation of call/cc trivial, which might make LLVM a more attractive target for implementing functional languages, cooperative software threading, etc. I'm sure lots of folks would be interested in hearing more about your work. Mark Leone On Sat, Feb 5, 2011 at 4:57 AM, Carlo Alberto Ferraris wrote: > Hi everybody, > I'd like to try implementing a pass that transforms all functions (and > function calls, returns, etc.) to CPS, so that TCO can get rid of all > (or most of) the function calling overhead (because, as you probably > know, the side effect of using CPS is that all function calls become > tail calls). > That being said, and since I'm pretty new to LLVM, I'd like to ask a > couple of things to the veterans: > 1. Can you see anything really wrong with the general idea of having > such a transformation? > 2. Has anybody worked on something like this in the past? Are there any > starting points you'd suggest I should take a look at? > 3. Do you have any advice about which direction should I take? > > B.R., > Carlo Alberto Ferraris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From rjmccall at apple.com Sun Feb 6 04:57:01 2011 From: rjmccall at apple.com (John McCall) Date: Sun, 6 Feb 2011 02:57:01 -0800 Subject: [LLVMdev] Segmentation fault on using get parent of a PHINode In-Reply-To: <4D4D9243.3020305@free.fr> References: <4D4D9243.3020305@free.fr> Message-ID: On Feb 5, 2011, at 10:09 AM, Duncan Sands wrote: > Hi Surinder, I don't see anything obviously wrong with your code. I suggest > that (1) you build LLVM with assertions enabled, (2) you run the verifier on > your bitcode, and (3) run your program under valgrind. I think there might be something unsound in our current dyn_cast implementation; that is, I'm pretty sure it type-checks for things it's not supposed to type-check for. In this example, &ins has type llvm::ilist_iterator*, because the iterator type (like most iterator types) does not overload operator&. This should really not compile, and yet it does. Anyway, the immediate fix is to use the iterator correctly: >> for (BasicBlock::iterator ins=b->begin(), e3=b->end(); >> ins!=e3; ++ins, ++l) // get instructions >> { if (const PHINode *PH = dyn_cast(&ins)) // Phi >> ers()<< getPHIAssigns(PH); This should be dyn_cast(*ins). John. From sks200203 at gmail.com Sun Feb 6 22:52:14 2011 From: sks200203 at gmail.com (sivakumar srinivasan) Date: Mon, 7 Feb 2011 10:22:14 +0530 Subject: [LLVMdev] Debug info generation through llvm backend Message-ID: Hi Everyone, I am really new to LLVM. I am working on something where I had to pick-up a half-cooked backend and need to add debug support to it. I have searched through messages but could not find a nice starting place. Could some one please provide me with some pointers about - what is already supported in llvm as far as emitting debugging information is concerned? - how to emit debug information through a llvm backend (any step-by-step process)? - any existing implementation? - also, how to search through mailing list archives? Thanks, -sks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110207/4825d777/attachment.html From jnspaulsson at hotmail.com Mon Feb 7 01:32:04 2011 From: jnspaulsson at hotmail.com (Jonas Paulsson) Date: Mon, 7 Feb 2011 08:32:04 +0100 Subject: [LLVMdev] Post-inc combining In-Reply-To: <62F916FB-DF49-4A51-B721-2A5989619209@apple.com> References: , <62F916FB-DF49-4A51-B721-2A5989619209@apple.com> Message-ID: When I compile the following program (for ARM): for(i=0;iThis Inner Loop Header: Depth=1 add r12, lr, r3 ldr lr, [r0, lr, lsl #2] add r1, lr, r1 cmp r12, r2 mov lr, r12 blt .LBB0_3 , which does not seem to be auto-incrementing, I think. I wonder what I should do to get loops auto-incing generally, for instance in this simple loop: for(i=0;i<256;i++) { s+=a[i]; } , which now yields .LBB0_1: @ %for.body @ =>This Inner Loop Header: Depth=1 ldr r3, [r0, r2] add r2, r2, #4 add r1, r3, r1 cmp r2, #1, 22 @ 1024 bne .LBB0_1 , which uses r0 as base address with r2 as offset. On my target, it is much preferred to use auto-inc in cases like this. I repeat my question, as I don't quite understand why the ldr/add is used by ARM here, instead of post-inc. I guess I would like the DAG combiner to work in cases like this, but it does not seem to do so. Thank you, Jonas Subject: Re: [LLVMdev] Post-inc combining From: bob.wilson at apple.com Date: Fri, 28 Jan 2011 08:56:09 -0800 CC: llvmdev at cs.uiuc.edu To: jnspaulsson at hotmail.com On Jan 27, 2011, at 11:13 PM, Jonas Paulsson wrote:Hi, I would like to transform a LLVM function containing a load and an add of the base address inside a loop to a post-incremented load. In DAGCombiner.cpp::CombineToPostIndexedLoadStore(), it says it cannot fold the add for instance if it is a predecessor/successor of the load. I find this odd, as this is exactly what I would like to handle: a simple loop with an address that is inremented in each iteration. I am considering using a target intrinsic for this purpose, as the SCEV interface is available on the LLVM I/R. In this way, I could get a DAG with a post-inc-load node instead of the load and add nodes. Is this a work in progress? Please explain why these constraints are put in the above mentioned method as they do not seem to facilitate post-inc instruction combining. The "predecessor" and "successor" terminology used there refers to the DAG, not to the order of the operations in the llvm IR. For example, if the result of the ADD is the value being stored to memory, then you couldn't fold that into into a post-inc STORE: %x = add i32 %addr, 4; store i32 %x, i32* %addr In the DAG for that, the ADD is a predecessor of the STORE. If the result of the add is used for some other memory reference, then it would not be a predecessor and could be folded. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110207/54cd90c3/attachment.html From florian.merz at kit.edu Mon Feb 7 03:10:17 2011 From: florian.merz at kit.edu (Florian Merz) Date: Mon, 7 Feb 2011 10:10:17 +0100 Subject: [LLVMdev] Data layout of structs In-Reply-To: <4D4C0F9C.8080902@informatik.rwth-aachen.de> References: <4D4C0F9C.8080902@informatik.rwth-aachen.de> Message-ID: <201102071010.18040.florian.merz@kit.edu> Hi Thomas, I suggest you read [1] for more information about data structure alignmnent and the reason for your 32 bit gap. Regards, Florian [1] http://en.wikipedia.org/wiki/Data_structure_alignment Am Freitag, 4. Februar 2011, um 15:39:24 schrieb Thomas Str?der: > Dear all, > > I'm currently working on the automated program analysis tool AProVE > (http://aprove.informatik.rwth-aachen.de/) and would like to use LLVM > for analysis of C programs. > > I have the following example C program dealing with simple lists of > integers: > > ------------ start C example ------------- > > #include > > struct list_el { > int val; > struct list_el * next; > }; > > typedef struct list_el item; > > void test(int length) { > item * curr, * head; > int i; > > head = NULL; > > for(i=1;i<=length;i++) { > curr = (item *)malloc(sizeof(item)); > curr->val = i; > curr->next = head; > head = curr; > } > > curr = head; > > while(curr) { > curr = curr->next; > } > } > > ------------ end C example ------------- > > > The output I get from the LLVM web interface is: > > ------------ start LLVM output ------------- > > ; ModuleID = '/tmp/webcompile/_27083_0.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-n8:16:32:64" target > triple = "x86_64-linux-gnu" > > %struct.item = type { i32, %struct.item* } > > define void @test(i32 %length) nounwind { > entry: > %0 = icmp slt i32 %length, 1 ; [#uses=1] > br i1 %0, label %return, label %bb > > bb: ; preds = %bb, %entry > %indvar = phi i32 [ %i.08, %bb ], [ 0, %entry ] ; [#uses=2] > %head.07 = phi %struct.item* [ %2, %bb ], [ null, %entry ] ; > <%struct.item*> [#uses=1] %i.08 = add i32 %indvar, 1 > ; [#uses=2] %1 = tail call noalias i8* @malloc(i64 16) nounwind ; > [#uses=3] %2 = bitcast i8* %1 to %struct.item* ; > <%struct.item*> [#uses=3] %3 = bitcast i8* %1 to i32* > ; [#uses=1] store i32 %i.08, i32* %3, align 8 > %4 = getelementptr inbounds i8* %1, i64 8 ; [#uses=1] > %5 = bitcast i8* %4 to %struct.item** ; <%struct.item**> > [#uses=1] store %struct.item* %head.07, %struct.item** %5, align 8 > %tmp = add i32 %indvar, 2 ; [#uses=1] > %6 = icmp sgt i32 %tmp, %length ; [#uses=1] > br i1 %6, label %bb4.preheader, label %bb > > bb4.preheader: ; preds = %bb > %7 = icmp eq %struct.item* %2, null ; [#uses=1] > br i1 %7, label %return, label %bb3 > > bb3: ; preds = %bb3, > %bb4.preheader %curr.06 = phi %struct.item* [ %9, %bb3 ], [ %2, > %bb4.preheader ] ; <%struct.item*> [#uses=1] %8 = getelementptr inbounds > %struct.item* %curr.06, i64 0, i32 1 ; <%struct.item**> [#uses=1] %9 = > load %struct.item** %8, align 8 ; <%struct.item*> [#uses=2] %10 > = icmp eq %struct.item* %9, null ; [#uses=1] br i1 %10, > label %return, label %bb3 > > return: ; preds = %bb3, > %bb4.preheader, %entry ret void > } > > declare noalias i8* @malloc(i64) nounwind > > ------------ end LLVM output ------------- > > > Now my problem is as follows. The pointer %4 (pointing to the second > field in the list element) is calculated by going 8 byte further in > memory. However, i32 only has a size of 4 byte. What is the reason > for the struct having the data layout of two times 8 bytes instead > of having 4 bytes for the integer and 8 bytes for the pointer to the > next element? Is there a general rule for the data layout of structs > in LLVM? > > Thank you, > Thomas From xinfinity_a at yahoo.com Mon Feb 7 05:17:50 2011 From: xinfinity_a at yahoo.com (Xinfinity) Date: Mon, 7 Feb 2011 03:17:50 -0800 (PST) Subject: [LLVMdev] How to prevent an instruction to be executed more than once? In-Reply-To: <3865A2C8-FE71-4831-96AC-AC15578EEC70@apple.com> References: <28981639.post@talk.nabble.com> <26340379-7982-4978-B544-C1316ED267D3@gmail.com> <28982790.post@talk.nabble.com> <3865A2C8-FE71-4831-96AC-AC15578EEC70@apple.com> Message-ID: <30862596.post@talk.nabble.com> As I have seen in the CodeGen phase there is the tail duplication step which duplicates all my inlined asm. However, tail duplication checks for each machine instruction if the description allows duplication or not. /// isNotDuplicable - Return true if this instruction cannot be safely 00363 /// duplicated. For example, if the instruction has a unique labels attached 00364 /// to it, duplicating it would cause multiple definition errors. 00365 bool isNotDuplicable() const { 00366 return Flags & (1 << TID::NotDuplicable); 00367 } Is there a way to mark my instructions as not duplicable and to propagate this description till the machine instruction level? What is the "unique label" attached to an instruction? Thanks. Alexandra. -- View this message in context: http://old.nabble.com/How-to-prevent-an-instruction-to-be-executed-more-than-once--tp28981639p30862596.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From douglasdocouto at gmail.com Mon Feb 7 06:20:48 2011 From: douglasdocouto at gmail.com (Douglas do Couto Teixeira) Date: Mon, 7 Feb 2011 10:20:48 -0200 Subject: [LLVMdev] Running the programs in the LLVM test suite with a pass and without it. Message-ID: Hi guys, I have a pass called "MyPass". And I can run this pass in the LLVM test suite programs and produce a report with the statistics of the execution of this pass. Now, I would like to run the programs in LLVM test suite and generate a report comparing the results obtained without using the pass with the results obtained using the pass. Is there any way to do this? Thank you, Douglas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110207/d07c4bfe/attachment.html From baldrick at free.fr Mon Feb 7 06:50:25 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 07 Feb 2011 13:50:25 +0100 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks Message-ID: <4D4FEA91.2090304@free.fr> Hi all, I wrote a little pass (attached) which does the following: if it sees a conditional branch instruction then it replaces all occurrences of the condition in the true block with "true" and in the false block with "false". Well, OK, it is a bit more sophisticated (and a bit more careful!) than that but you get the idea. It will turn this define i1 @t1(i1 %c) { br i1 %c, label %t, label %f t: ret i1 %c f: ret i1 %c } into this define i1 @t1(i1 %c) { br i1 %c, label %t, label %f t: ret i1 true f: ret i1 false } for example. Curiously enough LLVM doesn't seem to have a pass that does this. I took a look at the effect on the testsuite by scheduling a run of this pass just after each run of -correlated-propagation. In spite of being so simple (not to say simplistic) it has an enormous positive impact on Ada code and a substantial positive impact throughout the LLVM test-suite (I didn't check that programs still work after running the pass, so it could be that it has such a big effect because it is wrong!). So... should this kind of logic be incorporated into LLVM? Perhaps as part of an existing pass like -correlated-propagation? It would be easy to make the pass a bit more powerful. For example if the condition was "X == 0" then it could also replace X with 0 everywhere in the true block. Ciao, Duncan. PS: This was inspired by PR9004. -------------- next part -------------- A non-text attachment was scrubbed... Name: Prop.cpp Type: text/x-c++src Size: 3641 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110207/4d2bcd96/attachment.bin From jdkunk3 at gmail.com Mon Feb 7 07:20:31 2011 From: jdkunk3 at gmail.com (Jeff Kunkel) Date: Mon, 7 Feb 2011 08:20:31 -0500 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <4D4FEA91.2090304@free.fr> References: <4D4FEA91.2090304@free.fr> Message-ID: Are you sure this is really advantageous? '%c' is only one variable, but when you add the constant propagation, '%c' and false/true are two different variables. Thus define i1 @t1(i1 %c) { br i1 %c, label %t, label %f t: ret i1 %c f: ret i1 %c } should be br i1 R0, label %t, label %f t: ret R0 f: ret R0 However, with your pass define i1 @t1(i1 %c) { br i1 %c, label %t, label %f t: ret i1 true f: ret i1 false } will be define i1 @t1(i1 %c) { br i1 R0, label %t, label %f t: R1 = true ret i1 R1 f: R1 = false ret i1 R1 } I am thinking X86 where '%c' would be allocated a register and the false/true statement would be allocated a different register which would be EAX/AX on the x86 machine. Honestly, I believe this pattern could be conditional constant propagation / conditional re-materialization in the spiller. LLVM uses the spiller to propagate constants. This pass would be useful to identify some conditional re-materializations. You should look into hacking the spiller and see if this can be added to it. - My 2 cents, Jeff Kunkel On Mon, Feb 7, 2011 at 7:50 AM, Duncan Sands wrote: > Hi all, I wrote a little pass (attached) which does the following: if it > sees a > conditional branch instruction then it replaces all occurrences of the > condition > in the true block with "true" and in the false block with "false". Well, > OK, it > is a bit more sophisticated (and a bit more careful!) than that but you get > the > idea. It will turn this > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 %c > f: > ret i1 %c > } > into this > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 true > f: > ret i1 false > } > for example. Curiously enough LLVM doesn't seem to have a pass that does > this. > I took a look at the effect on the testsuite by scheduling a run of this > pass > just after each run of -correlated-propagation. In spite of being so > simple > (not to say simplistic) it has an enormous positive impact on Ada code and > a > substantial positive impact throughout the LLVM test-suite (I didn't check > that > programs still work after running the pass, so it could be that it has such > a > big effect because it is wrong!). > > So... should this kind of logic be incorporated into LLVM? Perhaps as part > of > an existing pass like -correlated-propagation? > > It would be easy to make the pass a bit more powerful. For example if the > condition was "X == 0" then it could also replace X with 0 everywhere in > the > true block. > > Ciao, Duncan. > > PS: This was inspired by PR9004. > > _______________________________________________ > 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/20110207/34cdbb82/attachment.html From baldrick at free.fr Mon Feb 7 07:37:10 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 07 Feb 2011 14:37:10 +0100 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: References: <4D4FEA91.2090304@free.fr> Message-ID: <4D4FF586.9090303@free.fr> Hi Jeff, > Are you sure this is really advantageous? '%c' is only one variable, but when > you add the constant propagation, '%c' and false/true are two different > variables. Thus the example was explanatory, not typical. In fact I didn't ever see returns being split like this in practice. What I do see typically is branches being eliminated. For example, consider the effect on bzip2: 36 branches are completely removed, 1 is changed from conditional to unconditional, various bits of dead code are eliminated (not a lot, 4 stores and a few computations). I chose this example randomly, but it's typical of what I see elsewhere. Ciao, Duncan. > > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 %c > f: > ret i1 %c > } > should be > br i1 R0, label %t, label %f > t: > ret R0 > f: > ret R0 > > However, with your pass > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 true > f: > ret i1 false > } > will be > define i1 @t1(i1 %c) { > br i1 R0, label %t, label %f > t: > R1 = true > ret i1 R1 > f: > R1 = false > ret i1 R1 > } > > I am thinking X86 where '%c' would be allocated a register and the false/true > statement would be allocated a different register which would be EAX/AX on the > x86 machine. > > Honestly, I believe this pattern could be conditional constant propagation > / conditional re-materialization in the spiller. LLVM uses the spiller to > propagate constants. This pass would be useful to identify some conditional > re-materializations. You should look into hacking the spiller and see if this > can be added to it. > > - My 2 cents, > Jeff Kunkel > > On Mon, Feb 7, 2011 at 7:50 AM, Duncan Sands > wrote: > > Hi all, I wrote a little pass (attached) which does the following: if it sees a > conditional branch instruction then it replaces all occurrences of the condition > in the true block with "true" and in the false block with "false". Well, OK, it > is a bit more sophisticated (and a bit more careful!) than that but you get the > idea. It will turn this > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 %c > f: > ret i1 %c > } > into this > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 true > f: > ret i1 false > } > for example. Curiously enough LLVM doesn't seem to have a pass that does this. > I took a look at the effect on the testsuite by scheduling a run of this pass > just after each run of -correlated-propagation. In spite of being so simple > (not to say simplistic) it has an enormous positive impact on Ada code and a > substantial positive impact throughout the LLVM test-suite (I didn't check that > programs still work after running the pass, so it could be that it has such a > big effect because it is wrong!). > > So... should this kind of logic be incorporated into LLVM? Perhaps as part of > an existing pass like -correlated-propagation? > > It would be easy to make the pass a bit more powerful. For example if the > condition was "X == 0" then it could also replace X with 0 everywhere in the > true block. > > Ciao, Duncan. > > PS: This was inspired by PR9004. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From jdkunk3 at gmail.com Mon Feb 7 07:49:58 2011 From: jdkunk3 at gmail.com (Jeff Kunkel) Date: Mon, 7 Feb 2011 08:49:58 -0500 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <4D4FF586.9090303@free.fr> References: <4D4FEA91.2090304@free.fr> <4D4FF586.9090303@free.fr> Message-ID: Then I misunderstood it's purpose. I see now that constant propagation could remove branches because you know a value is true. I was looking at the problem through my 'register allocator' lens. Here is a more expressive example of what you are doing. define i1 @t1(i1 %c) { br i1 %c, label %t, label %f t: br i1 %c, label %t2, label %f2 t2: code... ret something f2: code... ret something f: br i1 %c, label %t3, label %f3 t3: code... ret something f3: code... ret something } Would be changed into: define i1 @t1(i1 %c) { br i1 %c, label %t2, label %f3 t2: code... ret something f3: code... ret something } Jeff Kunkel On Mon, Feb 7, 2011 at 8:37 AM, Duncan Sands wrote: > Hi Jeff, > > > Are you sure this is really advantageous? '%c' is only one variable, but >> when >> you add the constant propagation, '%c' and false/true are two different >> variables. Thus >> > > the example was explanatory, not typical. In fact I didn't ever see > returns > being split like this in practice. What I do see typically is branches > being eliminated. For example, consider the effect on bzip2: 36 branches > are > completely removed, 1 is changed from conditional to unconditional, various > bits of dead code are eliminated (not a lot, 4 stores and a few > computations). > I chose this example randomly, but it's typical of what I see elsewhere. > > Ciao, Duncan. > > > >> define i1 @t1(i1 %c) { >> br i1 %c, label %t, label %f >> t: >> ret i1 %c >> f: >> ret i1 %c >> } >> should be >> br i1 R0, label %t, label %f >> t: >> ret R0 >> f: >> ret R0 >> >> However, with your pass >> define i1 @t1(i1 %c) { >> br i1 %c, label %t, label %f >> t: >> ret i1 true >> f: >> ret i1 false >> } >> will be >> define i1 @t1(i1 %c) { >> br i1 R0, label %t, label %f >> t: >> R1 = true >> ret i1 R1 >> f: >> R1 = false >> ret i1 R1 >> } >> >> I am thinking X86 where '%c' would be allocated a register and the >> false/true >> statement would be allocated a different register which would be EAX/AX on >> the >> x86 machine. >> >> Honestly, I believe this pattern could be conditional constant propagation >> / conditional re-materialization in the spiller. LLVM uses the spiller to >> propagate constants. This pass would be useful to identify some >> conditional >> re-materializations. You should look into hacking the spiller and see if >> this >> can be added to it. >> >> - My 2 cents, >> Jeff Kunkel >> >> On Mon, Feb 7, 2011 at 7:50 AM, Duncan Sands > > wrote: >> >> Hi all, I wrote a little pass (attached) which does the following: if >> it sees a >> conditional branch instruction then it replaces all occurrences of the >> condition >> in the true block with "true" and in the false block with "false". >> Well, OK, it >> is a bit more sophisticated (and a bit more careful!) than that but you >> get the >> idea. It will turn this >> define i1 @t1(i1 %c) { >> br i1 %c, label %t, label %f >> t: >> ret i1 %c >> f: >> ret i1 %c >> } >> into this >> define i1 @t1(i1 %c) { >> br i1 %c, label %t, label %f >> t: >> ret i1 true >> f: >> ret i1 false >> } >> for example. Curiously enough LLVM doesn't seem to have a pass that >> does this. >> I took a look at the effect on the testsuite by scheduling a run of >> this pass >> just after each run of -correlated-propagation. In spite of being so >> simple >> (not to say simplistic) it has an enormous positive impact on Ada code >> and a >> substantial positive impact throughout the LLVM test-suite (I didn't >> check that >> programs still work after running the pass, so it could be that it has >> such a >> big effect because it is wrong!). >> >> So... should this kind of logic be incorporated into LLVM? Perhaps as >> part of >> an existing pass like -correlated-propagation? >> >> It would be easy to make the pass a bit more powerful. For example if >> the >> condition was "X == 0" then it could also replace X with 0 everywhere >> in the >> true block. >> >> Ciao, Duncan. >> >> PS: This was inspired by PR9004. >> >> _______________________________________________ >> 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/20110207/54394dc4/attachment.html From baldrick at free.fr Mon Feb 7 07:57:17 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 07 Feb 2011 14:57:17 +0100 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: References: <4D4FEA91.2090304@free.fr> <4D4FF586.9090303@free.fr> Message-ID: <4D4FFA3D.4010004@free.fr> Hi Jeff, sorry my example was misleading. > Then I misunderstood it's purpose. I see now that constant propagation could > remove branches because you know a value is true. I was looking at the problem > through my 'register allocator' lens. Here is a more expressive example of what > you are doing. > > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > br i1 %c, label %t2, label %f2 > t2: > code... > ret something > f2: > code... > ret something > > f: > br i1 %c, label %t3, label %f3 > t3: > code... > ret something > f3: > code... > ret something > } > > Would be changed into: > define i1 @t1(i1 %c) { > br i1 %c, label %t2, label %f3 > t2: > code... > ret something > f3: > code... > ret something > } Yes that's exactly what it would do, and this happens a lot in practice. The reason that it fires a lot in Ada code for example if that the code is full of compiler generated checks (eg: every array access is checked) and the checks often end up being repeated (eg: because you access the same array element twice). Now all the later checks are eliminated if they are implied by the earlier checks. Ciao, Duncan. > > Jeff Kunkel > On Mon, Feb 7, 2011 at 8:37 AM, Duncan Sands > wrote: > > Hi Jeff, > > > Are you sure this is really advantageous? '%c' is only one variable, but > when > you add the constant propagation, '%c' and false/true are two different > variables. Thus > > > the example was explanatory, not typical. In fact I didn't ever see returns > being split like this in practice. What I do see typically is branches > being eliminated. For example, consider the effect on bzip2: 36 branches are > completely removed, 1 is changed from conditional to unconditional, various > bits of dead code are eliminated (not a lot, 4 stores and a few computations). > I chose this example randomly, but it's typical of what I see elsewhere. > > Ciao, Duncan. > > > > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 %c > f: > ret i1 %c > } > should be > br i1 R0, label %t, label %f > t: > ret R0 > f: > ret R0 > > However, with your pass > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 true > f: > ret i1 false > } > will be > define i1 @t1(i1 %c) { > br i1 R0, label %t, label %f > t: > R1 = true > ret i1 R1 > f: > R1 = false > ret i1 R1 > } > > I am thinking X86 where '%c' would be allocated a register and the > false/true > statement would be allocated a different register which would be EAX/AX > on the > x86 machine. > > Honestly, I believe this pattern could be conditional constant propagation > / conditional re-materialization in the spiller. LLVM uses the spiller to > propagate constants. This pass would be useful to identify some conditional > re-materializations. You should look into hacking the spiller and see if > this > can be added to it. > > - My 2 cents, > Jeff Kunkel > > On Mon, Feb 7, 2011 at 7:50 AM, Duncan Sands > >> wrote: > > Hi all, I wrote a little pass (attached) which does the following: > if it sees a > conditional branch instruction then it replaces all occurrences of > the condition > in the true block with "true" and in the false block with "false". > Well, OK, it > is a bit more sophisticated (and a bit more careful!) than that but > you get the > idea. It will turn this > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 %c > f: > ret i1 %c > } > into this > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 true > f: > ret i1 false > } > for example. Curiously enough LLVM doesn't seem to have a pass that > does this. > I took a look at the effect on the testsuite by scheduling a run of > this pass > just after each run of -correlated-propagation. In spite of being > so simple > (not to say simplistic) it has an enormous positive impact on Ada > code and a > substantial positive impact throughout the LLVM test-suite (I didn't > check that > programs still work after running the pass, so it could be that it > has such a > big effect because it is wrong!). > > So... should this kind of logic be incorporated into LLVM? Perhaps > as part of > an existing pass like -correlated-propagation? > > It would be easy to make the pass a bit more powerful. For example > if the > condition was "X == 0" then it could also replace X with 0 > everywhere in the > true block. > > Ciao, Duncan. > > PS: This was inspired by PR9004. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu > > > http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > From asb at asbradbury.org Mon Feb 7 08:38:57 2011 From: asb at asbradbury.org (Alex Bradbury) Date: Mon, 7 Feb 2011 14:38:57 +0000 Subject: [LLVMdev] Promoting i16 load to i32 Message-ID: Hi, I'm working on an LLVM backend for an architecture which does not natively support half-word loads. I'm having trouble getting LLVM to promote i16 to i32 loads for me - should I expect LLVM to be able to do this, are do I have to write a custom lowerer? This post (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/019929.html) gave me the impression that it should be possible, but maybe I misinterpreted. Below is what I've tried (on an LLVM last synced with upstream ~3 weeks ago). I've set my target to promote i16 loads in its TargetLowering. setLoadExtAction(ISD::EXTLOAD, MVT::i16, Promote); setLoadExtAction(ISD::ZEXTLOAD, MVT::i16, Promote); setLoadExtAction(ISD::SEXTLOAD, MVT::i16, Promote); The DataLayout is "e-p:32:32:32-i8:8:8-i16:32:32-i32:32:32-n32" If I test with a simple function as the following (which adds two i16 arguments): define zeroext i16 @a(i16 zeroext %x, i16 zeroext %y) nounwind { entry: %x.addr = alloca i16, align 2 %y.addr = alloca i16, align 2 store i16 %x, i16* %x.addr, align 2 store i16 %y, i16* %y.addr, align 2 %tmp = load i16* %x.addr, align 2 %conv = zext i16 %tmp to i32 %tmp1 = load i16* %y.addr, align 2 %conv2 = zext i16 %tmp1 to i32 %add = add nsw i32 %conv, %conv2 %conv3 = trunc i32 %add to i16 ret i16 %conv3 } Upon compiling I get this failed assertion: llc: LegalizeDAG.cpp:1309: llvm::SDValue::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `0 && "This action is not supported yet!"' failed. I initially expected the if statement on line 1191 (in my copy), `if (SrcWidth != SrcVT.getStoreSizeInBits()` to catch my i16 promotion case - but it doesn't because SrcVT.getSizeInBits() and SrcVT.getStoreSizeInBits() equals 16 with SrcVT == MVT::i16. I'd appreciate any pointers in the right direction. Thank you, Alex From fvbommel at gmail.com Mon Feb 7 09:30:49 2011 From: fvbommel at gmail.com (Frits van Bommel) Date: Mon, 7 Feb 2011 16:30:49 +0100 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <4D4FFA3D.4010004@free.fr> References: <4D4FEA91.2090304@free.fr> <4D4FF586.9090303@free.fr> <4D4FFA3D.4010004@free.fr> Message-ID: On Mon, Feb 7, 2011 at 2:57 PM, Duncan Sands wrote: > Yes that's exactly what it would do, and this happens a lot in practice. ?The > reason that it fires a lot in Ada code for example if that the code is full of > compiler generated checks (eg: every array access is checked) and the checks > often end up being repeated (eg: because you access the same array element > twice). ?Now all the later checks are eliminated if they are implied by the > earlier checks. Of course, that only happens if the compares have already been CSE'd. And it wouldn't handle e.g. 'arr.length > 10' followed by 'arr.length > 5'... This really needs to be implemented in a more generic pass to handle cases like that (PR 9004 mentions LVI). Maybe correlated value propagation should also look at all non-constant operands of all instructions to see if LVI knows they can be replaced by constants? In fact it looks like this + SimplifyInstruction() afterwards could obsolete the special handling for select, load and store while making the pass more powerful. From grosbach at apple.com Mon Feb 7 10:13:50 2011 From: grosbach at apple.com (Jim Grosbach) Date: Mon, 7 Feb 2011 08:13:50 -0800 Subject: [LLVMdev] Running the programs in the LLVM test suite with a pass and without it. In-Reply-To: References: Message-ID: <119D76C5-B7F5-44EA-924E-597327A59732@apple.com> Hi Douglas, Yes, you can use the "llc-beta" test suite option to do what you're looking for. That runs the tests with and without a set of command line options and provides a comparison. 1. Make your pass disabled by default and enabled via a command line option (e.g., --enable-mypass), 2. Tell the test-suite Makefiles to run your pass as the beta option*,. Look in Hi guys, > > I have a pass called "MyPass". And I can run this pass in the LLVM test suite programs and produce a report with the statistics of the execution of this pass. Now, I would like to run the programs in LLVM test suite and generate a report comparing the results obtained without using the pass with the results obtained using the pass. Is there any way to do this? > > Thank you, > > Douglas > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From jnspaulsson at hotmail.com Mon Feb 7 10:42:32 2011 From: jnspaulsson at hotmail.com (Jonas Paulsson) Date: Mon, 7 Feb 2011 17:42:32 +0100 Subject: [LLVMdev] post-inc loads/stores Message-ID: Hi, I would like to know how I should define these types of instructions in LLVM. I have for instance a load instruction that increments the address-register. I do not know how I should mark this - should the address register as well be in the outs list, or should some other flag be set, perhaps? Thank you, /Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110207/b69e991a/attachment.html From grosbach at apple.com Mon Feb 7 10:57:41 2011 From: grosbach at apple.com (Jim Grosbach) Date: Mon, 7 Feb 2011 08:57:41 -0800 Subject: [LLVMdev] post-inc loads/stores In-Reply-To: References: Message-ID: <1865B880-020D-4274-8215-2F0338FB9C67@apple.com> Hi Jonas, There's not really a very clean way to do this currently. The ARM backend does it as you indicate with the writeback register listed as an output as well as an input and marked as a tied operand constraint. Search for _PRE and _POST in ARMInstrInfo.td for examples. For most instances, instruction selection is done via custom lowering, not an ISel pattern on the pattern; see ARMISelLowering.cpp for that. -Jim On Feb 7, 2011, at 8:42 AM, Jonas Paulsson wrote: > Hi, > > I would like to know how I should define these types of instructions in LLVM. > > I have for instance a load instruction that increments the address-register. I do not know how I should mark this - should the address register as well be in the outs list, or should some other flag be set, perhaps? > > Thank you, > > /Jonas > > _______________________________________________ > 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 Feb 7 11:18:48 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 7 Feb 2011 20:18:48 +0300 Subject: [LLVMdev] post-inc loads/stores In-Reply-To: References: Message-ID: Hello Jonas, > I have for instance a load instruction that increments the address-register. > I do not know how I should mark this - should the address register as well > be in the outs list, or should some other flag be set, perhaps? You might consider looking into ARM and MSP430 backends for examples. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From bob.wilson at apple.com Mon Feb 7 11:33:59 2011 From: bob.wilson at apple.com (Bob Wilson) Date: Mon, 7 Feb 2011 09:33:59 -0800 Subject: [LLVMdev] post-inc loads/stores In-Reply-To: <1865B880-020D-4274-8215-2F0338FB9C67@apple.com> References: <1865B880-020D-4274-8215-2F0338FB9C67@apple.com> Message-ID: <7D0E4F5C-D66E-4BEF-8DE8-1FEA7F32A682@apple.com> On Feb 7, 2011, at 8:57 AM, Jim Grosbach wrote: > Hi Jonas, > > There's not really a very clean way to do this currently. The ARM backend does it as you indicate with the writeback register listed as an output as well as an input and marked as a tied operand constraint. Search for _PRE and _POST in ARMInstrInfo.td for examples. For most instances, instruction selection is done via custom lowering, not an ISel pattern on the pattern; see ARMISelLowering.cpp for that. Specifically, there is no way to use a pattern in the .td file for an instruction that produces multiple results. That is why the updating loads are selected with custom C++ code. For updating stores, the updated address is the only result and they can generally be selected from patterns in the .td files. From bob.wilson at apple.com Mon Feb 7 12:09:43 2011 From: bob.wilson at apple.com (Bob Wilson) Date: Mon, 7 Feb 2011 10:09:43 -0800 Subject: [LLVMdev] Post-inc combining In-Reply-To: References: <62F916FB-DF49-4A51-B721-2A5989619209@apple.com> Message-ID: On Feb 6, 2011, at 11:32 PM, Jonas Paulsson wrote: > When I compile the following program (for ARM): > > for(i=0;i { > s+=a[i]; > } > > , with GCC, I get the following loop body, with a post-modify load: > > .L4: > add r1, r1, r3 > ldr r4, [ip], r6 > rsb r5, r3, r1 > cmp r2, r5 > add r0, r0, r4 > bgt .L4 > > With LLVM, however, I get: > > .LBB0_3: @ %for.body > @ =>This Inner Loop Header: Depth=1 > add r12, lr, r3 > ldr lr, [r0, lr, lsl #2] > add r1, lr, r1 > cmp r12, r2 > mov lr, r12 > blt .LBB0_3 > > , which does not seem to be auto-incrementing, I think. No, it's not using a post-increment load. There are two separate requirements to make this happen: * LSR (the loop strength reduce pass) needs to transform the loop so that the load address is a simple induction variable. * The instruction selection needs to recognize the opportunity for folding the address increment into the load. In this case, LSR is not doing the right thing. > > I wonder what I should do to get loops auto-incing generally, for instance in this simple loop: > > for(i=0;i<256;i++) > { > s+=a[i]; > } > > , which now yields > > .LBB0_1: @ %for.body > @ =>This Inner Loop Header: Depth=1 > ldr r3, [r0, r2] > add r2, r2, #4 > add r1, r3, r1 > cmp r2, #1, 22 @ 1024 > bne .LBB0_1 > > , which uses r0 as base address with r2 as offset. On my target, it is much preferred to use auto-inc in cases like this. I repeat my question, as I don't quite understand why the ldr/add is used by ARM here, instead of post-inc. I guess I would like the DAG combiner to work in cases like this, but it does not seem to do so. Same issue. The DAG combiner can't handle it because LSR didn't expose the load address as a simple induction variable. E.G., if the code was something like: ldr r3, [r2] add r2, r2, #4 ...then the DAG combiner could do something with it. Feel free to file a bug report on these issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110207/6382e429/attachment.html From baldrick at free.fr Mon Feb 7 13:54:08 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 07 Feb 2011 20:54:08 +0100 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <4D4FEA91.2090304@free.fr> References: <4D4FEA91.2090304@free.fr> Message-ID: <4D504DE0.20605@free.fr> Here is a new and improved version that also does the following: if the condition for a conditional branch has the form "A && B" then A, B and the condition are all replaced with "true" in the true destination (similarly for || conditions in the false destination). Also, if the condition has the form "X == Y" then X is replaced by Y everywhere in the true destination (likewise if it is "X != Y" then X is replaced by Y everywhere in the false destination). Completely untested for correctness! Scheduling this pass after -correlated-propagation results for example in 5759 lines of bitcode being removed from 403.gcc. Ciao, Duncan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Prop.cpp Type: text/x-c++src Size: 5959 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110207/dd59aa72/attachment.bin From fvbommel at gmail.com Mon Feb 7 14:16:12 2011 From: fvbommel at gmail.com (Frits van Bommel) Date: Mon, 7 Feb 2011 21:16:12 +0100 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <4D504DE0.20605@free.fr> References: <4D4FEA91.2090304@free.fr> <4D504DE0.20605@free.fr> Message-ID: On Mon, Feb 7, 2011 at 8:54 PM, Duncan Sands wrote: > Here is a new and improved version that also does the following: if the > condition for a conditional branch has the form "A && B" then A, B and the > condition are all replaced with "true" in the true destination (similarly > for || conditions in the false destination). ?Also, if the condition has > the form "X == Y" then X is replaced by Y everywhere in the true destination > (likewise if it is "X != Y" then X is replaced by Y everywhere in the false > destination). ?Completely untested for correctness! I also had a try at this, integrating it with the existing correlated value propagation pass. See . I haven't tried if it provides all of the extra things this latest version does though. (It probably doesn't handle the 'X == Y' case where neither is a constant) My version has some tests and passes 'make check-all'. > Scheduling this pass after -correlated-propagation results for example in > 5759 lines of bitcode being removed from 403.gcc. I didn't gather any statistics on it though. From baldrick at free.fr Mon Feb 7 14:46:30 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 07 Feb 2011 21:46:30 +0100 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: References: <4D4FEA91.2090304@free.fr> <4D504DE0.20605@free.fr> Message-ID: <4D505A26.1050107@free.fr> Hi Frits, >> Here is a new and improved version that also does the following: if the >> condition for a conditional branch has the form "A&& B" then A, B and the >> condition are all replaced with "true" in the true destination (similarly >> for || conditions in the false destination). Also, if the condition has >> the form "X == Y" then X is replaced by Y everywhere in the true destination >> (likewise if it is "X != Y" then X is replaced by Y everywhere in the false >> destination). Completely untested for correctness! > > I also had a try at this, integrating it with the existing correlated > value propagation pass. See > . I will reply properly tomorrow, but for now let me just remark that querying LVI for everything is probably very slow. In fact I'm pretty sure that the reason it only calculates things lazily is that calculating for everything would take too much compile time. And doubtless this is the reason why the correlated value propagation pass only analyses a very limited set of instructions. The big advantage of my technique is that it is fast. The disadvantage is that it is rather limited in what it can do. Maybe some kind of combination would be good: add the logic from my pass to correlated value propagation to quickly forward propagate equality information from branch conditions, and reserve LVI for analysing a small amount of important instructions. Ciao, Duncan. From viridia at gmail.com Mon Feb 7 14:52:18 2011 From: viridia at gmail.com (Talin) Date: Mon, 7 Feb 2011 12:52:18 -0800 Subject: [LLVMdev] ConstantBuilder proposal In-Reply-To: References: Message-ID: On Fri, Feb 4, 2011 at 2:12 PM, Frits van Bommel wrote: > If you remove all the 'static's from the member functions, it'd work > more like IRBuilder. > It would also allow you to take the LLVMContext& as a constructor > parameter, so that methods like this: > > On Fri, Feb 4, 2011 at 6:57 PM, Talin wrote: > > /// GetStruct - return a constant struct given a context and a vector > > /// of elements. > > static Constant *GetStruct( > > LLVMContext &Context, > > const std::vector &V, > > bool Packed = false) { > > return ConstantStruct::get(Context, V, Packed); > > } > > can remove it from their parameter list. It's probably pretty unlikely > a given ConstantBuilder instance would be used with multiple > LLVMContexts. > > Making this a class you need an instance of would likely also allow > typing to be reduced a bit because said instance can be given a > shorter name than 'ConstantBuilder'. For example: 'cb.GetStruct(...)' > instead of 'ConstantBuilder::GetStruct(MyContext, ...)'. > Actually, my main question is whether there is even interest in this - I'm happy to write all the docs and unit tests, but only if this is something that people want. I know that it makes my life a lot easier to be able to create constant structs and arrays like this, but I can do that just as easily in my own project. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110207/3194ceb8/attachment.html From duan11 at illinois.edu Mon Feb 7 16:13:44 2011 From: duan11 at illinois.edu (Yuelu Duan) Date: Mon, 7 Feb 2011 16:13:44 -0600 Subject: [LLVMdev] A question about LICM (Loop Invariant Code Motion) Message-ID: Hi, I recently looked into the LICM(Loop Invariant Code Motion) pass of LLVM and got a question about hoist load instruction to loop preheader. I would like to show two examples: Example 1: int func(int n, int *fp) { int i; int a[1000]; for (i = 0; i < n; ++i) { a[i] += *fp; // load from *fp pointer, no hoist } } Here, load *fp CAN NOT be hoisted to loop preheader. If replace *fp with an local pointer, the load can not be hoisted either. However, with this example: int gv = 3;//global var int func(int n) { int i; int a[1000]; for (i = 0; i < n; ++i) { a[i] += gv; // load from the @gv pointer, hoist } } load for the global var gv's value CAN be hoist to loop preheader. After tracking the LICM pass, I find that both loads are loop invariant, and canSinkOrHoist() also returns true; however the difference is at Instruction::isSafeToSpeculativelyExecute(), for load from function parameter pointer, it return false; with load from a global var pointer, it returns true. As a result no hoist happens for a load *fp: **LICM.cpp if (isLoopInvariantInst(I) && canSinkOrHoistInst(I) && isSafeToExecuteUnconditionally(I)) // invokes I->IsSafeToSpeculativelyExecute() hoist(I); But I do not know why we need to treat fp/local pointer different with global pointer here. I think hoisting fp/local pointers should be fine if they are loop invariant and does not alias with other pointers.. Anyone can help me to figure this out? Thank you very much. -Yuelu, UIUC From bhurt at spnz.org Mon Feb 7 17:28:32 2011 From: bhurt at spnz.org (Brian Hurt) Date: Mon, 7 Feb 2011 18:28:32 -0500 (EST) Subject: [LLVMdev] Newbie Question: not using local variables Message-ID: I'm writing an ML-like language, and using LLVM as my target back end. I have one question though, and thought I'd throw it out onto the list. In my language, variables aren't mutable- once assigned, they can be shadowed, but not changed. And shadowing of variables is handled by alpha-renaming. What I mean by this that when I see: let x = 3 in ... the value of x can not be changed. It can be shadowed, like: let x = f () in let x = x + 4 in ... but one of the first things I do is rename all the variables so they're unique, so the above code might get changed into: let x_5734 = f () in let x_8643 = x_5734 + 4 in ... Now, my question is this: is there any downside to not having any stack-based local variables at all- just put everything into registers and let the register allocation code decide what needs to get spilled onto the stack? In other words, is there any problem with generating the following IR for the above code: %r17 = call i64 @f(i64 0) %r18 = add i64 %r17 4 The upside of doing this is simpler code generation, and hopefully more efficient code, as I am explicitly telling the optimizer I don't care where this variable lives. But, I'm somewhat worried that by not having any local variables at all, this may put too much pressure on the register allocator (especially for large functions). Also, how to attach debugging information to a register is something I need to figure out. Thoughts? Opinions? Is this a good way to proceed, or a bad way? Brian From reid.kleckner at gmail.com Mon Feb 7 17:57:31 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Mon, 7 Feb 2011 18:57:31 -0500 Subject: [LLVMdev] Newbie Question: not using local variables In-Reply-To: References: Message-ID: It should work fine, since one of the first things LLVM does is to turn as many allocas into registers as it can via mem2reg. Reid On Mon, Feb 7, 2011 at 6:28 PM, Brian Hurt wrote: > > I'm writing an ML-like language, and using LLVM as my target back end. ?I > have one question though, and thought I'd throw it out onto the list. ?In > my language, variables aren't mutable- once assigned, they can be > shadowed, but not changed. ?And shadowing of variables is handled by > alpha-renaming. ?What I mean by this that when I see: > ? ? ? ?let x = 3 in ... > the value of x can not be changed. ?It can be shadowed, like: > ? ? ? ?let x = f () in > ? ? ? ?let x = x + 4 in > ? ? ? ?... > but one of the first things I do is rename all the variables so they're > unique, so the above code might get changed into: > ? ? ? ?let x_5734 = f () in > ? ? ? ?let x_8643 = x_5734 + 4 in > ? ? ? ?... > > Now, my question is this: is there any downside to not having any > stack-based local variables at all- just put everything into registers and > let the register allocation code decide what needs to get spilled onto the > stack? ?In other words, is there any problem with generating the following > IR for the above code: > ? ? ? ?%r17 = call i64 @f(i64 0) > ? ? ? ?%r18 = add i64 %r17 4 > > The upside of doing this is simpler code generation, and hopefully more > efficient code, as I am explicitly telling the optimizer I don't care > where this variable lives. > > But, I'm somewhat worried that by not having any local variables at all, > this may put too much pressure on the register allocator (especially for > large functions). ?Also, how to attach debugging information to a register > is something I need to figure out. > > Thoughts? ?Opinions? ?Is this a good way to proceed, or a bad way? > > Brian > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From anton.skvorts at gmail.com Mon Feb 7 19:35:27 2011 From: anton.skvorts at gmail.com (Anton Skvorts) Date: Tue, 8 Feb 2011 01:35:27 +0000 Subject: [LLVMdev] Question about linker error Message-ID: Hello all, When extending the tutorial to support global variables I'm getting the following linker error: glob.o:glob.cpp:(.text+0x12241): undefined reference to `vtable for GlobalExprAST' collect2: ld returned 1 exit status GlobalExprAST class is: /// GlobalExprAST - Expression class for globals class GlobalExprAST : public ExprAST { std::string Name; ExprAST *Init; public: GlobalExprAST(const std::string &name, ExprAST *init) : Name(name), Init(init) {} virtual Value *Codegen(); }; /// Parser /// ::= 'global' identifier ('=' expression)? static ExprAST *ParseGlobalExpr() { getNextToken(); std::string Name = IdentifierStr; getNextToken(); ExprAST *Init = 0; if (CurTok == '=') { getNextToken(); Init = ParseExpression(); if (Init == 0) return 0; } return new GlobalExprAST(Name, Init); } Any help would be much appreaciated! Anton From rjmccall at apple.com Mon Feb 7 19:41:27 2011 From: rjmccall at apple.com (John McCall) Date: Mon, 7 Feb 2011 17:41:27 -0800 Subject: [LLVMdev] Newbie Question: not using local variables In-Reply-To: References: Message-ID: On Feb 7, 2011, at 3:28 PM, Brian Hurt wrote: > > I'm writing an ML-like language, and using LLVM as my target back end. I > have one question though, and thought I'd throw it out onto the list. In > my language, variables aren't mutable- once assigned, they can be > shadowed, but not changed. And shadowing of variables is handled by > alpha-renaming. What I mean by this that when I see: > let x = 3 in ... > the value of x can not be changed. It can be shadowed, like: > let x = f () in > let x = x + 4 in > ... > but one of the first things I do is rename all the variables so they're > unique, so the above code might get changed into: > let x_5734 = f () in > let x_8643 = x_5734 + 4 in > ... > > Now, my question is this: is there any downside to not having any > stack-based local variables at all- just put everything into registers and > let the register allocation code decide what needs to get spilled onto the > stack? In other words, is there any problem with generating the following > IR for the above code: > %r17 = call i64 @f(i64 0) > %r18 = add i64 %r17 4 > > The upside of doing this is simpler code generation, and hopefully more > efficient code, as I am explicitly telling the optimizer I don't care > where this variable lives. > > But, I'm somewhat worried that by not having any local variables at all, > this may put too much pressure on the register allocator (especially for > large functions). What Reid said, plus: the worst case of putting pressure on the register allocator is that it spills something to the stack. Forcing the use of local variables, by contrast, is basically just spilling to the stack all the time, so you're no better off than you were before. John. From reid.kleckner at gmail.com Mon Feb 7 20:35:06 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Mon, 7 Feb 2011 21:35:06 -0500 Subject: [LLVMdev] Question about linker error In-Reply-To: References: Message-ID: Guessing here, but I think the Codegen method is a "key" method. Normally the compiler emits weak definitions for things like inline functions, vtables, and other data associated with the class definition, but if it spots a key method definition, rather than duplicating all that crap in every translation unit, it will trust that whichever TU defines any key method will emit the vtable and the rest of the data. See if providing a definition of Codegen in a .cpp file fixes your problem. Reid On Mon, Feb 7, 2011 at 8:35 PM, Anton Skvorts wrote: > Hello all, > > When extending the tutorial to support global variables I'm getting > the following linker error: > > glob.o:glob.cpp:(.text+0x12241): undefined reference to `vtable for > GlobalExprAST' > collect2: ld returned 1 exit status > > GlobalExprAST class is: > > /// GlobalExprAST - Expression class for globals > class GlobalExprAST : public ExprAST { > ?std::string Name; > ?ExprAST *Init; > public: > ?GlobalExprAST(const std::string &name, ExprAST *init) > ?: Name(name), Init(init) {} > > ?virtual Value *Codegen(); > }; > > > /// Parser > /// ::= 'global' identifier ('=' expression)? > static ExprAST *ParseGlobalExpr() { > ? ?getNextToken(); > > ? ?std::string Name = IdentifierStr; > ? ?getNextToken(); > > ? ?ExprAST *Init = 0; > ? ?if (CurTok == '=') { > ? ? ?getNextToken(); > > ? ? ?Init = ParseExpression(); > ? ? ?if (Init == 0) return 0; > ? ?} > ?return new GlobalExprAST(Name, Init); > } > > Any help would be much appreaciated! > Anton > _______________________________________________ > 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 Mon Feb 7 23:38:42 2011 From: resistor at mac.com (Owen Anderson) Date: Mon, 07 Feb 2011 21:38:42 -0800 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <4D4FEA91.2090304@free.fr> References: <4D4FEA91.2090304@free.fr> Message-ID: <2BE122D0-4137-468C-A2EE-67C384BD0D6E@mac.com> Duncan, GVN already does this. See lines 1669-1689. --Owen On Feb 7, 2011, at 4:50 AM, Duncan Sands wrote: > Hi all, I wrote a little pass (attached) which does the following: if it sees a > conditional branch instruction then it replaces all occurrences of the condition > in the true block with "true" and in the false block with "false". Well, OK, it > is a bit more sophisticated (and a bit more careful!) than that but you get the > idea. It will turn this > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 %c > f: > ret i1 %c > } > into this > define i1 @t1(i1 %c) { > br i1 %c, label %t, label %f > t: > ret i1 true > f: > ret i1 false > } > for example. Curiously enough LLVM doesn't seem to have a pass that does this. > I took a look at the effect on the testsuite by scheduling a run of this pass > just after each run of -correlated-propagation. In spite of being so simple > (not to say simplistic) it has an enormous positive impact on Ada code and a > substantial positive impact throughout the LLVM test-suite (I didn't check that > programs still work after running the pass, so it could be that it has such a > big effect because it is wrong!). > > So... should this kind of logic be incorporated into LLVM? Perhaps as part of > an existing pass like -correlated-propagation? > > It would be easy to make the pass a bit more powerful. For example if the > condition was "X == 0" then it could also replace X with 0 everywhere in the > true block. > > Ciao, Duncan. > > PS: This was inspired by PR9004. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From eschew at gmail.com Tue Feb 8 00:05:35 2011 From: eschew at gmail.com (Ben Karel) Date: Tue, 8 Feb 2011 01:05:35 -0500 Subject: [LLVMdev] Newbie Question: not using local variables In-Reply-To: References: Message-ID: Hello Brian, There is actually one potential downside to using only LLVM registers: it will (at the moment) prevent you from using any sort of moving garbage collector (copying, compacting, or generational) for your language. The reason is that LLVM's garbage collection infrastructure does not (yet) compute register maps, only stack maps, and thus does not automatically re-load potentially moved pointers after safe points. Also, IIRC debug metadata must be attached to stack slots. But these issues are not worth worrying about yet. Do the simple, clear, and obvious thing first, then change tack if it proves to be insufficient for your needs. Have fun! -- Ben On Mon, Feb 7, 2011 at 6:28 PM, Brian Hurt wrote: > > I'm writing an ML-like language, and using LLVM as my target back end. I > have one question though, and thought I'd throw it out onto the list. In > my language, variables aren't mutable- once assigned, they can be > shadowed, but not changed. And shadowing of variables is handled by > alpha-renaming. What I mean by this that when I see: > let x = 3 in ... > the value of x can not be changed. It can be shadowed, like: > let x = f () in > let x = x + 4 in > ... > but one of the first things I do is rename all the variables so they're > unique, so the above code might get changed into: > let x_5734 = f () in > let x_8643 = x_5734 + 4 in > ... > > Now, my question is this: is there any downside to not having any > stack-based local variables at all- just put everything into registers and > let the register allocation code decide what needs to get spilled onto the > stack? In other words, is there any problem with generating the following > IR for the above code: > %r17 = call i64 @f(i64 0) > %r18 = add i64 %r17 4 > > The upside of doing this is simpler code generation, and hopefully more > efficient code, as I am explicitly telling the optimizer I don't care > where this variable lives. > > But, I'm somewhat worried that by not having any local variables at all, > this may put too much pressure on the register allocator (especially for > large functions). Also, how to attach debugging information to a register > is something I need to figure out. > > Thoughts? Opinions? Is this a good way to proceed, or a bad way? > > Brian > _______________________________________________ > 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/20110208/66673963/attachment.html From nicholas at mxc.ca Tue Feb 8 02:54:22 2011 From: nicholas at mxc.ca (Nick Lewycky) Date: Tue, 08 Feb 2011 00:54:22 -0800 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <4D504DE0.20605@free.fr> References: <4D4FEA91.2090304@free.fr> <4D504DE0.20605@free.fr> Message-ID: <4D5104BE.5010707@mxc.ca> Duncan Sands wrote: > Here is a new and improved version that also does the following: if the > condition for a conditional branch has the form "A && B" then A, B and the > condition are all replaced with "true" in the true destination (similarly > for || conditions in the false destination). Also, if the condition has > the form "X == Y" then X is replaced by Y everywhere in the true > destination > (likewise if it is "X != Y" then X is replaced by Y everywhere in the false > destination). Completely untested for correctness! Not to discourage you, but you're reinventing predsimplify. What PS did was find branches (or switches) where the target block was uniquely dominated by a single case, then assign %cond = true/false (or %switchval = const) and then walk up propagating that condition upwards (ie., if %cond = and i1 %a, %b then %a and %b are true, and if %a = icmp eq i32 %a, i32 0 then PS would immediately find all uses of %a dominated by that branch and replace them with 0 on the spot). After walking up, you would walk down again with what you learned; for example you may have done %A = add %X, %Y way early on and know in this lower branch that %Y is 0, now %A = %X. PS had a full comparison lattice (not-equals, signed-lessthan-unsigned-greaterthan) and also grew constant range analysis (x < y implies x != -1 and y != 0). While I know PS removed tons of code from the .ll I was never really able to detect a runtime performance improvement; my guess is that while I was killing off lots of dead code it didn't impact the performance of the live code much or at all. Nick > Scheduling this pass after -correlated-propagation results for example in > 5759 lines of bitcode being removed from 403.gcc. > > 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 marks at dcs.gla.ac.uk Tue Feb 8 03:15:07 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Tue, 08 Feb 2011 09:15:07 +0000 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <4D5104BE.5010707@mxc.ca> References: <4D4FEA91.2090304@free.fr> <4D504DE0.20605@free.fr> <4D5104BE.5010707@mxc.ca> Message-ID: <4D51099B.80605@dcs.gla.ac.uk> Nick Lewycky wrote: > Duncan Sands wrote: >> Here is a new and improved version that also does the following: if the >> condition for a conditional branch has the form "A && B" then A, B and the >> condition are all replaced with "true" in the true destination (similarly >> for || conditions in the false destination). Also, if the condition has >> the form "X == Y" then X is replaced by Y everywhere in the true >> destination >> (likewise if it is "X != Y" then X is replaced by Y everywhere in the false >> destination). Completely untested for correctness! > > Not to discourage you, but you're reinventing predsimplify. > > What PS did was find branches (or switches) where the target block was > uniquely dominated by a single case, then assign %cond = true/false (or > %switchval = const) and then walk up propagating that condition upwards > (ie., if %cond = and i1 %a, %b then %a and %b are true, and if %a = icmp > eq i32 %a, i32 0 then PS would immediately find all uses of %a dominated > by that branch and replace them with 0 on the spot). After walking up, > you would walk down again with what you learned; for example you may > have done %A = add %X, %Y way early on and know in this lower branch > that %Y is 0, now %A = %X. PS had a full comparison lattice (not-equals, > signed-lessthan-unsigned-greaterthan) and also grew constant range > analysis (x < y implies x != -1 and y != 0). > > While I know PS removed tons of code from the .ll I was never really > able to detect a runtime performance improvement; my guess is that while > I was killing off lots of dead code it didn't impact the performance of > the live code much or at all. > Killing off lots of dead code is going to improve compile time, since code-gen time tends to dominate optimise time. Improving compile time is important for those of us using the JIT compiler. Mark. > Nick > >> Scheduling this pass after -correlated-propagation results for example in >> 5759 lines of bitcode being removed from 403.gcc. >> >> 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 > . > From baldrick at free.fr Tue Feb 8 03:55:44 2011 From: baldrick at free.fr (Duncan Sands) Date: Tue, 08 Feb 2011 10:55:44 +0100 Subject: [LLVMdev] A question about LICM (Loop Invariant Code Motion) In-Reply-To: References: Message-ID: <4D511320.20107@free.fr> Hi Yuelu, > After tracking the LICM pass, I find that both loads are loop > invariant, and canSinkOrHoist() also returns true; however the > difference is at Instruction::isSafeToSpeculativelyExecute(), > for load from function parameter pointer, it return false; with load > from a global var pointer, it returns true. As a result no hoist > happens for a load *fp: the function parameter pointer might be null. Ciao, Duncan. From baldrick at free.fr Tue Feb 8 04:03:20 2011 From: baldrick at free.fr (Duncan Sands) Date: Tue, 08 Feb 2011 11:03:20 +0100 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <2BE122D0-4137-468C-A2EE-67C384BD0D6E@mac.com> References: <4D4FEA91.2090304@free.fr> <2BE122D0-4137-468C-A2EE-67C384BD0D6E@mac.com> Message-ID: <4D5114E8.8040302@free.fr> Hi Owen, > GVN already does this. See lines 1669-1689. you are mistaken. If you try running GVN on the example you will see that it doesn't do anything to it. The problem is that GVN only applies its logic when it simplifies an expression due to value numbering. If value numbering gives nothing (like for the returns in the example) then it doesn't do anything. I first noticed this because instsimplify improvements mean that GVN's value numbering catches less stuff (because it was caught earlier) and thus its correlated expression logic doesn't kick in resulting in less simplifications, i.e. improving instsimplify can cause regressions due to this GVN flaw. I opened PR9004 for this. Ciao, Duncan. > > --Owen > > On Feb 7, 2011, at 4:50 AM, Duncan Sands wrote: > >> Hi all, I wrote a little pass (attached) which does the following: if it sees a >> conditional branch instruction then it replaces all occurrences of the condition >> in the true block with "true" and in the false block with "false". Well, OK, it >> is a bit more sophisticated (and a bit more careful!) than that but you get the >> idea. It will turn this >> define i1 @t1(i1 %c) { >> br i1 %c, label %t, label %f >> t: >> ret i1 %c >> f: >> ret i1 %c >> } >> into this >> define i1 @t1(i1 %c) { >> br i1 %c, label %t, label %f >> t: >> ret i1 true >> f: >> ret i1 false >> } >> for example. Curiously enough LLVM doesn't seem to have a pass that does this. >> I took a look at the effect on the testsuite by scheduling a run of this pass >> just after each run of -correlated-propagation. In spite of being so simple >> (not to say simplistic) it has an enormous positive impact on Ada code and a >> substantial positive impact throughout the LLVM test-suite (I didn't check that >> programs still work after running the pass, so it could be that it has such a >> big effect because it is wrong!). >> >> So... should this kind of logic be incorporated into LLVM? Perhaps as part of >> an existing pass like -correlated-propagation? >> >> It would be easy to make the pass a bit more powerful. For example if the >> condition was "X == 0" then it could also replace X with 0 everywhere in the >> true block. >> >> Ciao, Duncan. >> >> PS: This was inspired by PR9004. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From reid.kleckner at gmail.com Tue Feb 8 09:36:29 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Tue, 8 Feb 2011 10:36:29 -0500 Subject: [LLVMdev] A question about LICM (Loop Invariant Code Motion) In-Reply-To: <4D511320.20107@free.fr> References: <4D511320.20107@free.fr> Message-ID: On Tue, Feb 8, 2011 at 4:55 AM, Duncan Sands wrote: > Hi Yuelu, > >> After tracking the LICM pass, I find that both loads are loop >> invariant, and canSinkOrHoist() also returns true; however the >> difference is at Instruction::isSafeToSpeculativelyExecute(), >> for load from function parameter pointer, it return false; with load >> from a global var pointer, it returns true. As a result no hoist >> happens for a load *fp: > > the function parameter pointer might be null. I suppose you could peel a single iteration to try to work around that. Reid From criswell at illinois.edu Tue Feb 8 10:00:24 2011 From: criswell at illinois.edu (John Criswell) Date: Tue, 8 Feb 2011 10:00:24 -0600 Subject: [LLVMdev] Forward/Backward Interprocedural Slicing in LLVM In-Reply-To: <4D06422C.9020800@cs.wisc.edu> References: <4D06422C.9020800@cs.wisc.edu> Message-ID: <4D516898.1090802@illinois.edu> On 12/13/10 9:56 AM, Rohit wrote: > Hi All, > > Are there any known implementations of static inter-procedural slicing > for LLVM (especially forward slicing)? > I did find a few references to it in the archives dating back to 2008, > but am not sure what the current status is. > Any pointers would be highly appreciated. Hi Rohit. Sorry for the extremely late reply; I was cleaning out my INBOX when I saw your message. We at Illinois have a partial backwards static inter-procedural slicing pass for LLVM 2.6. It will trace back through arguments but will not trace back from loads to potentially reaching stores. You'd have to use a points-to analysis (like DSA) and add some enhancements to the code to do that. If you'd like to have that code, just let me know, and I'll ask our advisor about it. -- John T. > Thanks > Rohit > > Grad Student > Middleware Security and Testing Group > http://cs.wisc.edu/mist > University of Wisconsin-Madison > _______________________________________________ > 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 Tue Feb 8 11:17:20 2011 From: resistor at mac.com (Owen Anderson) Date: Tue, 08 Feb 2011 09:17:20 -0800 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <4D51099B.80605@dcs.gla.ac.uk> References: <4D4FEA91.2090304@free.fr> <4D504DE0.20605@free.fr> <4D5104BE.5010707@mxc.ca> <4D51099B.80605@dcs.gla.ac.uk> Message-ID: <1E3A5FC9-DFBC-422B-844C-6F1BEDA00439@mac.com> On Feb 8, 2011, at 1:15 AM, Mark Shannon wrote: > Nick Lewycky wrote: >> Duncan Sands wrote: >>> Here is a new and improved version that also does the following: if the >>> condition for a conditional branch has the form "A && B" then A, B and the >>> condition are all replaced with "true" in the true destination (similarly >>> for || conditions in the false destination). Also, if the condition has >>> the form "X == Y" then X is replaced by Y everywhere in the true >>> destination >>> (likewise if it is "X != Y" then X is replaced by Y everywhere in the false >>> destination). Completely untested for correctness! >> >> Not to discourage you, but you're reinventing predsimplify. >> >> What PS did was find branches (or switches) where the target block was >> uniquely dominated by a single case, then assign %cond = true/false (or >> %switchval = const) and then walk up propagating that condition upwards >> (ie., if %cond = and i1 %a, %b then %a and %b are true, and if %a = icmp >> eq i32 %a, i32 0 then PS would immediately find all uses of %a dominated >> by that branch and replace them with 0 on the spot). After walking up, >> you would walk down again with what you learned; for example you may >> have done %A = add %X, %Y way early on and know in this lower branch >> that %Y is 0, now %A = %X. PS had a full comparison lattice (not-equals, >> signed-lessthan-unsigned-greaterthan) and also grew constant range >> analysis (x < y implies x != -1 and y != 0). >> >> While I know PS removed tons of code from the .ll I was never really >> able to detect a runtime performance improvement; my guess is that while >> I was killing off lots of dead code it didn't impact the performance of >> the live code much or at all. >> > > Killing off lots of dead code is going to improve compile time, > since code-gen time tends to dominate optimise time. > > Improving compile time is important for those of us using the JIT compiler. Except PredSimplify was also a big compile time sink, and didn't make up for any benefits it gave on that front. --Owen From baldrick at free.fr Tue Feb 8 11:55:26 2011 From: baldrick at free.fr (Duncan Sands) Date: Tue, 08 Feb 2011 18:55:26 +0100 Subject: [LLVMdev] A small pass to constant fold branch conditions in destination blocks In-Reply-To: <1E3A5FC9-DFBC-422B-844C-6F1BEDA00439@mac.com> References: <4D4FEA91.2090304@free.fr> <4D504DE0.20605@free.fr> <4D5104BE.5010707@mxc.ca> <4D51099B.80605@dcs.gla.ac.uk> <1E3A5FC9-DFBC-422B-844C-6F1BEDA00439@mac.com> Message-ID: <4D51838E.1050000@free.fr> >>> While I know PS removed tons of code from the .ll I was never really >>> able to detect a runtime performance improvement; my guess is that while >>> I was killing off lots of dead code it didn't impact the performance of >>> the live code much or at all. >>> >> >> Killing off lots of dead code is going to improve compile time, >> since code-gen time tends to dominate optimise time. >> >> Improving compile time is important for those of us using the JIT compiler. > > Except PredSimplify was also a big compile time sink, and didn't make up for any benefits it gave on that front. A big advantage of my pass is that it seems to be pretty quick. That's because it doesn't try to go beyond simple propagation of equalities. Ciao, Duncan. From dpatel at apple.com Tue Feb 8 12:44:00 2011 From: dpatel at apple.com (Devang Patel) Date: Tue, 8 Feb 2011 10:44:00 -0800 Subject: [LLVMdev] Newbie Question: not using local variables In-Reply-To: References: Message-ID: On Feb 7, 2011, at 10:05 PM, Ben Karel wrote: > Also, IIRC debug metadata must be attached to stack slots. FWIW this is was true in past but not strictly true anymore, though it is a road less travelled at -O0. One would normally use @llvm.dbg.declare intrinsic to map variable info with the stack slots. Now, you can use @llvm.dbg.value intrinsic to map variable info with a llvm register. - Devang From dpatel at apple.com Tue Feb 8 12:51:31 2011 From: dpatel at apple.com (Devang Patel) Date: Tue, 8 Feb 2011 10:51:31 -0800 Subject: [LLVMdev] Debug info generation through llvm backend In-Reply-To: References: Message-ID: On Feb 6, 2011, at 8:52 PM, sivakumar srinivasan wrote: > Hi Everyone, > > I am really new to LLVM. I am working on something where I had to pick-up a half-cooked backend and need to add debug support to it. I have searched through messages but could not find a nice starting place. Could some one please provide me with some pointers about > - what is already supported in llvm as far as emitting debugging information is concerned? > - how to emit debug information through a llvm backend (any step-by-step process)? > - any existing implementation? x86, ARM etc.. backends now emit debug info in DWARF format. To understand how it works, follow how @llvm.dbg.declare and @llvm.dbg.value intrinsics are lowered, at instruction selection time, from LLVM IR into machine instructions. Most of the work required here is target independent (note, DWARF format is also used to encode EH info, which is a separate story). Target independent AsmPrinter does bulk of the work (see DwarfDebug.cpp and AsmPrinter.cpp). The ongoing MC work is moving some of the printing stuff into MC world, where target specific support is required to support respective object file format. You may need to - enable certain flags for your target, see TargetLoweringObjectFile.h - provide a dwarf register map, see Target.td and TargetRegisterInfo.h > - also, how to search through mailing list archives? ? - Devang From devlists at shadowlab.org Tue Feb 8 13:04:10 2011 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Tue, 8 Feb 2011 20:04:10 +0100 Subject: [LLVMdev] Debug info generation through llvm backend In-Reply-To: References: Message-ID: Le 8 f?vr. 2011 ? 19:51, Devang Patel a ?crit : > > On Feb 6, 2011, at 8:52 PM, sivakumar srinivasan wrote: > >> Hi Everyone, >> >> I am really new to LLVM. I am working on something where I had to pick-up a half-cooked backend and need to add debug support to it. I have searched through messages but could not find a nice starting place. Could some one please provide me with some pointers about >> - what is already supported in llvm as far as emitting debugging information is concerned? >> - how to emit debug information through a llvm backend (any step-by-step process)? >> - any existing implementation? > > x86, ARM etc.. backends now emit debug info in DWARF format. To understand how it works, follow how @llvm.dbg.declare and @llvm.dbg.value intrinsics are lowered, at instruction selection time, from LLVM IR into machine instructions. > > Most of the work required here is target independent (note, DWARF format is also used to encode EH info, which is a separate story). Target independent AsmPrinter does bulk of the work (see DwarfDebug.cpp and AsmPrinter.cpp). The ongoing MC work is moving some of the printing stuff into MC world, where target specific support is required to support respective object file format. > > You may need to > - enable certain flags for your target, see TargetLoweringObjectFile.h > - provide a dwarf register map, see Target.td and TargetRegisterInfo.h > >> - also, how to search through mailing list archives? > > ? Google is your friend. Just append the following statement to your search and it should work: site:http://lists.cs.uiuc.edu/pipermail/llvmdev/ for exemple, looking for debug symbols debug symbols site:http://lists.cs.uiuc.edu/pipermail/llvmdev/ -- Jean-Daniel From matt.pharr at gmail.com Tue Feb 8 16:12:27 2011 From: matt.pharr at gmail.com (Matt Pharr) Date: Tue, 8 Feb 2011 14:12:27 -0800 Subject: [LLVMdev] vectors of pointers (why not?) Message-ID: <16197053-273F-4F83-B37D-CED1AA915650@gmail.com> I'm writing a compiler where I'd like to be able to (sometimes) represent lvalues of vectors (e.g. <4xfloat>) with vectors of pointers (e.g. <4xfloat *>). In this case, I'd like to be generating these vectors of pointers early on and later converting operations on them to a series of individual loads/stores with a later pass. (Note, though, that ISAs with "gather"/"scatter" instructions could do interesting operations on vectors of pointers directly...) However, llvm disallows vectors of pointers. llvm 2.8 would issue an error if it found any when running the module verifier pass; I had previously worked around this by creating vectors of i64s in cases where I actually wanted a vector of pointers, doing individual PtrToInt / IntToPtr conversions on the way in and out. Alongside this, I carried along an llvm::Type of the desired pointer type (e.g. <4xfloat *>), so that I could bitcast appropriately on the way back out. This was a hack, but it worked, though it also was wasteful for targets with 32-bit pointers. Unfortunately, llvm TOT now seems to prohibit even constructing a Type representing a vector of pointers, firing on an assertion in a constructor. My question is, why these prohibitions? I'd be a big help to have even a small loosening of restrictions that, say, allowed vectors of pointers but basically didn't allow any operations other than insertelement/extractelement on them. (I wouldn't complain about allowing more operations on them, e.g. a vectorized GEP instruction that took a vector of pointers and vectors of offsets, or load/store instructions that took them and turned them into individual loads/stores, but those are bigger changes!) I realize I could disable these assertions in my own llvm tree, but a) I'd like to know whether those assertions are there to enforce the specified restrictions or whether they are there to prevent bad things from happening downstream, and b) if the change is possible, it'd be nice to have it in the general distribution. Thanks for any help/guidance. -matt -- Matt Pharr http://pharr.org/matt From atrick at apple.com Tue Feb 8 16:22:07 2011 From: atrick at apple.com (Andrew Trick) Date: Tue, 8 Feb 2011 14:22:07 -0800 Subject: [LLVMdev] Debug info generation through llvm backend In-Reply-To: References: Message-ID: <4F4BD5AA-7C40-4444-84F2-49771899DD2E@apple.com> On Feb 6, 2011, at 8:52 PM, sivakumar srinivasan wrote: > also, how to search through mailing list archives? http://blog.gmane.org/gmane.comp.compilers.llvm.devel From andrew at sidefx.com Tue Feb 8 20:47:17 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Tue, 08 Feb 2011 21:47:17 -0500 Subject: [LLVMdev] noalias for functions? Message-ID: <4D520035.1060408@sidefx.com> I'm looking for a way to mark a function that may read and/or write to it's pointer arguments but that does not read or write to any other memory. Is there a combination of attributes that makes this possible? The best I can find is the readnone/readonly and noalias attributes, but it doesn't seem to be possible to indicate that it's only the pointer arguments that are read or modified (and not all the other global state). Here's a reference to a visual studio attribute that is essentially what I want: http://msdn.microsoft.com/en-us/library/k649tyc7%28v=vs.80%29.aspx Andrew From rafael.espindola at gmail.com Tue Feb 8 21:04:13 2011 From: rafael.espindola at gmail.com (=?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?=) Date: Tue, 08 Feb 2011 22:04:13 -0500 Subject: [LLVMdev] Why do we mangle names in llvm? Message-ID: <4D52042D.7020708@gmail.com> When we produce IL for int f(void) {...} it looks like define i32 @f() {.... and llvm is then responsible for adding the '_' prefix: _f: .... Why do we have this division? Wouldn't it be better for the IL to have the '_': define i32 @_f() {.... This causes problems with LTO because the symbols seem by the first pass are not the same as the ones seen once the final .o is produced. It can be fixed by having libLTO call void Mangler::getNameWithPrefix, but I was wondering if it wouldn't be better the avoid mangling in LLVM completely. Cheers, Rafael From abhirupju at gmail.com Wed Feb 9 02:26:49 2011 From: abhirupju at gmail.com (Abhirup Ghosh) Date: Wed, 9 Feb 2011 13:56:49 +0530 Subject: [LLVMdev] LLVM in Eclipse Message-ID: Hi, I am new to Eclipse IDE. I am working with LLVM using command line for some time. Now I want to integrate it with eclipse IDE. Can anyone please give layman instructions how to import the llvm source project, install it and built it in the eclipse IDE. Sorry for this type of novice request. - Abhirup -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110209/a01c70da/attachment.html From vasiliy.korchagin at gmail.com Wed Feb 9 07:02:57 2011 From: vasiliy.korchagin at gmail.com (Vasiliy Korchagin) Date: Wed, 09 Feb 2011 16:02:57 +0300 Subject: [LLVMdev] Lowering "memcpy" intrinsic function on ARM using LDMIA/STMIA Message-ID: <4D529081.2090902@gmail.com> Hi, llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and further combines them into ldm/stm with special pass after register allocation. But ldm/stm commands require registers to go in ascending order, what is often not so after regalloc, therefore some str/ldr commands. For example such code: struct Foo {int a, b, c, d; } void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } compiled to: ldmia r1, {r2, r3, r12} ldr r1, [r1, #12] stmia r0, {r2, r3, r12} str r1, [r0, #12] bx lr I ran different tests and always regalloc allocates at least one register not in ascending order. What is your ideas to overcome this issue? Maybe llvm should emit code for "memcpy" straight into ldm/stm or exchange registers before combining ldr/str to make them go in ascending order or fix somehow register allocator? Best regards, Vasiliy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110209/a37db267/attachment.html From ofv at wanadoo.es Wed Feb 9 07:18:09 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Wed, 09 Feb 2011 14:18:09 +0100 Subject: [LLVMdev] LLVM in Eclipse In-Reply-To: (Abhirup Ghosh's message of "Wed, 9 Feb 2011 13:56:49 +0530") References: Message-ID: <87y65pbb3i.fsf@wanadoo.es> Abhirup Ghosh writes: > Can anyone please give layman instructions how to import the llvm > source project, install it and built it in the eclipse IDE. http://www.llvm.org/docs/CMake.html From rcsaba at gmail.com Wed Feb 9 07:39:12 2011 From: rcsaba at gmail.com (Csaba Raduly) Date: Wed, 9 Feb 2011 14:39:12 +0100 Subject: [LLVMdev] LLVM in Eclipse In-Reply-To: References: Message-ID: Hi Abhirup, On Wed, Feb 9, 2011 at 9:26 AM, Abhirup Ghosh wrote: > Hi, > ???? I am new to Eclipse IDE. I am working with LLVM using command line for > some time. Now I want to integrate it with eclipse IDE. Can anyone please > give layman instructions how to import the llvm source project, install it > and built it in the eclipse IDE. You will need the Eclipse CDT plugin. Optionally, you could install one of the Subversion plugins (Subclipse ot Subversive). Plan A: all-in-one File->New/Other, Checkout Projects from SVN Create new repository location Url: http://llvm.org/svn/llvm-project/llvm/trunk select the root folder for checkout In the "Check Out As" page, select "Check out as a project configured using the New Project Wizard" Click Finish In the "New Project" wizard, under C/C++ select "C++ Project" Give the project a name, e.g. LLVM In the Project type, select Makefile project/Empty project Select the appropriate toolchain Click Next then Finish Eclipse will check out the sources. After it finished, you need to run configure manually. Now you should be able to build the LLVM project from Eclipse, and use Eclipse's svn integration to update it. Note that this will not fully work if you also want the clang frontend, because it resides in a different SVN tree. Plan B: manual checkout Use a Subversion client to check out LLVM (inside your workspace is best, e.g. $HOME/workspace/LLVM) Then create a new C++ project and name it LLVM. Eclipse would automagically set the location to the above and warn that the directory already exists. In Project type, select Makefile project/empty project Select the appropriate toolchain Click Next then Finish Again, you need to run configure manually, then you can build from Eclipse. P.S. Your question is probably off-topic for the llvm mailing list. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds From anand.arumug at gmail.com Wed Feb 9 08:09:57 2011 From: anand.arumug at gmail.com (Anand Arumugam) Date: Wed, 9 Feb 2011 09:09:57 -0500 Subject: [LLVMdev] Building LLVM on Cygwin. Message-ID: Hi, I followed the build instructions at http://www.aarongray.org/LLVM/BuildingLLVMonCygwin.html to build LLVM and LLVM GCC. Everything went fine except for the 'make install' step of llvm. At this step, I am getting a big list of files which are under /cygdrive/c/llvm-2.8/include/llvm and /cygdrive/c/llvm-2.8/include/llvm-c. The error I am getting is: /usr/bin/install: `./llvm-c/ExecutionEngine.h' and `/cygdrive/c/llvm-2.8/include/./llvm-c/ExecutionEngine.h' are the same file /usr/bin/install: `./llvm-c/LinkTimeOptimizer.h' and `/cygdrive/c/llvm-2.8/include/./llvm-c/LinkTimeOptimizer.h' are the same file /usr/bin/install: `./llvm-c/lto.h' and `/cygdrive/c/llvm-2.8/include/./llvm-c/lto.h' are the same file /usr/bin/install: `./llvm-c/Target.h' and `/cygdrive/c/llvm-2.8/include/./llvm-c/Target.h' are the same file /usr/bin/install: `./llvm-c/Transforms/IPO.h' and `/cygdrive/c/llvm-2.8/include/./llvm-c/Transforms/IPO.h' are the same file /usr/bin/install: `./llvm-c/Transforms/Scalar.h' and `/cygdrive/c/llvm-2.8/include/./llvm-c/Transforms/Scalar.h' are the same file make: *** [install-local] Error 1 I am not sure what I am doing wrong. I also tried a 'make clean' and 'make'. The 'make' completed successfully, but it is 'make install' that's giving me the error. Can you please tell me whats going wrong? The built executable are in /cygdrive/c/llvm-2.8/include/llvm/Release/bin. Thank you. Sincerely, Anand Arumugam. ------------------------- P.S: Following is the directory structure I am using: /cygdrive/c/llvm-2.8/src <--- contains the source extracted from the llvm-2.8 tar ball. The llvm-2.8 was built from /cygdrive/c/llvm-2.8 folder. /cygdrive/c/llvm-gcc-4.2-2.8/source <--- contains the source extracted from the llvm-gcc-4.2-2.8 tar ball. The llvm-gcc-4.2-2.8 was built from /cygdrive/c/llvm-gcc-4.2-2.8 folder. And the directory and its contents where make install is stopping: aarumug at aarumgxp /cygdrive/c/llvm-2.8 $ cd include/ aarumug at aarumgxp /cygdrive/c/llvm-2.8/include $ ls llvm/ llvm-c/ aarumug at aarumgxp /cygdrive/c/llvm-2.8/include $ cd llvm aarumug at aarumgxp /cygdrive/c/llvm-2.8/include/llvm $ ls ADT/ CallingConv.h GlobalValue.h IntrinsicsARM.td Metadata.h SymbolTableListTraits.h AbstractTypeUser.h CodeGen/ GlobalVariable.h IntrinsicsAlpha.td Module.h System/ Analysis/ CompilerDriver/ InlineAsm.h IntrinsicsCellSPU.td OperandTraits.h Target/ Argument.h Config/ InstrTypes.h IntrinsicsPowerPC.td Operator.h Transforms/ Assembly/ Constant.h Instruction.def IntrinsicsX86.td Pass.h Type.h Attributes.h Constants.h Instruction.h IntrinsicsXCore.td PassAnalysisSupport.h TypeSymbolTable.h AutoUpgrade.h DerivedTypes.h Instructions.h LLVMContext.h PassManager.h Use.h BasicBlock.h ExecutionEngine/ IntrinsicInst.h LinkAllPasses.h PassManagers.h User.h Bitcode/ Function.h Intrinsics.gen LinkAllVMCore.h PassRegistry.h Value.h CMakeLists.txt GVMaterializer.h Intrinsics.h Linker.h PassSupport.h ValueSymbolTable.h CallGraphSCCPass.h GlobalAlias.h Intrinsics.td MC/ Support/ aarumug at aarumgxp /cygdrive/c/llvm-2.8/include/llvm $ cd ../llvm-c aarumug at aarumgxp /cygdrive/c/llvm-2.8/include/llvm-c $ ls Analysis.h BitWriter.h EnhancedDisassembly.h LinkTimeOptimizer.h Transforms/ BitReader.h Core.h ExecutionEngine.h Target.h lto.h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110209/70f4672a/attachment.html From geek4civic at gmail.com Wed Feb 9 08:40:47 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Wed, 9 Feb 2011 23:40:47 +0900 Subject: [LLVMdev] Building LLVM on Cygwin. In-Reply-To: References: Message-ID: Anand, I have not tried building llvm-gcc, though, ... Please show me "/path/to/config.status --version". I doubt you did configure with "--prefix= /cygdrive/c/llvm-2.8" and you were trying to build llvm on /cygdrive/c/llvm-2.8 , ... it would be wrong. In common sense, build directory must be under your home directory or temporary directory. ...Takumi From jasonwkim at google.com Wed Feb 9 09:57:29 2011 From: jasonwkim at google.com (Jason Kim) Date: Wed, 9 Feb 2011 07:57:29 -0800 Subject: [LLVMdev] Lowering "memcpy" intrinsic function on ARM using LDMIA/STMIA In-Reply-To: <4D529081.2090902@gmail.com> References: <4D529081.2090902@gmail.com> Message-ID: On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin wrote: > Hi, > > llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and Hmm, this happens elsewhere as well (x86?). Perhaps what we need is a switch to disable memset/memcpy lowering? > further combines them into ldm/stm with special pass after register > allocation. But ldm/stm commands require registers to go in ascending order, > what is often not so after regalloc, therefore some str/ldr commands. For > example such code: > > struct Foo {int a, b, c, d; } > void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } > > compiled to: > > ldmia??? r1, {r2, r3, r12} > ldr??? r1, [r1, #12] > stmia??? r0, {r2, r3, r12} > str??? r1, [r0, #12] > bx??? lr > > I ran different tests and always regalloc allocates at least one register > not in ascending order. > > What is your ideas to overcome this issue? Maybe llvm should emit code for > "memcpy" straight into ldm/stm or exchange registers before combining > ldr/str to make them go in ascending order or fix somehow register > allocator? > > Best regards, Vasiliy. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From andrew at sidefx.com Wed Feb 9 10:16:05 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Wed, 09 Feb 2011 11:16:05 -0500 Subject: [LLVMdev] vectors of pointers (why not?) In-Reply-To: <16197053-273F-4F83-B37D-CED1AA915650@gmail.com> References: <16197053-273F-4F83-B37D-CED1AA915650@gmail.com> Message-ID: <4D52BDC5.7050900@sidefx.com> On 02/08/2011 05:12 PM, Matt Pharr wrote: > I'm writing a compiler where I'd like to be able to (sometimes) represent lvalues of vectors (e.g.<4xfloat>) with vectors of pointers (e.g.<4xfloat *>). In this case, I'd like to be generating these vectors of pointers early on and later converting operations on them to a series of individual loads/stores with a later pass. (Note, though, that ISAs with "gather"/"scatter" instructions could do interesting operations on vectors of pointers directly...) > > However, llvm disallows vectors of pointers. llvm 2.8 would issue an error if it found any when running the module verifier pass; I had previously worked around this by creating vectors of i64s in cases where I actually wanted a vector of pointers, doing individual PtrToInt / IntToPtr conversions on the way in and out. Alongside this, I carried along an llvm::Type of the desired pointer type (e.g.<4xfloat *>), so that I could bitcast appropriately on the way back out. This was a hack, but it worked, though it also was wasteful for targets with 32-bit pointers. > > Unfortunately, llvm TOT now seems to prohibit even constructing a Type representing a vector of pointers, firing on an assertion in a constructor. > > My question is, why these prohibitions? I'd be a big help to have even a small loosening of restrictions that, say, allowed vectors of pointers but basically didn't allow any operations other than insertelement/extractelement on them. (I wouldn't complain about allowing more operations on them, e.g. a vectorized GEP instruction that took a vector of pointers and vectors of offsets, or load/store instructions that took them and turned them into individual loads/stores, but those are bigger changes!) > > I realize I could disable these assertions in my own llvm tree, but a) I'd like to know whether those assertions are there to enforce the specified restrictions or whether they are there to prevent bad things from happening downstream, and b) if the change is possible, it'd be nice to have it in the general distribution. > > Thanks for any help/guidance. > > -matt Could you use an array of pointers instead? As far as I'm aware, the vector types in LLVM are intended to abstract the vector units on modern CPUs (SSE, etc.) which generally support operations on only integers and floating point values, which may be why there isn't native support for vectors of pointers. Andrew From anand.arumug at gmail.com Wed Feb 9 12:19:00 2011 From: anand.arumug at gmail.com (Anand Arumugam) Date: Wed, 9 Feb 2011 13:19:00 -0500 Subject: [LLVMdev] Building LLVM on Cygwin. In-Reply-To: References: Message-ID: On Wed, Feb 9, 2011 at 9:40 AM, NAKAMURA Takumi wrote: > Anand, > > > I have not tried building llvm-gcc, though, ... > > Please show me "/path/to/config.status --version". > [Anand] Here is the config.status output taken from '/cygdrive/c/llvm-2.8': ./config.status --version llvm config.status 2.8 configured by src/configure, generated by GNU Autoconf 2.60, with options "'--prefix=/cygdrive/c/llvm-2.8'" > I doubt you did configure with "--prefix= /cygdrive/c/llvm-2.8" and > you were trying to build llvm on /cygdrive/c/llvm-2.8 > , ... it would be wrong. > > In common sense, build directory must be under your home directory or > temporary directory. > > [Anand] The build has to be done from a different directory than the source. I was doing it from one level up. Whats wrong in the way I had it setup? So if I have given a different prefix other than the directory from where the build is done, then it will work. Is that what you are saying? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110209/5aad7f43/attachment.html From greened at obbligato.org Wed Feb 9 12:57:45 2011 From: greened at obbligato.org (David A. Greene) Date: Wed, 09 Feb 2011 12:57:45 -0600 Subject: [LLVMdev] vectors of pointers (why not?) In-Reply-To: <4D52BDC5.7050900@sidefx.com> (Andrew Clinton's message of "Wed, 09 Feb 2011 11:16:05 -0500") References: <16197053-273F-4F83-B37D-CED1AA915650@gmail.com> <4D52BDC5.7050900@sidefx.com> Message-ID: Andrew Clinton writes: > Could you use an array of pointers instead? As far as I'm aware, the > vector types in LLVM are intended to abstract the vector units on modern > CPUs (SSE, etc.) which generally support operations on only integers and > floating point values, which may be why there isn't native support for > vectors of pointers. Except that modern processors are far more expressive than SSE. Knights Ferry has gather/scatter instructions. Now I know Knights Ferry isn't a supported target and probably won't be for a while, if ever, but something that looks like it is almost certainly going to go mainstream in the next 2-3 years. It's certainly worth seriously considering how LLVM will support more traditional vector-style ISAs in the near future. -Dave From viridia at gmail.com Wed Feb 9 13:31:38 2011 From: viridia at gmail.com (Talin) Date: Wed, 9 Feb 2011 11:31:38 -0800 Subject: [LLVMdev] Convenience methods in ConstantExpr et al In-Reply-To: <4D4A6D1D.4080706@free.fr> References: <4D49CCD7.2000601@mxc.ca> <4D4A6D1D.4080706@free.fr> Message-ID: On Thu, Feb 3, 2011 at 12:53 AM, Duncan Sands wrote: > Hi Talin, > > > I find that I call the static methods in ConstantExpr a *lot* without > going > > through IRBuilder - hundreds of times in my frontend. My language > generates a > > lot of static data - reflection information, trace tables for the garbage > > collector, dispatch tables, runtime annotations, static object instances, > and so > > on. (In fact there's a special helper class "StructBuilder" that > automates a lot > > of the work of building constant structs, such as adding the standard > object > > header and so on.) > > I think it would be better to create a ConstBuilder class rather than add > stuff > to ConstantExpr. > > Well, it doesn't seem that there's much interest in a ConstBuilder class, based on the number of replies to my proposal :) So I'm back to the question as to whether it would be acceptable to add a few extra helper methods to ConstantExpr, ConstStruct, and so on. > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110209/ce2fefd5/attachment.html From nipun2512 at gmail.com Wed Feb 9 15:38:48 2011 From: nipun2512 at gmail.com (Nipun Arora) Date: Wed, 9 Feb 2011 16:38:48 -0500 Subject: [LLVMdev] x86 to LLVM-IR Message-ID: Hi, I was looking into ways to convert an x86 executable(ELF), to an LLVM-IR representation. To the best of my knowledge llvm-mc seems to be the tool which can be used... It would be great if anyone could give pointers in the same direction... Thanks Nipun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110209/1dda2e7d/attachment.html From reid.kleckner at gmail.com Wed Feb 9 16:10:47 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Wed, 9 Feb 2011 17:10:47 -0500 Subject: [LLVMdev] x86 to LLVM-IR In-Reply-To: References: Message-ID: Raising machine code back up to LLVM IR is hard to do in a way that will give you any efficiency or portability. llvm-mc will at most help you to disassemble an object file to LLVM's representation of the machine code. IIRC that's not even possible at the moment, since it requires parsing object files, not just generating them. Reid On Wed, Feb 9, 2011 at 4:38 PM, Nipun Arora wrote: > Hi, > I was looking into ways to convert an x86 executable(ELF), to an LLVM-IR > representation. > To the best of my knowledge llvm-mc seems to be the tool which can be > used... > It would be great if anyone could give pointers in the same direction... > Thanks > Nipun > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From vasiliy.korchagin at gmail.com Wed Feb 9 16:18:18 2011 From: vasiliy.korchagin at gmail.com (=?UTF-8?B?0JrQvtGA0YfQsNCz0LjQvSDQktCw0YHQuNC70LjQuQ==?=) Date: Thu, 10 Feb 2011 01:18:18 +0300 Subject: [LLVMdev] Lowering "memcpy" intrinsic function on ARM using LDMIA/STMIA In-Reply-To: References: <4D529081.2090902@gmail.com> Message-ID: <4D5312AA.5090108@gmail.com> 09.02.2011 18:57, Jason Kim ?????: > On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin > wrote: >> Hi, >> >> llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and > > Hmm, this happens elsewhere as well (x86?). Perhaps what we need is a > switch to disable memset/memcpy lowering? > Do you offer to call libc memset/memcpy functions always instead of intrinsic lowering? It seems not a good idea, because often (especially in cases of small chunks of memory) consecutive ldm/stm instructions are more efficient than memcpy call. >> further combines them into ldm/stm with special pass after register >> allocation. But ldm/stm commands require registers to go in ascending order, >> what is often not so after regalloc, therefore some str/ldr commands. For >> example such code: >> >> struct Foo {int a, b, c, d; } >> void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } >> >> compiled to: >> >> ldmia r1, {r2, r3, r12} >> ldr r1, [r1, #12] >> stmia r0, {r2, r3, r12} >> str r1, [r0, #12] >> bx lr >> >> I ran different tests and always regalloc allocates at least one register >> not in ascending order. >> >> What is your ideas to overcome this issue? Maybe llvm should emit code for >> "memcpy" straight into ldm/stm or exchange registers before combining >> ldr/str to make them go in ascending order or fix somehow register >> allocator? >> >> Best regards, Vasiliy. >> >> _______________________________________________ >> 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 Wed Feb 9 16:22:59 2011 From: deeppatel1987 at gmail.com (Sandeep Patel) Date: Wed, 9 Feb 2011 22:22:59 +0000 Subject: [LLVMdev] Lowering "memcpy" intrinsic function on ARM using LDMIA/STMIA In-Reply-To: <4D5312AA.5090108@gmail.com> References: <4D529081.2090902@gmail.com> <4D5312AA.5090108@gmail.com> Message-ID: -fno-builtin is the flag you want. deep On Wed, Feb 9, 2011 at 10:18 PM, ???????? ??????? wrote: > 09.02.2011 18:57, Jason Kim ?????: >> On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin >> ?wrote: >>> Hi, >>> >>> llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and >> >> Hmm, this happens elsewhere as well (x86?). Perhaps what we need is a >> switch to disable memset/memcpy lowering? >> > > Do you offer to call libc memset/memcpy functions always instead of > intrinsic lowering? It seems not a good idea, because often (especially > in cases of small chunks of memory) consecutive ldm/stm instructions are > more efficient than memcpy call. > >>> further combines them into ldm/stm with special pass after register >>> allocation. But ldm/stm commands require registers to go in ascending order, >>> what is often not so after regalloc, therefore some str/ldr commands. For >>> example such code: >>> >>> struct Foo {int a, b, c, d; } >>> void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } >>> >>> compiled to: >>> >>> ldmia ? ?r1, {r2, r3, r12} >>> ldr ? ?r1, [r1, #12] >>> stmia ? ?r0, {r2, r3, r12} >>> str ? ?r1, [r0, #12] >>> bx ? ?lr >>> >>> I ran different tests and always regalloc allocates at least one register >>> not in ascending order. >>> >>> What is your ideas to overcome this issue? Maybe llvm should emit code for >>> "memcpy" straight into ldm/stm or exchange registers before combining >>> ldr/str to make them go in ascending order or fix somehow register >>> allocator? >>> >>> Best regards, Vasiliy. >>> >>> _______________________________________________ >>> 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 vasiliy.korchagin at gmail.com Wed Feb 9 17:00:21 2011 From: vasiliy.korchagin at gmail.com (=?KOI8-R?Q?=EB=CF=D2=DE=C1=C7=C9=CE_=F7=C1=D3=C9=CC=C9=CA?=) Date: Thu, 10 Feb 2011 02:00:21 +0300 Subject: [LLVMdev] Lowering "memcpy" intrinsic function on ARM using LDMIA/STMIA In-Reply-To: References: <4D529081.2090902@gmail.com> <4D5312AA.5090108@gmail.com> Message-ID: <4D531C85.7040504@gmail.com> llc hasn't such flag and as I mentioned transforming memcpy into ldm/stm instructions often is more efficient way than calling memcpy from libc. 10.02.2011 01:22, Sandeep Patel ?????: > -fno-builtin is the flag you want. > > deep > > On Wed, Feb 9, 2011 at 10:18 PM, ???????? ??????? > wrote: >> 09.02.2011 18:57, Jason Kim ?????: >>> On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin >>> wrote: >>>> Hi, >>>> >>>> llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and >>> >>> Hmm, this happens elsewhere as well (x86?). Perhaps what we need is a >>> switch to disable memset/memcpy lowering? >>> >> >> Do you offer to call libc memset/memcpy functions always instead of >> intrinsic lowering? It seems not a good idea, because often (especially >> in cases of small chunks of memory) consecutive ldm/stm instructions are >> more efficient than memcpy call. >> >>>> further combines them into ldm/stm with special pass after register >>>> allocation. But ldm/stm commands require registers to go in ascending order, >>>> what is often not so after regalloc, therefore some str/ldr commands. For >>>> example such code: >>>> >>>> struct Foo {int a, b, c, d; } >>>> void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } >>>> >>>> compiled to: >>>> >>>> ldmia r1, {r2, r3, r12} >>>> ldr r1, [r1, #12] >>>> stmia r0, {r2, r3, r12} >>>> str r1, [r0, #12] >>>> bx lr >>>> >>>> I ran different tests and always regalloc allocates at least one register >>>> not in ascending order. >>>> >>>> What is your ideas to overcome this issue? Maybe llvm should emit code for >>>> "memcpy" straight into ldm/stm or exchange registers before combining >>>> ldr/str to make them go in ascending order or fix somehow register >>>> allocator? >>>> >>>> Best regards, Vasiliy. >>>> >>>> _______________________________________________ >>>> 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 atrick at apple.com Wed Feb 9 17:02:36 2011 From: atrick at apple.com (Andrew Trick) Date: Wed, 9 Feb 2011 15:02:36 -0800 Subject: [LLVMdev] A question about LICM (Loop Invariant Code Motion) In-Reply-To: References: <4D511320.20107@free.fr> Message-ID: <87539441-1407-4C3F-B2AD-FC2F77A7E1E6@apple.com> On Feb 8, 2011, at 7:36 AM, Reid Kleckner wrote: > On Tue, Feb 8, 2011 at 4:55 AM, Duncan Sands wrote: >> Hi Yuelu, >> >>> After tracking the LICM pass, I find that both loads are loop >>> invariant, and canSinkOrHoist() also returns true; however the >>> difference is at Instruction::isSafeToSpeculativelyExecute(), >>> for load from function parameter pointer, it return false; with load >>> from a global var pointer, it returns true. As a result no hoist >>> happens for a load *fp: >> >> the function parameter pointer might be null. > > I suppose you could peel a single iteration to try to work around that. Peeling is a good idea for small loops with invariant loads or conditions. I'm not sure why we don't do it. But it would cause code bloat (in the absense of profile data) and it's not a general solution. If null checks were the only problem, then the compiler could hoist the load under a non-null condition (e.g. select), replacing the original with a trap under the inverse condition. But even if the entire loop is dominated by a null check, it's still unsafe to hoist the load. The fundamental problem is that the language needs to guarantee that the load is safe to speculate. Modern languages do this. But I don't know how to represent that information in LLVM IR. We would need a way to indicate a load's control dependent conditions (null checks, type checks, and such). -Andy From atrick at apple.com Wed Feb 9 18:00:58 2011 From: atrick at apple.com (Andrew Trick) Date: Wed, 9 Feb 2011 16:00:58 -0800 Subject: [LLVMdev] Running the programs in the LLVM test suite with a pass and without it. In-Reply-To: References: Message-ID: <4EB51439-DDAB-408D-A162-DD6925085FE2@apple.com> On Feb 7, 2011, at 4:20 AM, Douglas do Couto Teixeira wrote: > Hi guys, > > I have a pass called "MyPass". And I can run this pass in the LLVM test suite programs and produce a report with the statistics of the execution of this pass. Now, I would like to run the programs in LLVM test suite and generate a report comparing the results obtained without using the pass with the results obtained using the pass. Is there any way to do this? If by "stats" you mean execution time, then you may use the Makefile support for "llc beta" as Jim suggested. I use the following without editing the Makefiles: TEST=nightly ENABLE_LLCBETA=1 LLCBETAOPTION="-my-pass" report.csv To compare across separate runs, I just load the report.csv into a spreadsheet and define some formulas. If you actually want to compare output from the -stats option, then you can compare the *.llc.s.info files (one for each benchmark) from two separate runs. I attached the script that I use to do this. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: comparestats.py Type: text/x-python-script Size: 2416 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110209/0b90ce5b/attachment.bin From geek4civic at gmail.com Wed Feb 9 19:32:08 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Thu, 10 Feb 2011 10:32:08 +0900 Subject: [LLVMdev] Building LLVM on Cygwin. In-Reply-To: References: Message-ID: On Thu, Feb 10, 2011 at 3:19 AM, Anand Arumugam wrote: > [Anand] Here is the config.status output taken from '/cygdrive/c/llvm-2.8': > > ./config.status --version > llvm config.status 2.8 > configured by src/configure, generated by GNU Autoconf 2.60, > ? with options "'--prefix=/cygdrive/c/llvm-2.8'" > So if I have given a different prefix other than the directory from where > the build is done, then it will work. Is that what you are saying? Sure. And, ... I missed your former article; I guess below. - You had attempted iteratively "make install" - At your 1st configure, your build directory /cygdrive/c/llvm-2.8 would not contain /cygdrive/c/llvm-2.8/include/llvm_c. - At your 1st "make install", you might get failure to attempt to install include/llvm/Config/* to same directory on the filesystem. (would succeed to install other include/llvm/*, include/llvm_c/* INTO THE BUILD DIRECTORY!) - At your 2nd build and install, everything went messily! Do you understand what "--prefix=/cygdrive/c/llvm-2.8" means? I recommend you should erase all src, build, install directories(rm -rf /cygdrive/c/llvm-2.8), and retry building on separated directory. ps. I don't also recommend to build on upper directory (src=/cygdrive/c/llvm-2.8/src, build=/cygdrive/c/llvm-2.8). Then you would lose benefit to clean up a build with "rm -rf {build directory}". An example of recommendation is; - src: /home/tsundere/sources/llvm-2.8 - build: /home/tsundere/working/directory/to/build/llvm --prefix=/cygdrive/c/llvm-2.8 (I suggest it would be possible with --prefix=/usr/local on cygwin) ...Takumi From clattner at apple.com Wed Feb 9 19:38:22 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 9 Feb 2011 17:38:22 -0800 Subject: [LLVMdev] A question about LICM (Loop Invariant Code Motion) In-Reply-To: References: Message-ID: <600B3052-62D0-42A3-8F3D-8E4EB580B894@apple.com> On Feb 7, 2011, at 2:13 PM, Yuelu Duan wrote: > Hi, > > I recently looked into the LICM(Loop Invariant Code Motion) pass of > LLVM and got a question about hoist load instruction to loop > preheader. I would like to show two examples: > > Example 1: > int func(int n, int *fp) { > int i; > int a[1000]; > for (i = 0; i < n; ++i) { > a[i] += *fp; // load from *fp pointer, no hoist > } > } > > Here, load *fp CAN NOT be hoisted to loop preheader. If replace *fp > with an local pointer, the load can not be hoisted either. clang -O2 hoists the load of fp out of the loop, since loop rotation transforms the loop. Are you not seeing this? -Chris From sks200203 at gmail.com Wed Feb 9 22:05:25 2011 From: sks200203 at gmail.com (sivakumar srinivasan) Date: Thu, 10 Feb 2011 09:35:25 +0530 Subject: [LLVMdev] Debug info generation through llvm backend In-Reply-To: References: Message-ID: Hi Devang, Thanks for the pointers. I will take some time to chew on this information and looking at different pieces of sources. Thanks, Jean-Daniel and Andrew for the search answers. -sks On Wed, Feb 9, 2011 at 12:21 AM, Devang Patel wrote: > > On Feb 6, 2011, at 8:52 PM, sivakumar srinivasan wrote: > > > Hi Everyone, > > > > I am really new to LLVM. I am working on something where I had to pick-up a half-cooked backend and need to add debug support to it. I have searched through messages but could not find a nice starting place. Could some one please provide me with some pointers about > > - what is already supported in llvm as far as emitting debugging information is concerned? > > - how to emit debug information through a llvm backend (any step-by-step process)? > > - any existing implementation? > > x86, ARM etc.. backends now emit debug info in DWARF format. To understand how it works, follow how @llvm.dbg.declare and @llvm.dbg.value intrinsics are lowered, at instruction selection time, from LLVM IR into machine instructions. > > Most of the work required here is target independent (note, DWARF format is also used to encode EH info, which is a separate story). Target independent AsmPrinter does bulk of the work ?(see DwarfDebug.cpp and AsmPrinter.cpp). The ongoing MC work is moving some of the printing stuff into MC world, where target specific support is required to support respective object file format. > > You may need to > - enable certain flags for your target, see TargetLoweringObjectFile.h > - provide a dwarf register map, see Target.td and TargetRegisterInfo.h > > > - also, how to search through mailing list archives? > > ? > > - > Devang > From harel.cain at gmail.com Thu Feb 10 01:36:03 2011 From: harel.cain at gmail.com (Harel Cain) Date: Thu, 10 Feb 2011 09:36:03 +0200 Subject: [LLVMdev] Preventing C backend from using gcc builtin functions Message-ID: Hi all, Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend and the C backend I see it converting regular (non-checking) memcpy and memset calls to __memset_chk and __memcpy_chk already at the IR stage. Then in the CBE output these are retained as gcc builtin functions. In a similar manner, llvm.objectsize.* calls are replaced with __builtin_object_size calls, another gcc builtin function. This way the resulting C code is usable as-is only on gcc-compatible compilers. Is there a way, either by passing some flags to the llvm-gcc frontend, or by specifying some other flag to llc, to prevent this from happening? Your help is as always much appreciated, Harel Cain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110210/162dd833/attachment.html From anton at korobeynikov.info Thu Feb 10 02:16:34 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 10 Feb 2011 11:16:34 +0300 Subject: [LLVMdev] Preventing C backend from using gcc builtin functions In-Reply-To: References: Message-ID: > Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend > and the C backend I see it converting regular (non-checking) memcpy and > memset calls to __memset_chk and __memcpy_chk already at the IR stage. Most probably these are changed due to defines in the system headers, so, compiler cannot do anything about this. You can hack on your system headers though. > In a similar manner, llvm.objectsize.* calls are replaced with > __builtin_object_size calls, another gcc builtin function. What should be used instead? > Is there a way, either by passing some flags to the llvm-gcc frontend, or by > specifying some other flag to llc, to prevent this from happening? CBE relies on many gcc extensions, so, I doubt fixing this small issue will change the overall situation. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From vasiliy.korchagin at gmail.com Thu Feb 10 02:40:36 2011 From: vasiliy.korchagin at gmail.com (=?KOI8-R?Q?=EB=CF=D2=DE=C1=C7=C9=CE_=F7=C1=D3=C9=CC=C9=CA?=) Date: Thu, 10 Feb 2011 11:40:36 +0300 Subject: [LLVMdev] Lowering "memcpy" intrinsic function on ARM using LDMIA/STMIA In-Reply-To: References: <4D529081.2090902@gmail.com> <4D5312AA.5090108@gmail.com> Message-ID: <4D53A484.4010101@gmail.com> Seems like a little misunderstanding. I wrote about bitcode memcpy intrinsic, not memcpy from libc. Exactly this intrinsic is used in IR for stuctures coping as in my example. And lowering of memcpy intrinsic has mentioned issue on ARM. 10.02.2011 01:22, Sandeep Patel ?????: > -fno-builtin is the flag you want. > > deep > > On Wed, Feb 9, 2011 at 10:18 PM, ???????? ??????? > wrote: >> 09.02.2011 18:57, Jason Kim ?????: >>> On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin >>> wrote: >>>> Hi, >>>> >>>> llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and >>> >>> Hmm, this happens elsewhere as well (x86?). Perhaps what we need is a >>> switch to disable memset/memcpy lowering? >>> >> >> Do you offer to call libc memset/memcpy functions always instead of >> intrinsic lowering? It seems not a good idea, because often (especially >> in cases of small chunks of memory) consecutive ldm/stm instructions are >> more efficient than memcpy call. >> >>>> further combines them into ldm/stm with special pass after register >>>> allocation. But ldm/stm commands require registers to go in ascending order, >>>> what is often not so after regalloc, therefore some str/ldr commands. For >>>> example such code: >>>> >>>> struct Foo {int a, b, c, d; } >>>> void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } >>>> >>>> compiled to: >>>> >>>> ldmia r1, {r2, r3, r12} >>>> ldr r1, [r1, #12] >>>> stmia r0, {r2, r3, r12} >>>> str r1, [r0, #12] >>>> bx lr >>>> >>>> I ran different tests and always regalloc allocates at least one register >>>> not in ascending order. >>>> >>>> What is your ideas to overcome this issue? Maybe llvm should emit code for >>>> "memcpy" straight into ldm/stm or exchange registers before combining >>>> ldr/str to make them go in ascending order or fix somehow register >>>> allocator? >>>> >>>> Best regards, Vasiliy. >>>> >>>> _______________________________________________ >>>> 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 echristo at apple.com Thu Feb 10 03:09:45 2011 From: echristo at apple.com (Eric Christopher) Date: Thu, 10 Feb 2011 01:09:45 -0800 Subject: [LLVMdev] Preventing C backend from using gcc builtin functions In-Reply-To: References: Message-ID: On Feb 10, 2011, at 12:16 AM, Anton Korobeynikov wrote: >> Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend >> and the C backend I see it converting regular (non-checking) memcpy and >> memset calls to __memset_chk and __memcpy_chk already at the IR stage. > Most probably these are changed due to defines in the system headers, > so, compiler cannot do anything about this. > You can hack on your system headers though. > >> In a similar manner, llvm.objectsize.* calls are replaced with >> __builtin_object_size calls, another gcc builtin function. > What should be used instead? For these two sets of things in particular you can pass -D_FORTIFY_SOURCE=0 on your command line. In general, you probably don't want to though. -eric From jaykang10 at imrc.kist.re.kr Thu Feb 10 05:31:45 2011 From: jaykang10 at imrc.kist.re.kr (Jin Gu Kang) Date: Thu, 10 Feb 2011 20:31:45 +0900 Subject: [LLVMdev] ConstantExpr::replaceUsesOfWithOnConstant() function for llvm::GetElementPtrConstantExpr Message-ID: <3E94D039A2B82544B3E7D48F924B0B25DFA3D87FE2@base.imrc.kist.re.kr> Hi LLVMdev members I found something strange in ConstantExpr::replaceUsesOfWithOnConstant() function. in lib/VMCore/Constants.cpp file 2118 if (getOpcode() == Instruction::GetElementPtr) { 2119 SmallVector Indices; 2120 Constant *Pointer = getOperand(0); 2121 Indices.reserve(getNumOperands()-1); 2122 if (Pointer == From) Pointer = To; 2123 2124 for (unsigned i = 1, e = getNumOperands(); i != e; ++i) { 2125 Constant *Val = getOperand(i); 2126 if (Val == From) Val = To; 2127 Indices.push_back(Val); 2128 } 2129 Replacement = ConstantExpr::getGetElementPtr(Pointer, 2130 &Indices[0], Indices.size()); when making replacement for GetElementPtr, above codes do not consider inbounds factor. so, I thought codes to inbounds factor as follows: original 2129 Replacement = ConstantExpr::getGetElementPtr(Pointer, 2130 &Indices[0], Indices.size()); -------------------------------------------------------------------------------------------> modified 2129 if(cast(this)->isInBounds()) 2130 Replacement = ConstantExpr::getInBoundsGetElementPtr(Pointer, 2131 &Indices[0], Indices.size()); 2132 else 2133 Replacement = ConstantExpr::getGetElementPtr(Pointer, 2134 &Indices[0], Indices.size()); What do you think about above codes? Best regards, Jin-Gu Kang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110210/3e2d880c/attachment.html From rcsaba at gmail.com Thu Feb 10 05:38:40 2011 From: rcsaba at gmail.com (Csaba Raduly) Date: Thu, 10 Feb 2011 12:38:40 +0100 Subject: [LLVMdev] Building LLVM on Cygwin. In-Reply-To: References: Message-ID: Hi Anand On Wed, Feb 9, 2011 at 7:19 PM, Anand Arumugam wrote: > On Wed, Feb 9, 2011 at 9:40 AM, NAKAMURA Takumi wrote: >> >> Anand, >> >> >> I have not tried building llvm-gcc, though, ... >> >> Please show me "/path/to/config.status --version". > > [Anand] Here is the config.status output taken from '/cygdrive/c/llvm-2.8': > > ./config.status --version > llvm config.status 2.8 > configured by src/configure, generated by GNU Autoconf 2.60, > ? with options "'--prefix=/cygdrive/c/llvm-2.8'" > > ... > > [Anand] The build has to be done from a different directory than the source. > I was doing it from one level up. Whats wrong in the way I had it setup? > > So if I have given a different prefix other than the directory from where > the build is done, then it will work. Is that what you are saying? > Hi Anand, In your first mail, you wrote: /cygdrive/c/llvm-2.8/src <--- contains the source extracted from the llvm-2.8 tar ball. With "--prefix= /cygdrive/c/llvm-2.8" you are dangerously mixing the source and install directories. I usually build from the Subversion, with the following setup: $HOME/LLVM/llvm <- sources $HOME/LLVM/build-release <- build dir --prefix=/usr/local Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds From kubastaszak at gmail.com Thu Feb 10 10:49:23 2011 From: kubastaszak at gmail.com (Jakub Staszak) Date: Thu, 10 Feb 2011 17:49:23 +0100 Subject: [LLVMdev] create function In-Reply-To: References: Message-ID: I think you might be interested in ExtractCodeRegion() function. - Jakub On Mon, Feb 7, 2011 at 2:40 PM, Jakub Staszak wrote: > I think you might be interested in ExtractCodeRegion() function. > > - Jakub > > On Sat, Feb 5, 2011 at 7:40 AM, neda 8664 wrote: >> i need split a sequential program to multithread. the first step I am going >> to assign each basic block of program to a thread, so i want create a >> function for each basic block and add instruction of basic block into it and >> assign every function to a thread. >> how could i do it? >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > From damien.llvm at gmail.com Thu Feb 10 12:30:36 2011 From: damien.llvm at gmail.com (Damien Vincent) Date: Thu, 10 Feb 2011 10:30:36 -0800 Subject: [LLVMdev] Hazard recognizers & basic blocks Message-ID: I am working on a target which has some structural hazards. To detect these hazards, I implemented a sub-class of PostRAHazardRecognizer. PostRAHazardRecognizer resets the hazard state on a basic block basis. So, how to detect hazards that may occur between the end of a basic block and the beginning of another basic block ? Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110210/3f17c651/attachment.html From damien.llvm at gmail.com Thu Feb 10 12:37:57 2011 From: damien.llvm at gmail.com (Damien Vincent) Date: Thu, 10 Feb 2011 10:37:57 -0800 Subject: [LLVMdev] Hazard recognizers & basic blocks In-Reply-To: References: Message-ID: To be more specific, let's consider the following (imcomplete) C code (OK, this is not good C style ;) ) { ... goto label0; ... goto label1; ... label0: { // some C code for basic block starting at label0 ... } label1: { // some C code for basic block starting at label1 ... } } In the previous example, the last instruction of basic block0 (starting at label0) is not a jump. There might be a structural hazard between this instruction and the first instruction of basic block1 (starting at label1). Did you have to deal with this kind of hazards ? Thanks. On Thu, Feb 10, 2011 at 10:30 AM, Damien Vincent wrote: > > I am working on a target which has some structural hazards. > To detect these hazards, I implemented a sub-class of > PostRAHazardRecognizer. > > PostRAHazardRecognizer resets the hazard state on a basic block basis. > So, how to detect hazards that may occur between the end of a basic block > and the beginning of another basic block ? > > Thanks ! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110210/aa571745/attachment.html From kubastaszak at gmail.com Thu Feb 10 17:11:30 2011 From: kubastaszak at gmail.com (Jakub Staszak) Date: Fri, 11 Feb 2011 00:11:30 +0100 Subject: [LLVMdev] PR9112 Message-ID: Hello, This simple patch fixes PR9112: Index: lib/Analysis/ValueTracking.cpp =================================================================== --- lib/Analysis/ValueTracking.cpp (revision 125281) +++ lib/Analysis/ValueTracking.cpp (working copy) @@ -593,6 +593,8 @@ // Otherwise take the unions of the known bit sets of the operands, // taking conservative care to avoid excessive recursion. if (Depth < MaxDepth - 1 && !KnownZero && !KnownOne) { + if (!P->getNumIncomingValues()) + return; KnownZero = APInt::getAllOnesValue(BitWidth); KnownOne = APInt::getAllOnesValue(BitWidth); for (unsigned i = 0, e = P->getNumIncomingValues(); i != e; ++i) { -- Jakub Staszak From nlewycky at google.com Thu Feb 10 18:01:15 2011 From: nlewycky at google.com (Nick Lewycky) Date: Thu, 10 Feb 2011 16:01:15 -0800 Subject: [LLVMdev] PR9112 In-Reply-To: References: Message-ID: Committed in r125319, thank you! For future reference, patches are supposed to be mailed to llvm-commits instead. Nick On 10 February 2011 15:11, Jakub Staszak wrote: > Hello, > > This simple patch fixes PR9112: > > Index: lib/Analysis/ValueTracking.cpp > =================================================================== > --- lib/Analysis/ValueTracking.cpp (revision 125281) > +++ lib/Analysis/ValueTracking.cpp (working copy) > @@ -593,6 +593,8 @@ > // Otherwise take the unions of the known bit sets of the operands, > // taking conservative care to avoid excessive recursion. > if (Depth < MaxDepth - 1 && !KnownZero && !KnownOne) { > + if (!P->getNumIncomingValues()) > + return; > KnownZero = APInt::getAllOnesValue(BitWidth); > KnownOne = APInt::getAllOnesValue(BitWidth); > for (unsigned i = 0, e = P->getNumIncomingValues(); i != e; ++i) { > > -- > Jakub Staszak > _______________________________________________ > 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/20110210/3989058e/attachment.html From leafy7382 at gmail.com Thu Feb 10 19:05:33 2011 From: leafy7382 at gmail.com (Chia-Wei Yeh) Date: Fri, 11 Feb 2011 09:05:33 +0800 Subject: [LLVMdev] Compiler error when self-hosting Message-ID: I've hit this weird compiler error when building llvm/clang $ clang --version clang version 2.9 (trunk 125254) Target: x86_64-apple-darwin10 Thread model: posix Source rev is 125326 $ make llvm[1]: Compiling APFloat.cpp for Release build llvm[1]: Compiling APInt.cpp for Release build llvm[1]: Compiling APSInt.cpp for Release build llvm[1]: Compiling Allocator.cpp for Release build llvm[1]: Compiling Atomic.cpp for Release build llvm[1]: Compiling CommandLine.cpp for Release build llvm[1]: Compiling ConstantRange.cpp for Release build llvm[1]: Compiling CrashRecoveryContext.cpp for Release build llvm[1]: Compiling DAGDeltaAlgorithm.cpp for Release build llvm[1]: Compiling Debug.cpp for Release build llvm[1]: Compiling DeltaAlgorithm.cpp for Release build llvm[1]: Compiling Disassembler.cpp for Release build llvm[1]: Compiling Dwarf.cpp for Release build llvm[1]: Compiling DynamicLibrary.cpp for Release build llvm[1]: Compiling Errno.cpp for Release build llvm[1]: Compiling ErrorHandling.cpp for Release build llvm[1]: Compiling FileUtilities.cpp for Release build llvm[1]: Compiling FoldingSet.cpp for Release build llvm[1]: Compiling FormattedStream.cpp for Release build llvm[1]: Compiling GraphWriter.cpp for Release build llvm[1]: Compiling Host.cpp for Release build llvm[1]: Compiling IncludeFile.cpp for Release build llvm[1]: Compiling IntEqClasses.cpp for Release build llvm[1]: Compiling IntervalMap.cpp for Release build llvm[1]: Compiling IsInf.cpp for Release build llvm[1]: Compiling IsNAN.cpp for Release build llvm[1]: Compiling ManagedStatic.cpp for Release build llvm[1]: Compiling Memory.cpp for Release build llvm[1]: Compiling MemoryBuffer.cpp for Release build llvm[1]: Compiling MemoryObject.cpp for Release build llvm[1]: Compiling Mutex.cpp for Release build llvm[1]: Compiling Path.cpp for Release build llvm[1]: Compiling PathV2.cpp for Release build llvm[1]: Compiling PluginLoader.cpp for Release build llvm[1]: Compiling PrettyStackTrace.cpp for Release build llvm[1]: Compiling Process.cpp for Release build llvm[1]: Compiling Program.cpp for Release build llvm[1]: Compiling RWMutex.cpp for Release build llvm[1]: Compiling Regex.cpp for Release build llvm[1]: Compiling SearchForAddressOfSpecialSymbol.cpp for Release build llvm[1]: Compiling Signals.cpp for Release build llvm[1]: Compiling SmallPtrSet.cpp for Release build llvm[1]: Compiling SmallVector.cpp for Release build llvm[1]: Compiling SourceMgr.cpp for Release build llvm[1]: Compiling Statistic.cpp for Release build llvm[1]: Compiling StringExtras.cpp for Release build llvm[1]: Compiling StringMap.cpp for Release build llvm[1]: Compiling StringPool.cpp for Release build llvm[1]: Compiling StringRef.cpp for Release build llvm[1]: Compiling SystemUtils.cpp for Release build llvm[1]: Compiling TargetRegistry.cpp for Release build llvm[1]: Compiling ThreadLocal.cpp for Release build llvm[1]: Compiling Threading.cpp for Release build llvm[1]: Compiling TimeValue.cpp for Release build llvm[1]: Compiling Timer.cpp for Release build llvm[1]: Compiling ToolOutputFile.cpp for Release build llvm[1]: Compiling Triple.cpp for Release build llvm[1]: Compiling Twine.cpp for Release build llvm[1]: Compiling Valgrind.cpp for Release build llvm[1]: Compiling circular_raw_ostream.cpp for Release build llvm[1]: Compiling raw_os_ostream.cpp for Release build llvm[1]: Compiling raw_ostream.cpp for Release build llvm[1]: Compiling regcomp.c for Release build UNREACHABLE executed! 0 clang 0x0000000100c268b2 llvm::SmallVectorImpl::resize(unsigned int) + 2098 1 clang 0x0000000100c26d89 llvm::SmallVectorImpl::resize(unsigned int) + 3337 2 libSystem.B.dylib 0x00007fff86e7367a _sigtramp + 26 3 libSystem.B.dylib 0x8000006300000001 _sigtramp + 2031667617 4 clang 0x0000000100c26b06 llvm::SmallVectorImpl::resize(unsigned int) + 2694 5 clang 0x0000000100c17d62 std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) + 1410 6 clang 0x00000001008025ef llvm::DenseMap, llvm::DenseMapInfo >::clear() + 4543 7 clang 0x000000010080238d llvm::DenseMap, llvm::DenseMapInfo >::clear() + 3933 8 clang 0x00000001008018b2 llvm::DenseMap, llvm::DenseMapInfo >::clear() + 1154 9 clang 0x0000000100837678 llvm::SmallVectorTemplateBase, std::pair >, false>::grow(unsigned long) + 6296 10 clang 0x0000000100836e2f llvm::SmallVectorTemplateBase, std::pair >, false>::grow(unsigned long) + 4175 11 clang 0x0000000100836547 llvm::SmallVectorTemplateBase, std::pair >, false>::grow(unsigned long) + 1895 12 clang 0x00000001008e1e2e llvm::MachineFunctionAnalysis::getPassName() const + 142 13 clang 0x0000000100b95ba8 llvm::cl::parser::~parser() + 19656 14 clang 0x0000000100b95e2b llvm::cl::parser::~parser() + 20299 15 clang 0x0000000100b95fc6 llvm::cl::parser::~parser() + 20710 16 clang 0x0000000100b96557 llvm::cl::parser::~parser() + 22135 17 clang 0x0000000100b96a7d llvm::cl::parser::~parser() + 23453 18 clang 0x00000001001124b6 std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique(std::pair const&) + 6550 19 clang 0x00000001001ead35 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 261 20 clang 0x0000000100208358 clang::ABIArgInfo::setCoerceToType(llvm::Type const*) + 952 21 clang 0x00000001001ea05e llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 3326 22 clang 0x0000000100054fb0 std::_Deque_base >::_M_initialize_map(unsigned long) + 2864 23 clang 0x000000010003611b llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 10491 24 clang 0x0000000100016cfb std::_Rb_tree, std::less, std::allocator >::_M_insert_unique(std::string const&) + 3723 25 clang 0x000000010000faa7 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 8727 26 clang 0x0000000100013468 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::SourceMgr::SrcBuffer const&) + 1272 27 clang 0x000000010000e464 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 3028 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name regcomp.c -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17 -resource-dir /usr/local/bin/../lib/clang/2.9 -dependency-file /Users/leafy/Projects/llvm/lib/Support/Release/regcomp.d.tmp -MP -MT /Users/leafy/Projects/llvm/lib/Support/Release/regcomp.o -MT /Users/leafy/Projects/llvm/lib/Support/Release/regcomp.d -D NDEBUG -D _GNU_SOURCE -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I /Users/leafy/Projects/llvm/include -I /Users/leafy/Projects/llvm/lib/Support -O3 -Wall -W -Wno-unused-parameter -Wwrite-strings -ferror-limit 19 -fmessage-length 133 -stack-protector 1 -fblocks -fno-common -fdiagnostics-show-option -fcolor-diagnostics -o /Users/leafy/Projects/llvm/lib/Support/Release/regcomp.o -x c regcomp.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'regcomp.c'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@p_ere' clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) make[1]: *** [/Users/leafy/Projects/llvm/lib/Support/Release/regcomp.o] Error 1 make: *** [all] Error 1 -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/350552a0/attachment.html From vmle at ucdavis.edu Thu Feb 10 20:20:21 2011 From: vmle at ucdavis.edu (Vu Le) Date: Thu, 10 Feb 2011 18:20:21 -0800 Subject: [LLVMdev] Unit testing with random input using JIT In-Reply-To: References: Message-ID: Hi Reid, If an argument is a pointer and the function changes the value it pointed to, do you know how to get that updated value after executing the wrapper function? Thanks. Vu On Tue, Jan 11, 2011 at 2:40 PM, Reid Kleckner wrote: > On Tue, Jan 11, 2011 at 1:41 PM, Vu Le wrote: > > Hi, > > I want to implement a tool that probes a function with several input and > > records all the return output. > > The function might have more than 1 return value (by reference > parameters). > > > > Does ExecutionEngine::runFunction() support function call with complex > > argument type? > > If not, I guess that I have to create a wrapper function, prepare all the > > data, and call the original function. > > Am I on the right track? > > For functions with complicated parameters and return values, > runFunction will generate a wrapper function that calls the function > with the right arguments. This is fairly expensive and leaks memory > if called more than once for the same function. If the type of the > function is known, you can just use getPointerToFunction, cast that, > and call it from C. > > If it's not known but you want to call it many times with different > arguments, you could generate a wrapper function responsible for > unpacking your own datastructure describing the arguments and calling > the function you are testing with those arguments. Seems like you are > on the right track there. > > Reid > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110210/58a0e295/attachment.html From reid.kleckner at gmail.com Thu Feb 10 20:56:41 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Thu, 10 Feb 2011 21:56:41 -0500 Subject: [LLVMdev] Unit testing with random input using JIT In-Reply-To: References: Message-ID: Not sure what you mean here. If you have a copy of that pointer in the caller of the wrapper function, you should be able to follow it to recover the modified value as normal. Reid On Thu, Feb 10, 2011 at 9:20 PM, Vu Le wrote: > Hi Reid, > If an argument is a pointer and the function changes the value it pointed > to, > do you know how to get that updated value after executing the wrapper > function? > > Thanks. > Vu > > On Tue, Jan 11, 2011 at 2:40 PM, Reid Kleckner > wrote: >> >> On Tue, Jan 11, 2011 at 1:41 PM, Vu Le wrote: >> > Hi, >> > I want to implement a tool that probes a function with several input and >> > records all the return output. >> > The function might have more than 1 return value (by reference >> > parameters). >> > >> > Does ExecutionEngine::runFunction() support function call with complex >> > argument type? >> > If not, I guess that I have to create a wrapper function, prepare all >> > the >> > data, and call the original function. >> > Am I on the right track? >> >> For functions with complicated parameters and return values, >> runFunction will generate a wrapper function that calls the function >> with the right arguments. ?This is fairly expensive and leaks memory >> if called more than once for the same function. ?If the type of the >> function is known, you can just use getPointerToFunction, cast that, >> and call it from C. >> >> If it's not known but you want to call it many times with different >> arguments, you could generate a wrapper function responsible for >> unpacking your own datastructure describing the arguments and calling >> the function you are testing with those arguments. ?Seems like you are >> on the right track there. >> >> Reid > > From anand.arumug at gmail.com Thu Feb 10 21:58:37 2011 From: anand.arumug at gmail.com (Anand Arumugam) Date: Thu, 10 Feb 2011 22:58:37 -0500 Subject: [LLVMdev] Building LLVM on Cygwin. In-Reply-To: References: Message-ID: Thanks to both Nakamura & Csaba Raduly. My directory structure was the culprit. I was able to build and install LLVM and LLVM-GCC successfully. The README.LLVM file that comes with the source is not very clear. It jumps between platforms and makes it difficult to follow it. Cheers, Anand. On Thu, Feb 10, 2011 at 6:38 AM, Csaba Raduly wrote: > Hi Anand > > On Wed, Feb 9, 2011 at 7:19 PM, Anand Arumugam wrote: > > On Wed, Feb 9, 2011 at 9:40 AM, NAKAMURA Takumi wrote: > >> > >> Anand, > >> > >> > >> I have not tried building llvm-gcc, though, ... > >> > >> Please show me "/path/to/config.status --version". > > > > [Anand] Here is the config.status output taken from > '/cygdrive/c/llvm-2.8': > > > > ./config.status --version > > llvm config.status 2.8 > > configured by src/configure, generated by GNU Autoconf 2.60, > > with options "'--prefix=/cygdrive/c/llvm-2.8'" > > > > > ... > > > > [Anand] The build has to be done from a different directory than the > source. > > I was doing it from one level up. Whats wrong in the way I had it setup? > > > > So if I have given a different prefix other than the directory from where > > the build is done, then it will work. Is that what you are saying? > > > > Hi Anand, > In your first mail, you wrote: > > /cygdrive/c/llvm-2.8/src <--- contains the source extracted from the > llvm-2.8 tar ball. > > With "--prefix= /cygdrive/c/llvm-2.8" you are dangerously mixing the > source and install directories. > > I usually build from the Subversion, with the following setup: > > $HOME/LLVM/llvm <- sources > $HOME/LLVM/build-release <- build dir > --prefix=/usr/local > > Csaba > -- > GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ > Life is complex, with real and imaginary parts. > "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus > Torvalds > "People disagree with me. I just ignore them." -- Linus Torvalds > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110210/607993b6/attachment.html From atrick at apple.com Fri Feb 11 00:07:53 2011 From: atrick at apple.com (Andrew Trick) Date: Thu, 10 Feb 2011 22:07:53 -0800 Subject: [LLVMdev] Lowering "memcpy" intrinsic function on ARM using LDMIA/STMIA In-Reply-To: <4D529081.2090902@gmail.com> References: <4D529081.2090902@gmail.com> Message-ID: <4DF6CE41-6A8B-4E09-B372-71211F38FD30@apple.com> On Feb 9, 2011, at 5:02 AM, Vasiliy Korchagin wrote: > llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and further combines them into ldm/stm with special pass after register allocation. But ldm/stm commands require registers to go in ascending order, what is often not so after regalloc, therefore some str/ldr commands. For example such code: > > struct Foo {int a, b, c, d; } > void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } > > compiled to: > > ldmia r1, {r2, r3, r12} > ldr r1, [r1, #12] > stmia r0, {r2, r3, r12} > str r1, [r0, #12] > bx lr > > I ran different tests and always regalloc allocates at least one register not in ascending order. > > What is your ideas to overcome this issue? Maybe llvm should emit code for "memcpy" straight into ldm/stm or exchange registers before combining ldr/str to make them go in ascending order or fix somehow register allocator? Hi Vasiliy, We should handle this better. I'm not sure how to guarantee that we can generate ldm/stm without regalloc support. Our only idea is to teach the new register allocator to do a much better job satisfying register hints. If you'd like to track this, feel free to file a bug. Thanks, -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110210/96323a81/attachment.html From alexdura at gmail.com Fri Feb 11 05:13:09 2011 From: alexdura at gmail.com (Alexandru Dura) Date: Fri, 11 Feb 2011 13:13:09 +0200 Subject: [LLVMdev] preserving an implicit def between basic blocks Message-ID: Hi, I have the following problem: In BB0 there is an instruction that defines a flag (implicit def) and in BB1 there is one that reads the flag (implicit use). When i run llc with -O3, the instruction in BB0 that defines the flag is removed. How can i prevent this? BB0 and BB1 are consecutive basic blocks. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/db6fd500/attachment.html From rhythm.mail at gmail.com Fri Feb 11 05:48:26 2011 From: rhythm.mail at gmail.com (Lian Cheng) Date: Fri, 11 Feb 2011 19:48:26 +0800 Subject: [LLVMdev] G++ 3.4.5 under RedHat AS4 fails to compile Clang trunk Message-ID: Compilation error output is attached. Seems that G++ 3.4.5 fails to pick the right specialization version of getExprLocImpl() function in lib/AST/Expr.cpp. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: error Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/4a248936/attachment-0001.pl From reid.kleckner at gmail.com Fri Feb 11 12:45:03 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Fri, 11 Feb 2011 13:45:03 -0500 Subject: [LLVMdev] Unit testing with random input using JIT In-Reply-To: References: Message-ID: If you know the prototype of f, you can just use getPointerToFunction and cast the result: // Let F be an llvm::Function* referring to 'f'. void (*f)(int*) = (void (*)(int*))JIT->getPointerToFunction(F); int a; f(&a); // read a I haven't compiled this, it's a guess at the usage from memory. Reid On Fri, Feb 11, 2011 at 12:55 PM, Vu Le wrote: > Suppose I want to test the function f with zero. > f(int *t){ > ? *t = 2 > } > What I did was that I create a wrapper > void Wrapper(){ > ? int a = 1; > ? int *b = &a; > ? f(b); > ? // now I want to print the value of b > ? // but I don't know how > } > > Thanks. > Vu > On Thu, Feb 10, 2011 at 6:56 PM, Reid Kleckner > wrote: >> >> Not sure what you mean here. ?If you have a copy of that pointer in >> the caller of the wrapper function, you should be able to follow it to >> recover the modified value as normal. >> >> Reid >> >> On Thu, Feb 10, 2011 at 9:20 PM, Vu Le wrote: >> > Hi Reid, >> > If an argument is a pointer and the function changes the value it >> > pointed >> > to, >> > do you know how to get that updated value after executing the wrapper >> > function? >> > >> > Thanks. >> > Vu >> > >> > On Tue, Jan 11, 2011 at 2:40 PM, Reid Kleckner >> > wrote: >> >> >> >> On Tue, Jan 11, 2011 at 1:41 PM, Vu Le wrote: >> >> > Hi, >> >> > I want to implement a tool that probes a function with several input >> >> > and >> >> > records all the return output. >> >> > The function might have more than 1 return value (by reference >> >> > parameters). >> >> > >> >> > Does ExecutionEngine::runFunction() support function call with >> >> > complex >> >> > argument type? >> >> > If not, I guess that I have to create a wrapper function, prepare all >> >> > the >> >> > data, and call the original function. >> >> > Am I on the right track? >> >> >> >> For functions with complicated parameters and return values, >> >> runFunction will generate a wrapper function that calls the function >> >> with the right arguments. ?This is fairly expensive and leaks memory >> >> if called more than once for the same function. ?If the type of the >> >> function is known, you can just use getPointerToFunction, cast that, >> >> and call it from C. >> >> >> >> If it's not known but you want to call it many times with different >> >> arguments, you could generate a wrapper function responsible for >> >> unpacking your own datastructure describing the arguments and calling >> >> the function you are testing with those arguments. ?Seems like you are >> >> on the right track there. >> >> >> >> Reid >> > >> > > > From vmle at ucdavis.edu Fri Feb 11 13:16:44 2011 From: vmle at ucdavis.edu (Vu Le) Date: Fri, 11 Feb 2011 11:16:44 -0800 Subject: [LLVMdev] Unit testing with random input using JIT In-Reply-To: References: Message-ID: Hi Reid, It's just an example. All the tested function are in bitcode. The arguments might be complex and might not be converted back to GenericValue. On Fri, Feb 11, 2011 at 10:45 AM, Reid Kleckner wrote: > If you know the prototype of f, you can just use getPointerToFunction > and cast the result: > > // Let F be an llvm::Function* referring to 'f'. > void (*f)(int*) = (void (*)(int*))JIT->getPointerToFunction(F); > int a; > f(&a); > // read a > > I haven't compiled this, it's a guess at the usage from memory. > > Reid > > On Fri, Feb 11, 2011 at 12:55 PM, Vu Le wrote: > > Suppose I want to test the function f with zero. > > f(int *t){ > > *t = 2 > > } > > What I did was that I create a wrapper > > void Wrapper(){ > > int a = 1; > > int *b = &a; > > f(b); > > // now I want to print the value of b > > // but I don't know how > > } > > > > Thanks. > > Vu > > On Thu, Feb 10, 2011 at 6:56 PM, Reid Kleckner > > wrote: > >> > >> Not sure what you mean here. If you have a copy of that pointer in > >> the caller of the wrapper function, you should be able to follow it to > >> recover the modified value as normal. > >> > >> Reid > >> > >> On Thu, Feb 10, 2011 at 9:20 PM, Vu Le wrote: > >> > Hi Reid, > >> > If an argument is a pointer and the function changes the value it > >> > pointed > >> > to, > >> > do you know how to get that updated value after executing the wrapper > >> > function? > >> > > >> > Thanks. > >> > Vu > >> > > >> > On Tue, Jan 11, 2011 at 2:40 PM, Reid Kleckner < > reid.kleckner at gmail.com> > >> > wrote: > >> >> > >> >> On Tue, Jan 11, 2011 at 1:41 PM, Vu Le wrote: > >> >> > Hi, > >> >> > I want to implement a tool that probes a function with several > input > >> >> > and > >> >> > records all the return output. > >> >> > The function might have more than 1 return value (by reference > >> >> > parameters). > >> >> > > >> >> > Does ExecutionEngine::runFunction() support function call with > >> >> > complex > >> >> > argument type? > >> >> > If not, I guess that I have to create a wrapper function, prepare > all > >> >> > the > >> >> > data, and call the original function. > >> >> > Am I on the right track? > >> >> > >> >> For functions with complicated parameters and return values, > >> >> runFunction will generate a wrapper function that calls the function > >> >> with the right arguments. This is fairly expensive and leaks memory > >> >> if called more than once for the same function. If the type of the > >> >> function is known, you can just use getPointerToFunction, cast that, > >> >> and call it from C. > >> >> > >> >> If it's not known but you want to call it many times with different > >> >> arguments, you could generate a wrapper function responsible for > >> >> unpacking your own datastructure describing the arguments and calling > >> >> the function you are testing with those arguments. Seems like you > are > >> >> on the right track there. > >> >> > >> >> Reid > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/3a8f7ca9/attachment.html From stoklund at 2pi.dk Fri Feb 11 13:51:53 2011 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Fri, 11 Feb 2011 11:51:53 -0800 Subject: [LLVMdev] preserving an implicit def between basic blocks In-Reply-To: References: Message-ID: <37654312-FB77-460C-BB5E-FB98D81DE7B4@2pi.dk> On Feb 11, 2011, at 3:13 AM, Alexandru Dura wrote: > In BB0 there is an instruction that defines a flag (implicit def) and in BB1 there is one that reads the flag (implicit use). When i run llc with -O3, the instruction in BB0 that defines the flag is removed. How can i prevent this? BB0 and BB1 are consecutive basic blocks. The SSA form of machine instructions does not support physical registers live across basic blocks. You can mark your flag register as reserved to prevent DeadMachineInstructionElim from removing the defining instructions. /jakob From echristo at apple.com Fri Feb 11 14:04:54 2011 From: echristo at apple.com (Eric Christopher) Date: Fri, 11 Feb 2011 12:04:54 -0800 Subject: [LLVMdev] G++ 3.4.5 under RedHat AS4 fails to compile Clang trunk In-Reply-To: References: Message-ID: <182AA2CA-08B1-460D-822B-86C2524D7E04@apple.com> On Feb 11, 2011, at 3:48 AM, Lian Cheng wrote: > Compilation error output is attached. > > Seems that G++ 3.4.5 fails to pick the right specialization version of getExprLocImpl() function in lib/AST/Expr.cpp. http://llvm.org/docs/GettingStarted.html#brokengcc -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/ffa764d2/attachment.html From wan at google.com Fri Feb 11 14:55:26 2011 From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=) Date: Fri, 11 Feb 2011 12:55:26 -0800 Subject: [LLVMdev] adding a function to test whether a char is a path separator Message-ID: Hi Doug, While refactoring clang::FileManager to use llvm::sys::path, I had a need for a function to test whether a char is a path separator. I think it would be generally useful. Would you be able to review it? You can see http://codereview.appspot.com/4186045 or the attachment. Thanks, -- Zhanyong -------------- next part -------------- A non-text attachment was scrubbed... Name: is_separator.patch Type: text/x-patch Size: 2481 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/54ad4b7d/attachment.bin From dgregor at apple.com Fri Feb 11 15:01:14 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 11 Feb 2011 13:01:14 -0800 Subject: [LLVMdev] adding a function to test whether a char is a path separator In-Reply-To: References: Message-ID: Looks good to me! - Doug On Feb 11, 2011, at 12:55 PM, Zhanyong Wan (?x.x x) wrote: > Hi Doug, > > While refactoring clang::FileManager to use llvm::sys::path, I had a > need for a function to test whether a char is a path separator. I > think it would be generally useful. Would you be able to review it? > You can see http://codereview.appspot.com/4186045 or the attachment. > > Thanks, > -- > Zhanyong > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/f593ffd9/attachment.html From z_alk at live.concordia.ca Fri Feb 11 15:08:32 2011 From: z_alk at live.concordia.ca (Zaid A.m. Al-Khatib) Date: Fri, 11 Feb 2011 21:08:32 +0000 Subject: [LLVMdev] Function::viewCFG() undefined reference Message-ID: Hello all, I am getting an undefined reference to Function::viewCFG() I have a function list iterator F and I am trying to get the CFG through F->viewCFG(); other function calls through the F pointer are working. - I have included the libraries: pthread, ffi, dl, m, LLVMAsmParse, LLVMCore, LLVMSupport, LLVMSystem. - I have dot and gv in my path, and I have reconfigured and rebuilt LLVM after using: .$/configure --srcdir=/home/zaid/llvm/llvm/ --disable-optimized --enable-debug-runtime $make which ended with llvm[0]: ***** Completed Debug Build llvm[0]: ***** Note: Debug build can be 10 times slower than an llvm[0]: ***** optimized build. Use make ENABLE_OPTIMIZED=1 to llvm[0]: ***** make an optimized build. Alternatively you can llvm[0]: ***** configure with --enable-optimized. [1]+ Done nedit configure restarted and tried again and it still doesn't work, same problem. Any ideas ? Thanks ! From grosser at fim.uni-passau.de Fri Feb 11 15:57:42 2011 From: grosser at fim.uni-passau.de (Tobias Grosser) Date: Fri, 11 Feb 2011 16:57:42 -0500 Subject: [LLVMdev] LLVM wiki cannot upload files Message-ID: <4D55B0D6.3020902@fim.uni-passau.de> Hi, I tried to add some info to the LLVM wiki and it seems there is still an unsolved bug. Uploading of files is not possible because permissions are not set correctly. I assume this is a bug, because this worked once. http://llvm.org/bugs/show_bug.cgi?id=7640 Can anybody have a look? Tobi From viridia at gmail.com Fri Feb 11 18:17:55 2011 From: viridia at gmail.com (Talin) Date: Fri, 11 Feb 2011 16:17:55 -0800 Subject: [LLVMdev] Stricter adherence to coding standards in LLVM? Message-ID: I notice that there's a lot of code in LLVM core libraries that is wildly inconsistent in formatting. Two particular things come to mind: -- Capitalization of method names. The LLVM guidelines say one thing, but a lot of recent code (such as IRBuilder) consistently does the opposite of what the guidelines say. One has to wonder which source of truth is more authoritative - after all, the docs could always be out of date. -- Whitespace around * and & in variable declarations. I see some files that consistently put the space after, some files put it before, while some files use one convention for parameters, and a different convention for member variables and local variables. Within a single file, the usage is pretty consistent, so you know that the people who wrote the code were really trying to adhere to a standard. Now, common wisdom for open source projects is that inconsistent legacy formatting is left alone, and new code adheres to whatever style is used in nearby code. Otherwise it creates difficulty for people who want to compare revisions in the source control. Occasionally there is a need to diff revisions that are widely spaced in time, and a global reformatting makes this hard if the reformatting change falls somewhere within the timespan of interest. The downside of this approach is that you're stuck with the inconsistent formatting forever. In my own open source projects, I take the opposite approach, which is to nip any inconsistencies in the bud as early and aggressively as possible, so that they won't cause problems later on. A person who needs to compare two revisions is far more likely to be interested in recent revisions than really old ones, so it's better to do large changes sooner rather than later - the farther in the past we can push back the reformatting the better. There is also the problem of backwards compatibility with existing users of the code. Obviously it's bad form to break user code for trivial stylistic reasons. However, if there is some other API change with broad impact that's going in, it might make sense to fix the names at the same time, given that folks are going to have to update their code anyway. (Although that's unlikely with a codebase as mature as LLVM). Another approach is to deprecate the old API for a given class entirely, and replace it with some newer, shinier version that just happens to conform to the letter of the conventions, so that people can continue to use the old class until they get around to upgrading. In the case of whitespace around * and &, that is semantically neutral, and the impact on the diffs are small, so a global fix to these would incur less pain overall. The main danger is that the discussion of proper style is likely to turn into a major religious war, making it not worth the effort to even raise the topic. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/f2e45dda/attachment.html From damien.llvm at gmail.com Fri Feb 11 20:38:36 2011 From: damien.llvm at gmail.com (Damien Vincent) Date: Fri, 11 Feb 2011 18:38:36 -0800 Subject: [LLVMdev] Instruction info on X86 - X86Wrapper Message-ID: In the X86 implementation, I noticed that tglobaladdr, tconstpool, ... are wrapped using node X86Wrapper. Do you have any idea of the goal of this wrapper ? Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/766f942e/attachment.html From rob.nikander at gmail.com Fri Feb 11 20:50:19 2011 From: rob.nikander at gmail.com (Rob Nikander) Date: Fri, 11 Feb 2011 21:50:19 -0500 Subject: [LLVMdev] One or many modules with the JIT? Message-ID: Hi, I'm at the beginning stages of building a language that uses the JIT, and works like a scripting language in that you run the source files without explicit compilation. I'd like to start using modules in the source language. Usually a module will correspond to a file. I'm wondering if I should also use separate LLVM modules, or keep compiling everything to the single module associated with the JIT engine. I see an `addModule' function in the engine, but I don't know what it does. Does that take care of linking? If that allows me to use separate LLVM modules, is there an advantage of doing it that way? thanks, Rob From reid.kleckner at gmail.com Fri Feb 11 22:15:22 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Fri, 11 Feb 2011 23:15:22 -0500 Subject: [LLVMdev] One or many modules with the JIT? In-Reply-To: References: Message-ID: If you're planning on making your own interpreter and module data structures, I'd say it's easiest to use a single module for all machine code you end up generating. No reason to complicate things by tracking different LLVM modules if you don't have to. Reid On Fri, Feb 11, 2011 at 9:50 PM, Rob Nikander wrote: > Hi, > > I'm at the beginning stages of building a language that uses the JIT, > and works like a scripting language in that you run the source files > without explicit compilation. ?I'd like to start using modules in the > source language. ?Usually a module will correspond to a file. ?I'm > wondering if I should also use separate LLVM modules, or keep > compiling everything to the single module associated with the JIT > engine. ? I see an `addModule' function in the engine, but I don't > know what it does. ?Does that take care of linking? ? If that allows > me to use separate LLVM modules, is there an advantage of doing it > that way? > > thanks, > Rob > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From Michael.Smith at synopsys.com Fri Feb 11 22:52:27 2011 From: Michael.Smith at synopsys.com (Michael Smith) Date: Fri, 11 Feb 2011 20:52:27 -0800 Subject: [LLVMdev] pow operator on Windows In-Reply-To: References: Message-ID: I have a very simple test case on Windows that shows some surprising behavior. This doesn't seem to be a problem on Linux. The example is: #include #include double heat(double Pr) { return pow(Pr, 0.33); } int main(int argc, char **argv) { double Nu = heat(291.00606180486119); printf("%.20f\n", Nu); } I've tested with MinGW's gcc.exe 3.4.5 and the Visual Studio 2008 C++ compiler, and LLVM 2.7 and 2.8. With "gcc test.c; ./a.exe", the printed result is 6.50260946378542390000 With "clang -emit-llvm -c test.c -o test.bc; lli test.bc", the printed result is 6.50260946378542480000 The difference in the last 2 digits is significant in the scientific software I'm working on. Does anyone have an explanation for why they differ, or how to make them behave the same? Thanks, Michael Smith From anton.skvorts at gmail.com Fri Feb 11 23:07:48 2011 From: anton.skvorts at gmail.com (Anton Skvorts) Date: Sat, 12 Feb 2011 05:07:48 +0000 Subject: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*' Message-ID: Hi Apolagize if this newbie question has some obvious answer. When running something like ... ExprAST *Init = GlobalNames[i].second; const Value *InitVal; InitVal = Init->Codegen(); GlobalVariable * globvar = new GlobalVariable(*TheModule, InitVal->getType(), false, llvm::GlobalValue::ExternalLinkage, InitVal, Twine(GlobalName)); ... I'm getting the following error error: invalid conversion from `const llvm::Value*' to `llvm::Constant*' How may I make this conversion? Any help would be much appreciated! Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/cd5fbea8/attachment.html From eli.friedman at gmail.com Sat Feb 12 00:03:57 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 11 Feb 2011 22:03:57 -0800 Subject: [LLVMdev] pow operator on Windows In-Reply-To: References: Message-ID: On Fri, Feb 11, 2011 at 8:52 PM, Michael Smith wrote: > I have a very simple test case on Windows that shows some surprising behavior. This doesn't seem to be a problem on Linux. > > The example is: > #include > #include > double heat(double Pr) { > ?return pow(Pr, 0.33); > } > int main(int argc, char **argv) { > ?double Nu = heat(291.00606180486119); > ?printf("%.20f\n", Nu); > } > > I've tested with MinGW's gcc.exe 3.4.5 and the Visual Studio 2008 C++ compiler, and LLVM 2.7 and 2.8. > With "gcc test.c; ./a.exe", the printed result is 6.50260946378542390000 > With "clang -emit-llvm -c test.c -o test.bc; lli test.bc", the printed result is 6.50260946378542480000 > > The difference in the last 2 digits is significant in the scientific software I'm working on. Does anyone have an explanation for why they differ, or how to make them behave the same? Both answers are within one double-precision ulp of the true answer, which is roughly 6.5026094637854243. So both answers are acceptable return values for pow(); normal implementations do not guarantee half-ulp accuracy for transcendental functions like pow(). My guess is that lli and the gcc-compiled program are using different versions of the C runtime library, and therefore different pow() implementations. If you really care about floating-point calculations being precisely reproducible across platforms, I would suggest using a library like mpfr instead of the compiler's floating-point implementation. -Eli From viridia at gmail.com Sat Feb 12 01:22:42 2011 From: viridia at gmail.com (Talin) Date: Fri, 11 Feb 2011 23:22:42 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules Message-ID: I've written a little GUI application that displays an LLVM module as an expandable tree, which can be useful for examining the module's contents. Some features: - Based on wxWidgets, so it's completely cross-platform. - CMake build script can locate both LLVM and wxWidgets installations automatically. - Loads either .ll or .bc files. - Supports browsing of LLVM types, variables, functions, aliases, and metadata. I'm working on supporting a more structured view of DWARF DIEs, but that is not complete. - Tree nodes are created lazily as needed. - The tree node system is highly extensible, each different LLVM object type is represented by a tree node class, adding new node classes is extremely easy. - The code is very straightforward and easy to read. - All image resources are embedded in the final executable, so the compiles program is just a single binary file, very easily installed. This is still a work in progress, but I think it's ready for people to start hacking on. If there is interest, I can check the code into the llvm.org svn somewhere - I just need to know where to put it. Otherwise, I'm happy to email a zip archive to folks who are interested. I'm willing to release the code under whatever license is most convenient. Here's a screenshot of what it looks like: [image: llbrowse.png] And here's what the node class for displaying variables looks like, as an example: class VariableItem : public TreeItemBase { public: VariableItem(const llvm::Module* module, const llvm::GlobalVariable* var) : module_(module), var_(var) {} // Overrides int GetIcon() const; wxString GetCaption() const; void CreateChildren(wxTreeCtrl* tree, const wxTreeItemId& id); bool CanCreateChildren() const; void ShowDetails(DetailsView* detailsView); private: const llvm::Module* const module_; const llvm::GlobalVariable* const var_; }; -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/aac344f7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 66648 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110211/aac344f7/attachment-0001.png From rengolin at systemcall.org Sat Feb 12 03:31:10 2011 From: rengolin at systemcall.org (Renato Golin) Date: Sat, 12 Feb 2011 09:31:10 +0000 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: Nice! I'm interested... would also be nice to cross this with llvm diff, eh? :) Cheers, Renato On 12-Feb-2011 7:28 AM, "Talin" wrote: > I've written a little GUI application that displays an LLVM module as an > expandable tree, which can be useful for examining the module's contents. > Some features: > > - Based on wxWidgets, so it's completely cross-platform. > - CMake build script can locate both LLVM and wxWidgets installations > automatically. > - Loads either .ll or .bc files. > - Supports browsing of LLVM types, variables, functions, aliases, and > metadata. I'm working on supporting a more structured view of DWARF DIEs, > but that is not complete. > - Tree nodes are created lazily as needed. > - The tree node system is highly extensible, each different LLVM object > type is represented by a tree node class, adding new node classes is > extremely easy. > - The code is very straightforward and easy to read. > - All image resources are embedded in the final executable, so the > compiles program is just a single binary file, very easily installed. > > This is still a work in progress, but I think it's ready for people to start > hacking on. > > If there is interest, I can check the code into the llvm.org svn somewhere - > I just need to know where to put it. Otherwise, I'm happy to email a zip > archive to folks who are interested. I'm willing to release the code under > whatever license is most convenient. > > Here's a screenshot of what it looks like: > > [image: llbrowse.png] > > And here's what the node class for displaying variables looks like, as an > example: > > class VariableItem : public TreeItemBase { > public: > VariableItem(const llvm::Module* module, const llvm::GlobalVariable* var) > : module_(module), var_(var) {} > > // Overrides > > int GetIcon() const; > wxString GetCaption() const; > void CreateChildren(wxTreeCtrl* tree, const wxTreeItemId& id); > bool CanCreateChildren() const; > void ShowDetails(DetailsView* detailsView); > > private: > const llvm::Module* const module_; > const llvm::GlobalVariable* const var_; > }; > > > -- > -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/8ae9cc2a/attachment.html From blunted2night at gmail.com Sat Feb 12 04:07:25 2011 From: blunted2night at gmail.com (Nathan Jeffords) Date: Sat, 12 Feb 2011 02:07:25 -0800 Subject: [LLVMdev] [patch] Dwarf Debug info support for COFF object files Message-ID: Hello All, I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything looks to be in order. Here is a short description of what the patches accomplish die.patch: adds a new DIEValue type to represent a section relative label. (their was already a type id specified so I provided a class modeled after DIELabel) secrel-fixup.patch: creats a new target specific fixup type (reloc_coff_secrel32) to represent COFF Section Relative relocations and updats the COFF object writer to write it as COFF_IMAGE_REL_AMD64_SREL32 secrel-streamer.patch adds a new directive in the MCStreamer interface to allow the AsmPrinter to emit a section relative label and provides implementations for all existings Streamer (all but WinCOFF either forward or error on it) secrel-dwarf.patch updates dwarf printing code to make use of the new directive & DIE value where appropriate (this is where the bug fix is) coff-debug.patch turns the dwarf output on in the X86/COFF AsmInfo classes - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/19580f05/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: die.patch Type: application/octet-stream Size: 2386 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/19580f05/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: secrel-fixup.patch Type: application/octet-stream Size: 2123 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/19580f05/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: secrel-streamer.patch Type: application/octet-stream Size: 6292 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/19580f05/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: secrel-dwarf.patch Type: application/octet-stream Size: 2349 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/19580f05/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: coff-debug.patch Type: application/octet-stream Size: 821 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/19580f05/attachment-0004.obj From raghu at cs.ucla.edu Sat Feb 12 04:42:01 2011 From: raghu at cs.ucla.edu (Raghu Prabhakar) Date: Sat, 12 Feb 2011 02:42:01 -0800 (PST) Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: Message-ID: <1402494654.86991.1297507321277.JavaMail.root@mail.cs.ucla.edu> Hi Talin, This looks interesting..! Can you email me your tool? Cheers, Raghu. ----- Original Message ----- From: "Renato Golin" To: "Talin" Cc: "LLVM Developers Mailing List" Sent: Saturday, February 12, 2011 1:31:10 AM Subject: Re: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules Nice! I'm interested... would also be nice to cross this with llvm diff, eh? :) Cheers, Renato On 12-Feb-2011 7:28 AM, "Talin" < viridia at gmail.com > wrote: > I've written a little GUI application that displays an LLVM module as an > expandable tree, which can be useful for examining the module's contents. > Some features: > > - Based on wxWidgets, so it's completely cross-platform. > - CMake build script can locate both LLVM and wxWidgets installations > automatically. > - Loads either .ll or .bc files. > - Supports browsing of LLVM types, variables, functions, aliases, and > metadata. I'm working on supporting a more structured view of DWARF DIEs, > but that is not complete. > - Tree nodes are created lazily as needed. > - The tree node system is highly extensible, each different LLVM object > type is represented by a tree node class, adding new node classes is > extremely easy. > - The code is very straightforward and easy to read. > - All image resources are embedded in the final executable, so the > compiles program is just a single binary file, very easily installed. > > This is still a work in progress, but I think it's ready for people to start > hacking on. > > If there is interest, I can check the code into the llvm.org svn somewhere - > I just need to know where to put it. Otherwise, I'm happy to email a zip > archive to folks who are interested. I'm willing to release the code under > whatever license is most convenient. > > Here's a screenshot of what it looks like: > > [image: llbrowse.png] > > And here's what the node class for displaying variables looks like, as an > example: > > class VariableItem : public TreeItemBase { > public: > VariableItem(const llvm::Module* module, const llvm::GlobalVariable* var) > : module_(module), var_(var) {} > > // Overrides > > int GetIcon() const; > wxString GetCaption() const; > void CreateChildren(wxTreeCtrl* tree, const wxTreeItemId& id); > bool CanCreateChildren() const; > void ShowDetails(DetailsView* detailsView); > > private: > const llvm::Module* const module_; > const llvm::GlobalVariable* const var_; > }; > > > -- > -- Talin _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dg at cowlark.com Sat Feb 12 05:34:45 2011 From: dg at cowlark.com (David Given) Date: Sat, 12 Feb 2011 11:34:45 +0000 Subject: [LLVMdev] pow operator on Windows In-Reply-To: References: Message-ID: <4D567055.2030507@cowlark.com> On 12/02/11 04:52, Michael Smith wrote: [...] > With "gcc test.c; ./a.exe", the printed result is 6.50260946378542390000 > With "clang -emit-llvm -c test.c -o test.bc; lli test.bc", the printed result is 6.50260946378542480000 The x86 has got several different FPU instruction sets, which don't all work at the same precision. In particular, using 387 instructions uses 80-bit floats when working with temporaries, while SSE instructions use 64-bit floats. gcc's default choice is 387, so if clang is defaulting to SSE (which most compiler software these days does because 387 instructions are horrible), this might explain the results you get. You might want to look at the generated machine code to see how they differ. If this *is* the problem, you can tell gcc to use a particular instruction set with -mfpmath=386 or -mfpmath=sse. -- ???? ?????????????? ????? http://www.cowlark.com ????? ? ? "I have a mind like a steel trap. It's rusty and full of dead mice." ? --- Anonymous, on rasfc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/b943e374/attachment.bin From dimitry at andric.com Sat Feb 12 06:06:30 2011 From: dimitry at andric.com (Dimitry Andric) Date: Sat, 12 Feb 2011 13:06:30 +0100 Subject: [LLVMdev] pow operator on Windows In-Reply-To: <4D567055.2030507@cowlark.com> References: <4D567055.2030507@cowlark.com> Message-ID: <4D5677C6.9040605@andric.com> On 2011-02-12 12:34, David Given wrote: ... > You might want to look at the generated machine code to see how they > differ. If this *is* the problem, you can tell gcc to use a particular > instruction set with -mfpmath=386 or -mfpmath=sse. I think you mean -mfpmath=387, instead. :) Btw, this option is also not supported by clang... any idea how it could be implemented, if at all? From baldrick at free.fr Sat Feb 12 06:47:01 2011 From: baldrick at free.fr (Duncan Sands) Date: Sat, 12 Feb 2011 13:47:01 +0100 Subject: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*' In-Reply-To: References: Message-ID: <4D568145.1000400@free.fr> Hi Anton, > I'm getting the following error > > error: invalid conversion from `const llvm::Value*' to `llvm::Constant*' > > How may I make this conversion? Any help would be much appreciated! cast(whatever) Ciao, Duncan. From fvbommel at gmail.com Sat Feb 12 07:14:20 2011 From: fvbommel at gmail.com (Frits van Bommel) Date: Sat, 12 Feb 2011 14:14:20 +0100 Subject: [LLVMdev] pow operator on Windows In-Reply-To: <4D5677C6.9040605@andric.com> References: <4D567055.2030507@cowlark.com> <4D5677C6.9040605@andric.com> Message-ID: On Sat, Feb 12, 2011 at 1:06 PM, Dimitry Andric wrote: > On 2011-02-12 12:34, David Given wrote: >> You might want to look at the generated machine code to see how they >> differ. If this *is* the problem, you can tell gcc to use a particular >> instruction set with -mfpmath=386 or -mfpmath=sse. > > I think you mean -mfpmath=387, instead. :) > > Btw, this option is also not supported by clang... any idea how it could > be implemented, if at all? Shouldn't be that hard for 32-bit x86 since -mattr=-sse already works when passed to llc (but not clang) so you should be able to just copy that code. For x86-64 it's trickier, as the calling convention uses SSE registers so -mattr=-sse ICEs when returning floats etc. ("LLVM ERROR: SSE register return with SSE disabled"). This would need either a) a more selective option to disable SSE *math* only (but allow use of SSE registers for parameters and return values), or b) change the calling convention to use x87 registers instead. This which would require recompiling anything that accepts or returns floating-point numbers, including printf(), sqrt() and friends, etc. From czhao at eecg.toronto.edu Sat Feb 12 21:15:04 2011 From: czhao at eecg.toronto.edu (Chuck Zhao) Date: Sat, 12 Feb 2011 22:15:04 -0500 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: <1402494654.86991.1297507321277.JavaMail.root@mail.cs.ucla.edu> References: <1402494654.86991.1297507321277.JavaMail.root@mail.cs.ucla.edu> Message-ID: <4D574CB8.60709@eecg.toronto.edu> I am interested, too. Thank you Chuck On 2/12/2011 5:42 AM, Raghu Prabhakar wrote: > Hi Talin, > > This looks interesting..! Can you email me your tool? > Cheers, > Raghu. > > ----- Original Message ----- > From: "Renato Golin" > To: "Talin" > Cc: "LLVM Developers Mailing List" > Sent: Saturday, February 12, 2011 1:31:10 AM > Subject: Re: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules > > > > > Nice! I'm interested... would also be nice to cross this with llvm diff, eh? :) > > Cheers, > Renato > On 12-Feb-2011 7:28 AM, "Talin"< viridia at gmail.com> wrote: >> I've written a little GUI application that displays an LLVM module as an >> expandable tree, which can be useful for examining the module's contents. >> Some features: >> >> - Based on wxWidgets, so it's completely cross-platform. >> - CMake build script can locate both LLVM and wxWidgets installations >> automatically. >> - Loads either .ll or .bc files. >> - Supports browsing of LLVM types, variables, functions, aliases, and >> metadata. I'm working on supporting a more structured view of DWARF DIEs, >> but that is not complete. >> - Tree nodes are created lazily as needed. >> - The tree node system is highly extensible, each different LLVM object >> type is represented by a tree node class, adding new node classes is >> extremely easy. >> - The code is very straightforward and easy to read. >> - All image resources are embedded in the final executable, so the >> compiles program is just a single binary file, very easily installed. >> >> This is still a work in progress, but I think it's ready for people to start >> hacking on. >> >> If there is interest, I can check the code into the llvm.org svn somewhere - >> I just need to know where to put it. Otherwise, I'm happy to email a zip >> archive to folks who are interested. I'm willing to release the code under >> whatever license is most convenient. >> >> Here's a screenshot of what it looks like: >> >> [image: llbrowse.png] >> >> And here's what the node class for displaying variables looks like, as an >> example: >> >> class VariableItem : public TreeItemBase { >> public: >> VariableItem(const llvm::Module* module, const llvm::GlobalVariable* var) >> : module_(module), var_(var) {} >> >> // Overrides >> >> int GetIcon() const; >> wxString GetCaption() const; >> void CreateChildren(wxTreeCtrl* tree, const wxTreeItemId& id); >> bool CanCreateChildren() const; >> void ShowDetails(DetailsView* detailsView); >> >> private: >> const llvm::Module* const module_; >> const llvm::GlobalVariable* const var_; >> }; >> >> >> -- >> -- Talin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gvenn.cfe.dev at gmail.com Sat Feb 12 08:40:45 2011 From: gvenn.cfe.dev at gmail.com (Garrison Venn) Date: Sat, 12 Feb 2011 09:40:45 -0500 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: Looks cool Talin. Personally it would be nice if it was checked into llvm.org, but is wxWidgets LGPL like license an issue for llvm's repository? Anyway I would be interested in a copy otherwise under a BSD like license. Thanks in advance Garrison On Feb 12, 2011, at 2:22, Talin wrote: > I've written a little GUI application that displays an LLVM module as an expandable tree, which can be useful for examining the module's contents. Some features: > Based on wxWidgets, so it's completely cross-platform. > CMake build script can locate both LLVM and wxWidgets installations automatically. > Loads either .ll or .bc files. > Supports browsing of LLVM types, variables, functions, aliases, and metadata. I'm working on supporting a more structured view of DWARF DIEs, but that is not complete. > Tree nodes are created lazily as needed. > The tree node system is highly extensible, each different LLVM object type is represented by a tree node class, adding new node classes is extremely easy. > The code is very straightforward and easy to read. > All image resources are embedded in the final executable, so the compiles program is just a single binary file, very easily installed. > This is still a work in progress, but I think it's ready for people to start hacking on. > > If there is interest, I can check the code into the llvm.org svn somewhere - I just need to know where to put it. Otherwise, I'm happy to email a zip archive to folks who are interested. I'm willing to release the code under whatever license is most convenient. > > Here's a screenshot of what it looks like: > > > > And here's what the node class for displaying variables looks like, as an example: > > class VariableItem : public TreeItemBase { > public: > VariableItem(const llvm::Module* module, const llvm::GlobalVariable* var) > : module_(module), var_(var) {} > > // Overrides > > int GetIcon() const; > wxString GetCaption() const; > void CreateChildren(wxTreeCtrl* tree, const wxTreeItemId& id); > bool CanCreateChildren() const; > void ShowDetails(DetailsView* detailsView); > > private: > const llvm::Module* const module_; > const llvm::GlobalVariable* const var_; > }; > > -- > -- Talin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/6b67dbe4/attachment.html From rhythm.mail at gmail.com Fri Feb 11 21:02:11 2011 From: rhythm.mail at gmail.com (Lian Cheng) Date: Sat, 12 Feb 2011 11:02:11 +0800 Subject: [LLVMdev] G++ 3.4.5 under RedHat AS4 fails to compile Clang trunk In-Reply-To: <182AA2CA-08B1-460D-822B-86C2524D7E04@apple.com> References: <182AA2CA-08B1-460D-822B-86C2524D7E04@apple.com> Message-ID: <4D55F833.6050200@gmail.com> On 2011-2-12 4:04, Eric Christopher wrote: > > On Feb 11, 2011, at 3:48 AM, Lian Cheng wrote: > >> Compilation error output is attached. >> >> Seems that G++ 3.4.5 fails to pick the right specialization version of >> getExprLocImpl() function in lib/AST/Expr.cpp. > > http://llvm.org/docs/GettingStarted.html#brokengcc Thanks for your reply! But this page suggests that GCC 3.4.x *MISCOMPILES* portions of the code on X86-64/amd64. IMHO this means GCC 3.4.x do compiles LLVM, but the compiled binary misbehaves. While my problem is GCC 3.4.5 fails to compile Clang (not LLVM). Cheng > > -eric > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From rhythm.mail at gmail.com Fri Feb 11 21:02:11 2011 From: rhythm.mail at gmail.com (Lian Cheng) Date: Sat, 12 Feb 2011 11:02:11 +0800 Subject: [LLVMdev] G++ 3.4.5 under RedHat AS4 fails to compile Clang trunk In-Reply-To: <182AA2CA-08B1-460D-822B-86C2524D7E04@apple.com> References: <182AA2CA-08B1-460D-822B-86C2524D7E04@apple.com> Message-ID: <4D55F833.6050200@gmail.com> On 2011-2-12 4:04, Eric Christopher wrote: > > On Feb 11, 2011, at 3:48 AM, Lian Cheng wrote: > >> Compilation error output is attached. >> >> Seems that G++ 3.4.5 fails to pick the right specialization version of >> getExprLocImpl() function in lib/AST/Expr.cpp. > > http://llvm.org/docs/GettingStarted.html#brokengcc Thanks for your reply! But this page suggests that GCC 3.4.x *MISCOMPILES* portions of the code on X86-64/amd64. IMHO this means GCC 3.4.x do compiles LLVM, but the compiled binary misbehaves. While my problem is GCC 3.4.5 fails to compile Clang (not LLVM). Cheng > > -eric > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From viridia at gmail.com Sat Feb 12 12:14:13 2011 From: viridia at gmail.com (Talin) Date: Sat, 12 Feb 2011 10:14:13 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: A lot of people have requested a source archive, so I'm making available here: http://code.google.com/p/tart/downloads/detail?name=llbrowse.tgz Have fun! On Fri, Feb 11, 2011 at 11:22 PM, Talin wrote: > I've written a little GUI application that displays an LLVM module as an > expandable tree, which can be useful for examining the module's contents. > Some features: > > - Based on wxWidgets, so it's completely cross-platform. > - CMake build script can locate both LLVM and wxWidgets installations > automatically. > - Loads either .ll or .bc files. > - Supports browsing of LLVM types, variables, functions, aliases, and > metadata. I'm working on supporting a more structured view of DWARF DIEs, > but that is not complete. > - Tree nodes are created lazily as needed. > - The tree node system is highly extensible, each different LLVM object > type is represented by a tree node class, adding new node classes is > extremely easy. > - The code is very straightforward and easy to read. > - All image resources are embedded in the final executable, so the > compiles program is just a single binary file, very easily installed. > > This is still a work in progress, but I think it's ready for people to > start hacking on. > > If there is interest, I can check the code into the llvm.org svn somewhere > - I just need to know where to put it. Otherwise, I'm happy to email a zip > archive to folks who are interested. I'm willing to release the code under > whatever license is most convenient. > > Here's a screenshot of what it looks like: > > [image: llbrowse.png] > > And here's what the node class for displaying variables looks like, as an > example: > > class VariableItem : public TreeItemBase { > public: > VariableItem(const llvm::Module* module, const llvm::GlobalVariable* var) > : module_(module), var_(var) {} > > // Overrides > > int GetIcon() const; > wxString GetCaption() const; > void CreateChildren(wxTreeCtrl* tree, const wxTreeItemId& id); > bool CanCreateChildren() const; > void ShowDetails(DetailsView* detailsView); > > private: > const llvm::Module* const module_; > const llvm::GlobalVariable* const var_; > }; > > > -- > -- Talin > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/25940955/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 66648 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/25940955/attachment.png From viridia at gmail.com Sat Feb 12 12:28:27 2011 From: viridia at gmail.com (Talin) Date: Sat, 12 Feb 2011 10:28:27 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: On Sat, Feb 12, 2011 at 6:40 AM, Garrison Venn wrote: > Looks cool Talin. > > Personally it would be nice if it was checked into llvm.org, but is > wxWidgets LGPL like license > an issue for llvm's repository? > There should be no problem with the license. wxWidgets is indeed distributed under a modified version of the LGPL (with a special exception to allow people to distribute binaries of their app without requiring the source). The LGPL allows derived works to be distributed under a more permissive license (such as BSD-like licenses) as long as all of the license terms are *less restrictive* than the LGPL. Also, since we're talking LGPL, not GPL, the "derived work" does not include applications based on the library, it only includes modifications to the library itself. Since LLBrowse does not include any wxWidgets source code, the source archive can be distributed under a BSD license. Binaries of LLBrowse can be distributed freely, without source, due to the special exception in the wxWidgets license. Thus, even though the University of Illinois license is not GPL-compatible (because of the copyright and endorsement clauses), this should not matter. Here's a page which lists which open source licenses are GPL-compatible: http://www.gnu.org/licenses/license-list.html > Anyway I would be interested in a copy otherwise under a BSD like license. > > Thanks in advance > > Garrison > > On Feb 12, 2011, at 2:22, Talin wrote: > > I've written a little GUI application that displays an LLVM module as an > expandable tree, which can be useful for examining the module's contents. > Some features: > > - Based on wxWidgets, so it's completely cross-platform. > - CMake build script can locate both LLVM and wxWidgets installations > automatically. > - Loads either .ll or .bc files. > - Supports browsing of LLVM types, variables, functions, aliases, and > metadata. I'm working on supporting a more structured view of DWARF DIEs, > but that is not complete. > - Tree nodes are created lazily as needed. > - The tree node system is highly extensible, each different LLVM object > type is represented by a tree node class, adding new node classes is > extremely easy. > - The code is very straightforward and easy to read. > - All image resources are embedded in the final executable, so the > compiles program is just a single binary file, very easily installed. > > This is still a work in progress, but I think it's ready for people to > start hacking on. > > If there is interest, I can check the code into the llvm.org svn somewhere > - I just need to know where to put it. Otherwise, I'm happy to email a zip > archive to folks who are interested. I'm willing to release the code under > whatever license is most convenient. > > Here's a screenshot of what it looks like: > > > > And here's what the node class for displaying variables looks like, as an > example: > > class VariableItem : public TreeItemBase { > public: > VariableItem(const llvm::Module* module, const llvm::GlobalVariable* var) > : module_(module), var_(var) {} > > // Overrides > > int GetIcon() const; > wxString GetCaption() const; > void CreateChildren(wxTreeCtrl* tree, const wxTreeItemId& id); > bool CanCreateChildren() const; > void ShowDetails(DetailsView* detailsView); > > private: > const llvm::Module* const module_; > const llvm::GlobalVariable* const var_; > }; > > > -- > -- Talin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/79fa90bb/attachment-0001.html From Michael.Smith at synopsys.com Sat Feb 12 12:41:36 2011 From: Michael.Smith at synopsys.com (Michael Smith) Date: Sat, 12 Feb 2011 10:41:36 -0800 Subject: [LLVMdev] pow operator on Windows In-Reply-To: References: <4D567055.2030507@cowlark.com> <4D5677C6.9040605@andric.com> Message-ID: This doesn't look related to llc's instructions. When I generate assembly using either llc or clang, they both use _pow; if I then compiled the assembly with gcc the results are identical to compiling the C source with gcc. So Eli's response that lli is using a different library than gcc and Visual Studio looks correct. The only option then is to use another library instead of llvm.pow.f64 - for my case this is easy because my actual use is generating LLVM bytecode directly rather than using clang. -----Original Message----- From: Frits van Bommel [mailto:fvbommel at gmail.com] Sent: Saturday, February 12, 2011 5:14 AM To: Dimitry Andric Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] pow operator on Windows On Sat, Feb 12, 2011 at 1:06 PM, Dimitry Andric wrote: > On 2011-02-12 12:34, David Given wrote: >> You might want to look at the generated machine code to see how they >> differ. If this *is* the problem, you can tell gcc to use a particular >> instruction set with -mfpmath=386 or -mfpmath=sse. > > I think you mean -mfpmath=387, instead. :) > > Btw, this option is also not supported by clang... any idea how it could > be implemented, if at all? Shouldn't be that hard for 32-bit x86 since -mattr=-sse already works when passed to llc (but not clang) so you should be able to just copy that code. For x86-64 it's trickier, as the calling convention uses SSE registers so -mattr=-sse ICEs when returning floats etc. ("LLVM ERROR: SSE register return with SSE disabled"). This would need either a) a more selective option to disable SSE *math* only (but allow use of SSE registers for parameters and return values), or b) change the calling convention to use x87 registers instead. This which would require recompiling anything that accepts or returns floating-point numbers, including printf(), sqrt() and friends, etc. From anton.skvorts at gmail.com Sat Feb 12 18:03:25 2011 From: anton.skvorts at gmail.com (Anton Skvorts) Date: Sun, 13 Feb 2011 00:03:25 +0000 Subject: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*' In-Reply-To: <4D568145.1000400@free.fr> References: <4D568145.1000400@free.fr> Message-ID: Hi Duncan Many many thanks, it works now! But there are still some details I must be missing. I'm getting an assertion when I try the following assignment in my script: global c = cos(1); Assertion failed: isa(Val) && "cast() argument of incompatible type!", file c:/llvm-source-2.7/include/llvm/Support/Casting.h, line 200 However, running for example cos(1); global a = 0.5403023058681398; # cos(1) = 0.5403023058681398 global b = 1 + 1; works fine @a = global double 0x3FE14A280FB5068C ; [#uses=0] @b = global double 2.000000e+000 ; [#uses=0] define double @0() { entry: ret double 0x3FE14A280FB5068C } The relevant code is ... Value *InitVal; InitVal = Init->Codegen(); GlobalVariable * globval = *new* *GlobalVariable*(*TheModule, InitVal->getType(), *false*, llvm::GlobalValue::*ExternalLinkage*, cast(InitVal), Twine(GlobalName) ); Any help, as always, would be really much appreciated! Anton Skvorts 2011/2/12 Duncan Sands > Hi Anton, > > > I'm getting the following error > > > > error: invalid conversion from `const llvm::Value*' to > `llvm::Constant*' > > > > How may I make this conversion? Any help would be much appreciated! > > > cast(whatever) > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110213/785d31fe/attachment.html From null.function at gmail.com Sat Feb 12 18:58:35 2011 From: null.function at gmail.com (nullnull) Date: Sat, 12 Feb 2011 19:58:35 -0500 Subject: [LLVMdev] Compiling LLVM-Clang with MinGW on Windows Message-ID: I'm a Windows user, and wish to run LLVM-Clang on Windows. In Visual Studio 2010, buidling was fairly straightforward via the solution file from CMake. However, there is no good document (thought I searched for an hour) how to compile LLVM with MinGW on Windows. I generated MinGW Makefile and build directories from CMake. I installed entire MinGW+MSys packages. I tried to run "make -f Makefile" in Msys command line. But, it just run another 'cmd.exe', and not working. Could you help me on this problem? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/717ee11f/attachment.html From geek4civic at gmail.com Sat Feb 12 19:16:59 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Sun, 13 Feb 2011 10:16:59 +0900 Subject: [LLVMdev] Compiling LLVM-Clang with MinGW on Windows In-Reply-To: References: Message-ID: On Sun, Feb 13, 2011 at 9:58 AM, nullnull wrote: > I generated MinGW Makefile and build directories from CMake. I installed > entire MinGW+MSys packages. I tried to run "make -f Makefile" in Msys > command line. But, it just run another 'cmd.exe', and not working. Why didn't you take "MSYS Makefiles" on CMake? FYI, it could be done with cmd.exe and mingw's make.exe (not MSYS's!) when you took "Mingw Makefiles" on CMake, unless %PATH% contains MSYS toolchain. ...Takumi From clattner at apple.com Sat Feb 12 20:03:29 2011 From: clattner at apple.com (Chris Lattner) Date: Sat, 12 Feb 2011 18:03:29 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: On Feb 12, 2011, at 10:28 AM, Talin wrote: > On Sat, Feb 12, 2011 at 6:40 AM, Garrison Venn wrote: > Looks cool Talin. > > Personally it would be nice if it was checked into llvm.org, but is wxWidgets LGPL like license > an issue for llvm's repository? > > There should be no problem with the license. wxWidgets is indeed distributed under a modified version of the LGPL (with a special exception to allow people to distribute binaries of their app without requiring the source). The LGPL allows derived works to be distributed under a more permissive license (such as BSD-like licenses) as long as all of the license terms are *less restrictive* than the LGPL. Also, since we're talking LGPL, not GPL, the "derived work" does not include applications based on the library, it only includes modifications to the library itself. Having GPL and other licenses in llvm's repositories is fine, dragonegg, llvm-gcc and the llvm-testsuite each have GPL code in them. Just keep repositories like LLVM, Clang, LLDB, etc pure UIUC license. Before checking this in to a new module, please whip up some web pages that document it. Thanks Talin! -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/c486a05a/attachment.html From viridia at gmail.com Sat Feb 12 20:18:24 2011 From: viridia at gmail.com (Talin) Date: Sat, 12 Feb 2011 18:18:24 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: On Sat, Feb 12, 2011 at 6:03 PM, Chris Lattner wrote: > > On Feb 12, 2011, at 10:28 AM, Talin wrote: > > On Sat, Feb 12, 2011 at 6:40 AM, Garrison Venn > wrote: > >> Looks cool Talin. >> >> Personally it would be nice if it was checked into llvm.org, but is >> wxWidgets LGPL like license >> an issue for llvm's repository? >> > > There should be no problem with the license. wxWidgets is indeed > distributed under a modified version of the LGPL (with a special exception > to allow people to distribute binaries of their app without requiring the > source). The LGPL allows derived works to be distributed under a more > permissive license (such as BSD-like licenses) as long as all of the license > terms are *less restrictive* than the LGPL. Also, since we're talking LGPL, > not GPL, the "derived work" does not include applications based on the > library, it only includes modifications to the library itself. > > > Having GPL and other licenses in llvm's repositories is fine, dragonegg, > llvm-gcc and the llvm-testsuite each have GPL code in them. Just keep > repositories like LLVM, Clang, LLDB, etc pure UIUC license. > > Before checking this in to a new module, please whip up some web pages that > document it. Thanks Talin! > > Do you have any suggestions as to where in the hierarchy this should go? What kind of docs are you looking for, user docs or developer docs? The program only has one command ("load module"), the rest is just displaying read-only data in tree form. BTW, I've added more support for displaying DWARF DIEs - here's a screenshot: [image: llbrowse2.png] -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/cca03650/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 48410 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/cca03650/attachment.png From clattner at apple.com Sat Feb 12 20:26:34 2011 From: clattner at apple.com (Chris Lattner) Date: Sat, 12 Feb 2011 18:26:34 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: On Feb 12, 2011, at 6:18 PM, Talin wrote: > Having GPL and other licenses in llvm's repositories is fine, dragonegg, llvm-gcc and the llvm-testsuite each have GPL code in them. Just keep repositories like LLVM, Clang, LLDB, etc pure UIUC license. > > Before checking this in to a new module, please whip up some web pages that document it. Thanks Talin! > > Do you have any suggestions as to where in the hierarchy this should go? I'd suggest a new top-level svn module. > What kind of docs are you looking for, user docs or developer docs? The program only has one command ("load module"), the rest is just displaying read-only data in tree form. User docs: what it is, what it depends on, how to build it, where to email questions/discussion about it etc. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/1dd529ab/attachment-0001.html From jianzhou at seas.upenn.edu Sat Feb 12 20:57:43 2011 From: jianzhou at seas.upenn.edu (Jianzhou Zhao) Date: Sat, 12 Feb 2011 21:57:43 -0500 Subject: [LLVMdev] any documents for the poolalloc project? Message-ID: Hi all, I was searching the background and document of the poolalloc project, but did not get any from google. Where can I find them? Thanks. -- Jianzhou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/2b728f3f/attachment.html From zaimoni at zaimoni.com Sat Feb 12 21:41:53 2011 From: zaimoni at zaimoni.com (Kenneth Boyd) Date: Sat, 12 Feb 2011 21:41:53 -0600 Subject: [LLVMdev] Compiling LLVM-Clang with MinGW on Windows In-Reply-To: References: Message-ID: <4D575301.1030304@zaimoni.com> On 2/12/2011 6:58 PM, nullnull wrote: > I'm a Windows user, and wish to run LLVM-Clang on Windows. > In Visual Studio 2010, buidling was fairly straightforward via the > solution file from CMake. However, there is no good document (thought > I searched for an hour) how to compile LLVM with MinGW on Windows. > I generated MinGW Makefile and build directories from CMake. Ok. > I installed entire MinGW+MSys packages. That's your problem. CMake actively refuses to generate makefiles for MingW32 if any flavor of the *NIX shell sh is on your path, including the sh provided by the MingW32 project. If you regenerate the makefile, it should autodetect MSYS in such a case. If the MSYS-targeted makefiles are broken (on my slightly non-standard MingW32 install with MSYS utilities, this is due to path format issues), you should look at my workaround : http://public.kitware.com/Bug/view.php?id=7870 . I have needed this workaround for all of CMake 2.6.2, 2.6.4, and 2.8.0, and expect the workaround to be needed indefinitely due to complete and utter lack of interest in a proper patch. Kenneth From tchammah at uwaterloo.ca Sat Feb 12 21:56:36 2011 From: tchammah at uwaterloo.ca (Tarek Chammah) Date: Sat, 12 Feb 2011 22:56:36 -0500 Subject: [LLVMdev] any documents for the poolalloc project? Message-ID: Hi Jianzhou, The best source of documentation for the poolalloc project remains Chris Lattner's dissertation: http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html Chapter 5 specifically if you'd like information on the poolalloc transformation. In addition to the thesis, there is also a brief manual for information on data structure analysis: http://llvm.org/svn/llvm-project/poolalloc/trunk/dsa-manual/ Tarek From null.function at gmail.com Sat Feb 12 22:17:38 2011 From: null.function at gmail.com (nullnull) Date: Sat, 12 Feb 2011 23:17:38 -0500 Subject: [LLVMdev] Compiling LLVM-Clang with MinGW on Windows In-Reply-To: <4D575301.1030304@zaimoni.com> References: <4D575301.1030304@zaimoni.com> Message-ID: Thanks Kenneth and Takumi. The soltuion was very simple. As Takumi pointed out, all I needed to just make MSYS makefiles. On Sat, Feb 12, 2011 at 10:41 PM, Kenneth Boyd wrote: > On 2/12/2011 6:58 PM, nullnull wrote: > > I'm a Windows user, and wish to run LLVM-Clang on Windows. > > In Visual Studio 2010, buidling was fairly straightforward via the > > solution file from CMake. However, there is no good document (thought > > I searched for an hour) how to compile LLVM with MinGW on Windows. > > I generated MinGW Makefile and build directories from CMake. > Ok. > > I installed entire MinGW+MSys packages. > That's your problem. CMake actively refuses to generate makefiles for > MingW32 if any flavor of the *NIX shell sh is on your path, including > the sh provided by the MingW32 project. If you regenerate the makefile, > it should autodetect MSYS in such a case. > > If the MSYS-targeted makefiles are broken (on my slightly non-standard > MingW32 install with MSYS utilities, this is due to path format issues), > you should look at my workaround : > http://public.kitware.com/Bug/view.php?id=7870 . I have needed this > workaround for all of CMake 2.6.2, 2.6.4, and 2.8.0, and expect the > workaround to be needed indefinitely due to complete and utter lack of > interest in a proper patch. > > Kenneth > _______________________________________________ > 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/20110212/921fa377/attachment.html From null.function at gmail.com Sat Feb 12 22:24:29 2011 From: null.function at gmail.com (nullnull) Date: Sat, 12 Feb 2011 23:24:29 -0500 Subject: [LLVMdev] Regarding CMake options for LLVM Message-ID: Figuring out to insert new compiling options or changing some options are very hard for a CMake newbie. I'm working on Windows (both Visual Studio, MingW/MSYS) via CMake. In particular, I'd like to do following two things: (1) I'd like to add "-std=c++0x" for some files in lib\Transforms\Instrumentation. (I don't think it's good idea to put this option entirely) (2) I'd like to change intermediate directories for all libraries and tools. (The default is ***.dir) I tried to add some CMake options, but failed. The aboves are easy on Visual Studio. But, chaning CMake (minimally) is hard to do. Thank you, "\0\0" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/6c7b8c07/attachment.html From jianzhou at seas.upenn.edu Sat Feb 12 22:40:26 2011 From: jianzhou at seas.upenn.edu (Jianzhou Zhao) Date: Sat, 12 Feb 2011 23:40:26 -0500 Subject: [LLVMdev] any documents for the poolalloc project? In-Reply-To: References: Message-ID: Thanks a lot! On Sat, Feb 12, 2011 at 10:56 PM, Tarek Chammah wrote: > Hi Jianzhou, > > The best source of documentation for the poolalloc project remains > Chris Lattner's dissertation: > http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html > > Chapter 5 specifically if you'd like information on the poolalloc > transformation. > > In addition to the thesis, there is also a brief manual for > information on data structure analysis: > http://llvm.org/svn/llvm-project/poolalloc/trunk/dsa-manual/ > > Tarek > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Jianzhou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110212/2a2a9c52/attachment.html From tzuhsiang.chien at gmail.com Sun Feb 13 00:00:00 2011 From: tzuhsiang.chien at gmail.com (Logan Chien) Date: Sun, 13 Feb 2011 14:00:00 +0800 Subject: [LLVMdev] Code/comment seems not synchronized in Mutex.cpp and RWMutex.cpp Message-ID: Hi, I'm confused by the comment and the source code of lib/Support/Mutex.cpp and lib/Support/RWMutex.cpp. In these files there are: // This variable is useful for situations where the pthread library has been // compiled with weak linkage for its interface symbols. This allows the // threading support to be turned off by simply *not linking against -lpthread*. // In that situation, the value of *pthread_mutex_init* will be 0 and // consequently pthread_enabled will be false. In such situations, all the // ... static const bool pthread_enabled = *true*; But pthread_enabled has no relation with pthread_mutex_init. I've check the log, pthread_enabled has been assigned to true since 2006. It was: static const bool pthread_enabled = *static_cast(pthread_mutex_init)*; * Shall we update or remove the comment?* Note: If we rollback the code, then 2 warnings will be generated: lib/Support/Mutex.cpp:55: warning: the address of ?int pthread_mutex_init( pthread_mutex_t*, const pthread_mutexattr_t*)? will always evaluate as ?true? lib/Support/RWMutex.cpp:57: warning: the address of ?int pthread_mutex_init( pthread_mutex_t*, const pthread_mutexattr_t*)? will always evaluate as ?true? Thanks, Logan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110213/c22b6471/attachment.html From reid.kleckner at gmail.com Sun Feb 13 01:08:45 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Sun, 13 Feb 2011 02:08:45 -0500 Subject: [LLVMdev] Regarding CMake options for LLVM In-Reply-To: References: Message-ID: On Sat, Feb 12, 2011 at 11:24 PM, nullnull wrote: > (1) I'd like to add "-std=c++0x" for some files in > lib\Transforms\Instrumentation. (I don't think it's good idea to put this > option entirely) IIRC this is actually not safe with libstdc++, because enabling C++0x changes some class definitions in ways that break ABI compatibility. In particular, I seem to remember this causing ODR violations. I don't know much about changing the CMake build. Reid From clattner at apple.com Sun Feb 13 02:24:38 2011 From: clattner at apple.com (Chris Lattner) Date: Sun, 13 Feb 2011 00:24:38 -0800 Subject: [LLVMdev] Implementing platform specific library call simplification In-Reply-To: <4D499E40.20409@xmos.com> References: <4D499E40.20409@xmos.com> Message-ID: On Feb 2, 2011, at 10:11 AM, Richard Osborne wrote: > The newlib C library provides iprintf(), a restricted version of printf > without support for floating-point formatting. I'd like to add an > optimization which turns calls to printf() into calls to iprintf() if > the format string has no floating point specifiers. Cool, ok. I can see how this would be very useful for a variety of embedded systems. > At the moment I've got this working locally by adding code to the > simplify-libcalls pass. However this will break on targets where > iprintf() isn't available. Is there a sensible place to add information > about which library functions are available for a particular target? I'd suggest adding a bool argument (HasIPrintf) to the createSimplifyLibCallsPass function and the pass constructor. Then clang (or whatever is setting up the pass manager) can query the appropriate target info to pass down this flag. Longer term, I'd like to introduce a simple interface (via TargetRegistry) for exposing target libcall info. This would be useful to eliminate the HAVE_FLOORF etc #defines in simplifylibcalls, which break cross compilation. -Chris From geek4civic at gmail.com Sun Feb 13 04:31:45 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Sun, 13 Feb 2011 19:31:45 +0900 Subject: [LLVMdev] Implementing platform specific library call simplification In-Reply-To: References: <4D499E40.20409@xmos.com> Message-ID: Chris and all, IMHO I think SimplifyLibcall and similar might be provided by rather clang (and frontends), than LLVM itself. Frontends might know better than LLVM (as backend infrastructure). ...Takumi From baldrick at free.fr Sun Feb 13 06:20:02 2011 From: baldrick at free.fr (Duncan Sands) Date: Sun, 13 Feb 2011 13:20:02 +0100 Subject: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*' In-Reply-To: References: <4D568145.1000400@free.fr> Message-ID: <4D57CC72.70501@free.fr> Hi Anton, > But there are still some details I must be missing. I'm getting an assertion > when I try the following assignment in my script: > global c = cos(1); > Assertion failed: isa(Val) && "cast() argument of incompatible type!", I think this is telling you that cos(1) is not a constant. Ciao, Duncan. From ofv at wanadoo.es Sun Feb 13 09:11:09 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Sun, 13 Feb 2011 16:11:09 +0100 Subject: [LLVMdev] Regarding CMake options for LLVM In-Reply-To: (nullnull's message of "Sat, 12 Feb 2011 23:24:29 -0500") References: Message-ID: <87zkq0m0ky.fsf@wanadoo.es> nullnull writes: > Figuring out to insert new compiling options or changing some options are > very hard for a CMake newbie. I'm working on Windows (both Visual Studio, > MingW/MSYS) via CMake. In particular, I'd like to do following two things: > > (1) I'd like to add "-std=c++0x" for some files in > lib\Transforms\Instrumentation. (I don't think it's good idea to put this > option entirely) > (2) I'd like to change intermediate directories for all libraries and tools. > (The default is ***.dir) I tried to add some CMake options, but failed. > > The aboves are easy on Visual Studio. But, chaning CMake (minimally) is hard > to do. Those are generic CMake questions, not specifically related to LLVM. The right place for asking those questions is the CMake mailing list. Anyways, the answer to your first question involves set_source_files_properties. From anton.skvorts at gmail.com Sun Feb 13 10:35:41 2011 From: anton.skvorts at gmail.com (Anton Skvorts) Date: Sun, 13 Feb 2011 16:35:41 +0000 Subject: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*' In-Reply-To: <4D57CC72.70501@free.fr> References: <4D568145.1000400@free.fr> <4D57CC72.70501@free.fr> Message-ID: Oh, I thought that after "codegening" cos(0) would get me double 1.0 (assigment is working for anything like: global a = 1/3 + 2 /3 for example) What would be the best way to make assigments involving functions, like global a = cos(0); without getting the assertion arising from InitVal = cast(Init->Codegen()); ? I made some changes and now my code basically works, except in assigments like the one above. It is a little bit frustrating because is the main thing preventing me finishing my little silly scripting language for monte carlo simulations. Value *GlobalExprAST::Codegen() { for (unsigned i = 0, e = GlobalNames.size(); i != e; ++i) { const std::string &GlobalName = GlobalNames[i].first; ExprAST *Init = GlobalNames[i].second; Constant *InitVal; InitVal = cast(Init->Codegen()); if (InitVal == 0) return 0; GlobalVariable * globval = new GlobalVariable(*TheModule, InitVal->getType(), false, llvm::GlobalValue::ExternalLinkage, InitVal, Twine(GlobalName) ); } } Thank you very much for our help Anton 2011/2/13 Duncan Sands : > Hi Anton, > >> But there are still some details I must be missing. I'm getting an assertion >> when I try the following assignment in my script: >> ? ? global c = cos(1); >> Assertion failed: isa(Val) && "cast() argument of incompatible type!", > > I think this is telling you that cos(1) is not a constant. > > 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 reid.kleckner at gmail.com Sun Feb 13 10:55:45 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Sun, 13 Feb 2011 11:55:45 -0500 Subject: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*' In-Reply-To: References: <4D568145.1000400@free.fr> <4D57CC72.70501@free.fr> Message-ID: On Sun, Feb 13, 2011 at 11:35 AM, Anton Skvorts wrote: > Oh, I thought that after "codegening" cos(0) would get me double 1.0 Your codegen method looks like it will generate code to evaluate cos(0). There's no way in LLVM to run this code at global scope, it has to be inside a function. If you want to support running arbitrary code at global scope in your language, you probably want to do something like what C++ does for static initializers, where you run code before main and fill in the values of global variables. > (assigment is working for anything like: global a = 1/3 + 2 /3 for > example) The reason 1/3 + 2/3 works is because the IRBuilder recognizes these as constants for you and folds them down to an LLVM Constant. Reid From baldrick at free.fr Sun Feb 13 11:09:56 2011 From: baldrick at free.fr (Duncan Sands) Date: Sun, 13 Feb 2011 18:09:56 +0100 Subject: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*' In-Reply-To: References: <4D568145.1000400@free.fr> <4D57CC72.70501@free.fr> Message-ID: <4D581064.9040805@free.fr> Hi Anton, > Oh, I thought that after "codegening" cos(0) would get me double 1.0 > (assigment is working for anything like: global a = 1/3 + 2 /3 for > example) What would be the best way to make assigments involving > functions, like global a = cos(0); > without getting the assertion arising from InitVal = > cast(Init->Codegen()); ? the problem is that you are performing a function call (to "cos"). A function call is simply not a constant in the sense of LLVM (even if it is a constant in the sense of mathematics): it needs to be executed to work out what the return value is, and something that needs to be executed is not a Constant. Probably you should have a constructor call "cos" and assign the return value to your global. To work out how to do this I suggest you write the C code corresponding to assigning cos(0) to a and stick it in http://llvm.org/demo to see how it is handled. Ciao, Duncan. From clattner at apple.com Sun Feb 13 12:50:14 2011 From: clattner at apple.com (Chris Lattner) Date: Sun, 13 Feb 2011 10:50:14 -0800 Subject: [LLVMdev] Implementing platform specific library call simplification In-Reply-To: References: <4D499E40.20409@xmos.com> Message-ID: <07426ECC-E2E2-4C10-ACB3-9E9CD4306125@apple.com> On Feb 13, 2011, at 2:31 AM, NAKAMURA Takumi wrote: > Chris and all, > > IMHO I think SimplifyLibcall and similar might be provided by rather > clang (and frontends), than LLVM itself. > Frontends might know better than LLVM (as backend infrastructure). SimplifyLibcall is applicable to any language that runs with libc (almost all of them), and at LTO time you can have mixed languages. I think that LLVM providing this functionality is goodness, and more generally I'd like to move it into instcombine at some point (when the appropriate "no-builtins" issues and target hooks are dealt with). -Chris From antseabra at gmail.com Sun Feb 13 13:45:54 2011 From: antseabra at gmail.com (=?ISO-8859-1?Q?Ant=F3nio_Saragga_Seabra?=) Date: Sun, 13 Feb 2011 19:45:54 +0000 Subject: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*' In-Reply-To: <4D581064.9040805@free.fr> References: <4D568145.1000400@free.fr> <4D57CC72.70501@free.fr> <4D581064.9040805@free.fr> Message-ID: Hi Duncan and Reid, Thanks for your comments and suggestions. I was puzzled because assigning to a local variable in the tutorial example works. For example: var a = cos(1) in ( 2 * a ); emits declare double @cos(double) define double @0() { entry: ret double 0x3FF14A280FB5068C } and we get the right answer 1.08060461. On Sun, Feb 13, 2011 at 5:09 PM, Duncan Sands wrote: > > Hi Anton, > > > Oh, I thought that after "codegening" cos(0) would get me double 1.0 > > (assigment is working for anything like: global a = 1/3 + 2 /3 for > > example) ? What would be the best way to make assigments involving > > functions, like ?global a = cos(0); > > without getting the assertion arising from ?InitVal = > > cast(Init->Codegen()); ? > > the problem is that you are performing a function call (to "cos"). ?A function > call is simply not a constant in the sense of LLVM (even if it is a constant in > the sense of mathematics): it needs to be executed to work out what the return > value is, and something that needs to be executed is not a Constant. > > Probably you should have a constructor call "cos" and assign the return value > to your global. ?To work out how to do this I suggest you write the C code > corresponding to assigning cos(0) to a and stick it in http://llvm.org/demo to > see how it is handled. > > 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 Arnaud.AllardDeGrandMaison at dibcom.com Sun Feb 13 15:44:52 2011 From: Arnaud.AllardDeGrandMaison at dibcom.com (Arnaud Allard de Grandmaison) Date: Sun, 13 Feb 2011 22:44:52 +0100 Subject: [LLVMdev] Hazard recognizers & basic blocks In-Reply-To: References: <57C38DA176A0A34A9B9F3CCCE33D3C4A01320BD1A701@FRPAR1CL009.coe.adi.dibcom.com>, Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4A01320BD8D261@FRPAR1CL009.coe.adi.dibcom.com> Ooops, you are right. Just forgot to CC the mailing list. Thanks for noticing it,, -- Arnaud de Grandmaison ________________________________________ From: Damien Vincent [damien.llvm at gmail.com] Sent: Saturday, February 12, 2011 3:57 AM To: Arnaud Allard de Grandmaison Subject: Re: [LLVMdev] Hazard recognizers & basic blocks Merci ! I was also planning to add a second pass to verify these special cases but wanted to make sure there is not a simpler and consistent way before proceeding. And you're right, another way is also to make sure that the final or the first instruction of a basic block are not instructions prone to structural hazards (this should not happen so often...). Btw, you didn't reply on the mailing list... is it just an omission ? Getting it on the mailing list might be helpful for the llvm community ;) Best regards, Damien On Fri, Feb 11, 2011 at 1:30 AM, Arnaud Allard de Grandmaison > wrote: Hi Damien, We also found this issue; our way of solving it was to add a pass after postRAScheduler to handle those inter MBB hazards. The postRAHazardRecognizer maintains a hazard state inside the basic block, and depending on the successor(s), the hazard are handled inside the current MBB or in the successor. But his gets really tricky when loops are involved. A simple and robust --- but not optimum --- way is to ensure that each MBB ends with no pending hazards. Best regards, -- Arnaud de Grandmaison ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Damien Vincent Sent: Thursday, February 10, 2011 7:38 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Hazard recognizers & basic blocks To be more specific, let's consider the following (imcomplete) C code (OK, this is not good C style ;) ) { ... goto label0; ... goto label1; ... label0: { // some C code for basic block starting at label0 ... } label1: { // some C code for basic block starting at label1 ... } } In the previous example, the last instruction of basic block0 (starting at label0) is not a jump. There might be a structural hazard between this instruction and the first instruction of basic block1 (starting at label1). Did you have to deal with this kind of hazards ? Thanks. On Thu, Feb 10, 2011 at 10:30 AM, Damien Vincent > wrote: I am working on a target which has some structural hazards. To detect these hazards, I implemented a sub-class of PostRAHazardRecognizer. PostRAHazardRecognizer resets the hazard state on a basic block basis. So, how to detect hazards that may occur between the end of a basic block and the beginning of another basic block ? Thanks ! ________________________________ CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you. CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you. From viridia at gmail.com Sun Feb 13 16:59:08 2011 From: viridia at gmail.com (Talin) Date: Sun, 13 Feb 2011 14:59:08 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: LLBrowse has now been checked in to the llvm.org subversion repository: http://llvm.org/svn/llvm-project/llbrowse/trunk/ There are instructions for building and running in the doc/ directory. First task if someone wants to take it on - update all of the source files to have the UIUC license info at the top, and add a LICENSE.txt file :) Other TODO items, many of which are fairly trivial: - Update the status bar when a module is loaded (currently says "no module loaded") - Add support for command-line parameters - you should be able to specify a module file on the command line and have it load it on startup. - Change the subversion property for the HTML files in the doc directory to have the proper mime type. - Add new icons for different DIE types (currently all DWARF nodes use the same icon.) Note that you need to re-run CMake after adding a new icon so it can create the dependency rules for converting the icon data to a C header file. Icons are always 20x20 and can easily be created in GIMP. - Add a "search" function that allows searching for a symbol by name. (This one's not trivial due to the lazy construction of tree nodes. Basically what it needs to do is walk the tree (avoiding cycles), and call treeCtrl->SelectItem and treeCtrl->EnsureVisible on the node whose caption contains the search string. I have some notes on how to do this.) - Make sure the app isn't leaking memory when loading a new module over an old one. In the mean time, I'll be working on getting DWARF derived type DIEs to display as much information as possible... :) On Fri, Feb 11, 2011 at 11:22 PM, Talin wrote: > I've written a little GUI application that displays an LLVM module as an > expandable tree, which can be useful for examining the module's contents. > Some features: > > - Based on wxWidgets, so it's completely cross-platform. > - CMake build script can locate both LLVM and wxWidgets installations > automatically. > - Loads either .ll or .bc files. > - Supports browsing of LLVM types, variables, functions, aliases, and > metadata. I'm working on supporting a more structured view of DWARF DIEs, > but that is not complete. > - Tree nodes are created lazily as needed. > - The tree node system is highly extensible, each different LLVM object > type is represented by a tree node class, adding new node classes is > extremely easy. > - The code is very straightforward and easy to read. > - All image resources are embedded in the final executable, so the > compiles program is just a single binary file, very easily installed. > > This is still a work in progress, but I think it's ready for people to > start hacking on. > > If there is interest, I can check the code into the llvm.org svn somewhere > - I just need to know where to put it. Otherwise, I'm happy to email a zip > archive to folks who are interested. I'm willing to release the code under > whatever license is most convenient. > > Here's a screenshot of what it looks like: > > [image: llbrowse.png] > > And here's what the node class for displaying variables looks like, as an > example: > > class VariableItem : public TreeItemBase { > public: > VariableItem(const llvm::Module* module, const llvm::GlobalVariable* var) > : module_(module), var_(var) {} > > // Overrides > > int GetIcon() const; > wxString GetCaption() const; > void CreateChildren(wxTreeCtrl* tree, const wxTreeItemId& id); > bool CanCreateChildren() const; > void ShowDetails(DetailsView* detailsView); > > private: > const llvm::Module* const module_; > const llvm::GlobalVariable* const var_; > }; > > > -- > -- Talin > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110213/27ec943c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 66648 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110213/27ec943c/attachment-0001.png From viridia at gmail.com Sun Feb 13 21:55:50 2011 From: viridia at gmail.com (Talin) Date: Sun, 13 Feb 2011 19:55:50 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: One more screen shot: The version I just checked now allows you to see all of the children of a given compile unit: [image: llbrowse3.png] I've already found at least one bug in my compiler's frontend using this tool :) Oh, and before I forget, I need three small changes to DebugInfo.h: - DebugInfoFinder's 'module' parameter should be const. - isArtificial should return a bool, not an unsigned. - DIDerivedType should have an method that allows access to the 'name' attribute of the DIE. On Sun, Feb 13, 2011 at 2:59 PM, Talin wrote: > LLBrowse has now been checked in to the llvm.org subversion repository: > > http://llvm.org/svn/llvm-project/llbrowse/trunk/ > > There are instructions for building and running in the doc/ directory. > > First task if someone > wants to take it on - update all of the source files to have the UIUC > license info at the top, and add a LICENSE.txt file :) > > Other TODO items, many of which are fairly trivial: > > - Update the status bar when a module is loaded (currently says "no > module loaded") > - Add support for command-line parameters - you should be able to > specify a module file on the command line and have it load it on startup. > - Change the subversion property for the HTML files in the doc > directory to have the proper mime type. > - Add new icons for different DIE types (currently all DWARF nodes use > the same icon.) Note that you need to re-run CMake after adding a new icon > so it can create the dependency rules for converting the icon data to a C > header file. Icons are always 20x20 and can easily be created in GIMP. > - Add a "search" function that allows searching for a symbol by name. > (This one's not trivial due to the lazy construction of tree nodes. > Basically what it needs to do is walk the tree (avoiding cycles), and call > treeCtrl->SelectItem and treeCtrl->EnsureVisible on the node whose caption > contains the search string. I have some notes on how to do this.) > - Make sure the app isn't leaking memory when loading a new module over > an old one. > > In the mean time, I'll be working on getting DWARF derived type DIEs to > display as much information as possible... :) > > On Fri, Feb 11, 2011 at 11:22 PM, Talin wrote: > >> I've written a little GUI application that displays an LLVM module as an >> expandable tree, which can be useful for examining the module's contents. >> Some features: >> >> - Based on wxWidgets, so it's completely cross-platform. >> - CMake build script can locate both LLVM and wxWidgets installations >> automatically. >> - Loads either .ll or .bc files. >> - Supports browsing of LLVM types, variables, functions, aliases, and >> metadata. I'm working on supporting a more structured view of DWARF DIEs, >> but that is not complete. >> - Tree nodes are created lazily as needed. >> - The tree node system is highly extensible, each different LLVM >> object type is represented by a tree node class, adding new node classes is >> extremely easy. >> - The code is very straightforward and easy to read. >> - All image resources are embedded in the final executable, so the >> compiles program is just a single binary file, very easily installed. >> >> This is still a work in progress, but I think it's ready for people to >> start hacking on. >> >> If there is interest, I can check the code into the llvm.org svn >> somewhere - I just need to know where to put it. Otherwise, I'm happy to >> email a zip archive to folks who are interested. I'm willing to release the >> code under whatever license is most convenient. >> >> Here's a screenshot of what it looks like: >> >> [image: llbrowse.png] >> >> And here's what the node class for displaying variables looks like, as an >> example: >> >> class VariableItem : public TreeItemBase { >> public: >> VariableItem(const llvm::Module* module, const llvm::GlobalVariable* >> var) >> : module_(module), var_(var) {} >> >> // Overrides >> >> int GetIcon() const; >> wxString GetCaption() const; >> void CreateChildren(wxTreeCtrl* tree, const wxTreeItemId& id); >> bool CanCreateChildren() const; >> void ShowDetails(DetailsView* detailsView); >> >> private: >> const llvm::Module* const module_; >> const llvm::GlobalVariable* const var_; >> }; >> >> >> -- >> -- Talin >> > > > > -- > -- Talin > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110213/ec9d4376/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 67361 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110213/ec9d4376/attachment-0001.png From baldrick at free.fr Mon Feb 14 03:11:02 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 14 Feb 2011 10:11:02 +0100 Subject: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*' In-Reply-To: References: <4D568145.1000400@free.fr> <4D57CC72.70501@free.fr> <4D581064.9040805@free.fr> Message-ID: <4D58F1A6.9020700@free.fr> Hi Ant?nio, > Thanks for your comments and suggestions. I was puzzled because > assigning to a local variable in the tutorial example works. For > example: > > var a = cos(1) in ( > 2 * a ); > > emits > > declare double @cos(double) > define double @0() { > entry: > ret double 0x3FF14A280FB5068C > } > > and we get the right answer 1.08060461. note that it did not declare a global variable "a". Probably it initialized "a" (however it was defined) with a call of "cos(1)" which the optimizers evaluated as the constant 0x3FF14A280FB5068C. Ciao, Duncan. > > > > On Sun, Feb 13, 2011 at 5:09 PM, Duncan Sands wrote: >> >> Hi Anton, >> >>> Oh, I thought that after "codegening" cos(0) would get me double 1.0 >>> (assigment is working for anything like: global a = 1/3 + 2 /3 for >>> example) What would be the best way to make assigments involving >>> functions, like global a = cos(0); >>> without getting the assertion arising from InitVal = >>> cast(Init->Codegen()); ? >> >> the problem is that you are performing a function call (to "cos"). A function >> call is simply not a constant in the sense of LLVM (even if it is a constant in >> the sense of mathematics): it needs to be executed to work out what the return >> value is, and something that needs to be executed is not a Constant. >> >> Probably you should have a constructor call "cos" and assign the return value >> to your global. To work out how to do this I suggest you write the C code >> corresponding to assigning cos(0) to a and stick it in http://llvm.org/demo to >> see how it is handled. >> >> 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 From rengolin at systemcall.org Mon Feb 14 03:17:10 2011 From: rengolin at systemcall.org (Renato Golin) Date: Mon, 14 Feb 2011 09:17:10 +0000 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: I think this deserves a blog post... --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/7ce81293/attachment.html From kalle.raiskila at nokia.com Mon Feb 14 08:17:05 2011 From: kalle.raiskila at nokia.com (Kalle Raiskila) Date: Mon, 14 Feb 2011 16:17:05 +0200 Subject: [LLVMdev] Promoting i16 load to i32 In-Reply-To: References: Message-ID: <1297693025.1837.50.camel@LLVMbuilder.research.nokia.com> Alex Bradbury wrote: > Hi, > > I'm working on an LLVM backend for an architecture which does not > natively support half-word loads. I'm having trouble getting LLVM to > promote i16 to i32 loads for me - should I expect LLVM to be able to > do this, are do I have to write a custom lowerer? I don't think LLVM does that currently. However - it would be a nice thing have. At least spu and, if I recall correctly, xcore backends have custom lowering for similar cases. kalle -- "Modern computing machines are very complex objects" -von Neumann introducing the NORC, 1954 From dpatel at apple.com Mon Feb 14 11:11:52 2011 From: dpatel at apple.com (Devang Patel) Date: Mon, 14 Feb 2011 09:11:52 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: Talin, On Feb 13, 2011, at 7:55 PM, Talin wrote: > Oh, and before I forget, I need three small changes to DebugInfo.h: > DebugInfoFinder's 'module' parameter should be const. > isArtificial should return a bool, not an unsigned. > DIDerivedType should have an method that allows access to the 'name' attribute of the DIE. DIDerivedType is derived from DIType and it has getName() method, so it would work. However, feel free to update DebugInfo.h for these needs. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/874329ba/attachment.html From dpatel at apple.com Mon Feb 14 11:12:43 2011 From: dpatel at apple.com (Devang Patel) Date: Mon, 14 Feb 2011 09:12:43 -0800 Subject: [LLVMdev] [patch] Dwarf Debug info support for COFF object files In-Reply-To: References: Message-ID: Hi Nathan, Thanks for these patches. I will review them and get back to you. - Devang On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > Hello All, > > I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything looks to be in order. > > Here is a short description of what the patches accomplish > > die.patch: > adds a new DIEValue type to represent a section relative label. (their was already a type id specified so I provided a class modeled after DIELabel) > > secrel-fixup.patch: > creats a new target specific fixup type (reloc_coff_secrel32) to represent COFF Section Relative relocations and updats the COFF object writer to write it as COFF_IMAGE_REL_AMD64_SREL32 > > secrel-streamer.patch > adds a new directive in the MCStreamer interface to allow the AsmPrinter to emit a section relative label and provides implementations for all existings Streamer (all but WinCOFF either forward or error on it) > > secrel-dwarf.patch > updates dwarf printing code to make use of the new directive & DIE value where appropriate (this is where the bug fix is) > > coff-debug.patch > turns the dwarf output on in the X86/COFF AsmInfo classes > > - Nathan > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From baldrick at free.fr Mon Feb 14 11:39:49 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 14 Feb 2011 18:39:49 +0100 Subject: [LLVMdev] Promoting i16 load to i32 In-Reply-To: References: Message-ID: <4D5968E5.8010705@free.fr> Hi Alex, > I'm working on an LLVM backend for an architecture which does not > natively support half-word loads. I'm having trouble getting LLVM to > promote i16 to i32 loads for me - should I expect LLVM to be able to > do this, are do I have to write a custom lowerer? it should do this if i16 is not a legal type but i32 is. Ciao, Duncan. From hkultala at iki.fi Mon Feb 14 12:10:35 2011 From: hkultala at iki.fi (Heikki Kultala) Date: Mon, 14 Feb 2011 20:10:35 +0200 Subject: [LLVMdev] broken alignment in stack(caused by bug in SelectionDAGBuilder) causes invalid schedules with r125471 and newer Message-ID: <3C654B56-35E4-4765-967B-B407098FE826@iki.fi> The following problems happens with architectures, where stack alignment is smaller than the biggest preferred alignment for any data type SP pointer may point anywhere with alignment of stack alignment (4 in our case) SelectionDAGBuilder however calls CreateStackObject with preferred alignment is given data type(8 in our problemaric case. The ABI alignment for this data type is only 4) This means, that the MachineFrameInfo thinks that the stack object is aligned by 8 bytes, even though in reality if may also be aligned only by 4 bytes, of the SP points to address which is aligned by 4, but not 8. r125471 introduced optimization which can optimize add into xor in case object is aligned so that the operation only touches the lowest bits, which were zero on the aligned pointer. But when the MachineFrameInfo contains invalid align information, this optimization breaks and it incorrectly optimizes add by 4 into xor by 4, when the object is (in reality) aligned by 4, not by 8(which MFI thinks about it's alignment) Two solutions come into my mind: 1) changiing the SelectionDAGBuilder to use std::min(StackAlignment, PreferredAlignment) instead of PreferredAlignment. This might require asserting (StackAlignment <= ABI alignment). 2) changing the SelectionAGBuilder to use ABI alignment instead of the preferred alignment for the stack objects. The affected code lines are around 4820, and 5694 of SelectionDAGBuilder.cpp From viridia at gmail.com Mon Feb 14 12:39:20 2011 From: viridia at gmail.com (Talin) Date: Mon, 14 Feb 2011 10:39:20 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin wrote: > I think this deserves a blog post... > > I'd like to wait until I get some feedback - I don't know yet if anyone is having trouble building or running the thing... > --renato > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/d9962099/attachment.html From hkultala at cs.tut.fi Mon Feb 14 12:43:50 2011 From: hkultala at cs.tut.fi (Heikki Kultala) Date: Mon, 14 Feb 2011 20:43:50 +0200 Subject: [LLVMdev] broken alignment in stack(caused by bug in SelectionDAGBuilder) causes invalid schedules with r125471 and newer In-Reply-To: <3C654B56-35E4-4765-967B-B407098FE826@iki.fi> References: <3C654B56-35E4-4765-967B-B407098FE826@iki.fi> Message-ID: <7D216BCE-BAAE-4D7E-B8B2-2791C5982FD7@cs.tut.fi> On 14 Feb 2011, at 20:10, Heikki Kultala wrote: > The following problems happens with architectures, where stack alignment is smaller than the biggest preferred alignment for any data type > > > SP pointer may point anywhere with alignment of stack alignment (4 in our case) > > SelectionDAGBuilder however calls CreateStackObject with preferred alignment is given data type(8 in our problemaric case. The ABI alignment for this data type is only 4) > > This means, that the MachineFrameInfo thinks that the stack object is aligned by 8 bytes, even though in reality if may also be aligned only by 4 bytes, of the SP points to address which is aligned by 4, but not 8. > > > r125471 introduced optimization which can optimize add into xor in case object is aligned so that the operation only touches the lowest bits, which were zero on the aligned pointer. > > But when the MachineFrameInfo contains invalid align information, this optimization breaks and it incorrectly optimizes add by 4 into xor by 4, when the object is (in reality) aligned by 4, not by 8(which MFI thinks about it's alignment) > > > > Two solutions come into my mind: > > 1) changiing the SelectionDAGBuilder to use std::min(StackAlignment, PreferredAlignment) instead of PreferredAlignment. This might require asserting (StackAlignment <= ABI alignment). > > 2) changing the SelectionAGBuilder to use ABI alignment instead of the preferred alignment for the stack objects. > > > The affected code lines are around 4820, and 5694 of SelectionDAGBuilder.cpp Hmm, it seems that CreateStackObject is called also in many other places with preferred alignment. So maybe it would be better to instead change the part which checks the alignment (InferPtrAlignment?) , so that for objects in stack , the alignment would be correctly calculated taking the stack alignment into consideration From edwintorok at gmail.com Mon Feb 14 12:58:16 2011 From: edwintorok at gmail.com (=?windows-1252?Q?T=F6r=F6k_Edwin?=) Date: Mon, 14 Feb 2011 20:58:16 +0200 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: <4D597B48.3030205@gmail.com> On 2011-02-14 20:39, Talin wrote: > > > On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin > wrote: > > I think this deserves a blog post... > > I'd like to wait until I get some feedback - I don't know yet if anyone > is having trouble building or running the thing... Hi Talin, What version of wxwidgets does llbrowse require, tried 2.8.10, and 2.9.1 and none worked: /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: ISO C++ forbids declaration of ?wxImageList? with no type /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: expected ?;? before ?*? token /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: ISO C++ forbids declaration of ?wxImageList? with no type /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: expected ?;? before ?*? token Some other minor issues: 1. If llvm-config is not in the path, 'cmake .' succeeds, and 'make fails'. cmake-gui shows that the problem is LLVM_CONFIG_EXECUTABLE-NOTFOUND. 2. It doesn't seem to build with LLVM 2.8, maybe you should check the LLVM version in CMake: /home/edwin/llbrowse/lib/BrowserApp.cpp:9:34: error: llvm/Support /Signals.h: No such file or directory Best regards, --Edwin From edwintorok at gmail.com Mon Feb 14 13:02:30 2011 From: edwintorok at gmail.com (=?windows-1252?Q?T=F6r=F6k_Edwin?=) Date: Mon, 14 Feb 2011 21:02:30 +0200 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: <4D597B48.3030205@gmail.com> References: <4D597B48.3030205@gmail.com> Message-ID: <4D597C46.2070507@gmail.com> On 2011-02-14 20:58, T?r?k Edwin wrote: > On 2011-02-14 20:39, Talin wrote: >> >> >> On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin > > wrote: >> >> I think this deserves a blog post... >> >> I'd like to wait until I get some feedback - I don't know yet if anyone >> is having trouble building or running the thing... > > Hi Talin, > > What version of wxwidgets does llbrowse require, tried 2.8.10, and 2.9.1 > and none worked: > /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: ISO C++ > forbids declaration of ?wxImageList? with no type > /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: expected > ?;? before ?*? token > /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: ISO C++ > forbids declaration of ?wxImageList? with no type > /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: expected > ?;? before ?*? token Correction, 2.8.10 gets past these errors, and shows these errors instead: CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o:(.rodata._ZTV10BrowserApp[vtable for BrowserApp]+0x120): undefined reference to `wxApp::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*)' CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o:(.rodata._ZTV10BrowserApp[vtable for BrowserApp]+0x128): undefined reference to `wxAppConsole::OnAssert(wchar_t const*, int, wchar_t const*, wchar_t const*)' CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o: In function `wxStringBase::wxStringBase(wxStringBase const&)': TreeView.cpp:(.text._ZN12wxStringBaseC2ERKS_[wxStringBase::wxStringBase(wxStringBase const&)]+0x43): undefined reference to `wxOnAssert(wchar_t const*, int, char const*, wchar_t const*, wchar_t const*)' CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o: In function `wxArrayString::Item(unsigned long) const': TreeView.cpp:(.text._ZNK13wxArrayString4ItemEm[wxArrayString::Item(unsigned long) const]+0x39): undefined reference to `wxOnAssert(wchar_t const*, int, char const*, wchar_t const*, wchar_t const*)' > > Some other minor issues: > 1. If llvm-config is not in the path, 'cmake .' succeeds, and 'make fails'. > cmake-gui shows that the problem is LLVM_CONFIG_EXECUTABLE-NOTFOUND. > > 2. It doesn't seem to build with LLVM 2.8, maybe you should check the > LLVM version in CMake: > /home/edwin/llbrowse/lib/BrowserApp.cpp:9:34: error: llvm/Support > /Signals.h: No such file or directory > > Best regards, > --Edwin From clattner at apple.com Mon Feb 14 13:04:44 2011 From: clattner at apple.com (Chris Lattner) Date: Mon, 14 Feb 2011 11:04:44 -0800 Subject: [LLVMdev] Stricter adherence to coding standards in LLVM? In-Reply-To: References: Message-ID: On Feb 11, 2011, at 4:17 PM, Talin wrote: > I notice that there's a lot of code in LLVM core libraries that is wildly inconsistent in formatting. Two particular things come to mind: > > -- Capitalization of method names. The LLVM guidelines say one thing, but a lot of recent code (such as IRBuilder) consistently does the opposite of what the guidelines say. One has to wonder which source of truth is more authoritative - after all, the docs could always be out of date. IRBuilder is recent, but the naming conventions are even more so. > -- Whitespace around * and & in variable declarations. I see some files that consistently put the space after, some files put it before, while some files use one convention for parameters, and a different convention for member variables and local variables. Within a single file, the usage is pretty consistent, so you know that the people who wrote the code were really trying to adhere to a standard. Yes, this is annoying. > Now, common wisdom for open source projects is that inconsistent legacy formatting is left alone, and new code adheres to whatever style is used in nearby code. ... > nip any inconsistencies in the bud as early and aggressively as possible .. > There is also the problem of backwards compatibility with existing users of the code. I'm not worried about API stability, this is something we don't guarantee. The approach I'd like to see is gentle, gradual migration. As new code is written, it should follow the standards, as existing code is modified, it should be updated to match the standards. This is what I do when working on the codebase, and would appreciate it if others would as well. It's best to not conflate coding standards changes in with other semantic changes though. Eventually, it would be great for someone to make a clang mode to enforce the standards for the project. If we had that, we could do a post-commit hook or something. -Chris From viridia at gmail.com Mon Feb 14 13:18:15 2011 From: viridia at gmail.com (Talin) Date: Mon, 14 Feb 2011 11:18:15 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: <4D597C46.2070507@gmail.com> References: <4D597B48.3030205@gmail.com> <4D597C46.2070507@gmail.com> Message-ID: Thanks for letting me know. I'll look into it right now. 2011/2/14 T?r?k Edwin > On 2011-02-14 20:58, T?r?k Edwin wrote: > > On 2011-02-14 20:39, Talin wrote: > >> > >> > >> On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin >> > wrote: > >> > >> I think this deserves a blog post... > >> > >> I'd like to wait until I get some feedback - I don't know yet if anyone > >> is having trouble building or running the thing... > > > > Hi Talin, > > > > What version of wxwidgets does llbrowse require, tried 2.8.10, and 2.9.1 > > and none worked: > > /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: ISO C++ > > forbids declaration of ?wxImageList? with no type > > /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: expected > > ?;? before ?*? token > > /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: ISO C++ > > forbids declaration of ?wxImageList? with no type > > /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: expected > > ?;? before ?*? token > > Correction, 2.8.10 gets past these errors, and shows these errors instead: > > CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o:(.rodata._ZTV10BrowserApp[vtable > for BrowserApp]+0x120): undefined reference to > `wxApp::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t > const*, wchar_t const*)' > > CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o:(.rodata._ZTV10BrowserApp[vtable > for BrowserApp]+0x128): undefined reference to > `wxAppConsole::OnAssert(wchar_t const*, int, wchar_t const*, wchar_t > const*)' > CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o: In function > `wxStringBase::wxStringBase(wxStringBase const&)': > > TreeView.cpp:(.text._ZN12wxStringBaseC2ERKS_[wxStringBase::wxStringBase(wxStringBase > const&)]+0x43): undefined reference to `wxOnAssert(wchar_t const*, int, > char const*, wchar_t const*, wchar_t const*)' > CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o: In function > `wxArrayString::Item(unsigned long) const': > TreeView.cpp:(.text._ZNK13wxArrayString4ItemEm[wxArrayString::Item(unsigned > long) const]+0x39): undefined reference to `wxOnAssert(wchar_t const*, > int, char const*, wchar_t const*, wchar_t const*)' > > > > > > Some other minor issues: > > 1. If llvm-config is not in the path, 'cmake .' succeeds, and 'make > fails'. > > cmake-gui shows that the problem is LLVM_CONFIG_EXECUTABLE-NOTFOUND. > > > > 2. It doesn't seem to build with LLVM 2.8, maybe you should check the > > LLVM version in CMake: > > /home/edwin/llbrowse/lib/BrowserApp.cpp:9:34: error: llvm/Support > > /Signals.h: No such file or directory > > > > Best regards, > > --Edwin > > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/a4c7c2c7/attachment.html From atomicdog.jwm at gmail.com Mon Feb 14 14:01:32 2011 From: atomicdog.jwm at gmail.com (John Myers) Date: Mon, 14 Feb 2011 12:01:32 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: On Mon, Feb 14, 2011 at 10:39 AM, Talin wrote > > >> I'd like to wait until I get some feedback - I don't know yet if anyone is > having trouble building or running the thing... > Hi Talin, This is the build error I get on my ubuntu 64 bit system... john at ubuntu:~/src/build-llbrowse$ make [ 5%] Building CXX object CMakeFiles/llbrowse.dir/lib/Formatting.cpp.o /home/john/src/llbrowse/lib/Formatting.cpp: In function ?void printTypeExpansion(wxTextOutputStream&, const llvm::Module*, const llvm::Type*, uint32_t)?: /home/john/src/llbrowse/lib/Formatting.cpp:33: error: ?X86_MMXTyID? is not a member of ?llvm::Type? make[2]: *** [CMakeFiles/llbrowse.dir/lib/Formatting.cpp.o] Error 1 make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 make: *** [all] Error 2 john at ubuntu:~/src/build-llbrowse$ llvm-config --version 2.9svn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/27a75689/attachment.html From peterl95124 at sbcglobal.net Mon Feb 14 14:49:23 2011 From: peterl95124 at sbcglobal.net (Peter Lawrence) Date: Mon, 14 Feb 2011 12:49:23 -0800 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: References: Message-ID: Andrew, your response highlights a naming problem in LLVM, which is that "array" and "vector" mean the same thing in normal computer language and compiler theory usage, so it is inconvenient and misleading within LLVM to give one a very specific meaning that is different from the other.... to the LLVM developers I would suggest using the term "packed" to refer to the type of data that the SPARC-VIS, the PPC-Altivec, and the Intel-mmx/sse (among others) instruction sets support. As far as I am aware not a single one of any of the above types of instruction sets allows the "subscripting" of packed data within a register (the Maspar computer had hardware that would allow subscripting of sub-elements of data within a larger/wider register, but it was the exception, not the rule, and it did not support any of the saturating arithmetic that is part-and-parcel of the packed data types in the currently existing "multi-media instruction sets"). sincerely, Peter Lawrence. > > Could you use an array of pointers instead? As far as I'm aware, the > vector types in LLVM are intended to abstract the vector units on > modern > CPUs (SSE, etc.) which generally support operations on only > integers and > floating point values, which may be why there isn't native support for > vectors of pointers. > > Andrew From viridia at gmail.com Mon Feb 14 15:11:08 2011 From: viridia at gmail.com (Talin) Date: Mon, 14 Feb 2011 13:11:08 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: <4D597C46.2070507@gmail.com> References: <4D597B48.3030205@gmail.com> <4D597C46.2070507@gmail.com> Message-ID: OK I figured out what the problem was - I assume you are trying to compile under Snow Leopard? There is a problem with linking against wxWidgets because the prebuilt binaries for wxWidgets are compiled in 32-bit mode, and the default compilation mode in Snow Leopard is 64 bits. See this article for an explanation: http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard Unfortunately, I am not certain what the right solution is yet. Maybe I'll have to add a check for Snow Leopard and add a flag to compile in 32-bit mode. Apparently this problem is solved in the upcoming 2.9 release of wxWidgets, but that is still an experimental version. In the mean time, I discovered a bunch of other build problems on OS X, which I have gone ahead and checked in fixes for (Things like vs. . I've also updated the docs to explain how to tell CMake where to find llvm-config. 2011/2/14 T?r?k Edwin > On 2011-02-14 20:58, T?r?k Edwin wrote: > > On 2011-02-14 20:39, Talin wrote: > >> > >> > >> On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin >> > wrote: > >> > >> I think this deserves a blog post... > >> > >> I'd like to wait until I get some feedback - I don't know yet if anyone > >> is having trouble building or running the thing... > > > > Hi Talin, > > > > What version of wxwidgets does llbrowse require, tried 2.8.10, and 2.9.1 > > and none worked: > > /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: ISO C++ > > forbids declaration of ?wxImageList? with no type > > /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: expected > > ?;? before ?*? token > > /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: ISO C++ > > forbids declaration of ?wxImageList? with no type > > /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: expected > > ?;? before ?*? token > > Correction, 2.8.10 gets past these errors, and shows these errors instead: > > CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o:(.rodata._ZTV10BrowserApp[vtable > for BrowserApp]+0x120): undefined reference to > `wxApp::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t > const*, wchar_t const*)' > > CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o:(.rodata._ZTV10BrowserApp[vtable > for BrowserApp]+0x128): undefined reference to > `wxAppConsole::OnAssert(wchar_t const*, int, wchar_t const*, wchar_t > const*)' > CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o: In function > `wxStringBase::wxStringBase(wxStringBase const&)': > > TreeView.cpp:(.text._ZN12wxStringBaseC2ERKS_[wxStringBase::wxStringBase(wxStringBase > const&)]+0x43): undefined reference to `wxOnAssert(wchar_t const*, int, > char const*, wchar_t const*, wchar_t const*)' > CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o: In function > `wxArrayString::Item(unsigned long) const': > TreeView.cpp:(.text._ZNK13wxArrayString4ItemEm[wxArrayString::Item(unsigned > long) const]+0x39): undefined reference to `wxOnAssert(wchar_t const*, > int, char const*, wchar_t const*, wchar_t const*)' > > > > > > Some other minor issues: > > 1. If llvm-config is not in the path, 'cmake .' succeeds, and 'make > fails'. > > cmake-gui shows that the problem is LLVM_CONFIG_EXECUTABLE-NOTFOUND. > > > > 2. It doesn't seem to build with LLVM 2.8, maybe you should check the > > LLVM version in CMake: > > /home/edwin/llbrowse/lib/BrowserApp.cpp:9:34: error: llvm/Support > > /Signals.h: No such file or directory > > > > Best regards, > > --Edwin > > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/249561ab/attachment.html From viridia at gmail.com Mon Feb 14 15:11:57 2011 From: viridia at gmail.com (Talin) Date: Mon, 14 Feb 2011 13:11:57 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: Message-ID: On Mon, Feb 14, 2011 at 12:01 PM, John Myers wrote: > > > On Mon, Feb 14, 2011 at 10:39 AM, Talin wrote > >> >>> I'd like to wait until I get some feedback - I don't know yet if anyone >> is having trouble building or running the thing... >> > > Hi Talin, > > This is the build error I get on my ubuntu 64 bit system... > > john at ubuntu:~/src/build-llbrowse$ make > [ 5%] Building CXX object CMakeFiles/llbrowse.dir/lib/Formatting.cpp.o > /home/john/src/llbrowse/lib/Formatting.cpp: In function ?void > printTypeExpansion(wxTextOutputStream&, const llvm::Module*, const > llvm::Type*, uint32_t)?: > /home/john/src/llbrowse/lib/Formatting.cpp:33: error: ?X86_MMXTyID? is not > a member of ?llvm::Type? > make[2]: *** [CMakeFiles/llbrowse.dir/lib/Formatting.cpp.o] Error 1 > make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 > make: *** [all] Error 2 > john at ubuntu:~/src/build-llbrowse$ llvm-config --version > 2.9svn > > Looks like I'll need to add a compile-time check to see if that symbol is available. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/11e011ff/attachment.html From viridia at gmail.com Mon Feb 14 15:13:05 2011 From: viridia at gmail.com (Talin) Date: Mon, 14 Feb 2011 13:13:05 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: <4D597B48.3030205@gmail.com> <4D597C46.2070507@gmail.com> Message-ID: Oh, and I updated the MIME types on the docs, so now you can read them online here: http://llvm.org/svn/llvm-project/llbrowse/trunk/doc/LLBrowse.html 2011/2/14 Talin > OK I figured out what the problem was - I assume you are trying to compile > under Snow Leopard? There is a problem with linking against wxWidgets > because the prebuilt binaries for wxWidgets are compiled in 32-bit mode, and > the default compilation mode in Snow Leopard is 64 bits. See this article > for an explanation: > > > http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard > > Unfortunately, I am not certain what the right solution is yet. Maybe I'll > have to add a check for Snow Leopard and add a flag to compile in 32-bit > mode. Apparently this problem is solved in the upcoming 2.9 release of > wxWidgets, but that is still an experimental version. > > In the mean time, I discovered a bunch of other build problems on OS X, > which I have gone ahead and checked in fixes for (Things like vs. > . I've also updated the docs to explain how to tell CMake where to > find llvm-config. > > 2011/2/14 T?r?k Edwin > >> On 2011-02-14 20:58, T?r?k Edwin wrote: >> >> > On 2011-02-14 20:39, Talin wrote: >> >> >> >> >> >> On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin > >> > wrote: >> >> >> >> I think this deserves a blog post... >> >> >> >> I'd like to wait until I get some feedback - I don't know yet if anyone >> >> is having trouble building or running the thing... >> > >> > Hi Talin, >> > >> > What version of wxwidgets does llbrowse require, tried 2.8.10, and 2.9.1 >> > and none worked: >> > /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: ISO C++ >> > forbids declaration of ?wxImageList? with no type >> > /home/edwin/llbrowse/include/llbrowse/Resources.h:46: error: expected >> > ?;? before ?*? token >> > /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: ISO C++ >> > forbids declaration of ?wxImageList? with no type >> > /home/edwin/llbrowse/include/llbrowse/Resources.h:47: error: expected >> > ?;? before ?*? token >> >> Correction, 2.8.10 gets past these errors, and shows these errors instead: >> >> CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o:(.rodata._ZTV10BrowserApp[vtable >> for BrowserApp]+0x120): undefined reference to >> `wxApp::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t >> const*, wchar_t const*)' >> >> CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o:(.rodata._ZTV10BrowserApp[vtable >> for BrowserApp]+0x128): undefined reference to >> `wxAppConsole::OnAssert(wchar_t const*, int, wchar_t const*, wchar_t >> const*)' >> CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o: In function >> `wxStringBase::wxStringBase(wxStringBase const&)': >> >> TreeView.cpp:(.text._ZN12wxStringBaseC2ERKS_[wxStringBase::wxStringBase(wxStringBase >> const&)]+0x43): undefined reference to `wxOnAssert(wchar_t const*, int, >> char const*, wchar_t const*, wchar_t const*)' >> CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o: In function >> `wxArrayString::Item(unsigned long) const': >> >> TreeView.cpp:(.text._ZNK13wxArrayString4ItemEm[wxArrayString::Item(unsigned >> long) const]+0x39): undefined reference to `wxOnAssert(wchar_t const*, >> int, char const*, wchar_t const*, wchar_t const*)' >> >> >> > >> > Some other minor issues: >> > 1. If llvm-config is not in the path, 'cmake .' succeeds, and 'make >> fails'. >> > cmake-gui shows that the problem is LLVM_CONFIG_EXECUTABLE-NOTFOUND. >> > >> > 2. It doesn't seem to build with LLVM 2.8, maybe you should check the >> > LLVM version in CMake: >> > /home/edwin/llbrowse/lib/BrowserApp.cpp:9:34: error: llvm/Support >> > /Signals.h: No such file or directory >> > >> > Best regards, >> > --Edwin >> >> > > > -- > -- Talin > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/cc991068/attachment.html From binalpatel4 at gmail.com Mon Feb 14 15:09:11 2011 From: binalpatel4 at gmail.com (Binal Patel) Date: Mon, 14 Feb 2011 13:09:11 -0800 Subject: [LLVMdev] Error while building llvm-gcc-4.2 Message-ID: *System:* Snow leopard 64bit *Problem: * Trying to build llvm-gcc, and I am getting an error shown below. *Here are the steps that i did:* $ mkdir llvm $ cd llvm llvm$ svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk llvm-src llvm$ cd llvm-src/trunk/ trunk$ svn update trunk$ ./configure --prefix=$PWD/../install trunk$ make ENABLE_OPTIMIZED=1 *Error*: llvm-gcc cannot be built in the source directory. Please follow the instructions in the README.LLVM file. make: *** [all] Error 1 *Please help:* What does this error mean? and how do i take care of it? (And README.LLVM is not that great of a help) Any help is greatly appreciated!! Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/e305bb27/attachment.html From andrew at sidefx.com Mon Feb 14 15:14:19 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Mon, 14 Feb 2011 16:14:19 -0500 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: References: Message-ID: <4D599B2B.101@sidefx.com> Agreed, I too was wondering why we need both arrays and vectors. It goes against the grain, I think, of the structure typing system used by LLVM. For example, a vector of 4 floats and an array of 4 floats are structurally the same type. Would it be feasible in the future to consolidate the two types by allowing "vector" operations (add, multiply, etc.) on arrays where it makes sense, and doing away with the specialized vector types? Andrew On 02/14/2011 03:49 PM, Peter Lawrence wrote: > Andrew, > your response highlights a naming problem in LLVM, > which is that "array" and "vector" > mean the same thing in normal computer language and compiler theory > usage, so it is > inconvenient and misleading within LLVM to give one a very specific > meaning that is different > from the other.... > > to the LLVM developers I would suggest using the term "packed" to > refer to the type of > data that the SPARC-VIS, the PPC-Altivec, and the Intel-mmx/sse > (among others) instruction > sets support. > > As far as I am aware not a single one of any of the above types of > instruction sets allows the "subscripting" of packed data within a > register (the Maspar > computer had hardware that would allow subscripting of sub-elements > of data within > a larger/wider register, but it was the exception, not the rule, and > it did not support > any of the saturating arithmetic that is part-and-parcel of the > packed data types in > the currently existing "multi-media instruction sets"). > > > sincerely, > Peter Lawrence. > From reid.kleckner at gmail.com Mon Feb 14 15:27:22 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Mon, 14 Feb 2011 16:27:22 -0500 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: References: Message-ID: On Mon, Feb 14, 2011 at 3:49 PM, Peter Lawrence wrote: > Andrew, > ? ? ? ? ? ? ? ?your response highlights a naming problem in LLVM, > which is that ?"array" and "vector" > mean the same thing in normal computer language and compiler theory > usage, so it is > inconvenient and misleading within LLVM to give one a very specific > meaning that is different > from the other.... The only place in CS I know of that "vector" is used to mean arbitrarily long sequence of elements is the C++ STL vector template class. So far as I know in the field of compilers "vectorization" always refers to lowering code down to use SIMD operations. > to the LLVM developers I would suggest using the term "packed" to > refer to the type of > data that the SPARC-VIS, the PPC-Altivec, and the Intel-mmx/sse > (among others) instruction > sets support. "packed" is already used to refer to "packed structs", ie structs without any padding. Reid From edwintorok at gmail.com Mon Feb 14 15:33:02 2011 From: edwintorok at gmail.com (=?windows-1252?Q?T=F6r=F6k_Edwin?=) Date: Mon, 14 Feb 2011 23:33:02 +0200 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: <4D597B48.3030205@gmail.com> <4D597C46.2070507@gmail.com> Message-ID: <4D599F8E.30302@gmail.com> On 2011-02-14 23:11, Talin wrote: > OK I figured out what the problem was - I assume you are trying to > compile under Snow Leopard? No, I should've mentioned it: this is Debian unstable x86_64, and wxwidgets is definetely 64-bit. Maybe its just something messed up on my system (had 2.9.1 in /usr/local/). Willtry removing that and reinstalling 2.8. --Edwin From viridia at gmail.com Mon Feb 14 15:36:54 2011 From: viridia at gmail.com (Talin) Date: Mon, 14 Feb 2011 13:36:54 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: <4D599F8E.30302@gmail.com> References: <4D597B48.3030205@gmail.com> <4D597C46.2070507@gmail.com> <4D599F8E.30302@gmail.com> Message-ID: If that doesn't work, try changing the order of 'base' and 'core' in the FindwxWidgets CMake rule. Sometimes the order matters. 2011/2/14 T?r?k Edwin > On 2011-02-14 23:11, Talin wrote: > > OK I figured out what the problem was - I assume you are trying to > > compile under Snow Leopard? > > No, I should've mentioned it: this is Debian unstable x86_64, and > wxwidgets is definetely 64-bit. > Maybe its just something messed up on my system (had 2.9.1 in > /usr/local/). Willtry removing that and reinstalling 2.8. > > --Edwin > > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/0001d045/attachment.html From edwintorok at gmail.com Mon Feb 14 15:44:35 2011 From: edwintorok at gmail.com (=?windows-1252?Q?T=F6r=F6k_Edwin?=) Date: Mon, 14 Feb 2011 23:44:35 +0200 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: <4D599F8E.30302@gmail.com> References: <4D597B48.3030205@gmail.com> <4D597C46.2070507@gmail.com> <4D599F8E.30302@gmail.com> Message-ID: <4D59A243.7050508@gmail.com> On 2011-02-14 23:33, T?r?k Edwin wrote: > On 2011-02-14 23:11, Talin wrote: >> OK I figured out what the problem was - I assume you are trying to >> compile under Snow Leopard? > > No, I should've mentioned it: this is Debian unstable x86_64, and > wxwidgets is definetely 64-bit. > Maybe its just something messed up on my system (had 2.9.1 in > /usr/local/). Willtry removing that and reinstalling 2.8. OK, I figured, I have to set CMAKE_BUILD_TYPE to Release and then everything works. With an empty CMAKE_BUILD_TYPE it doesn't work, maybe because LLVM defines _DEBUG and that confuses wxwidgets into a debug mode, and fails because wxwidgets is really built in release mode? Don't know... Best regards, --Edwin From edwintorok at gmail.com Mon Feb 14 15:56:12 2011 From: edwintorok at gmail.com (=?windows-1252?Q?T=F6r=F6k_Edwin?=) Date: Mon, 14 Feb 2011 23:56:12 +0200 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: <4D59A243.7050508@gmail.com> References: <4D597B48.3030205@gmail.com> <4D597C46.2070507@gmail.com> <4D599F8E.30302@gmail.com> <4D59A243.7050508@gmail.com> Message-ID: <4D59A4FC.1060108@gmail.com> On 2011-02-14 23:44, T?r?k Edwin wrote: > On 2011-02-14 23:33, T?r?k Edwin wrote: >> On 2011-02-14 23:11, Talin wrote: >>> OK I figured out what the problem was - I assume you are trying to >>> compile under Snow Leopard? >> >> No, I should've mentioned it: this is Debian unstable x86_64, and >> wxwidgets is definetely 64-bit. >> Maybe its just something messed up on my system (had 2.9.1 in >> /usr/local/). Willtry removing that and reinstalling 2.8. > > OK, I figured, I have to set CMAKE_BUILD_TYPE to Release and then > everything works. And Debug mode works, if I install the -dbg package and set wxwidget's USE_DEBUG in the cmake-gui. Without the -dbg package installed it keeps resetting to off (the USE_DEBUG variable). > With an empty CMAKE_BUILD_TYPE it doesn't work, maybe because LLVM > defines _DEBUG and that confuses wxwidgets into a debug mode, and fails > because wxwidgets is really built in release mode? > Don't know... > > Best regards, > --Edwin > From anton at korobeynikov.info Mon Feb 14 16:07:36 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 15 Feb 2011 01:07:36 +0300 Subject: [LLVMdev] Error while building llvm-gcc-4.2 In-Reply-To: References: Message-ID: Hello > What does this error mean? and how do i take care of it? > (And?README.LLVM is not that great of a help) Have you read it? Especially the section "Configure, Build, Install, Test"? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From peterl95124 at sbcglobal.net Mon Feb 14 16:29:50 2011 From: peterl95124 at sbcglobal.net (Peter Lawrence) Date: Mon, 14 Feb 2011 14:29:50 -0800 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: References: Message-ID: <60521344-AEBE-4E88-ADA4-CBAB398CE1B0@sbcglobal.net> Reid, although K&R's "The C Programming Language" does not use the term vector, note that Stroustrup's "The C++ Programming Language" does (way before STL was ever envisioned) ! Metcalf's "Effective Fortran-77" does not use the term vector, except that it is frequently used as the "name" for an array in array usage examples, but then in "Effective Fortran-90", when an array is used as an index into an array it is referred to as a "vector-valued-subscript", not an "array-valued-subscript" ! Guy Steel's "Common Lisp" quote: "one-dimensional arrays are called _vectors_ in Common Lisp...". the equivalent and interchangable usage of "array" and "vector" goes back to the beginning of computing.... when multiple items are placed within a single word of computer memory or a single register, it is "packed" data, regardless of whether that it is of uniform type and size (array/vector-like) or of different type and size (struct/record-like). best, -Peter Lawrence. On Feb 14, 2011, at 1:27 PM, Reid Kleckner wrote: > On Mon, Feb 14, 2011 at 3:49 PM, Peter Lawrence > wrote: >> Andrew, >> your response highlights a naming problem in LLVM, >> which is that "array" and "vector" >> mean the same thing in normal computer language and compiler theory >> usage, so it is >> inconvenient and misleading within LLVM to give one a very specific >> meaning that is different >> from the other.... > > The only place in CS I know of that "vector" is used to mean > arbitrarily long sequence of elements is the C++ STL vector template > class. So far as I know in the field of compilers "vectorization" > always refers to lowering code down to use SIMD operations. > >> to the LLVM developers I would suggest using the term "packed" to >> refer to the type of >> data that the SPARC-VIS, the PPC-Altivec, and the Intel-mmx/sse >> (among others) instruction >> sets support. > > "packed" is already used to refer to "packed structs", ie structs > without any padding. > > Reid From Micah.Villmow at amd.com Mon Feb 14 17:44:14 2011 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Mon, 14 Feb 2011 17:44:14 -0600 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: <4D599B2B.101@sidefx.com> References: <4D599B2B.101@sidefx.com> Message-ID: Andrew, This is one area of LLVM that maps very nicely to our GPU architecture. A vector is a native data type on these architectures. For example, on AMD's GPUs, the native type is 4x32bit vector with sub-components. Each of the individual 32bits can be indexed separately, but not dynamically. This is a big difference from an array of 32bit values. So there are cases where the meaning of the two are different on modern hardware. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Andrew Clinton > Sent: Monday, February 14, 2011 1:14 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 > > Agreed, I too was wondering why we need both arrays and vectors. It > goes against the grain, I think, of the structure typing system used by > LLVM. For example, a vector of 4 floats and an array of 4 floats are > structurally the same type. Would it be feasible in the future to > consolidate the two types by allowing "vector" operations (add, > multiply, etc.) on arrays where it makes sense, and doing away with the > specialized vector types? > > Andrew > > On 02/14/2011 03:49 PM, Peter Lawrence wrote: > > Andrew, > > your response highlights a naming problem in LLVM, > > which is that "array" and "vector" > > mean the same thing in normal computer language and compiler theory > > usage, so it is > > inconvenient and misleading within LLVM to give one a very specific > > meaning that is different > > from the other.... > > > > to the LLVM developers I would suggest using the term "packed" to > > refer to the type of > > data that the SPARC-VIS, the PPC-Altivec, and the Intel-mmx/sse > > (among others) instruction > > sets support. > > > > As far as I am aware not a single one of any of the above types of > > instruction sets allows the "subscripting" of packed data within a > > register (the Maspar > > computer had hardware that would allow subscripting of sub-elements > > of data within > > a larger/wider register, but it was the exception, not the rule, and > > it did not support > > any of the saturating arithmetic that is part-and-parcel of the > > packed data types in > > the currently existing "multi-media instruction sets"). > > > > > > sincerely, > > Peter Lawrence. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From binalpatel4 at gmail.com Mon Feb 14 18:00:48 2011 From: binalpatel4 at gmail.com (Binal Patel) Date: Mon, 14 Feb 2011 16:00:48 -0800 Subject: [LLVMdev] Error while building llvm-gcc-4.2 In-Reply-To: References: Message-ID: Yes, I tried the part in "Configure, Build, Install, Test", and I was getting errors there; and so i looked at one of the earlier posts where they actually resolve the issue. And i tried doing exactly what that post said, but it didnt work for me. Here, I was trying to resolve this build error: * * *configure: error: You must specify valid path to your LLVM tree with --enable-llvm=DIR* So, what should $DIR in --enable-llvm=$DIR be? /users/bp/llvm/llvm-src/trunk/? or /users/bp/llvm/obj/? or /usr/local/lib? I have tried all three of these and i am still getting an error above. (Default DIR is set to /users/bp/ - which also gives an error similar to above. I tried looking for --enable-llvm's proper description, but I couldn't find it using *./configure --help )* * * (So, i guess i was trying to see if can get away with building it differently inside the directory...some people were able to do it in previous posts, so i thought id give it a try too!) On Mon, Feb 14, 2011 at 2:07 PM, Anton Korobeynikov wrote: > Hello > > > What does this error mean? and how do i take care of it? > > (And README.LLVM is not that great of a help) > Have you read it? Especially the section "Configure, Build, Install, Test"? > > -- > 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/20110214/3f136a92/attachment.html From andrew at sidefx.com Mon Feb 14 18:32:10 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Mon, 14 Feb 2011 19:32:10 -0500 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: References: <4D599B2B.101@sidefx.com> Message-ID: <4D59C98A.8040309@sidefx.com> I'm just suggesting that from the perspective of the LLVM IR there doesn't seem to be a necessary semantic difference between arrays and vectors. Arrays provide a superset of the functionality available for vectors. I would be happy if the code generator used 4x32bit vectors for basic math on [4xfloat] arrays, and fell back to something less efficient if the user decided to dynamically index it. However, maybe this is more work for the code generator than is currently feasible. On 02/14/2011 06:44 PM, Villmow, Micah wrote: > Andrew, > This is one area of LLVM that maps very nicely to our GPU architecture. A vector is a native data type on these architectures. For example, on AMD's GPUs, the native type is 4x32bit vector with sub-components. Each of the individual 32bits can be indexed separately, but not dynamically. This is a big difference from an array of 32bit values. So there are cases where the meaning of the two are different on modern hardware. > > Micah > From clattner at apple.com Mon Feb 14 18:46:36 2011 From: clattner at apple.com (Chris Lattner) Date: Mon, 14 Feb 2011 16:46:36 -0800 Subject: [LLVMdev] "why have a vector type" In-Reply-To: <4D59C98A.8040309@sidefx.com> References: <4D599B2B.101@sidefx.com> <4D59C98A.8040309@sidefx.com> Message-ID: <4C242DF7-6C55-47A3-BD48-CC9633652ADF@apple.com> On Feb 14, 2011, at 4:32 PM, Andrew Clinton wrote: > I'm just suggesting that from the perspective of the LLVM IR there > doesn't seem to be a necessary semantic difference between arrays and > vectors. Arrays provide a superset of the functionality available for > vectors. I would be happy if the code generator used 4x32bit vectors > for basic math on [4xfloat] arrays, and fell back to something less > efficient if the user decided to dynamically index it. However, maybe > this is more work for the code generator than is currently feasible. You could make the same argument for arrays and structs: {i32,i32,i32,i32} is (almost) semantically equivalent to [4 x i32]. Similarly, pointers and integers are semantically very similar. You could even say that an i32 and f32 should be the same type and just have different operations available on them. This would map naturally to SSE for example. The answer here is that having these differentiated in the type system makes analysis, optimization, and code generation easier. Having explicit vector types is definitely goodness. -Chris > > On 02/14/2011 06:44 PM, Villmow, Micah wrote: >> Andrew, >> This is one area of LLVM that maps very nicely to our GPU architecture. A vector is a native data type on these architectures. For example, on AMD's GPUs, the native type is 4x32bit vector with sub-components. Each of the individual 32bits can be indexed separately, but not dynamically. This is a big difference from an array of 32bit values. So there are cases where the meaning of the two are different on modern hardware. >> >> Micah >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From kaelyn.alexi at gmail.com Mon Feb 14 18:22:10 2011 From: kaelyn.alexi at gmail.com (Kaelyn Uhrain) Date: Mon, 14 Feb 2011 16:22:10 -0800 Subject: [LLVMdev] Make "llvmc -opt" call "opt" for .ll files Message-ID: Without this patch, opt is never called for llvm-assembly (.ll) files when "-opt" is passed to llvmc: $ llvmc -clang -v test.ll llc -f -O2 test.ll -o /tmp/llvm_gvO2nK/test.s as /tmp/llvm_gvO2nK/test.s -o /tmp/llvm_gvO2nK/test.o llvm-ld -native -disable-internalize /tmp/llvm_gvO2nK/test.o -o a.out $ llvmc -clang -opt -v test.ll llc -f -O2 test.ll -o /tmp/llvm_2xiL86/test.s as /tmp/llvm_2xiL86/test.s -o /tmp/llvm_2xiL86/test.o llvm-ld -native -disable-internalize /tmp/llvm_2xiL86/test.o -o a.out This patch makes a small change to tools/llvmc/src/Base.td so that "-opt" is honored for .ll files. Invoking llvmc with this patch results in: $ llvmc -clang -v test.ll llc -O2 test.ll -o /tmp/llvm_nbnJRg/test.s as /tmp/llvm_nbnJRg/test.s -o /tmp/llvm_nbnJRg/test.o llvm-ld -native -disable-internalize /tmp/llvm_nbnJRg/test.o -o a.out $ llvmc -clang -opt -v test.ll llvm-as test.ll -o /tmp/llvm_OoIRlO/test.bc opt -f -O2 /tmp/llvm_OoIRlO/test.bc -o /tmp/llvm_OoIRlO/test.bc-GHASUE llc -O2 /tmp/llvm_OoIRlO/test.bc-GHASUE -o /tmp/llvm_OoIRlO/test.s as /tmp/llvm_OoIRlO/test.s -o /tmp/llvm_OoIRlO/test.o llvm-ld -native -disable-internalize /tmp/llvm_OoIRlO/test.o -o a.out -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-opt-ll.diff Type: text/x-patch Size: 646 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110214/888ca705/attachment.bin From simmon12 at illinois.edu Tue Feb 15 02:10:48 2011 From: simmon12 at illinois.edu (Patrick Simmons) Date: Tue, 15 Feb 2011 02:10:48 -0600 Subject: [LLVMdev] C++ Mangled Names Message-ID: <4D5A3508.1040403@illinois.edu> I have encountered a need for manually generating the mangled name of an arbitrary C++ function. The only way I currently know how to do this is to generate a dummy C++ source file, compile it, and look at the output. This approach is so ugly that I would like for it never to see the light of day. The c++filt tool generates demangled C++ names given the mangled ones, which is the opposite of what I want to do. Does anyone know how to "run c++filt in reverse"? Thanks, --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 ihusar at fit.vutbr.cz Tue Feb 15 07:09:57 2011 From: ihusar at fit.vutbr.cz (ihusar) Date: Tue, 15 Feb 2011 14:09:57 +0100 Subject: [LLVMdev] How to use ConstantFoldConstantExpression? Message-ID: Hello, i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, however I am not able to make it fold anything. Could you please give me some advice, what I am doing wrong? My code looks something like this: //data layout is obtained from clang-generated code for triple arm-none-linux-gnueabi with added v32:32:32 const char* const TARGET_DATA_LAYOUT = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v128:128:128-a0:0:64-n32"; TargetData TD(TARGET_DATA_LAYOUT); void transformConstantExpr(ConstantExpr* cop) { Constant* val = ConstantFoldConstantExpression(cop, &TD); if (val != NULL) { errs() << "**" << *cop << " to \n--" << *val << "\n"; } } And this is the output i get, all constants should result in "i32 0" (at least this is what I need): **i32 bitcast (<4 x i8> zeroinitializer to i32) to --i32 bitcast (<4 x i8> zeroinitializer to i32) **i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) to --i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) **i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) to --i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) **i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to --i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) to --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) **i32 bitcast (<2 x i16> zeroinitializer to i32) to --i32 bitcast (<2 x i16> zeroinitializer to i32) **i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 3) to i16)> to i32) to <4 x i8>) to i32) to --i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 3) to i16)> to i32) to <4 x i8>) to i32) Have I something wrong in the TargetData or do I miss something else? I tried also big endian, but it did not help. Thank you Adam Husar From ihusar at fit.vutbr.cz Tue Feb 15 07:51:58 2011 From: ihusar at fit.vutbr.cz (ihusar) Date: Tue, 15 Feb 2011 14:51:58 +0100 Subject: [LLVMdev] How to use ConstantFoldConstantExpression? In-Reply-To: References: Message-ID: I forgot to mention, that I use LLVM release 2.8, I did not try it with the latest revision, but I expect that I am rather doing something wrong than using non-implemented functions. On Tue, 15 Feb 2011 14:09:57 +0100, ihusar wrote: > Hello, > > i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, > however I am not able to make it fold anything. Could you please give me some advice, what I am doing wrong? > > > My code looks something like this: > > //data layout is obtained from clang-generated code for triple arm-none-linux-gnueabi with added v32:32:32 > const char* const TARGET_DATA_LAYOUT = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v128:128:128-a0:0:64-n32"; > > TargetData TD(TARGET_DATA_LAYOUT); > > void transformConstantExpr(ConstantExpr* cop) > { > Constant* val = ConstantFoldConstantExpression(cop, &TD); > if (val != NULL) > { > errs() << "**" << *cop << " to \n--" << *val << "\n"; > } > } > > And this is the output i get, all constants should result in "i32 0" (at least this is what I need): > > **i32 bitcast (<4 x i8> zeroinitializer to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32) > > **i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) to > --i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) > > **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) > > **i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) to > --i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) > > **i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) > > **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) > > **i32 bitcast (<2 x i16> zeroinitializer to i32) to > --i32 bitcast (<2 x i16> zeroinitializer to i32) > > **i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 3) to i16)> to i32) to <4 x i8>) to i32) to > --i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 3) to i16)> to i32) to <4 x i8>) to i32) > > > Have I something wrong in the TargetData or do I miss something else? > I tried also big endian, but it did not help. > > Thank you > Adam Husar > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From nadav.rotem at intel.com Tue Feb 15 07:59:21 2011 From: nadav.rotem at intel.com (Rotem, Nadav) Date: Tue, 15 Feb 2011 15:59:21 +0200 Subject: [LLVMdev] How to use ConstantFoldConstantExpression? In-Reply-To: References: Message-ID: <6594DDFF12B03D4E89690887C24869940270FC9A92@hasmsx504.ger.corp.intel.com> Adam, I just fixed this issue a few days ago. A version from the trunk should work for you. Cheers, Nadav -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ihusar Sent: Tuesday, February 15, 2011 15:52 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] How to use ConstantFoldConstantExpression? I forgot to mention, that I use LLVM release 2.8, I did not try it with the latest revision, but I expect that I am rather doing something wrong than using non-implemented functions. On Tue, 15 Feb 2011 14:09:57 +0100, ihusar wrote: > Hello, > > i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, > however I am not able to make it fold anything. Could you please give me some advice, what I am doing wrong? > > > My code looks something like this: > > //data layout is obtained from clang-generated code for triple arm-none-linux-gnueabi with added v32:32:32 > const char* const TARGET_DATA_LAYOUT = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v128:128:128-a0:0:64-n32"; > > TargetData TD(TARGET_DATA_LAYOUT); > > void transformConstantExpr(ConstantExpr* cop) > { > Constant* val = ConstantFoldConstantExpression(cop, &TD); > if (val != NULL) > { > errs() << "**" << *cop << " to \n--" << *val << "\n"; > } > } > > And this is the output i get, all constants should result in "i32 0" (at least this is what I need): > > **i32 bitcast (<4 x i8> zeroinitializer to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32) > > **i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) to > --i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) > > **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) > > **i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) to > --i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) > > **i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) > > **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) > > **i32 bitcast (<2 x i16> zeroinitializer to i32) to > --i32 bitcast (<2 x i16> zeroinitializer to i32) > > **i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 3) to i16)> to i32) to <4 x i8>) to i32) to > --i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 3) to i16)> to i32) to <4 x i8>) to i32) > > > Have I something wrong in the TargetData or do I miss something else? > I tried also big endian, but it did not help. > > Thank you > Adam Husar > _______________________________________________ > 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 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From fvbommel at gmail.com Tue Feb 15 08:06:55 2011 From: fvbommel at gmail.com (Frits van Bommel) Date: Tue, 15 Feb 2011 15:06:55 +0100 Subject: [LLVMdev] How to use ConstantFoldConstantExpression? In-Reply-To: <6594DDFF12B03D4E89690887C24869940270FC9A92@hasmsx504.ger.corp.intel.com> References: <6594DDFF12B03D4E89690887C24869940270FC9A92@hasmsx504.ger.corp.intel.com> Message-ID: On Tue, Feb 15, 2011 at 2:59 PM, Rotem, Nadav wrote: > I just fixed this issue a few days ago. A version from the trunk should work for you. Also, ihusar: you don't need ConstantFoldConstantExpression() here as they're folded automatically now. From baldrick at free.fr Tue Feb 15 08:16:16 2011 From: baldrick at free.fr (Duncan Sands) Date: Tue, 15 Feb 2011 15:16:16 +0100 Subject: [LLVMdev] How to use ConstantFoldConstantExpression? In-Reply-To: References: Message-ID: <4D5A8AB0.80108@free.fr> Hi, > I forgot to mention, that I use LLVM release 2.8, I did not try it with the latest revision, but I expect that I > am rather doing something wrong than using non-implemented functions. the constant folder has historically done a poor job of folding vector expressions. Does it succeed in folding non-vector expressions? Ciao, Duncan. > > On Tue, 15 Feb 2011 14:09:57 +0100, ihusar wrote: > >> Hello, >> >> i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, >> however I am not able to make it fold anything. Could you please give me some advice, what I am doing wrong? >> >> >> My code looks something like this: >> >> //data layout is obtained from clang-generated code for triple arm-none-linux-gnueabi with added v32:32:32 >> const char* const TARGET_DATA_LAYOUT = >> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v128:128:128-a0:0:64-n32"; >> >> TargetData TD(TARGET_DATA_LAYOUT); >> >> void transformConstantExpr(ConstantExpr* cop) >> { >> Constant* val = ConstantFoldConstantExpression(cop,&TD); >> if (val != NULL) >> { >> errs()<< "**"<< *cop<< " to \n--"<< *val<< "\n"; >> } >> } >> >> And this is the output i get, all constants should result in "i32 0" (at least this is what I need): >> >> **i32 bitcast (<4 x i8> zeroinitializer to i32) to >> --i32 bitcast (<4 x i8> zeroinitializer to i32) >> >> **i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) to >> --i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) >> >> **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to >> --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) >> >> **i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) to >> --i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) >> >> **i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to >> --i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) >> >> **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) to >> --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) >> >> **i32 bitcast (<2 x i16> zeroinitializer to i32) to >> --i32 bitcast (<2 x i16> zeroinitializer to i32) >> >> **i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to<4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to<4 x i8>), i32 3) to i16)> to i32) to<4 x i8>) to i32) to >> --i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to<4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to<4 x i8>), i32 3) to i16)> to i32) to<4 x i8>) to i32) >> >> >> Have I something wrong in the TargetData or do I miss something else? >> I tried also big endian, but it did not help. >> >> Thank you >> Adam Husar >> _______________________________________________ >> 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 ihusar at fit.vutbr.cz Tue Feb 15 08:26:09 2011 From: ihusar at fit.vutbr.cz (ihusar) Date: Tue, 15 Feb 2011 15:26:09 +0100 Subject: [LLVMdev] How to use ConstantFoldConstantExpression? In-Reply-To: <6594DDFF12B03D4E89690887C24869940270FC9A92@hasmsx504.ger.corp.intel.com> References: <6594DDFF12B03D4E89690887C24869940270FC9A92@hasmsx504.ger.corp.intel.com> Message-ID: Hello Nadav, thank you for your quick answer. Adam On Tue, 15 Feb 2011 14:59:21 +0100, Rotem, Nadav wrote: > Adam, > > I just fixed this issue a few days ago. A version from the trunk should work for you. > > Cheers, > Nadav > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ihusar > Sent: Tuesday, February 15, 2011 15:52 > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] How to use ConstantFoldConstantExpression? > > I forgot to mention, that I use LLVM release 2.8, I did not try it with the latest revision, but I expect that I > am rather doing something wrong than using non-implemented functions. > > On Tue, 15 Feb 2011 14:09:57 +0100, ihusar wrote: > >> Hello, >> >> i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, >> however I am not able to make it fold anything. Could you please give me some advice, what I am doing wrong? >> >> >> My code looks something like this: >> >> //data layout is obtained from clang-generated code for triple arm-none-linux-gnueabi with added v32:32:32 >> const char* const TARGET_DATA_LAYOUT = >> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v128:128:128-a0:0:64-n32"; >> >> TargetData TD(TARGET_DATA_LAYOUT); >> >> void transformConstantExpr(ConstantExpr* cop) >> { >> Constant* val = ConstantFoldConstantExpression(cop, &TD); >> if (val != NULL) >> { >> errs() << "**" << *cop << " to \n--" << *val << "\n"; >> } >> } >> >> And this is the output i get, all constants should result in "i32 0" (at least this is what I need): >> >> **i32 bitcast (<4 x i8> zeroinitializer to i32) to >> --i32 bitcast (<4 x i8> zeroinitializer to i32) >> >> **i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) to >> --i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) >> >> **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to >> --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32), i32 0) to i8), i8 0, i8 0, i8 0> to i32) >> >> **i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) to >> --i32 and (i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255) >> >> **i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) to >> --i32 bitcast (<4 x i8> zeroinitializer to i32), i32 255), i32 0) to i8), i8 0, i8 0, i8 0> to i32) >> >> **i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) to >> --i32 bitcast (<4 x i8> zeroinitializer to i32) to i8), i8 0, i8 0, i8 0> to i32) >> >> **i32 bitcast (<2 x i16> zeroinitializer to i32) to >> --i32 bitcast (<2 x i16> zeroinitializer to i32) >> >> **i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 3) to i16)> to i32) to <4 x i8>) to i32) to >> --i32 bitcast (<4 x i8> bitcast (i32 bitcast (<2 x i16> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 2) to i16), i16 zext (i8 extractelement (<4 x i8> bitcast (i32 bitcast (<4 x i8> zeroinitializer to i32) to <4 x i8>), i32 3) to i16)> to i32) to <4 x i8>) to i32) >> >> >> Have I something wrong in the TargetData or do I miss something else? >> I tried also big endian, but it did not help. >> >> Thank you >> Adam Husar >> _______________________________________________ >> 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 > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > From daveed at vandevoorde.com Tue Feb 15 09:41:20 2011 From: daveed at vandevoorde.com (David Vandevoorde) Date: Tue, 15 Feb 2011 10:41:20 -0500 Subject: [LLVMdev] C++ Mangled Names In-Reply-To: <4D5A3508.1040403@illinois.edu> References: <4D5A3508.1040403@illinois.edu> Message-ID: <701AB907-0B82-4535-BA52-6F20146EF0CC@vandevoorde.com> On Feb 15, 2011, at 3:10 AM, Patrick Simmons wrote: > I have encountered a need for manually generating the mangled name of an > arbitrary C++ function. The only way I currently know how to do this is > to generate a dummy C++ source file, compile it, and look at the > output. This approach is so ugly that I would like for it never to see > the light of day. The c++filt tool generates demangled C++ names given > the mangled ones, which is the opposite of what I want to do. Does > anyone know how to "run c++filt in reverse"? It's not so simple. Assuming you limit yourself to the ABI used by the GNU compiler, there is still an awful lot of information needed in the most general case. See: http://www.codesourcery.com/public/cxx-abi/abi.html#mangling for the mangling scheme (although the actual GCC implementation sometimes deviates from that for less common cases). If you're only dealing with non-local named functions and types plus ordinary type composition and exclude function templates (or at least, function templates with dependent expressions in the signature), it's probably not too hard (i.e., just a day or a few days work) to code up a mangler. If more is needed (local types, decltype, lambdas, etc.), it gets messier quite quickly. Daveed From jnspaulsson at hotmail.com Tue Feb 15 10:03:04 2011 From: jnspaulsson at hotmail.com (Jonas Paulsson) Date: Tue, 15 Feb 2011 17:03:04 +0100 Subject: [LLVMdev] Instruction selection of intrinsics Message-ID: Hi, I am a bit stuck with this because the intrinsics on the LLVM I/R can only have one value, but for a memory intrinsic, I need it to have two values actually. How should I add the second value and maintain the control chain? The intrinsic looks like (MVT::i16, MVT::other), and if I lower the node to (MVT::i16, MVT::i16, MVT::other), I get the problem that the user of the chain is not updated to the right value index. Should I put the chain in the same slot, like (MVT::i16, MVT::other, MVT::i16), to avoid this, or must the chain be last value / first operand always, and if so, why? Or, should I perhaps use a custom lowering and add the operand manually? thanks, Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110215/b35a66df/attachment.html From greened at obbligato.org Tue Feb 15 10:38:05 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 15 Feb 2011 10:38:05 -0600 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: (Peter Lawrence's message of "Mon, 14 Feb 2011 12:49:23 -0800") References: Message-ID: Peter Lawrence writes: > Andrew, your response highlights a naming problem in LLVM, which is > that "array" and "vector" mean the same thing in normal computer > language and compiler theory usage, so it is inconvenient and > misleading within LLVM to give one a very specific meaning that is > different from the other.... I think any sort of separation at all is counterproductive. The existing array/vector split is artificial. It would be better to have one array-like type and allow a reasonable set of operations on it. Target lowering should take care of legality issues. For best performance various transformation patterns will want to know about the target but that's true independent of vector types. Scalar optimizers want to know about targets too. > As far as I am aware not a single one of any of the above types of > instruction sets allows the "subscripting" of packed data within a > register Given what we know of Larrabee and speculating that the "Knights" family is likely a derivative of it, it's safe to assume that future Intel architectures will be much more like traditional vector machines. That means gather/scatter, element indexing, etc. The existing PINSR/PEXTR and shuffle instructions already allow a degree of element indexing. Note that the existing LLVM vector types already have insert/extract operators. Unifying array and vector and generalizing the result would open a lot of optimization opportunities. -Dave From greened at obbligato.org Tue Feb 15 10:38:56 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 15 Feb 2011 10:38:56 -0600 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: <4D599B2B.101@sidefx.com> (Andrew Clinton's message of "Mon, 14 Feb 2011 16:14:19 -0500") References: <4D599B2B.101@sidefx.com> Message-ID: Andrew Clinton writes: > Agreed, I too was wondering why we need both arrays and vectors. It > goes against the grain, I think, of the structure typing system used by > LLVM. For example, a vector of 4 floats and an array of 4 floats are > structurally the same type. Would it be feasible in the future to > consolidate the two types by allowing "vector" operations (add, > multiply, etc.) on arrays where it makes sense, and doing away with the > specialized vector types? Actually, I do not believe an array of 4 floats and a vector of 4 floats are the same. There are various bit packing and alignment semantics that differ. -Dave From greened at obbligato.org Tue Feb 15 10:42:19 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 15 Feb 2011 10:42:19 -0600 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: (Reid Kleckner's message of "Mon, 14 Feb 2011 16:27:22 -0500") References: Message-ID: Reid Kleckner writes: > So far as I know in the field of compilers "vectorization" always > refers to lowering code down to use SIMD operations. Not true at all. "Vectorization" as mapping exclusicely to fixed-length SSE-style instructions is relatively new. Traditionally, vectorization has meant targeting vector registers with variable-length operations and masks. The SSE-style instructions sets are very limited in comparison. The Allen/Kennedy book is a good resource. http://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860 -Dave From viridia at gmail.com Tue Feb 15 11:47:06 2011 From: viridia at gmail.com (Talin) Date: Tue, 15 Feb 2011 09:47:06 -0800 Subject: [LLVMdev] Introducing LLBrowse: A graphical browser for LLVM modules In-Reply-To: References: <4D597B48.3030205@gmail.com> <4D597C46.2070507@gmail.com> Message-ID: LLBrowse can now successfully build and run under Snow Leopard. The main problem was that wxWidgets uses the Carbon APIs, and there's apparently no 64-bit version of Carbon, so applications have to be compiled as 32-bits. Supposedly there's a new Cocoa-based version of wxWidgets that is in development, but it's still experimental. Here's the cmake command I used: cmake -G "Xcode" -D LLVM_CONFIG_EXECUTABLE="" -D CMAKE_OSX_ARCHITECTURES="i386;ppc" Note that you will also need a 32-bit version of the LLVM libraries as well. Defining CMAKE_OSX_ARCHITECTURES="i386;ppc" on the cmake command line works. You probably want to also set CMAKE_INSTALL_PREFIX so that you don't install the 32-bit libraries over your 64-bit ones. In any case, the program does appear to work, although it could use some OS X polish. -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110215/6df22876/attachment.html From renato.golin at arm.com Tue Feb 15 12:09:45 2011 From: renato.golin at arm.com (Renato Golin) Date: Tue, 15 Feb 2011 18:09:45 +0000 Subject: [LLVMdev] Structure Types and ABI sizes Message-ID: Hi all, We're hitting some walls here when generating the correct structure layout for specific C++ ABI requirements, and I was wondering how much StructLayout could help. For instance, the ABI has some complicated rules on the size of derived classes (http://www.codesourcery.com/public/cxx-abi/abi.html#class-types) and LLVM struct type cannot reflect that in full. Example: // CHECK: %struct.I = type { i32, i8 } struct I { int a; char b; }; // CHECK: %struct.J = type { [8 x i8], i8, [3 x i8] } struct J : I { char c; }; What happens here is that "c" is placed in the base's tail padding and there are three bytes padding because of the alignment. The main problem with this is that, by changing the member (that should be a structure) to an array, the alignment is lost. As LLVM types don't have explicit alignment in themselves, it's impossible to recover that information later and we need to make sure that every single use of that field gets the correct alignment. Furthermore, I wonder if that wouldn't impact some optimizations that take types into account (as Chris has just replied in the vector discussion)... Not sure... So, I'm not proposing to have alignment in types nor to make LLVM struct types conform to a specific ABI of a specific language, I'm just saying that there should be a cleaner way... Very much like the union type and bitfields, structure size and alignment problems can be very hairy. Simplifying the IR and leaving all decisions to the back-end can be a daunting task, but leaving the front-end to decide on sizes and alignment is maybe not the best alternative. StructLayout already knows a few things about structures (like calculating the offset based on the type's alignment) but it's ignorant regarding specific language decisions and ABIs. We could attach some information regarding the language that is being compiled so the back-end could make some informed choices on how to deal with structures/unions/bitfields and have less hacks in the front-end. I understand that cross-compilation between languages would break that assumption, unless the IR has some kind of flags on it stating the lang/abi used... but I know very few people like adding information to the IR... :/ Any pointers on how to solve this issue in a better way other than bloating the front-end? -- cheers, --renato From greened at obbligato.org Tue Feb 15 12:30:08 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 15 Feb 2011 12:30:08 -0600 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: (Renato Golin's message of "Tue, 15 Feb 2011 18:09:45 +0000") References: Message-ID: Renato Golin writes: > Example: > > // CHECK: %struct.I = type { i32, i8 } > struct I { > int a; > char b; > }; > > // CHECK: %struct.J = type { [8 x i8], i8, [3 x i8] } > struct J : I { > char c; > }; > > What happens here is that "c" is placed in the base's tail padding and > there are three bytes padding because of the alignment. The main > problem with this is that, by changing the member (that should be a > structure) to an array, the alignment is lost. As LLVM types don't I don't completely understand what you're saying here. Are you saying you want to have a J member of I repesented in LLVM, so that struct J becomes: { int32, int8, { int8 } } Do I understand you correctly? > So, I'm not proposing to have alignment in types nor to make LLVM > struct types conform to a specific ABI of a specific language, I'm > just saying that there should be a cleaner way... Very much like the > union type and bitfields, structure size and alignment problems can be > very hairy. Simplifying the IR and leaving all decisions to the > back-end can be a daunting task, but leaving the front-end to decide > on sizes and alignment is maybe not the best alternative. I think it's really the only alternative. LLVM is a low-level IR. Expressing things like inheritance and layout rules for such types is beyond the scope of the language. There are too many variations among high-level languages and target ABIs. For things like that the frontend needs to insert its own padding bytes. There are ways to do that without losing too much information. For example, we render the above without using arrays at all: %I = type { i32, i8, i16 } %J = type { %I, i8, i16 } There are some places where LLVM can do a better job, I think. StructLayout should "just work" in more cases. But the kind of generality you're talking about just isn't going to work very well in a low-level IR. Nor should it. It's not what the IR is designed to do. -Dave From gs5g08 at ecs.soton.ac.uk Tue Feb 15 13:54:08 2011 From: gs5g08 at ecs.soton.ac.uk (sabaliauskas g. (gs5g08)) Date: Tue, 15 Feb 2011 19:54:08 +0000 Subject: [LLVMdev] Possible LLVM or DragonEgg bug Message-ID: <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41AB@UOS-CL-EX7-L4.soton.ac.uk> I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): /usr/lib64/ccache/c++ -Wall -Wno-long-long -pthread -ffunction-sections -D_GLIBCXX_PARALLEL -fopenmp -D__STDC_CONSTANT_MACROS -fplugin=/home/John/Documents/Project/DragonEgg/dragonegg/dragonegg.so -O3 -DNDEBUG -fomit-frame-pointer -O3 -ffast-math -mmmx -msse -msse2 -msse3 -DNDEBUG CMakeFiles/createsamples.dir/createsamples.o -o ../../bin/opencv_createsamples -rdynamic ../../lib/libcxcore.so.2.0.0 ../../lib/libcv.so.2.0.0 ../../lib/libcvhaartraining.a ../../lib/libhighgui.so.2.0.0 ../../lib/libcv.so.2.0.0 ../../lib/libcxcore.so.2.0.0 ../../3rdparty/lib/libopencv_lapack.a ../../3rdparty/lib/libzlib.a ../../3rdparty/lib/libflann.a -ldl -lm -lpthread -lrt -lgomp -Wl,-rpath,/home/Gytis/Documents/Project/OpenCV/new2/OpenCV-2.0.0/bin/lib: ../../lib/libcv.so.2.0.0: undefined reference to `_mm_cvtsd_si32(double __vector)' collect2: ld returned 1 exit status As I understand the linker can not find intrinsic SSE2 function "_mm_cvtsd_si32" while trying to link "opencv_createsamples" executable to "libcv.so.2.0.0". If compiled with the same setup but with OpenMP disabled(i.e. no "-fopenmp" flag) compilation succeeds with no errors. I would be very grateful if any body could tell me the cause of this problem or at least give me some hints where to start looking for it. From renato.golin at arm.com Tue Feb 15 15:37:41 2011 From: renato.golin at arm.com (Renato Golin) Date: Tue, 15 Feb 2011 21:37:41 +0000 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: References: Message-ID: On 15 February 2011 18:30, David A. Greene wrote: > { int32, int8, { int8 } } > > Do I understand you correctly? Hi David, I'm actually looking for answers, not requesting features... ;) That structure would actually solve the problem for this specific case, but not for the general case. There are far too many exceptions to be worth make a special case for every one of them. > There are ways to do that without losing too much information. ?For > example, we render the above without using arrays at all: > > %I = type { i32, i8, i16 } > %J = type { %I, i8, i16 } Not if you follow the Itanium C++ ABI. In your example it works because { i8, i16 } pads nicely to 4 bytes, so there is no tail padding. If there is tail padding, the size of the Base class is different from the size of the Base class inside the Derived one. So, in my example "B : public A { char }": %A = type { i32, i8 } %B = type { %A, i8 } A has 8 bytes, as it should, but inside B it has only 5, so B's first field offset is 5, not 8. This is why we have to do: %B = { [5 x i8], i8, [3 x i8] } Adding the 3 bytes at the end is NOT the problem, but revoking the type (and it's natural alignment) from %A is. > There are some places where LLVM can do a better job, I think. > StructLayout should "just work" in more cases. ?But the kind of > generality you're talking about just isn't going to work very well in a > low-level IR. ?Nor should it. ?It's not what the IR is designed to do. My idea was that StructLayout could have more (optional) sources of information, to do a better job at figuring out sizes and offsets. We even thought about creating a Pass that will transform from natural structures, unions and bitfields to the horrible mess it results to when lowered, but that's avoiding the problem, not solving them. The IR was designed for type safety and we have far too many hacks in the type system that all C++ front-ends have to do. Maybe the original design wasn't followed so closely, or we need a new design document that clearly states what the goals are, because the way it is, it's not clear, and it's definitely not good for C++. -- cheers, --renato From dag at cray.com Tue Feb 15 15:46:34 2011 From: dag at cray.com (David Greene) Date: Tue, 15 Feb 2011 15:46:34 -0600 Subject: [LLVMdev] Need Advice: X86ShuffleDecode Problem Message-ID: I've run into a problem with X86ShuffleDecode.hpp while implementing AVX shuffles. It turns out that to decode AVX shuffles properly, I need to pass types to the X86ShuffleDecode logic. NumElements is not enough because 4 elements could mean 4 32-bit or 4 64-bit. The shuffle decode will be different based on the element type. As things stand right now, X86ShuffleDecode.hpp gets included into X86ISLowering.cpp and X86InstComments.cpp (at the very least, there may be other clients I'm not aware of). All functions in X86ShuffleDecode.hpp are static in the header with their full implementation visible. The #include strategy breaks down because sometimes static functions are defined in X86ShuffleDecode.hpp that are not used in the file that includes them. The reasons for this boil down to the fact that some clients have type information readily available and others don't so such type information needs to be synthesized from the available opcode and NumElements data. For convenience I put that synthesizing code into X86ShuffleDecode.hpp at new entry points. Such unused definitions cause compiler warnings which will be build errors when using -Werror. Naturally, I found the statically-defined functions in a header file odd, and figured the solution would be to move them to their own .cpp file, removing the static qualifier. That would eliminate the unused static function problems. Unfortunately, I tripped over the reason why they were defined static in the header in the first place. Moving them to their own .cpp causes a circular dependence between libLLVMX86AsmPrinter.a and libLLVMX86CodeGen.a. Putting them in the header seems to be a big hack to get around this problem. I need a way out. One option would be to create another X86 target library (libX86ShuffleDecode.a? We would need a better name). Another option is to use #ifdef code in X86ShuffleDecode.hpp but I really don't want to go that route. A third option might be to make some client code uglier by requiring it to compute types before calling functions in X86ShuffleDecode.hpp. I haven't tried this option yet so I don't know how ugly things will get or if it is even feasible. It would require more intrusive changes throughout the X86 codegen to implement AVX properly. I had hoped to avoid these kinds of changes as much as possible. I would prefer to create a new library. Is that a reasonable solution? If so, is there are good name for it? I can imagine more code that just shuffle decode logic might go in there eventually. Maybe something like X86Utils.a would be a good name. -Dave From kaelyn.alexi at gmail.com Tue Feb 15 15:47:34 2011 From: kaelyn.alexi at gmail.com (Kaelyn Uhrain) Date: Tue, 15 Feb 2011 13:47:34 -0800 Subject: [LLVMdev] Make "llvmc -opt" call "opt" for .ll files In-Reply-To: References: Message-ID: Without this patch, opt is never called for llvm-assembly (.ll) files when "-opt" is passed to llvmc: $ llvmc -clang -v test.ll llc -f -O2 test.ll -o /tmp/llvm_gvO2nK/test.s as /tmp/llvm_gvO2nK/test.s -o /tmp/llvm_gvO2nK/test.o llvm-ld -native -disable-internalize /tmp/llvm_gvO2nK/test.o -o a.out $ llvmc -clang -opt -v test.ll llc -f -O2 test.ll -o /tmp/llvm_2xiL86/test.s as /tmp/llvm_2xiL86/test.s -o /tmp/llvm_2xiL86/test.o llvm-ld -native -disable-internalize /tmp/llvm_2xiL86/test.o -o a.out This patch makes a small change to tools/llvmc/src/Base.td so that "-opt" is honored for .ll files. ?Invoking llvmc with this patch results in: $ llvmc -clang -v test.ll llc -O2 test.ll -o /tmp/llvm_nbnJRg/test.s as /tmp/llvm_nbnJRg/test.s -o /tmp/llvm_nbnJRg/test.o llvm-ld -native -disable-internalize /tmp/llvm_nbnJRg/test.o -o a.out $ llvmc -clang -opt -v test.ll llvm-as test.ll -o /tmp/llvm_OoIRlO/test.bc opt -f -O2 /tmp/llvm_OoIRlO/test.bc -o /tmp/llvm_OoIRlO/test.bc-GHASUE llc -O2 /tmp/llvm_OoIRlO/test.bc-GHASUE -o /tmp/llvm_OoIRlO/test.s as /tmp/llvm_OoIRlO/test.s -o /tmp/llvm_OoIRlO/test.o llvm-ld -native -disable-internalize /tmp/llvm_OoIRlO/test.o -o a.out Cheers, Kaelyn -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-opt-ll.diff Type: text/x-patch Size: 646 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110215/0680220b/attachment.bin From greened at obbligato.org Tue Feb 15 16:14:13 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 15 Feb 2011 16:14:13 -0600 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: (Renato Golin's message of "Tue, 15 Feb 2011 21:37:41 +0000") References: Message-ID: Renato Golin writes: >> There are ways to do that without losing too much information. ?For >> example, we render the above without using arrays at all: >> >> %I = type { i32, i8, i16 } >> %J = type { %I, i8, i16 } > > Not if you follow the Itanium C++ ABI. > > In your example it works because { i8, i16 } pads nicely to 4 bytes, That's why we use { i8, i16 }. It's not by accident. We do adhere to the Itanium ABI. > so there is no tail padding. If there is tail padding, the size of the > Base class is different from the size of the Base class inside the > Derived one. Yes, that's true for non-POD types. In that case the base class really has two different representations which need to be two different types in LLVM. This is really ugly stuff. I fixed a whole slew of bugs around just this issue last year. :) In these cases you may have to resort to arrays or at least a bunch of consecutive i8s. I'm sure we do so though I would have to verify that. > So, in my example "B : public A { char }": > > %A = type { i32, i8 } > %B = type { %A, i8 } > > A has 8 bytes, as it should, but inside B it has only 5, so B's first > field offset is 5, not 8. This is why we have to do: > > %B = { [5 x i8], i8, [3 x i8] } Wait, that's not what you showed before: // CHECK: %struct.J = type { [8 x i8], i8, [3 x i8] } struct J : I { char c; }; %B = { [5 x i8], i8, [3 x i8] } is not correct for the Itanium ABI because tail padding cannot be overlaid in "POD for the purposes of layout" types (secs. 1.1 and 2.2). You had it right the first time. :) > Adding the 3 bytes at the end is NOT the problem, but revoking the > type (and it's natural alignment) from %A is. What do you mean by "revoking?" Do you mean inferring the type of %A within %B given %B's layout? Why do you need to get the alignment information anyway? The byte offsets are fixed by the ABI so in the end, bits is bits and addresses is addresses. Ugly casts may be necessary but nothing too drastic that will seriously prevent optimization. > My idea was that StructLayout could have more (optional) sources of > information, to do a better job at figuring out sizes and offsets. We > even thought about creating a Pass that will transform from natural > structures, unions and bitfields to the horrible mess it results to > when lowered, but that's avoiding the problem, not solving them. I'm still not exactly sure what problem you're trying to solve. Is it a correctness issue in your code generator? That said, I have thought along similar lines to make frontends easier to construct. I imagined metadata on struct types to indicate layout requirements but the current metadata system is not appropriate since it does not consider metadata to be semantically important for correctness. But even with that solution, the frontend would still need to add the metadata to struct types. There's really no way around the frontend needing to understand the ABI at some level. It has to convey the language semantics to LLVM, which is by design language-agnostic. > The IR was designed for type safety and we have far too many hacks in > the type system that all C++ front-ends have to do. Maybe the original > design wasn't followed so closely, or we need a new design document > that clearly states what the goals are, because the way it is, it's > not clear, and it's definitely not good for C++. I'm not sure the IR was designed for type safety. The original designers can speak to that. But any language that has things like inttoptr and ptrtoint is inherently not type-safe. The typing helps certain classes of analysis and transformation but in the case of C++ inheritence there's not a whole lot that applies. You need a higher-level IR to take care of that stuff. -Dave From renato.golin at arm.com Tue Feb 15 16:53:57 2011 From: renato.golin at arm.com (Renato Golin) Date: Tue, 15 Feb 2011 22:53:57 +0000 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: References: Message-ID: On 15 February 2011 22:14, David A. Greene wrote: > That's why we use { i8, i16 }. ?It's not by accident. ?We do adhere to > the Itanium ABI. Oh, I see. But the padding is not a problem, it could be [3 x i8] or { i8, i16 }, it doesn't matter, since it's never going to be used. But the [8 x i8] that was the original Base type is, and that's cast'd away to plain array (with alignment 1). > Yes, that's true for non-POD types. ?In that case the base class really > has two different representations which need to be two different types > in LLVM. ?This is really ugly stuff. ?I fixed a whole slew of bugs > around just this issue last year. ?:) As you can see, it's my turn now... ;) >> %B = { [5 x i8], i8, [3 x i8] } > > Wait, that's not what you showed before: My bad, different case that one... > What do you mean by "revoking?" ?Do you mean inferring the type of %A > within %B given %B's layout? ?Why do you need to get the alignment > information anyway? ?The byte offsets are fixed by the ABI so in the > end, bits is bits and addresses is addresses. ?Ugly casts may be > necessary but nothing too drastic that will seriously prevent > optimization. Ok, that was my first real question. I'm not too focused on optimizations, so I don't know how much that would actually stop them from happening. What I see is that variables get cast'd away to arrays, passed to routines and cast's back (maybe to some different type) to do some arithmetic operation. If LLVM can understand that, that's fine. > I'm still not exactly sure what problem you're trying to solve. ?Is it a > correctness issue in your code generator? No. Our front-end follows the standard and the ABI to the letter, the problem starts when I have to match all ABI decisions to LLVM types. I could convert every single structure into arrays and rely only on our front-end, but that would make the IR very hard to debug. > That said, I have thought along similar lines to make frontends easier > to construct. ?I imagined metadata on struct types to indicate layout > requirements but the current metadata system is not appropriate since it > does not consider metadata to be semantically important for correctness. That's a valid point. The OpenCL guys were also discussing metadata and I think it's fair to consider it a first class citizen. But I also understand perfectly well why it hasn't, so far. Because metadata is SO generic, if you consider it first-class, people will start abusing of it for little personal modifications and the IR will stop being standard and diverge. So maybe, sticking things to the IR without metadata is still the best course for extra information (like build attributes, target sub-features, ABIs), but that's a completely different discussion. > But even with that solution, the frontend would still need to add the > metadata to struct types. ?There's really no way around the frontend > needing to understand the ABI at some level. ?It has to convey the > language semantics to LLVM, which is by design language-agnostic. Oh, I totally agree. Some knowledge is best left for the front-end, but there are some things that could be passed onto StructLayout (such as POD/nonPOD) with a little bit of effort and make the IR much easier to understand and debug. > I'm not sure the IR was designed for type safety. ?The original > designers can speak to that. ?But any language that has things like > inttoptr and ptrtoint is inherently not type-safe. ?The typing helps > certain classes of analysis and transformation but in the case of C++ > inheritence there's not a whole lot that applies. ?You need a > higher-level IR to take care of that stuff. Fair point. And that's where the idea of having the passes came from. Maybe having a high-level IR with language/ABI/sub-target information that gets converted to the current low-level IR only at the last time is the best course of action... But that unleashes a completely different beast that I'm not willing to handle right now... ;) cheers, --renato From greened at obbligato.org Tue Feb 15 17:21:50 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 15 Feb 2011 17:21:50 -0600 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: (Renato Golin's message of "Tue, 15 Feb 2011 22:53:57 +0000") References: Message-ID: Renato Golin writes: > On 15 February 2011 22:14, David A. Greene wrote: >> That's why we use { i8, i16 }. ?It's not by accident. ?We do adhere to >> the Itanium ABI. > > Oh, I see. But the padding is not a problem, it could be [3 x i8] or { > i8, i16 }, it doesn't matter, since it's never going to be used. Right. We do it for aesthetics. :) > But the [8 x i8] that was the original Base type is, and that's cast'd > away to plain array (with alignment 1). Yep. But again, I don't think you're losing much. >> Yes, that's true for non-POD types. ?In that case the base class really >> has two different representations which need to be two different types >> in LLVM. ?This is really ugly stuff. ?I fixed a whole slew of bugs >> around just this issue last year. ?:) > > As you can see, it's my turn now... ;) Good luck! :-/ >>> %B = { [5 x i8], i8, [3 x i8] } >> >> Wait, that's not what you showed before: > > My bad, different case that one... Whew! Thought I might have another nasty bug. :) > What I see is that variables get cast'd away to arrays, passed to > routines and cast's back (maybe to some different type) to do some > arithmetic operation. If LLVM can understand that, that's fine. It'll understand it but make sure it's casting to the correct types and using the correct offsets given the base types. We actually generate a bunch of ugly ptrtoint + arithmetic + inttptr + GEP stuff. I wrote an instcombine pass to fold that down to a single GEP where possible. I don't know if that's valid in general (due to inbounds and other GEP semantics) but it is for the cases we use it because we "know" where it came from. LLVM understands GEP better than ptrtoint/inttoptr, which is why we make the transform. Whether you can do this is probably dependent on how you lower things. >> I'm still not exactly sure what problem you're trying to solve. ?Is it a >> correctness issue in your code generator? > > No. Our front-end follows the standard and the ABI to the letter, the > problem starts when I have to match all ABI decisions to LLVM types. I > could convert every single structure into arrays and rely only on our > front-end, but that would make the IR very hard to debug. That's true and is the primary reason we try to maintain as much of the original structure as possible (i.e. not using arrays). We used to emit more array stuff but I actually put a fair amount of effort to improve this in our frontend. But we always have to include explicit padding at some point and that means odd-looking members from time to time. I haven't found it too terribly burdensome. >> That said, I have thought along similar lines to make frontends easier >> to construct. ?I imagined metadata on struct types to indicate layout >> requirements but the current metadata system is not appropriate since it >> does not consider metadata to be semantically important for correctness. > > That's a valid point. The OpenCL guys were also discussing metadata > and I think it's fair to consider it a first class citizen. I would like to see that too but it might be an uphill battle. :( > But I also understand perfectly well why it hasn't, so far. Because > metadata is SO generic, if you consider it first-class, people will > start abusing of it for little personal modifications and the IR will > stop being standard and diverge. Absolutely. Even so, I would consider debug info to be a semantic correctness issue. If the compiler can't produce debuggable code, it is useless. So we at least have some precendent for metadata being "important." The key with the debug info is that it's documented. It's its own little language, really. > Oh, I totally agree. Some knowledge is best left for the front-end, > but there are some things that could be passed onto StructLayout (such > as POD/nonPOD) with a little bit of effort and make the IR much easier > to understand and debug. I completely agree. > Fair point. And that's where the idea of having the passes came from. > Maybe having a high-level IR with language/ABI/sub-target information > that gets converted to the current low-level IR only at the last time > is the best course of action... > > But that unleashes a completely different beast that I'm not willing > to handle right now... ;) Oh, come on! Where's your sense of adventure? :) -Dave From renato.golin at arm.com Tue Feb 15 18:47:28 2011 From: renato.golin at arm.com (Renato Golin) Date: Wed, 16 Feb 2011 00:47:28 +0000 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: References: Message-ID: On 15 February 2011 23:21, David A. Greene wrote: > LLVM understands GEP better than ptrtoint/inttoptr, which is why we make > the transform. ?Whether you can do this is probably dependent on how you > lower things. We're using only GEPs from start, so we might not hit all the problems you did. I was actually surprised that the change to support those ABI constraints wasn't too big... >> That's a valid point. The OpenCL guys were also discussing metadata >> and I think it's fair to consider it a first class citizen. > > I would like to see that too but it might be an uphill battle. ?:( Maybe even steeper than introducing new fields to the IR... >> But that unleashes a completely different beast that I'm not willing >> to handle right now... ;) > > Oh, come on! ?Where's your sense of adventure? ?:) :D One thing at a time... It's in my TODO list to prepare a document with all the hacks one has to do to make C++ be translated to IR. As far as I know, llvm-gcc and clang had the same problems and solved the same hacky way, so there might be other people that would agree on some more radical changes. But we need more evidence to start with... One thing at a time... ;) -- cheers, --renato From rjmccall at apple.com Tue Feb 15 19:14:31 2011 From: rjmccall at apple.com (John McCall) Date: Tue, 15 Feb 2011 17:14:31 -0800 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: References: Message-ID: <0909E1A1-B757-4A4D-A102-92468C6EF468@apple.com> I think the obvious solution here is to use packed structs when the layout of an type as a base class would substantially differ from its layout as a complete object. This loses some alignment information, but frontends need to be aggressive about providing alignment on loads/stores/etc. anyway. I'm actually thinking of changing clang to do this. John. From clattner at apple.com Tue Feb 15 19:21:37 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 15 Feb 2011 17:21:37 -0800 Subject: [LLVMdev] improving constant/type uniquing In-Reply-To: References: <22B37424-EC2D-46CE-803B-0838C4A291B6@apple.com> <8D33B08D-5779-49BF-B260-0D56E65D73C4@apple.com> Message-ID: <42E3EB32-50B6-47E5-A8CC-7239BF6BDC9E@apple.com> On Feb 14, 2011, at 9:49 AM, Talin wrote: > A few additional thoughts on PR1210: > > I can think of three approaches to addressing this issue. The first approach is the one outlined in PR1210, which is to have the key have enough knowledge of the internals of the Type to be able to use the internal type array as the data for the key. > > The second approach is similar, which is to factor out the type array as a separate, immutable object which is shared by both the key and the type object. That is, you first create the type array, use that to look up the type, and if it doesn't find it, clone the type array and use it to construct a new type object, then use the same type array as the key. This is effectively what FoldingSet does. The actual bits are stored in the type if it exists. If it doesn't exist, the input vector of element types is hashed by the profiling function, and then the hash value is looked up. If there is no match, a type is created. The profile is designed to typically live on the stack to avoid a heap allocation. > Note that you can't use the same type array that you used for the lookup, because otherwise the get-or-insert function would sometimes have to take ownership of the type array depending on whether the type existed or not, which would be confusing. Right: the idea is that a lookup (which hits an already created value) should not do a heap allocation. > Another way around the ownership problem is to allocate all type arrays as part of the memory pool associated with the LLVMContext, and then 'intern' the type arrays so that they can be compared via pointer rather than by value. The type arrays go away when the context does, so you don't have to worry about who is responsible for freeing it. The downside is that you now have to do two hash lookups for the type object's get-or-create method. I don't really understand what you mean by this. You still need to hash on the identity of the type and the subclass of type still needs to have accessors for its elements. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110215/cf35a17f/attachment.html From jaykang10 at imrc.kist.re.kr Tue Feb 15 20:14:54 2011 From: jaykang10 at imrc.kist.re.kr (Jin Gu Kang) Date: Wed, 16 Feb 2011 11:14:54 +0900 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: References: Message-ID: <3E94D039A2B82544B3E7D48F924B0B25DFA3D87FE8@base.imrc.kist.re.kr> Hi renato Do you remember me? Your comment on previous mailing list was so helpful for me :) Nowdays I'm implementing modified LLVM IR to make target independent struct memory layout. Modified IR is changed to original LLVM IR later which can use general llvm operations (optimizations, code gernerations, etc...) I am inserting align information to type information to implement modified IR. For example, C source code struct kist { char a:7; int b:20; short c:3; int d:15; }; struct kist kang = {1, 2, 3, 4}; int main(void) { kang.d = 1; return 0; } ----------------------------------------------------------------- Modified LLVM IR %struct.kist = type { i7(char), i20(int), i3(short), i15(int) } @kang = global %struct.kist { i7(char) 1, i20(int) 2, i3(short) 3, i15(int) 4 } ; <%struct.kist*> [#uses=2] define arm_aapcscc i32(int) @main() nounwind { entry: %retval = alloca i32(int) ; [#uses=2] %0 = alloca i32(int) ; [#uses=2] %"alloca point" = bitcast i32(int) 0 to i32(int) ; [#uses=0] ovmresolving store i15(int) 1, i15(int)* getelementptr inbounds (%struct.kist* @kang, i32(uint) 0, i32(int) 3), align 4 store i32(int) 0, i32(int)* %0, align 4 %1 = load i32(int)* %0, align 4 ; [#uses=1] store i32(int) %1, i32(int)* %retval, align 4 br label %return return: ; preds = %entry %retval1 = load i32(int)* %retval ; [#uses=1] ret i32(int) %retval1 } ----------------------------------------------------------------- Reconstructed LLVM IR %0 = type { i8(char), i8(char), i8(char), i8(char), i8(char), i8(char), [2 x i8(char)] } %struct.kist = type <{ i32(int), i16(short), [2 x i8(char)] }> @kang = global %0 { i8(char) 1, i8(char) 1, i8(char) 0, i8(char) 24, i8(char) 4, i8(char) 0, [2 x i8(char)] zeroinitializer } ; <%0*> [#uses=1] define arm_aapcscc i32(int) @main() nounwind { entry: %retval = alloca i32(int) ; [#uses=2] %0 = alloca i32(int) ; [#uses=2] %"alloca point" = bitcast i32(int) 0 to i32(int) ; [#uses=0] %1 = load i16(short)* getelementptr inbounds (%struct.kist* bitcast (%0* @kang to %struct.kist*), i32(uint) 0, i32(int) 1), align 1 ; [#uses=1] %2 = and i16(short) %1, -32768 ; [#uses=1] %3 = or i16(short) %2, 1 ; [#uses=1] store i16(short) %3, i16(short)* getelementptr inbounds (%struct.kist* bitcast (%0* @kang to %struct.kist*), i32(uint) 0, i32(int) 1), align 1 store i32(int) 0, i32(int)* %0, align 4 %4 = load i32(int)* %0, align 4 ; [#uses=1] store i32(int) %4, i32(int)* %retval, align 4 br label %return return: ; preds = %entry %retval1 = load i32(int)* %retval ; [#uses=1] ret i32(int) %retval1 } ----------------------------------------------------------------- To insert align information into type information, I added align information to llvm-gcc's type nodes and llvm's type information as follows: example IntegerType llvm-gcc file: gcc/tree.c TYPE_OVMALIGNID(char_type_node) = CharAlignID; TYPE_OVMALIGNID(signed_char_type_node) = CharAlignID; TYPE_OVMALIGNID(unsigned_char_type_node) = UCharAlignID; TYPE_OVMALIGNID(short_integer_type_node) = ShortAlignID; TYPE_OVMALIGNID(short_unsigned_type_node) = UShortAlignID; TYPE_OVMALIGNID(integer_type_node) = IntAlignID; TYPE_OVMALIGNID(unsigned_type_node) = UIntAlignID; TYPE_OVMALIGNID(long_integer_type_node) = LongAlignID; TYPE_OVMALIGNID(long_unsigned_type_node) = ULongAlignID; TYPE_OVMALIGNID(long_long_integer_type_node) = LongLongAlignID; TYPE_OVMALIGNID(long_long_unsigned_type_node) = ULongLongAlignID; llvm file: include/llvm/Type.h based on llvm-2.6 class Type : public AbstractTypeUser { ... private: unsigned AlignID : 7; // insertion to add align information ... protected explicit Type(LLVMContext &C, TypeID id) : ID(id), Abstract(false), SubclassData(0), AlignID(0), RefCount(0), Context(C), ForwardType(0), NumContainedTys(0), ContainedTys(0) { ... void setAlignID(unsigned ID) { AlignID = ID; } inline unsigned getAlignID() const { return AlignID; } ... } llvm file: include/llvm/Type.h based on llvm-2.6 class IntegerType : public DerivedType { ... explicit IntegerType(LLVMContext &C, unsigned NumBits, unsigned AlignID) : DerivedType(C, IntegerTyID) { setSubclassData(NumBits); setAlignID(AlignID); } ... static const IntegerType* get(LLVMContext &C, unsigned NumBits, unsigned AlignID); ... llvm file: lib/VMCore/TypeContext.h based on llvm-2.6 class IntegerValType { IntegerValType(uint16_t numbits, unsigned alignid) : bits(numbits), AlignID(alignid){} static IntegerValType get(const IntegerType *Ty) { return IntegerValType(Ty->getBitWidth(), Ty->getAlignID()); } static IntegerValType get(const IntegerType *Ty, unsigned alignid) { return IntegerValType(Ty->getBitWidth(), alignid); } static unsigned hashTypeStructure(const IntegerType *Ty) { return (unsigned)((Ty->getBitWidth() << 4) | Ty->getAlignID()); } inline bool operator<(const IntegerValType &IVT) const { if (bits == IVT.bits) return AlignID < IVT.AlignID; else return bits < IVT.bits; llvm file: lib/Bitcode/Writer/BitcodeWriter.cpp based on llvm-2.6 static void WriteTypeTable(const ValueEnumerator &VE, BitstreamWriter &Stream) { ... // INTEGER: [width] [alignID] Code = bitc::TYPE_CODE_INTEGER; TypeVals.push_back(cast(T)->getBitWidth()); TypeVals.push_back(cast(T)->getAlignID()); llvm file: lib/Bitcode/Reader/BitcodeReader.cpp based on llvm-2.6 bool BitcodeReader::ParseTypeTable() { ... case bitc::TYPE_CODE_INTEGER: // INTEGER: [width] if (Record.size() < 1) return Error("Invalid Integer type record"); ResultTy = IntegerType::get(Context, Record[0], Record[1]); llvm file: include/llvm/Constants.h based on llvm-2.6 class ConstantInt : public Constant { ... static Constant* get(const Type* Ty, uint64_t V, bool isSigned, unsigned AlignID); static ConstantInt* get(const IntegerType* Ty, uint64_t V, bool isSigned, unsigned AlignID); static ConstantInt* get(LLVMContext &Context, const APInt& V, unsigned AlignID); static ConstantInt* get(const IntegerType* Ty, const StringRef& Str, uint8_t radix, unsigned AlignID); static Constant* get(const Type* Ty, const APInt& V, unsigned AlignID); ... llvm file: lib/VMCore/Constants.cpp based on llvm-2.6 ConstantInt *ConstantInt::get(LLVMContext &Context, const APInt& V, unsigned AlignID) { // Get the corresponding integer type for the bit width of the value. const IntegerType *ITy = IntegerType::get(Context, V.getBitWidth(), AlignID); ... llvm file: lib/VMCore/AsmWriter.cpp based on llvm-2.6 void TypePrinting::CalcTypeName(const Type *Ty, SmallVectorImpl &TypeStack, raw_ostream &OS, bool IgnoreTopLevelName) { ... OS << '('; switch (cast(Ty)->getAlignID()) { default: //assert(0 && "In OVM Unsupported Align ID"); break; case Type::UndefAlignID: break; case Type::CharAlignID: OS << "char"; break; case Type::UCharAlignID: OS << "uchar"; break; case Type::ShortAlignID: OS << "short"; ... There are more modifed files and modified code to make modified IR. Type information with align information like above code cause a lot of errors on general llvm operations. (For example, unique IntegerType on IntegerTypes TypeMap is decided by bitwidth, so equality of Integer types on current llvm assumes Integer Types with same bitwidth and a lot of passes use this assumption.) I agree to add align information to type information because we sometimes need to know original type. (i3 can be char 3bit or short 3bit or int 3bit or long 3bit) What do you think about i3(int) shape? --> i3(alignID) Thanks, Jin-Gu Kang ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Renato Golin [renato.golin at arm.com] Sent: Wednesday, February 16, 2011 3:09 AM To: LLVM Developers Mailing List Subject: [LLVMdev] Structure Types and ABI sizes Hi all, We're hitting some walls here when generating the correct structure layout for specific C++ ABI requirements, and I was wondering how much StructLayout could help. For instance, the ABI has some complicated rules on the size of derived classes (http://www.codesourcery.com/public/cxx-abi/abi.html#class-types) and LLVM struct type cannot reflect that in full. Example: // CHECK: %struct.I = type { i32, i8 } struct I { int a; char b; }; // CHECK: %struct.J = type { [8 x i8], i8, [3 x i8] } struct J : I { char c; }; What happens here is that "c" is placed in the base's tail padding and there are three bytes padding because of the alignment. The main problem with this is that, by changing the member (that should be a structure) to an array, the alignment is lost. As LLVM types don't have explicit alignment in themselves, it's impossible to recover that information later and we need to make sure that every single use of that field gets the correct alignment. Furthermore, I wonder if that wouldn't impact some optimizations that take types into account (as Chris has just replied in the vector discussion)... Not sure... So, I'm not proposing to have alignment in types nor to make LLVM struct types conform to a specific ABI of a specific language, I'm just saying that there should be a cleaner way... Very much like the union type and bitfields, structure size and alignment problems can be very hairy. Simplifying the IR and leaving all decisions to the back-end can be a daunting task, but leaving the front-end to decide on sizes and alignment is maybe not the best alternative. StructLayout already knows a few things about structures (like calculating the offset based on the type's alignment) but it's ignorant regarding specific language decisions and ABIs. We could attach some information regarding the language that is being compiled so the back-end could make some informed choices on how to deal with structures/unions/bitfields and have less hacks in the front-end. I understand that cross-compilation between languages would break that assumption, unless the IR has some kind of flags on it stating the lang/abi used... but I know very few people like adding information to the IR... :/ Any pointers on how to solve this issue in a better way other than bloating the front-end? -- cheers, --renato _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From viridia at gmail.com Tue Feb 15 21:17:02 2011 From: viridia at gmail.com (Talin) Date: Tue, 15 Feb 2011 19:17:02 -0800 Subject: [LLVMdev] improving constant/type uniquing In-Reply-To: <42E3EB32-50B6-47E5-A8CC-7239BF6BDC9E@apple.com> References: <22B37424-EC2D-46CE-803B-0838C4A291B6@apple.com> <8D33B08D-5779-49BF-B260-0D56E65D73C4@apple.com> <42E3EB32-50B6-47E5-A8CC-7239BF6BDC9E@apple.com> Message-ID: On Tue, Feb 15, 2011 at 5:21 PM, Chris Lattner wrote: > > > On Feb 14, 2011, at 9:49 AM, Talin wrote: > > A few additional thoughts on PR1210: > > I can think of three approaches to addressing this issue. The first > approach is the one outlined in PR1210, which is to have the key have > enough knowledge of the internals of the Type to be able to use the internal > type array as the data for the key. > > The second approach is similar, which is to factor out the type array as a > separate, immutable object which is shared by both the key and the type > object. That is, you first create the type array, use that to look up the > type, and if it doesn't find it, clone the type array and use it to > construct a new type object, then use the same type array as the key. > > > This is effectively what FoldingSet does. The actual bits are stored in > the type if it exists. If it doesn't exist, the input vector of element > types is hashed by the profiling function, and then the hash value is looked > up. If there is no match, a type is created. The profile is designed to > typically live on the stack to avoid a heap allocation. > > Note that you can't use the same type array that you used for the lookup, > because otherwise the get-or-insert function would sometimes have to take > ownership of the type array depending on whether the type existed or not, > which would be confusing. > > > Right: the idea is that a lookup (which hits an already created value) > should not do a heap allocation. > > Another way around the ownership problem is to allocate all type arrays as > part of the memory pool associated with the LLVMContext, and then 'intern' > the type arrays so that they can be compared via pointer rather than by > value. The type arrays go away when the context does, so you don't have to > worry about who is responsible for freeing it. The downside is that you now > have to do two hash lookups for the type object's get-or-create method. > > > I don't really understand what you mean by this. You still need to hash on > the identity of the type and the subclass of type still needs to have > accessors for its elements. > > I'll try to explain it a different way. Imagine you have a single folding set, independent of any type subclass, which takes as input an array of types (the key), and returns a pointer to an immutable vector or tuple of those types - much like an interned string. That pointer can then be used as a key to get a StructType or a FunctionType or any other type which has more than one type parameter, and all derived types now represent their type parameters as a single pointer, either to a type or to a tuple. It also means that type "{ int; int; int; }" shares the same type parameter array as "int (int, int)", both pointing to a tuple of 3 ints. Each subtype still has its own hash map that enables lookup of a subtype via it's type parameters, however there's no need to dereference the tuple pointer during this second lookup, you only need to compare the two pointers, not what they point to. I'm not certain that this approach has any real benefit, however, given the normal usage patterns of looking up types in LLVM. I was merely including it for the sake of completeness... since normally subtypes are interned anyway, and since most subtypes take only a single type parameter, the benefits of separately interning the type parameter array probably aren't worth the additional complexity. -Chris > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110215/5ad168a8/attachment.html From wendling at apple.com Tue Feb 15 23:34:34 2011 From: wendling at apple.com (Bill Wendling) Date: Tue, 15 Feb 2011 21:34:34 -0800 Subject: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule Message-ID: <8A8DC54A-1F82-4857-AA49-DDE3467232D2@apple.com> Hello LLVMers! Amazingly, it's been 4 months since the release of LLVM 2.8. And so much has changed since then! April will be six months since the previous release, so it's time to start thinking about LLVM 2.9! Here is a tentative schedule for the release (and, of course, our schedules never slip): March 6th - Branch for release. March 7th-14th - Testing Phase 1 March 14th-21st - Preparation for Phase 2 (fixing bugs, merging patches) March 21st-28th - Testing Phase 2 March 28th-April 3rd - Preparation for release April 3rd - Release So there are roughly three weeks to finish off any new features for LLVM 2.9. After Phase 1 starts, no new features will be accepted. After Phase 2 starts, all new features must be completed; only critical bug fixes will be accepted after Phase 2. As we get closer towards March 6th, I'll send out further announcements warning people of the impending branching and further outlining our patch-acceptance policy. Please let me know if you have any comments or concerns about this schedule. Share and enjoy! -bw From baldrick at free.fr Wed Feb 16 03:40:40 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 16 Feb 2011 10:40:40 +0100 Subject: [LLVMdev] Possible LLVM or DragonEgg bug In-Reply-To: <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41AB@UOS-CL-EX7-L4.soton.ac.uk> References: <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41AB@UOS-CL-EX7-L4.soton.ac.uk> Message-ID: <4D5B9B98.5040401@free.fr> Hi, > I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): I can reproduce this - investigating. Ciao, Duncan. From renato.golin at arm.com Wed Feb 16 03:53:40 2011 From: renato.golin at arm.com (Renato Golin) Date: Wed, 16 Feb 2011 09:53:40 +0000 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: <0909E1A1-B757-4A4D-A102-92468C6EF468@apple.com> References: <0909E1A1-B757-4A4D-A102-92468C6EF468@apple.com> Message-ID: On 16 February 2011 01:14, John McCall wrote: > I think the obvious solution here is to use packed structs when the layout of an type as a base class would substantially differ from its layout as a complete object. ?This loses some alignment information, but frontends need to be aggressive about providing alignment on loads/stores/etc. anyway. ?I'm actually thinking of changing clang to do this. That's actually a good idea... To have the normal structure when you use the base directly and the packed version to be embedded into derived types. I managed to fix all structure size problems I've seen, but if packed structs work the same way, it'll be much more elegant. Thanks John! -- cheers, --renato From baldrick at free.fr Wed Feb 16 11:14:06 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 16 Feb 2011 18:14:06 +0100 Subject: [LLVMdev] Possible LLVM or DragonEgg bug In-Reply-To: <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41AB@UOS-CL-EX7-L4.soton.ac.uk> References: <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41AB@UOS-CL-EX7-L4.soton.ac.uk> Message-ID: <4D5C05DE.7020204@free.fr> This is hopefully fixed in the latest version of dragonegg. Thanks for reporting it! Ciao, Duncan. On 15/02/11 20:54, sabaliauskas g. (gs5g08) wrote: > I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): > > /usr/lib64/ccache/c++ -Wall -Wno-long-long -pthread -ffunction-sections -D_GLIBCXX_PARALLEL -fopenmp -D__STDC_CONSTANT_MACROS -fplugin=/home/John/Documents/Project/DragonEgg/dragonegg/dragonegg.so -O3 -DNDEBUG -fomit-frame-pointer -O3 -ffast-math -mmmx -msse -msse2 -msse3 -DNDEBUG CMakeFiles/createsamples.dir/createsamples.o -o ../../bin/opencv_createsamples -rdynamic ../../lib/libcxcore.so.2.0.0 ../../lib/libcv.so.2.0.0 ../../lib/libcvhaartraining.a ../../lib/libhighgui.so.2.0.0 ../../lib/libcv.so.2.0.0 ../../lib/libcxcore.so.2.0.0 ../../3rdparty/lib/libopencv_lapack.a ../../3rdparty/lib/libzlib.a ../../3rdparty/lib/libflann.a -ldl -lm -lpthread -lrt -lgomp -Wl,-rpath,/home/Gytis/Documents/Project/OpenCV/new2/OpenCV-2.0.0/bin/lib: > ../../lib/libcv.so.2.0.0: undefined reference to `_mm_cvtsd_si32(double __vector)' > collect2: ld returned 1 exit status > > As I understand the linker can not find intrinsic SSE2 function "_mm_cvtsd_si32" while trying to link "opencv_createsamples" executable to "libcv.so.2.0.0". > > If compiled with the same setup but with OpenMP disabled(i.e. no "-fopenmp" flag) compilation succeeds with no errors. > > I would be very grateful if any body could tell me the cause of this problem or at least give me some hints where to start looking for it. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From peterl95124 at sbcglobal.net Wed Feb 16 12:20:22 2011 From: peterl95124 at sbcglobal.net (Peter Lawrence) Date: Wed, 16 Feb 2011 10:20:22 -0800 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13 In-Reply-To: References: Message-ID: <59AD32AC-0E8B-4395-9239-A6D6E3E4DE1B@sbcglobal.net> Dave, > Unifying array and vector and generalizing the result would open a lot > of optimization opportunities. you would be piling an incomplete optimization on top of a pile of already incomplete optimizations... Vectorization in Fortran is already a "hard" problem, requiring alias analysis (always an incomplete and inaccurate (conservative) analysis) and loop-carried array subscript dependence analysis (which is equivalent to the Diophantine Equation problem in Mathematics which is in general not solvable, so you end up again with incomplete and inaccurate (conservative) analysis). Doing this in C (without first class array/ matrix types), and with even more alias analysis issues, makes it more problematic. The final straw with all these multimedia instruction sets is that they require large alignment on their "packed array" data types (even Intel which started out not requiring alignment with MMX (though unaligned data invoked hugh performance penalties), did evolve with SSE to what everyone else requires). data alignment can (and should!) be analyzed within the same algorithms that do alias analysis, and the analysis has the same inherent limitations. The problem is that in real world applications it is typical for array data slices (ie sections of arrays that are passed to subroutines to be processed) to be unaligned, even if the array base address is aligned, the bounds of the section being processed are in general not aligned. You end up with wanting to clone your algorithm kernel for various incoming alignments (just like memcpy, memcmp, etc are often cloned internally for various relative alignments of the incoming arguments), but with a kernel accessing N different arrays you end up needing 2**N clones, which in general is an impractical code-explosion. The reason I object to the use of "vector" and "simd" when describing these "packed data" multimedia instruction sets is that in practical reality the traditional vectorization optimization technology just does not apply. You can always come up with geewiz examples where it does, but you cannot make it work in the general case. No matter what fancy data shuffling/permuting/inserting/extracting instructions get added to MMX/SSE/SSE2, they will still not solve the data alignment problem, so the instruction sets remain incompatible with "traditional vector machines" where there was always one-data-item-per-HW-register and there was never any alignment issue. best, Peter Lawrence. On Feb 15, 2011, at 8:38 AM, David A. Greene wrote: > Peter Lawrence writes: > >> Andrew, your response highlights a naming problem in LLVM, which is >> that "array" and "vector" mean the same thing in normal computer >> language and compiler theory usage, so it is inconvenient and >> misleading within LLVM to give one a very specific meaning that is >> different from the other.... > > I think any sort of separation at all is counterproductive. The > existing array/vector split is artificial. It would be better to have > one array-like type and allow a reasonable set of operations on it. > Target lowering should take care of legality issues. For best > performance various transformation patterns will want to know about > the > target but that's true independent of vector types. Scalar optimizers > want to know about targets too. > >> As far as I am aware not a single one of any of the above types of >> instruction sets allows the "subscripting" of packed data within a >> register > > Given what we know of Larrabee and speculating that the "Knights" > family > is likely a derivative of it, it's safe to assume that future Intel > architectures will be much more like traditional vector machines. > That > means gather/scatter, element indexing, etc. The existing PINSR/PEXTR > and shuffle instructions already allow a degree of element indexing. > Note that the existing LLVM vector types already have insert/extract > operators. > > Unifying array and vector and generalizing the result would open a lot > of optimization opportunities. > > -Dave From sebastian.redl at getdesigned.at Wed Feb 16 05:57:28 2011 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Wed, 16 Feb 2011 12:57:28 +0100 Subject: [LLVMdev] C++ Mangled Names In-Reply-To: <701AB907-0B82-4535-BA52-6F20146EF0CC@vandevoorde.com> References: <4D5A3508.1040403@illinois.edu> <701AB907-0B82-4535-BA52-6F20146EF0CC@vandevoorde.com> Message-ID: <4CA7A0A5-C2E9-47E4-B3A5-BE42B01B1DCB@getdesigned.at> On 15.02.2011, at 16:41, David Vandevoorde wrote: > > On Feb 15, 2011, at 3:10 AM, Patrick Simmons wrote: > >> I have encountered a need for manually generating the mangled name of an >> arbitrary C++ function. The only way I currently know how to do this is >> to generate a dummy C++ source file, compile it, and look at the >> output. This approach is so ugly that I would like for it never to see >> the light of day. The c++filt tool generates demangled C++ names given >> the mangled ones, which is the opposite of what I want to do. Does >> anyone know how to "run c++filt in reverse"? > > It's not so simple. Assuming you limit yourself to the ABI used by the GNU compiler, there is still an awful lot of information needed in the most general case. See: > > http://www.codesourcery.com/public/cxx-abi/abi.html#mangling > > for the mangling scheme (although the actual GCC implementation sometimes deviates from that for less common cases). > > If you're only dealing with non-local named functions and types plus ordinary type composition and exclude function templates (or at least, function templates with dependent expressions in the signature), it's probably not too hard (i.e., just a day or a few days work) to code up a mangler. If more is needed (local types, decltype, lambdas, etc.), it gets messier quite quickly. > > Daveed Clang contains a mangler. You just have to extract the code into a standalone tool. Sebastian From damien.llvm at gmail.com Wed Feb 16 13:08:31 2011 From: damien.llvm at gmail.com (Damien Vincent) Date: Wed, 16 Feb 2011 11:08:31 -0800 Subject: [LLVMdev] verbosity while invoking clang Message-ID: I am working on implementing a new target for llvm. So far (to make debugging easier), I was compiling a C code into 2 steps: 1) generate the llvm file: clang -ccc-host-triple mytarget -emit-llvm -S myfile.c -o myfile.ll 2) generate the assembly file using llc -march=mytarget myfile.ll Sometimes, I add some verbosity for the 2nd command like "-print-after-all". Now, I'd like to compile a C code in 1 step using clang (clang -ccc-host-triple mytarge -S myfile.c -o myfile.s) Is there a way to have options like "print-after-all" with clang ? (that might be a newbie question but I didn't find a clear spec of what parameters can be given to clang...). Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110216/b141426e/attachment.html From wendling at apple.com Wed Feb 16 14:59:49 2011 From: wendling at apple.com (Bill Wendling) Date: Wed, 16 Feb 2011 12:59:49 -0800 Subject: [LLVMdev] verbosity while invoking clang In-Reply-To: References: Message-ID: On Feb 16, 2011, at 11:08 AM, Damien Vincent wrote: > I am working on implementing a new target for llvm. > So far (to make debugging easier), I was compiling a C code into 2 steps: > 1) generate the llvm file: > clang -ccc-host-triple mytarget -emit-llvm -S myfile.c -o myfile.ll > 2) generate the assembly file using > llc -march=mytarget myfile.ll > > Sometimes, I add some verbosity for the 2nd command like "-print-after-all". > Now, I'd like to compile a C code in 1 step using clang (clang -ccc-host-triple mytarge -S myfile.c -o myfile.s) > Is there a way to have options like "print-after-all" with clang ? (that might be a newbie question but I didn't find a clear spec of what parameters can be given to clang...). > Hi Damien, I think you might want to use the "-mllvm" flag: $ clang -ccc-host-triple mytarge -S myfile.c -o myfile.s -mllvm -print-after-all -bw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110216/cb8719b6/attachment.html From j.wilhelmy at arcor.de Wed Feb 16 15:47:57 2011 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Wed, 16 Feb 2011 22:47:57 +0100 Subject: [LLVMdev] bytecode cache Message-ID: <4D5C460D.6010908@arcor.de> Hi! Is it possible to implement a byte code cache for a llvm-jit? This way the compile time occurs only once and the next time the compiled machine code can simply be loaded from disk. Of course care has to be taken with function pointers that are used as constants since they may change on the next run. -Jochen From damien.llvm at gmail.com Wed Feb 16 16:13:27 2011 From: damien.llvm at gmail.com (Damien Vincent) Date: Wed, 16 Feb 2011 14:13:27 -0800 Subject: [LLVMdev] verbosity while invoking clang In-Reply-To: References: Message-ID: Thank you, that's exactly what I was looking for. On Wed, Feb 16, 2011 at 12:59 PM, Bill Wendling wrote: > On Feb 16, 2011, at 11:08 AM, Damien Vincent wrote: > > I am working on implementing a new target for llvm. > So far (to make debugging easier), I was compiling a C code into 2 steps: > 1) generate the llvm file: > clang -ccc-host-triple mytarget -emit-llvm -S myfile.c -o myfile.ll > 2) generate the assembly file using > llc -march=mytarget myfile.ll > > Sometimes, I add some verbosity for the 2nd command like > "-print-after-all". > Now, I'd like to compile a C code in 1 step using clang (clang > -ccc-host-triple mytarge -S myfile.c -o myfile.s) > Is there a way to have options like "print-after-all" with clang ? (that > might be a newbie question but I didn't find a clear spec of what parameters > can be given to clang...). > > Hi Damien, > > I think you might want to use the "-mllvm" flag: > > $ clang -ccc-host-triple mytarge -S myfile.c -o myfile.s -mllvm > -print-after-all > > -bw > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110216/c5abcf2c/attachment.html From viridia at gmail.com Wed Feb 16 18:51:15 2011 From: viridia at gmail.com (Talin) Date: Wed, 16 Feb 2011 16:51:15 -0800 Subject: [LLVMdev] llvm.gcroot suggestion Message-ID: I think I'm one of the few people actually using LLVM's support for garbage collection, and so far I've found it very difficult to generate code that uses llvm.gcroot() correctly. In the current scheme, it is the frontend's responsibility to insure that any intermediate SSA values containing references to garbage collectible objects are copied to stack variables so that the GC strategy can calculate offsets for them. It is also the frontend's responsibility to reload those values after a sync point, since the collector may have moved them around. An additional chore is creating all of the allocas for those roots, which have to be in the first block of the function (because that's where allocas go according to my understanding of the rules of IR.) What this means is that the frontend is forced to generate very inefficient IR, with dozens of alloca slots at the beginning of the function, each marked as a root. It also has to initialize each of these roots to a known value, even if the root is only "live" for a very small part of the CFG. This is because currently there's no way for the frontend to tell LLVM that a given root has a limited lifespan (since calls to llvm.gcroot also have to be in the first block), and so you have to take a conservative approach and treat every root as if it were live for the entire function. It seems to me that "gc-rootness" should not be an aspect of an alloca, as it currently is now, but rather an aspect of a Value, similar to the way llvm.dbg.value() works. Let's imagine a new intrinsic, llvm.gcvalue(), which takes as its arguments a Value and a metadata pointer, and returns that same value as its result. The frontend can "wrap" any value, of any type, with llvm.gcvalue(), which is a signal to LLVM that this value is a garbage collection root. It would then be the responsibility of LLVM's code generator (or possibly some lowering pass) to insure that this value lives on the stack during sync points, and is reloaded after a sync point if it is still needed. During a sync point, these values would be treated exactly the way llvm.gcroot works today - that is, they live on the stack, and the GCStrategy gets passed a list of stack offsets and metadata pointers. The main difference is that only the values that are actually 'live' during the sync point are lowered from SSA values to allocas. This approach offers a bunch of advantages that I can think of: - LLVM knows much more about the liveness of values than the frontend does, and could compute a much more optimal and minimal stack map for each sync point. That is, two variables whose lifetimes do not overlap can use the same stack location for their roots to be stored in, and the stack maps generated by the GCStrategy would reflect this. - If at some future time LLVM supports register maps for garbage collection, you would not have to update your frontend. Since we're marking values, not stack slots, the frontend doesn't have to care where the variable is stored, so all frontends can take advantage of improvements in the representation of stack maps. - Writing frontends gets a lot easier, since the frontend is no longer responsible for generating and initializing allocas for every root. It also means a lot fewer opportunities for generating incorrect code. What do you think? -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110216/b6ed8c13/attachment.html From gs5g08 at ecs.soton.ac.uk Wed Feb 16 19:27:12 2011 From: gs5g08 at ecs.soton.ac.uk (sabaliauskas g. (gs5g08)) Date: Thu, 17 Feb 2011 01:27:12 +0000 Subject: [LLVMdev] Possible LLVM or DragonEgg bug In-Reply-To: <4D5C05DE.7020204@free.fr> References: <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41AB@UOS-CL-EX7-L4.soton.ac.uk>, <4D5C05DE.7020204@free.fr> Message-ID: <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41B0@UOS-CL-EX7-L4.soton.ac.uk> I have downloaded and compiled the latest versions of LLVM and DragonEgg from SVN, but I still seem to get this same problem. I am using 64-bit Linux OS maybe the fix was only for 32-bit OS'es? ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands [baldrick at free.fr] Sent: Wednesday, February 16, 2011 5:14 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Possible LLVM or DragonEgg bug This is hopefully fixed in the latest version of dragonegg. Thanks for reporting it! Ciao, Duncan. On 15/02/11 20:54, sabaliauskas g. (gs5g08) wrote: > I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): > > /usr/lib64/ccache/c++ -Wall -Wno-long-long -pthread -ffunction-sections -D_GLIBCXX_PARALLEL -fopenmp -D__STDC_CONSTANT_MACROS -fplugin=/home/John/Documents/Project/DragonEgg/dragonegg/dragonegg.so -O3 -DNDEBUG -fomit-frame-pointer -O3 -ffast-math -mmmx -msse -msse2 -msse3 -DNDEBUG CMakeFiles/createsamples.dir/createsamples.o -o ../../bin/opencv_createsamples -rdynamic ../../lib/libcxcore.so.2.0.0 ../../lib/libcv.so.2.0.0 ../../lib/libcvhaartraining.a ../../lib/libhighgui.so.2.0.0 ../../lib/libcv.so.2.0.0 ../../lib/libcxcore.so.2.0.0 ../../3rdparty/lib/libopencv_lapack.a ../../3rdparty/lib/libzlib.a ../../3rdparty/lib/libflann.a -ldl -lm -lpthread -lrt -lgomp -Wl,-rpath,/home/Gytis/Documents/Project/OpenCV/new2/OpenCV-2.0.0/bin/lib: > ../../lib/libcv.so.2.0.0: undefined reference to `_mm_cvtsd_si32(double __vector)' > collect2: ld returned 1 exit status > > As I understand the linker can not find intrinsic SSE2 function "_mm_cvtsd_si32" while trying to link "opencv_createsamples" executable to "libcv.so.2.0.0". > > If compiled with the same setup but with OpenMP disabled(i.e. no "-fopenmp" flag) compilation succeeds with no errors. > > I would be very grateful if any body could tell me the cause of this problem or at least give me some hints where to start looking for it. > > > _______________________________________________ > 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 baldrick at free.fr Thu Feb 17 01:31:48 2011 From: baldrick at free.fr (Duncan Sands) Date: Thu, 17 Feb 2011 08:31:48 +0100 Subject: [LLVMdev] Possible LLVM or DragonEgg bug In-Reply-To: <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41B0@UOS-CL-EX7-L4.soton.ac.uk> References: <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41AB@UOS-CL-EX7-L4.soton.ac.uk>, <4D5C05DE.7020204@free.fr> <13B0DE32CCA0C1499BA638270A8F90C1B6BCFA41B0@UOS-CL-EX7-L4.soton.ac.uk> Message-ID: <4D5CCEE4.60704@free.fr> > I have downloaded and compiled the latest versions of LLVM and DragonEgg from SVN, but I still seem to get this same problem. I am using 64-bit Linux OS maybe the fix was only for 32-bit OS'es? I am also using 64-bit linux, and the patch I applied fixed this issue. That said, OpenCV still didn't compile but for a different reason, which was nothing to do with dragonegg (i.e. it also failed with plain gcc). Are you sure you configured OpenCV to use the new plugin not the old? Ciao, Duncan. > ________________________________________ > From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands [baldrick at free.fr] > Sent: Wednesday, February 16, 2011 5:14 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Possible LLVM or DragonEgg bug > > This is hopefully fixed in the latest version of dragonegg. Thanks for > reporting it! > > Ciao, Duncan. > > On 15/02/11 20:54, sabaliauskas g. (gs5g08) wrote: >> I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): >> >> /usr/lib64/ccache/c++ -Wall -Wno-long-long -pthread -ffunction-sections -D_GLIBCXX_PARALLEL -fopenmp -D__STDC_CONSTANT_MACROS -fplugin=/home/John/Documents/Project/DragonEgg/dragonegg/dragonegg.so -O3 -DNDEBUG -fomit-frame-pointer -O3 -ffast-math -mmmx -msse -msse2 -msse3 -DNDEBUG CMakeFiles/createsamples.dir/createsamples.o -o ../../bin/opencv_createsamples -rdynamic ../../lib/libcxcore.so.2.0.0 ../../lib/libcv.so.2.0.0 ../../lib/libcvhaartraining.a ../../lib/libhighgui.so.2.0.0 ../../lib/libcv.so.2.0.0 ../../lib/libcxcore.so.2.0.0 ../../3rdparty/lib/libopencv_lapack.a ../../3rdparty/lib/libzlib.a ../../3rdparty/lib/libflann.a -ldl -lm -lpthread -lrt -lgomp -Wl,-rpath,/home/Gytis/Documents/Project/OpenCV/new2/OpenCV-2.0.0/bin/lib: >> ../../lib/libcv.so.2.0.0: undefined reference to `_mm_cvtsd_si32(double __vector)' >> collect2: ld returned 1 exit status >> >> As I understand the linker can not find intrinsic SSE2 function "_mm_cvtsd_si32" while trying to link "opencv_createsamples" executable to "libcv.so.2.0.0". >> >> If compiled with the same setup but with OpenMP disabled(i.e. no "-fopenmp" flag) compilation succeeds with no errors. >> >> I would be very grateful if any body could tell me the cause of this problem or at least give me some hints where to start looking for it. >> >> >> _______________________________________________ >> 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 cessu at iki.fi Thu Feb 17 02:03:52 2011 From: cessu at iki.fi (Kenneth Oksanen) Date: Thu, 17 Feb 2011 10:03:52 +0200 Subject: [LLVMdev] llvm.gcroot suggestion In-Reply-To: References: Message-ID: <1297929832.13089.14.camel@salamander> On Wed, 2011-02-16 at 16:51 -0800, Talin wrote: > [..] the frontend is forced to generate very inefficient IR, with > dozens of alloca slots at the beginning of the function, each marked > as a root. It also has to initialize each of these roots to a known > value, even if the root is only "live" for a very small part of the > CFG. This is because currently there's no way for the frontend to tell > LLVM that a given root has a limited lifespan (since calls to > llvm.gcroot also have to be in the first block), and so you have to > take a conservative approach and treat every root as if it were live > for the entire function. [..] I can confirm this observation. The generated code is clearly suboptimal, and it gets even worse if one tries to do live-precise garbage collection where the gcroot'ed alloca-slot no longer used must be explicitly assigned a null value. On my list processing micro-benchmarks these effects incur a performance hit of approximately 20%-30% compared to a manually crafted asm code, and that is including the overhead of the garbage collector. > It seems to me that "gc-rootness" should not be an aspect of an > alloca, as it currently is now, but rather an aspect of a Value [..] I'ld second that. -- ; mailto:cessu at iki.fi http://www.iki.fi/~cessu http://cessu.blogspot.com ((lambda(a) (a a((lambda(a)(lambda()(set! a(+ a 1))a))1)))(lambda(a c) ((lambda(b) (newline)(write b)(a a((lambda(c)(lambda()(c c)))(lambda(a) ((lambda(c) (if(=(modulo c b)0)(a a)c))(c))))))(c)))) ; Scheme me! From null.function at gmail.com Thu Feb 17 12:06:03 2011 From: null.function at gmail.com (nullnull) Date: Thu, 17 Feb 2011 13:06:03 -0500 Subject: [LLVMdev] Getting load/store byte size Message-ID: I'm instrumenting memory loads and stores in a LLVM module pass. In this work, I need to do (1) Getting memory address of the operand, (Looks I've done correctly) (2) Getting memory read/write size, (Question) (3) Location id of the load/store instruction. (Easy, I've done) For example, say that I'm reading a local variable 'a': %1 = load i32* %a, align 4 I need to know the address of the variable 'a' and the size. Of course, memory loads/stores could be from general GEP or global variables. Getting the address was easily doable by using "PtrToIntInst(load_inst->getPointerOperand(), ...)". However, getting load/store size wasn't that straight forward. In this example, it should be four bytes. I tried to get the Type* from the getPointerOperand() and tried to retrieve the size of the type, but failed. Question: [1] How can I retrieve the read/write size of load/store instruction? I have another question. If I can get the size, then what would be the maximum size? Obviously, 1 ~ 8 bytes for built-in types, but wondering even the larger size could be obtained. I suspect a vector load instruction could load up to 32 bytes (= 256 bits, in case of x86 AVX). Question: [2] What would be the maximum size of load/store operand? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110217/4c409f59/attachment.html From baldrick at free.fr Thu Feb 17 12:31:20 2011 From: baldrick at free.fr (Duncan Sands) Date: Thu, 17 Feb 2011 19:31:20 +0100 Subject: [LLVMdev] Getting load/store byte size In-Reply-To: References: Message-ID: <4D5D6978.9020006@free.fr> Hi nullnull, > I'm instrumenting memory loads and stores in a LLVM module pass. In this work, I > need to do > (1) Getting memory address of the operand, (Looks I've done correctly) > (2) Getting memory read/write size, (Question) use getTypeStoreSize defined in TargetData. Ciao, Duncan. From ramosian.glider at gmail.com Thu Feb 17 12:57:32 2011 From: ramosian.glider at gmail.com (Alexander Potapenko) Date: Thu, 17 Feb 2011 21:57:32 +0300 Subject: [LLVMdev] Getting load/store byte size In-Reply-To: References: Message-ID: You can take a look at http://code.google.com/p/data-race-test/source/browse/trunk/llvm/opt/ThreadSanitizer/ThreadSanitizer.cpp, where I do practically the same. The routine that obtains the size is getMopPtrSize(), getting the addresses is done in instrumentMop(). Alex On Thu, Feb 17, 2011 at 9:06 PM, nullnull wrote: > I'm instrumenting memory loads and stores in a LLVM module pass. In this > work, I need to do > (1) Getting memory address of the operand, (Looks I've done correctly) > (2) Getting memory read/write size, (Question) > (3) Location id of the load/store instruction. (Easy, I've done) > > For example, say that I'm reading a local variable 'a': > > %1 = load i32* %a, align 4 > > I need to know the address of the variable 'a' and the size. Of course, > memory loads/stores could be from general GEP or global variables. > > Getting the address was easily doable by using > "PtrToIntInst(load_inst->getPointerOperand(), ...)". However, getting > load/store size wasn't that straight forward. In this example, it should be > four bytes. I tried to get the Type* from the getPointerOperand() and tried > to retrieve the size of the type, but failed. > > Question: > [1] How can I retrieve the read/write size of load/store instruction? > > > I have another question. If I can get the size, then what would be the > maximum size? Obviously, 1 ~ 8 bytes for built-in types, but wondering even > the larger size could be obtained. I suspect a vector load instruction could > load up to 32 bytes (= 256 bits, in case of x86 AVX). > > Question: > [2] What would be the maximum size of load/store operand? > > > Thank you! From vadve at illinois.edu Thu Feb 17 13:31:25 2011 From: vadve at illinois.edu (Adve, Vikram Sadanand) Date: Thu, 17 Feb 2011 13:31:25 -0600 Subject: [LLVMdev] bytecode cache In-Reply-To: References: Message-ID: It is possible and, since LLVM doesn't support self-modifying code at the IR level, this should not be particularly difficult. It just hasn't been high on anybody's priority list so far. --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Feb 17, 2011, at 12:00 PM, wrote: > Message: 5 > Date: Wed, 16 Feb 2011 22:47:57 +0100 > From: Jochen Wilhelmy > Subject: [LLVMdev] bytecode cache > To: "llvmdev at cs.uiuc.edu" > Message-ID: <4D5C460D.6010908 at arcor.de> > Content-Type: text/plain; charset=ISO-8859-15; format=flowed > > Hi! > > Is it possible to implement a byte code cache for a llvm-jit? > This way the compile time occurs only once and the next time > the compiled machine code can simply be loaded from disk. > Of course care has to be taken with function pointers that are > used as constants since they may change on the next run. > > -Jochen From housel at acm.org Thu Feb 17 14:04:55 2011 From: housel at acm.org (Peter Housel) Date: Thu, 17 Feb 2011 12:04:55 -0800 Subject: [LLVMdev] llvm.gcroot suggestion In-Reply-To: References: Message-ID: <1297973095.2237.16.camel@eng-phousel-ubuntu> On Wed, 2011-02-16 at 16:51 -0800, Talin wrote: > > This approach offers a bunch of advantages that I can think of: > * LLVM knows much more about the liveness of values than the > frontend does, and could compute a much more optimal and > minimal stack map for each sync point. That is, two variables > whose lifetimes do not overlap can use the same stack location > for their roots to be stored in, and the stack maps generated > by the GCStrategy would reflect this. > * If at some future time LLVM supports register maps for garbage > collection, you would not have to update your frontend. Since > we're marking values, not stack slots, the frontend doesn't > have to care where the variable is stored, so all frontends > can take advantage of improvements in the representation of > stack maps. > * Writing frontends gets a lot easier, since the frontend is no > longer responsible for generating and initializing allocas for > every root. It also means a lot fewer opportunities for > generating incorrect code. > What do you think? I can't speak to the implementation, but as a potential user of this facility I think this approach is definitely preferable to the current one. The IR that the Open Dylan compiler is generating LLVM code from is almost SSA already, and I don't want to allocate stack slots for everything just for GC maps. -Peter S. Housel- housel at acm.org From reid.kleckner at gmail.com Thu Feb 17 14:50:27 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Thu, 17 Feb 2011 15:50:27 -0500 Subject: [LLVMdev] bytecode cache In-Reply-To: <4D5C460D.6010908@arcor.de> References: <4D5C460D.6010908@arcor.de> Message-ID: I think the way to do this is to generate a shared library which you reload. Shared libraries already handle the problems of PIC code and relocatable globals, so I think it would be best to leverage that. However, there's obviously some issues here. Presumably you don't have all the code up front, or you wouldn't be using a JIT in the first place. I don't think you can update the shlib as you go along, so you'd have to either spit out bitcode or a shlib at process exit (which would be fragile and expensive). If you spit out bitcode, which is probably cheaper and less complicated, you could codegen it (in the background?) to a shlib next time you launch. If you want a persistent code cache that you can update incrementally, I think you'll need to come up with something that looks quite different from LLVM's JIT. Finally, this reminds me of the work done on DynamoRIO to persist application code caches for use between processes and after reloading the app: http://www.burningcutlery.com/derek/docs/procshared-VEE08.pdf They've had to solve some of the same problems. Reid On Wed, Feb 16, 2011 at 4:47 PM, Jochen Wilhelmy wrote: > Hi! > > Is it possible to implement a byte code cache for a llvm-jit? > This way the compile time occurs only once and the next time > the compiled machine code can simply be loaded from disk. > Of course care has to be taken with function pointers that are > used as constants since they may change on the next run. > > -Jochen > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From viridia at gmail.com Thu Feb 17 15:07:00 2011 From: viridia at gmail.com (Talin) Date: Thu, 17 Feb 2011 13:07:00 -0800 Subject: [LLVMdev] llvm.gcroot suggestion In-Reply-To: References: Message-ID: On Wed, Feb 16, 2011 at 4:51 PM, Talin wrote: > I think I'm one of the few people actually using LLVM's support for garbage > collection, and so far I've found it very difficult to generate code that > uses llvm.gcroot() correctly. > > In the current scheme, it is the frontend's responsibility to insure that > any intermediate SSA values containing references to garbage collectible > objects are copied to stack variables so that the GC strategy can calculate > offsets for them. It is also the frontend's responsibility to reload those > values after a sync point, since the collector may have moved them around. > An additional chore is creating all of the allocas for those roots, which > have to be in the first block of the function (because that's where allocas > go according to my understanding of the rules of IR.) > > What this means is that the frontend is forced to generate very inefficient > IR, with dozens of alloca slots at the beginning of the function, each > marked as a root. It also has to initialize each of these roots to a known > value, even if the root is only "live" for a very small part of the CFG. > This is because currently there's no way for the frontend to tell LLVM that > a given root has a limited lifespan (since calls to llvm.gcroot also have to > be in the first block), and so you have to take a conservative approach and > treat every root as if it were live for the entire function. > > It seems to me that "gc-rootness" should not be an aspect of an alloca, as > it currently is now, but rather an aspect of a Value, similar to the way > llvm.dbg.value() works. > > Let's imagine a new intrinsic, llvm.gcvalue(), which takes as its arguments > a Value and a metadata pointer, and returns that same value as its result. > The frontend can "wrap" any value, of any type, with llvm.gcvalue(), which > is a signal to LLVM that this value is a garbage collection root. It would > then be the responsibility of LLVM's code generator (or possibly some > lowering pass) to insure that this value lives on the stack during sync > points, and is reloaded after a sync point if it is still needed. During a > sync point, these values would be treated exactly the way llvm.gcroot works > today - that is, they live on the stack, and the GCStrategy gets passed a > list of stack offsets and metadata pointers. The main difference is that > only the values that are actually 'live' during the sync point are lowered > from SSA values to allocas. > > This approach offers a bunch of advantages that I can think of: > > - LLVM knows much more about the liveness of values than the frontend > does, and could compute a much more optimal and minimal stack map for each > sync point. That is, two variables whose lifetimes do not overlap can use > the same stack location for their roots to be stored in, and the stack maps > generated by the GCStrategy would reflect this. > - If at some future time LLVM supports register maps for garbage > collection, you would not have to update your frontend. Since we're marking > values, not stack slots, the frontend doesn't have to care where the > variable is stored, so all frontends can take advantage of improvements in > the representation of stack maps. > - Writing frontends gets a lot easier, since the frontend is no longer > responsible for generating and initializing allocas for every root. It also > means a lot fewer opportunities for generating incorrect code. > > What do you think? > So a few additional thoughts: I think that it would be best to keep the existing llvm.gcroot() call in addition to having llvm.gvcalue(). llvm.gcroot() would be used for marking allocas as roots, and llvm.gcvalue() would mark SSA values as roots. In fact, if I could go back in time, I would rename them to correspond exactly with the llvm.dbg intrinsics. So in addition to llvm.dbg.declare() and llvm.dbg.value(), we'd also have llvm.gc.declare() and llvm.gc.value(), with analogous uses. Note that it is important that the LLVM GC intrinsics should not assume that the their arguments are pointers, as they could in some cases be structs or arrays that contain pointers. LLVM should make no assumptions about the internal structure of a GC root, that is an issue for the language's GCStrategy pass to worry about - typically the frontend will use the metadata argument to communicate the structure of a root to the GCStrategy. The only thing that LLVM has to guarantee is that during a sync point, it will be possible to associate each live root with an address in memory somewhere. As far as implementation goes, I'm assuming that there would be some pass that converts llvm.gcvalue() intrinsics into llvm.gcroot() intrinsics by temporarily storing the the root into an alloca and then reloading it as needed. (Actually you would probably want something richer than the current llvm.gcroot that allows an explicit begin and end so that information about liveness can be preserved. How about llvm.gc.beginroot() intrinsic to indicate that a given alloca should be considered a root starting at that point in the CFG, and llvm.gc.endroot() to indicate that the specified root no longer needs to be considered a root. This is much better than the current method of assigning NULL to a root, as it accommodates non-pointer roots, and avoids the extra pointer store which is not needed in many cases.) What is unclear to me is exactly when this should occur relative to other passes, but I think what you would want to do is perform optimization and liveness analysis first - thereby eliminating potentially dead roots before they are converted to memory locations. Unfortunately, I can't say too much about this, as I am not a backend person - I know very little about optimization and code generation in general or LLVM's backend passes in particular. There would also need to be some way to tell the code generator not to reload values after a sync point if the collector doesn't require it, such as a mark-and-sweep or other non-copying algorithm. The most straightforward way to handle this would be as an argument to the pass that does the lowering of llvm.gcvalue intrinsics. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110217/d7f12ee5/attachment.html From j.wilhelmy at arcor.de Thu Feb 17 17:30:22 2011 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Fri, 18 Feb 2011 00:30:22 +0100 Subject: [LLVMdev] bytecode cache In-Reply-To: References: <4D5C460D.6010908@arcor.de> Message-ID: <4D5DAF8E.2070205@arcor.de> > I think the way to do this is to generate a shared library which you > reload. Shared libraries already handle the problems of PIC code and > relocatable globals, so I think it would be best to leverage that. yes, I also think that this is the way to go. By the way I always have a complete "module" that is fixed and therefore I don't need to extend the shlib. One problem is how to load the shlib. I'd like to load it by hand and then execute it as e.g. windows lacks real shared libs. The same as a jit does but just loading the precompiled code and then executing it. -Jochen From rkotler at mips.com Thu Feb 17 17:39:59 2011 From: rkotler at mips.com (reed kotler) Date: Thu, 17 Feb 2011 15:39:59 -0800 Subject: [LLVMdev] td files in eclipse Message-ID: <4D5DB1CF.6080200@mips.com> Has anyone customized Eclipse to handle "td" files? From viridia at gmail.com Thu Feb 17 18:36:32 2011 From: viridia at gmail.com (Talin) Date: Thu, 17 Feb 2011 16:36:32 -0800 Subject: [LLVMdev] llvm.gcroot suggestion In-Reply-To: References: Message-ID: On Thu, Feb 17, 2011 at 1:07 PM, Talin wrote: > On Wed, Feb 16, 2011 at 4:51 PM, Talin wrote: > >> I think I'm one of the few people actually using LLVM's support for >> garbage collection, and so far I've found it very difficult to generate code >> that uses llvm.gcroot() correctly. >> >> In the current scheme, it is the frontend's responsibility to insure that >> any intermediate SSA values containing references to garbage collectible >> objects are copied to stack variables so that the GC strategy can calculate >> offsets for them. It is also the frontend's responsibility to reload those >> values after a sync point, since the collector may have moved them around. >> An additional chore is creating all of the allocas for those roots, which >> have to be in the first block of the function (because that's where allocas >> go according to my understanding of the rules of IR.) >> >> What this means is that the frontend is forced to generate very >> inefficient IR, with dozens of alloca slots at the beginning of the >> function, each marked as a root. It also has to initialize each of these >> roots to a known value, even if the root is only "live" for a very small >> part of the CFG. This is because currently there's no way for the frontend >> to tell LLVM that a given root has a limited lifespan (since calls to >> llvm.gcroot also have to be in the first block), and so you have to take a >> conservative approach and treat every root as if it were live for the entire >> function. >> >> It seems to me that "gc-rootness" should not be an aspect of an alloca, as >> it currently is now, but rather an aspect of a Value, similar to the way >> llvm.dbg.value() works. >> >> Let's imagine a new intrinsic, llvm.gcvalue(), which takes as its >> arguments a Value and a metadata pointer, and returns that same value as its >> result. The frontend can "wrap" any value, of any type, with llvm.gcvalue(), >> which is a signal to LLVM that this value is a garbage collection root. It >> would then be the responsibility of LLVM's code generator (or possibly some >> lowering pass) to insure that this value lives on the stack during sync >> points, and is reloaded after a sync point if it is still needed. During a >> sync point, these values would be treated exactly the way llvm.gcroot works >> today - that is, they live on the stack, and the GCStrategy gets passed a >> list of stack offsets and metadata pointers. The main difference is that >> only the values that are actually 'live' during the sync point are lowered >> from SSA values to allocas. >> >> This approach offers a bunch of advantages that I can think of: >> >> - LLVM knows much more about the liveness of values than the frontend >> does, and could compute a much more optimal and minimal stack map for each >> sync point. That is, two variables whose lifetimes do not overlap can use >> the same stack location for their roots to be stored in, and the stack maps >> generated by the GCStrategy would reflect this. >> - If at some future time LLVM supports register maps for garbage >> collection, you would not have to update your frontend. Since we're marking >> values, not stack slots, the frontend doesn't have to care where the >> variable is stored, so all frontends can take advantage of improvements in >> the representation of stack maps. >> - Writing frontends gets a lot easier, since the frontend is no longer >> responsible for generating and initializing allocas for every root. It also >> means a lot fewer opportunities for generating incorrect code. >> >> What do you think? >> > > So a few additional thoughts: I think that it would be best to keep the > existing llvm.gcroot() call in addition to having llvm.gvcalue(). > llvm.gcroot() would be used for marking allocas as roots, and llvm.gcvalue() > would mark SSA values as roots. > > In fact, if I could go back in time, I would rename them to correspond > exactly with the llvm.dbg intrinsics. So in addition to llvm.dbg.declare() > and llvm.dbg.value(), we'd also have llvm.gc.declare() and llvm.gc.value(), > with analogous uses. > > Note that it is important that the LLVM GC intrinsics should not assume > that the their arguments are pointers, as they could in some cases be > structs or arrays that contain pointers. LLVM should make no assumptions > about the internal structure of a GC root, that is an issue for the > language's GCStrategy pass to worry about - typically the frontend will use > the metadata argument to communicate the structure of a root to the > GCStrategy. The only thing that LLVM has to guarantee is that during a sync > point, it will be possible to associate each live root with an address in > memory somewhere. > > As far as implementation goes, I'm assuming that there would be some pass > that converts llvm.gcvalue() intrinsics into llvm.gcroot() intrinsics by > temporarily storing the the root into an alloca and then reloading it as > needed. (Actually you would probably want something richer than the current > llvm.gcroot that allows an explicit begin and end so that information about > liveness can be preserved. How about llvm.gc.beginroot() intrinsic to > indicate that a given alloca should be considered a root starting at that > point in the CFG, and llvm.gc.endroot() to indicate that the specified root > no longer needs to be considered a root. This is much better than the > current method of assigning NULL to a root, as it accommodates non-pointer > roots, and avoids the extra pointer store which is not needed in many > cases.) > > What is unclear to me is exactly when this should occur relative to other > passes, but I think what you would want to do is perform optimization and > liveness analysis first - thereby eliminating potentially dead roots before > they are converted to memory locations. Unfortunately, I can't say too much > about this, as I am not a backend person - I know very little about > optimization and code generation in general or LLVM's backend passes in > particular. > > There would also need to be some way to tell the code generator not to > reload values after a sync point if the collector doesn't require it, such > as a mark-and-sweep or other non-copying algorithm. The most straightforward > way to handle this would be as an argument to the pass that does the > lowering of llvm.gcvalue intrinsics. > Thinking about it even more, here's a short summary of what I would propose: - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage collection root. This remains in effect for the lifetime of the SSA value. - *llvm.gc.declare*(alloca, metadata) - marks an alloca as a garbage collection root. This intrinsic tells LLVM that it should start treating the alloca as a GC root from that point in the CFG onward. - *llvm.gc.undeclare*(alloca) - tells LLVM that the alloca should no longer be considered a GC root. If llvm.undeclare() is never called, then the alloca is treated as a root until the end of the function. One other thing I thought of was that it would be convenient to declare function parameters with llvm.gc.value(). However, I can get around not having that as a feature. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110217/922a0159/attachment.html From reid.kleckner at gmail.com Thu Feb 17 18:57:16 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Thu, 17 Feb 2011 19:57:16 -0500 Subject: [LLVMdev] llvm.gcroot suggestion In-Reply-To: References: Message-ID: On Thu, Feb 17, 2011 at 7:36 PM, Talin wrote: > llvm.gc.undeclare(alloca) - tells LLVM that the alloca should no longer be > considered a GC root. If llvm.undeclare() is never called, then the alloca > is treated as a root until the end of the function. LLVM has a lifetime.end intrinsic which is similar: http://llvm.org/docs/LangRef.html#int_lifetime_end Reid From null.function at gmail.com Thu Feb 17 22:42:38 2011 From: null.function at gmail.com (nullnull) Date: Thu, 17 Feb 2011 23:42:38 -0500 Subject: [LLVMdev] Enforcing execution order of passes Message-ID: I'd like to run my own passes (implemented as .so) via the opt tool on a linked bitcode. >opt -load=my_own_pass.so -do_my_passes ... test.bc > test.output.bc However, my passes require other LLVM's passes before and after. For example, the ordering of passes that I want: (1) A couple of LLVM's passes ==> (2) my_loop_pass ==> (3) my_module_pass ==> (4) Other LLVM's standard O3 optimizations (a bunch of passes). Can I enfore such complex pass ordering easily? I'd like to pass just a single argument in opt, which trigers the whole pipeline of passes. I tried to use getAnalysisUsage and addRequired. But, the documentation is somewhat vague, I wasn't able even to enforce the pass in (1) to be executed before (2) my loop pass. Also, I'm wondering there is a way to run other passes after my pass. Actually, I did it by hard coding in clang and LLVM source code. But, I'd like to avoid the changes in clang/LLVM as much as possible so that I don't need to compile LLVM suite. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110217/2a5799b1/attachment.html From criswell at illinois.edu Thu Feb 17 23:39:43 2011 From: criswell at illinois.edu (John Criswell) Date: Thu, 17 Feb 2011 23:39:43 -0600 Subject: [LLVMdev] Enforcing execution order of passes In-Reply-To: References: Message-ID: <4D5E061F.5040309@illinois.edu> On 2/17/2011 10:42 PM, nullnull wrote: > I'd like to run my own passes (implemented as .so) via the opt tool on > a linked bitcode. > >opt -load=my_own_pass.so -do_my_passes ... test.bc > test.output.bc > However, my passes require other LLVM's passes before and after. For > example, the ordering of passes that I want: > (1) A couple of LLVM's passes ==> (2) my_loop_pass ==> (3) > my_module_pass ==> (4) Other LLVM's standard O3 optimizations (a bunch > of passes). > Can I enfore such complex pass ordering easily? I'd like to pass just > a single argument in opt, which trigers the whole pipeline of passes. In general, a pass cannot force a transform pass to always be executed before it is run. A pass can only indicate the need for an analysis pass via addRequired() in its getAnalysisUsage() method. This is due to the fact that requiring some transform passes can cause create a set of pass dependencies and pass invalidations that make the passes impossible to schedule(*). To do what you want, you must either: 1) Run opt and specify the transforms in the proper order. 2) Write a script that runs opt as described in 1); or 3) Write a special command-line tool that automatically schedules the transforms to be run in the correct order -- John T. (*) There are a few cases in the LLVM source tree where one transform pass successfully requires another transform pass in getAnalysisUsage(). However, in a past conversation with PassManager's author, I have learned that this is not supported in the general case. > I tried to use getAnalysisUsage and addRequired. But, the > documentation is somewhat vague, I wasn't able even to enforce the > pass in (1) to be executed before (2) my loop pass. > Also, I'm wondering there is a way to run other passes after my pass. > Actually, I did it by hard coding in clang and LLVM source code. But, > I'd like to avoid the changes in clang/LLVM as much as possible so > that I don't need to compile LLVM suite. > Thank you! From markhor at ispras.ru Thu Feb 17 23:58:39 2011 From: markhor at ispras.ru (=?utf-8?B?0JLQsNC00LjQvCDQnNCw0YDQutC+0LLRhtC10LI=?=) Date: Fri, 18 Feb 2011 08:58:39 +0300 (MSK) Subject: [LLVMdev] Adding ARM/Thumb2 instructions with "S" suffux Message-ID: <49632.77.51.75.199.1298008719.squirrel@mail.ispras.ru> Hello everyone, I've added suffixed versions of ARM and Thumb2 instructions to tablegen. That is, for example, "movs" or "orrs". I implemented a rather simple codegen optimization which removes the comparison in patterns like orr r1, r2 ---> orrs r1, r2 cmp r1, 0 It works and have already shown nice acceleration (e.g., 3.3% in SQLite). I have a few questions. 1)"neverHasSideEffects" in tablegen means CPSR is not implicitly defined, doesn't it? 2)What else can be optimized using that super "S" power? 3)Current optimization implementation works similar to peephole, but right before ifcvt. Should I raise it up to somewhere else? 4)Please consider the following C code: int a, b, c; ... a = b * c; if (a > 0) { ... } One gets the corresponding ARM assembler mul r(a), r(b), r(c) cmp r(a), 1 blt LABEL // r(x) in the register where x is In the other cases ("if (a == 0)", "if (a < 0)") the resultant comparison is between r(a) and zero. So what is the hidden idea of comparing with 1 instead of producing mul r(a), r(b), r(c) cmp r(a), 0 ble LABEL ? Besides, where should I look for the code behind that? Thanks, Vadim Markovtsev, ISP RAS. From markhor at ispras.ru Fri Feb 18 00:26:15 2011 From: markhor at ispras.ru (=?utf-8?B?0JLQsNC00LjQvCDQnNCw0YDQutC+0LLRhtC10LI=?=) Date: Fri, 18 Feb 2011 09:26:15 +0300 (MSK) Subject: [LLVMdev] Adding "S" suffixed ARM and Thumb2 instructions Message-ID: <49813.77.51.75.199.1298010375.squirrel@mail.ispras.ru> Hello everyone, I've added the "S" suffixed versions of ARM and Thumb2 instructions to the rest of those declared in tablegen. For example, "movs" or "muls". Besides, I propose the codegen optimization based on them, which removes the redundant comparison in patterns like orr r1, r2, r3 ----> orrs r1, r2, r3 cmp r1, 0 This optimization has already shown nice acceleration, e.g. 3.3% in SQLite on CortexA8. I have some questions. 1)"neverHasSideEffects" in tablegen means that CPSR is not implicitly defined, doesn't it? 2)What else can be done using that super "S" power? 3)Current optimization implementation works similar to peephole (peephole pitiful cmp optimization was disabled), right before ifcvt. Should I raise it up somewhere? What do you think is the right place for such thing? 4)Consider the following C code: int a, b, c; ... a = b * c; if (a > 0) { ... } One gets the corresponding ARM assembler mul r(a), r(b), r(c) cmp r(a), 1 blt LABEL // r(x) is the register where x is The other cases ("if (a == 0)", "if (a < 0)") produce expected cmp r(a), 0 So what is the hidden idea of this resultant comparison with 1? Where should I look for the code behind that logic? Thanks, Vadim Markovtsev, ISP RAS. From gmarkhor at gmail.com Fri Feb 18 00:35:48 2011 From: gmarkhor at gmail.com (=?KOI8-R?B?98HEyc0g7cHSy8/Xw8XX?=) Date: Fri, 18 Feb 2011 09:35:48 +0300 Subject: [LLVMdev] Adding "S" suffixed ARM/Thumb2 instructions Message-ID: Hello everyone, I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Besides, I propose the codegen optimization based on them, which removes the redundant comparison in patterns like orr r1, r2, r3 ----> orrs r1, r2, r3 cmp r1, 0 This optimization has shown nice acceleration, e.g. 3.3% in SQLite on CortexA8 and works fine. I have some questions though. 1)"neverHasSideEffects" in tablegen means that CPSR is not implicitly defined, doesn't it? 2)What else can be done using that super "S" power? 3)Current optimization implementation works similar to peephole (peephole pitiful cmp optimization was disabled), right before ifcvt. Should I raise it up somewhere? What do you think is the right place for such thing? 4)Consider the following C code: int a, b, c; ... a = b * c; if (a > 0) { ... } One gets the corresponding ARM assembler mul r(a), r(b), r(c) cmp r(a), 1 blt LABEL // r(x) is the register where x is The other cases ("if (a == 0)", "if (a < 0)") produce expected cmp r(a), 0 So what is the hidden idea of this resultant comparison with 1? Where should I look for the code behind that logic? Thanks, Vadim Markovtsev, ISP RAS. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/1ab28267/attachment.html From nicolas.geoffray at gmail.com Fri Feb 18 03:05:03 2011 From: nicolas.geoffray at gmail.com (nicolas geoffray) Date: Fri, 18 Feb 2011 10:05:03 +0100 Subject: [LLVMdev] llvm.gcroot suggestion In-Reply-To: References: Message-ID: Hi Talin, On Fri, Feb 18, 2011 at 1:36 AM, Talin wrote: > > Thinking about it even more, here's a short summary of what I would > propose: > > - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage > collection root. This remains in effect for the lifetime of the SSA value. > - *llvm.gc.declare*(alloca, metadata) - marks an alloca as a garbage > collection root. This intrinsic tells LLVM that it should start treating the > alloca as a GC root from that point in the CFG onward. > - *llvm.gc.undeclare*(alloca) - tells LLVM that the alloca should no > longer be considered a GC root. If llvm.undeclare() is never called, then > the alloca is treated as a root until the end of the function. > > I am unsure why you need to provide a live range for a gc root. It looks to me that LLVM should be able to compute it (considering GC allocas never escape). I think the reason why you want this intrinsic is to work around the current way a GC root is declared (an alloca in the first block), but it does not have to be that way. At some point, Chris suggested that we could put the GC root in a different address space than other pointers. Cheers, Nicolas > > > One other thing I thought of was that it would be convenient to declare > function parameters with llvm.gc.value(). However, I can get around not > having that as a feature. > > -- > -- Talin > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/52df92c8/attachment.html From j.wilhelmy at arcor.de Fri Feb 18 04:52:20 2011 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Fri, 18 Feb 2011 11:52:20 +0100 Subject: [LLVMdev] Structure Types and ABI sizes Message-ID: <4D5E4F64.6080300@arcor.de> Hi! I followed the discussion on structure types with the example struct I { int a; char b; }; struct J : I { char c; }; Dave said that this translates to %I = type { i32, i8, i16 } %J = type { %I, i8, i16 } because the frontend has to communicate the ABI to llvm since llvm is language agnostic. What I really wonder is why it isn't %I = type { i32, i8 } %J = type { %I, i16, i8 } because llvm at least knows alignment rules by target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16... Therefore llvm has no other choice than assigning %I a size of 8 since an array may consist of %I elements and size of 5 would violate the aligment of the i32 member. If the ABI requires that member c has an offset of 8 instead of 5 then of course a padding behind %I is necessary in %J. -Jochen From j.wilhelmy at arcor.de Fri Feb 18 07:08:46 2011 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Fri, 18 Feb 2011 14:08:46 +0100 Subject: [LLVMdev] can llvm generate .so and even .dll? Message-ID: <4D5E6F5E.4030107@arcor.de> Hi! if llvm can generate .so and .dll my bytecode cache problem would be easily solved by creating shared libs for the target platform and loading them. -Jochen From rengolin at systemcall.org Fri Feb 18 07:14:21 2011 From: rengolin at systemcall.org (Renato Golin) Date: Fri, 18 Feb 2011 13:14:21 +0000 Subject: [LLVMdev] DIFactory Message-ID: Seems the last use of DIFactory in LLVM/Clang is in: clang/lib/CodeGen/CGDebugInfo.cpp to get the enums llvm::DIFactory::OpDeref and llvm::DIFactory::OpPlus. Shouldn't this be moved to DIBuilder and remove the dependency completely? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From reid.kleckner at gmail.com Fri Feb 18 08:45:23 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Fri, 18 Feb 2011 09:45:23 -0500 Subject: [LLVMdev] can llvm generate .so and even .dll? In-Reply-To: <4D5E6F5E.4030107@arcor.de> References: <4D5E6F5E.4030107@arcor.de> Message-ID: Nope, you'll have to call the system linker. =/ Reid On Fri, Feb 18, 2011 at 8:08 AM, Jochen Wilhelmy wrote: > Hi! > > if llvm can generate .so and .dll my bytecode cache problem would be easily > solved by creating shared libs for the target platform and loading them. > > -Jochen > > _______________________________________________ > 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 Feb 18 09:12:45 2011 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Fri, 18 Feb 2011 16:12:45 +0100 Subject: [LLVMdev] can llvm generate .so and even .dll? In-Reply-To: References: <4D5E6F5E.4030107@arcor.de> Message-ID: <4D5E8C6D.5040406@arcor.de> > Nope, you'll have to call the system linker. =/ > but can I create the appropiate object files? I think yes, but is there some kind of tutorial around? -Jochen From Anton.Lokhmotov at arm.com Fri Feb 18 09:27:13 2011 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Fri, 18 Feb 2011 15:27:13 -0000 Subject: [LLVMdev] [PATCH] OpenCL support - update on keywords In-Reply-To: <20110104214222.GA22362@pcc.me.uk> References: <20101216223130.GA1885@pcc.me.uk> <000001cba1f0$873bfe70$95b3fb50$@Lokhmotov@arm.com> <20110104214222.GA22362@pcc.me.uk> Message-ID: <000001cbcf80$512b0b10$f3812130$@Lokhmotov@arm.com> > -----Original Message----- > From: Peter Collingbourne [mailto:peter at pcc.me.uk] > Sent: 04 January 2011 21:42 > To: Anton Lokhmotov > Cc: cfe-dev at cs.uiuc.edu > Subject: Re: OpenCL support > > Here are my comments on the second patch. > > > +enum OpenCLAddressSpace { > > + OPENCL_PRIVATE = 0, > > + OPENCL_GLOBAL = 1, > > + OPENCL_LOCAL = 2, > > + OPENCL_CONSTANT = 3 > > +}; > > If we are going to standardise these address space numbers across > Clang and the LLVM backends, this enum declaration should be added > somewhere in LLVM so that the backends have access to it. Perhaps a > new header file called something like "llvm/Support/AddressSpaces.h"? We went for llvm/Support/OpenCL.h for now, because might need to add further OpenCL-specific support. Copying to llvmdev. > > +enum OpenCLImageAccess { > > + OPENCL_READ_ONLY = 1, > > + OPENCL_WRITE_ONLY = 2, > > + OPENCL_READ_WRITE = 3 > > +}; > > This should live in AST somewhere - once the image access attribute > is added to the AST we will need access to this declaration from all > AST clients. Similarly, we created clang/AST/OpenCL.h. > Also, please add test cases which test that: > > 1) the LLVM produced by the code generator is annotated with the > correct address space numbers for each new address space added; Done (test/CodeGenOpenCL/address-spaces.cl). > 2) the image access attributes are recognised by the parser/semantic > analyser. Partially done (test/Parser/opencl-image-access.cl). Semantic support for the image access qualifiers will be added along with support for the image types, which we are preparing for review now. > Other than that, LGTM. Many thanks, Anton. -------------- next part -------------- A non-text attachment was scrubbed... Name: 00002-keywords-llvm.patch Type: application/octet-stream Size: 874 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/86d3c7a6/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 00002-keywords-clang.patch Type: application/octet-stream Size: 16146 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/86d3c7a6/attachment-0001.obj From Edmund.Grimley-Evans at arm.com Fri Feb 18 09:31:54 2011 From: Edmund.Grimley-Evans at arm.com (Edmund Grimley-Evans) Date: Fri, 18 Feb 2011 15:31:54 -0000 Subject: [LLVMdev] EFLAGS and MVT::Glue Message-ID: The log message for revision 122213 says: > Change the X86 backend to stop using the evil ADDC/ADDE/SUBC/SUBE nodes (which > their carry depenedencies with MVT::Flag operands) and use clean and beautiful > EFLAGS dependences instead. (MVT::Flag has since been renamed to MVT::Glue.) That revision made bug 8404 go away. Am I right in thinking that one of the problems with MVT::Glue is that it is hard to guarantee that other instructions won't come between the two instructions that are glued together? And another problem is that you actually want to allow some instructions to come between them? Suppose, for example, that we have a selection DAG with these edges: X -> G1 -> G2 -> Y X -> A -> Y where the dependency between G1 and G2 is Glue. Then if instruction selection replaces X and G1 by a single instruction I1, and G2 and Y by a single instruction I2, then we end up with this DAG: I1 -> I2 I1 -> A -> I2 Now I1 and I2 are glued together, but A has to come between them. It's hard to know when a combination of rules that each look all right on their own might lead to this happening. I'm guessing that something like this lead to the "Wrong topological sorting" assertion failure in bug 8404. (I've seen the same assertion failure in some other cases where I have more reason to think that that's roughly what happened.) A real example to consider might be code like this: do { a[i] -= b[i]; } while (a[i++] >= 0); I'm currently getting ARM code like this: .LBB0_1: ldr r2, [r1], #4 ldr r3, [r0] sub r2, r3, r2 str r2, [r0], #4 cmp r2, #0 bge .LBB0_1 This could be improved, I think, by getting the subtract to set the flags instead of comparing with zero, like this: .LBB0_1: ldr r2, [r1], #4 ldr r3, [r0] subs r2, r3, r2 str r2, [r0], #4 bpl .LBB0_1 But that code might be hard to generate if the flag-setting SUBS is "glued" to the conditional branch BPL so you can't put the store between them. So, some questions: * Is there a set of rules for using Glue to avoid getting "Wrong topological sorting"? * If not, should we be avoiding Glue altogether? * How hard is it to replace Glue in other back ends by something like EFLAGS? Should we be doing that? Edmund -- 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 j.wilhelmy at arcor.de Fri Feb 18 10:18:50 2011 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Fri, 18 Feb 2011 17:18:50 +0100 Subject: [LLVMdev] Please add .o writer example to next release Message-ID: <4D5E9BEA.8090007@arcor.de> Hi! Is it possible that you add an example how to write a .o with llvm? Just like examples/ModuleMaker but instead of printing to stdout writing a .o file as starting point for the new MC functionality. -Jochen From ofv at wanadoo.es Fri Feb 18 10:33:59 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Fri, 18 Feb 2011 17:33:59 +0100 Subject: [LLVMdev] Please add .o writer example to next release References: <4D5E9BEA.8090007@arcor.de> Message-ID: <87tyg1l2tk.fsf@wanadoo.es> Jochen Wilhelmy writes: > Is it possible that you add an example how to write a .o with llvm? +1 From rafael.espindola at gmail.com Fri Feb 18 10:44:44 2011 From: rafael.espindola at gmail.com (Rafael Avila de Espindola) Date: Fri, 18 Feb 2011 11:44:44 -0500 Subject: [LLVMdev] can llvm generate .so and even .dll? In-Reply-To: <4D5E8C6D.5040406@arcor.de> References: <4D5E6F5E.4030107@arcor.de> <4D5E8C6D.5040406@arcor.de> Message-ID: <4D5EA1FC.2070706@gmail.com> > but can I create the appropiate object files? I think yes, but is there some > kind of tutorial around? You can. Check what "llc -filetype=obj -o foo.o foo.bc" does. > -Jochen Cheers, Rafael From viridia at gmail.com Fri Feb 18 10:50:54 2011 From: viridia at gmail.com (Talin) Date: Fri, 18 Feb 2011 08:50:54 -0800 Subject: [LLVMdev] llvm.gcroot suggestion In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 1:05 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Fri, Feb 18, 2011 at 1:36 AM, Talin wrote: >> >> Thinking about it even more, here's a short summary of what I would >> propose: >> >> - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage >> collection root. This remains in effect for the lifetime of the SSA value. >> - *llvm.gc.declare*(alloca, metadata) - marks an alloca as a garbage >> collection root. This intrinsic tells LLVM that it should start treating the >> alloca as a GC root from that point in the CFG onward. >> - *llvm.gc.undeclare*(alloca) - tells LLVM that the alloca should no >> longer be considered a GC root. If llvm.undeclare() is never called, then >> the alloca is treated as a root until the end of the function. >> >> > I am unsure why you need to provide a live range for a gc root. It looks to > me that LLVM should be able to compute it (considering GC allocas never > escape). I think the reason why you want this intrinsic is to work around > the current way a GC root is declared (an alloca in the first block), but it > does not have to be that way. At some point, Chris suggested that we could > put the GC root in a different address space than other pointers. > In the current scheme, the way you tell LLVM that a root is no longer needed is by assigning NULL to it. However, that assumes that all roots are pointers, which is not true in my world - a root can be a struct containing pointers inside of it. (In my current frontend, a non-pointer root is indicated by passing a non-NULL metadata argument to llvm.gcroot, which contains information about which fields in the struct are roots. This is especially important in the case of tagged unions, where the garbage collector may have to examine the union tag field in order to determine if the pointer field is indeed a pointer - passing the pointer alone would be insufficient to determine this.) Putting GC roots in a different address space works OK for me, as long as I can have SSA values that are structs that have pointers embedded in them that are in this different address space. In other words, if I have an SSA value that is a struct containing pointers which are roots, I need for the garbage collector to see the entire struct, not just the pointers. What I'm primarily asking for is to have the LLVM code generator automatically spill roots from SSA values to memory during a sync point, and reload them afterward, instead of my frontend having to generate code to do this. As I mentioned, the current scheme results in the frontend having to generate very inefficient IR because of the need to be conservative about root liveness. The frontend can't know anything about the optimization passes that LLVM will perform on the function. > Cheers, > Nicolas > > > >> >> >> One other thing I thought of was that it would be convenient to declare >> function parameters with llvm.gc.value(). However, I can get around not >> having that as a feature. >> >> -- >> -- Talin >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/cf8a9344/attachment.html From anton at korobeynikov.info Fri Feb 18 10:54:17 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Fri, 18 Feb 2011 19:54:17 +0300 Subject: [LLVMdev] EFLAGS and MVT::Glue In-Reply-To: References: Message-ID: Hello Edmund, > Am I right in thinking that one of the problems with MVT::Glue is that > it is hard to guarantee that other instructions won't come between the > two instructions that are glued together? No. This is actually why MVT::Glue was introduced: to always glue stuff altogether. > * How hard is it to replace Glue in other back ends by something like > ?EFLAGS? Should we be doing that? This is not possible for ARM right now, because latency-modelling scheduler cannot handle physreg deps (there is PR for this). But in general, adding more "degrees of freedom" is a generic goodness. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From blunted2night at gmail.com Fri Feb 18 11:18:38 2011 From: blunted2night at gmail.com (Nathan Jeffords) Date: Fri, 18 Feb 2011 09:18:38 -0800 Subject: [LLVMdev] Please add .o writer example to next release In-Reply-To: <87tyg1l2tk.fsf@wanadoo.es> References: <4D5E9BEA.8090007@arcor.de> <87tyg1l2tk.fsf@wanadoo.es> Message-ID: this is function I use to emit an object file: void output_object (llvm::Module * Module, llvm::TargetMachine * Target, llvm::raw_ostream & Output) { llvm::formatted_raw_ostream fOutput (Output); FunctionPassManager Passes(Module); Passes.add(new TargetData (*Target->getTargetData())); if (Target->addPassesToEmitFile(Passes, fOutput, llvm::TargetMachine::CGFT_ObjectFile, llvm::CodeGenOpt::None)) throw std::runtime_error ("bad voodoo (Target->addPassesToEmitFile)"); Passes.doInitialization(); for (llvm::Module::iterator I = Module->begin(), E = Module->end(); I != E; ++I) if (!I->isDeclaration()) Passes.run(*I); Passes.doFinalization(); } On Fri, Feb 18, 2011 at 8:33 AM, ?scar Fuentes wrote: > Jochen Wilhelmy writes: > > > Is it possible that you add an example how to write a .o with llvm? > > +1 > > _______________________________________________ > 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/20110218/8c750353/attachment.html From damien.llvm at gmail.com Fri Feb 18 11:55:37 2011 From: damien.llvm at gmail.com (Damien Vincent) Date: Fri, 18 Feb 2011 09:55:37 -0800 Subject: [LLVMdev] EFLAGS and MVT::Glue In-Reply-To: References: Message-ID: I'd like to point out some issues I encountered when using MVT::Flag Basically, applying some transformations might introduce some cycles in the graph (it's not a DAG anymore !). Let's consider your example: sub r2, r3, r2 cmp r2, #0 bge .LBB0_1 The initial graph might look like this one: I1: sub(r3,r2) ==> I2: CopyToReg I1 ==> I3: cmp r2, #0 I2 (input chain) & I3 (condition code) ==> I4: bge with I3 and I4 glued together. Now let's assume you remove the cmp instruction: I1: sub(r3,r2) ==> I2: CopyToReg I2(input chain) & I1 (condition code) ==> I4:bge with I1 and I4 glued together. And we just created a cycle in the graph: - a successor of I1 is I4 - a successor of I4 is I2 (because I1 and I4 are glued & I2 is a successor of I1) - a direct successor if I2 is I4 and so the cycle is there ! Please tell me if I missed something... But to me, it's "easy" to have some cycles in the graph even if it still looks a DAG when you draw the graph. Damien On Fri, Feb 18, 2011 at 7:31 AM, Edmund Grimley-Evans < Edmund.Grimley-Evans at arm.com> wrote: > The log message for revision 122213 says: > > > Change the X86 backend to stop using the evil ADDC/ADDE/SUBC/SUBE nodes > (which > > their carry depenedencies with MVT::Flag operands) and use clean and > beautiful > > EFLAGS dependences instead. > > (MVT::Flag has since been renamed to MVT::Glue.) > > That revision made bug 8404 go away. > > Am I right in thinking that one of the problems with MVT::Glue is that > it is hard to guarantee that other instructions won't come between the > two instructions that are glued together? And another problem is that > you actually want to allow some instructions to come between them? > > Suppose, for example, that we have a selection DAG with these edges: > > X -> G1 -> G2 -> Y > X -> A -> Y > > where the dependency between G1 and G2 is Glue. > > Then if instruction selection replaces X and G1 by a single > instruction I1, and G2 and Y by a single instruction I2, then we end > up with this DAG: > > I1 -> I2 > I1 -> A -> I2 > > Now I1 and I2 are glued together, but A has to come between them. It's > hard to know when a combination of rules that each look all right on > their own might lead to this happening. > > I'm guessing that something like this lead to the "Wrong topological > sorting" assertion failure in bug 8404. (I've seen the same assertion > failure in some other cases where I have more reason to think that > that's roughly what happened.) > > A real example to consider might be code like this: > > do { > a[i] -= b[i]; > } while (a[i++] >= 0); > > I'm currently getting ARM code like this: > > .LBB0_1: > ldr r2, [r1], #4 > ldr r3, [r0] > sub r2, r3, r2 > str r2, [r0], #4 > cmp r2, #0 > bge .LBB0_1 > > This could be improved, I think, by getting the subtract to set the > flags instead of comparing with zero, like this: > > .LBB0_1: > ldr r2, [r1], #4 > ldr r3, [r0] > subs r2, r3, r2 > str r2, [r0], #4 > bpl .LBB0_1 > > But that code might be hard to generate if the flag-setting SUBS is > "glued" to the conditional branch BPL so you can't put the store > between them. > > So, some questions: > > * Is there a set of rules for using Glue to avoid getting "Wrong > topological sorting"? > > * If not, should we be avoiding Glue altogether? > > * How hard is it to replace Glue in other back ends by something like > EFLAGS? Should we be doing that? > > Edmund > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/94b8131e/attachment.html From bob.wilson at apple.com Fri Feb 18 12:49:22 2011 From: bob.wilson at apple.com (Bob Wilson) Date: Fri, 18 Feb 2011 10:49:22 -0800 Subject: [LLVMdev] Adding "S" suffixed ARM/Thumb2 instructions In-Reply-To: References: Message-ID: On Feb 17, 2011, at 10:35 PM, ????? ????????? wrote: > Hello everyone, > > I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". > Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Adding separate "s" instructions is not the right thing to do. We've been trying hard to avoid adding those "twins". The instructions that can optionally set the condition codes have an "optional def" operand. For example, look at the "cc_out" operand in the "sI" class defined in ARMInstrFormats.td. If that operand is set to the CPSR register, then the instruction becomes the "s" variant. There are some existing peephole optimizations to make use of this, but there are some unresolved issues as well. Do you have some example testcases that show where we're missing opportunities? From Micah.Villmow at amd.com Fri Feb 18 13:44:23 2011 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Fri, 18 Feb 2011 13:44:23 -0600 Subject: [LLVMdev] [PATCH] OpenCL support - update on keywords In-Reply-To: <000001cbcf80$512b0b10$f3812130$@Lokhmotov@arm.com> References: <20101216223130.GA1885@pcc.me.uk> <000001cba1f0$873bfe70$95b3fb50$@Lokhmotov@arm.com> <20110104214222.GA22362@pcc.me.uk> <000001cbcf80$512b0b10$f3812130$@Lokhmotov@arm.com> Message-ID: Anton, Would there be any issue with switching the ordering of constant and local? > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Anton Lokhmotov > Sent: Friday, February 18, 2011 7:27 AM > To: 'Peter Collingbourne' > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: [LLVMdev] [PATCH] OpenCL support - update on keywords > > > -----Original Message----- > > From: Peter Collingbourne [mailto:peter at pcc.me.uk] > > Sent: 04 January 2011 21:42 > > To: Anton Lokhmotov > > Cc: cfe-dev at cs.uiuc.edu > > Subject: Re: OpenCL support > > > > Here are my comments on the second patch. > > > > > +enum OpenCLAddressSpace { > > > + OPENCL_PRIVATE = 0, > > > + OPENCL_GLOBAL = 1, > > > + OPENCL_LOCAL = 2, > > > + OPENCL_CONSTANT = 3 > > > +}; > > > > If we are going to standardise these address space numbers across > > Clang and the LLVM backends, this enum declaration should be added > > somewhere in LLVM so that the backends have access to it. Perhaps a > > new header file called something like "llvm/Support/AddressSpaces.h"? > We went for llvm/Support/OpenCL.h for now, because might need to add > further OpenCL-specific support. Copying to llvmdev. > > > > +enum OpenCLImageAccess { > > > + OPENCL_READ_ONLY = 1, > > > + OPENCL_WRITE_ONLY = 2, > > > + OPENCL_READ_WRITE = 3 > > > +}; > > > > This should live in AST somewhere - once the image access attribute > is > > added to the AST we will need access to this declaration from all AST > > clients. > Similarly, we created clang/AST/OpenCL.h. > > > Also, please add test cases which test that: > > > > 1) the LLVM produced by the code generator is annotated with the > > correct address space numbers for each new address space added; > Done (test/CodeGenOpenCL/address-spaces.cl). > > > 2) the image access attributes are recognised by the parser/semantic > > analyser. > Partially done (test/Parser/opencl-image-access.cl). Semantic support > for the image access qualifiers will be added along with support for > the image types, which we are preparing for review now. > > > Other than that, LGTM. > > Many thanks, > Anton. From aaronngray.lists at gmail.com Fri Feb 18 15:23:13 2011 From: aaronngray.lists at gmail.com (Aaron Gray) Date: Fri, 18 Feb 2011 21:23:13 +0000 Subject: [LLVMdev] C++ Mangled Names In-Reply-To: <4D5A3508.1040403@illinois.edu> References: <4D5A3508.1040403@illinois.edu> Message-ID: On 15 February 2011 08:10, Patrick Simmons wrote: > I have encountered a need for manually generating the mangled name of an > arbitrary C++ function. The only way I currently know how to do this is > to generate a dummy C++ source file, compile it, and look at the > output. This approach is so ugly that I would like for it never to see > the light of day. The c++filt tool generates demangled C++ names given > the mangled ones, which is the opposite of what I want to do. Does > anyone know how to "run c++filt in reverse"? > It would be lovely to have a declspec that adds an additional user given to label routines if required. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/77952018/attachment.html From viridia at gmail.com Fri Feb 18 15:32:19 2011 From: viridia at gmail.com (Talin) Date: Fri, 18 Feb 2011 13:32:19 -0800 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: I didn't know DIFactory existed until you mentioned it just now. And if folks are adding brand new classes to LLVM, can we not follow the naming conventions in the developer guidelines? On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin wrote: > Seems the last use of DIFactory in LLVM/Clang is in: > > clang/lib/CodeGen/CGDebugInfo.cpp to get the enums > llvm::DIFactory::OpDeref and llvm::DIFactory::OpPlus. > > Shouldn't this be moved to DIBuilder and remove the dependency completely? > > -- > 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 > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/de201df6/attachment.html From viridia at gmail.com Fri Feb 18 15:34:22 2011 From: viridia at gmail.com (Talin) Date: Fri, 18 Feb 2011 13:34:22 -0800 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: Sorry, I meant DIBuilder. On Fri, Feb 18, 2011 at 1:32 PM, Talin wrote: > I didn't know DIFactory existed until you mentioned it just now. > > And if folks are adding brand new classes to LLVM, can we not follow the > naming conventions in the developer guidelines? > > On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin wrote: > >> Seems the last use of DIFactory in LLVM/Clang is in: >> >> clang/lib/CodeGen/CGDebugInfo.cpp to get the enums >> llvm::DIFactory::OpDeref and llvm::DIFactory::OpPlus. >> >> Shouldn't this be moved to DIBuilder and remove the dependency completely? >> >> -- >> 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 >> > > > > -- > -- Talin > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/7b0fbe36/attachment.html From rengolin at systemcall.org Fri Feb 18 15:52:39 2011 From: rengolin at systemcall.org (Renato Golin) Date: Fri, 18 Feb 2011 21:52:39 +0000 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: On 18 February 2011 21:34, Talin wrote: > Sorry, I meant DIBuilder. DIBuilder is the new DIFactory. I've been playing with it this week and it's much easier and straightforward to use. I'm still having problems to create arrays, though. As far as I remember (from the 2010 meeting), the idea was to replace and deprecate DIFactory. I'm not saying we should do it now, just saying Clang should have no more deps on the old DIFactory to avoid header pollution, since it's only on one enum... ;) cheers, --renato From viridia at gmail.com Fri Feb 18 16:19:57 2011 From: viridia at gmail.com (Talin) Date: Fri, 18 Feb 2011 14:19:57 -0800 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 1:52 PM, Renato Golin wrote: > On 18 February 2011 21:34, Talin wrote: > > Sorry, I meant DIBuilder. > > DIBuilder is the new DIFactory. I've been playing with it this week > and it's much easier and straightforward to use. I'm still having > problems to create arrays, though. > > As far as I remember (from the 2010 meeting), the idea was to replace > and deprecate DIFactory. > > I'm not saying we should do it now, just saying Clang should have no > more deps on the old DIFactory to avoid header pollution, since it's > only on one enum... ;) > > Yeah, I remember that conversation - I just didn't know that any action had been taken. However, my other concern is this: According to the LLVM Coding Standards document (http://llvm.org/docs/CodingStandards.html#ll_naming): *Function names* should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). The coding standards say functions should begin with a lower case letter, but I see a lot of new code (not just DIBuilder) that uses method names that begin with an upper case letter. Is the document incorrect, or is there basically no enforcement? -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/c163935f/attachment.html From foldr at codedgers.com Fri Feb 18 18:37:27 2011 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Sat, 19 Feb 2011 00:37:27 +0000 (UTC) Subject: [LLVMdev] Make "llvmc -opt" call "opt" for .ll files References: Message-ID: Hi, Kaelyn Uhrain gmail.com> writes: > > Without this patch, opt is never called for llvm-assembly (.ll) files > when "-opt" is passed to llvmc: > > [...] Thanks, applied in r126000! From vgrover528 at gmail.com Fri Feb 18 18:53:00 2011 From: vgrover528 at gmail.com (Vinod Grover) Date: Fri, 18 Feb 2011 16:53:00 -0800 Subject: [LLVMdev] Fortran alternate entry points in LLVM IR? Message-ID: I was curious about what is a good way to represent alternate function entries in LLVM IR? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/683d3f86/attachment.html From sergey.yakoushkin at gmail.com Fri Feb 18 20:42:37 2011 From: sergey.yakoushkin at gmail.com (Sergey Yakoushkin) Date: Sat, 19 Feb 2011 03:42:37 +0100 Subject: [LLVMdev] Is va_arg deprecated? In-Reply-To: References: Message-ID: Hi David, I'm working on source to source transformations and instrumentation. A flag to disable 'va_arg' lowering in LLVM FEs will be very useful. Have you sent your modifications upstream to LLVM? If not, could you please share link to your public repository. Thanks, Sergey Yakoushkin On Mon, Jul 19, 2010 at 11:18 PM, David Meyer wrote: > Neal, > > FYI, my group has added a flag to llvm-gcc for emitting the va_arg > instruction (instead of lowering in the front-end), > and we also have an implementation of the VAARG instruction for > X86-64. (which is currently not implemented in the LLVM backend). > > Both of these things will be sent upstream to LLVM soon, pending some > more testing and review. > > If you are dire need of these features now, I can point you to the > (public) repository where we have the beta versions. > > - David M From viridia at gmail.com Fri Feb 18 22:31:10 2011 From: viridia at gmail.com (Talin) Date: Fri, 18 Feb 2011 20:31:10 -0800 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 1:52 PM, Renato Golin wrote: > On 18 February 2011 21:34, Talin wrote: > > Sorry, I meant DIBuilder. > > DIBuilder is the new DIFactory. I've been playing with it this week > and it's much easier and straightforward to use. I'm still having > problems to create arrays, though. > > As far as I remember (from the 2010 meeting), the idea was to replace > and deprecate DIFactory. > > I'm not saying we should do it now, just saying Clang should have no > more deps on the old DIFactory to avoid header pollution, since it's > only on one enum... ;) > > cheers, > --renato > A couple of other questions about DIBuilder: 1) I notice that there's no 'isMain' parameter to CreateCompileUnit. How do you specify the main module? 2) There's no means to set TheCU other than creating a new compile unit. This means that you have to generate all of the debug info for your module with a single DIBuilder instance, since there's no way to use a pre-existing compile unit. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110218/5f76dee6/attachment.html From niuqingpeng at gmail.com Sat Feb 19 01:04:43 2011 From: niuqingpeng at gmail.com (Qingpeng Niu) Date: Sat, 19 Feb 2011 02:04:43 -0500 Subject: [LLVMdev] Does anybody use clang complete for vim? Message-ID: Hi, Hi, I install clang complete on my lab machine. It is ok. But when i copy clang files to plugin of my laptop. It is not working. It gives the following information. User defined completion (^U^N^P) Pattern not found -- Qingpeng Niu Department of Computer Science and Engineering at OSU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110219/f4ce590c/attachment.html From baldrick at free.fr Sat Feb 19 03:25:04 2011 From: baldrick at free.fr (Duncan Sands) Date: Sat, 19 Feb 2011 10:25:04 +0100 Subject: [LLVMdev] Fortran alternate entry points in LLVM IR? In-Reply-To: References: Message-ID: <4D5F8C70.9070608@free.fr> Hi Vinod, > I was curious about what is a good way to represent alternate function entries > in LLVM IR? I suggest you use the same strategy as gcc: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/Alternate-Entry-Points.html Ciao, Duncan. From renato.golin at arm.com Sat Feb 19 12:49:03 2011 From: renato.golin at arm.com (Renato Golin) Date: Sat, 19 Feb 2011 18:49:03 +0000 Subject: [LLVMdev] Is va_arg deprecated? In-Reply-To: References: Message-ID: On 19 February 2011 02:42, Sergey Yakoushkin wrote: > I'm working on source to source transformations and instrumentation. > A flag to disable 'va_arg' lowering in LLVM FEs will be very useful. Hi, For the sake of simplicity, if types are simple, we emit va_arg directly, otherwise we do like Clang and lower it in the front-end. Would be nice to keep va_arg for the simple cases... cheers, --renato From clattner at apple.com Sat Feb 19 12:49:25 2011 From: clattner at apple.com (Chris Lattner) Date: Sat, 19 Feb 2011 10:49:25 -0800 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: On Feb 18, 2011, at 2:19 PM, Talin wrote: > > Yeah, I remember that conversation - I just didn't know that any action had been taken. > > However, my other concern is this: According to the LLVM Coding Standards document (http://llvm.org/docs/CodingStandards.html#ll_naming): > > Function names > should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). > > The coding standards say functions should begin with a lower case letter, but I see a lot of new code (not just DIBuilder) that uses method names that begin with an upper case letter. Is the document incorrect, or is there basically no enforcement? DIBuilder is older than the naming standards. Patches to improve DIBuilder's naming would definitely be appreciated. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110219/6b7fc5d3/attachment.html From howarth at bromo.med.uc.edu Sat Feb 19 13:25:54 2011 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 19 Feb 2011 14:25:54 -0500 Subject: [LLVMdev] llvm-gcc4.2 bootstrap broken? Message-ID: <20110219192554.GA5200@bromo.med.uc.edu> Is anyone able to bootstrap llvm-gcc42 svn on x86_64-apple-darwin10? Currently it is failing here with... /sw/src/fink.build/llvm-gcc42-2.9-0/llvm_gcc42_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/llvm-gcc42-2.9-0/llvm_gcc42_objdir/./prev-gcc/ -B/sw/lib/llvm-gcc-4.2/x86_64-apple-darwin10/bin/ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -I. -I. -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/. -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I/sw/include -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/sw/include -I/sw/include -DENABLE_LLVM -I/sw/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS ../../llvm-gcc-4.2-2.9.source/gcc/tree-iterator.c -o tree-iterator.o /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _iasm_addr.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _iasm_build_bracket.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _iasm_force_constraint.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _iasm_get_register_var.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _iasm_is_pseudo.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _iasm_print_operand.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _build_modify_expr.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _decl_constant_value.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _build_function_call.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _build_stmt.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _lookup_name.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _pointer_int_sum.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _store_init_value.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _cvt_utf8_utf16.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _create_init_utf16_var.eh can't be a weak_definition /var/tmp//ccopwjpg.s:unknown:Non-global symbol: _pushdecl_top_level.eh can't be a weak_definition make[3]: *** [stub-c.o] Error 1 make[3]: *** Waiting for unfinished jobs.... rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gfortran.pod gpl.pod gcc.pod make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 ### execution of /var/tmp/tmp.1.b4VcRD failed, exit code 2 From viridia at gmail.com Sat Feb 19 14:27:24 2011 From: viridia at gmail.com (Talin) Date: Sat, 19 Feb 2011 12:27:24 -0800 Subject: [LLVMdev] Looking for more LLBrowse testers / users Message-ID: LLBrowse - a GUI tool which allows you to inspect the contents of LLVM modules - now runs on Linux and OS X, and it works with both LLVM 2.8 and current LLVM head. I've updated the docs to include instructions on checking out and building the code under several different environments, which you can read here: http://llvm.org/svn/llvm-project/llbrowse/trunk/doc/LLBrowse.html (the doc also includes screenshots.) I'm interested in any bug reports or problems folks might have. You can either reply to this thread or email me privately. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110219/f2582f41/attachment.html From yuri at rawbw.com Sat Feb 19 16:52:07 2011 From: yuri at rawbw.com (Yuri) Date: Sat, 19 Feb 2011 14:52:07 -0800 Subject: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule In-Reply-To: <8A8DC54A-1F82-4857-AA49-DDE3467232D2@apple.com> References: <8A8DC54A-1F82-4857-AA49-DDE3467232D2@apple.com> Message-ID: <4D604997.8090903@rawbw.com> Will MC path for JNI be included in 2.9? Yuri From viridia at gmail.com Sat Feb 19 19:12:15 2011 From: viridia at gmail.com (Talin) Date: Sat, 19 Feb 2011 17:12:15 -0800 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 1:52 PM, Renato Golin wrote: > On 18 February 2011 21:34, Talin wrote: > > Sorry, I meant DIBuilder. > > DIBuilder is the new DIFactory. I've been playing with it this week > and it's much easier and straightforward to use. I'm still having > problems to create arrays, though. > OK I switched all my stuff over to use DIBuilder, and you are right - the arrays don't work. Everything else does though. > > As far as I remember (from the 2010 meeting), the idea was to replace > and deprecate DIFactory. > > I'm not saying we should do it now, just saying Clang should have no > more deps on the old DIFactory to avoid header pollution, since it's > only on one enum... ;) > > cheers, > --renato > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110219/a97b307e/attachment.html From yuri at rawbw.com Sat Feb 19 20:12:34 2011 From: yuri at rawbw.com (Yuri) Date: Sat, 19 Feb 2011 18:12:34 -0800 Subject: [LLVMdev] What are the equivalents of gcc inline control options like max-inline-insns-single in clang? Message-ID: <4D607892.4090706@rawbw.com> I got these warnings: clang: warning: argument unused during compilation: '-finline-limit=50' clang: warning: argument unused during compilation: '--param max-inline-insns-single=50' clang: warning: argument unused during compilation: '--param max-inline-insns-auto=12' clang: warning: argument unused during compilation: '--param large-function-insns=300' clang: warning: argument unused during compilation: '--param large-function-growth=20' clang: warning: argument unused during compilation: '--param inline-unit-growth=100' These options work with gcc and not with clang. What are the clang equivalents? Yuri From clattner at apple.com Sat Feb 19 20:29:18 2011 From: clattner at apple.com (Chris Lattner) Date: Sat, 19 Feb 2011 18:29:18 -0800 Subject: [LLVMdev] What are the equivalents of gcc inline control options like max-inline-insns-single in clang? In-Reply-To: <4D607892.4090706@rawbw.com> References: <4D607892.4090706@rawbw.com> Message-ID: <96ADC918-058D-443C-B69B-E65F501138DE@apple.com> On Feb 19, 2011, at 6:12 PM, Yuri wrote: > I got these warnings: > clang: warning: argument unused during compilation: '-finline-limit=50' > clang: warning: argument unused during compilation: '--param > max-inline-insns-single=50' > clang: warning: argument unused during compilation: '--param > max-inline-insns-auto=12' > clang: warning: argument unused during compilation: '--param > large-function-insns=300' > clang: warning: argument unused during compilation: '--param > large-function-growth=20' > clang: warning: argument unused during compilation: '--param > inline-unit-growth=100' > > These options work with gcc and not with clang. > What are the clang equivalents? Clang doesn't expose any equivalent. -Chris From yuri at rawbw.com Sat Feb 19 20:40:04 2011 From: yuri at rawbw.com (Yuri) Date: Sat, 19 Feb 2011 18:40:04 -0800 Subject: [LLVMdev] What are the equivalents of gcc inline control options like max-inline-insns-single in clang? In-Reply-To: <96ADC918-058D-443C-B69B-E65F501138DE@apple.com> References: <4D607892.4090706@rawbw.com> <96ADC918-058D-443C-B69B-E65F501138DE@apple.com> Message-ID: <4D607F04.70900@rawbw.com> On 02/19/2011 18:29, Chris Lattner wrote: > Clang doesn't expose any equivalent Why not? Such controls are useful to tune the level of optimization. For example from my experience forcing more inlining causes code to grow due to resulting duplication but often such code is also faster. Even though cache mishits may cause it to slow down too eventually. Speed is vital for software in many industries. User should be able to force-flatten the module leaving only interface functions. On the other hand user may want to lower the inlining level to speed up compilation. Yuri From yuri at rawbw.com Sat Feb 19 22:05:18 2011 From: yuri at rawbw.com (Yuri) Date: Sat, 19 Feb 2011 20:05:18 -0800 Subject: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule In-Reply-To: <4D604997.8090903@rawbw.com> References: <8A8DC54A-1F82-4857-AA49-DDE3467232D2@apple.com> <4D604997.8090903@rawbw.com> Message-ID: <4D6092FE.2080709@rawbw.com> On 02/19/2011 14:52, Yuri wrote: > Will MC path for JNI be included in 2.9? > Sorry. I meant: Will MC path for JIT be included in 2.9? From yuri at rawbw.com Sat Feb 19 22:28:45 2011 From: yuri at rawbw.com (Yuri) Date: Sat, 19 Feb 2011 20:28:45 -0800 Subject: [LLVMdev] Why __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ are defined as 4, 2, 1 in clang? Message-ID: <4D60987D.7010306@rawbw.com> clang isn't GNU C. So why does it define such values and why they are 4,2,1? It also defines __GNUC_STDC_INLINE__=1 for some reason. rev.126022 Yuri From joerg at britannica.bec.de Sat Feb 19 22:55:19 2011 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Sun, 20 Feb 2011 05:55:19 +0100 Subject: [LLVMdev] Why __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ are defined as 4, 2, 1 in clang? In-Reply-To: <4D60987D.7010306@rawbw.com> References: <4D60987D.7010306@rawbw.com> Message-ID: <20110220045519.GA12581@britannica.bec.de> On Sat, Feb 19, 2011 at 08:28:45PM -0800, Yuri wrote: > clang isn't GNU C. So why does it define such values and why they are 4,2,1? > It also defines __GNUC_STDC_INLINE__=1 for some reason. It is mostly compatible with GCC 4.2 and providing the macros makes a lot of code work without modifications. __GNUC_STDC_INLINE__ depends on the choosen level of standard compliance. The (current?) behavior again mimics GCC 4.2.1. Joerg From mikael at lyngvig.org Sun Feb 20 00:03:12 2011 From: mikael at lyngvig.org (Mikael Lyngvig) Date: Sun, 20 Feb 2011 07:03:12 +0100 Subject: [LLVMdev] LLVM and Windows? Message-ID: <4D60AEA0.6010105@lyngvig.org> Hi, This may be a daft question, but I have just begun taking a serious look at LLVM for a project that I am working on. Knowing myself pretty well, the probability that I ever complete the project is infinitesimal. I am saying this so you don't jump up out of your chair, yelling "HOORAY!" because I am considering to use LLVM. Think of me as an academic student with too much time on his hands, who is considering if he dares embark on the adventure of getting to know LLVM. The way I see it, my life is going to be much easier if I can delegate the responsibility for generating good code for a number of targets to you guys and instead focus on what I am trying to do. Also, I particularly like the aspect of global optimizations (link-time optimizations) in LLVM - they're one of the selling features of my project. The project is a new programming language (http://www.braceless.org) for which I have been contemplating writing my own backends, but the more I think of it, the less I like the idea. I know you guys from earlier where I posted a suggestion for an alternate implementation of exceptions (one that uses only a single bit to indicate whether an exception has occured and then uses the ordinary return value registers for the pointer to the exception instance, in the rare event that an exception really happens) and it seems to me that there's a natural match between what you do and what I'd like to do. Now I at least have two problems: 1) I've written my "compiler" (language parser, really) in C# and 2) I don't seem to be able to find any procedures on building LLVM on Windows. The first problem is easy to solve; I'll gladly recode my project in C++ just to get to use LLVM. The other problem is a bit bigger, though: LLVM's Windows support. Do you plan to offer "true" Windows support - i.e. release binaries/libraries for Windows and offer a build system that can be used on Windows? Or is LLVM always going to be a mostly *nix-only project? IF LLVM already supports building on Windows, please don't flame me but simply tell me in nice words that I am a moron and how to build LLVM for Windows. I am mostly interested in native x86_64 support for Windows. If there's anything I can do to help, please don't hesitate to let me know. I am on and off coding on portable build system written in C# for .NET/Mono (portable to a wide variety of hosts), which I could perhaps some day finish up and use to build the Windows release of LLVM. Perhaps I can be of some value as a real-life tester of the Win64 backend? My initial goal is to target Windows x64 first and then later on Windows x86, PPC, and so on. P.S. I have a Windows 7 x64 box and a Debian 6.0 Linux 64-bit PPC box (an ancient iMac G5 converted to a Linux box). I do know Linux and CAN work under Linux, but I prefer to use Windows because of the popularity of this platform and the fact that I have spent the last 20+ years working primarily on the PC/Windows platform. P.P.S. I love writing documentation so I wouldn't mind putting together some docs on how to get flying with LLVM on Windows. Sincerely, Mikael Lyngvig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/908fb8a9/attachment.html From null.function at gmail.com Sun Feb 20 00:16:05 2011 From: null.function at gmail.com (nullnull) Date: Sun, 20 Feb 2011 01:16:05 -0500 Subject: [LLVMdev] LLVM and Windows? In-Reply-To: <4D60AEA0.6010105@lyngvig.org> References: <4D60AEA0.6010105@lyngvig.org> Message-ID: I'm actively working on Windows with LLVM/clang (not directly contributing yet). First of all, it does compile on Windows (only tested in Visual Studio 2010). But, there are still many problems: (1) x86-64 won't compile as far as I know. CMake generates 64-bit soultion, but one project is missing. But, 32-bit solution compiles safely. (2) Although safe compiliation, there are many broken/unimplemented features as of now. I can't detail everything. Some of them are very serious. Currently, LLVM/clang on Windows is very experimental. I'm managed to make it work. I believe the future of LLVM/clang on Windows is very promising. I'm trying to report many bugs as much as I can, and also wish to contribute Windows support! On Sun, Feb 20, 2011 at 1:03 AM, Mikael Lyngvig wrote: > Hi, > > This may be a daft question, but I have just begun taking a serious look at > LLVM for a project that I am working on. Knowing myself pretty well, the > probability that I ever complete the project is infinitesimal. I am saying > this so you don't jump up out of your chair, yelling "HOORAY!" because I am > considering to use LLVM. Think of me as an academic student with too much > time on his hands, who is considering if he dares embark on the adventure of > getting to know LLVM. The way I see it, my life is going to be much easier > if I can delegate the responsibility for generating good code for a number > of targets to you guys and instead focus on what I am trying to do. Also, I > particularly like the aspect of global optimizations (link-time > optimizations) in LLVM - they're one of the selling features of my project. > > The project is a new programming language (http://www.braceless.org) for > which I have been contemplating writing my own backends, but the more I > think of it, the less I like the idea. I know you guys from earlier where I > posted a suggestion for an alternate implementation of exceptions (one that > uses only a single bit to indicate whether an exception has occured and then > uses the ordinary return value registers for the pointer to the exception > instance, in the rare event that an exception really happens) and it seems > to me that there's a natural match between what you do and what I'd like to > do. > > Now I at least have two problems: 1) I've written my "compiler" (language > parser, really) in C# and 2) I don't seem to be able to find any procedures > on building LLVM on Windows. The first problem is easy to solve; I'll > gladly recode my project in C++ just to get to use LLVM. The other problem > is a bit bigger, though: LLVM's Windows support. > > Do you plan to offer "true" Windows support - i.e. release > binaries/libraries for Windows and offer a build system that can be used on > Windows? Or is LLVM always going to be a mostly *nix-only project? > > IF LLVM already supports building on Windows, please don't flame me but > simply tell me in nice words that I am a moron and how to build LLVM for > Windows. I am mostly interested in native x86_64 support for Windows. > > If there's anything I can do to help, please don't hesitate to let me > know. I am on and off coding on portable build system written in C# for > .NET/Mono (portable to a wide variety of hosts), which I could perhaps some > day finish up and use to build the Windows release of LLVM. Perhaps I can > be of some value as a real-life tester of the Win64 backend? My initial > goal is to target Windows x64 first and then later on Windows x86, PPC, and > so on. > > P.S. I have a Windows 7 x64 box and a Debian 6.0 Linux 64-bit PPC box (an > ancient iMac G5 converted to a Linux box). I do know Linux and CAN work > under Linux, but I prefer to use Windows because of the popularity of this > platform and the fact that I have spent the last 20+ years working primarily > on the PC/Windows platform. > > P.P.S. I love writing documentation so I wouldn't mind putting together > some docs on how to get flying with LLVM on Windows. > > > Sincerely, > Mikael Lyngvig > > > _______________________________________________ > 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/20110220/b77bdcb5/attachment.html From mikael at lyngvig.org Sun Feb 20 01:19:58 2011 From: mikael at lyngvig.org (Mikael Lyngvig) Date: Sun, 20 Feb 2011 08:19:58 +0100 Subject: [LLVMdev] Windows/Visual Studio 2010 warnings (WARNINGS!) Message-ID: <4D60C09E.7000402@lyngvig.org> Hi, I stumbled across three warnings in LLVM when building with MS Visual Studio 2010. It has been my experience that different compilers detect different things, so I thought I'd pass them on to you (in case your compiler does not warn about these things): warning C4805: '==' : unsafe mix of type 'bool' and type 'unsigned int' in operation lib\Transforms\IPO\ExtractGV.cpp 58 1 LLVMipo warning C4805: '==' : unsafe mix of type 'bool' and type 'unsigned int' in operation lib\Transforms\IPO\ExtractGV.cpp 68 1 LLVMipo warning C4065: switch statement contains 'default' but no 'case' labels lib\Target\X86\X86GenRegisterInfo.inc 4360 1 LLVMX86CodeGen The two first seem worth some attention, the latter just seems slightly bizarre. Cheers, Mikael P.S. I was thinking you perhaps could make a blinking button labeled "Windows" on the front page of http://www.llvm.org, which when clicked guided people through the steps needed to build on Windows? Just a joke, but I do feel slightly daft. It's all in the docs. It is just that there are so many docs and so little expectation of native Windows support given the fact that you only provide MINGW32 executables. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/79285898/attachment.html From blunted2night at gmail.com Sun Feb 20 01:31:44 2011 From: blunted2night at gmail.com (Nathan Jeffords) Date: Sat, 19 Feb 2011 23:31:44 -0800 Subject: [LLVMdev] LLVM and Windows? In-Reply-To: <4D60AEA0.6010105@lyngvig.org> References: <4D60AEA0.6010105@lyngvig.org> Message-ID: LLVM builds cross platform via CMake, I currently build/debug LLVM and Clang via VS2010 directly from the IDE. The libraries default to static link so they don't need separate distribution.x64 support is not quite their, but x86 is not bad. There are a number of people working on Windows related support for the project. There are instructions on windows builds at http://llvm.org/docs/GettingStartedVS.html. I checkout out trunk from the SVN server, then use CMake to generate a Visual Studio 2010 solution, and then build it from the IDE. On Sat, Feb 19, 2011 at 10:03 PM, Mikael Lyngvig wrote: > Hi, > > This may be a daft question, but I have just begun taking a serious look at > LLVM for a project that I am working on. Knowing myself pretty well, the > probability that I ever complete the project is infinitesimal. I am saying > this so you don't jump up out of your chair, yelling "HOORAY!" because I am > considering to use LLVM. Think of me as an academic student with too much > time on his hands, who is considering if he dares embark on the adventure of > getting to know LLVM. The way I see it, my life is going to be much easier > if I can delegate the responsibility for generating good code for a number > of targets to you guys and instead focus on what I am trying to do. Also, I > particularly like the aspect of global optimizations (link-time > optimizations) in LLVM - they're one of the selling features of my project. > > The project is a new programming language (http://www.braceless.org) for > which I have been contemplating writing my own backends, but the more I > think of it, the less I like the idea. I know you guys from earlier where I > posted a suggestion for an alternate implementation of exceptions (one that > uses only a single bit to indicate whether an exception has occured and then > uses the ordinary return value registers for the pointer to the exception > instance, in the rare event that an exception really happens) and it seems > to me that there's a natural match between what you do and what I'd like to > do. > > Now I at least have two problems: 1) I've written my "compiler" (language > parser, really) in C# and 2) I don't seem to be able to find any procedures > on building LLVM on Windows. The first problem is easy to solve; I'll > gladly recode my project in C++ just to get to use LLVM. The other problem > is a bit bigger, though: LLVM's Windows support. > > Do you plan to offer "true" Windows support - i.e. release > binaries/libraries for Windows and offer a build system that can be used on > Windows? Or is LLVM always going to be a mostly *nix-only project? > > IF LLVM already supports building on Windows, please don't flame me but > simply tell me in nice words that I am a moron and how to build LLVM for > Windows. I am mostly interested in native x86_64 support for Windows. > > If there's anything I can do to help, please don't hesitate to let me > know. I am on and off coding on portable build system written in C# for > .NET/Mono (portable to a wide variety of hosts), which I could perhaps some > day finish up and use to build the Windows release of LLVM. Perhaps I can > be of some value as a real-life tester of the Win64 backend? My initial > goal is to target Windows x64 first and then later on Windows x86, PPC, and > so on. > > P.S. I have a Windows 7 x64 box and a Debian 6.0 Linux 64-bit PPC box (an > ancient iMac G5 converted to a Linux box). I do know Linux and CAN work > under Linux, but I prefer to use Windows because of the popularity of this > platform and the fact that I have spent the last 20+ years working primarily > on the PC/Windows platform. > > P.P.S. I love writing documentation so I wouldn't mind putting together > some docs on how to get flying with LLVM on Windows. > > > Sincerely, > Mikael Lyngvig > > > _______________________________________________ > 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/20110219/57f34cf8/attachment.html From clattner at apple.com Sun Feb 20 02:26:35 2011 From: clattner at apple.com (Chris Lattner) Date: Sun, 20 Feb 2011 00:26:35 -0800 Subject: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule In-Reply-To: <4D6092FE.2080709@rawbw.com> References: <8A8DC54A-1F82-4857-AA49-DDE3467232D2@apple.com> <4D604997.8090903@rawbw.com> <4D6092FE.2080709@rawbw.com> Message-ID: <7BEF1D6E-41FC-4E92-A0AB-E4B4EF502E2D@apple.com> On Feb 19, 2011, at 8:05 PM, Yuri wrote: > On 02/19/2011 14:52, Yuri wrote: >> Will MC path for JNI be included in 2.9? >> > > Sorry. I meant: Will MC path for JIT be included in 2.9? While it would be nice, it doesn't seem like anyone is working on it at the moment. -Chris From zwarich at apple.com Sun Feb 20 02:52:17 2011 From: zwarich at apple.com (Cameron Zwarich) Date: Sun, 20 Feb 2011 00:52:17 -0800 Subject: [LLVMdev] llvm-x86_64-linux-checks bot Message-ID: The llvm-x86_64-linux-checks bot has been out of action for a few days. Does anybody know what's up? It's a pretty useful bot to have, so it would be nice to get it running again. Cameron From baldrick at free.fr Sun Feb 20 03:13:38 2011 From: baldrick at free.fr (Duncan Sands) Date: Sun, 20 Feb 2011 10:13:38 +0100 Subject: [LLVMdev] llvm-x86_64-linux-checks bot In-Reply-To: References: Message-ID: <4D60DB42.7090607@free.fr> Hi Cameron, > The llvm-x86_64-linux-checks bot has been out of action for a few days. Does anybody know what's up? It's a pretty useful bot to have, so it would be nice to get it running again. it looks like the machine was rebooted and the buildbot did not automatically start itself on boot (it's supposed to but I don't think it ever worked properly). I've started it by hand. Ciao, Duncan. From yuri at rawbw.com Sun Feb 20 03:15:21 2011 From: yuri at rawbw.com (Yuri) Date: Sun, 20 Feb 2011 01:15:21 -0800 Subject: [LLVMdev] All variables with the name CS should be renamed into something else due to some conflict on Solaris Message-ID: <4D60DBA9.2050706@rawbw.com> In these two files: AliasSetTracker.h and CallSite.h (and maybe more) variables CS cause compiler errors on Solaris due to some macro definitions. They should be renamed into something else. Could anybody do it so I don't have to invent the new name and create a patch? Thank you, Yuri From zwarich at apple.com Sun Feb 20 03:16:07 2011 From: zwarich at apple.com (Cameron Zwarich) Date: Sun, 20 Feb 2011 01:16:07 -0800 Subject: [LLVMdev] llvm-x86_64-linux-checks bot In-Reply-To: <4D60DB42.7090607@free.fr> References: <4D60DB42.7090607@free.fr> Message-ID: <5DC4539C-4823-442D-848B-6B3BA73CA04F@apple.com> On 2011-02-20, at 1:13 AM, Duncan Sands wrote: > Hi Cameron, > >> The llvm-x86_64-linux-checks bot has been out of action for a few days. Does anybody know what's up? It's a pretty useful bot to have, so it would be nice to get it running again. > > it looks like the machine was rebooted and the buildbot did not automatically > start itself on boot (it's supposed to but I don't think it ever worked > properly). I've started it by hand. Thanks a lot! Individual developers rarely run with expensive checks on in normal development, so this is a big help. Cameron From edwintorok at gmail.com Sun Feb 20 03:33:06 2011 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sun, 20 Feb 2011 11:33:06 +0200 Subject: [LLVMdev] All variables with the name CS should be renamed into something else due to some conflict on Solaris In-Reply-To: <4D60DBA9.2050706@rawbw.com> References: <4D60DBA9.2050706@rawbw.com> Message-ID: <4D60DFD2.4060606@gmail.com> On 2011-02-20 11:15, Yuri wrote: > In these two files: AliasSetTracker.h and CallSite.h (and maybe more) > variables CS cause compiler errors on Solaris due to some macro > definitions. They should be renamed into something else. > Could anybody do it so I don't have to invent the new name and create a > patch? include/llvm/Support/Solaris.h #undef CS ^Doesn't that work? Maybe there is something wrong with the build and Solaris.h is not included everywhere? --Edwin From rengolin at systemcall.org Sun Feb 20 04:00:37 2011 From: rengolin at systemcall.org (Renato Golin) Date: Sun, 20 Feb 2011 10:00:37 +0000 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: On 20 February 2011 01:12, Talin wrote: > OK I switched all my stuff over to use DIBuilder, and you are right - the > arrays don't work. Everything else does though. Phew! I thought I was just being Friday-stupid... ;) There is a very thin line that could make it work (the conversion to MDNode* from operator* and then automatically become a Value*), but I don't think that would work and even if it did, it's bad practice because it's a completely unrelated feature. cheers, --renato From 6yearold at gmail.com Sun Feb 20 05:08:38 2011 From: 6yearold at gmail.com (arrowdodger) Date: Sun, 20 Feb 2011 14:08:38 +0300 Subject: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule In-Reply-To: <7BEF1D6E-41FC-4E92-A0AB-E4B4EF502E2D@apple.com> References: <8A8DC54A-1F82-4857-AA49-DDE3467232D2@apple.com> <4D604997.8090903@rawbw.com> <4D6092FE.2080709@rawbw.com> <7BEF1D6E-41FC-4E92-A0AB-E4B4EF502E2D@apple.com> Message-ID: On Sun, Feb 20, 2011 at 11:26 AM, Chris Lattner wrote: > > On Feb 19, 2011, at 8:05 PM, Yuri wrote: > > > On 02/19/2011 14:52, Yuri wrote: > >> Will MC path for JNI be included in 2.9? > >> > > > > Sorry. I meant: Will MC path for JIT be included in 2.9? > > While it would be nice, it doesn't seem like anyone is working on it at the > moment. > > -Chris What about this: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110207/116194.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/a46112bf/attachment.html From anton at korobeynikov.info Sun Feb 20 06:47:36 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Sun, 20 Feb 2011 15:47:36 +0300 Subject: [LLVMdev] What are the equivalents of gcc inline control options like max-inline-insns-single in clang? In-Reply-To: <4D607F04.70900@rawbw.com> References: <4D607892.4090706@rawbw.com> <96ADC918-058D-443C-B69B-E65F501138DE@apple.com> <4D607F04.70900@rawbw.com> Message-ID: > On 02/19/2011 18:29, Chris Lattner wrote: >> Clang doesn't expose any equivalent > > Why not? Because clang's inlining / optimization stuff is different from gcc's ? Also, such options tend to have different semantics in different versions of the compiler. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From anton at korobeynikov.info Sun Feb 20 06:49:49 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Sun, 20 Feb 2011 15:49:49 +0300 Subject: [LLVMdev] Windows/Visual Studio 2010 warnings (WARNINGS!) In-Reply-To: <4D60C09E.7000402@lyngvig.org> References: <4D60C09E.7000402@lyngvig.org> Message-ID: > P.S. I was thinking you perhaps could make a blinking button labeled > "Windows" on the front page of http://www.llvm.org, which when clicked > guided people through the steps needed to build on Windows? Shouldn't there be a button entitled "Linux" then? And "Mac OS X" ? And "FreeBSD"? ... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From baldrick at free.fr Sun Feb 20 07:23:26 2011 From: baldrick at free.fr (Duncan Sands) Date: Sun, 20 Feb 2011 14:23:26 +0100 Subject: [LLVMdev] Windows/Visual Studio 2010 warnings (WARNINGS!) In-Reply-To: References: <4D60C09E.7000402@lyngvig.org> Message-ID: <4D6115CE.5060106@free.fr> Hi Anton, >> P.S. I was thinking you perhaps could make a blinking button labeled >> "Windows" on the front page of http://www.llvm.org, which when clicked >> guided people through the steps needed to build on Windows? > Shouldn't there be a button entitled "Linux" then? And "Mac OS X" ? > And "FreeBSD"? ... it should be possible to query the browser to find out which O/S it is running on and display the appropriate button :) Ciao, Duncan. From yuri at rawbw.com Sun Feb 20 08:07:36 2011 From: yuri at rawbw.com (Yuri) Date: Sun, 20 Feb 2011 06:07:36 -0800 Subject: [LLVMdev] Windows/Visual Studio 2010 warnings (WARNINGS!) In-Reply-To: <4D60C09E.7000402@lyngvig.org> References: <4D60C09E.7000402@lyngvig.org> Message-ID: <4D612028.8030301@rawbw.com> On 02/19/2011 23:19, Mikael Lyngvig wrote: > P.S. I was thinking you perhaps could make a blinking button labeled > "Windows" on the front page of http://www.llvm.org, which when clicked > guided people through the steps needed to build on Windows? Just a > joke, but I do feel slightly daft. It's all in the docs. It is just > that there are so many docs and so little expectation of native > Windows support given the fact that you only provide MINGW32 executables. This button could also be made to move with the scroll window with some neat JavaScript so it can't be missed. Yuri -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/bd78d2fb/attachment.html From rengolin at systemcall.org Sun Feb 20 08:42:30 2011 From: rengolin at systemcall.org (Renato Golin) Date: Sun, 20 Feb 2011 14:42:30 +0000 Subject: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule In-Reply-To: References: <8A8DC54A-1F82-4857-AA49-DDE3467232D2@apple.com> <4D604997.8090903@rawbw.com> <4D6092FE.2080709@rawbw.com> <7BEF1D6E-41FC-4E92-A0AB-E4B4EF502E2D@apple.com> Message-ID: On 20 February 2011 11:08, arrowdodger <6yearold at gmail.com> wrote: > What about this: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110207/116194.html That doesn't sound stable enough for a release... -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From ofv at wanadoo.es Sun Feb 20 08:51:05 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Sun, 20 Feb 2011 15:51:05 +0100 Subject: [LLVMdev] LLVM and Windows? In-Reply-To: (nullnull's message of "Sun, 20 Feb 2011 01:16:05 -0500") References: <4D60AEA0.6010105@lyngvig.org> Message-ID: <87sjvikbdy.fsf@wanadoo.es> nullnull writes: > I'm actively working on Windows with LLVM/clang (not directly contributing > yet). > > First of all, it does compile on Windows (only tested in Visual Studio > 2010). But, there are still many problems: > > (1) x86-64 won't compile as far as I know. CMake generates 64-bit soultion, > but one project is missing. But, 32-bit solution compiles safely. Building with VS for x86-64 used to work, and *should* work. If it doesn't, please create a bug report describing the problem. > (2) Although safe compiliation, there are many broken/unimplemented features > as of now. I can't detail everything. Some of them are very serious. If those problems are not on the bug database, please report them. > Currently, LLVM/clang on Windows is very experimental. I'm managed to make > it work. I'm successfully using the JIT on Windows (32 bits) since a long time ago. So the level of completeness of LLVM on Windows depends on your needs. > I believe the future of LLVM/clang on Windows is very promising. I'm trying > to report many bugs as much as I can, and also wish to contribute Windows > support! Looking forward to your contributions. But please keep in mind that a good report is a valuable contribution too. From ofv at wanadoo.es Sun Feb 20 08:53:12 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Sun, 20 Feb 2011 15:53:12 +0100 Subject: [LLVMdev] Windows/Visual Studio 2010 warnings (WARNINGS!) References: <4D60C09E.7000402@lyngvig.org> Message-ID: <87oc66kbaf.fsf@wanadoo.es> Mikael Lyngvig writes: [snip] > It is just > that there are so many docs and so little expectation of native > Windows support given the fact that you only provide MINGW32 > executables. Executables created by MinGW are as native as those created by Visual Studio. From anton at korobeynikov.info Sun Feb 20 09:21:52 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Sun, 20 Feb 2011 18:21:52 +0300 Subject: [LLVMdev] Fwd: Windows/Visual Studio 2010 warnings (WARNINGS!) In-Reply-To: <4D6110D6.1080809@lyngvig.org> References: <4D60C09E.7000402@lyngvig.org> <4D6110D6.1080809@lyngvig.org> Message-ID: Forwarding to llvmdev ---------- Forwarded message ---------- From: Mikael Lyngvig Date: Sun, Feb 20, 2011 at 16:02 Subject: Re: [LLVMdev] Windows/Visual Studio 2010 warnings (WARNINGS!) To: Anton Korobeynikov I was joking about the fact that I am only a Windows user (LLVM initially does look rather *nix biased). But I guess you have a valid point.? The problem, as I see it, is that there is a LOT of (great) documentation.? If you stumble across the site and wanna get flying right away, you will hit the ground shortly after. Perhaps something could be done to make life easier on newbies like myself.? Here's a couple of ideas: 1. "The LLVM Getting Started Guide" could be written in bold typeface. 2. At the very top of "The LLVM Getting Started Guide" could be a bold link to the "Getting Started with the LLVM System using Microsoft Visual Studio" page. Those are just my two cents. I didn't intend to imply that Linux, Mac OS X, or FreeBSD guys are less than Windows guys.? More on the contrary (except for the Mac OS X guys).? Most Linux and FreeBSD users know what they are doing. P.S. Has anybody tried building LLVM with the OpenWatcom compiler?? If not, I will give it a try because it is about 10 percent faster than the Microsoft compiler in my 10 year old real-life tests (a print server). Cheers, Mikael Den 20-02-2011 13:49, Anton Korobeynikov skrev: P.S. I was thinking you perhaps could make a blinking button labeled "Windows" on the front page of http://www.llvm.org, which when clicked guided people through the steps needed to build on Windows? Shouldn't there be a button entitled "Linux" then? And "Mac OS X" ? And "FreeBSD"? ... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From lgratian at gmail.com Sun Feb 20 11:30:45 2011 From: lgratian at gmail.com (Gratian Lup) Date: Sun, 20 Feb 2011 19:30:45 +0200 Subject: [LLVMdev] Question about Value Range Propagation Message-ID: Hi! I'm a student who would like to participate on Google SOC for LLVM, and was thinking about what project to pick. I saw on the "Open projects" page that Value Range Propagation is not implemented and thought about doing it, based on a paper by Patterson (it's also used by GCC). But then I saw that last year someone did a Range Analysis pass that seems to do pretty much the same thing, but using a different algorithm. Am I missing something? It's possible that these do something different/have different usage scenarios?. If they are the same, I think it would be better to remove it from the open project list, so other people don't start thinking about how to do it, only to see later that it's already done :) Gratian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/c435f660/attachment.html From andrewah at hotmail.com Sun Feb 20 11:35:09 2011 From: andrewah at hotmail.com (Andrew Hall) Date: Sun, 20 Feb 2011 09:35:09 -0800 (PST) Subject: [LLVMdev] Build problems with llvm-gcc Message-ID: <30971814.post@talk.nabble.com> Hi there I'm new to LLVM & am trying to build llvm-gcc. I'm using Ubuntu 10.0.4. on an AMD64 processor. I've had no problems with building the LLVM suite itself, but during llvm-gcc compilation I am presented with the following error message - does anybody happen to know if there is any remedy? /root/llvm_gcc_source/llvm-gcc-objects/./gcc/xgcc -B/root/llvm_gcc_source/llvm-gcc-objects/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../libdecnumber -I/root/llvm_source/llvm/include -DSHARED -fexceptions -c ../../trunk/gcc/gthr-gnat.c -o libgcc/./gthr-gnat_s.o /root/llvm_gcc_source/llvm-gcc-objects/./gcc/xgcc -B/root/llvm_gcc_source/llvm-gcc-objects/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../libdecnumber -I/root/llvm_source/llvm/include -DSHARED -fexceptions -c ../../trunk/gcc/unwind-c.c -o libgcc/./unwind-c_s.o { nm -pg libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_bswapsi2_s.o libgcc/./_bswapdi2_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o; echo %%; \ cat ../../trunk/gcc/libgcc-std.ver ../../trunk/gcc/config/i386/libgcc-x86_64-glibc.ver \ | sed -e '/^[ ]*#/d' \ -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \ | /root/llvm_gcc_source/llvm-gcc-objects/./gcc/xgcc -B/root/llvm_gcc_source/llvm-gcc-objects/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../libdecnumber -I/root/llvm_source/llvm/include -E -xassembler-with-cpp -; \ } | gawk -f ../../trunk/gcc/mkmap-symver.awk > libgcc/./tmp-libgcc.map mv 'libgcc/./tmp-libgcc.map' libgcc/./libgcc.map /root/llvm_gcc_source/llvm-gcc-objects/./gcc/xgcc -B/root/llvm_gcc_source/llvm-gcc-objects/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_bswapsi2_s.o libgcc/./_bswapdi2_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so *** glibc detected *** /usr/bin/ld: munmap_chunk(): invalid pointer: 0x0000000001d39368 *** ======= Backtrace: ========= /lib/libc.so.6(+0x775b6)[0x2b9876d7f5b6] /usr/lib/libbfd-2.20.1-system.20100303.so(_bfd_elf_discard_section_eh_frame+0x3ee)[0x2b987667c5fe] /usr/lib/libbfd-2.20.1-system.20100303.so(bfd_elf_discard_info+0x2ed)[0x2b98766702cd] /usr/bin/ld[0x41fc5c] /usr/bin/ld[0x413abd] /usr/bin/ld[0x418306] /lib/libc.so.6(__libc_start_main+0xfd)[0x2b9876d26c4d] /usr/bin/ld[0x404269] ======= Memory map: ======== 00400000-00487000 r-xp 00000000 08:01 1316016 /usr/bin/ld.bfd 00686000-00687000 r--p 00086000 08:01 1316016 /usr/bin/ld.bfd 00687000-00688000 rw-p 00087000 08:01 1316016 /usr/bin/ld.bfd 00688000-0068a000 rw-p 00000000 00:00 0 0174d000-01e28000 rw-p 00000000 00:00 0 [heap] 2b98763e4000-2b9876404000 r-xp 00000000 08:01 1046555 /lib/ld-2.11.1.so 2b9876404000-2b9876452000 rw-p 00000000 00:00 0 2b9876603000-2b9876604000 r--p 0001f000 08:01 1046555 /lib/ld-2.11.1.so 2b9876604000-2b9876605000 rw-p 00020000 08:01 1046555 /lib/ld-2.11.1.so 2b9876605000-2b9876606000 rw-p 00000000 00:00 0 2b9876606000-2b98766d7000 r-xp 00000000 08:01 1308238 /usr/lib/libbfd-2.20.1-system.20100303.so 2b98766d7000-2b98768d7000 ---p 000d1000 08:01 1308238 /usr/lib/libbfd-2.20.1-system.20100303.so 2b98768d7000-2b98768e5000 r--p 000d1000 08:01 1308238 /usr/lib/libbfd-2.20.1-system.20100303.so 2b98768e5000-2b98768e8000 rw-p 000df000 08:01 1308238 /usr/lib/libbfd-2.20.1-system.20100303.so 2b98768e8000-2b98768ec000 rw-p 00000000 00:00 0 2b98768ec000-2b98768ee000 r-xp 00000000 08:01 1046657 /lib/libdl-2.11.1.so 2b98768ee000-2b9876aee000 ---p 00002000 08:01 1046657 /lib/libdl-2.11.1.so 2b9876aee000-2b9876aef000 r--p 00002000 08:01 1046657 /lib/libdl-2.11.1.so 2b9876aef000-2b9876af0000 rw-p 00003000 08:01 1046657 /lib/libdl-2.11.1.so 2b9876af0000-2b9876af1000 rw-p 00000000 00:00 0 2b9876af1000-2b9876b07000 r-xp 00000000 08:01 1046967 /lib/libz.so.1.2.3.3 2b9876b07000-2b9876d06000 ---p 00016000 08:01 1046967 /lib/libz.so.1.2.3.3 2b9876d06000-2b9876d07000 r--p 00015000 08:01 1046967 /lib/libz.so.1.2.3.3 2b9876d07000-2b9876d08000 rw-p 00016000 08:01 1046967 /lib/libz.so.1.2.3.3 2b9876d08000-2b9876e82000 r-xp 00000000 08:01 1046641 /lib/libc-2.11.1.so 2b9876e82000-2b9877081000 ---p 0017a000 08:01 1046641 /lib/libc-2.11.1.so 2b9877081000-2b9877085000 r--p 00179000 08:01 1046641 /lib/libc-2.11.1.so 2b9877085000-2b9877086000 rw-p 0017d000 08:01 1046641 /lib/libc-2.11.1.so 2b9877086000-2b987708d000 rw-p 00000000 00:00 0 2b987708d000-2b98770a3000 r-xp 00000000 08:01 1046852 /lib/libgcc_s.so.1 2b98770a3000-2b98772a2000 ---p 00016000 08:01 1046852 /lib/libgcc_s.so.1 2b98772a2000-2b98772a3000 r--p 00015000 08:01 1046852 /lib/libgcc_s.so.1 2b98772a3000-2b98772a4000 rw-p 00016000 08:01 1046852 /lib/libgcc_s.so.1 7fffcf3b1000-7fffcf3c8000 rw-p 00000000 00:00 0 [stack] 7fffcf3ff000-7fffcf400000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] collect2: ld terminated with signal 6 [Aborted] make[3]: *** [libgcc_s.so] Error 1 make[3]: Leaving directory `/root/llvm_gcc_source/llvm-gcc-objects/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/root/llvm_gcc_source/llvm-gcc-objects/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/root/llvm_gcc_source/llvm-gcc-objects' make: *** [all] Error 2 Thanks, Andrew. -- View this message in context: http://old.nabble.com/Build-problems-with-llvm-gcc-tp30971814p30971814.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From clattner at apple.com Sun Feb 20 12:44:54 2011 From: clattner at apple.com (Chris Lattner) Date: Sun, 20 Feb 2011 10:44:54 -0800 Subject: [LLVMdev] What are the equivalents of gcc inline control options like max-inline-insns-single in clang? In-Reply-To: <4D607F04.70900@rawbw.com> References: <4D607892.4090706@rawbw.com> <96ADC918-058D-443C-B69B-E65F501138DE@apple.com> <4D607F04.70900@rawbw.com> Message-ID: <84A757EA-30B3-47F1-9ACA-1AA1D5A699E1@apple.com> On Feb 19, 2011, at 6:40 PM, Yuri wrote: > On 02/19/2011 18:29, Chris Lattner wrote: >> Clang doesn't expose any equivalent > > Why not? It's a policy decision. These flags are not stable but users feel compelled to use them and then stick them in their makefiles. We should aim to make the compiler "do the right thing" (e.g. with just -O2 and -O3) and make that be enough for people. When people add flags like this to their makefiles, future changes in the compiler *pessimize* the code, because the old code tuned against a previous compiler is being built with *wrong* inline thresholds. > Such controls are useful to tune the level of optimization. For example > from my experience forcing more inlining causes code to grow due to > resulting duplication but often such code is also faster. Even though > cache mishits may cause it to slow down too eventually. Speed is vital > for software in many industries. I agree, we should just make the compiler faster without the flags. > User should be able to force-flatten the module leaving only interface > functions. The GCC folks have an __attribute__((flatten)) or something like that, which provides that. This approach allows developers to express their goal, not a random number. > On the other hand user may want to lower the inlining level > to speed up compilation. They can build at -O2. For compiler hackers, the opt/llc command line flags are exposed from clang/llvm-gcc with the -mllvm option. -Chris From pdox at google.com Sun Feb 20 13:54:04 2011 From: pdox at google.com (David Meyer) Date: Sun, 20 Feb 2011 11:54:04 -0800 Subject: [LLVMdev] Is va_arg deprecated? In-Reply-To: References: Message-ID: Sergey, Here's a patch on llvm-gcc which adds a flag "-fuse-llvm-va-arg". (Note that this patch won't ever be part of llvm-gcc upstream. It will most likely be deprecated by later changes.) - pdox -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/f814866f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-gcc-va-arg-2.patch Type: application/octet-stream Size: 5753 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/f814866f/attachment.obj From zwarich at apple.com Sun Feb 20 15:49:34 2011 From: zwarich at apple.com (Cameron Zwarich) Date: Sun, 20 Feb 2011 13:49:34 -0800 Subject: [LLVMdev] ConstantPoolValue lifecycle question Message-ID: I am investigating the leak in MC/ARM/elf-reloc-01.ll on the valgrind bot. It seems to be leaking two MachineConstantPoolValues. When a ConstantPoolSDNode is created with a ConstantPoolValue, it owns that ConstantPoolValue. In InstrEmitter::AddOperand(), the index of the CPV is taken from a MachineConstantPool, which has two cases: 1) This is a new constant, so a new entry is created. The MachineConstantPoolValue is freed in MachineConstantPool's destructor when it iterates over all of the entries in its table. 2) This constant can share an existing entry. The MachineConstantPoolValue is not added to the MachineConstantPool's table and is not freed by MachineConstantPool's destructor. Who owns the ConstantPoolValue in the second case and is responsible for freeing it? Thanks, Cameron From rafael.espindola at gmail.com Sun Feb 20 15:55:07 2011 From: rafael.espindola at gmail.com (=?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?=) Date: Sun, 20 Feb 2011 16:55:07 -0500 Subject: [LLVMdev] How do I free the metadata? Message-ID: <4D618DBB.9020209@gmail.com> LTO is working just fine with Firefox right now, except that I cannot enable debug information. With debug, linking a single .o into a .so with valgrind shows: ==24373== 36,311,472 bytes in 71,717 blocks are possibly lost in loss record 1,192 of 1,192 ==24373== at 0x4C2815C: malloc (vg_replace_malloc.c:236) ==24373== by 0x6CD42C4: llvm::MDNode::getMDNode(llvm::LLVMContext&, llvm::Value* const*, unsigned int, llvm::MDNode::FunctionLocalness, bool) (Metadata.cpp:226) The file itself is 4.5MB, so 36MB from just this allocation spot is a lot. Having 71,717 blocks also suggests that we should be using some pool. For now I would be more then happy if I was just able to free that. lto_module_dispose is being called and the llvm module is being destructed, but it looks like the only way to free the metadata is to destroy the LLVMContext. Is this by design? why? Thanks, Rafael From andreas.faerber at web.de Sun Feb 20 18:23:56 2011 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Mon, 21 Feb 2011 01:23:56 +0100 Subject: [LLVMdev] STM8 backend for Clang Message-ID: <15CFFE06-A81F-4E13-88C6-26A42ABCB476@web.de> Hi there, Inspired by the recent FOSDEM keynote, I've tried to write an LLVM backend for the STM8 microcontroller platform. The STM8S-Discovery evaluation board [1] has been handed out for free or is sold dirt- cheap, but there is no Open Source cross-compiler for it. The available ST assembler, linker and USB flash programmer are closed- source Windows binaries. And the compiler vendor I contacted for an evaluation license has failed to react at all. So, I was hoping to piece together an STM8 backend for LLVM, for Clang to be able to compile C code into STM8 assembler code that - as a first step - I might be able to use with the ST assembler on some Windows box and transfer it to the board there. Here's what I've put together so far: http://repo.or.cz/w/llvm/stm8.git http://repo.or.cz/w/clang/stm8.git The first issue I stumbled upon was that the Program Counter register is 24 bits. It seems that despite having been discussed in the past [2], value type i24 was never added. On my branch I did so and, due to ordering assumptions, had to adjust ~30 type enum values in both files [3]. Would such a binary-incompatible change be acceptable for trunk at all? Further, as pointer width I chose 16 bits since there currently seems to be no way to distinguish between near and far pointers? Anyway, I've put together enough skeleton code to successfully compile, but on Mac OS X v10.5 ppc host this is what I get: $ Debug+Asserts/bin/clang -ccc-host-triple stm8-unknown-elf ../hello.c -S -o ../hello.s 0 clang 0x0168c4f0 llvm::SearchForAddressOfSpecialSymbol(char const*) + 448 1 clang 0x0168cc8c llvm::sys::RunInterruptHandlers() + 456 2 libSystem.B.dylib 0x9422d9fc _sigtramp + 68 3 clang 0x0159692c std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair const&) + 132 4 clang 0x0f1c1cc0 std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair const&) + 230863896 Stack dump: 0. Program arguments: /Users/andreas/STM8S-Discovery/llvm-stm8/Debug +Asserts/bin/clang -cc1 -triple stm8-unknown-elf -S -disable-free - main-file-name hello.c -mrelocation-model static -mdisable-fp-elim - mconstructor-aliases -target-linker-version 85.2.1 -momit-leaf-frame- pointer -resource-dir /Users/andreas/STM8S-Discovery/llvm-stm8/Debug +Asserts/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 274 - fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o ../ hello.s -x c ../hello.c 1. parser at end of file clang: error: unable to execute command: Bus error clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) Same for stm8-unknown-none. Configured with --enable- targets=host,stm8. (It still works for the default Darwin/ppc target.) I'm fairly sure there's things I haven't implemented yet but I'm missing an assertion or error message as hint where to continue. Neither printf()s nor gdb breakpoints in the above llvm::SearchForAddressOfSpecialSymbol() are reached. Any hint what's going wrong or how to debug? Thanks! Regards, Andreas [1] http://www.st.com/stm8s-discovery [2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-November/018663.html [3] http://repo.or.cz/w/llvm/stm8.git/commitdiff/79de4e74e2bc33894cfef4487be06e4005a1a7a0 From eli.friedman at gmail.com Sun Feb 20 19:17:36 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Sun, 20 Feb 2011 17:17:36 -0800 Subject: [LLVMdev] How do I free the metadata? In-Reply-To: <4D618DBB.9020209@gmail.com> References: <4D618DBB.9020209@gmail.com> Message-ID: 2011/2/20 Rafael ?vila de Esp?ndola : > LTO is working just fine with Firefox right now, except that I cannot > enable debug information. > > With debug, linking a single .o into a .so with valgrind shows: > > ==24373== 36,311,472 bytes in 71,717 blocks are possibly lost in loss > record 1,192 of 1,192 > ==24373== ? ?at 0x4C2815C: malloc (vg_replace_malloc.c:236) > ==24373== ? ?by 0x6CD42C4: llvm::MDNode::getMDNode(llvm::LLVMContext&, > llvm::Value* const*, unsigned int, llvm::MDNode::FunctionLocalness, > bool) (Metadata.cpp:226) > > The file itself is 4.5MB, so 36MB from just this allocation spot is a > lot. Having 71,717 blocks also suggests that we should be using some pool. > > For now I would be more then happy if I was just able to free that. > lto_module_dispose is being called and the llvm module is being > destructed, but it looks like the only way to free the metadata is to > destroy the LLVMContext. Is this by design? why? Types, constants, and metadata are all associated with the LLVMContext; the primary reason for this is that it maintains pointer equality across modules, which is nice for cross-module work like linking. It's worth noting there isn't any strong reason to reuse an LLVMContext for multiple modules if you're not using the module linker or something like it. The LLVMContext design was introduced primarily to allow multi-threading, but it can also be used for memory management. -Eli From eli.friedman at gmail.com Sun Feb 20 19:44:53 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Sun, 20 Feb 2011 17:44:53 -0800 Subject: [LLVMdev] STM8 backend for Clang In-Reply-To: <15CFFE06-A81F-4E13-88C6-26A42ABCB476@web.de> References: <15CFFE06-A81F-4E13-88C6-26A42ABCB476@web.de> Message-ID: On Sun, Feb 20, 2011 at 4:23 PM, Andreas F?rber wrote: > Hi there, > > Inspired by the recent FOSDEM keynote, I've tried to write an LLVM > backend for the STM8 microcontroller platform. The STM8S-Discovery > evaluation board [1] has been handed out for free or is sold dirt- > cheap, but there is no Open Source cross-compiler for it. The > available ST assembler, linker and USB flash programmer are closed- > source Windows binaries. And the compiler vendor I contacted for an > evaluation license has failed to react at all. So, I was hoping to > piece together an STM8 backend for LLVM, for Clang to be able to > compile C code into STM8 assembler code that - as a first step - I > might be able to use with the ST assembler on some Windows box and > transfer it to the board there. > > Here's what I've put together so far: > http://repo.or.cz/w/llvm/stm8.git > http://repo.or.cz/w/clang/stm8.git > > The first issue I stumbled upon was that the Program Counter register > is 24 bits. It seems that despite having been discussed in the past > [2], value type i24 was never added. On my branch I did so and, due to > ordering assumptions, had to adjust ~30 type enum values in both files > [3]. Would such a binary-incompatible change be acceptable for trunk > at all? LLVM doesn't do binary compatibility outside of the representation used in bitcode files, so that isn't an issue. That said, if the only 24-bit register is the program counter, you could probably get away with pretending it's a 32-bit register. > Further, as pointer width I chose 16 bits since there currently seems > to be no way to distinguish between near and far pointers? LLVM doesn't support distinguishing between near and far pointers. Depending on how much work you want to put in and what exactly you're trying to build, you might be able to get away with just pretending all pointers are near and implementing __builtin_stm8_far_loadn() and __builtin_stm8_far_storen() intrinsics, though. > Anyway, I've put together enough skeleton code to successfully > compile, but on Mac OS X v10.5 ppc host this is what I get: > > $ Debug+Asserts/bin/clang -ccc-host-triple stm8-unknown-elf ../hello.c > -S -o ../hello.s > 0 ?clang ? ? ? ? ? ? 0x0168c4f0 > llvm::SearchForAddressOfSpecialSymbol(char const*) + 448 > 1 ?clang ? ? ? ? ? ? 0x0168cc8c llvm::sys::RunInterruptHandlers() + 456 > 2 ?libSystem.B.dylib 0x9422d9fc _sigtramp + 68 > 3 ?clang ? ? ? ? ? ? 0x0159692c std::_Rb_tree std::pair, > std::_Select1st >, > std::less, std::allocator llvm::Pass*> > >::_M_insert(std::_Rb_tree_node_base*, > std::_Rb_tree_node_base*, std::pair > const&) + 132 > 4 ?clang ? ? ? ? ? ? 0x0f1c1cc0 std::_Rb_tree std::pair, > std::_Select1st >, > std::less, std::allocator llvm::Pass*> > >::_M_insert(std::_Rb_tree_node_base*, > std::_Rb_tree_node_base*, std::pair > const&) + 230863896 > Stack dump: > 0. ? ? ?Program arguments: /Users/andreas/STM8S-Discovery/llvm-stm8/Debug > +Asserts/bin/clang -cc1 -triple stm8-unknown-elf -S -disable-free - > main-file-name hello.c -mrelocation-model static -mdisable-fp-elim - > mconstructor-aliases -target-linker-version 85.2.1 -momit-leaf-frame- > pointer -resource-dir /Users/andreas/STM8S-Discovery/llvm-stm8/Debug > +Asserts/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 274 - > fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o ../ > hello.s -x c ../hello.c > 1. ? ? ? parser at end of file > clang: error: unable to execute command: Bus error > clang: error: clang frontend command failed due to signal 1 (use -v to > see invocation) > > Same for stm8-unknown-none. Configured with --enable- > targets=host,stm8. (It still works for the default Darwin/ppc target.) > > I'm fairly sure there's things I haven't implemented yet but I'm > missing an assertion or error message as hint where to continue. > Neither printf()s nor gdb breakpoints in the above > llvm::SearchForAddressOfSpecialSymbol() are reached. > > Any hint what's going wrong or how to debug? Thanks! Try valgrind? That looks like some sort of memory corruption bug. -Eli From viridia at gmail.com Sun Feb 20 22:49:51 2011 From: viridia at gmail.com (Talin) Date: Sun, 20 Feb 2011 20:49:51 -0800 Subject: [LLVMdev] A working garbage collector - finally :) Message-ID: Well, after many months of effort, my LLVM-based garbage collector is finally passing its unit tests. This represents a significant milestone for me in the development of my programming language, Tart. The collector itself is fairly rudimentary - a single-generation, copying collector. It does not yet support multi-threaded programs, but in practice there's no serious obstacle to supporting threading due to the fact that the collector does not need any mutable global variables. The stack tracer is based on the paper I posted a few months back, which I have now transferred over to the LLVM wiki. It's meant to be a practical introduction to the task of building a garbage collector in LLVM: http://wiki.llvm.org/Building_a_stack_crawler_in_LLVM Here's a sample of one of the unit tests. It's checking that the tracer can properly distinguish between two states of a union, one state having a traceable object (a String), and the other state containing a non-traceable value (a float): def testCollectUnionLocalVar { var u:String or float = newString("Hello"); tart.gc.GC.collect(); assertTrue(u isa String); assertEq("Hello", typecast[String](u)); u = 1.0; tart.gc.GC.collect(); assertFalse(u isa String); } The heart of the collector is the TraceAction class - which is invoked for each pointer reference. The tracer for the Tart language is written, of course, in Tart, although the style is not the normal Tart style due to the need to deal with low-level objects such as addresses and pointers: private final class TraceActionImpl : TraceAction { protected def tracePointer(ptrAddr:Address[Object]) { let addr:Address[ubyte] = Memory.bitCast(ptrAddr[0]); if fromSpace.contains(addr) { let header:Address[ObjectHeader] = Memory.bitCast(addr); // A gcstate of 0 means that 'header' is the head of a statically // allocated object instance, in which case we need not do // anything since it will be traced as a static root. if (header.gcstate != 0) { if (header.gcstate & uint(GCFlags.RELOCATED)) != 0 { ptrAddr[0] = header.newLocation; } else { let size = header.gcstate & uint(~3); let newAddr:Address[ubyte] = toSpace.alloc(size); Memory.arrayCopy(newAddr, addr, size); header.newLocation = ptrAddr[0] = Memory.bitCast(newAddr); header.gcstate = uint(GCFlags.RELOCATED); } } } } } /** Static instance of the trace action. */ let TRACE_ACTION = TraceActionImpl(); The collect function simply invokes the trace action on the stack roots, the static roots, and the surviving members in the to-space: @LinkageName("GC_collect") def collect() { // Swap the spaces. toSpace, fromSpace = fromSpace, toSpace; toSpace.pos = toSpace.begin; // Trace static roots and runtime stack GCRuntimeSupport.traceStack(TRACE_ACTION); GCRuntimeSupport.traceStaticRoots(TRACE_ACTION); // Trace all remaining live objects. var tracePos = toSpace.begin; while (tracePos < toSpace.pos) { let header:Address[ObjectHeader] = Memory.bitCast(tracePos); let obj:Object = Memory.bitCast[Address[ubyte], Object](tracePos); let length = header.gcstate; TRACE_ACTION.traceObject(obj); tracePos += length; } } If you are curious about the Tart language ("Tart is to C++ as Python is to Perl") you can check it out at http://tart.googlecode.com or join the tart-dev mailing list on Google groups. -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/24e90bd8/attachment.html From yuri at rawbw.com Sun Feb 20 23:16:56 2011 From: yuri at rawbw.com (Yuri) Date: Sun, 20 Feb 2011 21:16:56 -0800 Subject: [LLVMdev] How to force stack alignment for particular target triple in JIT? Message-ID: <4D61F548.4070506@rawbw.com> I get SEGV in gcc-compiled procedure in Solaris10-i386. This procedure is called from llvm JIT code. Exact instruction that crashes is this: movdqa %xmm0, 0x10(%esp) %esp is 8-aligned, and by definition of movdqa it expects 16-aligned stack. This leads me to believe that llvm uses wrong ABI when calling external procedures and doesn't align stack properly. llvm module executing in JIT has this target triple: i386-pc-solaris2.10 Isn't target triple supposed to set correct ABI including stack alignment? How to set the correct alignment for this triple? Yuri From atomicdog.jwm at gmail.com Mon Feb 21 00:14:18 2011 From: atomicdog.jwm at gmail.com (John Myers) Date: Sun, 20 Feb 2011 22:14:18 -0800 Subject: [LLVMdev] Looking for more LLBrowse testers / users In-Reply-To: References: Message-ID: On Sat, Feb 19, 2011 at 12:27 PM, Talin wrote: > LLBrowse - a GUI tool which allows you to inspect the contents of LLVM > modules - now runs on Linux and OS X, and it works with both LLVM 2.8 and > current LLVM head. I've updated the docs to include instructions on checking > out and building the code under several different environments, which you > can read here: > http://llvm.org/svn/llvm-project/llbrowse/trunk/doc/LLBrowse.html (the doc > also includes screenshots.) > > I'm interested in any bug reports or problems folks might have. You can > either reply to this thread or email me privately. > -- > -- Talin > Hi Talin, I still get the same error... /home/john/src/llbrowse/lib/Formatting.cpp: In function ?void printTypeExpansion(wxTextOutputStream&, const llvm::Module*, const llvm::Type*, uint32_t)?: /home/john/src/llbrowse/lib/Formatting.cpp:33: error: ?X86_MMXTyID? is not a member of ?llvm::Type? make[2]: *** [CMakeFiles/llbrowse.dir/lib/Formatting.cpp.o] Error 1 make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 make: *** [all] Error 2 john at ubuntu:~/src/build-llbrowse$ uname -a Linux ubuntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linu If I comment out that line then I get the errors below: john at ubuntu:~/src/build-llbrowse$ make [ 5%] Building CXX object CMakeFiles/llbrowse.dir/lib/Formatting.cpp.o [ 11%] Building CXX object CMakeFiles/llbrowse.dir/lib/DetailsView.cpp.o [ 16%] Building CXX object CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o /home/john/src/llbrowse/lib/TreeView.cpp: In member function ?virtual void DIEItem::ShowDetails(DetailsView*)?: /home/john/src/llbrowse/lib/TreeView.cpp:913: error: ?class llvm::DISubprogram? has no member named ?isPrivate? /home/john/src/llbrowse/lib/TreeView.cpp:914: error: ?class llvm::DISubprogram? has no member named ?isProtected? /home/john/src/llbrowse/lib/TreeView.cpp:915: error: ?class llvm::DISubprogram? has no member named ?isExplicit? /home/john/src/llbrowse/lib/TreeView.cpp:916: error: ?class llvm::DISubprogram? has no member named ?isPrototyped? make[2]: *** [CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o] Error 1 make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 make: *** [all] Error 2 john at ubuntu:~/src/build-llbrowse$ john at ubuntu:~/src/build-llbrowse$ llvm-config --version 2.9svn john at ubuntu:~/src/build-llbrowse$ clang --version clang version 2.9 (trunk 126095) Target: x86_64-unknown-linux-gnu Thread model: posix john at ubuntu:~/src/build-llbrowse$ llc --version Low Level Virtual Machine (http://llvm.org/): llvm version 2.9svn Optimized build with assertions. Built Feb 19 2011 (13:43:27). Host: x86_64-unknown-linux-gnu Host CPU: corei7 Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/cd5ac996/attachment.html From viridia at gmail.com Mon Feb 21 01:05:21 2011 From: viridia at gmail.com (Talin) Date: Sun, 20 Feb 2011 23:05:21 -0800 Subject: [LLVMdev] Looking for more LLBrowse testers / users In-Reply-To: References: Message-ID: Huh, interesting. I must have made an error when I downloaded the 2.8 version of LLVM, because I see that 'isPrivate' isn't there (it was checked in a couple weeks before that, but didn't make the branch cut apparently.) On Sun, Feb 20, 2011 at 10:14 PM, John Myers wrote: > > > On Sat, Feb 19, 2011 at 12:27 PM, Talin wrote: > >> LLBrowse - a GUI tool which allows you to inspect the contents of LLVM >> modules - now runs on Linux and OS X, and it works with both LLVM 2.8 and >> current LLVM head. I've updated the docs to include instructions on checking >> out and building the code under several different environments, which you >> can read here: >> http://llvm.org/svn/llvm-project/llbrowse/trunk/doc/LLBrowse.html (the >> doc also includes screenshots.) >> >> I'm interested in any bug reports or problems folks might have. You can >> either reply to this thread or email me privately. >> -- >> -- Talin >> > > Hi Talin, > > I still get the same error... > /home/john/src/llbrowse/lib/Formatting.cpp: In function ?void > printTypeExpansion(wxTextOutputStream&, const llvm::Module*, const > llvm::Type*, uint32_t)?: > /home/john/src/llbrowse/lib/Formatting.cpp:33: error: ?X86_MMXTyID? is not > a member of ?llvm::Type? > make[2]: *** [CMakeFiles/llbrowse.dir/lib/Formatting.cpp.o] Error 1 > make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 > make: *** [all] Error 2 > john at ubuntu:~/src/build-llbrowse$ uname -a > Linux ubuntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 > x86_64 GNU/Linu > > If I comment out that line then I get the errors below: > john at ubuntu:~/src/build-llbrowse$ make > [ 5%] Building CXX object CMakeFiles/llbrowse.dir/lib/Formatting.cpp.o > [ 11%] Building CXX object CMakeFiles/llbrowse.dir/lib/DetailsView.cpp.o > [ 16%] Building CXX object CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o > /home/john/src/llbrowse/lib/TreeView.cpp: In member function ?virtual void > DIEItem::ShowDetails(DetailsView*)?: > /home/john/src/llbrowse/lib/TreeView.cpp:913: error: ?class > llvm::DISubprogram? has no member named ?isPrivate? > /home/john/src/llbrowse/lib/TreeView.cpp:914: error: ?class > llvm::DISubprogram? has no member named ?isProtected? > /home/john/src/llbrowse/lib/TreeView.cpp:915: error: ?class > llvm::DISubprogram? has no member named ?isExplicit? > /home/john/src/llbrowse/lib/TreeView.cpp:916: error: ?class > llvm::DISubprogram? has no member named ?isPrototyped? > make[2]: *** [CMakeFiles/llbrowse.dir/lib/TreeView.cpp.o] Error 1 > make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 > make: *** [all] Error 2 > john at ubuntu:~/src/build-llbrowse$ > john at ubuntu:~/src/build-llbrowse$ llvm-config --version > 2.9svn > john at ubuntu:~/src/build-llbrowse$ clang --version > clang version 2.9 (trunk 126095) > Target: x86_64-unknown-linux-gnu > Thread model: posix > john at ubuntu:~/src/build-llbrowse$ llc --version > Low Level Virtual Machine (http://llvm.org/): > llvm version 2.9svn > Optimized build with assertions. > Built Feb 19 2011 (13:43:27). > Host: x86_64-unknown-linux-gnu > Host CPU: corei7 > > > > Thanks, > John > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110220/6a00ee8a/attachment.html From baldrick at free.fr Mon Feb 21 01:50:58 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 21 Feb 2011 08:50:58 +0100 Subject: [LLVMdev] How to force stack alignment for particular target triple in JIT? In-Reply-To: <4D61F548.4070506@rawbw.com> References: <4D61F548.4070506@rawbw.com> Message-ID: <4D621962.8040001@free.fr> Hi Yuri, > I get SEGV in gcc-compiled procedure in Solaris10-i386. This procedure > is called from llvm JIT code. > Exact instruction that crashes is this: movdqa %xmm0, 0x10(%esp) > %esp is 8-aligned, and by definition of movdqa it expects 16-aligned stack. > This leads me to believe that llvm uses wrong ABI when calling external > procedures and doesn't align stack properly. > > llvm module executing in JIT has this target triple: i386-pc-solaris2.10 > > Isn't target triple supposed to set correct ABI including stack > alignment? How to set the correct alignment for this triple? it is, however as far as I can see nowhere in LLVM makes any important decisions based on the triple containing "solaris". I suggest you try to work out how the stack alignment is set for other operating systems and send in a patch fixing the solaris case. Ciao, Duncan. From yueguoguo1024 at gmail.com Mon Feb 21 02:27:44 2011 From: yueguoguo1024 at gmail.com (=?GB2312?B?1cXA1g==?=) Date: Mon, 21 Feb 2011 16:27:44 +0800 Subject: [LLVMdev] Questions about LLVM IR encoding Message-ID: Hi all, I am new to LLVM (even the field of compiler) and currently I am engaged in the work of adapting LLVM IR to M5 simulator to observe the enhancement of the novel architecture we design. Simply speaking if you know little about M5, my aim is to know how LLVM IR is interpreted and encoded, then try to implement it in the framework of M5. I have read the LLVM documents, yet I still have some questions as follows: 1. As IR is target-independent, how can we encode them into bit-code executable files without specific targets' information? 2. The "bitstream container format" as the document refers, is XML-like, and I wonder how does LLVM translate it into executable format such as bit-code. I have made several tests as the document suggests, but I conclude with nothing helpful to my work. The result of my experiment is attached. It is a simple add program, and from the bc file generated by llvm-bcanalyzer I cannot relate it to the original IR. For example, the expressions of actually represent those of store i32 1, i32* %a, align 4 store i32 2, i32* %b, align 4 in the .ll file. Despite the explicit opcode matches in the two forms, I am confused of the information of op0, op1 etc in the .bc file. What does it mean? This is not very clearly clarified in the document, or may I omit something? Can anybody please lend me a hand? Thanks very much sincerely! -- *with best regards* Zhang Le -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110221/967ecbec/attachment-0001.html From yueguoguo1024 at gmail.com Mon Feb 21 02:42:22 2011 From: yueguoguo1024 at gmail.com (=?GB2312?B?1cXA1g==?=) Date: Mon, 21 Feb 2011 16:42:22 +0800 Subject: [LLVMdev] Questions about LLVM IR encoding Message-ID: Hi all, I am new to LLVM (even the field of compiler) and currently I am engaged in the work of adapting LLVM IR to M5 simulator to observe the enhancement of the novel architecture we design. Simply speaking if you know little about M5, my aim is to know how LLVM IR is interpreted and encoded, then try to implement it in the framework of M5. I have read the LLVM documents, yet I still have some questions as follows: 1. As IR is target-independent, how can we encode them into bit-code executable files without specific targets' information? 2. The "bitstream container format" as the document refers, is XML-like, and I wonder how does LLVM translate it into executable format such as bit-code. I have made several tests as the document suggests, but I conclude with nothing helpful to my work. The result of my experiment is attached. It is a simple add program, and from the bc file generated by llvm-bcanalyzer I cannot relate it to the original IR. For example, the expressions of actually represent those of store i32 1, i32* %a, align 4 store i32 2, i32* %b, align 4 in the .ll file. Despite the explicit opcode matches in the two forms, I am confused of the information of op0, op1 etc in the .bc file. What does it mean? This is not very clearly clarified in the document, or may I omit something? Can anybody please lend me a hand? Thanks very much sincerely! -- *with best regards* Zhang Le -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110221/1ebc1f8d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: add.ll Type: application/octet-stream Size: 872 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110221/1ebc1f8d/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: add.bc.dump Type: application/octet-stream Size: 6699 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110221/1ebc1f8d/attachment-0001.obj From yuri at rawbw.com Mon Feb 21 03:32:31 2011 From: yuri at rawbw.com (Yuri) Date: Mon, 21 Feb 2011 01:32:31 -0800 Subject: [LLVMdev] How to force stack alignment for particular target triple in JIT? In-Reply-To: <4D621962.8040001@free.fr> References: <4D61F548.4070506@rawbw.com> <4D621962.8040001@free.fr> Message-ID: <4D62312F.5090103@rawbw.com> On 02/20/2011 23:50, Duncan Sands wrote: > Hi Yuri, > > >> I get SEGV in gcc-compiled procedure in Solaris10-i386. This procedure >> is called from llvm JIT code. >> Exact instruction that crashes is this: movdqa %xmm0, 0x10(%esp) >> %esp is 8-aligned, and by definition of movdqa it expects 16-aligned stack. >> This leads me to believe that llvm uses wrong ABI when calling external >> procedures and doesn't align stack properly. >> >> llvm module executing in JIT has this target triple: i386-pc-solaris2.10 >> >> Isn't target triple supposed to set correct ABI including stack >> alignment? How to set the correct alignment for this triple? >> > it is, however as far as I can see nowhere in LLVM makes any important > decisions based on the triple containing "solaris". I suggest you try > to work out how the stack alignment is set for other operating systems > and send in a patch fixing the solaris case. > > Ciao, Duncan The attached patch fixes the problem for me. Though further changes will likely be needed for full Solaris ABI compatibility. Yuri -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110221/ef99d6c5/attachment.txt From Anton.Lokhmotov at arm.com Mon Feb 21 03:45:18 2011 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Mon, 21 Feb 2011 09:45:18 -0000 Subject: [LLVMdev] [PATCH] OpenCL support - update on keywords In-Reply-To: References: <20101216223130.GA1885@pcc.me.uk> <000001cba1f0$873bfe70$95b3fb50$@Lokhmotov@arm.com> <20110104214222.GA22362@pcc.me.uk> <000001cbcf80$512b0b10$f3812130$@Lokhmotov@arm.com> Message-ID: <000001cbd1ac$0cb74ab0$2625e010$@Lokhmotov@arm.com> > > > > +enum OpenCLAddressSpace { > > > > + OPENCL_PRIVATE = 0, > > > > + OPENCL_GLOBAL = 1, > > > > + OPENCL_LOCAL = 2, > > > > + OPENCL_CONSTANT = 3 > > > > +}; > -----Original Message----- > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > Anton, > Would there be any issue with switching the ordering of constant and > local? Hi Micah, We'd rather not do that. First, this order follows the order of subsections in 6.5 of the OpenCL specification, with global described in 6.5.1, local in 6.5.2, constant in 6.5.3; private is described in 6.5.4 but it's also the default function-scope space which is 0. Second, we use the same order in our (non-LLVM) GPU backend. Best regards, Anton. From nicolas.geoffray at gmail.com Mon Feb 21 03:50:43 2011 From: nicolas.geoffray at gmail.com (nicolas geoffray) Date: Mon, 21 Feb 2011 10:50:43 +0100 Subject: [LLVMdev] llvm.gcroot suggestion In-Reply-To: References: Message-ID: Hi Talin, On Fri, Feb 18, 2011 at 5:50 PM, Talin wrote: > > > In the current scheme, the way you tell LLVM that a root is no longer > needed is by assigning NULL to it. However, that assumes that all roots are > pointers, which is not true in my world - a root can be a struct containing > pointers inside of it. (In my current frontend, a non-pointer root is > indicated by passing a non-NULL metadata argument to llvm.gcroot, which > contains information about which fields in the struct are roots. This is > especially important in the case of tagged unions, where the garbage > collector may have to examine the union tag field in order to determine if > the pointer field is indeed a pointer - passing the pointer alone would be > insufficient to determine this.) > For a tagged union, I guess you are currently using the second argument of llvm.gcroot to provde the information? I guess keeping an intrinsic for this kind of code is the best way to go. > Putting GC roots in a different address space works OK for me, as long as I > can have SSA values that are structs that have pointers embedded in them > that are in this different address space. In other words, if I have an SSA > value that is a struct containing pointers which are roots, I need for the > garbage collector to see the entire struct, not just the pointers. > That's entirely fine with a different address space. The roots given by the LLVM GC pass should contain the location of these embedded pointers. > > What I'm primarily asking for is to have the LLVM code generator > automatically spill roots from SSA values to memory during a sync point, and > reload them afterward, > I don't think that's even needed: long term, LLVM should return the location of all roots for a given sync point (typically method call). By all roots, I mean register roots and stack roots. The frontend should then be responsible for updating those roots. > instead of my frontend having to generate code to do this. As I mentioned, > the current scheme results in the frontend having to generate very > inefficient IR because of the need to be conservative about root liveness. > Agree. > The frontend can't know anything about the optimization passes that LLVM > will perform on the function. > Sure. And I think the way to go is to remove the llvm.gcroot intrinsic (and the hackish way it currently works: right now, because we take the address of the alloca, the LLVM optimiziers won't try to optimize an alloca that may escape through the llvm.gcroot function call). By having an address space for GC roots, optimizers don't need to care about anything. After the optimizers and the register allocator, a final LLVM pass should compute the root lists of all sync points. Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110221/550d783d/attachment.html From renato.golin at arm.com Mon Feb 21 04:20:30 2011 From: renato.golin at arm.com (Renato Golin) Date: Mon, 21 Feb 2011 10:20:30 +0000 Subject: [LLVMdev] Debug Information Interface / Documentation Message-ID: Hi all, We had some problems in the past when generating debug information, for which I have started a documentation [1]. The recent change to DIBuilder made it more difficult to check for inconsistencies, since neither the original interface nor the current one are documented. This is creating a lot of problems when integrating our front-end to LLVM and we never quite got the debug information working. From generating wrong information to just plain bad Dwarf (and crashing Dwarf consumers), it's so unreliable that we just can't use it for anything. I recently sent an example where a vanilla Clang/LLVM generates a completely wrong information on ARM. Other front-end developers are reporting the same issues. My concerns are: - The interface documentation [2] is outdated and not detailed enough (as is [3]), so it's hard to know what to generate; - The API is undocumented and it changed recently (also changing the interface slightly), which makes it *very* hard to keep-up; - The end result was (and still is) producing wrong and/or bad Dwarf; - The only documentation we have is the code, which is in constant change and has a lot of context; Can we work out a proper stable interface and, if possible, a reasonably stable API? I'm volunteering (again) to start, but I need help, otherwise it'll be yet another [1]. -- cheers, --renato [1] http://wiki.llvm.org/Debug_Information [2] http://llvm.org/docs/SourceLevelDebugging.html [3] http://llvm.org/docs/LangRef.html From joerg at britannica.bec.de Mon Feb 21 07:25:40 2011 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Mon, 21 Feb 2011 14:25:40 +0100 Subject: [LLVMdev] How to force stack alignment for particular target triple in JIT? In-Reply-To: <4D61F548.4070506@rawbw.com> References: <4D61F548.4070506@rawbw.com> Message-ID: <20110221132539.GA14011@britannica.bec.de> On Sun, Feb 20, 2011 at 09:16:56PM -0800, Yuri wrote: > Isn't target triple supposed to set correct ABI including stack > alignment? How to set the correct alignment for this triple? OSX uses 16 Byte. Linux silently changed the SYSV ABI to 16 Byte alignment as well. The most likely candidate is that all other ELF platforms simply inherited this change. Joerg From baldrick at free.fr Mon Feb 21 08:10:51 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 21 Feb 2011 15:10:51 +0100 Subject: [LLVMdev] Build problems with llvm-gcc In-Reply-To: <30971814.post@talk.nabble.com> References: <30971814.post@talk.nabble.com> Message-ID: <4D62726B.7050108@free.fr> Hi Andrew, > *** glibc detected *** /usr/bin/ld: munmap_chunk(): invalid pointer: > 0x0000000001d39368 *** > ======= Backtrace: ========= > /lib/libc.so.6(+0x775b6)[0x2b9876d7f5b6] > /usr/lib/libbfd-2.20.1-system.20100303.so(_bfd_elf_discard_section_eh_frame+0x3ee)[0x2b987667c5fe] > /usr/lib/libbfd-2.20.1-system.20100303.so(bfd_elf_discard_info+0x2ed)[0x2b98766702cd] this looks like a binutils bug. Try upgrading or downgrading binutils. Ciao, Duncan. From renato.golin at arm.com Mon Feb 21 09:00:14 2011 From: renato.golin at arm.com (Renato Golin) Date: Mon, 21 Feb 2011 15:00:14 +0000 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: On 19 February 2011 04:31, Talin wrote: > A couple of other questions about DIBuilder: > 1) I notice that there's no 'isMain' parameter to CreateCompileUnit. How do > you specify the main module? > 2) There's no means to set TheCU other than creating a new compile unit. > This means that you have to generate all of the debug info for your module > with a single DIBuilder instance, since there's no way to use a pre-existing > compile unit. A few more concerns: By putting the copy ctor in private, I can't define a DIBuilder in a context and assign it later with a respective module (or re-assign it for that matter). To overcome this, I've created a pointer to a DIBuilder and only create it when I have the module information. I have to do this because the front-end is not in C++, so I can't use the ctor init trick on DIBuilder like clang does. But that seems to be getting in the way of the DIDescriptor "operator MDNode *" or whatever is converting a DIDescriptor into a Value* in the code below (CGDebugInfo.cpp): llvm::Value *Subscript = DBuilder.GetOrCreateSubrange(0, NumElems); since GetOrCreateSubrange() returns a DISubrange (not a pointer) both in DIFactory and DIBuilder. Any pointers? (pardon the pun) -- cheers, --renato From florian.merz at kit.edu Mon Feb 21 10:18:12 2011 From: florian.merz at kit.edu (Florian Merz) Date: Mon, 21 Feb 2011 17:18:12 +0100 Subject: [LLVMdev] attaching metadata to llvm::Argument Message-ID: <201102211718.13024.florian.merz@kit.edu> Hey everyone, I'm trying to retrieve information about signed-/unsignedness of an llvm::Argument so I can print out it's value to the user properly. llvm itself doesn't distinguish signed and unsigned and so llvm::Type is of no help here. Checking for nsw/usw is only an unreliable approximation and only available for llvm::Instructions anyways. I tried to use debugging information (llvm::DIType) for this, but getMetadata() is not available for llvm::Argument, only for llvm::Instruction. Is there any other way to get at this information? Regards, Florian From douglasdocouto at gmail.com Mon Feb 21 11:27:01 2011 From: douglasdocouto at gmail.com (Douglas do Couto Teixeira) Date: Mon, 21 Feb 2011 14:27:01 -0300 Subject: [LLVMdev] Question about Value Range Propagation In-Reply-To: References: Message-ID: Hi, Gratian, I did that Summer of Code. I used a different algorithm than Patterson's. It is a constraint system by Su and Wagner, which is more modern, and has some advantages over older works. In particular, it is non-iterative. I found it very hard to compare it with Patterson's analysis, because there is not much description in that paper. However, there is another paper, by Stephenson, which gives a nice description of an iterative analysis. Although I have not compared it with an implementation of Stephenson's algo yet, I believe Su's technique would converge much faster. I have an explanation about our implementation here: ( http://homepages.dcc.ufmg.br/~douglas/RangeAnalysis.html). We have been able to apply it on the whole LLVM test suite, and also on the SPEC CPU 2006 programs. Results are good for small programs (about 40% bitwidth reduction in Stanford benchmark, for instance), but are a bit disappoint for big programs (around 8% reduction for SPEC CPU 2006). In any case, Stephenson's algo probably would lead to the same results, although it does one thing that Su does not do: Stephenson assume that the program is correct, so, upon having a use like a[v], it assumes that v is inside the boundaries of the array, and uses this information to constraint the value range of v a bit more. My work is not part of the LLVM mainline yet. But I would be happy to contribute with the code of my range analysis implementation if it can help you in something else. Best, Douglas On Sun, Feb 20, 2011 at 2:30 PM, Gratian Lup wrote: > Hi! > I'm a student who would like to participate on Google SOC for LLVM, and was > thinking about what project to pick. I saw on the "Open projects" page that > Value Range Propagation is not implemented and thought about doing it, based > on a paper by Patterson (it's also used by GCC). But then I saw that last > year someone did a Range Analysis pass that seems to do pretty much the same > thing, but using a different algorithm. > Am I missing something? It's possible that these do something > different/have different usage scenarios?. > If they are the same, I think it would be better to remove it from the open > project list, so other people don't start thinking about how to do it, only > to see later that it's already done :) > > Gratian > > _______________________________________________ > 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/20110221/41b7da1b/attachment.html From baldrick at free.fr Mon Feb 21 11:41:26 2011 From: baldrick at free.fr (Duncan Sands) Date: Mon, 21 Feb 2011 18:41:26 +0100 Subject: [LLVMdev] How to force stack alignment for particular target triple in JIT? In-Reply-To: <4D62312F.5090103@rawbw.com> References: <4D61F548.4070506@rawbw.com> <4D621962.8040001@free.fr> <4D62312F.5090103@rawbw.com> Message-ID: <4D62A3C6.1000107@free.fr> Hi Yuri, > The attached patch fixes the problem for me. Though further changes will likely > be needed for full Solaris ABI compatibility. I applied this in commit 126130. Ciao, Duncan. From dpatel at apple.com Mon Feb 21 12:17:49 2011 From: dpatel at apple.com (Devang Patel) Date: Mon, 21 Feb 2011 10:17:49 -0800 Subject: [LLVMdev] DIFactory In-Reply-To: References: Message-ID: <4726FF3B-EAA9-4700-8249-6B2E6C6B1047@apple.com> On Feb 18, 2011, at 8:31 PM, Talin wrote: > 2) There's no means to set TheCU other than creating a new compile unit. This means that you have to generate all of the debug info for your module with a single DIBuilder instance, since there's no way to use a pre-existing compile unit. TheCU is an internal debug info information that FE should not care about. DIBuilder is meant to use for one translation unit by FE. If all the internal debug info information is exposed to FE then you'll get DIFactory. - Devang From Micah.Villmow at amd.com Mon Feb 21 12:26:58 2011 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Mon, 21 Feb 2011 12:26:58 -0600 Subject: [LLVMdev] [PATCH] OpenCL support - update on keywords In-Reply-To: <000001cbd1ac$0cb74ab0$2625e010$@Lokhmotov@arm.com> References: <20101216223130.GA1885@pcc.me.uk> <000001cba1f0$873bfe70$95b3fb50$@Lokhmotov@arm.com> <20110104214222.GA22362@pcc.me.uk> <000001cbcf80$512b0b10$f3812130$@Lokhmotov@arm.com> <000001cbd1ac$0cb74ab0$2625e010$@Lokhmotov@arm.com> Message-ID: The problem is that we use the ordering private, global, constant and local, and this is the same ordering that is used on Apple as well. As we already have OpenCL binaries out in public, making the change is problematic as we want to keep backward compatibility at all costs. Thanks, Micah > -----Original Message----- > From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com] > Sent: Monday, February 21, 2011 1:45 AM > To: Villmow, Micah; 'Peter Collingbourne' > Cc: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu > Subject: RE: [PATCH] OpenCL support - update on keywords > > > > > > +enum OpenCLAddressSpace { > > > > > + OPENCL_PRIVATE = 0, > > > > > + OPENCL_GLOBAL = 1, > > > > > + OPENCL_LOCAL = 2, > > > > > + OPENCL_CONSTANT = 3 > > > > > +}; > > > -----Original Message----- > > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > > > Anton, > > Would there be any issue with switching the ordering of constant > and > > local? > > Hi Micah, > > We'd rather not do that. First, this order follows the order of > subsections > in 6.5 of the OpenCL specification, with global described in 6.5.1, > local in > 6.5.2, constant in 6.5.3; private is described in 6.5.4 but it's also > the > default function-scope space which is 0. Second, we use the same order > in > our (non-LLVM) GPU backend. > > Best regards, > Anton. > > > From rengolin at systemcall.org Mon Feb 21 13:07:13 2011 From: rengolin at systemcall.org (Renato Golin) Date: Mon, 21 Feb 2011 19:07:13 +0000 Subject: [LLVMdev] DIFactory In-Reply-To: <4726FF3B-EAA9-4700-8249-6B2E6C6B1047@apple.com> References: <4726FF3B-EAA9-4700-8249-6B2E6C6B1047@apple.com> Message-ID: On 21 February 2011 18:17, Devang Patel wrote: > TheCU is an internal debug info information that FE should not care about. DIBuilder is meant to use for one translation unit by FE. If all the internal debug info information is exposed to FE then you'll get DIFactory. I agree, DIBuilder should not expose its internal structure. This is why, on a C-only world, it's essential that you separate declaration from instantiation on DIBuilder. So far, it's been easy to do that with DIFactory (using a pointer to it), but DIBuilder's get-range makes it difficult. Can you change it to accept a list of DIDescriptors rather than Value*? I think for the metadata it doesn't make any difference and in the back-end you can always convert it. cheers, --renato From dpatel at apple.com Mon Feb 21 13:35:23 2011 From: dpatel at apple.com (Devang Patel) Date: Mon, 21 Feb 2011 11:35:23 -0800 Subject: [LLVMdev] DIFactory In-Reply-To: References: <4726FF3B-EAA9-4700-8249-6B2E6C6B1047@apple.com> Message-ID: <073846E8-838D-408E-8D59-B141CBC94FF7@apple.com> On Feb 21, 2011, at 11:07 AM, Renato Golin wrote: > So far, it's been easy to do that with DIFactory (using a pointer to > it), but DIBuilder's get-range makes it difficult. Can you change it > to accept a list of DIDescriptors rather than Value*? I think for the > metadata it doesn't make any difference and in the back-end you can > always convert it. If you have patch, go ahead, I am fine with it. - Devang From rengolin at systemcall.org Mon Feb 21 13:38:18 2011 From: rengolin at systemcall.org (Renato Golin) Date: Mon, 21 Feb 2011 19:38:18 +0000 Subject: [LLVMdev] DIFactory In-Reply-To: <073846E8-838D-408E-8D59-B141CBC94FF7@apple.com> References: <4726FF3B-EAA9-4700-8249-6B2E6C6B1047@apple.com> <073846E8-838D-408E-8D59-B141CBC94FF7@apple.com> Message-ID: On 21 February 2011 19:35, Devang Patel wrote: > If you have patch, go ahead, I am fine with it. I don't, but can produce one. Will look into it tomorrow morning. cheers, --renato From Micah.Villmow at amd.com Mon Feb 21 16:12:37 2011 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Mon, 21 Feb 2011 16:12:37 -0600 Subject: [LLVMdev] [PATCH] OpenCL support - update on keywords In-Reply-To: References: <20101216223130.GA1885@pcc.me.uk> <000001cba1f0$873bfe70$95b3fb50$@Lokhmotov@arm.com> <20110104214222.GA22362@pcc.me.uk> <000001cbcf80$512b0b10$f3812130$@Lokhmotov@arm.com> <000001cbd1ac$0cb74ab0$2625e010$@Lokhmotov@arm.com> Message-ID: Anton, We have discussed this internally a little bit. What about encoding the address space definition into the data layout string? That way various vendors can be compatible with each other. For example if the CL was generated by clang, it would have: target datalayout = "e-p:32:32:32-addr0:private-addr1:global-addr2:local-addr3:constant-i1:8:8-i8:8:8-i16:16:16" but our frontend would generate: target datalayout = "e-p:32:32:32-addr0:private-addr1:global-addr2:constant-addr3:local-i1:8:8-i8:8:8-i16:16:16" This information can be ignored on platforms that don't support multiple address spaces and would allow dynamic mapping so that the back end's do not need to have different modes for each different frontend. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Villmow, Micah > Sent: Monday, February 21, 2011 10:27 AM > To: Anton.Lokhmotov at arm.com; 'Peter Collingbourne' > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [PATCH] OpenCL support - update on keywords > > The problem is that we use the ordering private, global, constant and > local, and this is the same ordering that is used on Apple as well. As > we already have OpenCL binaries out in public, making the change is > problematic as we want to keep backward compatibility at all costs. > > Thanks, > Micah > > > -----Original Message----- > > From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com] > > Sent: Monday, February 21, 2011 1:45 AM > > To: Villmow, Micah; 'Peter Collingbourne' > > Cc: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu > > Subject: RE: [PATCH] OpenCL support - update on keywords > > > > > > > > +enum OpenCLAddressSpace { > > > > > > + OPENCL_PRIVATE = 0, > > > > > > + OPENCL_GLOBAL = 1, > > > > > > + OPENCL_LOCAL = 2, > > > > > > + OPENCL_CONSTANT = 3 > > > > > > +}; > > > > > -----Original Message----- > > > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > > > > > Anton, > > > Would there be any issue with switching the ordering of constant > > and > > > local? > > > > Hi Micah, > > > > We'd rather not do that. First, this order follows the order of > > subsections > > in 6.5 of the OpenCL specification, with global described in 6.5.1, > > local in > > 6.5.2, constant in 6.5.3; private is described in 6.5.4 but it's also > > the > > default function-scope space which is 0. Second, we use the same > order > > in > > our (non-LLVM) GPU backend. > > > > Best regards, > > Anton. > > > > > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From carl.norum at apple.com Mon Feb 21 16:58:58 2011 From: carl.norum at apple.com (Carl Norum) Date: Mon, 21 Feb 2011 14:58:58 -0800 Subject: [LLVMdev] Passing structures as pointers, MSVC x64 style Message-ID: <3B4C4E79-C7D4-4BF6-9C64-5871B7D2EEC9@apple.com> The MS x64 ABI calling convention (http://msdn.microsoft.com/en-us/library/ms235286(VS.80).aspx) says: Any argument that doesn?t fit in 8 bytes, or is not 1, 2, 4, or 8 bytes, must be passed by reference. Clang isn't doing that for us when passing our triple, x86_64-pc-win32-macho. Here's a simple example program: struct Guid { unsigned int Data1; unsigned short Data2; unsigned short Data3; unsigned char Data4[8]; }; struct Guid g = { 0x8faf43c9, 0x85e9, 0x41f9, { 0xbe, 0x42, 0x99, 0x96, 0x4, 0xe0, 0x85, 0xb3 } }; void v(int, ...); void byValue(void) { v(1, g); } void byReference(void) { v(1, &g); } And the disassembled output: _byValue: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp,%rbp 0000000000000004 subq $0x30,%rsp 0000000000000008 movq 0x00000008(%rip),%rax 000000000000000f movq %rax,0xf8(%rbp) 0000000000000013 movq 0x00000000(%rip),%rax 000000000000001a movq %rax,0xf0(%rbp) 000000000000001e movq 0xf0(%rbp),%rdx 0000000000000022 movq 0xf8(%rbp),%r8 0000000000000026 movl $0x00000001,%ecx 000000000000002b callq 0x00000030 0000000000000030 addq $0x30,%rsp 0000000000000034 popq %rbp 0000000000000035 ret _byReference: 0000000000000040 pushq %rbp 0000000000000041 movq %rsp,%rbp 0000000000000044 subq $0x20,%rsp 0000000000000048 movl $0x00000001,%ecx 000000000000004d leaq 0x00000000(%rip),%rdx 0000000000000054 callq 0x00000059 0000000000000059 addq $0x20,%rsp 000000000000005d popq %rbp 000000000000005e ret The same program's output from MSVC: 0000000000000000 : 0: 48 56 rex.W push %rsi 2: 57 push %rdi 3: 48 83 ec 38 sub $0x38,%rsp 7: 48 8d 44 24 20 lea 0x20(%rsp),%rax c: 48 8d 0d 00 00 00 00 lea 0x0(%rip),%rcx # 13 13: 48 8b f8 mov %rax,%rdi 16: 48 8b f1 mov %rcx,%rsi 19: b9 10 00 00 00 mov $0x10,%ecx 1e: f3 a4 rep movsb %ds:(%rsi),%es:(%rdi) 20: 48 8d 54 24 20 lea 0x20(%rsp),%rdx 25: b9 01 00 00 00 mov $0x1,%ecx 2a: e8 00 00 00 00 callq 2f 2f: 48 83 c4 38 add $0x38,%rsp 33: 5f pop %rdi 34: 5e pop %rsi 0000000000000040 : 40: 48 83 ec 28 sub $0x28,%rsp 44: 48 8d 15 00 00 00 00 lea 0x0(%rip),%rdx # 4b 4b: b9 01 00 00 00 mov $0x1,%ecx 50: e8 00 00 00 00 callq 55 55: 48 83 c4 28 add $0x28,%rsp 59: c3 retq As you can see, MSVC is making a copy of the structure and then passing a pointer to it in the byValue() call, whereas clang is actually stuffing the whole structure into the parameter transfer registers and spilling over onto the stack. Does clang support the MSVC style calling convention? Did I miss something when submitting our earlier patches? Background information - we have a printf-like function in EFI that has a "%g" format string for printing GUIDs. It looks like there's some sloppy code around that calls that print function with GUIDs, rather than with pointers to GUIDs as the print function expects. On MSVC, because of this calling convention detail, it works fine - clang-built ROMs crash spectacularly. Thanks for any suggestions or ideas! I'll happily try to come up with a patch if someone can point me in the right general direction in the source tree! -- Carl From rafael.espindola at gmail.com Mon Feb 21 17:38:04 2011 From: rafael.espindola at gmail.com (=?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?=) Date: Mon, 21 Feb 2011 18:38:04 -0500 Subject: [LLVMdev] How do I free the metadata? In-Reply-To: References: <4D618DBB.9020209@gmail.com> Message-ID: <4D62F75C.1040304@gmail.com> > Types, constants, and metadata are all associated with the > LLVMContext; the primary reason for this is that it maintains pointer > equality across modules, which is nice for cross-module work like > linking. > > It's worth noting there isn't any strong reason to reuse an > LLVMContext for multiple modules if you're not using the module linker > or something like it. The LLVMContext design was introduced primarily > to allow multi-threading, but it can also be used for memory > management. I could try that, but using the plugin in nm and ar is a degenerate case. Once that works the build will get to the linker... Shouldn't we at least free the metadata when no module is using it? The metadata in a debug build is a lot larger than the IL itself... > -Eli Cheers, Rafael From echristo at apple.com Mon Feb 21 17:58:19 2011 From: echristo at apple.com (Eric Christopher) Date: Mon, 21 Feb 2011 15:58:19 -0800 Subject: [LLVMdev] llvm-gcc4.2 bootstrap broken? In-Reply-To: <20110219192554.GA5200@bromo.med.uc.edu> References: <20110219192554.GA5200@bromo.med.uc.edu> Message-ID: <643ED677-87D5-41ED-8355-852CB4C7E862@apple.com> On Feb 19, 2011, at 11:25 AM, Jack Howarth wrote: > Is anyone able to bootstrap llvm-gcc42 svn on x86_64-apple-darwin10? Currently it is > failing here with... It was broken. I think I've fixed it in reverting 125960. -eric From yuri at rawbw.com Mon Feb 21 18:03:32 2011 From: yuri at rawbw.com (Yuri) Date: Mon, 21 Feb 2011 16:03:32 -0800 Subject: [LLVMdev] How to force stack alignment for particular target triple in JIT? In-Reply-To: <20110221132539.GA14011@britannica.bec.de> References: <4D61F548.4070506@rawbw.com> <20110221132539.GA14011@britannica.bec.de> Message-ID: <4D62FD54.6030209@rawbw.com> On 02/21/2011 05:25, Joerg Sonnenberger wrote: > OSX uses 16 Byte. Linux silently changed the SYSV ABI to 16 Byte > alignment as well. The most likely candidate is that all other ELF > platforms simply inherited this change. > It turns out that Solaris (and FreeBSD) is supposed to be SYSV compliant and should have word stack alignment. gcc probably made a sweeping change once linux decided to change stack alignment. I filed gcc PR asking gcc to revert their behavior back to prescribed by documentation: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 So my previous patch is more for gcc compatibility, rather than a permanent correction. Yuri From geek4civic at gmail.com Mon Feb 21 18:51:15 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Tue, 22 Feb 2011 09:51:15 +0900 Subject: [LLVMdev] Passing structures as pointers, MSVC x64 style In-Reply-To: <3B4C4E79-C7D4-4BF6-9C64-5871B7D2EEC9@apple.com> References: <3B4C4E79-C7D4-4BF6-9C64-5871B7D2EEC9@apple.com> Message-ID: Carl, See clang/lib/CodeGen/TargetInfo.cpp. // FIXME: mingw64-gcc emits 128-bit struct as i128 if (Size <= 128 && (Size & (Size - 1)) == 0) return ABIArgInfo::getDirect(llvm::IntegerType::get(getVMContext(), Size)); It was my workaround, sorry. Please check to tweak the clause (128 to 64) and lemme know. ...Takumi On Tue, Feb 22, 2011 at 7:58 AM, Carl Norum wrote: > > The MS x64 ABI calling convention (http://msdn.microsoft.com/en-us/library/ms235286(VS.80).aspx) says: > > ? ?Any argument that doesn?t fit in 8 bytes, or is not 1, 2, 4, or 8 bytes, must be passed by reference. > > Clang isn't doing that for us when passing our triple, x86_64-pc-win32-macho. > > Here's a simple example program: > > ? ?struct Guid { > ? ? ?unsigned int ? ?Data1; > ? ? ?unsigned short ?Data2; > ? ? ?unsigned short ?Data3; > ? ? ?unsigned char ? Data4[8]; > ? ?}; > > ? ?struct Guid g = { 0x8faf43c9, 0x85e9, 0x41f9, { 0xbe, 0x42, 0x99, 0x96, 0x4, 0xe0, 0x85, 0xb3 } }; > > ? ?void v(int, ...); > > ? ?void byValue(void) > ? ?{ > ? ? ?v(1, g); > ? ?} > > ? ?void byReference(void) > ? ?{ > ? ? ?v(1, &g); > ? ?} > > And the disassembled output: > > ? ?_byValue: > ? ?0000000000000000 ? ?pushq ? %rbp > ? ?0000000000000001 ? ?movq ? ?%rsp,%rbp > ? ?0000000000000004 ? ?subq ? ?$0x30,%rsp > ? ?0000000000000008 ? ?movq ? ?0x00000008(%rip),%rax > ? ?000000000000000f ? ?movq ? ?%rax,0xf8(%rbp) > ? ?0000000000000013 ? ?movq ? ?0x00000000(%rip),%rax > ? ?000000000000001a ? ?movq ? ?%rax,0xf0(%rbp) > ? ?000000000000001e ? ?movq ? ?0xf0(%rbp),%rdx > ? ?0000000000000022 ? ?movq ? ?0xf8(%rbp),%r8 > ? ?0000000000000026 ? ?movl ? ?$0x00000001,%ecx > ? ?000000000000002b ? ?callq ? 0x00000030 > ? ?0000000000000030 ? ?addq ? ?$0x30,%rsp > ? ?0000000000000034 ? ?popq ? ?%rbp > ? ?0000000000000035 ? ?ret > > ? ?_byReference: > ? ?0000000000000040 ? ?pushq ? %rbp > ? ?0000000000000041 ? ?movq ? ?%rsp,%rbp > ? ?0000000000000044 ? ?subq ? ?$0x20,%rsp > ? ?0000000000000048 ? ?movl ? ?$0x00000001,%ecx > ? ?000000000000004d ? ?leaq ? ?0x00000000(%rip),%rdx > ? ?0000000000000054 ? ?callq ? 0x00000059 > ? ?0000000000000059 ? ?addq ? ?$0x20,%rsp > ? ?000000000000005d ? ?popq ? ?%rbp > ? ?000000000000005e ? ?ret > > The same program's output from MSVC: > > ? ?0000000000000000 : > ? ? ? 0: ? 48 56 ? ? ? ? ? ? ? ? ? rex.W push ? %rsi > ? ? ? 2: ? 57 ? ? ? ? ? ? ? ? ? ? ?push ? %rdi > ? ? ? 3: ? 48 83 ec 38 ? ? ? ? ? ? sub ? ?$0x38,%rsp > ? ? ? 7: ? 48 8d 44 24 20 ? ? ? ? ?lea ? ?0x20(%rsp),%rax > ? ? ? c: ? 48 8d 0d 00 00 00 00 ? ?lea ? ?0x0(%rip),%rcx ? ? ? ?# 13 > ? ? ?13: ? 48 8b f8 ? ? ? ? ? ? ? ?mov ? ?%rax,%rdi > ? ? ?16: ? 48 8b f1 ? ? ? ? ? ? ? ?mov ? ?%rcx,%rsi > ? ? ?19: ? b9 10 00 00 00 ? ? ? ? ?mov ? ?$0x10,%ecx > ? ? ?1e: ? f3 a4 ? ? ? ? ? ? ? ? ? rep movsb %ds:(%rsi),%es:(%rdi) > ? ? ?20: ? 48 8d 54 24 20 ? ? ? ? ?lea ? ?0x20(%rsp),%rdx > ? ? ?25: ? b9 01 00 00 00 ? ? ? ? ?mov ? ?$0x1,%ecx > ? ? ?2a: ? e8 00 00 00 00 ? ? ? ? ?callq ?2f > ? ? ?2f: ? 48 83 c4 38 ? ? ? ? ? ? add ? ?$0x38,%rsp > ? ? ?33: ? 5f ? ? ? ? ? ? ? ? ? ? ?pop ? ?%rdi > ? ? ?34: ? 5e ? ? ? ? ? ? ? ? ? ? ?pop ? ?%rsi > > ? ?0000000000000040 : > ? ? ?40: ? 48 83 ec 28 ? ? ? ? ? ? sub ? ?$0x28,%rsp > ? ? ?44: ? 48 8d 15 00 00 00 00 ? ?lea ? ?0x0(%rip),%rdx ? ? ? ?# 4b > ? ? ?4b: ? b9 01 00 00 00 ? ? ? ? ?mov ? ?$0x1,%ecx > ? ? ?50: ? e8 00 00 00 00 ? ? ? ? ?callq ?55 > ? ? ?55: ? 48 83 c4 28 ? ? ? ? ? ? add ? ?$0x28,%rsp > ? ? ?59: ? c3 ? ? ? ? ? ? ? ? ? ? ?retq > > As you can see, MSVC is making a copy of the structure and then passing a pointer to it in the byValue() call, whereas clang is actually stuffing the whole structure into the parameter transfer registers and spilling over onto the stack. ?Does clang support the MSVC style calling convention? ?Did I miss something when submitting our earlier patches? > > Background information - we have a printf-like function in EFI that has a "%g" format string for printing GUIDs. ?It looks like there's some sloppy code around that calls that print function with GUIDs, rather than with pointers to GUIDs as the print function expects. ?On MSVC, because of this calling convention detail, it works fine - clang-built ROMs crash spectacularly. > > Thanks for any suggestions or ideas! ?I'll happily try to come up with a patch if someone can point me in the right general direction in the source tree! > > -- Carl > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From carl.norum at apple.com Mon Feb 21 19:31:16 2011 From: carl.norum at apple.com (Carl Norum) Date: Mon, 21 Feb 2011 17:31:16 -0800 Subject: [LLVMdev] Passing structures as pointers, MSVC x64 style In-Reply-To: References: <3B4C4E79-C7D4-4BF6-9C64-5871B7D2EEC9@apple.com> Message-ID: <0896F0EA-F14D-435F-9A76-2AA81B095DA8@apple.com> On Feb 21, 2011, at 4:51 PM, NAKAMURA Takumi wrote: > Carl, > > See clang/lib/CodeGen/TargetInfo.cpp. > > // FIXME: mingw64-gcc emits 128-bit struct as i128 > if (Size <= 128 && > (Size & (Size - 1)) == 0) > return ABIArgInfo::getDirect(llvm::IntegerType::get(getVMContext(), > Size)); > > It was my workaround, sorry. > Please check to tweak the clause (128 to 64) and lemme know. Hi Takumi, I think you hit the nail on the head with that one. Changing that constant to 64 seems to have done the trick. Here's the new disassembled output: _byValue: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp,%rbp 0000000000000004 subq $0x30,%rsp 0000000000000008 leaq 0xf0(%rbp),%rdx 000000000000000c movq 0x00000008(%rip),%rax 0000000000000013 movq %rax,0xf8(%rbp) 0000000000000017 movq 0x00000000(%rip),%rax 000000000000001e movq %rax,0xf0(%rbp) 0000000000000022 movl $0x00000001,%ecx 0000000000000027 callq 0x0000002c 000000000000002c addq $0x30,%rsp 0000000000000030 popq %rbp 0000000000000031 ret %rdx is now getting the address of a copy of the struct! Patch attached; if it looks good to you I'll commit it. -- Carl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msabi_patch.txt Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110221/8968ede5/attachment.txt From felixcca at yahoo.ca Mon Feb 21 20:31:43 2011 From: felixcca at yahoo.ca (=?iso-8859-1?Q?F=E9lix_Cloutier?=) Date: Mon, 21 Feb 2011 21:31:43 -0500 Subject: [LLVMdev] Can I use Clang to parse snippets of C++ code? Message-ID: <2FB507D0-B596-4769-9AF8-FF69DFA87A93@yahoo.ca> Hello guys, I'd like to use Clang to parse snippets of (and emit bytecode for) C++ code that come from larger files that don't contain only C++, but looking at the clang interpreter example, either I didn't get it, or it looks like the driver expects only files, and not strings or char buffers. Is there a simple way to achieve this? Do I have to split my input into small files and pass them to clang, or is there a better way? F?lix From reid.kleckner at gmail.com Mon Feb 21 20:45:33 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Mon, 21 Feb 2011 21:45:33 -0500 Subject: [LLVMdev] Can I use Clang to parse snippets of C++ code? In-Reply-To: <2FB507D0-B596-4769-9AF8-FF69DFA87A93@yahoo.ca> References: <2FB507D0-B596-4769-9AF8-FF69DFA87A93@yahoo.ca> Message-ID: The semantics of C++ depend heavily on what comes before the given fragment. How do you plan to address this? For example, if you know all the headers you think these snippets will include, you can do something similar to PCH to parse the fragment in context of all of the headers. I don't know much about feeding clang buffers instead of files, but I believe it can be done with some of the "virtual" file suport that has been added recently. Reid 2011/2/21 F?lix Cloutier : > Hello guys, > > I'd like to use Clang to parse snippets of (and emit bytecode for) C++ code that come from larger files that don't contain only C++, but looking at the clang interpreter example, either I didn't get it, or it looks like the driver expects only files, and not strings or char buffers. > > Is there a simple way to achieve this? Do I have to split my input into small files and pass them to clang, or is there a better way? > > F?lix > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From felixcca at yahoo.ca Mon Feb 21 21:24:24 2011 From: felixcca at yahoo.ca (=?iso-8859-1?Q?F=E9lix_Cloutier?=) Date: Mon, 21 Feb 2011 22:24:24 -0500 Subject: [LLVMdev] Can I use Clang to parse snippets of C++ code? In-Reply-To: References: <2FB507D0-B596-4769-9AF8-FF69DFA87A93@yahoo.ca> Message-ID: Yup, I know beforehand everything that needs to be included or declared, so this is not an issue. It *would* work if I made individual files, but it doesn't look like a very intuitive way to do it. I'll look into PCH. I was a little bit startled when I opened the index.html file docs/; at least there seems to be a lot of documentation inside the code. F?lix Le 2011-02-21 ? 21:45:33, Reid Kleckner a ?crit : > The semantics of C++ depend heavily on what comes before the given > fragment. How do you plan to address this? For example, if you know > all the headers you think these snippets will include, you can do > something similar to PCH to parse the fragment in context of all of > the headers. > > I don't know much about feeding clang buffers instead of files, but I > believe it can be done with some of the "virtual" file suport that has > been added recently. > > Reid > > 2011/2/21 F?lix Cloutier : >> Hello guys, >> >> I'd like to use Clang to parse snippets of (and emit bytecode for) C++ code that come from larger files that don't contain only C++, but looking at the clang interpreter example, either I didn't get it, or it looks like the driver expects only files, and not strings or char buffers. >> >> Is there a simple way to achieve this? Do I have to split my input into small files and pass them to clang, or is there a better way? >> >> F?lix >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> From clattner at apple.com Mon Feb 21 22:35:55 2011 From: clattner at apple.com (Chris Lattner) Date: Mon, 21 Feb 2011 20:35:55 -0800 Subject: [LLVMdev] Can I use Clang to parse snippets of C++ code? In-Reply-To: <2FB507D0-B596-4769-9AF8-FF69DFA87A93@yahoo.ca> References: <2FB507D0-B596-4769-9AF8-FF69DFA87A93@yahoo.ca> Message-ID: On Feb 21, 2011, at 6:31 PM, F?lix Cloutier wrote: > Hello guys, > > I'd like to use Clang to parse snippets of (and emit bytecode for) C++ code that come from larger files that don't contain only C++, but looking at the clang interpreter example, either I didn't get it, or it looks like the driver expects only files, and not strings or char buffers. > > Is there a simple way to achieve this? Do I have to split my input into small files and pass them to clang, or is there a better way? It depends on exactly what you're trying to achieve. LLDB uses clang to parse individual expressions, and does this by hooking into various name lookup routines to dynamically/lazily populate symbol tables from debug info. This is all possible, but it's a nontrivial amount of work. -Chris From alexdura at gmail.com Tue Feb 22 02:40:47 2011 From: alexdura at gmail.com (Alexandru Dura) Date: Tue, 22 Feb 2011 10:40:47 +0200 Subject: [LLVMdev] unary floating point operations using clang Message-ID: Hello, Is there a way of generating unary floating point operations (like ISD::FABS, ISD::FSIN, ...) from C code using clang? I am building a backend for a machine that has hw support for these ops and I need a way to test them. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/32cd0699/attachment.html From xinfinity_a at yahoo.com Tue Feb 22 04:27:46 2011 From: xinfinity_a at yahoo.com (Xinfinity) Date: Tue, 22 Feb 2011 02:27:46 -0800 (PST) Subject: [LLVMdev] llvm2.8 -insert-function-profiling Message-ID: <30984547.post@talk.nabble.com> Hi, I intend to use llvm profiling to check my code and I am interested in counting the calls per function. I have used profile.pl -function code.bc but I get the error: opt: Unknown command line argument '-insert-function-profiling'. Try: 'opt -help' Indeed, -insert-function-profiling is not listed as one of the options for opt, displayed by opt -help. I am using llvm 2.8. what could be the problem? If I test with -edge, the tool requires an input code which contains the main function. Since I test the SPEC CPU 2006 benches, the source code is split in multiple files. How can I use the llvm profiler to obtain the most frequently called functions in the whole program. I mention that I transform each *.c file into a *.bc file to process it and then link them together. Thanks, Alexandra -- View this message in context: http://old.nabble.com/llvm2.8---insert-function-profiling-tp30984547p30984547.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From abel at ispras.ru Tue Feb 22 04:33:10 2011 From: abel at ispras.ru (Andrey Belevantsev) Date: Tue, 22 Feb 2011 13:33:10 +0300 Subject: [LLVMdev] Question about Value Range Propagation In-Reply-To: References: Message-ID: <4D6390E6.5060805@ispras.ru> Hi Douglas, On 21.02.2011 20:27, Douglas do Couto Teixeira wrote: > My work is not part of the LLVM mainline yet. But I would be happy to > contribute with the code of my range analysis implementation if it can help > you in something else. We were thinking of adding VRP to LLVM too, though we were mostly interested in Patterson's approach (i.e. not connected with SSI form). It would be great if you can share the code nevertheless. Andrey From baldrick at free.fr Tue Feb 22 04:33:37 2011 From: baldrick at free.fr (Duncan Sands) Date: Tue, 22 Feb 2011 11:33:37 +0100 Subject: [LLVMdev] Questions about LLVM IR encoding In-Reply-To: References: Message-ID: <4D639101.3060505@free.fr> Hi ??, > Hi all, I am new to LLVM (even the field of compiler) and currently I am engaged > in the work of adapting LLVM IR to M5 simulator to observe the enhancement of > the novel architecture we design. > Simply speaking if you know little about M5, my aim is to know how LLVM IR is > interpreted and encoded, then try to implement it in the framework of M5. > I have read the LLVM documents, yet I still have some questions as follows: > 1. As IR is target-independent, how can we encode them into bit-code executable > files without specific targets' information? I don't know what you mean by a "bit-code executable". However if you want to run bitcode (eg: by compiling to a native program using llc, or using the JIT or interpreter lli) then at that moment you need to specify the target if you did not specify it before (the target can be specified in the bitcode). > 2. The "bitstream container format" as the document refers, is XML-like, and I > wonder how does LLVM translate it into executable format such as bit-code. You should have no need to deal directly with the on-disk bitcode format. Again I am not sure what you mean when you call bit-code an "executable format". Ciao, Duncan. > I have made several tests as the document suggests, but I conclude with > nothing helpful to my work. > The result of my experiment is attached. > It is a simple add program, and from the bc file generated by > llvm-bcanalyzer I cannot relate it to the original IR. > For example, the expressions of > > > actually represent those of > store i32 1, i32* %a, align 4 > store i32 2, i32* %b, align 4 > in the .ll file. > Despite the explicit opcode matches in the two forms, I am confused of the > information of op0, op1 etc in the .bc file. > What does it mean? This is not very clearly clarified in the document, or > may I omit something? > > Can anybody please lend me a hand? > Thanks very much sincerely! > > -- > /with best regards / > Zhang Le > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From baldrick at free.fr Tue Feb 22 05:19:58 2011 From: baldrick at free.fr (Duncan Sands) Date: Tue, 22 Feb 2011 12:19:58 +0100 Subject: [LLVMdev] Question about Value Range Propagation In-Reply-To: <4D6390E6.5060805@ispras.ru> References: <4D6390E6.5060805@ispras.ru> Message-ID: <4D639BDE.7050105@free.fr> Hi Andrey, > On 21.02.2011 20:27, Douglas do Couto Teixeira wrote: >> My work is not part of the LLVM mainline yet. But I would be happy to >> contribute with the code of my range analysis implementation if it can help >> you in something else. > We were thinking of adding VRP to LLVM too, though we were mostly > interested in Patterson's approach (i.e. not connected with SSI form). It > would be great if you can share the code nevertheless. the big problem with Patterson's VRP is that it is expensive in terms of compile time. LLVM used to have some passes (ABCD, predsimplify) that did this kind of thing, but they were removed essentially because their compile time was too great for the goodness they brought. Ciao, Duncan. From reid.kleckner at gmail.com Tue Feb 22 09:25:21 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Tue, 22 Feb 2011 10:25:21 -0500 Subject: [LLVMdev] Question about Value Range Propagation In-Reply-To: <4D639BDE.7050105@free.fr> References: <4D6390E6.5060805@ispras.ru> <4D639BDE.7050105@free.fr> Message-ID: On Tue, Feb 22, 2011 at 6:19 AM, Duncan Sands wrote: > the big problem with Patterson's VRP is that it is expensive in terms of > compile time. ?LLVM used to have some passes (ABCD, predsimplify) that did > this kind of thing, but they were removed essentially because their compile > time was too great for the goodness they brought. Any reason not to just leave them on at O3? Based on the discussion around your simple condition propagation pass, it seemed predsimplify did delete dead code, but it didn't really improve generated code performance. O3 seems the appropriate place to put expensive optimizations with diminishing returns. Reid From rengolin at systemcall.org Tue Feb 22 09:40:19 2011 From: rengolin at systemcall.org (Renato Golin) Date: Tue, 22 Feb 2011 15:40:19 +0000 Subject: [LLVMdev] DIFactory In-Reply-To: References: <4726FF3B-EAA9-4700-8249-6B2E6C6B1047@apple.com> <073846E8-838D-408E-8D59-B141CBC94FF7@apple.com> Message-ID: On 21 February 2011 19:38, Renato Golin wrote: > On 21 February 2011 19:35, Devang Patel wrote: >> If you have patch, go ahead, I am fine with it. Hi Devang, After meddling with CGDebugInfo, I now know why GetOrCreateArray accepts a list of Value** instead of DIDescriptors: arrays are used for many other things than just types. Talin, To make arrays work you just need to include "Metadata.h" in your file. When forcing a conversion through MDNode* -> Value*, I finally got a meaningful error "MDNode type is incomplete", that led me to including Metadata and getting the behaviour CGDebugInfo has when putting DISubrange into a Value* vector. cheers, --renato From patrick.rieder at online.de Tue Feb 22 09:42:41 2011 From: patrick.rieder at online.de (patrick.rieder at online.de) Date: Tue, 22 Feb 2011 16:42:41 +0100 (CET) Subject: [LLVMdev] Instruction Selection: Splitting instruction selection and scheduling Message-ID: <1377183358.1684173.1298389361130.JavaMail.tomcat55@mrmseu1.kundenserver.de> An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/5b1c122c/attachment.html -------------- next part -------------- Hi, I'm currently working on an optimization pass, that requires the execution between instruction selection and scheduling. In addition, this pass is working on MachineFunction/Function level. Therefore it's necessary, that the instruction selection for the whole Function is completed before any scheduling is done. After the optimization pass had completed it's work, the regular scheduling should start. Is there a way to split those two phases and let the instruction selection complete for all basic blocks, before the scheduling starts? A second question: Requires the instruction selection of a basic block the completion of scheduling of previous basic blocks? Regards, Patrick From douglasdocouto at gmail.com Tue Feb 22 10:21:26 2011 From: douglasdocouto at gmail.com (Douglas do Couto Teixeira) Date: Tue, 22 Feb 2011 13:21:26 -0300 Subject: [LLVMdev] Question about Value Range Propagation In-Reply-To: <4D639BDE.7050105@free.fr> References: <4D6390E6.5060805@ispras.ru> <4D639BDE.7050105@free.fr> Message-ID: Hi, guys, my current implementation goes over the whole LLVM test suite plus SPEC CPU 2006 in less than one minute. So, in term of runtime, the results seem good. However, the analysis is not very precise yet. Compared to Stephenson's original work, I reduce about 31% of the bits from bitwise (Stephenson's benchmark). He reduced it by 53%. But he would assume that the program was correct. So, if he found an operand like a[v], he could assume that v < size(a). Or, if he found an instruction like a[0:15] = b + c, then he could assume that both b and c are less than 17 bits. In any case, for small benchmarks, such as Stanford, MiBench and Bitwise my implementation gets some non-trivial bit size reductions. For very big benchmarks such as gcc (SPEC 2006), the reduction is not good (around 8%). About SSI, actually I am using e-SSA, the same IR used in ABCD. The size is much smaller (10% of SSI), and the time to build it is negligible. Regards, Douglas On Tue, Feb 22, 2011 at 8:19 AM, Duncan Sands wrote: > Hi Andrey, > > > On 21.02.2011 20:27, Douglas do Couto Teixeira wrote: > >> My work is not part of the LLVM mainline yet. But I would be happy to > >> contribute with the code of my range analysis implementation if it can > help > >> you in something else. > > We were thinking of adding VRP to LLVM too, though we were mostly > > interested in Patterson's approach (i.e. not connected with SSI form). > It > > would be great if you can share the code nevertheless. > > the big problem with Patterson's VRP is that it is expensive in terms of > compile time. LLVM used to have some passes (ABCD, predsimplify) that did > this kind of thing, but they were removed essentially because their compile > time was too great for the goodness they brought. > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/f47e9851/attachment-0001.html From czhao at eecg.toronto.edu Tue Feb 22 10:29:34 2011 From: czhao at eecg.toronto.edu (Chuck Zhao) Date: Tue, 22 Feb 2011 11:29:34 -0500 Subject: [LLVMdev] still failed to build the llbrowse on Debian5-32b-llvm2.8 In-Reply-To: References: Message-ID: <4D63E46E.4090100@eecg.toronto.edu> I still can't build LLBrowse on my Debian5-i386 machine today, The following is a full build console output. I am using LLVM-2.8 release build, with needed wxWidgets and CMake. Thank you Chuck sideshow.eecg>time cmake ../llbrowse -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found wxWidgets: TRUE -- Looking for assert.h -- Looking for assert.h - found -- Looking for auto_ptr.h -- Looking for auto_ptr.h - not found -- Looking for C++ include memory -- Looking for C++ include memory - found -- LLVM llvm-config found at: /steffan/a/a0/czhao/opt/opt32/llvm-2.8r/bin/llvm-config -- Configuring done -- Generating done -- Build files have been written to: /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/obj 1.976u 2.100s 0:14.37 28.3% 0+0k 48680+2392io 174pf+0w sideshow.eecg>time make [ 5%] Converting PNG image file resources/icons/folder.png [ 11%] Converting PNG image file resources/icons/collapse.png [ 16%] Converting PNG image file resources/icons/typeref.png [ 22%] Converting PNG image file resources/icons/expand.png [ 27%] Converting PNG image file resources/icons/type.png [ 33%] Converting PNG image file resources/icons/function.png [ 38%] Converting PNG image file resources/icons/module.png [ 44%] Converting PNG image file resources/icons/variable.png [ 50%] Converting PNG image file resources/icons/debug.png [ 55%] Converting PNG image file resources/icons/meta.png [ 61%] Converting PNG image file resources/icons/alias.png [ 66%] Converting PNG image file resources/icons/constant.png Scanning dependencies of target llbrowse [ 72%] Building CXX object CMakeFiles/llbrowse.dir/lib/BrowserFrame.cpp.o [ 77%] Building CXX object CMakeFiles/llbrowse.dir/lib/DetailsView.cpp.o [ 83%] Building CXX object CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp: In member function 'virtual bool BrowserApp::OnInit()': /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp:29: error: 'PrintStackTraceOnErrorSignal' is not a member of 'llvm::sys' make[2]: *** [CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o] Error 1 make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 make: *** [all] Error 2 7.228u 1.228s 0:12.34 68.3% 0+0k 13512+1784io 3pf+0w sideshow.eecg> From x.tong at utoronto.ca Tue Feb 22 11:03:17 2011 From: x.tong at utoronto.ca (Xin Tong Utoronto) Date: Tue, 22 Feb 2011 12:03:17 -0500 Subject: [LLVMdev] LLVM ExecutionEngine/JIT trampoline question Message-ID: I have a question on the LLVM JIT I did some brief memory reading one day and I found that a call to a non-library function is resolved by the X86CompilationCallback, but the X86CompilationCallback is reached through a trampoline. why can not the generated code jump to the X86CompilationCallback function directly ? 0x2b0a6a4d103b: mov $0x2b0a6a561010,%rax 0x2b0a6a4d1045: callq *%rax // call foo > > > ==> > > 0x2b0a6a561010: mov $0xa743a0,%r10 // some kind of > trampoline > 0x2b0a6a56101a: callq *%r10 > > ==> > > 0xa743a0 : push %rbp > 0xa743a1 : mov %rsp,%rbp > 0xa743a4 : push %rdi > 0xa743a5 : push %rsi -- Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/812862a9/attachment.html From reid.kleckner at gmail.com Tue Feb 22 11:39:21 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Tue, 22 Feb 2011 12:39:21 -0500 Subject: [LLVMdev] LLVM ExecutionEngine/JIT trampoline question In-Reply-To: References: Message-ID: The address of the callee may be more than 2 GB away in memory, which cannot be encoded as an immediate offset in the call instruction. So, the value is first materialized with a mov instruction which can encode the immediate and then jumped to through a register. Reid On Tue, Feb 22, 2011 at 12:03 PM, Xin Tong Utoronto wrote: > I have a question on the LLVM JIT > > I did some brief memory reading one day and I found that a call to a > non-library function is resolved by the X86CompilationCallback, but the > X86CompilationCallback is reached through a trampoline. why can not? the > generated code jump to the X86CompilationCallback function directly ? > > ????????? 0x2b0a6a4d103b: mov??? $0x2b0a6a561010,%rax > ????????? 0x2b0a6a4d1045: callq? *%rax > // call foo >> >> >> ==> >> >> 0x2b0a6a561010: mov??? $0xa743a0,%r10?????????????????? // some kind of >> trampoline >> 0x2b0a6a56101a: callq? *%r10 >> >> ==> >> >> 0xa743a0 :??????? push?? %rbp >> 0xa743a1 :??? mov??? %rsp,%rbp >> 0xa743a4 :??? push?? %rdi >> 0xa743a5 :??? push?? %rsi > > -- > Kind Regards > > Xin Tong > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From andrew at sidefx.com Tue Feb 22 11:41:06 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Tue, 22 Feb 2011 12:41:06 -0500 Subject: [LLVMdev] attaching metadata to llvm::Argument In-Reply-To: <201102211718.13024.florian.merz@kit.edu> References: <201102211718.13024.florian.merz@kit.edu> Message-ID: <4D63F532.9090503@sidefx.com> I too would have an immediate application if metadata could be attached to arguments. I'm currently working around it by using named metadata in the module (matched by index to the arguments). Andrew On 02/21/2011 11:18 AM, Florian Merz wrote: > Hey everyone, > > I'm trying to retrieve information about signed-/unsignedness of an > llvm::Argument so I can print out it's value to the user properly. llvm itself > doesn't distinguish signed and unsigned and so llvm::Type is of no help here. > Checking for nsw/usw is only an unreliable approximation and only available > for llvm::Instructions anyways. > > I tried to use debugging information (llvm::DIType) for this, but > getMetadata() is not available for llvm::Argument, only for llvm::Instruction. > > Is there any other way to get at this information? > > Regards, > Florian > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dpatel at apple.com Tue Feb 22 11:54:13 2011 From: dpatel at apple.com (Devang Patel) Date: Tue, 22 Feb 2011 09:54:13 -0800 Subject: [LLVMdev] attaching metadata to llvm::Argument In-Reply-To: <4D63F532.9090503@sidefx.com> References: <201102211718.13024.florian.merz@kit.edu> <4D63F532.9090503@sidefx.com> Message-ID: <1F8E30B9-AED9-4060-89CA-8A3D0A96F565@apple.com> There is no support to have metadata attached with an argument because there was any need so far. If you have really good reason to have it then you'll at least need to - propose llvm IR syntax and update llvm IR spec to attach metadata - update llvm parser and asm writer - update bitcode reader and writer - Devang On Feb 22, 2011, at 9:41 AM, Andrew Clinton wrote: > I too would have an immediate application if metadata could be attached > to arguments. I'm currently working around it by using named metadata > in the module (matched by index to the arguments). > > Andrew > > On 02/21/2011 11:18 AM, Florian Merz wrote: >> Hey everyone, >> >> I'm trying to retrieve information about signed-/unsignedness of an >> llvm::Argument so I can print out it's value to the user properly. llvm itself >> doesn't distinguish signed and unsigned and so llvm::Type is of no help here. >> Checking for nsw/usw is only an unreliable approximation and only available >> for llvm::Instructions anyways. >> >> I tried to use debugging information (llvm::DIType) for this, but >> getMetadata() is not available for llvm::Argument, only for llvm::Instruction. >> >> Is there any other way to get at this information? >> >> Regards, >> Florian >> _______________________________________________ >> 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 howarth at bromo.med.uc.edu Tue Feb 22 11:58:09 2011 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Feb 2011 12:58:09 -0500 Subject: [LLVMdev] llvm-gcc4.2 bootstrap broken? In-Reply-To: <643ED677-87D5-41ED-8355-852CB4C7E862@apple.com> References: <20110219192554.GA5200@bromo.med.uc.edu> <643ED677-87D5-41ED-8355-852CB4C7E862@apple.com> Message-ID: <20110222175809.GA25373@bromo.med.uc.edu> On Mon, Feb 21, 2011 at 03:58:19PM -0800, Eric Christopher wrote: > > On Feb 19, 2011, at 11:25 AM, Jack Howarth wrote: > > > Is anyone able to bootstrap llvm-gcc42 svn on x86_64-apple-darwin10? Currently it is > > failing here with... > > It was broken. I think I've fixed it in reverting 125960. > > -eric Eric, The llvm-gcc42 bootstrap is fixed in current svn. FYI, the current polyhedron 2005 results are below. Compared to the previous results on 18 Sep 2010 for llvm 2.8, the regressions in ac are retained and aermod is now also regressed 13% as well as fatigue by 12%. Jack ================================================================================ Date & Time : 22 Feb 2011 10:43:00 Test Name : llvm_gfortran_lin_p4 Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 2000.0 Target Error % : 0.100 Minimum Repeats : 10 Maximum Repeats : 100 Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- ------- ---------- ------- ------- ------ ac 1.46 26528 14.02 10 0.0074 aermod 29.53 1013016 17.17 10 0.0065 air 1.09 53272 7.61 10 0.0275 capacita 0.55 36752 47.54 10 0.0066 channel 0.31 26704 2.20 11 0.0947 doduc 2.10 131656 31.09 10 0.0236 fatigue 0.97 65552 9.59 10 0.0333 gas_dyn 0.79 54280 13.14 12 0.0973 induct 2.10 166616 23.76 10 0.0045 linpk 0.26 18248 15.70 10 0.0319 mdbx 0.78 49504 12.01 10 0.0121 nf 0.32 23048 31.75 18 0.0876 protein 1.16 70392 39.86 10 0.0104 rnflow 1.57 66184 32.30 10 0.0097 test_fpu 1.34 57032 11.28 10 0.0152 tfft 0.25 18600 2.15 14 0.0491 Geometric Mean Execution Time = 14.38 seconds ================================================================================ which compares to the previous results of... ================================================================================ Date & Time : 7 Apr 2010 22:24:16 Test Name : llvm_gfortran_lin_p4 Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 2000.0 Target Error % : 0.100 Minimum Repeats : 10 Maximum Repeats : 100 Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- ------- ---------- ------- ------- ------ ac 0.34 10000 12.85 10 0.0067 aermod 20.01 10000 15.42 10 0.0076 air 1.52 10000 7.50 12 0.0934 capacita 0.58 10000 45.67 10 0.0152 channel 0.41 10000 2.19 10 0.0365 doduc 2.29 10000 29.08 10 0.0140 fatigue 1.02 10000 8.83 10 0.0582 gas_dyn 0.77 10000 13.12 21 0.0909 induct 2.54 10000 24.22 10 0.0096 linpk 0.28 10000 15.67 10 0.0343 mdbx 0.79 10000 12.09 10 0.0070 nf 0.33 10000 30.10 12 0.0751 protein 1.10 10000 42.02 10 0.0100 rnflow 1.53 10000 32.00 10 0.0214 test_fpu 1.28 10000 11.73 10 0.0446 tfft 0.24 10000 2.16 13 0.0988 Geometric Mean Execution Time = 14.07 seconds ================================================================================ ================================================================================ Date & Time : 18 Sep 2010 21:28:47 Test Name : llvm_gfortran_lin_p4 Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 2000.0 Target Error % : 0.100 Minimum Repeats : 10 Maximum Repeats : 100 Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- ------- ---------- ------- ------- ------ ac 0.29 10000 14.20 10 0.0147 aermod 18.69 10000 15.23 10 0.0412 air 1.13 10000 7.51 16 0.0570 capacita 0.51 10000 48.51 10 0.0506 channel 0.30 10000 2.20 10 0.0697 doduc 1.97 10000 30.31 10 0.0084 fatigue 0.81 10000 8.55 10 0.0098 gas_dyn 0.67 10000 13.00 15 0.0740 induct 2.04 10000 24.40 10 0.0089 linpk 0.25 10000 15.68 10 0.0734 mdbx 0.77 10000 12.02 10 0.0120 nf 0.33 10000 31.94 10 0.0909 protein 1.00 10000 40.53 10 0.0118 rnflow 1.42 10000 32.31 12 0.0642 test_fpu 1.26 10000 11.31 13 0.0964 tfft 0.22 10000 2.15 13 0.0167 Geometric Mean Execution Time = 14.20 seconds ================================================================================ From andrew at sidefx.com Tue Feb 22 12:00:24 2011 From: andrew at sidefx.com (Andrew Clinton) Date: Tue, 22 Feb 2011 13:00:24 -0500 Subject: [LLVMdev] attaching metadata to llvm::Argument In-Reply-To: <4D63F532.9090503@sidefx.com> References: <201102211718.13024.florian.merz@kit.edu> <4D63F532.9090503@sidefx.com> Message-ID: <4D63F9B8.9070305@sidefx.com> The reason that I need this is that I'm supporting runtime function specialization, where the arguments have known default values. When the function is specialized, I need to replace uses of the argument with the default value. I could not find any other way to store the metadata for the default values other than to use module-level data. Does anyone know a better way to accomplish this in the LLVM IR? On 02/22/2011 12:41 PM, Andrew Clinton wrote: > I too would have an immediate application if metadata could be attached > to arguments. I'm currently working around it by using named metadata > in the module (matched by index to the arguments). > > Andrew > > On 02/21/2011 11:18 AM, Florian Merz wrote: >> Hey everyone, >> >> I'm trying to retrieve information about signed-/unsignedness of an >> llvm::Argument so I can print out it's value to the user properly. llvm itself >> doesn't distinguish signed and unsigned and so llvm::Type is of no help here. >> Checking for nsw/usw is only an unreliable approximation and only available >> for llvm::Instructions anyways. >> >> I tried to use debugging information (llvm::DIType) for this, but >> getMetadata() is not available for llvm::Argument, only for llvm::Instruction. >> >> Is there any other way to get at this information? >> >> Regards, >> Florian >> _______________________________________________ >> 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 andreas.faerber at web.de Tue Feb 22 12:59:52 2011 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Tue, 22 Feb 2011 19:59:52 +0100 Subject: [LLVMdev] STM8 backend for Clang In-Reply-To: References: <15CFFE06-A81F-4E13-88C6-26A42ABCB476@web.de> Message-ID: Am 21.02.2011 um 02:44 schrieb Eli Friedman: > On Sun, Feb 20, 2011 at 4:23 PM, Andreas F?rber > wrote: >> The first issue I stumbled upon was that the Program Counter register >> is 24 bits. [...] > > [...] if the only > 24-bit register is the program counter, you could probably get away > with pretending it's a 32-bit register. > >> Further, as pointer width I chose 16 bits since there currently seems >> to be no way to distinguish between near and far pointers? > > LLVM doesn't support distinguishing between near and far pointers. > Depending on how much work you want to put in and what exactly you're > trying to build, you might be able to get away with just pretending > all pointers are near and implementing __builtin_stm8_far_loadn() and > __builtin_stm8_far_storen() intrinsics, though. The example C code uses far pointers, e.g., to set up interrupt vectors: typedef void @far (*interrupt_handler_t)(void); struct interrupt_vector { unsigned char interrupt_instruction; interrupt_handler_t interrupt_handler; }; So I do need support for 24-bit pointers in the Clang frontend, in order for the struct to fill four bytes here. Not sure how intrinsics could help there. I assume that @far is a non- standard keyword. Is it possible to derive a new language standard similar to GCC's --std=gnu99 to handle such extensions? The only guide I could find was on how to add an attribute... Andreas From arushi987 at gmail.com Tue Feb 22 13:31:55 2011 From: arushi987 at gmail.com (Arushi Aggarwal) Date: Tue, 22 Feb 2011 13:31:55 -0600 Subject: [LLVMdev] Clone a function and change signature Message-ID: Hi, I want to clone a given function, and add an argument to it. I then want to add a call to that new function. I have a callInstruction CI, which I want to transform to call this new function, and to take a new argument. The code I added was as follows CI->getCalledFunction()->dump(); Function* DirectF = CloneFunction(CI->getCalledFunction()); DirectF->setName(CI->getCalledFunction()->getNameStr() + "_SPEC"); DirectF->setLinkage(GlobalValue::InternalLinkage); // add the extra argument new Argument(GEP->getPointerOperand()->getType(),"arg",DirectF); M.getFunctionList().push_back(DirectF); DirectF->dump(); SmallVector Args; for(unsigned j =1;jgetNumOperands();j++) { Args.push_back(CI->getOperand(j)); } //Add the extra parameter Args.push_back(GEP->getPointerOperand()); CallInst *CallI = CallInst::Create(DirectF,Args.begin(), Args.end(),"", CI); CallI->dump(); But I get the following exception call void @point_DIRECT(i16* %tmp1324mod, i16* %tmp1322mod) nounwind define internal void @point_DIRECT(i16* %x, i16* %y) nounwind { entry: %xx = alloca i32 ; [#uses=3] %yy = alloca i32 ; [#uses=3] %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*> [#uses=1] %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; [#uses=1] br i1 %tmp1, label %return, label %bb, !dbg !1018 bb: ; preds = %entry %tmp2 = load i16* %x, align 2, !dbg !1023 ; [#uses=1] %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; [#uses=1] store i32 %tmp3, i32* %xx, align 4, !dbg !1023 %tmp4 = load i16* %y, align 2, !dbg !1024 ; [#uses=1] %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; [#uses=1] store i32 %tmp5, i32* %yy, align 4, !dbg !1024 %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*> [#uses=1] call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) nounwind %tmp8 = load i32* %xx, align 4, !dbg !1026 ; [#uses=1] %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; [#uses=1] store i16 %tmp9, i16* %x, align 2, !dbg !1026 %tmp10 = load i32* %yy, align 4, !dbg !1027 ; [#uses=1] %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; [#uses=1] store i16 %tmp11, i16* %y, align 2, !dbg !1027 ret void return: ; preds = %entry ret void } define internal void @point_DIRECT_SPEC(i16* %x, i16* %y, %struct.termbox* %arg) nounwind { entry: %xx = alloca i32 ; [#uses=3] %yy = alloca i32 ; [#uses=3] %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*> [#uses=1] %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; [#uses=1] br i1 %tmp1, label %return, label %bb, !dbg !1018 bb: ; preds = %entry %tmp2 = load i16* %x, align 2, !dbg !1023 ; [#uses=1] %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; [#uses=1] store i32 %tmp3, i32* %xx, align 4, !dbg !1023 %tmp4 = load i16* %y, align 2, !dbg !1024 ; [#uses=1] %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; [#uses=1] store i32 %tmp5, i32* %yy, align 4, !dbg !1024 %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*> [#uses=1] call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) nounwind %tmp8 = load i32* %xx, align 4, !dbg !1026 ; [#uses=1] %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; [#uses=1] store i16 %tmp9, i16* %x, align 2, !dbg !1026 %tmp10 = load i32* %yy, align 4, !dbg !1027 ; [#uses=1] %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; [#uses=1] store i16 %tmp11, i16* %y, align 2, !dbg !1027 ret void return: ; preds = %entry ret void } opt: /home/vadve/aggarwa4/llvm27/llvm-2.7/lib/VMCore/Instructions.cpp:307: void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int): Assertion `(NumParams == FTy->getNumParams() || (FTy->isVarArg() && NumParams > FTy->getNumParams())) && "Calling a function with bad signature!"' failed. When I looked at the excption, it occurs when creating the CallInst. The type of the function being called at that point is still the old type, without the extra parameter, though the extra parameter seems to have been added when I dump DirectF. Can I get any pointers to what I am doing wrong, and what might be a potential solution. Thanks, Arushi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/618028cf/attachment.html From criswell at illinois.edu Tue Feb 22 13:46:45 2011 From: criswell at illinois.edu (John Criswell) Date: Tue, 22 Feb 2011 13:46:45 -0600 Subject: [LLVMdev] Clone a function and change signature In-Reply-To: References: Message-ID: <4D6412A5.1030300@illinois.edu> On 2/22/11 1:31 PM, Arushi Aggarwal wrote: > Hi, > > I want to clone a given function, and add an argument to it. I then > want to add a call to that new function. I have a callInstruction CI, > which I want to transform to call this new function, and to take a new > argument. If I understand correctly, you're cloning the function first and then adding a new argument to the clone. Do I understand correctly? If so, I don't believe you can do that. IIRC, you have to first create a new, empty function with the additional argument and then use CloneFunctionInto() to clone the body of the original function into the new function. I believe that's what poolalloc does and what I did the last time I had to add function arguments to a function. -- John T. > > The code I added was as follows > > CI->getCalledFunction()->dump(); > Function* DirectF = CloneFunction(CI->getCalledFunction()); > DirectF->setName(CI->getCalledFunction()->getNameStr() + "_SPEC"); > DirectF->setLinkage(GlobalValue::InternalLinkage); > // add the extra argument > new Argument(GEP->getPointerOperand()->getType(),"arg",DirectF); > M.getFunctionList().push_back(DirectF); > DirectF->dump(); > > SmallVector Args; > for(unsigned j =1;jgetNumOperands();j++) { > Args.push_back(CI->getOperand(j)); > } > //Add the extra parameter > Args.push_back(GEP->getPointerOperand()); > CallInst *CallI = CallInst::Create(DirectF,Args.begin(), > Args.end(),"", CI); > CallI->dump(); > > > But I get the following exception > > call void @point_DIRECT(i16* %tmp1324mod, i16* %tmp1322mod) nounwind > > define internal void @point_DIRECT(i16* %x, i16* %y) nounwind { > entry: > %xx = alloca i32 ; [#uses=3] > %yy = alloca i32 ; [#uses=3] > %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*> > [#uses=1] > %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; [#uses=1] > br i1 %tmp1, label %return, label %bb, !dbg !1018 > > bb: ; preds = %entry > %tmp2 = load i16* %x, align 2, !dbg !1023 ; [#uses=1] > %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; [#uses=1] > store i32 %tmp3, i32* %xx, align 4, !dbg !1023 > %tmp4 = load i16* %y, align 2, !dbg !1024 ; [#uses=1] > %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; [#uses=1] > store i32 %tmp5, i32* %yy, align 4, !dbg !1024 > %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*> > [#uses=1] > call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) > nounwind > %tmp8 = load i32* %xx, align 4, !dbg !1026 ; [#uses=1] > %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; [#uses=1] > store i16 %tmp9, i16* %x, align 2, !dbg !1026 > %tmp10 = load i32* %yy, align 4, !dbg !1027 ; [#uses=1] > %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; [#uses=1] > store i16 %tmp11, i16* %y, align 2, !dbg !1027 > ret void > > return: ; preds = %entry > ret void > } > > > define internal void @point_DIRECT_SPEC(i16* %x, i16* %y, > %struct.termbox* %arg) nounwind { > entry: > %xx = alloca i32 ; [#uses=3] > %yy = alloca i32 ; [#uses=3] > %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*> > [#uses=1] > %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; [#uses=1] > br i1 %tmp1, label %return, label %bb, !dbg !1018 > > bb: ; preds = %entry > %tmp2 = load i16* %x, align 2, !dbg !1023 ; [#uses=1] > %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; [#uses=1] > store i32 %tmp3, i32* %xx, align 4, !dbg !1023 > %tmp4 = load i16* %y, align 2, !dbg !1024 ; [#uses=1] > %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; [#uses=1] > store i32 %tmp5, i32* %yy, align 4, !dbg !1024 > %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*> > [#uses=1] > call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) > nounwind > %tmp8 = load i32* %xx, align 4, !dbg !1026 ; [#uses=1] > %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; [#uses=1] > store i16 %tmp9, i16* %x, align 2, !dbg !1026 > %tmp10 = load i32* %yy, align 4, !dbg !1027 ; [#uses=1] > %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; [#uses=1] > store i16 %tmp11, i16* %y, align 2, !dbg !1027 > ret void > > return: ; preds = %entry > ret void > } > > opt: > /home/vadve/aggarwa4/llvm27/llvm-2.7/lib/VMCore/Instructions.cpp:307: > void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned > int): Assertion `(NumParams == FTy->getNumParams() || (FTy->isVarArg() > && NumParams > FTy->getNumParams())) && "Calling a function with bad > signature!"' failed. > > > When I looked at the excption, it occurs when creating the CallInst. > > The type of the function being called at that point is still the old > type, without the extra parameter, though the extra parameter seems to > have been added when I dump DirectF. > > Can I get any pointers to what I am doing wrong, and what might be a > potential solution. > > Thanks, > Arushi From greened at obbligato.org Tue Feb 22 14:20:56 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 22 Feb 2011 14:20:56 -0600 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: <4D5E4F64.6080300@arcor.de> (Jochen Wilhelmy's message of "Fri, 18 Feb 2011 11:52:20 +0100") References: <4D5E4F64.6080300@arcor.de> Message-ID: Jochen Wilhelmy writes: > struct I { > int a; > char b; > }; > > struct J : I { > char c; > }; > > Dave said that this translates to > > %I = type { i32, i8, i16 } > %J = type { %I, i8, i16 } It translates to that in OUR compiler. It's not the only answer. > because the frontend has to communicate the ABI to llvm since llvm is > language agnostic. Correct. > What I really wonder is why it isn't > > %I = type { i32, i8 } > %J = type { %I, i16, i8 } > > because llvm at least knows alignment rules by > > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16... > > Therefore llvm has no other choice than assigning %I a size of 8 > since an array may consist of %I elements and size of 5 would violate > the aligment of the i32 member. I can't quite parse this. %I doesn't get "assigned" a size by anyone. Do you meant the size of struct I is eight bytes? Yes, that's true. > If the ABI requires that member c has an offset of 8 instead of 5 then > of course a padding behind %I is necessary in %J. Yes, the padding is required. I believe %J = type { %I, i16, i8 } would work just as well as long as %I = type { i32, i8 } as in your example. Our frontend is far from "perfect" in the sense of aesthetics. :) -Dave From viridia at gmail.com Tue Feb 22 14:23:27 2011 From: viridia at gmail.com (Talin) Date: Tue, 22 Feb 2011 12:23:27 -0800 Subject: [LLVMdev] still failed to build the llbrowse on Debian5-32b-llvm2.8 In-Reply-To: <4D63E46E.4090100@eecg.toronto.edu> References: <4D63E46E.4090100@eecg.toronto.edu> Message-ID: OK try it now - I checked in a few more fixes. On Tue, Feb 22, 2011 at 8:29 AM, Chuck Zhao wrote: > I still can't build LLBrowse on my Debian5-i386 machine today, > The following is a full build console output. > I am using LLVM-2.8 release build, with needed wxWidgets and CMake. > > Thank you > > Chuck > > sideshow.eecg>time cmake ../llbrowse > -- The C compiler identification is GNU > -- The CXX compiler identification is GNU > -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc > -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Found wxWidgets: TRUE > -- Looking for assert.h > -- Looking for assert.h - found > -- Looking for auto_ptr.h > -- Looking for auto_ptr.h - not found > -- Looking for C++ include memory > -- Looking for C++ include memory - found > -- LLVM llvm-config found at: > /steffan/a/a0/czhao/opt/opt32/llvm-2.8r/bin/llvm-config > -- Configuring done > -- Generating done > -- Build files have been written to: > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/obj > 1.976u 2.100s 0:14.37 28.3% 0+0k 48680+2392io 174pf+0w > sideshow.eecg>time make > [ 5%] Converting PNG image file resources/icons/folder.png > [ 11%] Converting PNG image file resources/icons/collapse.png > [ 16%] Converting PNG image file resources/icons/typeref.png > [ 22%] Converting PNG image file resources/icons/expand.png > [ 27%] Converting PNG image file resources/icons/type.png > [ 33%] Converting PNG image file resources/icons/function.png > [ 38%] Converting PNG image file resources/icons/module.png > [ 44%] Converting PNG image file resources/icons/variable.png > [ 50%] Converting PNG image file resources/icons/debug.png > [ 55%] Converting PNG image file resources/icons/meta.png > [ 61%] Converting PNG image file resources/icons/alias.png > [ 66%] Converting PNG image file resources/icons/constant.png > Scanning dependencies of target llbrowse > [ 72%] Building CXX object CMakeFiles/llbrowse.dir/lib/BrowserFrame.cpp.o > [ 77%] Building CXX object CMakeFiles/llbrowse.dir/lib/DetailsView.cpp.o > [ 83%] Building CXX object CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp: > In member function 'virtual bool BrowserApp::OnInit()': > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp:29: > error: 'PrintStackTraceOnErrorSignal' is not a member of 'llvm::sys' > make[2]: *** [CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o] Error 1 > make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 > make: *** [all] Error 2 > 7.228u 1.228s 0:12.34 68.3% 0+0k 13512+1784io 3pf+0w > > sideshow.eecg> > > > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/4bd0c5e3/attachment.html From anton at korobeynikov.info Tue Feb 22 14:27:01 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 22 Feb 2011 23:27:01 +0300 Subject: [LLVMdev] repo.or.cz GIT mirrors Message-ID: Hello Everyone As you might already know, git mirrors of llvm repository started from repo.or.cz mirrors, where stuff was pushed almost by hands out of git-svn local copy. Right now we have official and automatically updated GIT mirrors on llvm.org and thus repo.or.cz mirrors look a bit redundant. However, they might still be useful, but definitely not within the current "push mode". It is possible to convert them to plain GIT mirrors of llvm.org GIT mirrors with automatic pulling, but this, in fact, will require us to delete repo.or.cz repos and recreate them from scratch. I hope this would affect only forks, from which only 1-2 seem to be active (and hopefully they can be just recreated on top of new projects). Any objections for such procedure? Maybe someone will have better idea? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From greened at obbligato.org Tue Feb 22 14:34:55 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 22 Feb 2011 14:34:55 -0600 Subject: [LLVMdev] Questions about LLVM IR encoding In-Reply-To: (" =?utf-8?B?5byg5LmQIidz?= message of "Mon, 21 Feb 2011 16:27:44 +0800") References: Message-ID: ?? writes: > Hi all, I am new to LLVM (even the field of compiler) and currently I am engaged in the work of adapting LLVM IR to M5 simulator to observe > the enhancement of the novel architecture we design. > Simply speaking if you know?little about?M5, my aim is to know how LLVM IR is interpreted and encoded, then try to implement it in the > framework of M5. > I have read the LLVM documents, yet I still have some questions as follows: > ? > 1. As IR is target-independent, how can we encode them into bit-code executable files without specific?targets' information??? > 2. The "bitstream container format" as the document refers, is XML-like, and I wonder how does LLVM translate it into executable format such > as bit-code. If I'm understanding you correctly, you want to treat LLVM IR as an ISA and simulate that in M5, writing a new M5 target to execute LLVM IR in bitcode format. Is that right? I don't think that's a good option. While it can theoretically be done, you're going to miss very important machine aspects such as: - limited register set - alignment issues - calling sequence - instruction/text size There are others, but all of the above can impact performance in major ways. Not modeling them is going to give you very inaccurate results. If you can express your architectural enhancement in one of the existing targets, I would do that. At the very worst you can create new instructions (say, for x86) and insert them into the asm stream with raw .byte directives in the .s file. I've done that many times in the past. Another option is to create a new Target in LLVM and define the ISA you want to evaluate. This is a lot more work as it requires a new Target in LLVM and a new implementation for M5 but it gives you more flexibility and makes future changes easier. I would go with one of the existing Targets if possible and add any new instructions you need. That's going to give you the most realistic results. -Dave From clattner at apple.com Tue Feb 22 14:43:27 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 22 Feb 2011 12:43:27 -0800 Subject: [LLVMdev] Clone a function and change signature In-Reply-To: <4D6412A5.1030300@illinois.edu> References: <4D6412A5.1030300@illinois.edu> Message-ID: On Feb 22, 2011, at 11:46 AM, John Criswell wrote: > On 2/22/11 1:31 PM, Arushi Aggarwal wrote: >> Hi, >> >> I want to clone a given function, and add an argument to it. I then >> want to add a call to that new function. I have a callInstruction CI, >> which I want to transform to call this new function, and to take a new >> argument. > > If I understand correctly, you're cloning the function first and then > adding a new argument to the clone. Do I understand correctly? > > If so, I don't believe you can do that. IIRC, you have to first create > a new, empty function with the additional argument and then use > CloneFunctionInto() to clone the body of the original function into the > new function. I believe that's what poolalloc does and what I did the > last time I had to add function arguments to a function. Right, you can also take a look at the dead argument elimination or argument promotion passes for examples. -Chris From clattner at apple.com Tue Feb 22 14:44:18 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 22 Feb 2011 12:44:18 -0800 Subject: [LLVMdev] Question about Value Range Propagation In-Reply-To: References: <4D6390E6.5060805@ispras.ru> <4D639BDE.7050105@free.fr> Message-ID: <1D82F914-A36A-4447-B36C-70E46F35B751@apple.com> On Feb 22, 2011, at 7:25 AM, Reid Kleckner wrote: > On Tue, Feb 22, 2011 at 6:19 AM, Duncan Sands wrote: >> the big problem with Patterson's VRP is that it is expensive in terms of >> compile time. LLVM used to have some passes (ABCD, predsimplify) that did >> this kind of thing, but they were removed essentially because their compile >> time was too great for the goodness they brought. > > Any reason not to just leave them on at O3? Based on the discussion > around your simple condition propagation pass, it seemed predsimplify > did delete dead code, but it didn't really improve generated code > performance. O3 seems the appropriate place to put expensive > optimizations with diminishing returns. Hi Reid, -O3 compile time matters. We don't turn things on in -O3 or -O4 that just burn compiler cycles but don't add value. -Chris From clattner at apple.com Tue Feb 22 14:44:41 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 22 Feb 2011 12:44:41 -0800 Subject: [LLVMdev] unary floating point operations using clang In-Reply-To: References: Message-ID: On Feb 22, 2011, at 12:40 AM, Alexandru Dura wrote: > Hello, > > Is there a way of generating unary floating point operations (like ISD::FABS, ISD::FSIN, ...) from C code using clang? I am building a backend for a machine that has hw support for these ops and I need a way to test them. Sure, just call sin() and cos(). -Chris From criswell at illinois.edu Tue Feb 22 14:57:34 2011 From: criswell at illinois.edu (John Criswell) Date: Tue, 22 Feb 2011 14:57:34 -0600 Subject: [LLVMdev] Question about Value Range Propagation In-Reply-To: <4D639BDE.7050105@free.fr> References: <4D6390E6.5060805@ispras.ru> <4D639BDE.7050105@free.fr> Message-ID: <4D64233E.20006@illinois.edu> On 2/22/11 5:19 AM, Duncan Sands wrote: > Hi Andrey, > >> On 21.02.2011 20:27, Douglas do Couto Teixeira wrote: >>> My work is not part of the LLVM mainline yet. But I would be happy to >>> contribute with the code of my range analysis implementation if it can help >>> you in something else. >> We were thinking of adding VRP to LLVM too, though we were mostly >> interested in Patterson's approach (i.e. not connected with SSI form). It >> would be great if you can share the code nevertheless. > the big problem with Patterson's VRP is that it is expensive in terms of > compile time. LLVM used to have some passes (ABCD, predsimplify) that did > this kind of thing, but they were removed essentially because their compile > time was too great for the goodness they brought. I was under the impression that ABCD was removed because no one was maintaining and improving it. Is my impression incorrect? The SAFECode compiler adds additional run-time checks for array bounds checking. If the ABCD code was working but just wasn't useful for regular C code, I'd like to know. It may still have value for projects like SAFECode. -- John T. > 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 czhao at eecg.toronto.edu Tue Feb 22 15:36:03 2011 From: czhao at eecg.toronto.edu (Chuck Zhao) Date: Tue, 22 Feb 2011 16:36:03 -0500 Subject: [LLVMdev] still failed to build the llbrowse on Debian5-32b-llvm2.8 In-Reply-To: References: <4D63E46E.4090100@eecg.toronto.edu> Message-ID: <4D642C43.7030806@eecg.toronto.edu> Nice, It builds and runs fine now. Thank you, Talin Chuck On 2/22/2011 3:23 PM, Talin wrote: > OK try it now - I checked in a few more fixes. > > On Tue, Feb 22, 2011 at 8:29 AM, Chuck Zhao > wrote: > > I still can't build LLBrowse on my Debian5-i386 machine today, > The following is a full build console output. > I am using LLVM-2.8 release build, with needed wxWidgets and CMake. > > Thank you > > Chuck > > sideshow.eecg>time cmake ../llbrowse > -- The C compiler identification is GNU > -- The CXX compiler identification is GNU > -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc > -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc > -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Found wxWidgets: TRUE > -- Looking for assert.h > -- Looking for assert.h - found > -- Looking for auto_ptr.h > -- Looking for auto_ptr.h - not found > -- Looking for C++ include memory > -- Looking for C++ include memory - found > -- LLVM llvm-config found at: > /steffan/a/a0/czhao/opt/opt32/llvm-2.8r/bin/llvm-config > -- Configuring done > -- Generating done > -- Build files have been written to: > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/obj > 1.976u 2.100s 0:14.37 28.3% 0+0k 48680+2392io 174pf+0w > sideshow.eecg>time make > [ 5%] Converting PNG image file resources/icons/folder.png > [ 11%] Converting PNG image file resources/icons/collapse.png > [ 16%] Converting PNG image file resources/icons/typeref.png > [ 22%] Converting PNG image file resources/icons/expand.png > [ 27%] Converting PNG image file resources/icons/type.png > [ 33%] Converting PNG image file resources/icons/function.png > [ 38%] Converting PNG image file resources/icons/module.png > [ 44%] Converting PNG image file resources/icons/variable.png > [ 50%] Converting PNG image file resources/icons/debug.png > [ 55%] Converting PNG image file resources/icons/meta.png > [ 61%] Converting PNG image file resources/icons/alias.png > [ 66%] Converting PNG image file resources/icons/constant.png > Scanning dependencies of target llbrowse > [ 72%] Building CXX object > CMakeFiles/llbrowse.dir/lib/BrowserFrame.cpp.o > [ 77%] Building CXX object > CMakeFiles/llbrowse.dir/lib/DetailsView.cpp.o > [ 83%] Building CXX object > CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp: > In member function 'virtual bool BrowserApp::OnInit()': > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp:29: > error: 'PrintStackTraceOnErrorSignal' is not a member of 'llvm::sys' > make[2]: *** [CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o] Error 1 > make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 > make: *** [all] Error 2 > 7.228u 1.228s 0:12.34 68.3% 0+0k 13512+1784io 3pf+0w > > sideshow.eecg> > > > > > > -- > -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/b4bb8299/attachment.html From dineth2007 at gmail.com Tue Feb 22 15:47:40 2011 From: dineth2007 at gmail.com (Dineth) Date: Tue, 22 Feb 2011 16:47:40 -0500 Subject: [LLVMdev] duplicate .debug_line sections Message-ID: I'm using LLVM 2.8 with GNU Binutils for Ubuntu 2.20.51-system.20100908. When I try to assemble a .s file generated with llc with g++ I get the error: Fatal error: duplicate .debug_line sections. I'm using llvm-gcc/g++ as front end. I also tried generating the .o file directly using -filetype=obj but that too fails with BFD: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 assertion fail ../../bfd/elf.c:1805 when trying to convert the .o file to an archive with ar. I would appreciate any help very much. Thanks. -- dineth From dpatel at apple.com Tue Feb 22 15:54:44 2011 From: dpatel at apple.com (Devang Patel) Date: Tue, 22 Feb 2011 13:54:44 -0800 Subject: [LLVMdev] duplicate .debug_line sections In-Reply-To: References: Message-ID: <41D33723-1B56-4AB0-A239-301A21902E5E@apple.com> On Feb 22, 2011, at 1:47 PM, Dineth wrote: > I'm using LLVM 2.8 with GNU Binutils for Ubuntu > 2.20.51-system.20100908. When I try to assemble a .s file generated > with llc with g++ I get the error: > > Fatal error: duplicate .debug_line sections. This is probably http://llvm.org/bugs/show_bug.cgi?id=6218 - Devang > > I'm using llvm-gcc/g++ as front end. > > I also tried generating the .o file directly using -filetype=obj but > that too fails with > > BFD: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 assertion > fail ../../bfd/elf.c:1805 > > when trying to convert the .o file to an archive with ar. > > I would appreciate any help very much. Thanks. > From czhao at eecg.toronto.edu Tue Feb 22 16:01:53 2011 From: czhao at eecg.toronto.edu (Chuck Zhao) Date: Tue, 22 Feb 2011 17:01:53 -0500 Subject: [LLVMdev] obtain the address and size of LLVM generated temporaries Message-ID: <4D643251.1080809@eecg.toronto.edu> I wonder what is the right approach to obtain the address and size of LLVM (compiler) generated temporaries? E.g. %0 = %x + %y store i32 i0, i32 %z, align 4 How can I get the address of %0 (which could be either a stack or heap variable)? Thank you Chuck From yuri at rawbw.com Tue Feb 22 16:29:13 2011 From: yuri at rawbw.com (Yuri) Date: Tue, 22 Feb 2011 14:29:13 -0800 Subject: [LLVMdev] obtain the address and size of LLVM generated temporaries In-Reply-To: <4D643251.1080809@eecg.toronto.edu> References: <4D643251.1080809@eecg.toronto.edu> Message-ID: <4D6438B9.9050405@rawbw.com> On 02/22/2011 14:01, Chuck Zhao wrote: > I wonder what is the right approach to obtain the address and size of > LLVM (compiler) generated temporaries? > > E.g. > > %0 = %x + %y > store i32 i0, i32 %z, align 4 > > How can I get the address of %0 (which could be either a stack or heap > variable)? > This is not possible since such value can also be in register. Yuri From j.wilhelmy at arcor.de Tue Feb 22 16:39:07 2011 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Tue, 22 Feb 2011 23:39:07 +0100 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: References: <4D5E4F64.6080300@arcor.de> Message-ID: <4D643B0B.1090809@arcor.de> >> What I really wonder is why it isn't >> >> %I = type { i32, i8 } >> %J = type { %I, i16, i8 } >> >> because llvm at least knows alignment rules by >> >> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16... >> >> Therefore llvm has no other choice than assigning %I a size of 8 >> since an array may consist of %I elements and size of 5 would violate >> the aligment of the i32 member. > I can't quite parse this. %I doesn't get "assigned" a size by anyone. > Do you meant the size of struct I is eight bytes? Yes, that's true. Yes I mean that %I = type { i32, i8 } is 8 bytes given the alignment rules (i.e. llvm "assigns" a size of 8 bytes to this struct after parsing it) > Yes, the padding is required. I believe %J = type { %I, i16, i8 } would > work just as well as long as %I = type { i32, i8 } as in your example. Yes but given the ABI requires the last member to be at offset 5, which may happen (i.e. no tail padding if I is derived from), then your solution %I = type { i32, i8, i16 } is problematic or do you switch struct generation dependent on the ABI? The question arises to me since I would use an "always working" solution (with no case distinction) but of course I'm not deep enough in the matter. -Jochen From drizzle76 at gmail.com Tue Feb 22 17:37:19 2011 From: drizzle76 at gmail.com (drizzle drizzle) Date: Tue, 22 Feb 2011 15:37:19 -0800 Subject: [LLVMdev] virtual register does not exist Message-ID: Hi is there a way to know later that an earlier pass inside the codegen might have eliminated a virtual register. I carry information abt virtual registers which i would like to update if any virtual register does not exist since. thanks dz From atomicdog.jwm at gmail.com Tue Feb 22 17:46:30 2011 From: atomicdog.jwm at gmail.com (John Myers) Date: Tue, 22 Feb 2011 15:46:30 -0800 Subject: [LLVMdev] Looking for more LLBrowse testers / users In-Reply-To: References: Message-ID: On Tue, Feb 22, 2011 at 3:30 PM, Talin wrote: > This should be fixed now. > -- > -- Talin > Thanks, It compiles and runs now. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/167f6951/attachment.html From stoklund at 2pi.dk Tue Feb 22 18:24:47 2011 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Tue, 22 Feb 2011 16:24:47 -0800 Subject: [LLVMdev] virtual register does not exist In-Reply-To: References: Message-ID: On Feb 22, 2011, at 3:37 PM, drizzle drizzle wrote: > Hi > is there a way to know later that an earlier pass inside the codegen > might have eliminated a virtual register. > I carry information abt virtual registers which i would like to update > if any virtual register does not exist since. You can check if any instructions are using it with MRI->reg_nodbg_empty(Reg). /jakob From felixcca at yahoo.ca Tue Feb 22 18:46:24 2011 From: felixcca at yahoo.ca (=?iso-8859-1?Q?F=E9lix_Cloutier?=) Date: Tue, 22 Feb 2011 19:46:24 -0500 Subject: [LLVMdev] Can I use Clang to parse snippets of C++ code? In-Reply-To: References: <2FB507D0-B596-4769-9AF8-FF69DFA87A93@yahoo.ca> Message-ID: <5E4C34C9-B5D2-4F6C-819F-25E79E217479@yahoo.ca> I believe that what I'm trying to do with Clang is fairly simple; the final goal, however, might be a little harder. Knowing myself, there are chances I'll never go through with this project (like Mikael who posted earlier, I'm nothing but an enthusiastic student with lots of time on my hands), but it feels cool enough to me to announce my idea. Besides, I'll probably need help from more knowledgeable people anyways. The way LLVM works makes it pretty easy and straightforward to generate code from nested structures (like ASTs), which is totally commendable since LLVM is a compiler back-end. However, in the past months I've set myself to make an emulator back-end with LLVM that would translate machine code to LLBC then compile it to native code with the JIT, and my experience haven't been so great, especially because of the following: it's stupid-hard to debug just-in-time generated code with the version of gdb that ships with Xcode (it repeatedly crashed on me); the sheer number of cases to treat is, in itself, rebuking enough: a NES 6502 is 'fine' with just less than 60 distinct operations, but the full-fledged PowerPC you get with a GameCube has roughly 6 times more; when faced with subtle bugs, it's much easier to deal with C++ code representing what you want to do (like interpreter code) than IRBuilder::Create* calls. I figured that while I can't do much about the first, if I could get LLVM to generate code that would generate code, the two others would be much less cumbersome. So my plan is to write a tool that accepts a specification of how instructions should be interpreted, with handlers written in C++, and turn that into an usable recompiler (that would also use LLVM libraries). The grammar would be a shell for C++ code, and I'd use Clang to turn the actual code into LLBC; then, I would pass through the code (? la llvm2cpp), and create calls to an IRBuilder to generate equivalent code. Once this generated class compiled (through regular means), clients would call the appropriate methods on the object to generate code, and will finally be able to get a Function to use with the JIT. I've joined an example grammar and an example expected output (made on the train, it's not actually working, but it gives a good idea). Branch management (except for the branching itself) would have to be completely managed by the client, but this is a minor hurt compared to what it is right now. As a side-effect of using C++ to make instruction handlers, such a solution could almost be a drop-in replacement for existing interpreters. So this is what I'd like to be able to compile with Clang: snippets of C++, with a few symbols declared beforehand. F?lix Le 2011-02-21 ? 23:35:55, Chris Lattner a ?crit : > > On Feb 21, 2011, at 6:31 PM, F?lix Cloutier wrote: > >> Hello guys, >> >> I'd like to use Clang to parse snippets of (and emit bytecode for) C++ code that come from larger files that don't contain only C++, but looking at the clang interpreter example, either I didn't get it, or it looks like the driver expects only files, and not strings or char buffers. >> >> Is there a simple way to achieve this? Do I have to split my input into small files and pass them to clang, or is there a better way? > > It depends on exactly what you're trying to achieve. LLDB uses clang to parse individual expressions, and does this by hooking into various name lookup routines to dynamically/lazily populate symbol tables from debug info. > > This is all possible, but it's a nontrivial amount of work. > > -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/bebb8b03/attachment-0002.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: example.txt Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/bebb8b03/attachment-0001.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/bebb8b03/attachment-0003.html From eli.friedman at gmail.com Tue Feb 22 18:59:46 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 22 Feb 2011 16:59:46 -0800 Subject: [LLVMdev] STM8 backend for Clang In-Reply-To: References: <15CFFE06-A81F-4E13-88C6-26A42ABCB476@web.de> Message-ID: On Tue, Feb 22, 2011 at 10:59 AM, Andreas F?rber wrote: > Am 21.02.2011 um 02:44 schrieb Eli Friedman: > >> On Sun, Feb 20, 2011 at 4:23 PM, Andreas F?rber >> wrote: >>> >>> The first issue I stumbled upon was that the Program Counter register >>> is 24 bits. [...] >> >> [...] if the only >> 24-bit register is the program counter, you could probably get away >> with pretending it's a 32-bit register. >> >>> Further, as pointer width I chose 16 bits since there currently seems >>> to be no way to distinguish between near and far pointers? >> >> LLVM doesn't support distinguishing between near and far pointers. >> Depending on how much work you want to put in and what exactly you're >> trying to build, you might be able to get away with just pretending >> all pointers are near and implementing __builtin_stm8_far_loadn() and >> __builtin_stm8_far_storen() intrinsics, though. > > The example C code uses far pointers, e.g., to set up interrupt vectors: > > typedef void @far (*interrupt_handler_t)(void); > > struct interrupt_vector > { > ?unsigned char interrupt_instruction; > ?interrupt_handler_t interrupt_handler; > }; > > So I do need support for 24-bit pointers in the Clang frontend, in order for > the struct to fill four bytes here. > Not sure how intrinsics could help there. I assume that @far is a > non-standard keyword. Is it possible to derive a new language standard > similar to GCC's --std=gnu99 to handle such extensions? The only guide I > could find was on how to add an attribute... You can add extensions that are enabled for only a particular target; it's just that adding new syntax tends to be a lot of work. Builtins are a lot easier to implement. :) As for how to do it, just start with parsing and work your way down the pipeline; there isn't any guide because the specifics tend to vary a lot with the extension you're implementing. -Eli From x.tong at utoronto.ca Tue Feb 22 19:14:02 2011 From: x.tong at utoronto.ca (Xin Tong Utoronto) Date: Tue, 22 Feb 2011 20:14:02 -0500 Subject: [LLVMdev] LLVM ExecutionEngine/JIT trampoline question In-Reply-To: References: Message-ID: I understand that we need to push the address to a register then branch using the register. But i am asking why there is a trampoline there such that a call to foo is first branched to an snippet and the snippet branches to the X86CompilationCallback. is this snippet necessary ? Thanks Xin On Tue, Feb 22, 2011 at 12:39 PM, Reid Kleckner wrote: > The address of the callee may be more than 2 GB away in memory, which > cannot be encoded as an immediate offset in the call instruction. So, > the value is first materialized with a mov instruction which can > encode the immediate and then jumped to through a register. > > Reid > > On Tue, Feb 22, 2011 at 12:03 PM, Xin Tong Utoronto > wrote: > > I have a question on the LLVM JIT > > > > I did some brief memory reading one day and I found that a call to a > > non-library function is resolved by the X86CompilationCallback, but the > > X86CompilationCallback is reached through a trampoline. why can not the > > generated code jump to the X86CompilationCallback function directly ? > > > > 0x2b0a6a4d103b: mov $0x2b0a6a561010,%rax > > 0x2b0a6a4d1045: callq *%rax > > // call foo > >> > >> > >> ==> > >> > >> 0x2b0a6a561010: mov $0xa743a0,%r10 // some kind of > >> trampoline > >> 0x2b0a6a56101a: callq *%r10 > >> > >> ==> > >> > >> 0xa743a0 : push %rbp > >> 0xa743a1 : mov %rsp,%rbp > >> 0xa743a4 : push %rdi > >> 0xa743a5 : push %rsi > > > > -- > > Kind Regards > > > > Xin Tong > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > -- Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/d97d7221/attachment.html From sujatha.gurumurthy at intel.com Tue Feb 22 19:21:31 2011 From: sujatha.gurumurthy at intel.com (Gurumurthy, Sujatha) Date: Tue, 22 Feb 2011 17:21:31 -0800 Subject: [LLVMdev] LLVMdev Digest, Vol 80, Issue 37-Help to unsubscribe In-Reply-To: References: Message-ID: Please unsubscribe me from this list. Sujatha Gurumurthy Staffing Consultant/Talent Advisor UMG - Ultra Mobile Group sujatha.gurumurthy at intel.com US ERP Manager Interested in Employee Referral Program Visit referral.intel.com/ Intel USA Employee Referral Program Group 100 Best Companies to Work For 2011: Intel - INTC - from FORTUNE -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of llvmdev-request at cs.uiuc.edu Sent: Tuesday, February 22, 2011 4:47 PM To: llvmdev at cs.uiuc.edu Subject: LLVMdev Digest, Vol 80, Issue 37 Send LLVMdev mailing list submissions to llvmdev at cs.uiuc.edu To subscribe or unsubscribe via the World Wide Web, visit http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev or, via email, send a message with subject or body 'help' to llvmdev-request at cs.uiuc.edu You can reach the person managing the list at llvmdev-owner at cs.uiuc.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of LLVMdev digest..." Today's Topics: 1. Re: attaching metadata to llvm::Argument (Andrew Clinton) 2. Re: STM8 backend for Clang (Andreas F?rber) 3. Clone a function and change signature (Arushi Aggarwal) 4. Re: Clone a function and change signature (John Criswell) 5. Re: Structure Types and ABI sizes (David A. Greene) 6. Re: still failed to build the llbrowse on Debian5-32b-llvm2.8 (Talin) 7. repo.or.cz GIT mirrors (Anton Korobeynikov) 8. Re: Questions about LLVM IR encoding (David A. Greene) 9. Re: Clone a function and change signature (Chris Lattner) 10. Re: Question about Value Range Propagation (Chris Lattner) 11. Re: unary floating point operations using clang (Chris Lattner) 12. Re: Question about Value Range Propagation (John Criswell) 13. Re: still failed to build the llbrowse on Debian5-32b-llvm2.8 (Chuck Zhao) 14. duplicate .debug_line sections (Dineth) 15. Re: duplicate .debug_line sections (Devang Patel) 16. obtain the address and size of LLVM generated temporaries (Chuck Zhao) 17. Re: obtain the address and size of LLVM generated temporaries (Yuri) 18. Re: Structure Types and ABI sizes (Jochen Wilhelmy) 19. virtual register does not exist (drizzle drizzle) 20. Re: Looking for more LLBrowse testers / users (John Myers) 21. Re: virtual register does not exist (Jakob Stoklund Olesen) 22. Re: Can I use Clang to parse snippets of C++ code? (F?lix Cloutier) ---------------------------------------------------------------------- Message: 1 Date: Tue, 22 Feb 2011 13:00:24 -0500 From: Andrew Clinton Subject: Re: [LLVMdev] attaching metadata to llvm::Argument To: LLVM Developers Mailing List Message-ID: <4D63F9B8.9070305 at sidefx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed The reason that I need this is that I'm supporting runtime function specialization, where the arguments have known default values. When the function is specialized, I need to replace uses of the argument with the default value. I could not find any other way to store the metadata for the default values other than to use module-level data. Does anyone know a better way to accomplish this in the LLVM IR? On 02/22/2011 12:41 PM, Andrew Clinton wrote: > I too would have an immediate application if metadata could be attached > to arguments. I'm currently working around it by using named metadata > in the module (matched by index to the arguments). > > Andrew > > On 02/21/2011 11:18 AM, Florian Merz wrote: >> Hey everyone, >> >> I'm trying to retrieve information about signed-/unsignedness of an >> llvm::Argument so I can print out it's value to the user properly. llvm itself >> doesn't distinguish signed and unsigned and so llvm::Type is of no help here. >> Checking for nsw/usw is only an unreliable approximation and only available >> for llvm::Instructions anyways. >> >> I tried to use debugging information (llvm::DIType) for this, but >> getMetadata() is not available for llvm::Argument, only for llvm::Instruction. >> >> Is there any other way to get at this information? >> >> Regards, >> Florian >> _______________________________________________ >> 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 ------------------------------ Message: 2 Date: Tue, 22 Feb 2011 19:59:52 +0100 From: Andreas F?rber Subject: Re: [LLVMdev] STM8 backend for Clang To: Eli Friedman Cc: llvmdev at cs.uiuc.edu Message-ID: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Am 21.02.2011 um 02:44 schrieb Eli Friedman: > On Sun, Feb 20, 2011 at 4:23 PM, Andreas F?rber > wrote: >> The first issue I stumbled upon was that the Program Counter register >> is 24 bits. [...] > > [...] if the only > 24-bit register is the program counter, you could probably get away > with pretending it's a 32-bit register. > >> Further, as pointer width I chose 16 bits since there currently seems >> to be no way to distinguish between near and far pointers? > > LLVM doesn't support distinguishing between near and far pointers. > Depending on how much work you want to put in and what exactly you're > trying to build, you might be able to get away with just pretending > all pointers are near and implementing __builtin_stm8_far_loadn() and > __builtin_stm8_far_storen() intrinsics, though. The example C code uses far pointers, e.g., to set up interrupt vectors: typedef void @far (*interrupt_handler_t)(void); struct interrupt_vector { unsigned char interrupt_instruction; interrupt_handler_t interrupt_handler; }; So I do need support for 24-bit pointers in the Clang frontend, in order for the struct to fill four bytes here. Not sure how intrinsics could help there. I assume that @far is a non- standard keyword. Is it possible to derive a new language standard similar to GCC's --std=gnu99 to handle such extensions? The only guide I could find was on how to add an attribute... Andreas ------------------------------ Message: 3 Date: Tue, 22 Feb 2011 13:31:55 -0600 From: Arushi Aggarwal Subject: [LLVMdev] Clone a function and change signature To: llvmdev at cs.uiuc.edu Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi, I want to clone a given function, and add an argument to it. I then want to add a call to that new function. I have a callInstruction CI, which I want to transform to call this new function, and to take a new argument. The code I added was as follows CI->getCalledFunction()->dump(); Function* DirectF = CloneFunction(CI->getCalledFunction()); DirectF->setName(CI->getCalledFunction()->getNameStr() + "_SPEC"); DirectF->setLinkage(GlobalValue::InternalLinkage); // add the extra argument new Argument(GEP->getPointerOperand()->getType(),"arg",DirectF); M.getFunctionList().push_back(DirectF); DirectF->dump(); SmallVector Args; for(unsigned j =1;jgetNumOperands();j++) { Args.push_back(CI->getOperand(j)); } //Add the extra parameter Args.push_back(GEP->getPointerOperand()); CallInst *CallI = CallInst::Create(DirectF,Args.begin(), Args.end(),"", CI); CallI->dump(); But I get the following exception call void @point_DIRECT(i16* %tmp1324mod, i16* %tmp1322mod) nounwind define internal void @point_DIRECT(i16* %x, i16* %y) nounwind { entry: %xx = alloca i32 ; [#uses=3] %yy = alloca i32 ; [#uses=3] %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*> [#uses=1] %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; [#uses=1] br i1 %tmp1, label %return, label %bb, !dbg !1018 bb: ; preds = %entry %tmp2 = load i16* %x, align 2, !dbg !1023 ; [#uses=1] %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; [#uses=1] store i32 %tmp3, i32* %xx, align 4, !dbg !1023 %tmp4 = load i16* %y, align 2, !dbg !1024 ; [#uses=1] %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; [#uses=1] store i32 %tmp5, i32* %yy, align 4, !dbg !1024 %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*> [#uses=1] call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) nounwind %tmp8 = load i32* %xx, align 4, !dbg !1026 ; [#uses=1] %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; [#uses=1] store i16 %tmp9, i16* %x, align 2, !dbg !1026 %tmp10 = load i32* %yy, align 4, !dbg !1027 ; [#uses=1] %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; [#uses=1] store i16 %tmp11, i16* %y, align 2, !dbg !1027 ret void return: ; preds = %entry ret void } define internal void @point_DIRECT_SPEC(i16* %x, i16* %y, %struct.termbox* %arg) nounwind { entry: %xx = alloca i32 ; [#uses=3] %yy = alloca i32 ; [#uses=3] %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*> [#uses=1] %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; [#uses=1] br i1 %tmp1, label %return, label %bb, !dbg !1018 bb: ; preds = %entry %tmp2 = load i16* %x, align 2, !dbg !1023 ; [#uses=1] %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; [#uses=1] store i32 %tmp3, i32* %xx, align 4, !dbg !1023 %tmp4 = load i16* %y, align 2, !dbg !1024 ; [#uses=1] %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; [#uses=1] store i32 %tmp5, i32* %yy, align 4, !dbg !1024 %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*> [#uses=1] call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) nounwind %tmp8 = load i32* %xx, align 4, !dbg !1026 ; [#uses=1] %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; [#uses=1] store i16 %tmp9, i16* %x, align 2, !dbg !1026 %tmp10 = load i32* %yy, align 4, !dbg !1027 ; [#uses=1] %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; [#uses=1] store i16 %tmp11, i16* %y, align 2, !dbg !1027 ret void return: ; preds = %entry ret void } opt: /home/vadve/aggarwa4/llvm27/llvm-2.7/lib/VMCore/Instructions.cpp:307: void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int): Assertion `(NumParams == FTy->getNumParams() || (FTy->isVarArg() && NumParams > FTy->getNumParams())) && "Calling a function with bad signature!"' failed. When I looked at the excption, it occurs when creating the CallInst. The type of the function being called at that point is still the old type, without the extra parameter, though the extra parameter seems to have been added when I dump DirectF. Can I get any pointers to what I am doing wrong, and what might be a potential solution. Thanks, Arushi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/618028cf/attachment-0001.html ------------------------------ Message: 4 Date: Tue, 22 Feb 2011 13:46:45 -0600 From: John Criswell Subject: Re: [LLVMdev] Clone a function and change signature To: Arushi Aggarwal Cc: "llvmdev at cs.uiuc.edu" Message-ID: <4D6412A5.1030300 at illinois.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed On 2/22/11 1:31 PM, Arushi Aggarwal wrote: > Hi, > > I want to clone a given function, and add an argument to it. I then > want to add a call to that new function. I have a callInstruction CI, > which I want to transform to call this new function, and to take a new > argument. If I understand correctly, you're cloning the function first and then adding a new argument to the clone. Do I understand correctly? If so, I don't believe you can do that. IIRC, you have to first create a new, empty function with the additional argument and then use CloneFunctionInto() to clone the body of the original function into the new function. I believe that's what poolalloc does and what I did the last time I had to add function arguments to a function. -- John T. > > The code I added was as follows > > CI->getCalledFunction()->dump(); > Function* DirectF = CloneFunction(CI->getCalledFunction()); > DirectF->setName(CI->getCalledFunction()->getNameStr() + "_SPEC"); > DirectF->setLinkage(GlobalValue::InternalLinkage); > // add the extra argument > new Argument(GEP->getPointerOperand()->getType(),"arg",DirectF); > M.getFunctionList().push_back(DirectF); > DirectF->dump(); > > SmallVector Args; > for(unsigned j =1;jgetNumOperands();j++) { > Args.push_back(CI->getOperand(j)); > } > //Add the extra parameter > Args.push_back(GEP->getPointerOperand()); > CallInst *CallI = CallInst::Create(DirectF,Args.begin(), > Args.end(),"", CI); > CallI->dump(); > > > But I get the following exception > > call void @point_DIRECT(i16* %tmp1324mod, i16* %tmp1322mod) nounwind > > define internal void @point_DIRECT(i16* %x, i16* %y) nounwind { > entry: > %xx = alloca i32 ; [#uses=3] > %yy = alloca i32 ; [#uses=3] > %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*> > [#uses=1] > %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; [#uses=1] > br i1 %tmp1, label %return, label %bb, !dbg !1018 > > bb: ; preds = %entry > %tmp2 = load i16* %x, align 2, !dbg !1023 ; [#uses=1] > %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; [#uses=1] > store i32 %tmp3, i32* %xx, align 4, !dbg !1023 > %tmp4 = load i16* %y, align 2, !dbg !1024 ; [#uses=1] > %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; [#uses=1] > store i32 %tmp5, i32* %yy, align 4, !dbg !1024 > %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*> > [#uses=1] > call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) > nounwind > %tmp8 = load i32* %xx, align 4, !dbg !1026 ; [#uses=1] > %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; [#uses=1] > store i16 %tmp9, i16* %x, align 2, !dbg !1026 > %tmp10 = load i32* %yy, align 4, !dbg !1027 ; [#uses=1] > %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; [#uses=1] > store i16 %tmp11, i16* %y, align 2, !dbg !1027 > ret void > > return: ; preds = %entry > ret void > } > > > define internal void @point_DIRECT_SPEC(i16* %x, i16* %y, > %struct.termbox* %arg) nounwind { > entry: > %xx = alloca i32 ; [#uses=3] > %yy = alloca i32 ; [#uses=3] > %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*> > [#uses=1] > %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; [#uses=1] > br i1 %tmp1, label %return, label %bb, !dbg !1018 > > bb: ; preds = %entry > %tmp2 = load i16* %x, align 2, !dbg !1023 ; [#uses=1] > %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; [#uses=1] > store i32 %tmp3, i32* %xx, align 4, !dbg !1023 > %tmp4 = load i16* %y, align 2, !dbg !1024 ; [#uses=1] > %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; [#uses=1] > store i32 %tmp5, i32* %yy, align 4, !dbg !1024 > %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*> > [#uses=1] > call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) > nounwind > %tmp8 = load i32* %xx, align 4, !dbg !1026 ; [#uses=1] > %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; [#uses=1] > store i16 %tmp9, i16* %x, align 2, !dbg !1026 > %tmp10 = load i32* %yy, align 4, !dbg !1027 ; [#uses=1] > %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; [#uses=1] > store i16 %tmp11, i16* %y, align 2, !dbg !1027 > ret void > > return: ; preds = %entry > ret void > } > > opt: > /home/vadve/aggarwa4/llvm27/llvm-2.7/lib/VMCore/Instructions.cpp:307: > void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned > int): Assertion `(NumParams == FTy->getNumParams() || (FTy->isVarArg() > && NumParams > FTy->getNumParams())) && "Calling a function with bad > signature!"' failed. > > > When I looked at the excption, it occurs when creating the CallInst. > > The type of the function being called at that point is still the old > type, without the extra parameter, though the extra parameter seems to > have been added when I dump DirectF. > > Can I get any pointers to what I am doing wrong, and what might be a > potential solution. > > Thanks, > Arushi ------------------------------ Message: 5 Date: Tue, 22 Feb 2011 14:20:56 -0600 From: greened at obbligato.org (David A. Greene) Subject: Re: [LLVMdev] Structure Types and ABI sizes To: Jochen Wilhelmy Cc: "llvmdev at cs.uiuc.edu" Message-ID: Content-Type: text/plain; charset=us-ascii Jochen Wilhelmy writes: > struct I { > int a; > char b; > }; > > struct J : I { > char c; > }; > > Dave said that this translates to > > %I = type { i32, i8, i16 } > %J = type { %I, i8, i16 } It translates to that in OUR compiler. It's not the only answer. > because the frontend has to communicate the ABI to llvm since llvm is > language agnostic. Correct. > What I really wonder is why it isn't > > %I = type { i32, i8 } > %J = type { %I, i16, i8 } > > because llvm at least knows alignment rules by > > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16... > > Therefore llvm has no other choice than assigning %I a size of 8 > since an array may consist of %I elements and size of 5 would violate > the aligment of the i32 member. I can't quite parse this. %I doesn't get "assigned" a size by anyone. Do you meant the size of struct I is eight bytes? Yes, that's true. > If the ABI requires that member c has an offset of 8 instead of 5 then > of course a padding behind %I is necessary in %J. Yes, the padding is required. I believe %J = type { %I, i16, i8 } would work just as well as long as %I = type { i32, i8 } as in your example. Our frontend is far from "perfect" in the sense of aesthetics. :) -Dave ------------------------------ Message: 6 Date: Tue, 22 Feb 2011 12:23:27 -0800 From: Talin Subject: Re: [LLVMdev] still failed to build the llbrowse on Debian5-32b-llvm2.8 To: Chuck Zhao Cc: LLVM Developers Mailing List Message-ID: Content-Type: text/plain; charset="iso-8859-1" OK try it now - I checked in a few more fixes. On Tue, Feb 22, 2011 at 8:29 AM, Chuck Zhao wrote: > I still can't build LLBrowse on my Debian5-i386 machine today, > The following is a full build console output. > I am using LLVM-2.8 release build, with needed wxWidgets and CMake. > > Thank you > > Chuck > > sideshow.eecg>time cmake ../llbrowse > -- The C compiler identification is GNU > -- The CXX compiler identification is GNU > -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc > -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Found wxWidgets: TRUE > -- Looking for assert.h > -- Looking for assert.h - found > -- Looking for auto_ptr.h > -- Looking for auto_ptr.h - not found > -- Looking for C++ include memory > -- Looking for C++ include memory - found > -- LLVM llvm-config found at: > /steffan/a/a0/czhao/opt/opt32/llvm-2.8r/bin/llvm-config > -- Configuring done > -- Generating done > -- Build files have been written to: > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/obj > 1.976u 2.100s 0:14.37 28.3% 0+0k 48680+2392io 174pf+0w > sideshow.eecg>time make > [ 5%] Converting PNG image file resources/icons/folder.png > [ 11%] Converting PNG image file resources/icons/collapse.png > [ 16%] Converting PNG image file resources/icons/typeref.png > [ 22%] Converting PNG image file resources/icons/expand.png > [ 27%] Converting PNG image file resources/icons/type.png > [ 33%] Converting PNG image file resources/icons/function.png > [ 38%] Converting PNG image file resources/icons/module.png > [ 44%] Converting PNG image file resources/icons/variable.png > [ 50%] Converting PNG image file resources/icons/debug.png > [ 55%] Converting PNG image file resources/icons/meta.png > [ 61%] Converting PNG image file resources/icons/alias.png > [ 66%] Converting PNG image file resources/icons/constant.png > Scanning dependencies of target llbrowse > [ 72%] Building CXX object CMakeFiles/llbrowse.dir/lib/BrowserFrame.cpp.o > [ 77%] Building CXX object CMakeFiles/llbrowse.dir/lib/DetailsView.cpp.o > [ 83%] Building CXX object CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp: > In member function 'virtual bool BrowserApp::OnInit()': > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp:29: > error: 'PrintStackTraceOnErrorSignal' is not a member of 'llvm::sys' > make[2]: *** [CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o] Error 1 > make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 > make: *** [all] Error 2 > 7.228u 1.228s 0:12.34 68.3% 0+0k 13512+1784io 3pf+0w > > sideshow.eecg> > > > -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/4bd0c5e3/attachment-0001.html ------------------------------ Message: 7 Date: Tue, 22 Feb 2011 23:27:01 +0300 From: Anton Korobeynikov Subject: [LLVMdev] repo.or.cz GIT mirrors To: LLVM Developers Mailing List Cc: clang-dev Developers Message-ID: Content-Type: text/plain; charset=UTF-8 Hello Everyone As you might already know, git mirrors of llvm repository started from repo.or.cz mirrors, where stuff was pushed almost by hands out of git-svn local copy. Right now we have official and automatically updated GIT mirrors on llvm.org and thus repo.or.cz mirrors look a bit redundant. However, they might still be useful, but definitely not within the current "push mode". It is possible to convert them to plain GIT mirrors of llvm.org GIT mirrors with automatic pulling, but this, in fact, will require us to delete repo.or.cz repos and recreate them from scratch. I hope this would affect only forks, from which only 1-2 seem to be active (and hopefully they can be just recreated on top of new projects). Any objections for such procedure? Maybe someone will have better idea? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University ------------------------------ Message: 8 Date: Tue, 22 Feb 2011 14:34:55 -0600 From: greened at obbligato.org (David A. Greene) Subject: Re: [LLVMdev] Questions about LLVM IR encoding To: ?? Cc: llvmdev at cs.uiuc.edu Message-ID: Content-Type: text/plain; charset=utf-8 ?? writes: > Hi all, I am new to LLVM (even the field of compiler) and currently I am engaged in the work of adapting LLVM IR to M5 simulator to observe > the enhancement of the novel architecture we design. > Simply speaking if you know?little about?M5, my aim is to know how LLVM IR is interpreted and encoded, then try to implement it in the > framework of M5. > I have read the LLVM documents, yet I still have some questions as follows: > ? > 1. As IR is target-independent, how can we encode them into bit-code executable files without specific?targets' information??? > 2. The "bitstream container format" as the document refers, is XML-like, and I wonder how does LLVM translate it into executable format such > as bit-code. If I'm understanding you correctly, you want to treat LLVM IR as an ISA and simulate that in M5, writing a new M5 target to execute LLVM IR in bitcode format. Is that right? I don't think that's a good option. While it can theoretically be done, you're going to miss very important machine aspects such as: - limited register set - alignment issues - calling sequence - instruction/text size There are others, but all of the above can impact performance in major ways. Not modeling them is going to give you very inaccurate results. If you can express your architectural enhancement in one of the existing targets, I would do that. At the very worst you can create new instructions (say, for x86) and insert them into the asm stream with raw .byte directives in the .s file. I've done that many times in the past. Another option is to create a new Target in LLVM and define the ISA you want to evaluate. This is a lot more work as it requires a new Target in LLVM and a new implementation for M5 but it gives you more flexibility and makes future changes easier. I would go with one of the existing Targets if possible and add any new instructions you need. That's going to give you the most realistic results. -Dave ------------------------------ Message: 9 Date: Tue, 22 Feb 2011 12:43:27 -0800 From: Chris Lattner Subject: Re: [LLVMdev] Clone a function and change signature To: John Criswell Cc: "llvmdev at cs.uiuc.edu" Message-ID: Content-Type: text/plain; charset=us-ascii On Feb 22, 2011, at 11:46 AM, John Criswell wrote: > On 2/22/11 1:31 PM, Arushi Aggarwal wrote: >> Hi, >> >> I want to clone a given function, and add an argument to it. I then >> want to add a call to that new function. I have a callInstruction CI, >> which I want to transform to call this new function, and to take a new >> argument. > > If I understand correctly, you're cloning the function first and then > adding a new argument to the clone. Do I understand correctly? > > If so, I don't believe you can do that. IIRC, you have to first create > a new, empty function with the additional argument and then use > CloneFunctionInto() to clone the body of the original function into the > new function. I believe that's what poolalloc does and what I did the > last time I had to add function arguments to a function. Right, you can also take a look at the dead argument elimination or argument promotion passes for examples. -Chris ------------------------------ Message: 10 Date: Tue, 22 Feb 2011 12:44:18 -0800 From: Chris Lattner Subject: Re: [LLVMdev] Question about Value Range Propagation To: Reid Kleckner Cc: llvmdev at cs.uiuc.edu Message-ID: <1D82F914-A36A-4447-B36C-70E46F35B751 at apple.com> Content-Type: text/plain; charset=us-ascii On Feb 22, 2011, at 7:25 AM, Reid Kleckner wrote: > On Tue, Feb 22, 2011 at 6:19 AM, Duncan Sands wrote: >> the big problem with Patterson's VRP is that it is expensive in terms of >> compile time. LLVM used to have some passes (ABCD, predsimplify) that did >> this kind of thing, but they were removed essentially because their compile >> time was too great for the goodness they brought. > > Any reason not to just leave them on at O3? Based on the discussion > around your simple condition propagation pass, it seemed predsimplify > did delete dead code, but it didn't really improve generated code > performance. O3 seems the appropriate place to put expensive > optimizations with diminishing returns. Hi Reid, -O3 compile time matters. We don't turn things on in -O3 or -O4 that just burn compiler cycles but don't add value. -Chris ------------------------------ Message: 11 Date: Tue, 22 Feb 2011 12:44:41 -0800 From: Chris Lattner Subject: Re: [LLVMdev] unary floating point operations using clang To: Alexandru Dura Cc: llvmdev at cs.uiuc.edu Message-ID: Content-Type: text/plain; charset=us-ascii On Feb 22, 2011, at 12:40 AM, Alexandru Dura wrote: > Hello, > > Is there a way of generating unary floating point operations (like ISD::FABS, ISD::FSIN, ...) from C code using clang? I am building a backend for a machine that has hw support for these ops and I need a way to test them. Sure, just call sin() and cos(). -Chris ------------------------------ Message: 12 Date: Tue, 22 Feb 2011 14:57:34 -0600 From: John Criswell Subject: Re: [LLVMdev] Question about Value Range Propagation To: Duncan Sands Cc: "llvmdev at cs.uiuc.edu" Message-ID: <4D64233E.20006 at illinois.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed On 2/22/11 5:19 AM, Duncan Sands wrote: > Hi Andrey, > >> On 21.02.2011 20:27, Douglas do Couto Teixeira wrote: >>> My work is not part of the LLVM mainline yet. But I would be happy to >>> contribute with the code of my range analysis implementation if it can help >>> you in something else. >> We were thinking of adding VRP to LLVM too, though we were mostly >> interested in Patterson's approach (i.e. not connected with SSI form). It >> would be great if you can share the code nevertheless. > the big problem with Patterson's VRP is that it is expensive in terms of > compile time. LLVM used to have some passes (ABCD, predsimplify) that did > this kind of thing, but they were removed essentially because their compile > time was too great for the goodness they brought. I was under the impression that ABCD was removed because no one was maintaining and improving it. Is my impression incorrect? The SAFECode compiler adds additional run-time checks for array bounds checking. If the ABCD code was working but just wasn't useful for regular C code, I'd like to know. It may still have value for projects like SAFECode. -- John T. > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev ------------------------------ Message: 13 Date: Tue, 22 Feb 2011 16:36:03 -0500 From: Chuck Zhao Subject: Re: [LLVMdev] still failed to build the llbrowse on Debian5-32b-llvm2.8 To: Talin Cc: LLVM Developers Mailing List Message-ID: <4D642C43.7030806 at eecg.toronto.edu> Content-Type: text/plain; charset="iso-8859-1" Nice, It builds and runs fine now. Thank you, Talin Chuck On 2/22/2011 3:23 PM, Talin wrote: > OK try it now - I checked in a few more fixes. > > On Tue, Feb 22, 2011 at 8:29 AM, Chuck Zhao > wrote: > > I still can't build LLBrowse on my Debian5-i386 machine today, > The following is a full build console output. > I am using LLVM-2.8 release build, with needed wxWidgets and CMake. > > Thank you > > Chuck > > sideshow.eecg>time cmake ../llbrowse > -- The C compiler identification is GNU > -- The CXX compiler identification is GNU > -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc > -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc > -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Found wxWidgets: TRUE > -- Looking for assert.h > -- Looking for assert.h - found > -- Looking for auto_ptr.h > -- Looking for auto_ptr.h - not found > -- Looking for C++ include memory > -- Looking for C++ include memory - found > -- LLVM llvm-config found at: > /steffan/a/a0/czhao/opt/opt32/llvm-2.8r/bin/llvm-config > -- Configuring done > -- Generating done > -- Build files have been written to: > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/obj > 1.976u 2.100s 0:14.37 28.3% 0+0k 48680+2392io 174pf+0w > sideshow.eecg>time make > [ 5%] Converting PNG image file resources/icons/folder.png > [ 11%] Converting PNG image file resources/icons/collapse.png > [ 16%] Converting PNG image file resources/icons/typeref.png > [ 22%] Converting PNG image file resources/icons/expand.png > [ 27%] Converting PNG image file resources/icons/type.png > [ 33%] Converting PNG image file resources/icons/function.png > [ 38%] Converting PNG image file resources/icons/module.png > [ 44%] Converting PNG image file resources/icons/variable.png > [ 50%] Converting PNG image file resources/icons/debug.png > [ 55%] Converting PNG image file resources/icons/meta.png > [ 61%] Converting PNG image file resources/icons/alias.png > [ 66%] Converting PNG image file resources/icons/constant.png > Scanning dependencies of target llbrowse > [ 72%] Building CXX object > CMakeFiles/llbrowse.dir/lib/BrowserFrame.cpp.o > [ 77%] Building CXX object > CMakeFiles/llbrowse.dir/lib/DetailsView.cpp.o > [ 83%] Building CXX object > CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp: > In member function 'virtual bool BrowserApp::OnInit()': > /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp:29: > error: 'PrintStackTraceOnErrorSignal' is not a member of 'llvm::sys' > make[2]: *** [CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o] Error 1 > make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2 > make: *** [all] Error 2 > 7.228u 1.228s 0:12.34 68.3% 0+0k 13512+1784io 3pf+0w > > sideshow.eecg> > > > > > > -- > -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/b4bb8299/attachment-0001.html ------------------------------ Message: 14 Date: Tue, 22 Feb 2011 16:47:40 -0500 From: Dineth Subject: [LLVMdev] duplicate .debug_line sections To: llvmdev Message-ID: Content-Type: text/plain; charset=ISO-8859-1 I'm using LLVM 2.8 with GNU Binutils for Ubuntu 2.20.51-system.20100908. When I try to assemble a .s file generated with llc with g++ I get the error: Fatal error: duplicate .debug_line sections. I'm using llvm-gcc/g++ as front end. I also tried generating the .o file directly using -filetype=obj but that too fails with BFD: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 assertion fail ../../bfd/elf.c:1805 when trying to convert the .o file to an archive with ar. I would appreciate any help very much. Thanks. -- dineth ------------------------------ Message: 15 Date: Tue, 22 Feb 2011 13:54:44 -0800 From: Devang Patel Subject: Re: [LLVMdev] duplicate .debug_line sections To: Dineth Cc: llvmdev Message-ID: <41D33723-1B56-4AB0-A239-301A21902E5E at apple.com> Content-Type: text/plain; charset=us-ascii On Feb 22, 2011, at 1:47 PM, Dineth wrote: > I'm using LLVM 2.8 with GNU Binutils for Ubuntu > 2.20.51-system.20100908. When I try to assemble a .s file generated > with llc with g++ I get the error: > > Fatal error: duplicate .debug_line sections. This is probably http://llvm.org/bugs/show_bug.cgi?id=6218 - Devang > > I'm using llvm-gcc/g++ as front end. > > I also tried generating the .o file directly using -filetype=obj but > that too fails with > > BFD: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 assertion > fail ../../bfd/elf.c:1805 > > when trying to convert the .o file to an archive with ar. > > I would appreciate any help very much. Thanks. > ------------------------------ Message: 16 Date: Tue, 22 Feb 2011 17:01:53 -0500 From: Chuck Zhao Subject: [LLVMdev] obtain the address and size of LLVM generated temporaries To: LLVM Developers Mailing List Message-ID: <4D643251.1080809 at eecg.toronto.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I wonder what is the right approach to obtain the address and size of LLVM (compiler) generated temporaries? E.g. %0 = %x + %y store i32 i0, i32 %z, align 4 How can I get the address of %0 (which could be either a stack or heap variable)? Thank you Chuck ------------------------------ Message: 17 Date: Tue, 22 Feb 2011 14:29:13 -0800 From: Yuri Subject: Re: [LLVMdev] obtain the address and size of LLVM generated temporaries To: Chuck Zhao Cc: LLVM Developers Mailing List Message-ID: <4D6438B9.9050405 at rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 02/22/2011 14:01, Chuck Zhao wrote: > I wonder what is the right approach to obtain the address and size of > LLVM (compiler) generated temporaries? > > E.g. > > %0 = %x + %y > store i32 i0, i32 %z, align 4 > > How can I get the address of %0 (which could be either a stack or heap > variable)? > This is not possible since such value can also be in register. Yuri ------------------------------ Message: 18 Date: Tue, 22 Feb 2011 23:39:07 +0100 From: Jochen Wilhelmy Subject: Re: [LLVMdev] Structure Types and ABI sizes To: "David A. Greene" Cc: "llvmdev at cs.uiuc.edu" Message-ID: <4D643B0B.1090809 at arcor.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> What I really wonder is why it isn't >> >> %I = type { i32, i8 } >> %J = type { %I, i16, i8 } >> >> because llvm at least knows alignment rules by >> >> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16... >> >> Therefore llvm has no other choice than assigning %I a size of 8 >> since an array may consist of %I elements and size of 5 would violate >> the aligment of the i32 member. > I can't quite parse this. %I doesn't get "assigned" a size by anyone. > Do you meant the size of struct I is eight bytes? Yes, that's true. Yes I mean that %I = type { i32, i8 } is 8 bytes given the alignment rules (i.e. llvm "assigns" a size of 8 bytes to this struct after parsing it) > Yes, the padding is required. I believe %J = type { %I, i16, i8 } would > work just as well as long as %I = type { i32, i8 } as in your example. Yes but given the ABI requires the last member to be at offset 5, which may happen (i.e. no tail padding if I is derived from), then your solution %I = type { i32, i8, i16 } is problematic or do you switch struct generation dependent on the ABI? The question arises to me since I would use an "always working" solution (with no case distinction) but of course I'm not deep enough in the matter. -Jochen ------------------------------ Message: 19 Date: Tue, 22 Feb 2011 15:37:19 -0800 From: drizzle drizzle Subject: [LLVMdev] virtual register does not exist To: LLVMdev at cs.uiuc.edu Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi is there a way to know later that an earlier pass inside the codegen might have eliminated a virtual register. I carry information abt virtual registers which i would like to update if any virtual register does not exist since. thanks dz ------------------------------ Message: 20 Date: Tue, 22 Feb 2011 15:46:30 -0800 From: John Myers Subject: Re: [LLVMdev] Looking for more LLBrowse testers / users To: Talin , LLVM Developers Mailing List Message-ID: Content-Type: text/plain; charset="iso-8859-1" On Tue, Feb 22, 2011 at 3:30 PM, Talin wrote: > This should be fixed now. > -- > -- Talin > Thanks, It compiles and runs now. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/167f6951/attachment-0001.html ------------------------------ Message: 21 Date: Tue, 22 Feb 2011 16:24:47 -0800 From: Jakob Stoklund Olesen Subject: Re: [LLVMdev] virtual register does not exist To: drizzle drizzle Cc: LLVMdev at cs.uiuc.edu Message-ID: Content-Type: text/plain; charset=us-ascii On Feb 22, 2011, at 3:37 PM, drizzle drizzle wrote: > Hi > is there a way to know later that an earlier pass inside the codegen > might have eliminated a virtual register. > I carry information abt virtual registers which i would like to update > if any virtual register does not exist since. You can check if any instructions are using it with MRI->reg_nodbg_empty(Reg). /jakob ------------------------------ Message: 22 Date: Tue, 22 Feb 2011 19:46:24 -0500 From: F?lix Cloutier Subject: Re: [LLVMdev] Can I use Clang to parse snippets of C++ code? To: Chris Lattner Cc: LLVM Developers Mailing List Message-ID: <5E4C34C9-B5D2-4F6C-819F-25E79E217479 at yahoo.ca> Content-Type: text/plain; charset="iso-8859-1" I believe that what I'm trying to do with Clang is fairly simple; the final goal, however, might be a little harder. Knowing myself, there are chances I'll never go through with this project (like Mikael who posted earlier, I'm nothing but an enthusiastic student with lots of time on my hands), but it feels cool enough to me to announce my idea. Besides, I'll probably need help from more knowledgeable people anyways. The way LLVM works makes it pretty easy and straightforward to generate code from nested structures (like ASTs), which is totally commendable since LLVM is a compiler back-end. However, in the past months I've set myself to make an emulator back-end with LLVM that would translate machine code to LLBC then compile it to native code with the JIT, and my experience haven't been so great, especially because of the following: it's stupid-hard to debug just-in-time generated code with the version of gdb that ships with Xcode (it repeatedly crashed on me); the sheer number of cases to treat is, in itself, rebuking enough: a NES 6502 is 'fine' with just less than 60 distinct operations, but the full-fledged PowerPC you get with a GameCube has roughly 6 times more; when faced with subtle bugs, it's much easier to deal with C++ code representing what you want to do (like interpreter code) than IRBuilder::Create* calls. I figured that while I can't do much about the first, if I could get LLVM to generate code that would generate code, the two others would be much less cumbersome. So my plan is to write a tool that accepts a specification of how instructions should be interpreted, with handlers written in C++, and turn that into an usable recompiler (that would also use LLVM libraries). The grammar would be a shell for C++ code, and I'd use Clang to turn the actual code into LLBC; then, I would pass through the code (? la llvm2cpp), and create calls to an IRBuilder to generate equivalent code. Once this generated class compiled (through regular means), clients would call the appropriate methods on the object to generate code, and will finally be able to get a Function to use with the JIT. I've joined an example grammar and an example expected output (made on the train, it's not actually working, but it gives a good idea). Branch management (except for the branching itself) would have to be completely managed by the client, but this is a minor hurt compared to what it is right now. As a side-effect of using C++ to make instruction handlers, such a solution could almost be a drop-in replacement for existing interpreters. So this is what I'd like to be able to compile with Clang: snippets of C++, with a few symbols declared beforehand. F?lix Le 2011-02-21 ? 23:35:55, Chris Lattner a ?crit : > > On Feb 21, 2011, at 6:31 PM, F?lix Cloutier wrote: > >> Hello guys, >> >> I'd like to use Clang to parse snippets of (and emit bytecode for) C++ code that come from larger files that don't contain only C++, but looking at the clang interpreter example, either I didn't get it, or it looks like the driver expects only files, and not strings or char buffers. >> >> Is there a simple way to achieve this? Do I have to split my input into small files and pass them to clang, or is there a better way? > > It depends on exactly what you're trying to achieve. LLDB uses clang to parse individual expressions, and does this by hooking into various name lookup routines to dynamically/lazily populate symbol tables from debug info. > > This is all possible, but it's a nontrivial amount of work. > > -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/bebb8b03/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: example.txt Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/bebb8b03/attachment.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/bebb8b03/attachment-0001.html ------------------------------ _______________________________________________ LLVMdev mailing list LLVMdev at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev End of LLVMdev Digest, Vol 80, Issue 37 *************************************** From clattner at apple.com Tue Feb 22 20:46:14 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 22 Feb 2011 18:46:14 -0800 Subject: [LLVMdev] New TargetSpec 'llvmnote' Message-ID: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> Hi All, There is recently a discussion on the LLDB list about how to deal with targets, and our current mismash of llvm::Triple and the various subclasses of TargetSubtarget leave a lot to be desired. GNU target triples are really important as input devices to the compiler (users want to specify them) but they aren't detailed enough for internal clients. Anyway, in short, I think that we should unify the variety of code we have to deal with this stuff into a new TargetSpec class. I don't have any short-term plan to implement this, but I wrote up some of my thoughts here: http://nondot.org/sabre/LLVMNotes/TargetSpec.txt Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. -Chris From reid.kleckner at gmail.com Tue Feb 22 22:24:43 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Tue, 22 Feb 2011 23:24:43 -0500 Subject: [LLVMdev] LLVM ExecutionEngine/JIT trampoline question In-Reply-To: References: Message-ID: This is to support lazy compilation, so that when a new function is invoked it is codegen'd and the trampoline is hotpatched to jump to the new code. This way all the callsites don't have to be updated. Reid On Tue, Feb 22, 2011 at 8:14 PM, Xin Tong Utoronto wrote: > I understand that we need to push the address to a register then branch > using the register. But i am asking why there is a trampoline there such > that a call to foo is first branched to an snippet and the snippet branches > to the X86CompilationCallback. is this snippet necessary ? > > Thanks > > Xin > > > On Tue, Feb 22, 2011 at 12:39 PM, Reid Kleckner > wrote: >> >> The address of the callee may be more than 2 GB away in memory, which >> cannot be encoded as an immediate offset in the call instruction. ?So, >> the value is first materialized with a mov instruction which can >> encode the immediate and then jumped to through a register. >> >> Reid >> >> On Tue, Feb 22, 2011 at 12:03 PM, Xin Tong Utoronto >> wrote: >> > I have a question on the LLVM JIT >> > >> > I did some brief memory reading one day and I found that a call to a >> > non-library function is resolved by the X86CompilationCallback, but the >> > X86CompilationCallback is reached through a trampoline. why can not? the >> > generated code jump to the X86CompilationCallback function directly ? >> > >> > ????????? 0x2b0a6a4d103b: mov??? $0x2b0a6a561010,%rax >> > ????????? 0x2b0a6a4d1045: callq? *%rax >> > // call foo >> >> >> >> >> >> ==> >> >> >> >> 0x2b0a6a561010: mov??? $0xa743a0,%r10?????????????????? // some kind of >> >> trampoline >> >> 0x2b0a6a56101a: callq? *%r10 >> >> >> >> ==> >> >> >> >> 0xa743a0 :??????? push?? %rbp >> >> 0xa743a1 :??? mov??? %rsp,%rbp >> >> 0xa743a4 :??? push?? %rdi >> >> 0xa743a5 :??? push?? %rsi >> > >> > -- >> > Kind Regards >> > >> > Xin Tong >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> > > > > > -- > Kind Regards > > Xin Tong > From baldrick at free.fr Wed Feb 23 02:07:01 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 23 Feb 2011 09:07:01 +0100 Subject: [LLVMdev] obtain the address and size of LLVM generated temporaries In-Reply-To: <4D643251.1080809@eecg.toronto.edu> References: <4D643251.1080809@eecg.toronto.edu> Message-ID: <4D64C025.2060407@free.fr> Hi Chuck, > I wonder what is the right approach to obtain the address and size of > LLVM (compiler) generated temporaries? > > E.g. > > %0 = %x + %y > store i32 i0, i32 %z, align 4 > > How can I get the address of %0 (which could be either a stack or heap > variable)? actually %0 is neither a stack or a heap variable, it is an LLVM "virtual register" and has no address. It has type i32, so storing it writes the same number of bytes as any i32 store, see getTypeStoreSize. Ciao, Duncan. From dg at cowlark.com Wed Feb 23 04:47:41 2011 From: dg at cowlark.com (David Given) Date: Wed, 23 Feb 2011 10:47:41 +0000 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> Message-ID: <4D64E5CD.6020207@cowlark.com> On 02/23/11 02:46, Chris Lattner wrote: [...] > Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. Can I put in a plea to have as much of LLVM as possible *not* require knowledge of a single, specific architecture to work? I have various things I would like to do that work on abstract machines, where I don't have a specific target or CPU in mind, but just want to work at the bitcode level. Right now the only way I know of doing this is to hardcode the datalayout into a new target and rebuild the whole shooting match, LLVM and clang combined. I very much do not want to do this. What would be really nice is to be able to specify a custom datalayout on the command line and have as many tools as possible still work, particularly clang --- trying to generate code with non-standard datalayouts is kinda hard right now. -- ???? ?????????????? ????? http://www.cowlark.com ????? ? "Thou who might be our Father, who perhaps may be in Heaven, hallowed ? be Thy Name, if Name Thou hast and any desire to see it hallowed..." ? --- _Creatures of Light and Darkness_, Roger Zelazny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110223/506f79fc/attachment.bin From Anton.Lokhmotov at arm.com Wed Feb 23 05:47:48 2011 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Wed, 23 Feb 2011 11:47:48 -0000 Subject: [LLVMdev] [PATCH] OpenCL support - update on keywords In-Reply-To: References: <20101216223130.GA1885@pcc.me.uk> <000001cba1f0$873bfe70$95b3fb50$@Lokhmotov@arm.com> <20110104214222.GA22362@pcc.me.uk> <000001cbcf80$512b0b10$f3812130$@Lokhmotov@arm.com> <000001cbd1ac$0cb74ab0$2625e010$@Lokhmotov@arm.com> Message-ID: <000001cbd34f$7ecbe580$7c63b080$@Lokhmotov@arm.com> Hi Micah, > The problem is that we use the ordering private, global, constant and > local, and this is the same ordering that is used on Apple as well. As > we already have OpenCL binaries out in public, making the change is > problematic as we want to keep backward compatibility at all costs. When you say 'binaries', I assume you mean 'LLVM bitcode'? (The ordering of enums in intermediate code wouldn't matter if the binaries were native x86 code.) I believe the OpenCL specification provides no guarantees whatsoever regarding compatibility of binaries: neither between binaries from different vendors, nor between binaries from the same vendor. So IMO users who try to avoid runtime compilation and port binaries between different versions of AMD SDK actually ask for trouble. (This doesn't mean I don't appreciate your concern, however.) > We have discussed this internally a little bit. What about encoding > the address space definition into the data layout string? That way > various vendors can be compatible with each other. This encoding would clearly not be enough for full binary compatibility, and it would quite solve the problem with binaries that are already out in public. (Of course, you can assume that if a binary doesn't include the address space related string, it's an old one using the private-global-constant-local ordering.) I think that instead of allowing this customisation (which will allow an unbounded number of mappings of the address spaces to integers) we should declare the most sensible order "standard" or "canonical", and allow the backends to query the binary to see if it is in the standard form. Does it make sense? Thus, we are getting back to the problem of defining the standard form of representing OpenCL C programs in LLVM-IR. Soon I'll start sending proposals for representing different features and solicit feedback from the list. Best regards, Anton. From deeppatel1987 at gmail.com Wed Feb 23 11:59:39 2011 From: deeppatel1987 at gmail.com (Sandeep Patel) Date: Wed, 23 Feb 2011 17:59:39 +0000 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> Message-ID: On Wed, Feb 23, 2011 at 2:46 AM, Chris Lattner wrote: > > There is recently a discussion on the LLDB list about how to deal with targets, and our current mismash of llvm::Triple and the various subclasses of TargetSubtarget leave a lot to be desired. ?GNU target triples are really important as input devices to the compiler (users want to specify them) but they aren't detailed enough for internal clients. > > Anyway, in short, I think that we should unify the variety of code we have to deal with this stuff into a new TargetSpec class. ? I don't have any short-term plan to implement this, but I wrote up some of my thoughts here: > http://nondot.org/sabre/LLVMNotes/TargetSpec.txt > > Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. Bitcode currently does not carry enough options information to handle LTO. For example, if you use -O1 for a particular translation unit but -O4 for the rest of them, that information isn't saved and provided to LTO when the actual optimization is happening. Similarly, some options like soft-float/hard-float aren't preserved. We should consider these issues while solving this. deep From Anton.Lokhmotov at arm.com Wed Feb 23 12:01:57 2011 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Wed, 23 Feb 2011 18:01:57 -0000 Subject: [LLVMdev] [PATCH] OpenCL half support Message-ID: <000201cbd383$c35adec0$4a109c40$@Lokhmotov@arm.com> Please find attached Clang/LLVM patches for supporting 'half' - the half-precision floating-point type, which in particular is used in OpenCL C. Please review. Background and motivation. Whilst the half type is defined by IEEE 754-2008 as storage only (i.e. no arithmetic is supposed to be performed on values of this type), it's growing in importance in embedded systems. The cl_khr_fp16 extension of OpenCL lifts restrictions for declaring half variables and arrays, dereferencing half pointers, performing arithmetic and conversions, etc. The latest version of the C++ ABI supports half as well. Therefore, we believe half should become a fundamental type in LLVM. (After all, LLVM already supports x86_fp80, fp128 and ppc_fp128.) Anton. -------------- next part -------------- A non-text attachment was scrubbed... Name: 00003-half-llvm.patch Type: application/octet-stream Size: 12006 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110223/d954665d/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 00003-half-clang.patch Type: application/octet-stream Size: 23694 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110223/d954665d/attachment-0001.obj From greened at obbligato.org Wed Feb 23 13:12:11 2011 From: greened at obbligato.org (David A. Greene) Date: Wed, 23 Feb 2011 13:12:11 -0600 Subject: [LLVMdev] Structure Types and ABI sizes In-Reply-To: <4D643B0B.1090809@arcor.de> (Jochen Wilhelmy's message of "Tue, 22 Feb 2011 23:39:07 +0100") References: <4D5E4F64.6080300@arcor.de> <4D643B0B.1090809@arcor.de> Message-ID: Jochen Wilhelmy writes: >> Yes, the padding is required. I believe %J = type { %I, i16, i8 } would >> work just as well as long as %I = type { i32, i8 } as in your example. > Yes but given the ABI requires the last member to be at offset 5, > which may happen > (i.e. no tail padding if I is derived from), then your solution No, this is not true for this example. This is getting into extremely delicate areas of the Itanium C++ ABI. In this example, %I is a "POD for the purposes of layout" type. Such types cannot have their tail padding overlapped when they are inherited from. So %I is eight bytes in all contexts. If %I is not a "POD for the purposes of layout" type, that it's tail padding MUST be overlapped when inherited from. In this case, we end up creating two types for %I, %I and %I' and use %I' as the type when it is inherited from. Fun, eh? :-/ -Dave From greened at obbligato.org Wed Feb 23 13:17:38 2011 From: greened at obbligato.org (David A. Greene) Date: Wed, 23 Feb 2011 13:17:38 -0600 Subject: [LLVMdev] repo.or.cz GIT mirrors In-Reply-To: (Anton Korobeynikov's message of "Tue, 22 Feb 2011 23:27:01 +0300") References: Message-ID: Anton Korobeynikov writes: > Hello Everyone > > As you might already know, git mirrors of llvm repository started from > repo.or.cz mirrors, where stuff was pushed almost by hands out of > git-svn local copy. Right now we have official and automatically > updated GIT mirrors on llvm.org and thus repo.or.cz mirrors look a bit > redundant. However, they might still be useful, but definitely not > within the current "push mode". It is possible to convert them to > plain GIT mirrors of llvm.org GIT mirrors with automatic pulling, but > this, in fact, will require us to delete repo.or.cz repos and recreate > them from scratch. Do git repositories cloned from git-svn mirrors work properly? For example: svn ^ | | V git-svn / \ / \ git clone A git clone B I don't think one can share commits from clone A to/from clone B without going through the parent git-svn repository. Is that right? I recall having read something about that somewhere. If this is a problem, it might be counterproductive to provide a repo.or.cz mirror at all, because people will think it's a "proper" git repository when it really isn't. BTW, the llvm.org git-svn mirror is for trunk only, right? How difficult would it be to include the latest release tag in the git-svn mirror (RELEASE_28 right now)? This would greatly help people that work with the latest release of llvm rather than trunk. -Dave From clattner at apple.com Wed Feb 23 13:26:07 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 23 Feb 2011 11:26:07 -0800 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: <4D64E5CD.6020207@cowlark.com> References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> <4D64E5CD.6020207@cowlark.com> Message-ID: On Feb 23, 2011, at 2:47 AM, David Given wrote: > On 02/23/11 02:46, Chris Lattner wrote: > [...] >> Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. > > Can I put in a plea to have as much of LLVM as possible *not* require > knowledge of a single, specific architecture to work? > > I have various things I would like to do that work on abstract machines, > where I don't have a specific target or CPU in mind, but just want to > work at the bitcode level. Right now the only way I know of doing this > is to hardcode the datalayout into a new target and rebuild the whole > shooting match, LLVM and clang combined. I very much do not want to do this. This request is completely orthogonal to the proposal. If you generate target independent LLVM IR, you don't have to put a triple into the IR. This isn't going to change. -Chris From peter at pcc.me.uk Wed Feb 23 13:26:11 2011 From: peter at pcc.me.uk (Peter Collingbourne) Date: Wed, 23 Feb 2011 19:26:11 +0000 Subject: [LLVMdev] [PATCH] OpenCL support - update on keywords In-Reply-To: <000001cbcf80$512b0b10$f3812130$@Lokhmotov@arm.com> References: <20101216223130.GA1885@pcc.me.uk> <20110104214222.GA22362@pcc.me.uk> <000001cbcf80$512b0b10$f3812130$@Lokhmotov@arm.com> Message-ID: <20110223192611.GA30802@pcc.me.uk> On Fri, Feb 18, 2011 at 03:27:13PM -0000, Anton Lokhmotov wrote: > > -----Original Message----- > > From: Peter Collingbourne [mailto:peter at pcc.me.uk] > > Sent: 04 January 2011 21:42 > > To: Anton Lokhmotov > > Cc: cfe-dev at cs.uiuc.edu > > Subject: Re: OpenCL support > > > > Here are my comments on the second patch. > > > > > +enum OpenCLAddressSpace { > > > + OPENCL_PRIVATE = 0, > > > + OPENCL_GLOBAL = 1, > > > + OPENCL_LOCAL = 2, > > > + OPENCL_CONSTANT = 3 > > > +}; > > > > If we are going to standardise these address space numbers across > > Clang and the LLVM backends, this enum declaration should be added > > somewhere in LLVM so that the backends have access to it. Perhaps a > > new header file called something like "llvm/Support/AddressSpaces.h"? > We went for llvm/Support/OpenCL.h for now, because might need to add further > OpenCL-specific support. Copying to llvmdev. I don't think we should include the word OpenCL in the name of this enum/header. We may very well in the future want to define address space constants for other languages, which should not overlap with the OpenCL constants, by extending this enum. IMHO we shouldn't pollute the llvm namespace with this enum either. In a similar style to the llvm/CallingConv.h header, we could consider creating another namespace and placing the enum inside (llvm::AddrSpace::ID perhaps?) A few additional comments: "private" should not be marked as a type qualifier, type specifier qualifier or declaration specifier in languages other than OpenCL. Otherwise we will end up accepting invalid C++ declarations such as: private int i; or even int private i; There are several 80-col violations in lib/Parse/ParseDecl.cpp and in the CreateIntegerAttribute function. git also picked up some trailing whitespace errors. To avoid the code duplication between ParseDeclarationSpecifiers, ParseOptionalTypeSpecifier and ParseTypeQualifierListOpt you should introduce a ParseOpenCLTypeAttributes function (e.g. see ParseBorlandTypeAttributes). Other than that, LGTM. Thanks, -- Peter From czhao at eecg.toronto.edu Wed Feb 23 14:54:34 2011 From: czhao at eecg.toronto.edu (Chuck Zhao) Date: Wed, 23 Feb 2011 15:54:34 -0500 Subject: [LLVMdev] obtain the address and size of LLVM generated temporaries In-Reply-To: <4D6438B9.9050405@rawbw.com> References: <4D643251.1080809@eecg.toronto.edu> <4D6438B9.9050405@rawbw.com> Message-ID: <4D65740A.7040804@eecg.toronto.edu> Yuri, Duncan, Thank you for the replies. I tried to do a GEP() on %0. The execution asserted, saying some type mismatching. I agree with Duncan, Compiler generated temporaries (%0) are neither local or global variables, they are actually virtual registers who don't have address, no types, while the size is determined by the operands of the instruction (E.g., add i32 has a result size of i32, while add i16 has a result size of i16). // Original C code: void foo(int x, int y){ volatile int z; z = x + y; printf("val : %d\n", z); } and its generated LLVM IR: // LLVM IR Code generated from the C code: define void @foo(i32 %x, i32 %y) nounwind noinline { entry: %z = alloca i32, align 4 %0 = add nsw i32 %y, %x volatile store i32 %0, i32* %z, align 4 %1 = volatile load i32* %z, align 4 %2 = call i32 (i8*, ...)* @printf(i8* noalias getelementptr inbounds ([10 x i8]* @.str, i32 0, i32 0), i32 %1) nounwind ret void } By piping it to the C Backend, I get // C Code generated via the C Backend: void foo(unsigned int llvm_cbe_x, unsigned int llvm_cbe_y) { unsigned int llvm_cbe_z; /* Address-exposed local */ unsigned int llvm_cbe_tmp__1; unsigned int llvm_cbe_tmp__2; *((unsigned int volatile*)(&llvm_cbe_z)) = (((unsigned int )(((unsigned int )llvm_cbe_y) + ((unsigned int )llvm_cbe_x)))); llvm_cbe_tmp__1 = *((unsigned int volatile*)(&llvm_cbe_z)); llvm_cbe_tmp__2 = printf(((&_OC_str.array[((signed int )0u)])), llvm_cbe_tmp__1); return; } Motivated by the C Backend, I think what I can do is to generate a local (stack) variable and store the %0 into it. E.g.: %0 = add nsw i32 %y, %x %tmp_1 = alloca i32, align 4 store i32 %0, *i32 %tmp_1 ... Now, %tmp_1 is a local variable that holds the value of %0, has a known good size and can have its address taken. Does this make sense? Thank you Chuck On 2/22/2011 5:29 PM, Yuri wrote: > On 02/22/2011 14:01, Chuck Zhao wrote: >> I wonder what is the right approach to obtain the address and size of >> LLVM (compiler) generated temporaries? >> >> E.g. >> >> %0 = %x + %y >> store i32 i0, i32 %z, align 4 >> >> How can I get the address of %0 (which could be either a stack or heap >> variable)? > > This is not possible since such value can also be in register. > > Yuri -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110223/e89f60e6/attachment.html From dg at cowlark.com Wed Feb 23 15:24:38 2011 From: dg at cowlark.com (David Given) Date: Wed, 23 Feb 2011 21:24:38 +0000 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> <4D64E5CD.6020207@cowlark.com> Message-ID: <4D657B16.8070503@cowlark.com> On 23/02/11 19:26, Chris Lattner wrote: [...] > This request is completely orthogonal to the proposal. If you generate target independent LLVM IR, you don't have to put a triple into the IR. This isn't going to change. Unfortunately clang doesn't appear to be aware of this. It's forcing me to specify a triple (or at least, I haven't discovered a way of generating target-independent IR with it yet). If I want to, say, generate code where ints are 64 bits but have a 32 bit alignment, as far as I know I have to go create a custom target and rebuild everything. If this is purely a clang issue which doesn't extend to the rest of LLVM that's fine and I'll bring it up with them, but nevertheless I feel that hardcoding this kind of information into the target is a bit restrictive. For example: the proposal mentions storing information as enums. This means that if I want a target with a feature that TargetSpec doesn't know about, my choices are to either pick 'unknown' or else add it to the enum table and then rebuild everything. Given that the actual values of the enums are arbitrary and hidden, they should just be an implementation detail. An alternative implementation would be to keep a map of feature tokens and dynamically assign new values as necessary. This means that it would be possible for TargetSpec to parse "fnord.le.linux.elf.with-baz" even though TargetSpec knows nothing about the 'fnord' architecture. This would then allow custom passes which *do* know what a fnord is to be able to reason about the feature information. -- ???? ?????????????? ????? http://www.cowlark.com ????? ? ? "I have a mind like a steel trap. It's rusty and full of dead mice." ? --- Anonymous, on rasfc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110223/9fce314a/attachment.bin From housel at acm.org Wed Feb 23 15:32:35 2011 From: housel at acm.org (Peter Housel) Date: Wed, 23 Feb 2011 13:32:35 -0800 Subject: [LLVMdev] DWARF DW_AT_language in LLVM Message-ID: <1298496755.4053.22.camel@eng-phousel-ubuntu> Is there any good reason for using DW_FORM_data1 for the DW_AT_language attribute of DW_TAG_compile_unit? This prevents using language codes in the DW_LANG_lo_user=0x8000 to DW_LANG_hi_user=0xffff range. I think the obvious change to use DW_FORM_data2 in line 1897 of lib/CodeGen/AsmPrinter/DwarfDebug.cpp should fix it. Or, if there are binary compatibility issues, the abbrev form could be chosen conditionally. Are there? Thanks -Peter S. Housel- housel at acm.org From gohman at apple.com Wed Feb 23 15:43:35 2011 From: gohman at apple.com (Dan Gohman) Date: Wed, 23 Feb 2011 13:43:35 -0800 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> Message-ID: On Feb 22, 2011, at 6:46 PM, Chris Lattner wrote: > This leads to a number of problems in LLVM: > - we have a bunch of duplication > - we have confusion about what a triple is (normalized or not) > - no good way to tell if a triple is normalized > - no good, centralized way to reason about which triples are allowed and valid > - the MC assembler has to link in the entire X86 backend to get subtarget info > - we don't have a good way to implement things like .code32 in the MC assembler > - LLDB replicates a lot of this code and heuristics > - we don't have good interfaces to inquire about the host > - we do std::string manipulation in llvm::Triple > - linux triples are actually quadruples! > - darwin tools that take -arch have to map them onto something internally. Most of these are motivations for refactoring and code cleanup, but not really for inventing a new target mini-language to replace triples. The main problems with triples IMHO which motivate this are: - The vendor field is vague and non-orthoganal. - Triples don't represent subtarget attributes, except in the way that subtarget attributes are sometimes mangled into the architecture field in confusing ways. At an initial read, the targetspec proposal's solutions to these problems seem reasonable. It's a little surprising to have a dedicated "Byte Order" field. One possible reason for it is that mips.le.* is marginally nicer than mipsel.*, however that's not obviously worth burdening everyone else for. Another possible reason is to allow otherwise architecture-independent strings to encode an endianness. However, that's not a concept that LLVM currently has. And without more targetdata parts, it's not obvious how useful it is by itself. On the other hand, if "Byte Order" makes sense to include, should other parts of targetdata be included? Pointer size seems the next most desirable -- endianness and pointer size would be sufficient for many elf tools, for example. However, the other parts of targetdata could conceivably be useful too. The "OS" field seems like it should be renamed to "ABI", since in the description you discuss actual OS's that support multiple ABIs. In the "Feature Delta" field, using "+" to add features but using a charactar other than "-" to remove them is unfortunate. How about just prohibiting "-" in CPU names? Or for another idea, how about prefixing negative features with "no-", as in "core2+sse41+no-cmov"? Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110223/b045a55e/attachment.html From dag at cray.com Wed Feb 23 15:49:38 2011 From: dag at cray.com (David Greene) Date: Wed, 23 Feb 2011 15:49:38 -0600 Subject: [LLVMdev] CodeGenOpt Message-ID: The existing CodeGenOpt is not flexible enough for our needs. Our customers want to be able to control the optimization level at a fine grain, so we provide them separate dials for general optimization, fp optimization and memory hierarchy optimization. I would like to replace the existing CodeGenOpt::Level enum with a more general CodeGenOpt class that can track different sets of optimization level. Initially it would look something like this: class CodeGenOpt { ... public getOptLevel() ...; getFPLevel() ...; getMemLevel() ...; }; Does this sound reasonable? -Dave From blunted2night at gmail.com Wed Feb 23 16:11:24 2011 From: blunted2night at gmail.com (Nathan Jeffords) Date: Wed, 23 Feb 2011 14:11:24 -0800 Subject: [LLVMdev] DWARF DW_AT_language in LLVM In-Reply-To: <1298496755.4053.22.camel@eng-phousel-ubuntu> References: <1298496755.4053.22.camel@eng-phousel-ubuntu> Message-ID: On Wed, Feb 23, 2011 at 1:32 PM, Peter Housel wrote: > Is there any good reason for using DW_FORM_data1 for the DW_AT_language > attribute of DW_TAG_compile_unit? This prevents using language codes in > the DW_LANG_lo_user=0x8000 to DW_LANG_hi_user=0xffff range. > > I think the obvious change to use DW_FORM_data2 in line 1897 of > lib/CodeGen/AsmPrinter/DwarfDebug.cpp should fix it. Or, if there are > binary compatibility issues, the abbrev form could be chosen > conditionally. Are there? > this bit be when I tried to use a language ID in the user range > > Thanks > -Peter S. Housel- housel at acm.org > > > _______________________________________________ > 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/20110223/70ff5014/attachment.html From geek4civic at gmail.com Wed Feb 23 16:26:46 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Thu, 24 Feb 2011 07:26:46 +0900 Subject: [LLVMdev] [cfe-dev] repo.or.cz GIT mirrors In-Reply-To: References: Message-ID: Good morning, Dave. On Thu, Feb 24, 2011 at 4:17 AM, David A. Greene wrote: > Do git repositories cloned from git-svn mirrors work properly? ?For > example: > > ? ? ? ? ? ? ? ? ? ? ? ? svn > ? ? ? ? ? ? ? ? ? ? ? ? ?^ > ? ? ? ? ? ? ? ? ? ? ? ? ?| > ? ? ? ? ? ? ? ? ? ? ? ? ?| > ? ? ? ? ? ? ? ? ? ? ? ? ?V > ? ? ? ? ? ? ? ? ? ? ? git-svn > ? ? ? ? ? ? ? ? ? ? ? / ? ? \ > ? ? ? ? ? ? ? ? ? ? ?/ ? ? ? \ > ? ? ? ? ? ? ? ?git clone A ?git clone B > > I don't think one can share commits from clone A to/from clone B without > going through the parent git-svn repository. ?Is that right? ?I recall > having read something about that somewhere. Maybe sure on git-svn's branch (eg. master). "master" should never be pushed to "git-svn", but "git pull --rebase" should be done. Each clonee should do "git-svn dcommit" individually. (and it would be happier if you did "git pull --rebase llvm.org) Of course, other branches may be push/pull-ed among repos. It is git! > If this is a problem, it might be counterproductive to provide a > repo.or.cz mirror at all, because people will think it's a "proper" git > repository when it really isn't. Which do you mention to, "Anton's repo" or "(coming) cloned repo from llvm.org"? With latter, I don't think there might be any matters. (as far as a person would never do "git push -f repo.or.cz master") > BTW, the llvm.org git-svn mirror is for trunk only, right? ?How > difficult would it be to include the latest release tag in the git-svn > mirror (RELEASE_28 right now)? ?This would greatly help people that work > with the latest release of llvm rather than trunk. +1. Anton, please provide *official* release branches. ;) ...Takumi From anton at korobeynikov.info Wed Feb 23 16:40:03 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 24 Feb 2011 01:40:03 +0300 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: <4D657B16.8070503@cowlark.com> References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> <4D64E5CD.6020207@cowlark.com> <4D657B16.8070503@cowlark.com> Message-ID: > Unfortunately clang doesn't appear to be aware of this. It's forcing me > to specify a triple (or at least, I haven't discovered a way of > generating target-independent IR with it yet). If I want to, say, > generate code where ints are 64 bits but have a 32 bit alignment, as far > as I know I have to go create a custom target and rebuild everything. You cannot generate platform-independent IR out of C. See http://llvm.org/docs/FAQ.html#platformindependent for more info -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From dpatel at apple.com Wed Feb 23 16:42:13 2011 From: dpatel at apple.com (Devang Patel) Date: Wed, 23 Feb 2011 14:42:13 -0800 Subject: [LLVMdev] DWARF DW_AT_language in LLVM In-Reply-To: <1298496755.4053.22.camel@eng-phousel-ubuntu> References: <1298496755.4053.22.camel@eng-phousel-ubuntu> Message-ID: <6CA6DAFF-F4B4-4201-8CF8-9348B2929EE9@apple.com> Peter, On Feb 23, 2011, at 1:32 PM, Peter Housel wrote: > Is there any good reason for using DW_FORM_data1 for the DW_AT_language > attribute of DW_TAG_compile_unit? This prevents using language codes in > the DW_LANG_lo_user=0x8000 to DW_LANG_hi_user=0xffff range. > > I think the obvious change to use DW_FORM_data2 in line 1897 of > lib/CodeGen/AsmPrinter/DwarfDebug.cpp should fix it. Or, if there are > binary compatibility issues, the abbrev form could be chosen > conditionally. Are there? I do not see any binary compatibility issue. In any case, if there are any I'd learn them about soon! Checked in change to use DW_FORM_data2. r126339. I am curious, what is your source language ? - Devang From housel at acm.org Wed Feb 23 16:53:59 2011 From: housel at acm.org (Peter Housel) Date: Wed, 23 Feb 2011 14:53:59 -0800 Subject: [LLVMdev] DWARF DW_AT_language in LLVM In-Reply-To: <6CA6DAFF-F4B4-4201-8CF8-9348B2929EE9@apple.com> References: <1298496755.4053.22.camel@eng-phousel-ubuntu> <6CA6DAFF-F4B4-4201-8CF8-9348B2929EE9@apple.com> Message-ID: <1298501639.4053.29.camel@eng-phousel-ubuntu> On Wed, 2011-02-23 at 14:42 -0800, Devang Patel wrote: > > I think the obvious change to use DW_FORM_data2 in line 1897 of > > lib/CodeGen/AsmPrinter/DwarfDebug.cpp should fix it. Or, if there are > > binary compatibility issues, the abbrev form could be chosen > > conditionally. Are there? > > I do not see any binary compatibility issue. In any case, if there are > any I'd learn them about soon! Checked in change to use DW_FORM_data2. r126339. Thanks! > I am curious, what is your source language ? Dylan, generated using the Open Dylan compiler. -Peter- From wilsons at start.ca Wed Feb 23 17:24:19 2011 From: wilsons at start.ca (Stephen Wilson) Date: Wed, 23 Feb 2011 18:24:19 -0500 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> Message-ID: <20110223232419.GA18131@fibrous.localdomain> On Wed, Feb 23, 2011 at 01:43:35PM -0800, Dan Gohman wrote: > On Feb 22, 2011, at 6:46 PM, Chris Lattner wrote: > > This leads to a number of problems in LLVM: > > - we have a bunch of duplication > > - we have confusion about what a triple is (normalized or not) > > - no good way to tell if a triple is normalized > > - no good, centralized way to reason about which triples are allowed and valid > > - the MC assembler has to link in the entire X86 backend to get subtarget info > > - we don't have a good way to implement things like .code32 in the MC assembler > > - LLDB replicates a lot of this code and heuristics > > - we don't have good interfaces to inquire about the host > > - we do std::string manipulation in llvm::Triple > > - linux triples are actually quadruples! > > - darwin tools that take -arch have to map them onto something internally. > > Most of these are motivations for refactoring and code cleanup, but not > really for inventing a new target mini-language to replace triples. > > The main problems with triples IMHO which motivate this are: > > - The vendor field is vague and non-orthoganal. > - Triples don't represent subtarget attributes, except in the way that > subtarget attributes are sometimes mangled into the architecture field > in confusing ways. > > At an initial read, the targetspec proposal's solutions to these > problems seem reasonable. > > It's a little surprising to have a dedicated "Byte Order" field. One > possible reason for it is that mips.le.* is marginally nicer than > mipsel.*, however that's not obviously worth burdening everyone else > for. Another possible reason is to allow otherwise > architecture-independent strings to encode an endianness. However, > that's not a concept that LLVM currently has. And without more > targetdata parts, it's not obvious how useful it is by itself. In LLDB we currently have an "ArchSpec" class that llvm::TargetSpec could eventually replace. Currently, one of the main applications for having a "byte order" bit in LLDB is to allow sensible construction of default specifications: for example ARM is almost always little endian, but there are board configurations where this is not the case. I think with sensible default values most people will not find the extra flag a burden. Having a byte order bit just helps model bi-endian architectures that much more accurately IMHO. For example, it would help when implementing support for debugging boot code that forces the processor to switch modes (PowerPC for example). > On the other hand, if "Byte Order" makes sense to include, should > other parts of targetdata be included? Pointer size seems the next > most desirable -- endianness and pointer size would be sufficient for > many elf tools, for example. However, the other parts of > targetdata could conceivably be useful too. Possibly useful again from an LLDB perspective. I could imagine debugging x86_64 operating system code and needing a way to communicate transitions from 64-bit mode and 32-bit compatibility mode seamlessly. However, I must stress this is *possibly* useful -- I do not have a firm conclusion to offer here. Perhaps this is something that we could support on an as needed basis. > The "OS" field seems like it should be renamed to "ABI", since in the > description you discuss actual OS's that support multiple ABIs. > > In the "Feature Delta" field, using "+" to add features but using > a charactar other than "-" to remove them is unfortunate. How about > just prohibiting "-" in CPU names? Or for another idea, how about > prefixing negative features with "no-", as in "core2+sse41+no-cmov"? > > Dan > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- steve From arushi987 at gmail.com Wed Feb 23 17:58:50 2011 From: arushi987 at gmail.com (Arushi Aggarwal) Date: Wed, 23 Feb 2011 17:58:50 -0600 Subject: [LLVMdev] Clone a function and change signature In-Reply-To: References: <4D6412A5.1030300@illinois.edu> Message-ID: Thanks a lot. That worked. Arushi On Tue, Feb 22, 2011 at 2:43 PM, Chris Lattner wrote: > > On Feb 22, 2011, at 11:46 AM, John Criswell wrote: > > > On 2/22/11 1:31 PM, Arushi Aggarwal wrote: > >> Hi, > >> > >> I want to clone a given function, and add an argument to it. I then > >> want to add a call to that new function. I have a callInstruction CI, > >> which I want to transform to call this new function, and to take a new > >> argument. > > > > If I understand correctly, you're cloning the function first and then > > adding a new argument to the clone. Do I understand correctly? > > > > If so, I don't believe you can do that. IIRC, you have to first create > > a new, empty function with the additional argument and then use > > CloneFunctionInto() to clone the body of the original function into the > > new function. I believe that's what poolalloc does and what I did the > > last time I had to add function arguments to a function. > > Right, you can also take a look at the dead argument elimination or > argument promotion passes for examples. > > -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110223/ed9b5f69/attachment.html From echristo at apple.com Wed Feb 23 18:08:45 2011 From: echristo at apple.com (Eric Christopher) Date: Wed, 23 Feb 2011 16:08:45 -0800 Subject: [LLVMdev] llvm-gcc4.2 bootstrap broken? In-Reply-To: <20110222175809.GA25373@bromo.med.uc.edu> References: <20110219192554.GA5200@bromo.med.uc.edu> <643ED677-87D5-41ED-8355-852CB4C7E862@apple.com> <20110222175809.GA25373@bromo.med.uc.edu> Message-ID: On Feb 22, 2011, at 9:58 AM, Jack Howarth wrote: > The llvm-gcc42 bootstrap is fixed in current svn. FYI, the current polyhedron 2005 results are below. > Compared to the previous results on 18 Sep 2010 for llvm 2.8, the regressions in ac are retained and > aermod is now also regressed 13% as well as fatigue by 12%. Urgh. Thanks for the mail. There's not a lot I can do about this right now, but if you file bugs with testcases we can run and play with then that'd help and we might be able get things done as we can. Thanks! -eric From clattner at apple.com Wed Feb 23 19:28:42 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 23 Feb 2011 17:28:42 -0800 Subject: [LLVMdev] CodeGenOpt In-Reply-To: References: Message-ID: <6D33C7DD-9DB2-4555-8449-D34027EA5EB2@apple.com> On Feb 23, 2011, at 1:49 PM, David Greene wrote: > The existing CodeGenOpt is not flexible enough for our needs. Our > customers want to be able to control the optimization level at a fine > grain, so we provide them separate dials for general optimization, fp > optimization and memory hierarchy optimization. > > I would like to replace the existing CodeGenOpt::Level enum with a more > general CodeGenOpt class that can track different sets of optimization > level. Initially it would look something like this: > > class CodeGenOpt { > ... > public > getOptLevel() ...; > getFPLevel() ...; > getMemLevel() ...; > }; > > Does this sound reasonable? I don't think that this is the right way to go. Higher level decisions like that should affect your choice of passes to schedule. -Chris From dineth2007 at gmail.com Wed Feb 23 22:36:38 2011 From: dineth2007 at gmail.com (Dineth) Date: Wed, 23 Feb 2011 23:36:38 -0500 Subject: [LLVMdev] defined in discarded section `.gnu.linkonce.t... Message-ID: I'm using LLVM to compile one of the MYSQL libraries and then generate assembly using llc and compile that with gcc to create the lib and link with the rest of the system. I'm able to compile llc output with gcc without any problem. However, when I try to link the server with the library compiled with LLVM I get the following error during linking: `.gnu.linkonce.t._ZN6BitmapILj39EEoREj' referenced in section `.data.rel.ro' of ../storage/falcon/libXXX.1.o: defined in discarded section `.gnu.linkonce.t._ZN6BitmapILj39EEoREj' of ../storage/falcon/libXXX.1.o I use LLVM 2.8, GCC 4.5.2, Binutils 2.21.51.20110223. Any help on how to get around this problem is much appreciated. Thank you. -- dineth From clattner at apple.com Thu Feb 24 00:29:51 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 23 Feb 2011 22:29:51 -0800 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> Message-ID: On Feb 23, 2011, at 9:59 AM, Sandeep Patel wrote: >> Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. > > Bitcode currently does not carry enough options information to handle > LTO. For example, if you use -O1 for a particular translation unit but > -O4 for the rest of them, that information isn't saved and provided to > LTO when the actual optimization is happening. Similarly, some options > like soft-float/hard-float aren't preserved. We should consider these > issues while solving this. That's true, but the same is also true for a huge variety of other codegen-level flags. I don't think we want to encode every possible detail at this level. Specific things can be solved in different ways: for example, -ffast-math is best solved by adding a flag onto individual fp ops. Some things (like mixed versions of -mpreferred-stack-boundary) are worth just punting on, IMO. In any case, I'm not interested in trying to tackle the long tail of weird codegen options + LTO at this point. -Chris From clattner at apple.com Thu Feb 24 00:36:44 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 23 Feb 2011 22:36:44 -0800 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> Message-ID: <0CC5EE69-4F32-4B38-B544-019D7A0E9036@apple.com> On Feb 23, 2011, at 1:43 PM, Dan Gohman wrote: > Most of these are motivations for refactoring and code cleanup, but not > really for inventing a new target mini-language to replace triples. That's all I'm proposing. I'm not suggesting that the "mini language" be exposed to users, it's just a "serialized for an internal-to-llvm clients" data structure. The string form would be persisted in .ll and .bc files, that's all. > It's a little surprising to have a dedicated "Byte Order" field. One > possible reason for it is that mips.le.* is marginally nicer than > mipsel.*, however that's not obviously worth burdening everyone else > for. Another possible reason is to allow otherwise > architecture-independent strings to encode an endianness. However, > that's not a concept that LLVM currently has. And without more > targetdata parts, it's not obvious how useful it is by itself. It is useful for doing simple queries about the target, and these are things that can be derived from .o files. > On the other hand, if "Byte Order" makes sense to include, should > other parts of targetdata be included? Pointer size seems the next > most desirable -- endianness and pointer size would be sufficient for > many elf tools, for example. However, the other parts of > targetdata could conceivably be useful too. I could be convinced about this. The other approach would be to formalize this as part of the arch spec and treat mips and mips-le as two different arches, and have a predicate that generates the bit on demand. > The "OS" field seems like it should be renamed to "ABI", since in the > description you discuss actual OS's that support multiple ABIs. It's really a cross product of OS's and ABIs. For example, darwin10 vs darwin9 is not an ABI, it is an OS. I consider linux-eabi to be different than linux-someotherabi because the entire OS has to be build that way. *shrug* > In the "Feature Delta" field, using "+" to add features but using > a charactar other than "-" to remove them is unfortunate. How about > just prohibiting "-" in CPU names? Or for another idea, how about > prefixing negative features with "no-", as in "core2+sse41+no-cmov"? Good idea! I changed it to use commas and "no", giving "core2,sse41,nocmov". -Chris From clattner at apple.com Thu Feb 24 00:40:04 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 23 Feb 2011 22:40:04 -0800 Subject: [LLVMdev] New TargetSpec 'llvmnote' In-Reply-To: <20110223232419.GA18131@fibrous.localdomain> References: <261DB389-7711-48EE-B4B8-51655A212C55@apple.com> <20110223232419.GA18131@fibrous.localdomain> Message-ID: <13AFD37E-9AE9-4EC2-A581-891330A00319@apple.com> On Feb 23, 2011, at 3:24 PM, Stephen Wilson wrote: >> >> On the other hand, if "Byte Order" makes sense to include, should >> other parts of targetdata be included? Pointer size seems the next >> most desirable -- endianness and pointer size would be sufficient for >> many elf tools, for example. However, the other parts of >> targetdata could conceivably be useful too. > > Possibly useful again from an LLDB perspective. I could imagine > debugging x86_64 operating system code and needing a way to communicate > transitions from 64-bit mode and 32-bit compatibility mode seamlessly. > However, I must stress this is *possibly* useful -- I do not have a firm > conclusion to offer here. Perhaps this is something that we could > support on an as needed basis. I think that this can be reliably determined from the arch (through a predicate). x86-64 will always be 64-bit, x86 will always be 32-bit. Doing a "32-bit ABI in 64-bit mode" needs to be a new arch anyway, so that sort of thing isn't an issue IMO. To Dan's point, this argues for forcing a 1-1 mapping between arch and endianness, which would allow making endianness be a predicate instead of being an encoded part of the data structure. The *only* downside I see to that is that we couldn't form a TargetSpec that *just* contains an endianness, at least without introducing a "unknown-64bit" and "unknown-32bit" archspec, which seems silly. -Chris From clattner at apple.com Thu Feb 24 00:41:05 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 23 Feb 2011 22:41:05 -0800 Subject: [LLVMdev] [PATCH] OpenCL half support In-Reply-To: <000201cbd383$c35adec0$4a109c40$%Lokhmotov@arm.com> References: <000201cbd383$c35adec0$4a109c40$%Lokhmotov@arm.com> Message-ID: <8AF16F0D-A73A-455B-9141-C30C234299D8@apple.com> On Feb 23, 2011, at 10:01 AM, Anton Lokhmotov wrote: > Please find attached Clang/LLVM patches for supporting 'half' - the > half-precision floating-point type, which in particular is used in OpenCL C. > Please review. > > Background and motivation. Whilst the half type is defined by IEEE 754-2008 > as storage only (i.e. no arithmetic is supposed to be performed on values of > this type), it's growing in importance in embedded systems. The cl_khr_fp16 > extension of OpenCL lifts restrictions for declaring half variables and > arrays, dereferencing half pointers, performing arithmetic and conversions, > etc. The latest version of the C++ ABI supports half as well. Therefore, > we believe half should become a fundamental type in LLVM. (After all, LLVM > already supports x86_fp80, fp128 and ppc_fp128.) Hi Anton, Does the spec force evaluation to happen in half mode, or does it specify that there is a promotion to float (or some other type) an operation, then truncation back to half? -Chris From clattner at apple.com Thu Feb 24 01:21:40 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 23 Feb 2011 23:21:40 -0800 Subject: [LLVMdev] Implementing platform specific library call simplification In-Reply-To: References: <4D499E40.20409@xmos.com> Message-ID: <12463B47-052E-40A2-B1AB-39A07AD84882@apple.com> On Feb 13, 2011, at 12:24 AM, Chris Lattner wrote: > On Feb 2, 2011, at 10:11 AM, Richard Osborne wrote: >> The newlib C library provides iprintf(), a restricted version of printf >> without support for floating-point formatting. I'd like to add an >> optimization which turns calls to printf() into calls to iprintf() if >> the format string has no floating point specifiers. > > Cool, ok. I can see how this would be very useful for a variety of embedded systems. > >> At the moment I've got this working locally by adding code to the >> simplify-libcalls pass. However this will break on targets where >> iprintf() isn't available. Is there a sensible place to add information >> about which library functions are available for a particular target? > > I'd suggest adding a bool argument (HasIPrintf) to the createSimplifyLibCallsPass function and the pass constructor. Then clang (or whatever is setting up the pass manager) can query the appropriate target info to pass down this flag. > > Longer term, I'd like to introduce a simple interface (via TargetRegistry) for exposing target libcall info. This would be useful to eliminate the HAVE_FLOORF etc #defines in simplifylibcalls, which break cross compilation. Hi Richard, Just to close the loop on this, I went ahead and added a new llvm/Target/TargetLibraryInfo.h and added it to simplifylibcalls. TargetLibraryInfo doesn't handle all the libcalls that SimplifyLibCalls handles yet, but it should provide a starting point for iprintf: just add an iprintf enum to TargetLibraryInfo and make your transformation predicated on TLI->has(LibFunc::iprintf). It would be great to see this go into mainline, -Chris From criswell at illinois.edu Thu Feb 24 02:41:07 2011 From: criswell at illinois.edu (John Criswell) Date: Thu, 24 Feb 2011 02:41:07 -0600 Subject: [LLVMdev] Implementing platform specific library call simplification In-Reply-To: <12463B47-052E-40A2-B1AB-39A07AD84882@apple.com> References: <4D499E40.20409@xmos.com> <12463B47-052E-40A2-B1AB-39A07AD84882@apple.com> Message-ID: <4D6619A3.8060001@illinois.edu> On 2/24/2011 1:21 AM, Chris Lattner wrote: > On Feb 13, 2011, at 12:24 AM, Chris Lattner wrote: > >> On Feb 2, 2011, at 10:11 AM, Richard Osborne wrote: >>> The newlib C library provides iprintf(), a restricted version of printf >>> without support for floating-point formatting. I'd like to add an >>> optimization which turns calls to printf() into calls to iprintf() if >>> the format string has no floating point specifiers. >> Cool, ok. I can see how this would be very useful for a variety of embedded systems. >> >>> At the moment I've got this working locally by adding code to the >>> simplify-libcalls pass. However this will break on targe