From matthieu.riou at gmail.com Mon Sep 1 00:52:40 2008 From: matthieu.riou at gmail.com (Matthieu Riou) Date: Sun, 31 Aug 2008 22:52:40 -0700 Subject: [LLVMdev] Unresolveable fallthrough functions Message-ID: Hi, I'm following the Kaleidoscope tutorial (which is very good btw) and am having difficulties having function calls for functions that haven't been defined getting resolved to plain C++ functions. In the tutorial (end of chapter 4), executing "extern putchard(x); putchard(120);" should execute the corresponding C++ function defined in the same file. Unfortunately in my case it only produces the following error: ready> ERROR: Program used external function 'putchard' which could not be resolved! Any idea of what could be wrong? Thanks! Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080831/a9a7b6d9/attachment.html From baldrick at free.fr Mon Sep 1 08:53:24 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 1 Sep 2008 15:53:24 +0200 Subject: [LLVMdev] Type Legalizer - Load handling problem In-Reply-To: <1220033339.4175.20.camel@idc-lt-i00171.microchip.com> References: <200808291728.44126.baldrick@free.fr> <1220033339.4175.20.camel@idc-lt-i00171.microchip.com> Message-ID: <200809011553.24404.baldrick@free.fr> > > That said, it looks like it is done this way because no-one needed > > anything more. It could easily be changed to handle the case of any > > number of return values. > > > Why not use ReplaceNodeWith ? I just took a look and it isn't that simple. This code is used for example to replace i32 = truncate 0x2374b48 with the first result of i32,ch = load 0x2356390, 0x2357188, 0x2356b88 <0x236ee80:0> alignment=4 This works fine right now. It fails with ReplaceNodeWith because the number of results differs. It could be made to work by using a MergeValues node to produce a node with one result out of the load, and similarly for the other examples of this kind of thing. Ciao, Duncan. From asl at math.spbu.ru Mon Sep 1 10:14:33 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Mon, 1 Sep 2008 19:14:33 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?VW5yZXNvbHZlYWJsZSBmYWxsdGhyb3VnaCBmdW5jdGlv?= =?koi8-r?b?bnM=?= Message-ID: <200809011514.m81FEXfE031649@star.math.spbu.ru> Hello, > ready> ERROR: Program used external function 'putchard' which could not be > resolved! > Any idea of what could be wrong? Please make sure you're using C linkage for such functions, due to mangling the name of function being emitted is not "putchard". Something like this: extern "C" void putchard(char c) { ... } Or, just provide a mapping by hands (if you're on platform without dynamic linking, e.g. on windows) -- WBR, Anton Korobeynikov From sanjiv.gupta at microchip.com Mon Sep 1 12:41:52 2008 From: sanjiv.gupta at microchip.com (sanjiv gupta) Date: Mon, 01 Sep 2008 23:11:52 +0530 Subject: [LLVMdev] Type Legalizer - Load handling problem In-Reply-To: <200809011553.24404.baldrick@free.fr> References: <200808291728.44126.baldrick@free.fr> <1220033339.4175.20.camel@idc-lt-i00171.microchip.com> <200809011553.24404.baldrick@free.fr> Message-ID: <1220290912.3905.7.camel@idc-lt-i00171.microchip.com> On Mon, 2008-09-01 at 15:53 +0200, Duncan Sands wrote: > > > That said, it looks like it is done this way because no-one needed > > > anything more. It could easily be changed to handle the case of any > > > number of return values. > > > > > Why not use ReplaceNodeWith ? > > I just took a look and it isn't that simple. This code is used > for example to replace > i32 = truncate 0x2374b48 > with the first result of > i32,ch = load 0x2356390, 0x2357188, 0x2356b88 <0x236ee80:0> alignment=4 > This works fine right now. It fails with ReplaceNodeWith because the > number of results differs. It could be made to work by using a MergeValues > node to produce a node with one result out of the load, and similarly for > the other examples of this kind of thing. > I think we will have to go that way since I may want to replace a "store" node also (A store node does not produce any results). In this case ReplaceNodeWith () is my only way out. Thanks, Sanjiv From sanjiv.gupta at microchip.com Mon Sep 1 12:50:15 2008 From: sanjiv.gupta at microchip.com (sanjiv gupta) Date: Mon, 01 Sep 2008 23:20:15 +0530 Subject: [LLVMdev] BUILD_TRIPLET node. Message-ID: <1220291415.3905.16.camel@idc-lt-i00171.microchip.com> Currently I can use a BUILD_PAIR to make a pair of two arbitrary values to a desired result value. For example, I can make i8,build_pair = (i8, i8) or i16,build_pair = (i1, i8). This is turning out to very handy when I replace nodes during the expansion/legalization of types for my target. I was just wondering if we could go one more step further and create a BUILD_TRIPLET node which can contain three incoming operands instead of just two. I know that I can do that with two build_pairs , but a build_triplet will make my code cleaner and easy to follow. - Sanjiv From matthieu.riou at gmail.com Mon Sep 1 13:17:32 2008 From: matthieu.riou at gmail.com (mriou) Date: Mon, 1 Sep 2008 11:17:32 -0700 (PDT) Subject: [LLVMdev] Unresolveable fallthrough functions In-Reply-To: <200809011514.m81FEXfE031649@star.math.spbu.ru> References: <200809011514.m81FEXfE031649@star.math.spbu.ru> Message-ID: <19258704.post@talk.nabble.com> Anton Korobeynikov wrote: > > Hello, > >> ready> ERROR: Program used external function 'putchard' which could not >> be >> resolved! >> Any idea of what could be wrong? > Please make sure you're using C linkage for such functions, due to > mangling the name of > function being emitted is not "putchard". Something like this: > > extern "C" void putchard(char c) { > ... > } > > Or, just provide a mapping by hands (if you're on platform without dynamic > linking, e.g. on > windows) > Thanks for the reply. I'm on Linux and the function is extern'd: extern "C" double putchard(double X) { putchar((char)X); return 0; } Using the sin(x) and cos(x) functions work though, only the ones included in the main file don't. So I'm a bit puzzled... Thanks, Matthieu -- View this message in context: http://www.nabble.com/Unresolveable-fallthrough-functions-tp19249293p19258704.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From cedric.venet at laposte.net Mon Sep 1 14:01:25 2008 From: cedric.venet at laposte.net (=?iso-8859-1?Q?C=E9dric_Venet?=) Date: Mon, 1 Sep 2008 21:01:25 +0200 Subject: [LLVMdev] Unresolveable fallthrough functions In-Reply-To: <19258704.post@talk.nabble.com> References: <200809011514.m81FEXfE031649@star.math.spbu.ru> <19258704.post@talk.nabble.com> Message-ID: <002701c90c65$22d6c320$68844960$@venet@laposte.net> > -----Message d'origine----- > De?: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > De la part de mriou > Envoy??: lundi 1 septembre 2008 20:18 > ??: llvmdev at cs.uiuc.edu > Objet?: Re: [LLVMdev] Unresolveable fallthrough functions > > > > > Anton Korobeynikov wrote: > > > > Hello, > > > >> ready> ERROR: Program used external function 'putchard' which could > not > >> be > >> resolved! > >> Any idea of what could be wrong? > > Please make sure you're using C linkage for such functions, due to > > mangling the name of > > function being emitted is not "putchard". Something like this: > > > > extern "C" void putchard(char c) { > > ... > > } > > > > Or, just provide a mapping by hands (if you're on platform without > dynamic > > linking, e.g. on > > windows) > > > > Thanks for the reply. I'm on Linux and the function is extern'd: > > extern "C" double putchard(double X) { > putchar((char)X); > return 0; > } > > Using the sin(x) and cos(x) functions work though, only the ones > included in > the main file don't. So I'm a bit puzzled... > > Thanks, > Matthieu > If you don't use the function anywhere, the compiler may/will strip it off (or if the compiler can 'understand' that the function is never called). It may be the problem. Just my 2cents C?dric From eli.friedman at gmail.com Mon Sep 1 16:02:41 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 1 Sep 2008 14:02:41 -0700 Subject: [LLVMdev] BUILD_TRIPLET node. In-Reply-To: <1220291415.3905.16.camel@idc-lt-i00171.microchip.com> References: <1220291415.3905.16.camel@idc-lt-i00171.microchip.com> Message-ID: On Mon, Sep 1, 2008 at 10:50 AM, sanjiv gupta wrote: > Currently I can use a BUILD_PAIR to make a pair of two arbitrary values > to a desired result value. For example, I can make i8,build_pair = > (i8, i8) or i16,build_pair = (i1, i8). I don't think those are legal; from SelectionDAGNodes.h: // BUILD_PAIR - This is the opposite of EXTRACT_ELEMENT in some ways. Given // two values of the same integer value type, this produces a value twice as // big. Like EXTRACT_ELEMENT, this can only be used before legalization. > This is turning out to very handy when I replace nodes during the > expansion/legalization of types for my target. > > I was just wondering if we could go one more step further and create a > BUILD_TRIPLET node which can contain three incoming operands instead of > just two. I know that I can do that with two build_pairs , but a > build_triplet will make my code cleaner and easy to follow. Maybe MERGE_VALUES would be more suited to what you're doing? -Eli From Dr.Graef at t-online.de Mon Sep 1 18:54:39 2008 From: Dr.Graef at t-online.de (Albert Graef) Date: Tue, 02 Sep 2008 01:54:39 +0200 Subject: [LLVMdev] Unresolveable fallthrough functions In-Reply-To: <19258704.post@talk.nabble.com> References: <200809011514.m81FEXfE031649@star.math.spbu.ru> <19258704.post@talk.nabble.com> Message-ID: <48BC80BF.4020001@t-online.de> mriou wrote: > Using the sin(x) and cos(x) functions work though, only the ones included in > the main file don't. So I'm a bit puzzled... Did you link your executable with -rdynamic? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From matthieu.riou at gmail.com Mon Sep 1 19:03:27 2008 From: matthieu.riou at gmail.com (Matthieu Riou) Date: Mon, 1 Sep 2008 17:03:27 -0700 Subject: [LLVMdev] Unresolveable fallthrough functions In-Reply-To: <48BC80BF.4020001@t-online.de> References: <200809011514.m81FEXfE031649@star.math.spbu.ru> <19258704.post@talk.nabble.com> <48BC80BF.4020001@t-online.de> Message-ID: Ah yes you're right (as well as Cedric). Using -rdynamic solved it, thanks a lot for the help. I'll submit a documentation patch for the tutorial. Thanks! Matthieu On Mon, Sep 1, 2008 at 4:54 PM, Albert Graef wrote: > mriou wrote: > > Using the sin(x) and cos(x) functions work though, only the ones included > in > > the main file don't. So I'm a bit puzzled... > > Did you link your executable with -rdynamic? > > -- > Dr. Albert Gr"af > Dept. of Music-Informatics, University of Mainz, Germany > Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de > WWW: http://www.musikinformatik.uni-mainz.de/ag > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080901/52f727fa/attachment.html From baldrick at free.fr Tue Sep 2 02:25:37 2008 From: baldrick at free.fr (Duncan Sands) Date: Tue, 2 Sep 2008 09:25:37 +0200 Subject: [LLVMdev] Type Legalizer - Load handling problem In-Reply-To: <1220290912.3905.7.camel@idc-lt-i00171.microchip.com> References: <200809011553.24404.baldrick@free.fr> <1220290912.3905.7.camel@idc-lt-i00171.microchip.com> Message-ID: <200809020925.38272.baldrick@free.fr> > I think we will have to go that way since I may want to replace a "store" node also > (A store node does not produce any results). In this case ReplaceNodeWith () is my only way out. I agree we should go that way because it is more logical. However you can also work around the problem by calling ReplaceNodeWith yourself, and returning an SDValue with null node. Ciao, Duncan. From baldrick at free.fr Tue Sep 2 03:00:43 2008 From: baldrick at free.fr (Duncan Sands) Date: Tue, 2 Sep 2008 10:00:43 +0200 Subject: [LLVMdev] LLVM build failures Message-ID: <200809021000.43447.baldrick@free.fr> I'm seeing a lot of build failures recently: (1) on x86-64 linux, gcc 4.1.2: ... llvm[3]: Compiling Hello.cpp for Debug build (PIC) llvm[3]: Linking Debug Loadable Module LLVMHello.so /usr/bin/ld: .../llvm/build/llvm/lib/Transforms/Hello/Debug/.libs/Hello.o: relocation R_X86_64_PC32 against `std::basic_string, std::allocator >::~basic_string()@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status ... (2) on alpha, gcc 4.2.4. The "unknown component name: alphacodegen" didn't use to occur. ... make[2]: Leaving directory `.../llvm/build/llvm/tools/llvm-link' llvm-config: unknown component name: alphacodegen make[2]: Entering directory `.../llvm/build/llvm/tools/lli' llvm[2]: Compiling lli.cpp for Debug build llvm-config: unknown component name: alphacodegen llvm[2]: Linking Debug executable lli .../llvm/build/llvm/tools/lli/Debug/lli.o: In function `ForceCodegenLinking': .../llvm/build/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:32: undefined reference to `llvm::createSimpleRegisterAllocator()' .../llvm/build/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:33: undefined reference to `llvm::createLocalRegisterAllocator()' .../llvm/build/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:34: undefined reference to `llvm::createBigBlockRegisterAllocator()' .../llvm/build/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:35: undefined reference to `llvm::createLinearScanRegisterAllocator()' .../llvm/build/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:37: undefined reference to `llvm::createSimpleRegisterCoalescer()' (lots more of these) (3) similar problem on sparc64, gcc 4.3.1: ... make[2]: Leaving directory `.../llvm/build/llvm/tools/llvm-link' llvm-config: unknown component name: sparccodegen make[2]: Entering directory `.../llvm/build/llvm/tools/lli' llvm[2]: Compiling lli.cpp for Debug build llvm-config: unknown component name: sparccodegen llvm[2]: Linking Debug executable lli .../llvm/build/llvm/tools/lli/Debug/lli.o: In function `ForceCodegenLinking': .../llvm/build/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:32: undefined reference to `llvm::createSimpleRegisterAllocato r()' .../llvm/build/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:33: undefined reference to `llvm::createLocalRegisterAllocator()' .../llvm/build/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:34: undefined reference to `llvm::createBigBlockRegisterAllocator()' (lots more of these) Not sure when these started failing - sometime within the last two weeks. Ciao, Duncan. From evan.cheng at apple.com Tue Sep 2 03:23:28 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 2 Sep 2008 01:23:28 -0700 Subject: [LLVMdev] Correct way of JITing multiple modules? In-Reply-To: <255C5EF2-C526-44C0-B178-8E8D06271783@swan.ac.uk> References: <255C5EF2-C526-44C0-B178-8E8D06271783@swan.ac.uk> Message-ID: <3B8910EE-BC89-47D2-A0FE-4284A0E2BF23@apple.com> On Aug 31, 2008, at 7:54 AM, David Chisnall wrote: > Hi, > > I'm trying to work out the correct way of JITing multiple modules. > My original approach was to create a new ExecutionEngine for each > Module, however this generates an assert failure. If I create a new Right. That won't work. > > ModuleProvider for each new Module and then add this to a single > ExecutionEngine then I have a problem with static constructors not Multiple ModuleProvider is the right solution. > > being run. With a single module, I can call > runStaticConstructorsDestructors(). With the second one, neither > ommitting this nor calling it a second time appears to work (I don't > think either of these is exactly correct, since I don't want to run > the static constructors on pre-existing modules twice, I just want > static ctors to run in the new module). You can add a new runStaticConstructorsDestructors which takes a Module as argument and runs only the static initializers for the module. You can model it after the existing runStaticConstructorsDestructors. It should be pretty straight forward. Evan > > > Can anyone advise? > > David > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Tue Sep 2 03:24:51 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 2 Sep 2008 01:24:51 -0700 Subject: [LLVMdev] LLVM Instruction Scheduling Pass In-Reply-To: <1220088476.4427.14.camel@idc-lt-i00171.microchip.com> References: <1220031822.4175.8.camel@idc-lt-i00171.microchip.com> <2D513AD2-578D-450D-B539-22ED66C1FEFD@apple.com> <1220088476.4427.14.camel@idc-lt-i00171.microchip.com> Message-ID: <3F73B99E-071B-4A52-9629-DFDB9BD03CE1@apple.com> On Aug 30, 2008, at 2:27 AM, sanjiv gupta wrote: > On Sat, 2008-08-30 at 00:17 -0700, Evan Cheng wrote: >> On Aug 29, 2008, at 10:43 AM, sanjiv gupta wrote: >> >>> I have two instructions , both have flag dependency onto a common >>> instruction. So this forms a closed loop. The instruction scheduler >>> asserts saying that the common instruction is already inserted into >>> FlaggedNodes list....etc. >> >> A flag value cannot be read by two nods. That's not legal. >> > I see. > What's a good way to model instructions that depend on the side-effect > of an earlier instruction? Using flag is the right solution. But if you have multiple nodes that are dependent on the same flag, you'll have to linearize them. The first reader of the flag should produce a flag itself so the second reader can read that flag value instead. Evan > > > > - Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Tue Sep 2 03:27:03 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 2 Sep 2008 01:27:03 -0700 Subject: [LLVMdev] BUILD_TRIPLET node. In-Reply-To: <1220291415.3905.16.camel@idc-lt-i00171.microchip.com> References: <1220291415.3905.16.camel@idc-lt-i00171.microchip.com> Message-ID: On Sep 1, 2008, at 10:50 AM, sanjiv gupta wrote: > Currently I can use a BUILD_PAIR to make a pair of two arbitrary > values > to a desired result value. For example, I can make i8,build_pair = > (i8, i8) or i16,build_pair = (i1, i8). > > This is turning out to very handy when I replace nodes during the > expansion/legalization of types for my target. > > I was just wondering if we could go one more step further and create a > BUILD_TRIPLET node which can contain three incoming operands instead > of > just two. I know that I can do that with two build_pairs , but a > build_triplet will make my code cleaner and easy to follow. We generally do not extend the IR just for convenience. Adding something like BUILD_TRIPLET is too arbitrary. It goes against the LLVM philosophy. Sorry. Evan > > > - Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From m.kooijman at student.utwente.nl Tue Sep 2 04:49:20 2008 From: m.kooijman at student.utwente.nl (Matthijs Kooijman) Date: Tue, 2 Sep 2008 11:49:20 +0200 Subject: [LLVMdev] LLVM build failures In-Reply-To: <200809021000.43447.baldrick@free.fr> References: <200809021000.43447.baldrick@free.fr> Message-ID: <20080902094920.GB32157@katherina.student.utwente.nl> Hi Duncan, > (1) on x86-64 linux, gcc 4.1.2: I'm not seeing those in x86-64 with gcc 4.3 on my system. However, I was seeing build failures on x86-32 with gcc 4.1, related to undefined references. These were caused by the -finlines-visibility-hidden introduced by r55557. I reverted that patch, could you check if you're still seeing all these failures? Gr. Matthijs From asl at math.spbu.ru Tue Sep 2 06:26:40 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Tue, 2 Sep 2008 15:26:40 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?TExWTSBidWlsZCBmYWlsdXJlcw==?= Message-ID: <200809021126.m82BQeFG002617@star.math.spbu.ru> Hi, > (2) on alpha, gcc 4.2.4. The "unknown component name: alphacodegen" > didn't use to occur. My fault, I'll fix it. The problem is that lli wants to link in JIT module, which does not exist for these targets. -- WBR, Anton Korobeynikov From prakash.prabhu at gmail.com Tue Sep 2 10:46:25 2008 From: prakash.prabhu at gmail.com (Prakash Prabhu) Date: Tue, 2 Sep 2008 11:46:25 -0400 Subject: [LLVMdev] CloneBasicBlock and Unnamed Temporaries Message-ID: <85a4cc050809020846v6d1c54eeg896e5d4f4def493b@mail.gmail.com> Hi, I was trying to use CloneBasicBlock() (in Cloning.h) to clone basic blocks in one of my transform passes. For example, when I have a basic block like: bb1: ; preds = %bb load i32* %i, align 4 ; :11 [#uses=2] load i32* %n_addr, align 4 ; :12 [#uses=2] icmp slt i32 %11, %12 ; :13 [#uses=2] cloning it gives something like: bb1_clone: ; preds = %entry load i32* %i, align 4 ; :28 [#uses=0] load i32* %n_addr, align 4 ; :29 [#uses=0] icmp slt i32 %11, %12 ; :30 [#uses=0] Since the temporaries referred to in the cloned icmp instruction are still those created in bb1, I get the "Instruction does not dominate all uses" error thrown by Verifier. A couple of questions (assuming that the code is not in SSA form, courtesy -reg2ssa pass): (1) Is it always true in the general case (it was true in the example I tested with) that the unnamed temporaries referenced/created are local to a basic block ? (2) If the answer to (1) is no: If I add the cloned basic block (bb1_clone) into the same function at a place such that all paths to bb1_clone from the entry are the same as the earlier paths to bb1 (except that I am now removing an earlier path to bb1 from one of its predecessor), would repatching the unnamed temporaries in bb_clone1 to the new ones (local to the cloned block ?) in the client transform pass be good enough to result in a well formed LLVM IR representation ? Thanks much for your time. - Prakash From dyson at akya.co.uk Tue Sep 2 11:05:19 2008 From: dyson at akya.co.uk (Dyson Wilkes) Date: Tue, 02 Sep 2008 17:05:19 +0100 Subject: [LLVMdev] LLVS newbie adding a new target Message-ID: <48BD643F.2030004@akya.co.uk> Hi I am interested in developing a new target for LLVM and wanted to check where my new code should reside. Should I just add a new sub-directory to lib/Targets and populate that with the necessary files? I am using ARM as a template, as I am most familiar with that architecture, so I assume copying files from that directory is a good starting point. I have tried a trivial build of a new target based on ARM by copying all the ARM target files to a new directory and changing names of files in the code to create a "new" target. After adding the new target to the TARGETS_TO_BUILD list in "configure", I was able to "make" a new build that included the new target. Of course it is just a copy of the ARM target at this stage but it confirms I have grasped the basics of the LLVM tree and build process. My concern is that, if there is a new release of LLVM, I will need to re-integrate my source into it. At this stage this looks fairly trivial to do but I do now want to get caught out in the future by ploughing on without checking there is not a more intelligent way to organise my code that I have overlooked. Cheers, - Dyson From dag at cray.com Tue Sep 2 12:42:40 2008 From: dag at cray.com (David Greene) Date: Tue, 2 Sep 2008 12:42:40 -0500 Subject: [LLVMdev] Instruction MVT::ValueTypes Message-ID: <200809021242.41080.dag@cray.com> Is there an easy way to get the MVT::ValueType of a MachineInstruction MachineOperand? For example, the register operand of an x86 MOVAPD should have an MVT::ValueType of v2f64. A MOVAPS register operand should have an MVT::ValueType of v4f32. So given a MachineInstruction and its MachineOperands is there some easy way to derive this information? I don't see anything in TargetInstrInfo that would help. -Dave From isanbard at gmail.com Tue Sep 2 12:45:01 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 2 Sep 2008 10:45:01 -0700 Subject: [LLVMdev] LLVS newbie adding a new target In-Reply-To: <48BD643F.2030004@akya.co.uk> References: <48BD643F.2030004@akya.co.uk> Message-ID: <16e5fdf90809021045k62f61b5av7ff52b30c6bdf6f6@mail.gmail.com> On Tue, Sep 2, 2008 at 9:05 AM, Dyson Wilkes wrote: > Hi > > I am interested in developing a new target for LLVM and wanted to check > where my new code should reside. Should I just add a new sub-directory > to lib/Targets and populate that with the necessary files? Yup! That would be the place. > I am using > ARM as a template, as I am most familiar with that architecture, so I > assume copying files from that directory is a good starting point. > Your assumption is correct. :-) > I have tried a trivial build of a new target based on ARM by copying all > the ARM target files to a new directory and changing names of files in > the code to create a "new" target. After adding the new target to the > TARGETS_TO_BUILD list in "configure", I was able to "make" a new build > that included the new target. Of course it is just a copy of the ARM > target at this stage but it confirms I have grasped the basics of the > LLVM tree and build process. > > My concern is that, if there is a new release of LLVM, I will need to > re-integrate my source into it. At this stage this looks fairly trivial > to do but I do now want to get caught out in the future by ploughing on > without checking there is not a more intelligent way to organise my code > that I have overlooked. > No, what you're doing is the best approach. If you want, you can live off of the SVN top-of-tree. Then you won't have to worry about merging with a new release problems. You also get the benefit of being on top of changes that could affect the interface to your new back-end. Of course, there could be breakage having nothing to do with your back-end that you'll have to deal with. So there are trade-offs. -bw From regehr at cs.utah.edu Tue Sep 2 14:08:29 2008 From: regehr at cs.utah.edu (John Regehr) Date: Tue, 2 Sep 2008 13:08:29 -0600 (MDT) Subject: [LLVMdev] New llvm-gcc bootstrap failure In-Reply-To: <38a0d8450808250204x56fe7f9cm6f7adfcfece8f75d@mail.gmail.com> References: <200807232023.17401.baldrick@free.fr> <38a0d8450808221048k51f796aen52808ce106d82f50@mail.gmail.com> <38a0d8450808250204x56fe7f9cm6f7adfcfece8f75d@mail.gmail.com> Message-ID: I get the error below (and have for a couple weeks now) when trying to build llvm-gcc on Ubuntu Feisty. In the meantime, on Ubuntu Gutsy, everything has been building fine. Both are release builds for x86. John cc1: StringMap.cpp:177: void llvm::StringMapImpl::RemoveKey(llvm::StringMapEntryBase*): Assertion `V == V2 && "Didn't find key?"' failed. From regehr at cs.utah.edu Tue Sep 2 14:13:10 2008 From: regehr at cs.utah.edu (John Regehr) Date: Tue, 2 Sep 2008 13:13:10 -0600 (MDT) Subject: [LLVMdev] New llvm-gcc bootstrap failure In-Reply-To: References: <200807232023.17401.baldrick@free.fr> <38a0d8450808221048k51f796aen52808ce106d82f50@mail.gmail.com> <38a0d8450808250204x56fe7f9cm6f7adfcfece8f75d@mail.gmail.com> Message-ID: Doh-- not that it likely matters but I meant to say that things have been building fine on Hardy (8.04) not Gutsy. John On Tue, 2 Sep 2008, John Regehr wrote: > I get the error below (and have for a couple weeks now) when trying to > build llvm-gcc on Ubuntu Feisty. In the meantime, on Ubuntu Gutsy, > everything has been building fine. Both are release builds for x86. > > John > > > cc1: StringMap.cpp:177: void > llvm::StringMapImpl::RemoveKey(llvm::StringMapEntryBase*): Assertion `V == > V2 && "Didn't find key?"' failed. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From evan.cheng at apple.com Tue Sep 2 16:47:10 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 2 Sep 2008 14:47:10 -0700 Subject: [LLVMdev] Instruction MVT::ValueTypes In-Reply-To: <200809021242.41080.dag@cray.com> References: <200809021242.41080.dag@cray.com> Message-ID: <8113A778-EE02-4D7C-A920-EC97B6471004@apple.com> On Sep 2, 2008, at 10:42 AM, David Greene wrote: > Is there an easy way to get the MVT::ValueType of a MachineInstruction > MachineOperand? For example, the register operand of an x86 MOVAPD > should > have an MVT::ValueType of v2f64. A MOVAPS register operand should > have an > MVT::ValueType of v4f32. The short answer is no. A op of a number of different VTs can map to the same instruction. However, given a register class you can get to the list of VTs that map to it. Take a look at TargetRegisterDesc. Evan > > > So given a MachineInstruction and its MachineOperands is there some > easy way > to derive this information? I don't see anything in TargetInstrInfo > that > would help. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From wmatyjewicz at fastmail.fm Tue Sep 2 17:24:31 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Wed, 03 Sep 2008 00:24:31 +0200 Subject: [LLVMdev] Dependence Analysis [was: Flow-Sensitive AA] In-Reply-To: <96683FDD-B488-45F7-8485-430508EF4C00@apple.com> References: <200808181719.11656.dag@cray.com> <200808201505.14738.dag@cray.com> <1219307831.25343.1269753457@webmail.messagingengine.com> <96683FDD-B488-45F7-8485-430508EF4C00@apple.com> Message-ID: <48BDBD1F.30703@fastmail.fm> > We want to model this as an analysis and make following changes. > > - Rename LoopMemDepAnalysis as DataDependenceAnalysis. Various > transformation passes will use this interface to access data > dependence info. This is an external interface. Put this in include/ > llvm/Analysis. > - Make DirectionVector (and later on DistanceVector) independent > interface and put them in ADT. > - Put various tests, DeltaTest, in lib/Analysis folder. The > transformation pass does not need to see these details. > - DataDependenceAnalysis will select various dependence tests based on > user selection. We want a interface similar to AnalysisGroup used by > Alias Analysis, but we also want to allow the possibility of running > multiple tests at the same time. > - Make ArrayDepTester a private implementation detail of > DataDependenceAnalysis. > > What do you think ? It makes sense to me. However, I don't have idea how to organize dependence analysis internally to allow for flexibility and precision at the same time. The second hard part is, I guess, designing good analysis interface. For instance: how should distance vectors be represented? as separate objects or annotations to distance vectors? The number of distance (direction) vectors grows quadratically with the size of the loop (roughly) what may constitute a problem for really large loops. Unfortunately, I won't have time to help you with the implementation now. But feel free to use any pieces of the code I have posted. Wojtek From isanbard at gmail.com Tue Sep 2 19:22:47 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 2 Sep 2008 17:22:47 -0700 Subject: [LLVMdev] Merge-Cha-Cha Message-ID: <16e5fdf90809021722n167528f1je08cabeddb6bab5f@mail.gmail.com> As you all have undoubtedly noticed, I recently did Yet Another Merge to Apple's GCC top-of-tree. This merge was prompted by several important fixes in the "blocks" implementation. There are still many testcases that need to be moved over, but those can come at our leisure. I compiled both the "Apple way" and the "FSF way". It also passed the tests in llvm-test/Multitest. It should be a good merge, but let me know if things break for you. -bw From belayda at gmail.com Tue Sep 2 19:34:09 2008 From: belayda at gmail.com (Bernardo Elayda) Date: Tue, 2 Sep 2008 17:34:09 -0700 Subject: [LLVMdev] Info on LLVM 2.3 which is available as a virutal appliance Message-ID: <3e5ed32f0809021734u268cfee8tfa84cc9181c81700@mail.gmail.com> Hi! I'm glad that their is interest in the VMware install of LLVM 2.3. The appliance(compressed via 7zip) is over 800 MB in size. So, I can't send it out via email. I don't have the resources to host it. If someone can find an area that this appliance can live, I'd be willing to upload it os that everyone could use it. regards, Bernardo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080902/0deafef9/attachment.html From scott.llvm at h4ck3r.net Tue Sep 2 20:07:57 2008 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Tue, 2 Sep 2008 18:07:57 -0700 Subject: [LLVMdev] Creating global data with [ 0 x ... ] type Message-ID: <84decce20809021807m425f4d59i7f204bcaff470837@mail.gmail.com> Hi I'm trying to create some global data representing something similar to a vtable in C++ (that'll be pointed to by the head of objects). I've called this a "metadata" table below. It includes some miscellaneous class-level information, as well as a typical vtable list-of-function-pointers. I need to have the vtable "inlined" into the metadata, in that I don't want an extra indirection by storing a pointer to the vtable in the metadata table. This means that the metadata table ends in a variable sized array. i.e.: %VtableEntryType = type { i32, i32 } %MetadataTable = type { i32, [0 x %VtableEntryType] } However, I can't figure out how to initialize it: ; most entries elided for simplicity @MyMetadataTable = global %MetadataTable { i32 0, [1 x %VtableEntryType] [ ; <--- problem here! %VtableEntryType { i32 1234, i32 1234 } ] } bitcast won't let me cast from [1 x %VtableEntryType] to [0 x %VtableEntryType] (I guess because the size differs). Is there another way to accomplish this initialization? I currently have a different metadata-type per language-type, but when there's 50k types in the system, it gets overly heavy to declare all those types when the only thing that ever happens to @MyMetadataTable is a store into the header of an object during allocation. thanks, scott From gordonhenriksen at me.com Tue Sep 2 20:55:13 2008 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Tue, 02 Sep 2008 21:55:13 -0400 Subject: [LLVMdev] Creating global data with [ 0 x ... ] type In-Reply-To: <84decce20809021807m425f4d59i7f204bcaff470837@mail.gmail.com> References: <84decce20809021807m425f4d59i7f204bcaff470837@mail.gmail.com> Message-ID: On Sep 2, 2008, at 21:07, Scott Graham wrote: > I'm trying to create some global data representing something similar > to a vtable in C++ (that'll be pointed to by the head of objects). > I've called this a "metadata" table below. It includes some > miscellaneous class-level information, as well as a typical vtable > list-of-function-pointers. > > I need to have the vtable "inlined" into the metadata, in that I don't > want an extra indirection by storing a pointer to the vtable in the > metadata table. This means that the metadata table ends in a variable > sized array. > > i.e.: > > %VtableEntryType = type { i32, i32 } > %MetadataTable = type { i32, [0 x %VtableEntryType] } > > However, I can't figure out how to initialize it: > > ; most entries elided for simplicity > @MyMetadataTable = global %MetadataTable { > i32 0, > [1 x %VtableEntryType] [ ; <--- problem here! > %VtableEntryType { i32 1234, i32 1234 } > ] > } > > > bitcast won't let me cast from [1 x %VtableEntryType] to [0 x > %VtableEntryType] (I guess because the size differs). Is there another > way to accomplish this initialization? > > I currently have a different metadata-type per language-type, but when > there's 50k types in the system, it gets overly heavy to declare all > those types when the only thing that ever happens to @MyMetadataTable > is a store into the header of an object during allocation. Hi Scott, As you've already discovered, your global variable must be defined using its actual storage type, which includes using a concrete array length. Bitcast the GlobalVariable from { ..., [n x ...] }* to { ..., [0 x ...] }* at the use sites instead (note: casting the pointer type, not the struct type). You do not need to name the types, of course. Note that the LLVM linker will introduce these bitcasts for you automatically (as will, in effect, the system linker). ? Gordon From vadve at cs.uiuc.edu Tue Sep 2 22:14:32 2008 From: vadve at cs.uiuc.edu (Vikram S. Adve) Date: Tue, 2 Sep 2008 22:14:32 -0500 Subject: [LLVMdev] Dependence Analysis [was: Flow-Sensitive AA] In-Reply-To: <48BDBD1F.30703@fastmail.fm> References: <200808181719.11656.dag@cray.com> <200808201505.14738.dag@cray.com> <1219307831.25343.1269753457@webmail.messagingengine.com> <96683FDD-B488-45F7-8485-430508EF4C00@apple.com> <48BDBD1F.30703@fastmail.fm> Message-ID: <0A745C63-2BB2-4DD0-BB4A-5F1189A9F49C@cs.uiuc.edu> On Sep 2, 2008, at 5:24 PM, Wojciech Matyjewicz wrote: > Unfortunately, I won't have time to help you with the implementation > now. But feel free to use any pieces of the code I have posted. I believe that Matthieu Delahaye is planning to work on this project so that should not be a problem. Your code will be helpful to him as a starting point so thanks for that! If you ever want to get back into this, please let us know. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080902/2f4aae42/attachment.html From regehr at cs.utah.edu Tue Sep 2 22:21:20 2008 From: regehr at cs.utah.edu (John Regehr) Date: Tue, 2 Sep 2008 21:21:20 -0600 (MDT) Subject: [LLVMdev] Merge-Cha-Cha In-Reply-To: <16e5fdf90809021722n167528f1je08cabeddb6bab5f@mail.gmail.com> References: <16e5fdf90809021722n167528f1je08cabeddb6bab5f@mail.gmail.com> Message-ID: I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -I/home/regehr/llvm/include -I/home/regehr/llvm/include -DENABLE_LLVM -I/home/regehr/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS ../../gcc/postreload-gcse.c -o postreload-gcse.o ../../gcc/postreload-gcse.c: In function eliminate_partially_redundant_load: ../../gcc/postreload-gcse.c:1123: error: flag_darwin_rtl_pre_ignore_critical_edges undeclared (first use in this function) ../../gcc/postreload-gcse.c:1123: error: (Each undeclared identifier is reported only once ../../gcc/postreload-gcse.c:1123: error: for each function it appears in.) make[3]: *** [postreload-gcse.o] Error 1 make[3]: Leaving directory `/home/regehr/llvm-gcc/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/regehr/llvm-gcc/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/regehr/llvm-gcc/build' make: *** [all] Error 2 regehr at john-home:~/llvm-gcc/build$ -- John Regehr, regehr at cs.utah.edu Assistant Professor, School of Computing, University of Utah http://www.cs.utah.edu/~regehr/ On Tue, 2 Sep 2008, Bill Wendling wrote: > As you all have undoubtedly noticed, I recently did Yet Another Merge > to Apple's GCC top-of-tree. This merge was prompted by several > important fixes in the "blocks" implementation. There are still many > testcases that need to be moved over, but those can come at our > leisure. I compiled both the "Apple way" and the "FSF way". It also > passed the tests in llvm-test/Multitest. It should be a good merge, > but let me know if things break for you. > > -bw > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From espindola at google.com Wed Sep 3 04:57:13 2008 From: espindola at google.com (Rafael Espindola) Date: Wed, 3 Sep 2008 10:57:13 +0100 Subject: [LLVMdev] New llvm-gcc bootstrap failure In-Reply-To: References: <200807232023.17401.baldrick@free.fr> <38a0d8450808221048k51f796aen52808ce106d82f50@mail.gmail.com> <38a0d8450808250204x56fe7f9cm6f7adfcfece8f75d@mail.gmail.com> Message-ID: <38a0d8450809030257w6d2c3353p35a3f13d6af81866@mail.gmail.com> 2008/9/2 John Regehr : > I get the error below (and have for a couple weeks now) when trying to > build llvm-gcc on Ubuntu Feisty. In the meantime, on Ubuntu Gutsy, > everything has been building fine. Both are release builds for x86. Can you try to reduce the problem? Copy and past the command line that fails, and add -save-temps -v. Having the cc1 line that fails and the .i file should help. > John Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047 From lhames at gmail.com Wed Sep 3 07:58:35 2008 From: lhames at gmail.com (Lang Hames) Date: Wed, 3 Sep 2008 22:58:35 +1000 Subject: [LLVMdev] Codegen/Register allocation question. Message-ID: <728927c70809030558h7e153e4o304dfe6e3d003bca@mail.gmail.com> Hi LLVMers, I have finally sorted out licensing issues and found some time, so I'm trying to port my PBQP register allocator to 2.4 in order to contribute it (if you want it). I've run into a bug that has me confused though. I'm currently failing the following assertion: llc: VirtRegMap.cpp:1733: void::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&, llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' failed. when attempting to allocate this machine function: entry: 4 %reg1024 = MOV32rr %EDI 12 %reg1025 = MOV64rr %RSI 20 ADJCALLSTACKDOWN 0, %ESP, %EFLAGS, %ESP 28 %reg1026 = MOV8ri 4 36 %reg1027 = FsFLD0SD 44 %reg1028 = LEA64r %reg0, 1, %reg0, 52 %RDI = MOV64rr %reg1028 60 %XMM0 = FsMOVAPDrr %reg1027 68 %XMM1 = FsMOVAPDrr %reg1027 76 %XMM2 = FsMOVAPDrr %reg1027 84 %XMM3 = FsMOVAPDrr %reg1027 92 %AL = MOV8rr %reg1026 100 CALL64pcrel32 , %RDI, %XMM0, %XMM1, %XMM2, %XMM3, %AL, %RAX, %RCX, %RDX, %RSI, %RDI, %R8, %R9, %R10, %R11, %FP0, %FP1, %FP2, %FP3, %FP4, %FP5, %FP6, %ST0, %ST1, %MM0, %MM1, %MM2, %MM3, %MM4, %MM5, %MM6, %MM7, %XMM0, %XMM1, %XMM2, %XMM3, %XMM4, %XMM5, %XMM6, %XMM7, %XMM8, %XMM9, %XMM10, %XMM11, %XMM12, %XMM13, %XMM14, %XMM15, %EFLAGS, %EAX, %ECX, %EDI, %EDX, %ESI 108 ADJCALLSTACKUP 0, 0, %ESP, %EFLAGS, %ESP 116 %reg1029 = MOV32rr %EAX, %RAX 124 %reg1030 = MOV32r0 %EFLAGS 132 %EAX = MOV32rr %reg1030 140 RET %EAX, %AX ********** REGISTER MAP ********** [reg1024 -> EAX] [reg1025 -> R10] [reg1026 -> AH] [reg1027 -> XMM10] [reg1028 -> R10] [reg1029 -> EAX] [reg1030 -> EAX] The failure occurs when the spiller tries to eliminate the assignment 116 %reg1029 = MOV32rr %EAX, %RAX after reg1029 is assigned EAX. It occurs because EAX isn't listed as killed, so InvalidateKills doesn't return it in KillRegs (but does return RAX). Is this a bug (was EAX supposed to be marked killed?), or was the register allocator supposed to mark EAX as killed? (doesn't seem as if it should - it was killed before regalloc got involved). Or have I missed something else? bugpoint produced bytecode is attached, but I don't suppose it's much help without the allocator. That's packaged as an LLVM project at the moment - so if it'll help you debug I can send you a copy. Cheers, Lang. --------- Bugpoint reduced bytecode from SingleSource/Vector/Output/build.llvm.bc --------- ; ModuleID = 'bugpoint-reduced-simplified.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128" target triple = "x86_64-pc-linux-gnu" @.str1 = external constant [13 x i8] ; <[13 x i8]*> [#uses=1] declare i32 @printf(i8* noalias, ...) nounwind define i32 @main(i32 %argc, i8** %Argv) nounwind { entry: %tmp25.i14 = call i32 (i8*, ...)* @printf( i8* noalias getelementptr ([13 x i8]* @.str1, i32 0, i64 0), double 0.000000e+00, double 0.000000e+00, double 0.000000e+00, double 0.000000e+00 ) nounwind ; [#uses=0] ret i32 0 } From baldrick at free.fr Wed Sep 3 09:02:07 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 3 Sep 2008 16:02:07 +0200 Subject: [LLVMdev] LLVM build failures In-Reply-To: <20080902094920.GB32157@katherina.student.utwente.nl> References: <200809021000.43447.baldrick@free.fr> <20080902094920.GB32157@katherina.student.utwente.nl> Message-ID: <200809031602.07782.baldrick@free.fr> > > (1) on x86-64 linux, gcc 4.1.2: > I'm not seeing those in x86-64 with gcc 4.3 on my system. > > However, I was seeing build failures on x86-32 with gcc 4.1, related to > undefined references. These were caused by the -finlines-visibility-hidden > introduced by r55557. I reverted that patch, could you check if you're still > seeing all these failures? x86-64 now compiles, thanks! Ciao, Duncan. From srimks11 at gmail.com Wed Sep 3 09:35:44 2008 From: srimks11 at gmail.com (Mukesh Srivastava) Date: Wed, 3 Sep 2008 20:05:44 +0530 Subject: [LLVMdev] LLVM FPGA interface. Message-ID: <3efa6bfc0809030735n1d94ef82o8b39e2f3a4eb8b94@mail.gmail.com> Hi LLVM community members. I downloaded LLVM-GCC4.2 Front-end source code and succefully installed alongwith LLVM-2.3 on linux x86_64. I think it's front-end has better optimizations. I am naive to LLVM environment, my focus is to generate LLVM inermediate code for FPGA. Are there any resources/links/papers/documents which discusses LLVM intermediate generation for FPGA needs. I am aware with Xilinx "CHiMPS" interface for FPGA but probably CHiMPS doesn't have any freely available eval version of CHiMPS to try with LLVM for study purposes. I 'ope I am not bothering LLVM developer's in asking such preliminary questions and support. ~BR Mukesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080903/731d3305/attachment-0001.html From andrewl at lenharth.org Wed Sep 3 09:47:40 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Wed, 3 Sep 2008 07:47:40 -0700 Subject: [LLVMdev] LLVM build failures In-Reply-To: <200809021126.m82BQeFG002617@star.math.spbu.ru> References: <200809021126.m82BQeFG002617@star.math.spbu.ru> Message-ID: <85dfcd7f0809030747x5ce38558w2ea718eab51cc3da@mail.gmail.com> 2008/9/2 Anton Korobeynikov : > Hi, > >> (2) on alpha, gcc 4.2.4. The "unknown component name: alphacodegen" >> didn't use to occur. > My fault, I'll fix it. The problem is that lli wants to link in JIT > module, which does not exist for these targets. JIT use to exist (and sometimes work) for alpha. I haven't done anything to get rid of it so I'm assuming it isn't being registered properly or something due to me not having done anything to keep it working. Andrew From dag at cray.com Wed Sep 3 10:50:31 2008 From: dag at cray.com (David Greene) Date: Wed, 3 Sep 2008 10:50:31 -0500 Subject: [LLVMdev] Dependence Analysis [was: Flow-Sensitive AA] In-Reply-To: <1220030118.7166.27.camel@matthieu-laptop> References: <200808181719.11656.dag@cray.com> <96683FDD-B488-45F7-8485-430508EF4C00@apple.com> <1220030118.7166.27.camel@matthieu-laptop> Message-ID: <200809031050.31784.dag@cray.com> On Friday 29 August 2008 12:15, Matthieu Delahaye wrote: > > - DataDependenceAnalysis will select various dependence tests based > > on > > user selection. We want a interface similar to AnalysisGroup used > > by > > Alias Analysis, but we also want to allow the possibility of running > > multiple tests at the same time. > > That will probably be the most difficult part. But with all the people > that shows interest on using or adding new analysis here, I am hopeful > we will obtain an acceptable stable API. Can you elaborate on the complexity here? Why is this any different from the way AliasAnalysis works? Yes, there will be a different API but the concept is the same -- if I can't make a solid decision, hand it off to the next analysis in the chain. -Dave From matthieu at illinois.edu Wed Sep 3 12:39:50 2008 From: matthieu at illinois.edu (Matthieu Delahaye) Date: Wed, 03 Sep 2008 12:39:50 -0500 Subject: [LLVMdev] Dependence Analysis [was: Flow-Sensitive AA] In-Reply-To: <200809031050.31784.dag@cray.com> References: <200808181719.11656.dag@cray.com> <96683FDD-B488-45F7-8485-430508EF4C00@apple.com> <1220030118.7166.27.camel@matthieu-laptop> <200809031050.31784.dag@cray.com> Message-ID: <1220463590.12291.88.camel@matthieu-laptop> On Wed, 2008-09-03 at 10:50 -0500, David Greene wrote: > On Friday 29 August 2008 12:15, Matthieu Delahaye wrote: > > > > - DataDependenceAnalysis will select various dependence tests based > > > on > > > user selection. We want a interface similar to AnalysisGroup used > > > by > > > Alias Analysis, but we also want to allow the possibility of running > > > multiple tests at the same time. > > > > That will probably be the most difficult part. But with all the people > > that shows interest on using or adding new analysis here, I am hopeful > > we will obtain an acceptable stable API. > > Can you elaborate on the complexity here? Why is this any different from > the way AliasAnalysis works? Yes, there will be a different API but the > concept is the same -- if I can't make a solid decision, hand it off to the > next analysis in the chain. I was actually talking about the API itself but I do think the chaining itself is not as easy either. First, note that my knowledge of data dependence analysis is much more theoretical than practical. Which means that any possibility I am suggesting needs to be pondered by their actual usefulness and that it does not necessarily means it can be implemented under reasonable conditions. Any critic is more than welcome. API: This is the matter of providing the possibilities to ask useful questions, and providing useful answers. [in the pow of the passes that are using the analysis]. The "textbook" version would be: give me the memory dependency(ies) between these two instructions. With the possibility to select the "dialect" of the answer: - There is a dependency, there is not, or maybe - Direction vectors - Distance vectors ... For many of us, including myself, this is all I would need. But if I would be working on vectorization, another question like "?Tell me whether there is no distance vector with a distance on the last level less than 4" is more meaningful. And: - this can be proved far faster than generating the whole dependencies (I have seen 50x speedup figures, but this is implementation dependent) - could be proved even in some cases where the Omega test cannot. So two questions: Is there any other kind of queries? Are they actually useful? Now for the "useful" answers: We have to admit that the proportion of loops whose upper bounds are known constant values at compile-time is decreasing rapidly... Some analysis handle that well at the cost of potentially generating different results predicated by conditions on these symbolic values. The expression of these predicates might not be trivial. This is what I had in mind when I talked above the difficulty of having a good API that do not change every time a new analysis is added. I doubt this API could be defined without the review of analysis users and writers. Now about the chaining: it is a matter of precision. We want either the exact result or, when it is not possible, we might want the most precise conservative answer [when we want to know more than yes/no/maybe]. The solution, as you describe it, is ok as long as one can provide an exact result. However, when no test can: - You may have obtained an exact result by making them work together rather than independently. - What conservative answer to provide when each test failed, but different conservative answers are provided from more than two tests? Matthieu From sanjiv.gupta at microchip.com Wed Sep 3 13:39:46 2008 From: sanjiv.gupta at microchip.com (sanjiv gupta) Date: Thu, 04 Sep 2008 00:09:46 +0530 Subject: [LLVMdev] Type Legalizer - Load handling problem In-Reply-To: <200809020925.38272.baldrick@free.fr> References: <200809011553.24404.baldrick@free.fr> <1220290912.3905.7.camel@idc-lt-i00171.microchip.com> <200809020925.38272.baldrick@free.fr> Message-ID: <1220467186.2972.1.camel@idc-lt-i00171.microchip.com> On Tue, 2008-09-02 at 09:25 +0200, Duncan Sands wrote: > > I think we will have to go that way since I may want to replace a "store" node also > > (A store node does not produce any results). In this case ReplaceNodeWith () is my only way out. > > I agree we should go that way because it is more logical. However > you can also work around the problem by calling ReplaceNodeWith > yourself, and returning an SDValue with null node. > How do we access ReplaceNodeWith in TLI ? - Sanjiv > Ciao, > > Duncan. From overminddl1 at gmail.com Wed Sep 3 13:47:57 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Wed, 3 Sep 2008 12:47:57 -0600 Subject: [LLVMdev] Info on LLVM 2.3 which is available as a virutal appliance In-Reply-To: <3e5ed32f0809021734u268cfee8tfa84cc9181c81700@mail.gmail.com> References: <3e5ed32f0809021734u268cfee8tfa84cc9181c81700@mail.gmail.com> Message-ID: <3f49a9f40809031147t223fd440n5283887d1bdb7979@mail.gmail.com> As long as it does not exceed a terabyte or 1.5tb or so of download bandwidth a month, I could host it without issue. Probably something relating directly to the LLVM servers would be best, or perhaps the VMWare appliances page? On Tue, Sep 2, 2008 at 6:34 PM, Bernardo Elayda wrote: > Hi! > > I'm glad that their is interest in the VMware install of LLVM 2.3. > > The appliance(compressed via 7zip) is over 800 MB in size. So, I can't send > it out via email. > I don't have the resources to host it. If someone can find an area that > this appliance can live, I'd be willing to upload it os that everyone could > use it. > > regards, > Bernardo > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From dag at cray.com Wed Sep 3 15:06:46 2008 From: dag at cray.com (David Greene) Date: Wed, 3 Sep 2008 15:06:46 -0500 Subject: [LLVMdev] Dependence Analysis [was: Flow-Sensitive AA] In-Reply-To: <1220463590.12291.88.camel@matthieu-laptop> References: <200808181719.11656.dag@cray.com> <200809031050.31784.dag@cray.com> <1220463590.12291.88.camel@matthieu-laptop> Message-ID: <200809031506.46603.dag@cray.com> On Wednesday 03 September 2008 12:39, Matthieu Delahaye wrote: = > API: This is the matter of providing the possibilities to ask useful > questions, and providing useful answers. [in the pow of the passes that > are using the analysis]. > > The "textbook" version would be: give me the memory dependency(ies) > between these two instructions. With the possibility to select the > "dialect" of the answer: > - There is a dependency, there is not, or maybe > - Direction vectors > - Distance vectors > ... > > For many of us, including myself, this is all I would need. But if I Right. > would be working on vectorization, another question like "?Tell me > whether there is no distance vector with a distance on the last level > less than 4" is more meaningful. And: So why not have the caller examine the distance vectors? We don't need an additional API to ask this question. The analysis should just do the analysis, it doesn't need to know every possible use of the results. > - this can be proved far faster than generating the whole dependencies > (I have seen 50x speedup figures, but this is implementation dependent) Just to clarify, are you saying answering the "any distance < 4" question can be faster than generating all the distance vectors? Ok, yeah, I can believe that, so we probably do want an API for that. So ignore my previous paragraph. :) > - could be proved even in some cases where the Omega test cannot. Ok, I can believe that too. > So two questions: Is there any other kind of queries? Are they actually > useful? If we need more queries later we can always add them. The way I would approach this is to implement the basic API (yes/no/maybe and distance/direction vectors) and let clients use that information to derive their own answers. After some experience with that we'll have a better sense of what other APIs might be useful. Then we can start adding things like the "distance < N" query. > Now for the "useful" answers: We have to admit that the proportion of > loops whose upper bounds are known constant values at compile-time is > decreasing rapidly... Depends what you mean by "known" and "at compile time." It's not uncommon to generate conditional code where there are runtime checks for loop bounds and a selection among code generated with different parallelization strategies. So strictly speaking the loop bounds are not statically known but the compiler makes them known to itself for special cases by inserting runtime tests. The compiler can also use symbol information to infer minimum and maximum bounds. For example, it's reasonable to assume a loop won't iterate beyond the bounds of the arrays used in the loop, so if you have symbol information you can figure more things out than what you'd get from simply examining the code. Range analysis can also play a role here. > Some analysis handle that well at the cost of potentially generating > different results predicated by conditions on these symbolic values. You read my mind. :) Though what do you mean by "different results" here? Different code? I hope you don't mean "different answers." :) > The expression of these predicates might not be trivial. Funny story, I've seen literally PAGES of scalar code that attempts to figure out whether vectorization applies at runtime and then selects the vector code if it does. Usually vectorization applies and the vector code is so fast it more than makes up for the additional computation involved in the checks. > This is what I had in mind when I talked above the difficulty of having > a good API that do not change every time a new analysis is added. I > doubt this API could be defined without the review of analysis users and > writers. But ultimately these "tricks" such as runtime decision-making are not under the purvue of the memory dependence analysis. In these cases the compiler is "forcing" an answer it wants by create code paths where it knows certain properties. There's no analysis necessary because the compiler created those paths in the first place with very specific goals in mind. I think the interface you've outlined above is sufficient for now. We'll gain experience and add to it later if necessary. > Now about the chaining: it is a matter of precision. We want either the > exact result or, when it is not possible, we might want the most precise > conservative answer [when we want to know more than yes/no/maybe]. Right. > The solution, as you describe it, is ok as long as one can provide an > exact result. However, when no test can: > - You may have obtained an exact result by making them work together > rather than independently. Possibly, though I don't have a good picture of what "work together" looks like. When I think about alias analysis, for example, I think of cheaper analyses chaining to more expensive ones. The more expensive ones subsume the functionality of the cheaper ones. This property may not always hold for memory dependence analysis. But in those cases, is it really possible to combine results and come up with something more precise? I don't know. Again, I think it's reasonable to start with a model based on how alias analysis works and then enhance the model if we find cases where this kind of interaction is beneficial. The key is not to make the perfect the enemy of the good. Get something going now. We can always make it better later. > - What conservative answer to provide when each test failed, but > different conservative answers are provided from more than two tests? I would think most of the time it would be pretty clear (you want to take the greatest distance, for example). For those cases where it's not clear, just pick one for now. We'll gain experience and tune it later. -Dave From dag at cray.com Wed Sep 3 15:14:08 2008 From: dag at cray.com (David Greene) Date: Wed, 3 Sep 2008 15:14:08 -0500 Subject: [LLVMdev] Instruction MVT::ValueTypes In-Reply-To: <8113A778-EE02-4D7C-A920-EC97B6471004@apple.com> References: <200809021242.41080.dag@cray.com> <8113A778-EE02-4D7C-A920-EC97B6471004@apple.com> Message-ID: <200809031514.09156.dag@cray.com> On Tuesday 02 September 2008 16:47, Evan Cheng wrote: > On Sep 2, 2008, at 10:42 AM, David Greene wrote: > > Is there an easy way to get the MVT::ValueType of a MachineInstruction > > MachineOperand? For example, the register operand of an x86 MOVAPD > > should > > have an MVT::ValueType of v2f64. A MOVAPS register operand should > > have an > > MVT::ValueType of v4f32. > > The short answer is no. A op of a number of different VTs can map to > the same instruction. In general, that may be true, but for most instructions isn't it 1:1? What are some examples where it isn't 1:1? The vector processor needs to know how the data in the register is organized to compute the operation, after all. Thinking about MOVAPS / MOVAPD I suppose one could argue that it's perfectly legal to do a MOVAPD on a vector register that contains 8-bit data. It's just bits, after all, but there is a "preference" to what should be in the register for performance reasons. It's not good to mix-and-match MOVAPD and MOVAPS on the same data. > However, given a register class you can get to > the list of VTs that map to it. Take a look at TargetRegisterDesc. Tha'ts usually not enough. For example, in an SSE operand you want to know the type of data contained in it (32-bit [or less] or 64-bit) to generate optimal code. Just knowing that it's a 128-bit vector register that can hold 8-, 16-, 32- or 64-bit data is not enough. Getting this information into the TargetInstrInfo / TargetOperandInfo would take a fair amount of TableGen and .td file hacking, I would think. Right? -Dave From andrewl at lenharth.org Wed Sep 3 15:20:44 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Wed, 3 Sep 2008 13:20:44 -0700 Subject: [LLVMdev] Merge-Cha-Cha In-Reply-To: References: <16e5fdf90809021722n167528f1je08cabeddb6bab5f@mail.gmail.com> Message-ID: <85dfcd7f0809031320x430a1c04h737c29b74a897b54@mail.gmail.com> On Tue, Sep 2, 2008 at 8:21 PM, John Regehr wrote: > I'm getting the error below on Ubuntu Hardy on ia32 on r55688. I'm getting this too on Redhat. The problem is TARGET_MACHO is defined. The error is in an #ifdef TARGET_MACHO block. I didn't find where TARGET_MACHO was being defined though. Andrew > > John > > make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' > gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute > -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include > -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber > -I../libdecnumber -I/home/regehr/llvm/include -I/home/regehr/llvm/include > -DENABLE_LLVM -I/home/regehr/llvm/include -D_DEBUG -D_GNU_SOURCE > -D__STDC_LIMIT_MACROS ../../gcc/postreload-gcse.c -o postreload-gcse.o > ../../gcc/postreload-gcse.c: In function > eliminate_partially_redundant_load: > ../../gcc/postreload-gcse.c:1123: error: > flag_darwin_rtl_pre_ignore_critical_edges undeclared (first use in this > function) > ../../gcc/postreload-gcse.c:1123: error: (Each undeclared identifier is > reported only once > ../../gcc/postreload-gcse.c:1123: error: for each function it appears in.) > make[3]: *** [postreload-gcse.o] Error 1 > make[3]: Leaving directory `/home/regehr/llvm-gcc/build/gcc' > make[2]: *** [all-stage1-gcc] Error 2 > make[2]: Leaving directory `/home/regehr/llvm-gcc/build' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/home/regehr/llvm-gcc/build' > make: *** [all] Error 2 > regehr at john-home:~/llvm-gcc/build$ > > > -- > John Regehr, regehr at cs.utah.edu > Assistant Professor, School of Computing, University of Utah > http://www.cs.utah.edu/~regehr/ > > On Tue, 2 Sep 2008, Bill Wendling wrote: > >> As you all have undoubtedly noticed, I recently did Yet Another Merge >> to Apple's GCC top-of-tree. This merge was prompted by several >> important fixes in the "blocks" implementation. There are still many >> testcases that need to be moved over, but those can come at our >> leisure. I compiled both the "Apple way" and the "FSF way". It also >> passed the tests in llvm-test/Multitest. It should be a good merge, >> but let me know if things break for you. >> >> -bw >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From andrewl at lenharth.org Wed Sep 3 15:23:11 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Wed, 3 Sep 2008 13:23:11 -0700 Subject: [LLVMdev] New llvm-gcc bootstrap failure In-Reply-To: References: <200807232023.17401.baldrick@free.fr> <38a0d8450808221048k51f796aen52808ce106d82f50@mail.gmail.com> <38a0d8450808250204x56fe7f9cm6f7adfcfece8f75d@mail.gmail.com> Message-ID: <85dfcd7f0809031323u5121285dj70e29b668998c856@mail.gmail.com> On Tue, Sep 2, 2008 at 12:08 PM, John Regehr wrote: > I get the error below (and have for a couple weeks now) when trying to > build llvm-gcc on Ubuntu Feisty. In the meantime, on Ubuntu Gutsy, > everything has been building fine. Both are release builds for x86. I've seen this error too with gcc version 4.1.2 20070626 (Red Hat 4.1.2-14). I do not see it with gcc version 3.4.6 20060404 (Red Hat 3.4.6-9). Also, if you use the Debug build (--enable-checking does not currently select the LLVM debug build to link into llvm-gcc, so you have to set this manually), I do not see the error, only the Release build. valgrind seems clean on the Release build. Andrew > > John > > > cc1: StringMap.cpp:177: void > llvm::StringMapImpl::RemoveKey(llvm::StringMapEntryBase*): Assertion `V == > V2 && "Didn't find key?"' failed. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From regehr at cs.utah.edu Wed Sep 3 15:27:48 2008 From: regehr at cs.utah.edu (John Regehr) Date: Wed, 3 Sep 2008 14:27:48 -0600 (MDT) Subject: [LLVMdev] New llvm-gcc bootstrap failure In-Reply-To: <85dfcd7f0809031323u5121285dj70e29b668998c856@mail.gmail.com> References: <200807232023.17401.baldrick@free.fr> <38a0d8450808221048k51f796aen52808ce106d82f50@mail.gmail.com> <38a0d8450808250204x56fe7f9cm6f7adfcfece8f75d@mail.gmail.com> <85dfcd7f0809031323u5121285dj70e29b668998c856@mail.gmail.com> Message-ID: > I've seen this error too with gcc version 4.1.2 20070626 (Red Hat 4.1.2-14). > I do not see it with gcc version 3.4.6 20060404 (Red Hat 3.4.6-9). Right-- Ubuntu Feisty also uses 4.1.2, and fails to build LLVM. The newer Ubuntu uses 4.2.something and compiles LLVM cleanly. John From vadve at cs.uiuc.edu Wed Sep 3 15:29:16 2008 From: vadve at cs.uiuc.edu (Vikram S. Adve) Date: Wed, 3 Sep 2008 15:29:16 -0500 Subject: [LLVMdev] Dependence Analysis [was: Flow-Sensitive AA] In-Reply-To: <200809031506.46603.dag@cray.com> References: <200808181719.11656.dag@cray.com> <200809031050.31784.dag@cray.com> <1220463590.12291.88.camel@matthieu-laptop> <200809031506.46603.dag@cray.com> Message-ID: David, I agree with all of what you said here except for one point: On Sep 3, 2008, at 3:06 PM, David Greene wrote: >> >> This is what I had in mind when I talked above the difficulty of >> having >> a good API that do not change every time a new analysis is added. I >> doubt this API could be defined without the review of analysis >> users and >> writers. > > But ultimately these "tricks" such as runtime decision-making are > not under > the purvue of the memory dependence analysis. In these cases the > compiler is > "forcing" an answer it wants by create code paths where it knows > certain > properties. There's no analysis necessary because the compiler > created those > paths in the first place with very specific goals in mind. That may not be the case because the compiler may need dependence "breaking conditions" to generate this code. For example, such a condition might say [a particular instruction pair does not have a dependence if] "N > sizeof(A)" or "i + j < 10". The dependence *test* usually has to generate this condition, e.g., polyhedral analyses like Omega can do this. The same functionality could also be useful for interactive porting tools helping users port programs to a parallel language, one of the target projects for the dependence analyzer here at Illinois. Having said that ... > I think the > interface you've outlined above is sufficient for now. We'll gain > experience > and add to it later if necessary. ... I agree: let's do the basic Yes/No/Maybe and Direction/Distance vectors for now, and add more sophisticated queries as clients emerge for them. --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve From gohman at apple.com Wed Sep 3 15:42:33 2008 From: gohman at apple.com (Dan Gohman) Date: Wed, 3 Sep 2008 13:42:33 -0700 Subject: [LLVMdev] Instruction MVT::ValueTypes In-Reply-To: <200809031514.09156.dag@cray.com> References: <200809021242.41080.dag@cray.com> <8113A778-EE02-4D7C-A920-EC97B6471004@apple.com> <200809031514.09156.dag@cray.com> Message-ID: <3250CC8D-A534-46F8-A94C-D5ADD12910CB@apple.com> On Sep 3, 2008, at 1:14 PM, David Greene wrote: > On Tuesday 02 September 2008 16:47, Evan Cheng wrote: >> On Sep 2, 2008, at 10:42 AM, David Greene wrote: >>> Is there an easy way to get the MVT::ValueType of a >>> MachineInstruction >>> MachineOperand? For example, the register operand of an x86 MOVAPD >>> should >>> have an MVT::ValueType of v2f64. A MOVAPS register operand should >>> have an >>> MVT::ValueType of v4f32. >> >> The short answer is no. A op of a number of different VTs can map to >> the same instruction. > > In general, that may be true, but for most instructions isn't it > 1:1? What > are some examples where it isn't 1:1? The vector processor needs to > know how the data in the register is organized to compute the > operation, after > all. > > Thinking about MOVAPS / MOVAPD I suppose one could argue that it's > perfectly legal to do a MOVAPD on a vector register that contains 8- > bit data. > It's just bits, after all, but there is a "preference" to what > should be in > the register for performance reasons. It's not good to mix-and- > match MOVAPD > and MOVAPS on the same data. For the case of MOVAPS vs. MOVAPD vs. MOVDQU (assuming you have a micro-architecture where there's actually a difference), this can be achieved by having instruction selection select the right instructions. For example, find code like this in X86InstrSSE.td: def : Pat<(alignedloadv2i64 addr:$src), (MOVAPSrm addr:$src)>, Requires<[HasSSE2]>; def : Pat<(loadv2i64 addr:$src), (MOVUPSrm addr:$src)>, Requires<[HasSSE2]>; and change it to not select MOVAPS for that microarchitecture, for example. Dan From isanbard at gmail.com Wed Sep 3 15:58:20 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 3 Sep 2008 13:58:20 -0700 Subject: [LLVMdev] Merge-Cha-Cha In-Reply-To: References: <16e5fdf90809021722n167528f1je08cabeddb6bab5f@mail.gmail.com> Message-ID: <16e5fdf90809031358y3cc87c76q49202b0a7db7c1e@mail.gmail.com> On Tue, Sep 2, 2008 at 8:21 PM, John Regehr wrote: > I'm getting the error below on Ubuntu Hardy on ia32 on r55688. > ... > ../../gcc/postreload-gcse.c:1123: error: > flag_darwin_rtl_pre_ignore_critical_edges undeclared (first use in this > function) This is a Darwin-specific flag. I added a conditional to check for "CONFIG_DARWIN_H" before executing the code in question. Please check to see if it works for you. -bw From baldrick at free.fr Wed Sep 3 16:22:12 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 3 Sep 2008 23:22:12 +0200 Subject: [LLVMdev] Type Legalizer - Load handling problem In-Reply-To: <1220467186.2972.1.camel@idc-lt-i00171.microchip.com> References: <200809020925.38272.baldrick@free.fr> <1220467186.2972.1.camel@idc-lt-i00171.microchip.com> Message-ID: <200809032322.12832.baldrick@free.fr> > How do we access ReplaceNodeWith in TLI ? I hadn't understood you wanted to custom lower: I assumed you wanted to teach legalize types what to do if the pointer type is illegal, in the generic code. Indeed if you want to custom lower then there isn't much choice. Ciao, Duncan. From criswell at cs.uiuc.edu Wed Sep 3 17:12:32 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 03 Sep 2008 17:12:32 -0500 Subject: [LLVMdev] xcodebuild and LLVM Message-ID: <48BF0BD0.2070609@cs.uiuc.edu> Dear All, Is there a way to convince xcodebuild to build bitcode files for LLVM for an arbitrary Xcode project? So far, I've been able to get xcodebuild to use LLVM by installing XCode 3.1 and using CC="llvm-gcc" on the command line. I've also managed to get LLVM bitcode generates for intermediate files by using "CC="lvm-gcc -emit-llvm"; however, this gives an error during linking stating that ld does not understand the -emit-llvm option. Thanks in advance. -- John T. From kremenek at apple.com Wed Sep 3 17:19:21 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 3 Sep 2008 15:19:21 -0700 Subject: [LLVMdev] xcodebuild and LLVM In-Reply-To: <48BF0BD0.2070609@cs.uiuc.edu> References: <48BF0BD0.2070609@cs.uiuc.edu> Message-ID: On Sep 3, 2008, at 3:12 PM, John Criswell wrote: > Dear All, > > Is there a way to convince xcodebuild to build bitcode files for LLVM > for an arbitrary Xcode project? So far, I've been able to get > xcodebuild to use LLVM by installing XCode 3.1 and using CC="llvm-gcc" > on the command line. I've also managed to get LLVM bitcode generates > for intermediate files by using "CC="lvm-gcc -emit-llvm"; however, > this > gives an error during linking stating that ld does not understand the > -emit-llvm option. > > Thanks in advance. > > -- John T. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev In addition to specifying CC, xcodebuild also consults the environment variables LD and LDPLUSPLUS for your linker commands (for C and C++ sources respectively). I would try LD=llvm-gcc and LDPLUSPLUS=llvm-g+ + respectively. From belayda at gmail.com Wed Sep 3 17:51:00 2008 From: belayda at gmail.com (Bernardo Elayda) Date: Wed, 3 Sep 2008 15:51:00 -0700 Subject: [LLVMdev] VMware LLVM 2.3 appliance update Message-ID: <3e5ed32f0809031551u46fdebc9n9b87e88230f43c5f@mail.gmail.com> Thanks Overmind! I had forgotten about the VMware Appliance Page, which has an area for 'community' appliances. I'll work on getting it there. I'll post here again when the appliance is available. regards, Bernardo >As long as it does not exceed a terabyte or 1.5tb or so of download >bandwidth a month, I could host it without issue. Probably something >relating directly to the LLVM servers would be best, or perhaps the >VMWare appliances page? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080903/afa60e10/attachment-0001.html From regehr at cs.utah.edu Wed Sep 3 18:41:13 2008 From: regehr at cs.utah.edu (John Regehr) Date: Wed, 3 Sep 2008 17:41:13 -0600 (MDT) Subject: [LLVMdev] Merge-Cha-Cha In-Reply-To: <16e5fdf90809031358y3cc87c76q49202b0a7db7c1e@mail.gmail.com> References: <16e5fdf90809021722n167528f1je08cabeddb6bab5f@mail.gmail.com> <16e5fdf90809031358y3cc87c76q49202b0a7db7c1e@mail.gmail.com> Message-ID: > to see if it works for you. Works. John From mrs at apple.com Wed Sep 3 19:58:18 2008 From: mrs at apple.com (Mike Stump) Date: Wed, 3 Sep 2008 17:58:18 -0700 Subject: [LLVMdev] xcodebuild and LLVM In-Reply-To: <48BF0BD0.2070609@cs.uiuc.edu> References: <48BF0BD0.2070609@cs.uiuc.edu> Message-ID: <04A2A6E0-8CCA-4441-A462-A7BD4B660A19@apple.com> On Sep 3, 2008, at 3:12 PM, John Criswell wrote: > Is there a way to convince xcodebuild to build bitcode files for LLVM > for an arbitrary Xcode project? So far, I've been able to get > xcodebuild to use LLVM by installing XCode 3.1 and using CC="llvm-gcc" > on the command line. I've also managed to get LLVM bitcode generates > for intermediate files by using "CC="lvm-gcc -emit-llvm"; however, > this > gives an error during linking stating that ld does not understand the > -emit-llvm option. In the LINK_SPEC just add %{emit-llvm: } before %{e*} or, if that doesn't work, try % Hi All, I've started using llvm recently, and liking it. To get myself started with LLVM development, I'm think of implementing escape analysis for llvm. Could you please give me some pointers related to it , so as to start off the work ? or anything specific in your mind about it, so as to handle bigger issues related to LLVM. Thanks & Regards, Pramod Bhatotia. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080904/57281712/attachment.html From evan.cheng at apple.com Thu Sep 4 00:44:35 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 3 Sep 2008 22:44:35 -0700 Subject: [LLVMdev] Codegen/Register allocation question. In-Reply-To: <728927c70809030558h7e153e4o304dfe6e3d003bca@mail.gmail.com> References: <728927c70809030558h7e153e4o304dfe6e3d003bca@mail.gmail.com> Message-ID: On Sep 3, 2008, at 5:58 AM, Lang Hames wrote: > Hi LLVMers, > > I have finally sorted out licensing issues and found some time, so I'm > trying to port my PBQP register allocator to 2.4 in order to Nice! We would definitely welcome your contribution. > > contribute it (if you want it). I've run into a bug that has me > confused though. > > I'm currently failing the following assertion: > > llc: VirtRegMap.cpp:1733: > void::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&, > llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' failed. > > > when attempting to allocate this machine function: > > entry: > 4 %reg1024 = MOV32rr %EDI > 12 %reg1025 = MOV64rr %RSI > 20 ADJCALLSTACKDOWN 0, %ESP, %EFLAGS, > %ESP > 28 %reg1026 = MOV8ri 4 > 36 %reg1027 = FsFLD0SD > 44 %reg1028 = LEA64r %reg0, 1, %reg0, > 52 %RDI = MOV64rr %reg1028 > 60 %XMM0 = FsMOVAPDrr %reg1027 > 68 %XMM1 = FsMOVAPDrr %reg1027 > 76 %XMM2 = FsMOVAPDrr %reg1027 > 84 %XMM3 = FsMOVAPDrr %reg1027 > 92 %AL = MOV8rr %reg1026 > 100 CALL64pcrel32 , %RDI, %XMM0, > %XMM1, %XMM2, %XMM3, %AL, %RAX, > %RCX, %RDX, %RSI, > %RDI, %R8, %R9, > %R10, %R11, %FP0, > %FP1, %FP2, %FP3, > %FP4, %FP5, %FP6, > %ST0, %ST1, %MM0, > %MM1, %MM2, %MM3, > %MM4, %MM5, %MM6, > %MM7, %XMM0, %XMM1, > %XMM2, %XMM3, %XMM4, > %XMM5, %XMM6, %XMM7, > %XMM8, %XMM9, %XMM10, > %XMM11, %XMM12, %XMM13, > %XMM14, %XMM15, %EFLAGS, > %EAX, %ECX, %EDI, > %EDX, %ESI > 108 ADJCALLSTACKUP 0, 0, %ESP, %EFLAGS, > %ESP > 116 %reg1029 = MOV32rr %EAX, %RAX > 124 %reg1030 = MOV32r0 %EFLAGS > 132 %EAX = MOV32rr %reg1030 > 140 RET %EAX, %AX > > > ********** REGISTER MAP ********** > [reg1024 -> EAX] > [reg1025 -> R10] > [reg1026 -> AH] > [reg1027 -> XMM10] > [reg1028 -> R10] > [reg1029 -> EAX] > [reg1030 -> EAX] > > > The failure occurs when the spiller tries to eliminate the assignment > > 116 %reg1029 = MOV32rr %EAX, %RAX > > after reg1029 is assigned EAX. It occurs because EAX isn't listed as > killed, so InvalidateKills doesn't return it in KillRegs (but does > return RAX). > > Is this a bug (was EAX supposed to be marked killed?), or was the > register allocator supposed to mark EAX as killed? (doesn't seem as if > it should - it was killed before regalloc got involved). > Or have I missed something else? It's a bug. The assertion is too strict. I've fixed it. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080901/066733.html Evan > > > bugpoint produced bytecode is attached, but I don't suppose it's much > help without the allocator. That's packaged as an LLVM project at the > moment - so if it'll help you debug I can send you a copy. > > Cheers, > Lang. > > > > > --------- Bugpoint reduced bytecode from > SingleSource/Vector/Output/build.llvm.bc --------- > > ; ModuleID = 'bugpoint-reduced-simplified.bc' > target datalayout = > "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32- > f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128" > target triple = "x86_64-pc-linux-gnu" > @.str1 = external constant [13 x i8] ; <[13 x i8]*> > [#uses=1] > > declare i32 @printf(i8* noalias, ...) nounwind > > define i32 @main(i32 %argc, i8** %Argv) nounwind { > entry: > %tmp25.i14 = call i32 (i8*, ...)* @printf( i8* noalias > getelementptr ([13 x i8]* @.str1, i32 0, i64 0), double 0.000000e+00, > double 0.000000e+00, double 0.000000e+00, double 0.000000e+00 ) > nounwind ; [#uses=0] > ret i32 0 > } > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Thu Sep 4 01:16:44 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 3 Sep 2008 23:16:44 -0700 Subject: [LLVMdev] Instruction MVT::ValueTypes In-Reply-To: <200809031514.09156.dag@cray.com> References: <200809021242.41080.dag@cray.com> <8113A778-EE02-4D7C-A920-EC97B6471004@apple.com> <200809031514.09156.dag@cray.com> Message-ID: <5DFFC9D7-6865-4D0A-826F-370F4BC3A8BF@apple.com> On Sep 3, 2008, at 1:14 PM, David Greene wrote: > On Tuesday 02 September 2008 16:47, Evan Cheng wrote: >> On Sep 2, 2008, at 10:42 AM, David Greene wrote: >>> Is there an easy way to get the MVT::ValueType of a >>> MachineInstruction >>> MachineOperand? For example, the register operand of an x86 MOVAPD >>> should >>> have an MVT::ValueType of v2f64. A MOVAPS register operand should >>> have an >>> MVT::ValueType of v4f32. >> >> The short answer is no. A op of a number of different VTs can map to >> the same instruction. > > In general, that may be true, but for most instructions isn't it > 1:1? What > are some examples where it isn't 1:1? The vector processor needs to > know how the data in the register is organized to compute the > operation, after > all. What about bitcast'ed values? Or i1 value zero-extended and stored in i8 register? > > > Thinking about MOVAPS / MOVAPD I suppose one could argue that it's > perfectly legal to do a MOVAPD on a vector register that contains 8- > bit data. > It's just bits, after all, but there is a "preference" to what > should be in > the register for performance reasons. It's not good to mix-and- > match MOVAPD > and MOVAPS on the same data. That's not really true in many cases. On x86, sometimes many opcodes do the same thing. We often use the shortest one. Domain crossing penalty doesn't really matter in newer x86 implementations. Besides that's just an optimization, it's not an correctness issue. > > >> However, given a register class you can get to >> the list of VTs that map to it. Take a look at TargetRegisterDesc. > > Tha'ts usually not enough. For example, in an SSE operand you want > to know > the type of data contained in it (32-bit [or less] or 64-bit) to > generate > optimal code. Just knowing that it's a 128-bit vector register that > can hold > 8-, 16-, 32- or 64-bit data is not enough. Another question to ask is... What are you trying to achieve? What crazy ideas do you have? Evan > > > Getting this information into the TargetInstrInfo / > TargetOperandInfo would > take a fair amount of TableGen and .td file hacking, I would think. > Right? > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From isanbard at gmail.com Thu Sep 4 04:55:11 2008 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 4 Sep 2008 02:55:11 -0700 Subject: [LLVMdev] Codegen/Register allocation question. In-Reply-To: References: <728927c70809030558h7e153e4o304dfe6e3d003bca@mail.gmail.com> Message-ID: <2D63C4F5-8A7C-46FC-AEB8-FA49D2E778A9@gmail.com> On Sep 3, 2008, at 10:44 PM, Evan Cheng wrote: > On Sep 3, 2008, at 5:58 AM, Lang Hames wrote: > >> Hi LLVMers, >> >> I have finally sorted out licensing issues and found some time, so >> I'm >> trying to port my PBQP register allocator to 2.4 in order to > > Nice! We would definitely welcome your contribution. > We certainly do! :-) One word of advice, if you're working to get your code accepted into the mainline, you'll want to start using the SVN top-of-tree soon. We don't back port fixes to previous releases (because our release cycle is short), so you won't necessarily get Evan's fix below. Cheers! -bw >> >> contribute it (if you want it). I've run into a bug that has me >> confused though. >> >> I'm currently failing the following assertion: >> >> llc: VirtRegMap.cpp:1733: >> void::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&, >> llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' failed. > >> >> >> when attempting to allocate this machine function: >> >> entry: >> 4 %reg1024 = MOV32rr %EDI >> 12 %reg1025 = MOV64rr %RSI >> 20 ADJCALLSTACKDOWN 0, %ESP, %EFLAGS, >> %ESP >> 28 %reg1026 = MOV8ri 4 >> 36 %reg1027 = FsFLD0SD >> 44 %reg1028 = LEA64r %reg0, 1, %reg0, >> 52 %RDI = MOV64rr %reg1028 >> 60 %XMM0 = FsMOVAPDrr %reg1027 >> 68 %XMM1 = FsMOVAPDrr %reg1027 >> 76 %XMM2 = FsMOVAPDrr %reg1027 >> 84 %XMM3 = FsMOVAPDrr %reg1027 >> 92 %AL = MOV8rr %reg1026 >> 100 CALL64pcrel32 , %RDI, %XMM0, >> %XMM1, %XMM2, %XMM3, %AL, %RAX, >> %RCX, %RDX, %RSI, >> %RDI, %R8, %R9, >> %R10, %R11, %FP0, >> %FP1, %FP2, %FP3, >> %FP4, %FP5, %FP6, >> %ST0, %ST1, %MM0, >> %MM1, %MM2, %MM3, >> %MM4, %MM5, %MM6, >> %MM7, %XMM0, %XMM1, >> %XMM2, %XMM3, %XMM4, >> %XMM5, %XMM6, %XMM7, >> %XMM8, %XMM9, %XMM10, >> %XMM11, %XMM12, %XMM13, >> %XMM14, %XMM15, %EFLAGS, >> %EAX, %ECX, %EDI, >> %EDX, %ESI >> 108 ADJCALLSTACKUP 0, 0, %ESP, %EFLAGS, >> %ESP >> 116 %reg1029 = MOV32rr %EAX, %RAX >> 124 %reg1030 = MOV32r0 %EFLAGS >> 132 %EAX = MOV32rr %reg1030 >> 140 RET %EAX, %AX >> >> >> ********** REGISTER MAP ********** >> [reg1024 -> EAX] >> [reg1025 -> R10] >> [reg1026 -> AH] >> [reg1027 -> XMM10] >> [reg1028 -> R10] >> [reg1029 -> EAX] >> [reg1030 -> EAX] >> >> >> The failure occurs when the spiller tries to eliminate the assignment >> >> 116 %reg1029 = MOV32rr %EAX, %RAX >> >> after reg1029 is assigned EAX. It occurs because EAX isn't listed as >> killed, so InvalidateKills doesn't return it in KillRegs (but does >> return RAX). >> >> Is this a bug (was EAX supposed to be marked killed?), or was the >> register allocator supposed to mark EAX as killed? (doesn't seem as >> if >> it should - it was killed before regalloc got involved). >> Or have I missed something else? > > It's a bug. The assertion is too strict. I've fixed it. > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080901/066733.html > > Evan > >> >> >> bugpoint produced bytecode is attached, but I don't suppose it's much >> help without the allocator. That's packaged as an LLVM project at the >> moment - so if it'll help you debug I can send you a copy. >> >> Cheers, >> Lang. >> >> >> >> >> --------- Bugpoint reduced bytecode from >> SingleSource/Vector/Output/build.llvm.bc --------- >> >> ; ModuleID = 'bugpoint-reduced-simplified.bc' >> target datalayout = >> "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32- >> f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128" >> target triple = "x86_64-pc-linux-gnu" >> @.str1 = external constant [13 x i8] ; <[13 x i8]*> >> [#uses=1] >> >> declare i32 @printf(i8* noalias, ...) nounwind >> >> define i32 @main(i32 %argc, i8** %Argv) nounwind { >> entry: >> %tmp25.i14 = call i32 (i8*, ...)* @printf( i8* noalias >> getelementptr ([13 x i8]* @.str1, i32 0, i64 0), double 0.000000e+00, >> double 0.000000e+00, double 0.000000e+00, double 0.000000e+00 ) >> nounwind ; [#uses=0] >> ret i32 0 >> } >> _______________________________________________ >> 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 lhames at gmail.com Thu Sep 4 06:20:24 2008 From: lhames at gmail.com (Lang Hames) Date: Thu, 4 Sep 2008 21:20:24 +1000 Subject: [LLVMdev] Register allocation problems with TLS unit test. Message-ID: <728927c70809040420t344e1d3ay21adee2caadf50d5@mail.gmail.com> Running the SingleSource tests with llc while debugging my PBQP allocator I noticed that test-suite/SingleSource/UnitTests/Threads/tls.c has some issues with register allocators other than linear scan: Local, simple & bigblock regalloc all cause the following ld assertion failures: bash-3.2$ gcc tls.foo.s -o tls.foo.debug -lm -lpthread /usr/bin/ld: BFD version 2.17.50.0.18-1 20070731 assertion fail ../../bfd/elf64-x86-64.c:2561 /usr/bin/ld: BFD version 2.17.50.0.18-1 20070731 assertion fail ../../bfd/elf64-x86-64.c:2566 /usr/bin/ld: BFD version 2.17.50.0.18-1 20070731 assertion fail ../../bfd/elf64-x86-64.c:2568 The resulting code segfaults on execution. I haven't figured out exactly why yet. Will post more details when I figure them out. If it helps my system is an AMD64 running Ubuntu and LLVM SVN. Cheers, Lang. From asl at math.spbu.ru Thu Sep 4 07:00:22 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 4 Sep 2008 16:00:22 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?UmVnaXN0ZXIgYWxsb2NhdGlvbiBwcm9ibGVtcyB3aXRo?= =?koi8-r?b?IFRMUyB1bml0IHRlc3Qu?= Message-ID: <200809041200.m84C0MdY024189@star.math.spbu.ru> Hello, Lang > The resulting code segfaults on execution. I haven't figured out > exactly why yet. Will post more details when I figure them out. As far as I remember, it was a bug in binutils, which is workaround'ed in gcc, but triggered with LLVM-generated code. I don't remember much details, but I believe there was a binutils PR for this. -- WBR, Anton Korobeynikov From st at iss.tu-darmstadt.de Thu Sep 4 07:07:24 2008 From: st at iss.tu-darmstadt.de (ST) Date: Thu, 4 Sep 2008 14:07:24 +0200 Subject: [LLVMdev] LLVM FPGA interface. In-Reply-To: <3efa6bfc0809030735n1d94ef82o8b39e2f3a4eb8b94@mail.gmail.com> References: <3efa6bfc0809030735n1d94ef82o8b39e2f3a4eb8b94@mail.gmail.com> Message-ID: <200809041407.24928.st@iss.tu-darmstadt.de> Hi > I am naive to LLVM environment, my focus is to generate LLVM inermediate > code for FPGA. Are there any resources/links/papers/documents which > discusses LLVM intermediate generation for FPGA needs. I think you are talking about ESL tools? http://www.xilinx.com/products/design_tools/logic_design/advanced/esl/index.htm Trident compiler http://trident.sourceforge.net/ COMRADE http://www.esa.informatik.tu-darmstadt.de/twiki/bin/view/Research/WebHomeDe.html > I am aware with Xilinx "CHiMPS" interface for FPGA but probably CHiMPS > doesn't have any freely available eval version of CHiMPS to try with > LLVM for study purposes. Would you mind detailing what you are trying to archive? ST From zhousheng00 at gmail.com Thu Sep 4 10:31:44 2008 From: zhousheng00 at gmail.com (Zhou Sheng) Date: Thu, 4 Sep 2008 23:31:44 +0800 Subject: [LLVMdev] A simple case about SDiv Message-ID: <8abe0dc60809040831u43b19308rfa96d031ecdead39@mail.gmail.com> Hi, I have a simple C case as following: int test(int x, int y) { return -x / -y; } With llvm-gcc -O1, I got: define i32 @test(i32 %x, i32 %y) nounwind { entry: sub i32 0, %x ; :0 [#uses=1] sub i32 0, %y ; :1 [#uses=1] sdiv i32 %0, %1 ; :2 [#uses=1] ret i32 %2 } With llvm-gcc -O2, I got: define i32 @test(i32 %x, i32 %y) nounwind { entry: sdiv i32 %x, %y ; :0 [#uses=1] ret i32 %0 } I wonder which pass does this transform. I tried several passes, like -instcombine, -simplifycfg, -gcse -globaldce -globalopt -adce , but all failed to do this transform. Anybody know this? Thanks. Sheng. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080904/e0428101/attachment.html From nunoplopes at sapo.pt Thu Sep 4 10:39:36 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Thu, 4 Sep 2008 16:39:36 +0100 Subject: [LLVMdev] missed optimizations Message-ID: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> Hi, I have two questions about optimizations performed by llvm. Consider these simple functions: int x(int b) { return b?4:6; } int y() { return x(0); } int x2() { return 5; } int y2() { return x2(); } the optimized bitcode (with clang + opt -std-compiler-opts) is: define i32 @y(...) nounwind { entry: ret i32 6 } define i32 @y2(...) nounwind { entry: %call = call i32 (...)* @x2( ) ; [#uses=0] ret i32 5 } So why does LLVM optimizes the more difficult case, but leaves behind the function call in the easiest case? :) Second question: int f(); int g() { if (f() == 5) return 3; return 4; } int h() { if (g() == 6) return 2; return 1; } gives the following optimized bc: define i32 @g(...) nounwind { entry: %call = call i32 (...)* @f( ) ; [#uses=1] %cmp = icmp eq i32 %call, 5 ; [#uses=1] %retval = select i1 %cmp, i32 3, i32 4 ; [#uses=1] ret i32 %retval } define i32 @h(...) nounwind { entry: %call = call i32 (...)* @g( ) ; [#uses=1] %cmp = icmp eq i32 %call, 6 ; [#uses=1] %retval = select i1 %cmp, i32 2, i32 1 ; [#uses=1] ret i32 %retval } In function h(), llvm doesn't realize that g() never returns 6, and thus it could reduce that function to { g(); return 1; }. Doesn't llvm produce some sort of summary for functions with e.g. their possible return values? If not, is there any pass where I could implement this? (I have some code that has many opportunities for this kind of optimization) Also, shouldn't the function g() get inlined in the h() function? It is inlined only if I change the g() function to be static. So isn't llvm being too conservative when inlining global functions? Thanks, Nuno From baldrick at free.fr Thu Sep 4 10:56:16 2008 From: baldrick at free.fr (Duncan Sands) Date: Thu, 4 Sep 2008 17:56:16 +0200 Subject: [LLVMdev] A simple case about SDiv In-Reply-To: <8abe0dc60809040831u43b19308rfa96d031ecdead39@mail.gmail.com> References: <8abe0dc60809040831u43b19308rfa96d031ecdead39@mail.gmail.com> Message-ID: <200809041756.17474.baldrick@free.fr> > I tried several passes, like -instcombine, -simplifycfg, -gcse -globaldce > -globalopt -adce , but all failed to do this transform. Try "opt -std-compile-opts -debug-pass=Arguments" If that does the simplification, then try bisecting the set of passes it ran (printed thanks to -debug-pass) to find out which combination did it. Ciao, Duncan. From zhousheng00 at gmail.com Thu Sep 4 11:08:23 2008 From: zhousheng00 at gmail.com (Zhou Sheng) Date: Fri, 5 Sep 2008 00:08:23 +0800 Subject: [LLVMdev] A simple case about SDiv In-Reply-To: <200809041756.17474.baldrick@free.fr> References: <8abe0dc60809040831u43b19308rfa96d031ecdead39@mail.gmail.com> <200809041756.17474.baldrick@free.fr> Message-ID: <8abe0dc60809040908p784d81c7o232d26fb086a6bbf@mail.gmail.com> Hi Duncan, Thanks for your help. But seems "opt -std-compile-opts" can't do this simplication :( Any ideas? Sheng. 2008/9/4 Duncan Sands > > I tried several passes, like -instcombine, -simplifycfg, -gcse -globaldce > > -globalopt -adce , but all failed to do this transform. > > Try "opt -std-compile-opts -debug-pass=Arguments" > If that does the simplification, then try bisecting > the set of passes it ran (printed thanks to -debug-pass) > to find out which combination did it. > > Ciao, > > Duncan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080905/24bb3f6b/attachment.html From cedric.venet at laposte.net Thu Sep 4 11:19:46 2008 From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=) Date: Thu, 04 Sep 2008 18:19:46 +0200 Subject: [LLVMdev] missed optimizations In-Reply-To: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> References: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> Message-ID: <48C00AA2.4010509@laposte.net> Nuno Lopes a ?crit : > Hi, > > I have two questions about optimizations performed by llvm. > > Consider these simple functions: > int x(int b) { return b?4:6; } > int y() { return x(0); } > > int x2() { return 5; } > int y2() { return x2(); } > > the optimized bitcode (with clang + opt -std-compiler-opts) is: > define i32 @y(...) nounwind { > entry: > ret i32 6 > } > > define i32 @y2(...) nounwind { > entry: > %call = call i32 (...)* @x2( ) ; [#uses=0] > ret i32 5 > } > > So why does LLVM optimizes the more difficult case, but leaves behind the > function call in the easiest case? :) > I don't know why vararg would inhibit optimisation but maybe it is the problem. You should try with: int x2(void) { return 5; } int y2(void) { return x2(); } it may solve the problem (or use C++ as langage) C?dric From dpatel at apple.com Thu Sep 4 12:26:18 2008 From: dpatel at apple.com (Devang Patel) Date: Thu, 4 Sep 2008 10:26:18 -0700 Subject: [LLVMdev] xcodebuild and LLVM In-Reply-To: <04A2A6E0-8CCA-4441-A462-A7BD4B660A19@apple.com> References: <48BF0BD0.2070609@cs.uiuc.edu> <04A2A6E0-8CCA-4441-A462-A7BD4B660A19@apple.com> Message-ID: <41E2242F-83C0-429D-B3C3-6ABDE5108001@apple.com> On Sep 3, 2008, at 5:58 PM, Mike Stump wrote: > On Sep 3, 2008, at 3:12 PM, John Criswell wrote: >> Is there a way to convince xcodebuild to build bitcode files for LLVM >> for an arbitrary Xcode project? So far, I've been able to get >> xcodebuild to use LLVM by installing XCode 3.1 and using CC="llvm- >> gcc" >> on the command line. I've also managed to get LLVM bitcode generates >> for intermediate files by using "CC="lvm-gcc -emit-llvm"; however, >> this >> gives an error during linking stating that ld does not understand the >> -emit-llvm option. > > In the LINK_SPEC just add %{emit-llvm: } before %{e*} or, if that > doesn't work, try % References: <8abe0dc60809040831u43b19308rfa96d031ecdead39@mail.gmail.com> Message-ID: On Thu, Sep 4, 2008 at 8:31 AM, Zhou Sheng wrote: > Hi, > > I have a simple C case as following: > > int test(int x, int y) { > return -x / -y; > } > > With llvm-gcc -O1, I got: > > define i32 @test(i32 %x, i32 %y) nounwind { > entry: > sub i32 0, %x ; :0 [#uses=1] > sub i32 0, %y ; :1 [#uses=1] > sdiv i32 %0, %1 ; :2 [#uses=1] > ret i32 %2 > } > > With llvm-gcc -O2, I got: > > define i32 @test(i32 %x, i32 %y) nounwind { > entry: > sdiv i32 %x, %y ; :0 [#uses=1] > ret i32 %0 > } > > I wonder which pass does this transform. No LLVM pass can do this transform; it assumes that integer overflow is undefined, and the conversion to bitcode loses sign information. The optimization level is probably triggering the gcc's folder to be more aggressive. -Eli From regehr at cs.utah.edu Thu Sep 4 13:40:59 2008 From: regehr at cs.utah.edu (John Regehr) Date: Thu, 4 Sep 2008 12:40:59 -0600 (MDT) Subject: [LLVMdev] New llvm-gcc bootstrap failure In-Reply-To: References: <200807232023.17401.baldrick@free.fr> <38a0d8450808221048k51f796aen52808ce106d82f50@mail.gmail.com> <38a0d8450808250204x56fe7f9cm6f7adfcfece8f75d@mail.gmail.com> <85dfcd7f0809031323u5121285dj70e29b668998c856@mail.gmail.com> Message-ID: Just to confirm that gcc-4.1.2 is the problem (as opposed to libc or whatever) I can build a release version of llvm-gcc just fine on Ubuntu Feisty using gcc-4.3.2. So either some undefined behavior snuck into llvm that only manifests on this compiler, or else 4.1.2 is miscompiling something. John >> I've seen this error too with gcc version 4.1.2 20070626 (Red Hat 4.1.2-14). >> I do not see it with gcc version 3.4.6 20060404 (Red Hat 3.4.6-9). > > Right-- Ubuntu Feisty also uses 4.1.2, and fails to build LLVM. > > The newer Ubuntu uses 4.2.something and compiles LLVM cleanly. > > John > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From dag at cray.com Thu Sep 4 18:29:12 2008 From: dag at cray.com (David Greene) Date: Thu, 4 Sep 2008 18:29:12 -0500 Subject: [LLVMdev] Intel asm Message-ID: <200809041829.12406.dag@cray.com> I found a few fragments of threads in the internet ether where llvm folks talked about Intel vs. AT&T syntax. Apparently the project ran into trouble with name collisions when using Intel syntax (an example of a variable named "dword" was cited). I just tried dumping Intel syntax asm and assembling it with gas. It doesn't particularly like what llvm is putting out (comment delimeters are wrong, etc.). Is the Intel AsmPrinter meant to produce asm that is understood by gas or is it only meant to satisfy NASM, etc.? -Dave From overminddl1 at gmail.com Thu Sep 4 18:43:48 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Thu, 4 Sep 2008 17:43:48 -0600 Subject: [LLVMdev] missed optimizations In-Reply-To: <48C00AA2.4010509@laposte.net> References: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> <48C00AA2.4010509@laposte.net> Message-ID: <3f49a9f40809041643n67564a77uae28b6302f1c9a87@mail.gmail.com> The LLVM browser test optimizes both examples as expected... What optimization options are different? Although that optimization could be gcc-llvm level and not actual llvm level... On Thu, Sep 4, 2008 at 10:19 AM, C?dric Venet wrote: > Nuno Lopes a ?crit : >> Hi, >> >> I have two questions about optimizations performed by llvm. >> >> Consider these simple functions: >> int x(int b) { return b?4:6; } >> int y() { return x(0); } >> >> int x2() { return 5; } >> int y2() { return x2(); } >> >> the optimized bitcode (with clang + opt -std-compiler-opts) is: >> define i32 @y(...) nounwind { >> entry: >> ret i32 6 >> } >> >> define i32 @y2(...) nounwind { >> entry: >> %call = call i32 (...)* @x2( ) ; [#uses=0] >> ret i32 5 >> } >> >> So why does LLVM optimizes the more difficult case, but leaves behind the >> function call in the easiest case? :) >> > > I don't know why vararg would inhibit optimisation but maybe it is the > problem. > You should try with: > > int x2(void) { return 5; } > int y2(void) { return x2(); } > > it may solve the problem (or use C++ as langage) > > C?dric > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From eli.friedman at gmail.com Thu Sep 4 19:45:19 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 4 Sep 2008 17:45:19 -0700 Subject: [LLVMdev] missed optimizations In-Reply-To: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> References: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> Message-ID: On Thu, Sep 4, 2008 at 8:39 AM, Nuno Lopes wrote: > Hi, > > I have two questions about optimizations performed by llvm. > > Consider these simple functions: > int x(int b) { return b?4:6; } > int y() { return x(0); } > > int x2() { return 5; } > int y2() { return x2(); } > > the optimized bitcode (with clang + opt -std-compiler-opts) is: > define i32 @y(...) nounwind { > entry: > ret i32 6 > } > > define i32 @y2(...) nounwind { > entry: > %call = call i32 (...)* @x2( ) ; [#uses=0] > ret i32 5 > } > > So why does LLVM optimizes the more difficult case, but leaves behind the > function call in the easiest case? :) Pretty simple: LLVM doesn't know how to eliminate the call. There are a couple of ways it could be eliminated: DCE or inlining. The current DCE infrastructure isn't clever enough to do interprocedural analysis, so that doesn't eliminate it. And the inliner immediately gives up on varargs functions, so that doesn't eliminate it. And That said, clang really should be turning int x2() { return x(0); } into "define i32 @x2()" rather than "define i32 @x2(...)"; the function isn't varargs, and marking it as such could lead to wrong code for exotic calling conventions. > > Second question: > int f(); > > int g() { > if (f() == 5) return 3; > return 4; > } > > int h() { > if (g() == 6) return 2; > return 1; > } > > gives the following optimized bc: > > define i32 @g(...) nounwind { > entry: > %call = call i32 (...)* @f( ) ; [#uses=1] > %cmp = icmp eq i32 %call, 5 ; [#uses=1] > %retval = select i1 %cmp, i32 3, i32 4 ; [#uses=1] > ret i32 %retval > } > > define i32 @h(...) nounwind { > entry: > %call = call i32 (...)* @g( ) ; [#uses=1] > %cmp = icmp eq i32 %call, 6 ; [#uses=1] > %retval = select i1 %cmp, i32 2, i32 1 ; [#uses=1] > ret i32 %retval > } > > In function h(), llvm doesn't realize that g() never returns 6, and thus it > could reduce that function to { g(); return 1; }. Doesn't llvm produce some > sort of summary for functions with e.g. their possible return values? If > not, is there any pass where I could implement this? (I have some code that > has many opportunities for this kind of optimization) No, there isn't any such infrastructure at the moment. The LLVM pass that might do that sort of thing is predsimplify, but it isn't an interprocedural pass. It's not necessarily difficult to implement, depending on how precise you want it to be, but nobody's implemented it; as far as I know, it doesn't provide significant benefits for normal C/C++ code. If there's some specific pattern in your code, you could probably throw together a specialized pass pretty quickly. > Also, shouldn't the function g() get inlined in the h() function? It is > inlined only if I change the g() function to be static. So isn't llvm being > too conservative when inlining global functions? The inliner doesn't like varargs; see above. -Eli From belayda at gmail.com Thu Sep 4 22:03:18 2008 From: belayda at gmail.com (Bernardo Elayda) Date: Thu, 4 Sep 2008 20:03:18 -0700 Subject: [LLVMdev] Newbie question on front-end and code compaction Message-ID: <3e5ed32f0809042003r56d33feam72cbca48223dc556@mail.gmail.com> Hi! I'm still a newbie to LLVM, so I'm looking for guidance that will tell me the right docs to read. I'm interested in working on 2 different things. I'm interested on adding a new front end for a functional language such as Lisp. I'm also interested in helping out with compaction(making code with a small footprint). What are the right docs for me to start reading and reviewing? tia, Bernardo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080904/09c73887/attachment.html From viridia at gmail.com Thu Sep 4 22:35:47 2008 From: viridia at gmail.com (Talin) Date: Thu, 04 Sep 2008 20:35:47 -0700 Subject: [LLVMdev] Demangling question Message-ID: <48C0A913.6040401@gmail.com> So I got tired of LLVM's PrintStackTrace() function only being able to print mangled C++ names. I went ahead and wrote a demangler (shown below), however there's one slight problem, which is that the output of backtrace_symbols appears to be different on different platforms. In order to use the cxxabi demangler, you need to provide it with the portion of each line that contains the mangled name, and strip all of the other items on that line. In the case of OS X, the mangled symbol is delimited by whitespace, however on some platforms it appears that the mangled name is surrounded by parentheses. I guess what could be done is to just write a version of the line stripper per platform. I'd start by only supporting the platforms I have access to, and letting other people contribute the parsing code for their platform. #if HAVE_CXXABI_H #include #endif /// .... static void PrintStackTrace(int skipFrames) { #ifdef HAVE_BACKTRACE // Use backtrace() to output a backtrace on Linux systems with glibc. int depth = backtrace(stackTrace, static_cast(arrayLengthOf(StackTrace))); #ifdef HAVE_CXXABI_H if (char ** symbols = backtrace_symbols(StackTrace, depth)) { // Name buffer used to contain demangling result. size_t sz = 256; char * buffer = (char *)malloc(sz); for (int i = 0; i < depth; ++i) { // Skip this frame, and possibly the assert machinery as well. if (i >= skipFrames) { char * symbol = symbols[i]; // TODO: This is a very cheesy way to extract the symbol name, // need to come up with something that will work on various platforms. // fprintf(outstream, "%s\n", symbol); char * begin = strchr(symbol, '_'); char * demangled_name = NULL; if (begin) { char * end = strchr(begin, ' '); if (end) { *end = 0; int status; demangled_name = abi::__cxa_demangle(begin, buffer, &sz, &status); } } if (demangled_name != NULL) { fprintf(outstream, "%s\n", demangled_name); // Result may be a realloc of input buffer. buffer = demangled_name; } } } free(symbols); free(buffer); } #else backtrace_symbols_fd(StackTrace, depth, STDERR_FILENO); #endif #endif } Oh, and one other thing I haven't figured out is how to add a test for into LLVM's configure script. In any case, if someone wants to work on this feel free to use this code, I've been too busy lately to make a patch. -- Talin From idadesub at users.sourceforge.net Thu Sep 4 23:28:47 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Thu, 4 Sep 2008 21:28:47 -0700 Subject: [LLVMdev] Newbie question on front-end and code compaction In-Reply-To: <3e5ed32f0809042003r56d33feam72cbca48223dc556@mail.gmail.com> References: <3e5ed32f0809042003r56d33feam72cbca48223dc556@mail.gmail.com> Message-ID: <1ef034530809042128g3b06acc9x4a790441b2500723@mail.gmail.com> On Thu, Sep 4, 2008 at 8:03 PM, Bernardo Elayda wrote: > Hi! > > I'm still a newbie to LLVM, so I'm looking for guidance that will tell me > the right docs to read. > > I'm interested in working on 2 different things. I'm interested on adding a > new front end for a functional language such as Lisp. I'm also interested > in helping out with compaction(making code with a small footprint). What > are the right docs for me to start reading and reviewing? I'd start with the kaleidoscope tutorials, they taught me a lot about llvm: http://llvm.org/docs/tutorial/ From matthijs at stdin.nl Fri Sep 5 03:03:25 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Fri, 5 Sep 2008 10:03:25 +0200 Subject: [LLVMdev] missed optimizations In-Reply-To: References: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> Message-ID: <20080905080325.GA32157@katherina.student.utwente.nl> Hi Eli, > That said, clang really should be turning int x2() { return x(0); } > into "define i32 @x2()" rather than "define i32 @x2(...)"; the > function isn't varargs, and marking it as such could lead to wrong > code for exotic calling conventions. I always understood that this is correct per C language specification. For functions that are internal (static), the DeadArgElim pass removes the vararg spec if it's unused, but that's not applicable in this case. Any particular reason the inliner doesn't touch varargs? I think that when you call a varargs function without any varargs, it should be able to inline it just fine? Or at least when the function in question also doesn't call the va_* functions. > > Also, shouldn't the function g() get inlined in the h() function? It is > > inlined only if I change the g() function to be static. So isn't llvm being > > too conservative when inlining global functions? > > The inliner doesn't like varargs; see above. And the fact that it is inlined when it's static, is probably due to the DeadArgElim I mentioned above. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080905/f0ce343d/attachment.bin From baldrick at free.fr Fri Sep 5 03:22:35 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 5 Sep 2008 10:22:35 +0200 Subject: [LLVMdev] A simple case about SDiv In-Reply-To: <8abe0dc60809040908p784d81c7o232d26fb086a6bbf@mail.gmail.com> References: <8abe0dc60809040831u43b19308rfa96d031ecdead39@mail.gmail.com> <200809041756.17474.baldrick@free.fr> <8abe0dc60809040908p784d81c7o232d26fb086a6bbf@mail.gmail.com> Message-ID: <200809051022.36112.baldrick@free.fr> > Any ideas? Most likely it is the gcc folder doing it. This gcc optimization is run in llvm-gcc because it's basically impossible to turn it off! You can check by passing -mllvm -disable-llvm-optzns to llvm-gcc along with -O2. If the optimization still occurs then it was gcc that did it. Ciao, Duncan. From asl at math.spbu.ru Fri Sep 5 03:49:25 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 5 Sep 2008 12:49:25 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?SW50ZWwgYXNt?= Message-ID: <200809050849.m858nP3g080219@star.math.spbu.ru> Hello, David > Is the Intel AsmPrinter meant to produce asm that is understood by gas or > is it only meant to satisfy NASM, etc.? It's expected to produce assembler, which is understood by masm mainly. However, don't expect much from this asmprinter - masm does not have many features required to emit assembler properly. -- WBR, Anton Korobeynikov From asl at math.spbu.ru Fri Sep 5 03:51:39 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 5 Sep 2008 12:51:39 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?RGVtYW5nbGluZyBxdWVzdGlvbg==?= Message-ID: <200809050851.m858pdoa004150@star.math.spbu.ru> Hello, Talin > In any case, if someone wants to work on this feel free to use this > code, I've been too busy lately to make a patch. Please, file a PR - I'll take care about this. -- WBR, Anton Korobeynikov From eli.friedman at gmail.com Fri Sep 5 03:57:19 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 5 Sep 2008 01:57:19 -0700 Subject: [LLVMdev] missed optimizations In-Reply-To: <20080905080325.GA32157@katherina.student.utwente.nl> References: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> <20080905080325.GA32157@katherina.student.utwente.nl> Message-ID: On Fri, Sep 5, 2008 at 1:03 AM, Matthijs Kooijman wrote: > Hi Eli, > >> That said, clang really should be turning int x2() { return x(0); } >> into "define i32 @x2()" rather than "define i32 @x2(...)"; the >> function isn't varargs, and marking it as such could lead to wrong >> code for exotic calling conventions. > I always understood that this is correct per C language specification. What's the question here? The C standard says that int(*)() is not a varargs function, but rather a function without an explicitly declared argument list, and is actually incompatible with any varargs function. As far as I can tell, though, the LLVM varargs specifier is more forgiving; llvm-gcc seems to be willing to call int(*)() using an llvm varargs type. > > Any particular reason the inliner doesn't touch varargs? I think that when you > call a varargs function without any varargs, it should be able to inline it > just fine? Or at least when the function in question also doesn't call the > va_* functions. I think it's just unimplemented. -Eli From nicolas at capens.net Fri Sep 5 09:06:02 2008 From: nicolas at capens.net (Nicolas Capens) Date: Fri, 5 Sep 2008 16:06:02 +0200 Subject: [LLVMdev] Keeping values in memory Message-ID: <006501c90f60$87ef6520$97ce2f60$@net> Hi all, It looks like LLVM is quite eager to load values into registers when they have multiple uses. Unfortunately, this increases register pressure, specifically on x86. In my experience modern x86 processors are very capable of using memory operands as source. In fact the only cases where a register is preferred over repeatedly using the same memory operand is when multiple instructions could use the value in the same clock cycle, or when it significantly reduces code size. I have found this to be mostly a concern with SIMD code (MMX and SSE). So if anyone could tell me where to find the code that determines whether to load a value into a register or leave it in memory, I could perform some tests to see if a better heuristic exists. Thanks, Nicolas Capens -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080905/bed8c71a/attachment.html From marcsiebren at gmail.com Thu Sep 4 15:59:42 2008 From: marcsiebren at gmail.com (Marc-Siebren Kwadijk) Date: Thu, 4 Sep 2008 22:59:42 +0200 Subject: [LLVMdev] wrong guess at operating system in the bug reports form Message-ID: <77EEDD41-2A0C-4D8F-929B-48E11724DCC3@gmail.com> Hi, The bug reporting system at http://llvm.org/bugs/enter_bug.cgi? product=clang guessed my operating system to be Macintosh, 9.x but it is Macintosh, 10.x. The form says to mail this address in case the system wasn't guessed right. some details that are maybe helpful to you: Mac OSX 10.4.11 Safari 3.1.2 (4525.22) and I didn't do tricks to try to change my browsers user-agent. Hope this is helpful to you! greetings, Marc From mrs at apple.com Fri Sep 5 12:06:54 2008 From: mrs at apple.com (Mike Stump) Date: Fri, 5 Sep 2008 10:06:54 -0700 Subject: [LLVMdev] Newbie question on front-end and code compaction In-Reply-To: <3e5ed32f0809042003r56d33feam72cbca48223dc556@mail.gmail.com> References: <3e5ed32f0809042003r56d33feam72cbca48223dc556@mail.gmail.com> Message-ID: <965996F8-F061-433D-871D-81EB8DE373F1@apple.com> On Sep 4, 2008, at 8:03 PM, Bernardo Elayda wrote: > I'm also interested in helping out with compaction(making code with > a small footprint). People pointed out recently on the list that -Os doesn't work so well. See the email from regehr at cs.utah.edu on Aug 20 on llvmdev. You should be able to work with him to get testcases, from there you just grind through them and find why they are bigger and reduce them. Failing that, just compile up any software and compare. Should be lots of low hanging fruit. From evan.cheng at apple.com Fri Sep 5 12:20:46 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 5 Sep 2008 10:20:46 -0700 Subject: [LLVMdev] Keeping values in memory In-Reply-To: <006501c90f60$87ef6520$97ce2f60$@net> References: <006501c90f60$87ef6520$97ce2f60$@net> Message-ID: <89300078-F239-490E-A79A-E399108E93A8@apple.com> On Sep 5, 2008, at 7:06 AM, Nicolas Capens wrote: > Hi all, > > It looks like LLVM is quite eager to load values into registers when > they have multiple uses. Unfortunately, this increases register > pressure, specifically on x86. In my experience modern x86 > processors are very capable of using memory operands as source. In > fact the only cases where a register is preferred over repeatedly > using the same memory operand is when multiple instructions could > use the value in the same clock cycle, or when it significantly > reduces code size. > > I have found this to be mostly a concern with SIMD code (MMX and > SSE). So if anyone could tell me where to find the code that > determines whether to load a value into a register or leave it in > memory, I could perform some tests to see if a better heuristic > exists. This is done in instruction selection. In general using registers over memory is preferred. I can see certain situations where keeping values in registers can end up hurting performance due to added spilling. However, a heuristic is never going to be satisfactory solution because it's guaranteed to miss important cases. The right approach to combat this is implement generalized re- materialization in the register allocator. That'll come sometime (hopefully) next year when I rewrite the register allocator. Evan > > Thanks, > > Nicolas Capens > _______________________________________________ > 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/20080905/70e732db/attachment.html From dalej at apple.com Fri Sep 5 12:21:37 2008 From: dalej at apple.com (Dale Johannesen) Date: Fri, 5 Sep 2008 10:21:37 -0700 Subject: [LLVMdev] Newbie question on front-end and code compaction In-Reply-To: <965996F8-F061-433D-871D-81EB8DE373F1@apple.com> References: <3e5ed32f0809042003r56d33feam72cbca48223dc556@mail.gmail.com> <965996F8-F061-433D-871D-81EB8DE373F1@apple.com> Message-ID: <5F5F8C4E-1D09-40EE-9436-0B8076DDDB51@apple.com> On Sep 5, 2008, at 10:06 AMPDT, Mike Stump wrote: > On Sep 4, 2008, at 8:03 PM, Bernardo Elayda wrote: >> I'm also interested in helping out with compaction(making code with >> a small footprint). > > People pointed out recently on the list that -Os doesn't work so > well. See the email from regehr at cs.utah.edu on Aug 20 on llvmdev. > You should be able to work with him to get testcases, from there you > just grind through them and find why they are bigger and reduce them. > Failing that, just compile up any software and compare. Should be > lots of low hanging fruit. Thread starts here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016600.html The last message points out inlining and unrolling heuristics as low- hanging fruit, and I agree. But there is a lot more beyond that, particular instruction selection on x86. From overminddl1 at gmail.com Fri Sep 5 14:42:21 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Fri, 5 Sep 2008 13:42:21 -0600 Subject: [LLVMdev] Integer questions Message-ID: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> First off, most of my information about the integer representation in LLVM is from http://llvm.org/docs/LangRef.html#t_integer and I could use some things cleared up. First, I guess that smaller integer sizes, say, i1 (boolean) are stuffed into a full word size for the cpu it is compiled on (so 8bits, or 32 bits or whatever). What if someone made an i4 and compiled it on 32/64 bit windows/nix/bsd on a standard x86 or x64 system, and they set the value to 15 (the max size of an unsigned i4), if it is still rounded up to the next nearest size when compiled (i8 or i32 or what-not), what if when that value has 15, but a 1 was added to it, it will be represented in memory at 16, or if you ignore all but the first 4 bits it would be zero. Is there any enforcement in the range of a given integer (in other words, regardless of architecture, would an i4 be constrained to only be 0 to 15, or is this the realm of the language to enforce, I would think it would be as having it at LLVM level would add noticeable overhead on non-machine size integers, and given that it would be in the realm of the language to deal with, how can the language be certain what values are directly appropriate for the architecture it is being compiled on)? In just a quick guess, I would say that something like an i4 would be compiled as if it was an i8, treated identically to an i8 in all circumstances, is this correct? Second, what if the specified integer size is rather large, say that an i512 was specified, would this cause a compile error (something along the lines of the specified integer size being too large to fit in the machine architecture), or would it rather compile in the necessary code to do bignum math on it (or would something like that be in the realm of the language designer, although having it at LLVM level would also make sense, after all, what best knows how to compile something for speed on the target system other then the compiler itself)? In just a quick guess, I would say that specifying an integer bit size too large for the machine would cause a compile error, but the docs do not hint at that (especially with the given example of: i1942652 a really big integer of over 1 million bits), is this correct? Third, assuming either or both of the above things had to be enforced/implemented by the language designer, what would be the best way for the language to ask LLVM what the appropriate machine integer sizes are, so that if an i64 is specified, then bignum math would be done by the language on a 32-bit compile, but would just be a native int on a 64-bit compile. The reason this is asked instead of just directly testing the cpu bit (32-bit, 64-bit, whatever) is that some processors allow double sized integers to be specified, so a 64-bit integer on some 32-bit cpu's is just fine, as is a 128-bit int on a 64-bit cpu, thus how can I query what are the best appropriate integer sizes? Some background on the questions: Making a JIT'd, speed-critical 'scripting-language' for a certain app of mine, integer types have a bitsize part, like how LLVM does it, i4/s4 is a signed integer of 4-bits, u4 is an unsigned integer of 4-bits, etc... From kapilanand2 at gmail.com Fri Sep 5 15:14:48 2008 From: kapilanand2 at gmail.com (kapil anand) Date: Fri, 5 Sep 2008 16:14:48 -0400 Subject: [LLVMdev] Query regarding Inline Assembly Message-ID: <9f741d560809051314y66af34edw9e4d24b3e72dccd@mail.gmail.com> Hi all, I am using the inline assembly expressions( which are different from Module Level Inline Assembly) and have some doubts about how do the assembly expressions affect the optimization passes. I inserted an inline assembly for a particular instruction and I assume that this instruction affects the Data Flow. Thus I want to make sure that no pass should move any instruction across this assembly expression. I tried by making the side-effect flag of assembly instruction to be true but still the passes were moving instruction across this assembly expression. Is there any other way to specify stricter constraint for assembly expressions? Thanks Kapil From eli.friedman at gmail.com Fri Sep 5 15:57:23 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 5 Sep 2008 13:57:23 -0700 Subject: [LLVMdev] Integer questions In-Reply-To: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> Message-ID: On Fri, Sep 5, 2008 at 12:42 PM, OvermindDL1 wrote: > First off, most of my information about the integer representation in > LLVM is from http://llvm.org/docs/LangRef.html#t_integer and I could > use some things cleared up. Okay... that's a good start :) > First, I guess that smaller integer sizes, say, i1 (boolean) are > stuffed into a full word size for the cpu it is compiled on (so 8bits, > or 32 bits or whatever). The code is compiled so that it works. :) At least hopefully; I think there are still some bugs lurking with unusual types. CodeGen will use a native register to do arithmetic. > What if someone made an i4 and compiled it on 32/64 bit > windows/nix/bsd on a standard x86 or x64 system, and they set the > value to 15 (the max size of an unsigned i4), if it is still rounded > up to the next nearest size when compiled (i8 or i32 or what-not), > what if when that value has 15, but a 1 was added to it, it will be > represented in memory at 16, or if you ignore all but the first 4 bits > it would be zero. Is there any enforcement in the range of a given > integer (in other words, regardless of architecture, would an i4 be > constrained to only be 0 to 15, or is this the realm of the language > to enforce, I would think it would be as having it at LLVM level would > add noticeable overhead on non-machine size integers, and given that > it would be in the realm of the language to deal with, how can the > language be certain what values are directly appropriate for the > architecture it is being compiled on)? > In just a quick guess, I would say that something like an i4 would be > compiled as if it was an i8, treated identically to an i8 in all > circumstances, is this correct? An i4 is a four-bit integer; it is guaranteed to act like a true i4 for all arithmetic operations. CodeGen will mask the integers appropriately to achieve the desired behavior. > Second, what if the specified integer size is rather large, say that > an i512 was specified, would this cause a compile error (something > along the lines of the specified integer size being too large to fit > in the machine architecture), or would it rather compile in the > necessary code to do bignum math on it (or would something like that > be in the realm of the language designer, although having it at LLVM > level would also make sense, after all, what best knows how to compile > something for speed on the target system other then the compiler > itself)? > In just a quick guess, I would say that specifying an integer bit size > too large for the machine would cause a compile error, but the docs do > not hint at that (especially with the given example of: i1942652 a > really big integer of over 1 million bits), is this correct? The language and the optimizers don't have any issues with such types, at least in theory. Ignoring bugs, CodeGen can currently handle anything up to i128 for all operations on most architectures; if the operations aren't natively supported, it falls back to calling the implementation in libgcc. -Eli From baldrick at free.fr Fri Sep 5 17:07:52 2008 From: baldrick at free.fr (Duncan Sands) Date: Sat, 6 Sep 2008 00:07:52 +0200 Subject: [LLVMdev] Integer questions In-Reply-To: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> Message-ID: <200809060007.52512.baldrick@free.fr> Hi, > First, I guess that smaller integer sizes, say, i1 (boolean) are > stuffed into a full word size for the cpu it is compiled on (so 8bits, > or 32 bits or whatever). on x86-32, an i1 gets placed in an 8 bit register. > What if someone made an i4 and compiled it on 32/64 bit > windows/nix/bsd on a standard x86 or x64 system, and they set the > value to 15 (the max size of an unsigned i4), if it is still rounded > up to the next nearest size when compiled (i8 or i32 or what-not), The extra bits typically contain rubbish, but you can't tell. For example, suppose in the bitcode you decide to print out the value of the i4 by calling printf. So in the bitcode you first (say) zero-extend the i4 to an i32 which you pass to printf. Well, the code-generators will generate the following (or equivalent) for the zero-extension: mask off the rubbish bits in the i8 register (i.e. set them to zero) then zero-extend the result to a full 32 bit register. This all happens transparently. > what if when that value has 15, but a 1 was added to it, it will be > represented in memory at 16, or if you ignore all but the first 4 bits > it would be zero. It acts like an i4: the bits corresponding to the i4 will have the right value (0) while the rest will have some rubbish. > Is there any enforcement in the range of a given > integer (in other words, regardless of architecture, would an i4 be > constrained to only be 0 to 15, or is this the realm of the language > to enforce, I would think it would be as having it at LLVM level would > add noticeable overhead on non-machine size integers, and given that > it would be in the realm of the language to deal with, how can the > language be certain what values are directly appropriate for the > architecture it is being compiled on)? > In just a quick guess, I would say that something like an i4 would be > compiled as if it was an i8, treated identically to an i8 in all > circumstances, is this correct? No it is not. It acts exactly like an i4, even though on x86-32 the code-generators implement this in an i8. There is a whole pile of logic in lib/CodeGen/SelectionDAG/Legalize*Types.cpp in order to get this effect (currently you have to pass -enable-legalize-types to llc to turn on codegen support for funky integer sizes). > Second, what if the specified integer size is rather large, say that > an i512 was specified, would this cause a compile error (something > along the lines of the specified integer size being too large to fit > in the machine architecture), or would it rather compile in the > necessary code to do bignum math on it (or would something like that > be in the realm of the language designer, although having it at LLVM > level would also make sense, after all, what best knows how to compile > something for speed on the target system other then the compiler > itself)? The current maximum the code generators support is i256. If you try to use bigger integers it will work fine in the bitcode, but if you try to do code generation the compiler will crash. > In just a quick guess, I would say that specifying an integer bit size > too large for the machine would cause a compile error, but the docs do > not hint at that (especially with the given example of: i1942652 a > really big integer of over 1 million bits), is this correct? No, you can use i256 on a 32 bit machine for example. > Third, assuming either or both of the above things had to be > enforced/implemented by the language designer, what would be the best > way for the language to ask LLVM what the appropriate machine integer > sizes are, so that if an i64 is specified, then bignum math would be > done by the language on a 32-bit compile, but would just be a native > int on a 64-bit compile. The reason this is asked instead of just > directly testing the cpu bit (32-bit, 64-bit, whatever) is that some > processors allow double sized integers to be specified, so a 64-bit > integer on some 32-bit cpu's is just fine, as is a 128-bit int on a > 64-bit cpu, thus how can I query what are the best appropriate integer > sizes? I don't know, sorry. Ciao, Duncan. From viridia at gmail.com Fri Sep 5 21:46:12 2008 From: viridia at gmail.com (Talin) Date: Fri, 05 Sep 2008 19:46:12 -0700 Subject: [LLVMdev] "has different visibility" warnings Message-ID: <48C1EEF4.9080701@gmail.com> Recently I started getting these warnings - thousands of them - and I'm not sure what I did to cause them or how to solve them: ld: warning llvm::MemoryBuffer::getBufferStart() const has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning llvm::OwningPtr::OwningPtr(llvm::MemoryBuffer*)has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning llvm::OwningPtr::OwningPtr(llvm::MemoryBuffer*)has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning llvm::OwningPtr::~OwningPtr()has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning llvm::OwningPtr::~OwningPtr()has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning llvm::APInt::isSingleWord() consthas different visibility (2) in /usr/local/lib/libLLVMTarget.a(TargetData.o) and (1) in /usr/local/lib/libLLVMSupport.a(APFloat.o) ld: warning llvm::APInt::isSingleWord() consthas different visibility (2) in /usr/local/lib/libLLVMCore.a(Instructions.o) and (1) in /usr/local/lib/libLLVMSupport.a(APFloat.o) ld: warning llvm::APInt::getNumWords() consthas different visibility (2) in /usr/local/lib/libLLVMCore.a(Instructions.o) and (1) in /usr/local/lib/libLLVMSupport.a(APFloat.o) ld: warning llvm::APInt::clearUnusedBits() has different visibility (2) in /usr/local/lib/libLLVMCore.a(Instructions.o) and (1) in /usr/local/lib/libLLVMSupport.a(APFloat.o) (and so on...) Any suggestions? -- Talin From gordonhenriksen at me.com Fri Sep 5 22:19:22 2008 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Fri, 05 Sep 2008 23:19:22 -0400 Subject: [LLVMdev] "has different visibility" warnings In-Reply-To: <48C1EEF4.9080701@gmail.com> References: <48C1EEF4.9080701@gmail.com> Message-ID: <7A1360FC-26C4-49E0-B5DC-E8ADC2CB1CDF@me.com> http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016763.html On 2008-09-05, at 22:46, Talin wrote: > Recently I started getting these warnings - thousands of them - and > I'm > not sure what I did to cause them or how to solve them: > > ld: warning llvm::MemoryBuffer::getBufferStart() const has different > visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and > (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) > ld: warning > llvm::OwningPtr::OwningPtr(llvm::MemoryBuffer*)has > different visibility (1) in > /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in > /usr/local/lib/libLLVMSupport.a(CommandLine.o) > ld: warning > llvm::OwningPtr::OwningPtr(llvm::MemoryBuffer*)has > different visibility (1) in > /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in > /usr/local/lib/libLLVMSupport.a(CommandLine.o) > ld: warning llvm::OwningPtr::~OwningPtr()has > different visibility (1) in > /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in > /usr/local/lib/libLLVMSupport.a(CommandLine.o) > ld: warning llvm::OwningPtr::~OwningPtr()has > different visibility (1) in > /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in > /usr/local/lib/libLLVMSupport.a(CommandLine.o) > ld: warning llvm::APInt::isSingleWord() consthas different visibility > (2) in /usr/local/lib/libLLVMTarget.a(TargetData.o) and (1) in > /usr/local/lib/libLLVMSupport.a(APFloat.o) > ld: warning llvm::APInt::isSingleWord() consthas different visibility > (2) in /usr/local/lib/libLLVMCore.a(Instructions.o) and (1) in > /usr/local/lib/libLLVMSupport.a(APFloat.o) > ld: warning llvm::APInt::getNumWords() consthas different visibility > (2) > in /usr/local/lib/libLLVMCore.a(Instructions.o) and (1) in > /usr/local/lib/libLLVMSupport.a(APFloat.o) > ld: warning llvm::APInt::clearUnusedBits() has different > visibility > (2) in /usr/local/lib/libLLVMCore.a(Instructions.o) and (1) in > /usr/local/lib/libLLVMSupport.a(APFloat.o) > > (and so on...) Any suggestions? > > -- Talin > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev ? Gordon From zhousheng00 at gmail.com Fri Sep 5 23:45:13 2008 From: zhousheng00 at gmail.com (Zhou Sheng) Date: Sat, 6 Sep 2008 12:45:13 +0800 Subject: [LLVMdev] A simple case about SDiv In-Reply-To: <200809051022.36112.baldrick@free.fr> References: <8abe0dc60809040831u43b19308rfa96d031ecdead39@mail.gmail.com> <200809041756.17474.baldrick@free.fr> <8abe0dc60809040908p784d81c7o232d26fb086a6bbf@mail.gmail.com> <200809051022.36112.baldrick@free.fr> Message-ID: <8abe0dc60809052145t6193200btc3d66e4bed034b17@mail.gmail.com> 2008/9/5 Duncan Sands > > Any ideas? > > Most likely it is the gcc folder doing it. > This gcc optimization is run in llvm-gcc > because it's basically impossible to turn > it off! Agree. I found that gcc option -fstrict-overflow, with which gcc will do that simplication. Defaultly, that option is turn on with -O2 or above. > You can check by passing > -mllvm -disable-llvm-optzns > to llvm-gcc along with -O2. If the > optimization still occurs then it was > gcc that did it. eh... I got some error as following: llvm-gcc -O2 -mllvm -disable-llvm-optzns -emit-llvm -c test.c -o test.ll -S cc1: warning: unrecognized gcc debugging option: i cc1: warning: unrecognized gcc debugging option: s cc1: warning: unrecognized gcc debugging option: b cc1: warning: unrecognized gcc debugging option: l cc1: warning: unrecognized gcc debugging option: e cc1: warning: unrecognized gcc debugging option: - cc1: warning: unrecognized gcc debugging option: l cc1: warning: unrecognized gcc debugging option: l cc1: warning: unrecognized gcc debugging option: m cc1: warning: unrecognized gcc debugging option: - cc1: warning: unrecognized gcc debugging option: o cc1: warning: unrecognized gcc debugging option: t cc1: warning: unrecognized gcc debugging option: z cc1: warning: unrecognized gcc debugging option: n cc1: warning: unrecognized gcc debugging option: s cc1: Unknown command line argument '-mtune=generic'. Try: 'cc1 --help' Am I missing something? Sheng. > > > Ciao, > > Duncan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080906/52b83751/attachment.html From chris at xrnd.com Sat Sep 6 01:30:33 2008 From: chris at xrnd.com (Chris Knight) Date: Sat, 6 Sep 2008 06:30:33 -0000 (UTC) Subject: [LLVMdev] llvm on opensolaris Message-ID: <39896.66.65.173.28.1220682633.squirrel@webmail.xrnd.com> Hello, Has anyone successfully built llvm and llvm-gcc on OpenSolaris on x64? TIA Chris. From asl at math.spbu.ru Sat Sep 6 04:38:37 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sat, 6 Sep 2008 13:38:37 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?bGx2bSBvbiBvcGVuc29sYXJpcw==?= Message-ID: <200809060938.m869cbgq075940@star.math.spbu.ru> Hello, > Has anyone successfully built llvm and llvm-gcc on OpenSolaris on x64? I think yes. There is even a PR for this. Some changes were not integrated yet, because they need to be rewritten in better way. -- WBR, Anton Korobeynikov From asl at math.spbu.ru Sat Sep 6 07:26:56 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sat, 6 Sep 2008 16:26:56 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?QSBzaW1wbGUgY2FzZSBhYm91dCBTRGl2?= Message-ID: <200809061226.m86CQuZv096026@star.math.spbu.ru> Hello, > eh... I got some error as following: > llvm-gcc -O2 -mllvm -disable-llvm-optzns -emit-llvm -c test.c -o test.ll -S You need to pass these pair of options directly to cc1, driver is breaking them. -- WBR, Anton Korobeynikov From chris at xrnd.com Sat Sep 6 09:12:15 2008 From: chris at xrnd.com (Chris Knight) Date: Sat, 6 Sep 2008 14:12:15 -0000 (UTC) Subject: [LLVMdev] llvm on opensolaris In-Reply-To: <200809060938.m869cbgq075940@star.math.spbu.ru> References: <200809060938.m869cbgq075940@star.math.spbu.ru> Message-ID: <47993.66.65.173.28.1220710335.squirrel@webmail.xrnd.com> > I think yes. There is even a PR for this. Some changes were not integrated > yet, because they need to be rewritten in better way. I see a couple for older versions of Solaris but nothing for OpenSolaris. Do you happen to remember the PR number? thanks. From asl at math.spbu.ru Sat Sep 6 09:16:43 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sat, 6 Sep 2008 18:16:43 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?bGx2bSBvbiBvcGVuc29sYXJpcw==?= Message-ID: <200809061416.m86EGhEe067007@star.math.spbu.ru> Hi, Chris > I see a couple for older versions of Solaris but nothing for OpenSolaris. > Do you happen to remember the PR number? Well, for example - http://llvm.org/bugs/show_bug.cgi?id=2516 I think Nathan can comment on solaris support status. -- WBR, Anton Korobeynikov From luked at cs.rochester.edu Sat Sep 6 09:55:04 2008 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Sat, 06 Sep 2008 10:55:04 -0400 Subject: [LLVMdev] Query regarding Inline Assembly In-Reply-To: <9f741d560809051314y66af34edw9e4d24b3e72dccd@mail.gmail.com> References: <9f741d560809051314y66af34edw9e4d24b3e72dccd@mail.gmail.com> Message-ID: <48C299C8.4040602@cs.rochester.edu> kapil anand wrote: > Hi all, > > I am using the inline assembly expressions( which are different from > Module Level Inline Assembly) and have some doubts about how do the > assembly expressions affect the optimization passes. > > I inserted an inline assembly for a particular instruction and I > assume that this instruction affects the Data Flow. Thus I want to > make sure that no pass should move any instruction across this > assembly expression. I tried by making the side-effect flag of > assembly instruction to be true but still the passes were moving > instruction across this assembly expression. Is there any other way to > specify stricter constraint for assembly expressions? Setting "memory" in the clobber flags and making the assembly volatile should prevent code motion across the instruction. Luke > > Thanks > > Kapil > _______________________________________________ > 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 Sat Sep 6 12:09:03 2008 From: baldrick at free.fr (Duncan Sands) Date: Sat, 6 Sep 2008 19:09:03 +0200 Subject: [LLVMdev] Visibility warning Message-ID: <200809061909.03566.baldrick@free.fr> Unlike those happy few who are seeing thousands of visibility warnings, I get only one with gcc 4.3: lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:3889: warning: ?llvm::SDISelAsmOperandInfo? declared with greater visibility than the type of its field ?llvm::SDISelAsmOperandInfo::AssignedRegs? Anyway know what this is about? Ciao, Duncan. From zhousheng00 at gmail.com Sun Sep 7 00:24:05 2008 From: zhousheng00 at gmail.com (Zhou Sheng) Date: Sun, 7 Sep 2008 13:24:05 +0800 Subject: [LLVMdev] A simple case about SDiv Message-ID: <8abe0dc60809062224u464345d6x87e8d241a0e4420f@mail.gmail.com> Hi, >Hello, > >> eh... I got some error as following: >> llvm-gcc -O2 -mllvm -disable-llvm-optzns -emit-llvm -c test.c -o >test.ll -S >You need to pass these pair of options directly to cc1, driver is >breaking them. Yes, you are right. Thanks for pointing out that. Sheng. >-- >WBR, Anton Korobeynikov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080907/a146297d/attachment.html From jonathandeanharrop at googlemail.com Fri Sep 5 22:26:20 2008 From: jonathandeanharrop at googlemail.com (Jon Harrop) Date: Sat, 6 Sep 2008 04:26:20 +0100 Subject: [LLVMdev] OCaml bindings to LLVM Message-ID: <200809060426.20303.jon@ffconsultancy.com> I'm having another play with LLVM using the OCaml bindings for a forthcoming OCaml Journal article and I have a couple of remarks: Firstly, I noticed that the execute engine is very slow, taking milliseconds to call a JIT compiled function. Is this an inherent overhead or am I calling it incorrectly or is this something that can be optimized in the OCaml bindings? Secondly, I happened to notice that JIT compiled code executed on the fly does not read from the stdin of the host OCaml program although it can write to stdout. Is this a bug? Many thanks, -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e From rich at pennware.com Mon Sep 8 06:03:00 2008 From: rich at pennware.com (Richard Pennington) Date: Mon, 08 Sep 2008 06:03:00 -0500 Subject: [LLVMdev] adde/addc Message-ID: <48C50664.4040708@pennware.com> My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this possible given the current code generation stuff? Is there another approach that I should consider? -Rich From rich at pennware.com Mon Sep 8 06:20:56 2008 From: rich at pennware.com (Richard Pennington) Date: Mon, 08 Sep 2008 06:20:56 -0500 Subject: [LLVMdev] adde/addc In-Reply-To: <48C50664.4040708@pennware.com> References: <48C50664.4040708@pennware.com> Message-ID: <48C50A98.2020705@pennware.com> Richard Pennington wrote: > My target doesn't support 64 bit arithmetic, so I'd like to supply > definitions for adde/addc. The problem is I can't seem to figure out the > magic. Here's an example of what I need to generate: > > # two i64s in r5/r6 and r7/r8 > # result in r1/r2, carry in r3 > > # adde > add r2, r6, r8 > cmpltu r3, r2, r6 # compute carry > > # addc > add r1, r5, r7 > add r1, zero, r3 Oops! I meant: add r1, r1, r3 > > Is this possible given the current code generation stuff? Is there > another approach that I should consider? > > -Rich > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From rlsosborne at googlemail.com Mon Sep 8 06:22:14 2008 From: rlsosborne at googlemail.com (Richard Osborne) Date: Mon, 08 Sep 2008 12:22:14 +0100 Subject: [LLVMdev] adde/addc In-Reply-To: <48C50664.4040708@pennware.com> References: <48C50664.4040708@pennware.com> Message-ID: <48C50AE6.6000900@googlemail.com> Richard Pennington wrote: > My target doesn't support 64 bit arithmetic, so I'd like to supply > definitions for adde/addc. The problem is I can't seem to figure out the > magic. Here's an example of what I need to generate: > > # two i64s in r5/r6 and r7/r8 > # result in r1/r2, carry in r3 > > # adde > add r2, r6, r8 > cmpltu r3, r2, r6 # compute carry > > # addc > add r1, r5, r7 > add r1, zero, r3 > > Is this possible given the current code generation stuff? Is there > another approach that I should consider? > > -Rich > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > I needed to do exactly the same for my target. I set ISD::ADD to be custom expanded (setOperationAction(ISD::ADD, MVT::i64, Custom)) and the same for ISD::SUB. I then added the following code to my target to do the expansion: ExpandADDSUB(SDNode *N, SelectionDAG &DAG) { assert(N->getValueType(0) == MVT::i64 && (N->getOpcode() == ISD::ADD || N->getOpcode() == ISD::SUB) && "Unknown operand to lower!"); // Extract components SDOperand LHSL = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, N->getOperand(0), DAG.getConstant(0, MVT::i32)); SDOperand LHSH = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, N->getOperand(0), DAG.getConstant(1, MVT::i32)); SDOperand RHSL = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, N->getOperand(1), DAG.getConstant(0, MVT::i32)); SDOperand RHSH = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, N->getOperand(1), DAG.getConstant(1, MVT::i32)); // Expand SDOperand Lo = DAG.getNode(N->getOpcode(), MVT::i32, LHSL, RHSL); ISD::CondCode CarryCC = (N->getOpcode() == ISD::ADD) ? ISD::SETULT : ISD::SETUGT; SDOperand Carry = DAG.getSetCC(MVT::i32, Lo, LHSL, CarryCC); SDOperand Hi = DAG.getNode(N->getOpcode(), MVT::i32, LHSH, Carry); Hi = DAG.getNode(N->getOpcode(), MVT::i32, Hi, RHSH); // Merge the pieces return DAG.getNode(ISD::BUILD_PAIR, MVT::i64, Lo, Hi).Val; } In LowerOperation I lower add and sub using: case ISD::ADD: case ISD::SUB: return SDOperand(ExpandADDSUB(Op.Val, DAG),0); This is for LLVM 2.3. I've haven't updated to the head recently so there might be additional changes needed for the new legalize types infrastructure. Hope this helps, Richard From matthijs at stdin.nl Mon Sep 8 10:57:38 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Mon, 8 Sep 2008 17:57:38 +0200 Subject: [LLVMdev] Overzealous PromoteCastOfAllocation Message-ID: <20080908155737.GJ32157@katherina.student.utwente.nl> Hi all, I'm currently running into some problems with instcombine changing the type of alloca instructions. In particular, the PromoteCastOfAllocation looks at any allocation instruction that is used by a bitast. It does a few checks, but basically tries to change the type of the alloca instruction to the type pointed to by the bitcasted type. The current heuristic for determining if this is a good idea, is "do it if the aligment of the new type is larger than before" (Note that this is not just a safety check, since when the aligments are equal, the alloca is not changed). This heuristic seems to have been introduced to prevent infinite loops when there are multiple uses of the alloca. At first glance, changing the alloca type to remove a bitcast seems a sensible idea. However, the transformation seems quite ignorant of other uses of the alloca. It does properly update them by inserting extra bitcasts, but in a lot of cases, this means you can remove a single (or perhaps a few) bitcasts, while introducing a bunch of other bitcasts. IMHO, a better policy is needed. Another problem that occurs here, is that this transformation can replace a struct alloca with a single integer alloca. This, in turn, can confuse other passes like scalarrepl, and produce but ugly code. I've assembled a small example of this. declare void @bar(i16, i16) define internal void @empty(i32* %X) { ret void } define void @foo(i16 %A, i16 %B) { entry: ;; Alloc a struct %V = alloca {i16, i16} ;; Save our arguments into it %V1 = getelementptr {i16, i16}* %V, i32 0, i32 0 %V2 = getelementptr {i16, i16}* %V, i32 0, i32 1 store i16 %A, i16* %V1 store i16 %B, i16* %V2 ;; Load the values again %R1 = load i16* %V1 %R2 = load i16* %V2 ;; Pass them to an external function to make them used call void @bar(i16 %R1, i16 %R2) ;; Bitcast the alloca to i32& %V32 = bitcast {i16, i16}* %V to i32* ;; And make it appear used (at first glance, deadargelim will ;; can remove this use later on call void @empty(i32* %V32) ret void } The above program does almost nothing, but contains an alloca of {i16, i16} which is bitcasted to i32* somewhere. This i32* appears used, but can later be removed (you'll see why). Now, when I run instcombine over this code, I get the following (other functions left out, they are unchanged). define void @foo(i16 %A, i16 %B) { entry: %V = alloca i32 ; [#uses=3] %tmpcast = bitcast i32* %V to { i16, i16 }* ; <{ i16, i16 }*> [#uses=1] %V1 = bitcast i32* %V to i16* ; [#uses=2] %V2 = getelementptr { i16, i16 }* %tmpcast, i32 0, i32 1 ; [#uses=2] store i16 %A, i16* %V1, align 4 store i16 %B, i16* %V2 %R1 = load i16* %V1, align 4 ; [#uses=1] %R2 = load i16* %V2 ; [#uses=1] call void @bar( i16 %R1, i16 %R2 ) call void @empty( i32* %V ) ret void } Here, the alloca is replaced by an i32 alloca. This doesn't seem like an improvement to me, since now the proper uses of the struct (geps) need a bitcast first. Though this looks like a minor problem at best, it confuses scalarrepl. When I run -deadargelim -die -scalarrepl over the instcombined code (the first two to remove the i32* use and bitcast), I get the following ugly code: define void @foo(i16 %A, i16 %B) { entry: %A1 = zext i16 %A to i32 ; [#uses=1] %A12 = shl i32 %A1, 16 ; [#uses=1] %V.in.mask = and i32 undef, 65535 ; [#uses=1] %A12.ins = or i32 %V.in.mask, %A12 ; [#uses=1] %B9 = zext i16 %B to i32 ; [#uses=1] %V.in8.mask = and i32 %A12.ins, -65536 ; [#uses=1] %B9.ins = or i32 %V.in8.mask, %B9 ; [#uses=2] %R14 = lshr i32 %B9.ins, 16 ; [#uses=1] %R15 = trunc i32 %R14 to i16 ; [#uses=1] %R27 = trunc i32 %B9.ins to i16 ; [#uses=1] call void @bar( i16 %R15, i16 %R27 ) call void @empty( ) ret void } However, when I run -deadargelim -die -scalarrepl directly on the original code, I get the result I expect: define void @foo(i16 %A, i16 %B) { entry: call void @bar( i16 %A, i16 %B ) call void @empty( ) ret void } Now, I know that the shift/zext/trunc mess above might be supposed to be cleaned up by instcombine again (it isn't currently), I think that the actual problem lies with PromoteCastOfAllocation in instcombine. IMHO, the struct alloca shouldn't have been replaced with an i32 alloca in the first place. Also, in the code where I originally noticed this problem, the resulting code is more complex and less likely to be simplified again. In particular, instead of the @empty function I have a call to memmove, whose destination is passed as an argument to another function. ArgumentPromotion is able to split up this struct argument and remove the memmove, but by then the alloca is already screwed up by instcombine and scalarrepl is no longer able to properly expand it. Any comments on this problem? Do you agree that the current replacement policy of PromoteCastOfAllocation is a bit too wide? I think that some other policy should be implemented in PromoteCastOfAllocation, probably one that takes into account the number of bitcasts that can be removed and the number that would be introduced, or perhaps just refuse to change a struct alloca to an integer alloca, or... Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080908/617834b4/attachment.bin From daniel at zuster.org Mon Sep 8 11:18:34 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Mon, 8 Sep 2008 09:18:34 -0700 Subject: [LLVMdev] "has different visibility" warnings In-Reply-To: <7A1360FC-26C4-49E0-B5DC-E8ADC2CB1CDF@me.com> References: <48C1EEF4.9080701@gmail.com> <7A1360FC-26C4-49E0-B5DC-E8ADC2CB1CDF@me.com> Message-ID: <6a8523d60809080918j35a57a0ct8d635b9570e34be@mail.gmail.com> The root of the problem is that I committed the changes to apply -fvisibility-lines-hidden but that was later backed out. If you have object files built in the time in between the commit and the backing out then they will differ. A clean rebuild should get rid of the warnings. - Daniel On Fri, Sep 5, 2008 at 8:19 PM, Gordon Henriksen wrote: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016763.html > > On 2008-09-05, at 22:46, Talin wrote: > >> Recently I started getting these warnings - thousands of them - and >> I'm >> not sure what I did to cause them or how to solve them: >> >> ld: warning llvm::MemoryBuffer::getBufferStart() const has different >> visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and >> (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) >> ld: warning >> llvm::OwningPtr::OwningPtr(llvm::MemoryBuffer*)has >> different visibility (1) in >> /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in >> /usr/local/lib/libLLVMSupport.a(CommandLine.o) >> ld: warning >> llvm::OwningPtr::OwningPtr(llvm::MemoryBuffer*)has >> different visibility (1) in >> /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in >> /usr/local/lib/libLLVMSupport.a(CommandLine.o) >> ld: warning llvm::OwningPtr::~OwningPtr()has >> different visibility (1) in >> /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in >> /usr/local/lib/libLLVMSupport.a(CommandLine.o) >> ld: warning llvm::OwningPtr::~OwningPtr()has >> different visibility (1) in >> /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in >> /usr/local/lib/libLLVMSupport.a(CommandLine.o) >> ld: warning llvm::APInt::isSingleWord() consthas different visibility >> (2) in /usr/local/lib/libLLVMTarget.a(TargetData.o) and (1) in >> /usr/local/lib/libLLVMSupport.a(APFloat.o) >> ld: warning llvm::APInt::isSingleWord() consthas different visibility >> (2) in /usr/local/lib/libLLVMCore.a(Instructions.o) and (1) in >> /usr/local/lib/libLLVMSupport.a(APFloat.o) >> ld: warning llvm::APInt::getNumWords() consthas different visibility >> (2) >> in /usr/local/lib/libLLVMCore.a(Instructions.o) and (1) in >> /usr/local/lib/libLLVMSupport.a(APFloat.o) >> ld: warning llvm::APInt::clearUnusedBits() has different >> visibility >> (2) in /usr/local/lib/libLLVMCore.a(Instructions.o) and (1) in >> /usr/local/lib/libLLVMSupport.a(APFloat.o) >> >> (and so on...) Any suggestions? >> >> -- Talin >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > ? Gordon > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From daniel at zuster.org Mon Sep 8 11:23:48 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Mon, 8 Sep 2008 09:23:48 -0700 Subject: [LLVMdev] OCaml bindings to LLVM In-Reply-To: <200809060426.20303.jon@ffconsultancy.com> References: <200809060426.20303.jon@ffconsultancy.com> Message-ID: <6a8523d60809080923q735dc69eo6a8f711844417c31@mail.gmail.com> On Fri, Sep 5, 2008 at 8:26 PM, Jon Harrop wrote: > Firstly, I noticed that the execute engine is very slow, taking milliseconds > to call a JIT compiled function. Is this an inherent overhead or am I calling > it incorrectly or is this something that can be optimized in the OCaml > bindings? What is the signature of the function you are calling? When calling a generated function via runFunction, the JIT handles some common signatures but if it doesn't recognize the function signature it falls back on generating a stub function on the fly. This generation is fairly expensive and is probably the overhead you are seeing. There should be little more inherent overhead than the cost of a function call if the stub path isn't being taken. The simple solution (aside from fixing JIT) is to change your signature to match one of the ones the JIT special cases (see JIT::runFunction). A nullary one with arguments passed in globals works fine, if thread safety isn't a concern. - Daniel From mdevan.foobar at gmail.com Mon Sep 8 12:18:50 2008 From: mdevan.foobar at gmail.com (Mahadevan R) Date: Mon, 8 Sep 2008 22:48:50 +0530 Subject: [LLVMdev] [ANN] llvm-py 0.3 released. Message-ID: Hi. Version 0.3 of llvm-py, Python bindings for LLVM, has been released. llvm-py now supports reading/writing of bitcode and LLVM assembly files, intrinsics and all the transformation passes. Also included are bug fixes and documentation/test updates. Home page: http://mdevan.nfshost.com/llvm-py/ Thanks & Regards, -Mahadevan. From evan.cheng at apple.com Mon Sep 8 12:24:02 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 8 Sep 2008 10:24:02 -0700 Subject: [LLVMdev] adde/addc In-Reply-To: <48C50664.4040708@pennware.com> References: <48C50664.4040708@pennware.com> Message-ID: <4BBAC2AB-0F88-41CA-B14E-821CA4ECB3A2@apple.com> Legalizer will expand arithmetics using addc and adde. Is it not working for you? It works fine on x86, you can take a look how it's done. Evan On Sep 8, 2008, at 4:03 AM, Richard Pennington wrote: > My target doesn't support 64 bit arithmetic, so I'd like to supply > definitions for adde/addc. The problem is I can't seem to figure out > the > magic. Here's an example of what I need to generate: > > # two i64s in r5/r6 and r7/r8 > # result in r1/r2, carry in r3 > > # adde > add r2, r6, r8 > cmpltu r3, r2, r6 # compute carry > > # addc > add r1, r5, r7 > add r1, zero, r3 > > Is this possible given the current code generation stuff? Is there > another approach that I should consider? > > -Rich > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gohman at apple.com Mon Sep 8 13:08:55 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 8 Sep 2008 11:08:55 -0700 Subject: [LLVMdev] Integer questions In-Reply-To: <200809060007.52512.baldrick@free.fr> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> <200809060007.52512.baldrick@free.fr> Message-ID: <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> On Sep 5, 2008, at 3:07 PM, Duncan Sands wrote: > The current maximum the code generators support is i256. If you try > to > use bigger integers it will work fine in the bitcode, but if you try > to do code generation the compiler will crash. FYI, there is one other issue here, PR2660. While codegen in general can handle types like i256, individual targets don't always have calling convention rules to cover them. For example, returning an i128 on x86-32 or an i256 on x86-64 doesn't doesn't fit in the registers designated for returning values on those targets. Dan From gohman at apple.com Mon Sep 8 13:42:03 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 8 Sep 2008 11:42:03 -0700 Subject: [LLVMdev] Visibility warning In-Reply-To: <200809061909.03566.baldrick@free.fr> References: <200809061909.03566.baldrick@free.fr> Message-ID: Hi Duncan, Does r55922 fix this for you? Dan On Sep 6, 2008, at 10:09 AM, Duncan Sands wrote: > Unlike those happy few who are seeing thousands of visibility > warnings, I get only one with gcc 4.3: > > lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:3889: warning: > ?llvm::SDISelAsmOperandInfo? declared with greater visibility than > the type of its field ?llvm::SDISelAsmOperandInfo::AssignedRegs? > > Anyway know what this is about? > > 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 gohman at apple.com Mon Sep 8 13:53:03 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 8 Sep 2008 11:53:03 -0700 Subject: [LLVMdev] Overzealous PromoteCastOfAllocation In-Reply-To: <20080908155737.GJ32157@katherina.student.utwente.nl> References: <20080908155737.GJ32157@katherina.student.utwente.nl> Message-ID: <643C9D81-4750-48E5-B26C-C7699B04065B@apple.com> Hi Matthijs, Changing PromoteCastOfAllocation to not replace aggregate allocas with non-aggregate allocas if they have GEP users sounds reasonable to me. Finding the maximum alignment is sometimes still useful though, so it would be nice to update the alignment field of the alloca even if its type is left unchanged. Dan On Sep 8, 2008, at 8:57 AM, Matthijs Kooijman wrote: > Hi all, > > I'm currently running into some problems with instcombine changing > the type of > alloca instructions. In particular, the PromoteCastOfAllocation > looks at any > allocation instruction that is used by a bitast. > > It does a few checks, but basically tries to change the type of the > alloca > instruction to the type pointed to by the bitcasted type. The current > heuristic for determining if this is a good idea, is "do it if the > aligment of > the new type is larger than before" (Note that this is not just a > safety > check, since when the aligments are equal, the alloca is not > changed). This > heuristic seems to have been introduced to prevent infinite loops > when there > are multiple uses of the alloca. > > At first glance, changing the alloca type to remove a bitcast seems > a sensible > idea. However, the transformation seems quite ignorant of other uses > of the > alloca. It does properly update them by inserting extra bitcasts, > but in a lot > of cases, this means you can remove a single (or perhaps a few) > bitcasts, > while introducing a bunch of other bitcasts. IMHO, a better policy > is needed. > > Another problem that occurs here, is that this transformation can > replace a > struct alloca with a single integer alloca. This, in turn, can > confuse other > passes like scalarrepl, and produce but ugly code. I've assembled a > small > example of this. > > declare void @bar(i16, i16) > > define internal void @empty(i32* %X) { > ret void > } > > define void @foo(i16 %A, i16 %B) { > entry: > ;; Alloc a struct > %V = alloca {i16, i16} > ;; Save our arguments into it > %V1 = getelementptr {i16, i16}* %V, i32 0, i32 0 > %V2 = getelementptr {i16, i16}* %V, i32 0, i32 1 > store i16 %A, i16* %V1 > store i16 %B, i16* %V2 > > ;; Load the values again > %R1 = load i16* %V1 > %R2 = load i16* %V2 > ;; Pass them to an external function to make them used > call void @bar(i16 %R1, i16 %R2) > > ;; Bitcast the alloca to i32& > %V32 = bitcast {i16, i16}* %V to i32* > ;; And make it appear used (at first glance, deadargelim will > ;; can remove this use later on > call void @empty(i32* %V32) > ret void > } > > The above program does almost nothing, but contains an alloca of > {i16, i16} > which is bitcasted to i32* somewhere. This i32* appears used, but > can later be > removed (you'll see why). > > Now, when I run instcombine over this code, I get the following (other > functions left out, they are unchanged). > define void @foo(i16 %A, i16 %B) { > entry: > %V = alloca i32 ; [#uses=3] > %tmpcast = bitcast i32* %V to { i16, i16 }* ; > <{ i16, i16 }*> [#uses=1] > %V1 = bitcast i32* %V to i16* ; [#uses=2] > %V2 = getelementptr { i16, i16 }* %tmpcast, i32 0, i32 > 1 ; [#uses=2] > store i16 %A, i16* %V1, align 4 > store i16 %B, i16* %V2 > %R1 = load i16* %V1, align 4 ; [#uses=1] > %R2 = load i16* %V2 ; [#uses=1] > call void @bar( i16 %R1, i16 %R2 ) > call void @empty( i32* %V ) > ret void > } > > Here, the alloca is replaced by an i32 alloca. This doesn't seem > like an > improvement to me, since now the proper uses of the struct (geps) > need a > bitcast first. Though this looks like a minor problem at best, it > confuses > scalarrepl. > > When I run -deadargelim -die -scalarrepl over the instcombined code > (the first > two to remove the i32* use and bitcast), I get the following ugly > code: > define void @foo(i16 %A, i16 %B) { > entry: > %A1 = zext i16 %A to i32 ; [#uses=1] > %A12 = shl i32 %A1, 16 ; [#uses=1] > %V.in.mask = and i32 undef, 65535 ; [#uses=1] > %A12.ins = or i32 %V.in.mask, %A12 ; [#uses=1] > %B9 = zext i16 %B to i32 ; [#uses=1] > %V.in8.mask = and i32 %A12.ins, -65536 ; [#uses=1] > %B9.ins = or i32 %V.in8.mask, %B9 ; [#uses=2] > %R14 = lshr i32 %B9.ins, 16 ; [#uses=1] > %R15 = trunc i32 %R14 to i16 ; [#uses=1] > %R27 = trunc i32 %B9.ins to i16 ; [#uses=1] > call void @bar( i16 %R15, i16 %R27 ) > call void @empty( ) > ret void > } > > However, when I run -deadargelim -die -scalarrepl directly on the > original code, I get the result I expect: > define void @foo(i16 %A, i16 %B) { > entry: > call void @bar( i16 %A, i16 %B ) > call void @empty( ) > ret void > } > > Now, I know that the shift/zext/trunc mess above might be supposed > to be > cleaned up by instcombine again (it isn't currently), I think that > the actual > problem lies with PromoteCastOfAllocation in instcombine. IMHO, the > struct > alloca shouldn't have been replaced with an i32 alloca in the first > place. > > Also, in the code where I originally noticed this problem, the > resulting code > is more complex and less likely to be simplified again. In > particular, instead > of the @empty function I have a call to memmove, whose destination > is passed > as an argument to another function. ArgumentPromotion is able to > split up this > struct argument and remove the memmove, but by then the alloca is > already > screwed up by instcombine and scalarrepl is no longer able to > properly expand > it. > > > Any comments on this problem? Do you agree that the current > replacement policy > of PromoteCastOfAllocation is a bit too wide? > > I think that some other policy should be implemented in > PromoteCastOfAllocation, probably one that takes into account the > number of > bitcasts that can be removed and the number that would be > introduced, or > perhaps just refuse to change a struct alloca to an integer alloca, > or... > > > Gr. > > Matthijs > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gordonhenriksen at me.com Mon Sep 8 14:17:01 2008 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Mon, 08 Sep 2008 15:17:01 -0400 Subject: [LLVMdev] OCaml bindings to LLVM In-Reply-To: <200809060426.20303.jon@ffconsultancy.com> References: <200809060426.20303.jon@ffconsultancy.com> Message-ID: <4916D780-DB79-4FD0-A39F-9A1D0ED33348@me.com> On 2008-09-05, at 23:26, Jon Harrop wrote: > I'm having another play with LLVM using the OCaml bindings for a > forthcoming > OCaml Journal article and I have a couple of remarks: > > Firstly, I noticed that the execute engine is very slow, taking > milliseconds to call a JIT compiled function. Is this an inherent > overhead or am I calling it incorrectly or is this something that > can be optimized in the OCaml bindings? The high-level calling convention using GenericValue is going to be very slow relative to a native function call. This is true in C++, but even moreso in Ocaml, which must cons up a bunch of objects on the heap for each call. To get best performance, you would want to avoid fine-grained calls into JIT'd code, e.g. by iterating over inputs inside the JIT instead of outside. If you want to improve performance of the GenericValue-based interface, I'd suggest trying to minimize the number and overhead of allocations in your Ocaml code, then look at the bindings themselves: - If GenericValues can't be reused, add bindings to allow mutating them. Reuse the same 'n' instances for each call into JIT code. Yucky imperative data structures to the rescue. - Write bindings for a heap-allocated GenericValue[] and wrap that in a custom block instead of heap-allocating each GenericValue individually. Of course such an array must be mutable. More imperative data structures! - Try using placement new to initialize GenericValues inside of Ocaml blocks instead of new'ing them up on the C++ heap as is presently done. This would be outside the bounds of standard C++, so it could fail. This would require circumventing the C bindings, since such cannot expose the C++ GenericValue class as a struct. - Use Ocaml variants for inputs (type GenericValue = Pointer of 'a | Int of bits * value | ...) and convert those to a stack-based SmallVector. This will avoid finalizers on the Ocaml blocks. This doesn't work symmetrically for outputs, though. Likewise, it involves going around the C bindings. But realize that a GenericValue-based interface will always be slow relative to a native call. If you have a specific performance goal though, you may be able to cheaply eliminate 'enough' overhead for your needs without much work. All of the above are relatively simple (should be doable in a day, modulo patch review). For the very best performance, you really want to call the JIT'd function directly?e.g., let nf = native_function name m where native_function has type string -> Llvm.module -> 'a and nf has some functional type, like int -> int -> int. However, this is subject to the quirks and complexities of the Ocaml FFI (e.g., overflow arguments passed in a global array on x86, totally nonstandard calling convention). - If you know in advance the signature of the functions you're going to call, you can write shims in C (similar to those in llvm_ocaml.c) that will add not terribly much overhead. These wouldn't really be of any use to anyone else, though. - If not, you can generate the shims at runtime using LLVM (even inline them into the callee), but will have to reimplement Ocaml's FFI macros for unwrapping values and tracking stack roots. This would take considerably more effort to implement (esp. portably), but would be a substantial improvement to the bindings if the helpers were incorporated therein. > Secondly, I happened to notice that JIT compiled code executed on > the fly does not read from the stdin of the host OCaml program > although it can write to stdout. Is this a bug? This has nothing to do with LLVM. ? Gordon From TWilson at ugobe.com Mon Sep 8 15:13:31 2008 From: TWilson at ugobe.com (Tyler Wilson) Date: Mon, 8 Sep 2008 13:13:31 -0700 Subject: [LLVMdev] Questions on using LLVM to build a VM Message-ID: Good day, Firstly, I am very new to this project. I have dug through some of the documentation, but cannot find a satisfying answer to some questions I have. I hope somebody here can edify me. I am interested in embedded a LLVM 'VM' inside an embedded ARM-based device. That is, I want to be able to load and execute .bc files directly in an embedded system. The questions: - Are there any more direct examples of doing the above? - I am unclear on how the .bc is 'linked' to the external functions it calls. For example, if I have a 'print' or 'playSound' function implemented in my firmware environment, and have properly exposed it to the LLVM front-end language, how does the connection and actual function call occur at run-time? If I can get answers or pointers to answers, that should get me started. Thank you, Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080908/1b28457a/attachment-0001.html From overminddl1 at gmail.com Mon Sep 8 15:39:24 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 8 Sep 2008 14:39:24 -0600 Subject: [LLVMdev] Integer questions In-Reply-To: <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> <200809060007.52512.baldrick@free.fr> <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> Message-ID: <3f49a9f40809081339x167f0e71v2093004d11d05ab4@mail.gmail.com> On Mon, Sep 8, 2008 at 12:08 PM, Dan Gohman wrote: > FYI, there is one other issue here, PR2660. While codegen in > general can handle types like i256, individual targets don't always > have calling convention rules to cover them. For example, returning > an i128 on x86-32 or an i256 on x86-64 doesn't doesn't fit in the > registers designated for returning values on those targets. I am mostly just interested in x86 (32-bit and 64-bit) based systems, so it would choke? And how would it choke (exception thrown, some getlasterror style message passing, or what?). To ask bluntly, I would need to do bignum arithmetic in my side, rather then letting LLVM do it (since the backend would most likely not do it)? Has anyone thought about putting bignum's inside LLVM itself, LLVM would be able to generate the best things possible for a given system, and I do not mean bignum like some arbitrary sized number ala Python/Erlang/etc. number, some static sized integer would be best for my use, i2048 for example, although if there were an arbitrary length version I would put that in the language as well. Which I guess I should also ask about, how does LLVM do error handling for when something cannot be compiled for whatever reason? From haohui.mai at gmail.com Mon Sep 8 15:49:38 2008 From: haohui.mai at gmail.com (Haohui Mai) Date: Mon, 8 Sep 2008 15:49:38 -0500 Subject: [LLVMdev] Questions on using LLVM to build a VM In-Reply-To: References: Message-ID: <42F9D97C-7F30-4A56-9A47-E9508BA8AB7C@gmail.com> Tyler, I think you might be looking for a JIT in ARM architecture. It seems that it has been "out of box" in LLVM distribution already, probably you might need some work to fit them into your system. I suggest you have a look at the Kaleidoscope example. It uses a trick to make standard functions, like abs / cot available to Kaleidoscope. You might implement your system in similar way. -- Haohui On Sep 8, 2008, at 3:13 PM, Tyler Wilson wrote: > Good day, > > Firstly, I am very new to this project. I have dug through some of > the documentation, but cannot find a satisfying answer to some > questions I have. I hope somebody here can edify me. > > I am interested in embedded a LLVM ?VM? inside an embedded ARM-based > device. That is, I want to be able to load and execute .bc files > directly in an embedded system. > > The questions: > > - Are there any more direct examples of doing the above? > - I am unclear on how the .bc is ?linked? to the external > functions it calls. For example, if I have a ?print? or ?playSound? > function implemented in my firmware environment, and have properly > exposed it to the LLVM front-end language, how does the connection > and actual function call occur at run-time? > > If I can get answers or pointers to answers, that should get me > started. > > Thank you, > Tyler > _______________________________________________ > 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/20080908/dc1fbdbd/attachment.html From eli.friedman at gmail.com Mon Sep 8 15:59:06 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 8 Sep 2008 13:59:06 -0700 Subject: [LLVMdev] adde/addc In-Reply-To: <4BBAC2AB-0F88-41CA-B14E-821CA4ECB3A2@apple.com> References: <48C50664.4040708@pennware.com> <4BBAC2AB-0F88-41CA-B14E-821CA4ECB3A2@apple.com> Message-ID: On Mon, Sep 8, 2008 at 10:24 AM, Evan Cheng wrote: > Legalizer will expand arithmetics using addc and adde. Yes, but it silently assumes that addc/adde are legal! (See the ISD::ADDC case in SelectionDAGLegalize::LegalizeOp.) -Eli From gohman at apple.com Mon Sep 8 16:32:13 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 8 Sep 2008 14:32:13 -0700 Subject: [LLVMdev] Integer questions In-Reply-To: <3f49a9f40809081339x167f0e71v2093004d11d05ab4@mail.gmail.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> <200809060007.52512.baldrick@free.fr> <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> <3f49a9f40809081339x167f0e71v2093004d11d05ab4@mail.gmail.com> Message-ID: <45ADCEA9-E6B6-418C-84B9-71B979A7B4E6@apple.com> On Sep 8, 2008, at 1:39 PM, OvermindDL1 wrote: > On Mon, Sep 8, 2008 at 12:08 PM, Dan Gohman wrote: >> FYI, there is one other issue here, PR2660. While codegen in >> general can handle types like i256, individual targets don't always >> have calling convention rules to cover them. For example, returning >> an i128 on x86-32 or an i256 on x86-64 doesn't doesn't fit in the >> registers designated for returning values on those targets. > > I am mostly just interested in x86 (32-bit and 64-bit) based systems, > so it would choke? And how would it choke (exception thrown, some > getlasterror style message passing, or what?). To ask bluntly, I > would need to do bignum arithmetic in my side, rather then letting > LLVM do it (since the backend would most likely not do it)? If assertions are enabled, it will trigger an assertion failure. This particular issue is only relevant for function return values. > > > Has anyone thought about putting bignum's inside LLVM itself, LLVM > would be able to generate the best things possible for a given system, > and I do not mean bignum like some arbitrary sized number ala > Python/Erlang/etc. number, some static sized integer would be best for > my use, i2048 for example, although if there were an arbitrary length > version I would put that in the language as well. Integers like i2048 that are well beyond the reach of the register set on x86 pose additional challenges if you want efficient generated code. > > > Which I guess I should also ask about, how does LLVM do error handling > for when something cannot be compiled for whatever reason? The Verifier pass is recommended; it catches a lot of invalid stuff and be configured to abort, print an error to stderr, or return an error status and message string. It doesn't catch everything though; codegen's error handling today is usually an assertion failure, assuming assertions are enabled. Dan From rich at pennware.com Mon Sep 8 16:43:50 2008 From: rich at pennware.com (Richard Pennington) Date: Mon, 08 Sep 2008 16:43:50 -0500 Subject: [LLVMdev] adde/addc In-Reply-To: <4BBAC2AB-0F88-41CA-B14E-821CA4ECB3A2@apple.com> References: <48C50664.4040708@pennware.com> <4BBAC2AB-0F88-41CA-B14E-821CA4ECB3A2@apple.com> Message-ID: <48C59C96.1030007@pennware.com> Evan Cheng wrote: > Legalizer will expand arithmetics using addc and adde. Is it not > working for you? It works fine on x86, you can take a look how it's > done. > > Evan The x86 has a carry bit, my target doesn't. It's not clear to me how I would specify the use of a general purpose register to contain the calculated carry in the current adde/addc scheme. -Rich From scott.llvm at h4ck3r.net Mon Sep 8 16:45:29 2008 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Mon, 8 Sep 2008 14:45:29 -0700 Subject: [LLVMdev] Problems when refining type Message-ID: <84decce20809081445qb70fe6ic710ccac18f9b1ef@mail.gmail.com> Hi I'm using the llvm-c wrapper, and trying to build some recursive types (using released 2.3). I get an assert on trying to create a second opaque pointer type after refining a first. The first time through creating an opaque pointer type, a new type is created and returned from PointerType::get, but the second time, ValueType (the opaque type) is found in the PointerTypes map, which seems to cause problems. I sort of feel like it probably shouldn't be found because the opaque types should be distinct, but I also don't really understand how it ought to work, so maybe I'm way off base. ------------- #include "Core.h" int main() { LLVMTypeRef a = LLVMPointerType(LLVMOpaqueType(), 0); LLVMTypeHandleRef ha = LLVMCreateTypeHandle(a); LLVMTypeRef atypes[1] = { LLVMResolveTypeHandle(ha) }; LLVMRefineType(LLVMResolveTypeHandle(ha), LLVMStructType(atypes, 1, 0)); LLVMTypeRef b = LLVMPointerType(LLVMOpaqueType(), 0); // assert here .... } ------------- The assertion text is: Assertion failed: isa(Val) && "cast() argument of incompatible type!", file ...\llvm\include\llvm/Support/Casting.h, line 199 Can anyone explain what I'm doing wrong here? thanks, scott From scott.llvm at h4ck3r.net Mon Sep 8 18:21:14 2008 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Mon, 8 Sep 2008 16:21:14 -0700 Subject: [LLVMdev] Problems when refining type In-Reply-To: <84decce20809081445qb70fe6ic710ccac18f9b1ef@mail.gmail.com> References: <84decce20809081445qb70fe6ic710ccac18f9b1ef@mail.gmail.com> Message-ID: <84decce20809081621r72d2d401r785c039828c1c0d9@mail.gmail.com> Quick follow up on this, I tried defining DEBUG_MERGE_TYPES to see if I could figure out what was going wrong, but that made the problem disappear. Similarly, sometimes, running it in a debugger causes the assert not to trigger. Changing the test to: int main() { LLVMTypeRef x = LLVMOpaqueType(); printf("%p\n", x); LLVMTypeRef a = LLVMPointerType(x, 0); LLVMTypeHandleRef ha = LLVMCreateTypeHandle(a); LLVMTypeRef atypes[1] = { LLVMResolveTypeHandle(ha) }; LLVMRefineType(LLVMResolveTypeHandle(ha), LLVMStructType(atypes, 1, 0)); LLVMTypeRef y = LLVMOpaqueType(); printf("%p\n", y); LLVMTypeRef b = LLVMPointerType(y, 0); LLVMTypeHandleRef hb = LLVMCreateTypeHandle(b); LLVMTypeRef btypes[1] = { LLVMResolveTypeHandle(hb) }; LLVMRefineType(LLVMResolveTypeHandle(hb), LLVMStructType(btypes, 1, 0)); return 0; } made it a little more clear what was going on. When this test "works", the return value from LLVMOpaqueType() is different both times, and while PointerTypes in Type.cpp still has the old opaque type left over, it isn't found. But, since the first opaque type gets refined away (and deleted), LLVMOpaqueType can return the same pointer value twice, meaning that the PointerTypes map holding PointerValType's has a Type* that's invalid. Could anyone suggest where to try invalidating that map? (if that's the right thing to do). Or perhaps PointerValType needs to be a PATypeHolder? thanks, scott On Mon, Sep 8, 2008 at 2:45 PM, Scott Graham wrote: > Hi > > I'm using the llvm-c wrapper, and trying to build some recursive types > (using released 2.3). > > I get an assert on trying to create a second opaque pointer type after > refining a first. > > The first time through creating an opaque pointer type, a new type is > created and returned from PointerType::get, but the second time, > ValueType (the opaque type) is found in the PointerTypes map, which > seems to cause problems. I sort of feel like it probably shouldn't be > found because the opaque types should be distinct, but I also don't > really understand how it ought to work, so maybe I'm way off base. > > ------------- > #include "Core.h" > > int main() > { > LLVMTypeRef a = LLVMPointerType(LLVMOpaqueType(), 0); > LLVMTypeHandleRef ha = LLVMCreateTypeHandle(a); > LLVMTypeRef atypes[1] = { LLVMResolveTypeHandle(ha) }; > LLVMRefineType(LLVMResolveTypeHandle(ha), LLVMStructType(atypes, 1, 0)); > > LLVMTypeRef b = LLVMPointerType(LLVMOpaqueType(), 0); // assert here > .... > } > ------------- > The assertion text is: > > Assertion failed: isa(Val) && "cast() argument of incompatible > type!", file ...\llvm\include\llvm/Support/Casting.h, line 199 > > Can anyone explain what I'm doing wrong here? > > thanks, > scott > From eli.friedman at gmail.com Mon Sep 8 18:24:53 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 8 Sep 2008 16:24:53 -0700 Subject: [LLVMdev] Problems when refining type In-Reply-To: <84decce20809081445qb70fe6ic710ccac18f9b1ef@mail.gmail.com> References: <84decce20809081445qb70fe6ic710ccac18f9b1ef@mail.gmail.com> Message-ID: On Mon, Sep 8, 2008 at 2:45 PM, Scott Graham wrote: > LLVMTypeRef a = LLVMPointerType(LLVMOpaqueType(), 0); > LLVMTypeHandleRef ha = LLVMCreateTypeHandle(a); > LLVMTypeRef atypes[1] = { LLVMResolveTypeHandle(ha) }; > LLVMRefineType(LLVMResolveTypeHandle(ha), LLVMStructType(atypes, 1, 0)); > > Can anyone explain what I'm doing wrong here? It looks like a bug; the type map is somehow holding onto a stale pointer to an opaque type. That said, refining a pointer type is a very unusual operation; I'd suggest sticking to refining opaque types. -Eli From overminddl1 at gmail.com Mon Sep 8 18:30:25 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 8 Sep 2008 17:30:25 -0600 Subject: [LLVMdev] Integer questions In-Reply-To: <45ADCEA9-E6B6-418C-84B9-71B979A7B4E6@apple.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> <200809060007.52512.baldrick@free.fr> <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> <3f49a9f40809081339x167f0e71v2093004d11d05ab4@mail.gmail.com> <45ADCEA9-E6B6-418C-84B9-71B979A7B4E6@apple.com> Message-ID: <3f49a9f40809081630v192a51c1v757eb87e86ddf149@mail.gmail.com> > The Verifier pass is recommended; it catches a lot of > invalid stuff and be configured to abort, print an error to > stderr, or return an error status and message string. > > It doesn't catch everything though; codegen's error > handling today is usually an assertion failure, assuming > assertions are enabled. Was looking through some other code in LLVM, I noticed an abort(), how often do those occur as they would be *really* bad to occur in my circumstances (the couple I saw were in the JIT class) as catching the abort signal may not always be possible depending on the hosts code. Will the verifier catch things like integers that are too big for the platform that I am currently on, or will that be done by something like the JIT when it compiles it? And yea, assertions are a very large "no" in this library, especially since bad code will probably happen very often (it is effectively a scripting language, will load, compile, and run code at run time, I do expect to write out things to a cache to help future loading time though, time is not really an issue during loading, but there may be a potentially massive amount of code later on, so better safe then sorry, not to mention that code speed during execution needs to be as fast as possible, the normal scripting languages out are no where near fast enough according to tests, at least the ones that are capable of continuations) Which brings me to something else, I will create a new thread due to the massive topic change... From kapilanand2 at gmail.com Mon Sep 8 19:08:47 2008 From: kapilanand2 at gmail.com (kapil anand) Date: Mon, 8 Sep 2008 20:08:47 -0400 Subject: [LLVMdev] ARM Media Instruction Message-ID: <9f741d560809081708v381ed43ep471eec5c46718e22@mail.gmail.com> Hi, I was going through the ARM Codegen support in LLVM and noticed that Media instructions like UADD16, UADD8 are not listed in ARM Codegen tables( Specifically, ARMGenInstrNames.inc does not list these instructions). So, can ARM codegen produce media instructions or does it lack the support for them? Thanks Kapil From sgraham at gmail.com Mon Sep 8 19:19:51 2008 From: sgraham at gmail.com (Scott Graham) Date: Mon, 8 Sep 2008 17:19:51 -0700 Subject: [LLVMdev] Problems when refining type In-Reply-To: References: <84decce20809081445qb70fe6ic710ccac18f9b1ef@mail.gmail.com> Message-ID: <84decce20809081719r7701b6deqb281ad6d19c79b67@mail.gmail.com> >> Can anyone explain what I'm doing wrong here? > > It looks like a bug; the type map is somehow holding onto a stale > pointer to an opaque type. That said, refining a pointer type is a > very unusual operation; I'd suggest sticking to refining opaque types. Ah, that would be it. Thanks! Could I suggest adding: assert(NewType->getTypeID() != PointerTyID && "Should not be refining pointer type!"); to DerivedType::refineAbstractTypeTo(const Type *NewType) if/because refining pointers makes no sense? scott From overminddl1 at gmail.com Mon Sep 8 19:24:00 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 8 Sep 2008 18:24:00 -0600 Subject: [LLVMdev] Tail-calling Message-ID: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> You can skip this first and second paragraph if you just want to get to the description, the 'real' question I want is the bottom most paragraph and may still make enough sense to read without reading everything else, but there are a few other hidden questions and opinions being asked in the rest of it. In this little scripting language I am making is basically going to be a C with Actors (like how C++ started out essentially as C with Classes). Just as C++ is not a 'real' OO style (little tid-bit, the person who originally coined object-oriented programming was actually talking about something like the Actor-oriented programming, but I am using common terms here), but it is 'enough' to make things useful, I am going to put in just enough Actor type stuff to make it useful, while trying to retain as much speed as possible. For the sake of the Actor model I need to strip out a lot of standard C constructs (no more mutable globals for example) so I am basically just keeping the C syntax (I may still allow mutable globals, just may trust the coder to 'do-the-right-thing', and otherwise give plenty of warnings to scare away the newbies). The purpose of this little scripting language is to do a lot of math processing (and other light-weight event handling and such), but it needs to scale, not just to multiple cores, but multiple computers. I already have a back-end written in C++ for this that I use for C++ apps (with a ton of scaffolding, the purpose of this little language is to get rid of the ugly scaffolding and make it into something pleasant to write, while allowing other users of my app to code for it as well) as well as a design structure of how the system will work, so the 'hard' part is pretty done, now it is time for the tedious part. On the level of the language, not the implementation, I plan on having two types of functions in this app, one will function like normal C function, return, arguments, etc., nothing special, the second type will basically have no return value (when it returns it 'ends', will be cleared up shortly, however tasklet calls later on the stack can return values, but the 'main' tasklet function, the one that when it returns the tasklet dies, it cannot have a return value). There will be a couple built-in functions in the language (most likely only 3, the rest will be built from those inside the language itself, these 3 will hereafter be referred to as switching functions) that will be capable of 'suspending' a (using Stackless Python terminology here) tasklet and switching to something else. A tasklet will be created by an explicit call, passing in the function that will run the tasklet. Internally normal functions will be as normal, nothing special. The tasklet style functions are unique, basically a function will be a tasklet capable function if it has one of those switching functions anywhere down in its calling queue. Normal functions cannot call tasklet functions, but tasklet function can call normal function. A switch occurs when an explicit switching call is made, or the bottom-most tasklet function on the tasklet stack returns. When a switch occurs, one of two things will happen depending on the what the scheduler that it is assigned to wants to do, it will either (at the llvm level) return, or it will tail-call another tasklet function, which at the llvm level means calling the function of a tasklet that is defined to be the continuation function. As you can probably now see from the design, this relies on (proper) tail-calls working... all the time. When the code is compiled, normal functions are as normal, but tasklet functions, if they call a normal function, will call it as normal, registers, stack, everything. However, if a tasklet function calls another tasklet function, then at the LLVM level the function will be split into a couple functions (with further split happening if there are more tasklet function calls later on) where the function will become a tail-call. At this point, refer to the link http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt that I am using as a basis, although with some minor changes in passed around data. First difference, I am not using a garbage collector (not at this moment anyway, and the design of the language may not require that I need one at all actually, most things will be on the fake tasklet stack, which is managed by the scheduler, the rest will mostly just be messages, which will be managed internally by a different system, I originally made those behind the scenes systems for C++). The rest is pretty similar, except that I have two styles in mind, one is much different then what he put. Since the tasklet functions cannot be called from a function pointer, only compiled in directly, and since normal functions can still be called any which way since they will always return before a switch happens anyway (otherwise they would have been a tasklet function), I will know exactly how much memory a whole tasklet call stack will need down to its deepest point. I also do not work toward recursion for looping, it will still be C++ style for that, so tail-call optimization inside the language itself is not necessary. Because of this though, I have two 'obvious' ways to manage the memory for a tasklet. First, I can do it of the sabre method and allocate (from the scheduler) the memory for each continuation individually as they occur, seems overly costly and inefficient, especially since I have all necessary information, however it is nice in that all necessary memory is not allocated all at once, in other words, only the memory being used will be allocated, no 'dead-weight'. The second method is to allocate all the memory a tasklet will need down to its deepest tasklet call on its call stack (which in the generic case will still not be that much, probably a few hundred bytes max in the general case considering the system I will be using this on). This should be faster due to the lack of needing to get memory for each tasklet function invocation, but it will have 'dead-weight' in the parts of it that are unused, so potentially a tasklet stack could be very light, except for one deep call that may need a few kb or few hundred kb of space down in a function that may only be called once on that callstack, so there would be a tremendous amount of unused memory during the rest of the life of that tasklet. However, I could combine the two method, either by doing it through the compiler (heuristically guessing?), or perhaps an explicit language syntax such as a qualifier for the function declaration (I would think the full allocation one would be the norm, but perhaps on a deep function that may need lots of memory, and still switch, it would be defined to only allocate that memory upon its creation), or perhaps a slightly different way of calling the function (so instead of it being function defined, it could be caller defined, would give more control so it could be used better depending on the circumstance, but that is generally more work for the coder, it is language design and not really relevant here, but I am curious on thoughts regardless). The broken (non-first, the second and on) tasklet function signature would probably just be something along the lines of: schedulerRelevantEnum aTaskletFunctionName(topOfStackOrContinuationPtr *ptr, someType ReturnValueFromFunctionBreak) Basically it would follow sabre's document in this regard pretty closely. The top most call of a tasklet function (before splitting) would not contain the return value (since something is calling it, nor would other tasklet function calls that return nothing. As stated though, it is pretty identical to sabres method in the above link, use it, and if the nameserver is down again use the Google cache at http://google.com/search?q=cache:http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt&hl=en&rlz=1C1GGLS_enUS291&sa=G&strip=1 So, the main question, is this style now feasible on modern x86 (32 and 64 bit) based systems (both *nix and Windows based) good for LLVM? In other words, are tail-calls always working now when the function call happens at the end, even if the function is being called through a function pointer (are tail-calls on function pointers working correctly right now, or is this whole project but for naught till later)? From gohman at apple.com Mon Sep 8 19:59:16 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 8 Sep 2008 17:59:16 -0700 Subject: [LLVMdev] Integer questions In-Reply-To: <3f49a9f40809081630v192a51c1v757eb87e86ddf149@mail.gmail.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> <200809060007.52512.baldrick@free.fr> <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> <3f49a9f40809081339x167f0e71v2093004d11d05ab4@mail.gmail.com> <45ADCEA9-E6B6-418C-84B9-71B979A7B4E6@apple.com> <3f49a9f40809081630v192a51c1v757eb87e86ddf149@mail.gmail.com> Message-ID: <4BCAAD07-7E64-431F-955E-CD7FE4B90CE2@apple.com> On Sep 8, 2008, at 4:30 PM, OvermindDL1 wrote: >> The Verifier pass is recommended; it catches a lot of >> invalid stuff and be configured to abort, print an error to >> stderr, or return an error status and message string. >> >> It doesn't catch everything though; codegen's error >> handling today is usually an assertion failure, assuming >> assertions are enabled. > > Was looking through some other code in LLVM, I noticed an abort(), how > often do those occur as they would be *really* bad to occur in my > circumstances (the couple I saw were in the JIT class) as catching the > abort signal may not always be possible depending on the hosts code. > > Will the verifier catch things like integers that are too big for the > platform that I am currently on, or will that be done by something > like the JIT when it compiles it? No, the verifier currently does not know about target-specific codegen limitations. > > And yea, assertions are a very large "no" in this library, especially > since bad code will probably happen very often Patches to do the kind of checking you're asking about would be welcome :-). I don't think it makes sense to extend the Verifier itself here; it's supposed to accept any valid LLVM IR. I think a separate CodeGenVerifier might be a good approach though, or possibly extending codegen itself with the ability to interrupt itself and yield some kind of error status. Dan From overminddl1 at gmail.com Mon Sep 8 21:08:35 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 8 Sep 2008 20:08:35 -0600 Subject: [LLVMdev] Integer questions In-Reply-To: <4BCAAD07-7E64-431F-955E-CD7FE4B90CE2@apple.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> <200809060007.52512.baldrick@free.fr> <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> <3f49a9f40809081339x167f0e71v2093004d11d05ab4@mail.gmail.com> <45ADCEA9-E6B6-418C-84B9-71B979A7B4E6@apple.com> <3f49a9f40809081630v192a51c1v757eb87e86ddf149@mail.gmail.com> <4BCAAD07-7E64-431F-955E-CD7FE4B90CE2@apple.com> Message-ID: <3f49a9f40809081908r358919bdoab28b3dc7fda71c2@mail.gmail.com> > Patches to do the kind of checking you're asking about would be > welcome :-). I don't think it makes sense to extend the > Verifier itself here; it's supposed to accept any valid LLVM IR. > I think a separate CodeGenVerifier might be a good approach > though, or possibly extending codegen itself with the ability to > interrupt itself and yield some kind of error status. And I presume you all are allergic to exceptions, since I have seen none so far (probably due to help the C bindings and such), return error codes all over the place then? If I do any extension on this (short on time, so good chance I cannot, but if I do) the usual non-exception style I use is the return value is a status code, the last argument passed in is an optional std::string* (the return code gives the basic error reason, the string gives details), anything that actually needs to be returned are the first arguments as references/pointers, would that work? From overminddl1 at gmail.com Mon Sep 8 21:18:55 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 8 Sep 2008 20:18:55 -0600 Subject: [LLVMdev] Integer questions In-Reply-To: <3f49a9f40809081908r358919bdoab28b3dc7fda71c2@mail.gmail.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> <200809060007.52512.baldrick@free.fr> <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> <3f49a9f40809081339x167f0e71v2093004d11d05ab4@mail.gmail.com> <45ADCEA9-E6B6-418C-84B9-71B979A7B4E6@apple.com> <3f49a9f40809081630v192a51c1v757eb87e86ddf149@mail.gmail.com> <4BCAAD07-7E64-431F-955E-CD7FE4B90CE2@apple.com> <3f49a9f40809081908r358919bdoab28b3dc7fda71c2@mail.gmail.com> Message-ID: <3f49a9f40809081918w3ea3baa5t137a231cf9713691@mail.gmail.com> Do note though, that would cause an interface breaking change (just in the function signatures, but still). An alternate would be to just pass in a struct that the user can subclass to perform their own error reporting, call a certain function in it or so before it finally bails out, it puts a level of indirection so if someone wants to recover they will have to use their own variables stored somewhere, so it is much more ugly and would not work well with C style bindings, whereas the interface breaking change would. Or are there any other styles that are preferred? On Mon, Sep 8, 2008 at 8:08 PM, OvermindDL1 wrote: >> Patches to do the kind of checking you're asking about would be >> welcome :-). I don't think it makes sense to extend the >> Verifier itself here; it's supposed to accept any valid LLVM IR. >> I think a separate CodeGenVerifier might be a good approach >> though, or possibly extending codegen itself with the ability to >> interrupt itself and yield some kind of error status. > > And I presume you all are allergic to exceptions, since I have seen > none so far (probably due to help the C bindings and such), return > error codes all over the place then? If I do any extension on this > (short on time, so good chance I cannot, but if I do) the usual > non-exception style I use is the return value is a status code, the > last argument passed in is an optional std::string* (the return code > gives the basic error reason, the string gives details), anything that > actually needs to be returned are the first arguments as > references/pointers, would that work? > From eli.friedman at gmail.com Mon Sep 8 21:44:38 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 8 Sep 2008 19:44:38 -0700 Subject: [LLVMdev] Tail-calling In-Reply-To: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> Message-ID: On Mon, Sep 8, 2008 at 5:24 PM, OvermindDL1 wrote: > In other words, are tail-calls always working now when the function > call happens at the end, even if the function is being called through > a function pointer (are tail-calls on function pointers working > correctly right now, or is this whole project but for naught till > later)? Tail calls are disabled by default; to enable them, you have to pass -tailcallopt to llc. It looks like there's a bug preventing indirect tail calls from working... I don't think there's anything fundamentally preventing them from working, though. -Eli From regehr at cs.utah.edu Mon Sep 8 23:55:12 2008 From: regehr at cs.utah.edu (John Regehr) Date: Mon, 08 Sep 2008 22:55:12 -0600 Subject: [LLVMdev] compiler code coverage Message-ID: <48C601B0.2060704@cs.utah.edu> I ran across these awesome coverage reports for llvm: http://chandlerc.net/llvm-coverage/ Anyone interested in seeing how much of a coverage increase is gotten by compiling random programs? http://www.cs.utah.edu/~eeide/emsoft08/ It may be profitable to create a new category of programs in the test suite: random programs that cause otherwise-uncovered parts of the compiler to execute. John From evan.cheng at apple.com Tue Sep 9 01:05:12 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 8 Sep 2008 23:05:12 -0700 Subject: [LLVMdev] ARM Media Instruction In-Reply-To: <9f741d560809081708v381ed43ep471eec5c46718e22@mail.gmail.com> References: <9f741d560809081708v381ed43ep471eec5c46718e22@mail.gmail.com> Message-ID: <216DC355-C14A-43BF-BBF2-47552DD09D03@apple.com> Hi, They are not currently support. Patches welcome! Evan On Sep 8, 2008, at 5:08 PM, kapil anand wrote: > Hi, > > I was going through the ARM Codegen support in LLVM and noticed that > Media instructions like UADD16, UADD8 are not listed in ARM Codegen > tables( Specifically, ARMGenInstrNames.inc does not list these > instructions). > > So, can ARM codegen produce media instructions or does it lack the > support for them? > > Thanks > > > Kapil > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Tue Sep 9 01:08:47 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 8 Sep 2008 23:08:47 -0700 Subject: [LLVMdev] adde/addc In-Reply-To: <48C59C96.1030007@pennware.com> References: <48C50664.4040708@pennware.com> <4BBAC2AB-0F88-41CA-B14E-821CA4ECB3A2@apple.com> <48C59C96.1030007@pennware.com> Message-ID: You may have to custom lower i64 arithmetics. You can make use of "flag" outputs to ensure the instructions are generated in the order you want. The instruction which produces a flag value and the user of the flag are "glued" together. They are scheduled as a single unit and nothing else can be scheduled in between. Evan On Sep 8, 2008, at 2:43 PM, Richard Pennington wrote: > Evan Cheng wrote: >> Legalizer will expand arithmetics using addc and adde. Is it not >> working for you? It works fine on x86, you can take a look how it's >> done. >> >> Evan > > The x86 has a carry bit, my target doesn't. > > It's not clear to me how I would specify the use of a general purpose > register to contain the calculated carry in the current adde/addc > scheme. > > -Rich > _______________________________________________ > 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 Sep 9 02:06:52 2008 From: baldrick at free.fr (Duncan Sands) Date: Tue, 9 Sep 2008 09:06:52 +0200 Subject: [LLVMdev] Visibility warning In-Reply-To: References: <200809061909.03566.baldrick@free.fr> Message-ID: <200809090906.53098.baldrick@free.fr> > Does r55922 fix this for you? Yes it does. Ciao, Duncan. From baldrick at free.fr Tue Sep 9 02:21:14 2008 From: baldrick at free.fr (Duncan Sands) Date: Tue, 9 Sep 2008 09:21:14 +0200 Subject: [LLVMdev] compiler code coverage In-Reply-To: <48C601B0.2060704@cs.utah.edu> References: <48C601B0.2060704@cs.utah.edu> Message-ID: <200809090921.14362.baldrick@free.fr> > Anyone interested in seeing how much of a coverage increase is gotten by > compiling random programs? > > http://www.cs.utah.edu/~eeide/emsoft08/ Sure! > It may be profitable to create a new category of programs in the test > suite: random programs that cause otherwise-uncovered parts of the > compiler to execute. Yes, that would be great. However it would be better if they were bitcode rather than C. Ciao, Duncan. From overminddl1 at gmail.com Tue Sep 9 03:19:32 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 9 Sep 2008 02:19:32 -0600 Subject: [LLVMdev] Tail-calling In-Reply-To: References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> Message-ID: <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> > Tail calls are disabled by default; to enable them, you have to pass > -tailcallopt to llc. It looks like there's a bug preventing indirect > tail calls from working... I don't think there's anything > fundamentally preventing them from working, though. I will not be using llc, it will all be through the C++ API. I looked through the code a bit, but could not see any real direct way to turn on tall-calls, the only thing I could really find was a single global (yes, a global... ugh...) that many things referenced, if I set that then things should use tail-call versions of things. What about this indirect bug, is anyone working on it? I would try, but I am quite certain I do not yet have the LLVM internals knowledge to (or even where to look). From nunoplopes at sapo.pt Tue Sep 9 06:51:38 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Tue, 09 Sep 2008 12:51:38 +0100 Subject: [LLVMdev] missed optimizations Message-ID: <20080909125138.10854h6e5ruvp9hk@w9.mail.sapo.pt> ----- Mensagem encaminhada de MAILER-DAEMON at sapo.pt ----- Ok, thank you all for your explanations! I'll try to implement those improvements in the coming days. Thanks, Nuno ----- Original Message ----- >> Hi, >> >> I have two questions about optimizations performed by llvm. >> >> Consider these simple functions: >> int x(int b) { return b?4:6; } >> int y() { return x(0); } >> >> int x2() { return 5; } >> int y2() { return x2(); } >> >> the optimized bitcode (with clang + opt -std-compiler-opts) is: >> define i32 @y(...) nounwind { >> entry: >> ret i32 6 >> } >> >> define i32 @y2(...) nounwind { >> entry: >> %call = call i32 (...)* @x2( ) ; [#uses=0] >> ret i32 5 >> } >> >> So why does LLVM optimizes the more difficult case, but leaves behind the >> function call in the easiest case? :) > > Pretty simple: LLVM doesn't know how to eliminate the call. > > There are a couple of ways it could be eliminated: DCE or inlining. > The current DCE infrastructure isn't clever enough to do > interprocedural analysis, so that doesn't eliminate it. And the > inliner immediately gives up on varargs functions, so that doesn't > eliminate it. And > > That said, clang really should be turning int x2() { return x(0); } > into "define i32 @x2()" rather than "define i32 @x2(...)"; the > function isn't varargs, and marking it as such could lead to wrong > code for exotic calling conventions. > >> >> Second question: >> int f(); >> >> int g() { >> if (f() == 5) return 3; >> return 4; >> } >> >> int h() { >> if (g() == 6) return 2; >> return 1; >> } >> >> gives the following optimized bc: >> >> define i32 @g(...) nounwind { >> entry: >> %call = call i32 (...)* @f( ) ; [#uses=1] >> %cmp = icmp eq i32 %call, 5 ; [#uses=1] >> %retval = select i1 %cmp, i32 3, i32 4 ; [#uses=1] >> ret i32 %retval >> } >> >> define i32 @h(...) nounwind { >> entry: >> %call = call i32 (...)* @g( ) ; [#uses=1] >> %cmp = icmp eq i32 %call, 6 ; [#uses=1] >> %retval = select i1 %cmp, i32 2, i32 1 ; [#uses=1] >> ret i32 %retval >> } >> >> In function h(), llvm doesn't realize that g() never returns 6, and thus >> it >> could reduce that function to { g(); return 1; }. Doesn't llvm produce >> some >> sort of summary for functions with e.g. their possible return values? If >> not, is there any pass where I could implement this? (I have some code >> that >> has many opportunities for this kind of optimization) > > No, there isn't any such infrastructure at the moment. The LLVM pass > that might do that sort of thing is predsimplify, but it isn't an > interprocedural pass. It's not necessarily difficult to implement, > depending on how precise you want it to be, but nobody's implemented > it; as far as I know, it doesn't provide significant benefits for > normal C/C++ code. If there's some specific pattern in your code, you > could probably throw together a specialized pass pretty quickly. > >> Also, shouldn't the function g() get inlined in the h() function? It is >> inlined only if I change the g() function to be static. So isn't llvm >> being >> too conservative when inlining global functions? > > The inliner doesn't like varargs; see above. > > -Eli ----- Finalizar mensagem encaminhada ----- From rich at pennware.com Tue Sep 9 07:02:28 2008 From: rich at pennware.com (Richard Pennington) Date: Tue, 09 Sep 2008 07:02:28 -0500 Subject: [LLVMdev] adde/addc In-Reply-To: <48C50AE6.6000900@googlemail.com> References: <48C50664.4040708@pennware.com> <48C50AE6.6000900@googlemail.com> Message-ID: <48C665D4.1020701@pennware.com> Richard Osborne wrote: [snip] > ExpandADDSUB(SDNode *N, SelectionDAG &DAG) > { > assert(N->getValueType(0) == MVT::i64 && > (N->getOpcode() == ISD::ADD || N->getOpcode() == ISD::SUB) && > "Unknown operand to lower!"); > > // Extract components > SDOperand LHSL = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, > N->getOperand(0), > DAG.getConstant(0, MVT::i32)); > SDOperand LHSH = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, > N->getOperand(0), > DAG.getConstant(1, MVT::i32)); > SDOperand RHSL = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, > N->getOperand(1), > DAG.getConstant(0, MVT::i32)); > SDOperand RHSH = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, > N->getOperand(1), > DAG.getConstant(1, MVT::i32)); > > // Expand > SDOperand Lo = DAG.getNode(N->getOpcode(), MVT::i32, LHSL, RHSL); > > ISD::CondCode CarryCC = (N->getOpcode() == ISD::ADD) ? ISD::SETULT : > ISD::SETUGT; > SDOperand Carry = DAG.getSetCC(MVT::i32, Lo, LHSL, CarryCC); > > SDOperand Hi = DAG.getNode(N->getOpcode(), MVT::i32, LHSH, Carry); > Hi = DAG.getNode(N->getOpcode(), MVT::i32, Hi, RHSH); > // Merge the pieces > return DAG.getNode(ISD::BUILD_PAIR, MVT::i64, Lo, Hi).Val; > } > Thanks for the help! For me (with current LLVM) it became: SDValue Nios2TargetLowering:: ExpandADDSUB(SDValue Op, SelectionDAG &DAG) { assert(Op.getValueType() == MVT::i64 && (Op.getOpcode() == ISD::ADD || Op.getOpcode() == ISD::SUB) && "Unknown operand to lower!"); // Extract components SDValue LHSL = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, Op.getOperand(0), DAG.getConstant(0, MVT::i32)); SDValue LHSH = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, Op.getOperand(0), DAG.getConstant(1, MVT::i32)); SDValue RHSL = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, Op.getOperand(1), DAG.getConstant(0, MVT::i32)); SDValue RHSH = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, Op.getOperand(1), DAG.getConstant(1, MVT::i32)); // Expand SDValue Lo = DAG.getNode(Op.getOpcode(), MVT::i32, LHSL, RHSL); ISD::CondCode CarryCC = (Op.getOpcode() == ISD::ADD) ? ISD::SETULT : ISD::SETUGT; SDValue Carry = DAG.getSetCC(MVT::i32, Lo, LHSL, CarryCC); SDValue Hi = DAG.getNode(Op.getOpcode(), MVT::i32, LHSH, Carry); Hi = DAG.getNode(Op.getOpcode(), MVT::i32, Hi, RHSH); // Merge the pieces return DAG.getNode(ISD::BUILD_PAIR, MVT::i64, Lo, Hi); } -Rich From criswell at cs.uiuc.edu Tue Sep 9 14:13:53 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 09 Sep 2008 14:13:53 -0500 Subject: [LLVMdev] xcodebuild and LLVM In-Reply-To: References: <48BF0BD0.2070609@cs.uiuc.edu> Message-ID: <48C6CAF1.2040100@cs.uiuc.edu> Dear Ted and All, Thanks. This has helped some. However, I'm now getting errors from libtool about an object being modified after free. Is libtool supposed to work with LLVM bitcode files? If so, would grabbing the latest source potentially fix the problem (I'm currently using XCode 3.1), or will I need a way to convince xcodebuild to use something other than libtool? -- John T. Ted Kremenek wrote: > On Sep 3, 2008, at 3:12 PM, John Criswell wrote: > > >> Dear All, >> >> Is there a way to convince xcodebuild to build bitcode files for LLVM >> for an arbitrary Xcode project? So far, I've been able to get >> xcodebuild to use LLVM by installing XCode 3.1 and using CC="llvm-gcc" >> on the command line. I've also managed to get LLVM bitcode generates >> for intermediate files by using "CC="lvm-gcc -emit-llvm"; however, >> this >> gives an error during linking stating that ld does not understand the >> -emit-llvm option. >> >> Thanks in advance. >> >> -- John T. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > In addition to specifying CC, xcodebuild also consults the environment > variables LD and LDPLUSPLUS for your linker commands (for C and C++ > sources respectively). I would try LD=llvm-gcc and LDPLUSPLUS=llvm-g+ > + respectively. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From gohman at apple.com Tue Sep 9 21:37:06 2008 From: gohman at apple.com (Dan Gohman) Date: Tue, 9 Sep 2008 19:37:06 -0700 Subject: [LLVMdev] Integer questions In-Reply-To: <3f49a9f40809081918w3ea3baa5t137a231cf9713691@mail.gmail.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> <200809060007.52512.baldrick@free.fr> <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> <3f49a9f40809081339x167f0e71v2093004d11d05ab4@mail.gmail.com> <45ADCEA9-E6B6-418C-84B9-71B979A7B4E6@apple.com> <3f49a9f40809081630v192a51c1v757eb87e86ddf149@mail.gmail.com> <4BCAAD07-7E64-431F-955E-CD7FE4B90CE2@apple.com> <3f49a9f40809081908r358919bdoab28b3dc7fda71c2@mail.gmail.com> <3f49a9f40809081918w3ea3baa5t137a231cf9713691@mail.gmail.com> Message-ID: <37DB2460-70B0-44EF-BA18-94EC460E321F@apple.com> On Sep 8, 2008, at 7:18 PM, OvermindDL1 wrote: > Do note though, that would cause an interface breaking change (just in > the function signatures, but still). An alternate would be to just > pass in a struct that the user can subclass to perform their own error > reporting, call a certain function in it or so before it finally bails > out, it puts a level of indirection so if someone wants to recover > they will have to use their own variables stored somewhere, so it is > much more ugly and would not work well with C style bindings, whereas > the interface breaking change would. Or are there any other styles > that are preferred? I agree; having an abstract class interface for users to subclass sounds like over-engineering here. > > > On Mon, Sep 8, 2008 at 8:08 PM, OvermindDL1 > wrote: >>> Patches to do the kind of checking you're asking about would be >>> welcome :-). I don't think it makes sense to extend the >>> Verifier itself here; it's supposed to accept any valid LLVM IR. >>> I think a separate CodeGenVerifier might be a good approach >>> though, or possibly extending codegen itself with the ability to >>> interrupt itself and yield some kind of error status. >> >> And I presume you all are allergic to exceptions, since I have seen >> none so far (probably due to help the C bindings and such), return >> error codes all over the place then? If I do any extension on this >> (short on time, so good chance I cannot, but if I do) the usual >> non-exception style I use is the return value is a status code, the >> last argument passed in is an optional std::string* (the return code >> gives the basic error reason, the string gives details), anything >> that >> actually needs to be returned are the first arguments as >> references/pointers, would that work? I don't know what the best approach is. It would need to be something that doesn't interfere with users who don't need it, and presumably it would need to be good enough to meet your needs. Dan From dyson at akya.co.uk Wed Sep 10 04:33:37 2008 From: dyson at akya.co.uk (Dyson Wilkes) Date: Wed, 10 Sep 2008 10:33:37 +0100 Subject: [LLVMdev] ReplaceUses: curious Message-ID: <48C79471.9080401@akya.co.uk> Hi I am looking at some of the existing targets to try to understand more about writing a backend. I was a little puzzled by the use of a method ReplaceUses in *ISelDAGToDAG.cpp (*= most targets, e.g. ARM, X86..). I found its definition in the *GenDAGISel.inc file that is autogenerated from the target description. I can only assume TableGen emits this method definition for every traget. Is this method implementation, in some way that I cannot see, specific to a given target? I cannot see a reason for it not being a method of SelectionDAGISel and just implemented once? Whilst the existing targets do offer a newcomer to LLWM a template to writing a new backend, can anyone point me to other sources of information to help me get up and running more quickly. I have read the various LLVM documents but, for example, the Writing an LLVM Backend and TableGen documents are rather high level. Am I going about this in the best way, i.e. trawling through the code and doxygen documents etc? Am I missing something? Thanks for any help you can give, - Dyson From jonathandeanharrop at googlemail.com Mon Sep 8 14:10:46 2008 From: jonathandeanharrop at googlemail.com (Jon Harrop) Date: Mon, 8 Sep 2008 20:10:46 +0100 Subject: [LLVMdev] OCaml bindings to LLVM In-Reply-To: <6a8523d60809080923q735dc69eo6a8f711844417c31@mail.gmail.com> References: <200809060426.20303.jon@ffconsultancy.com> <6a8523d60809080923q735dc69eo6a8f711844417c31@mail.gmail.com> Message-ID: <200809082010.47024.jon@ffconsultancy.com> On Monday 08 September 2008 17:23:48 Daniel Dunbar wrote: > On Fri, Sep 5, 2008 at 8:26 PM, Jon Harrop > > wrote: > > Firstly, I noticed that the execute engine is very slow, taking > > milliseconds to call a JIT compiled function. Is this an inherent > > overhead or am I calling it incorrectly or is this something that can be > > optimized in the OCaml bindings? > > What is the signature of the function you are calling? unit -> unit So I am passing zero arguments and returning void. > When calling a generated function via runFunction, the JIT handles some > common signatures but if it doesn't recognize the function signature it > falls back on generating > a stub function on the fly. This generation is fairly expensive and is > probably the overhead > you are seeing. There should be little more inherent overhead than the > cost of a function > call if the stub path isn't being taken. > > The simple solution (aside from fixing JIT) is to change your > signature to match one > of the ones the JIT special cases (see JIT::runFunction). A nullary > one with arguments > passed in globals works fine, if thread safety isn't a concern. I see. Looking at JIT::runFunction, passing one dummy int32 argument should do the trick. I'll see if I can write something a little cleverer on the OCaml side to run-time compile stubs either so that partial application can be used to share them or just memoize to reuse them. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e From jonathandeanharrop at googlemail.com Mon Sep 8 15:47:15 2008 From: jonathandeanharrop at googlemail.com (Jon Harrop) Date: Mon, 8 Sep 2008 21:47:15 +0100 Subject: [LLVMdev] OCaml bindings to LLVM In-Reply-To: <4916D780-DB79-4FD0-A39F-9A1D0ED33348@me.com> References: <200809060426.20303.jon@ffconsultancy.com> <4916D780-DB79-4FD0-A39F-9A1D0ED33348@me.com> Message-ID: <200809082147.15885.jon@ffconsultancy.com> On Monday 08 September 2008 20:17:01 Gordon Henriksen wrote: > On 2008-09-05, at 23:26, Jon Harrop wrote: > > I'm having another play with LLVM using the OCaml bindings for a > > forthcoming > > OCaml Journal article and I have a couple of remarks: > > > > Firstly, I noticed that the execute engine is very slow, taking > > milliseconds to call a JIT compiled function. Is this an inherent > > overhead or am I calling it incorrectly or is this something that > > can be optimized in the OCaml bindings? > > The high-level calling convention using GenericValue is going to be > very slow relative to a native function call. This is true in C++, but > even moreso in Ocaml, which must cons up a bunch of objects on the > heap for each call. Unless tens of thousands of allocations are made for every call, I do not believe that explains the performance discrepancy I quantified. A millisecond is a long time in this context. Does it spawn or fork a process? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e From Micah.Villmow at amd.com Wed Sep 10 14:18:47 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 10 Sep 2008 12:18:47 -0700 Subject: [LLVMdev] Determining the names of all the functions in a module Message-ID: <0F538B3E30A440469A53C9CC35C225EB039676F1@ssanexmb1.amd.com> I am attemping to figure out how to access the function names that are stored in a module so that I know which function I am currently in. I am attempting to write a backend that targets a language that only allows integer function names and I need to create mapping between the string and the integer. I've looked in the header files but I cannot determine how to extract the function name from either a Function object or a Module. Any tips or ideas would be greatly appreciated. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080910/a356143b/attachment.html From julio.martin.hidalgo at gmail.com Wed Sep 10 14:39:26 2008 From: julio.martin.hidalgo at gmail.com (Julio) Date: Wed, 10 Sep 2008 21:39:26 +0200 Subject: [LLVMdev] Determining the names of all the functions in a module In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB039676F1@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB039676F1@ssanexmb1.amd.com> Message-ID: <832eb8bb0809101239s140873fdqa278e45513253449@mail.gmail.com> Hello, since I know, you can use getFunctionList or a function iterator (begin & end) on the Module, and then use getName on the Function object (you can get the name from any object that inherits from Value). Bye. 2008/9/10 Villmow, Micah > I am attemping to figure out how to access the function names that are > stored in a > > module so that I know which function I am currently in. I am attempting to > write a > > backend that targets a language that only allows integer function names and > I need > > to create mapping between the string and the integer. I've looked in the > header files > > but I cannot determine how to extract the function name from either a > Function object > > or a Module. > > > > Any tips or ideas would be greatly appreciated. > > > > Thanks, > > > > Micah Villmow > > Systems Engineer > > Advanced Technology & Performance > > Advanced Micro Devices Inc. > > 4555 Great America Pkwy, > > Santa Clara, CA. 95054 > > P: 408-572-6219 > > F: 408-572-6596 > > > > _______________________________________________ > 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/20080910/7d7e5e91/attachment.html From Micah.Villmow at amd.com Wed Sep 10 16:35:14 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 10 Sep 2008 14:35:14 -0700 Subject: [LLVMdev] Custom Lowering and fneg Message-ID: <0F538B3E30A440469A53C9CC35C225EB039677B6@ssanexmb1.amd.com> So, I have this small test program that I figured would cause no problems but want to test all the various data types and operations with my modified sparc backend. I've been working on LLVM for about 3 days now, so this might be a problem with not knowing enough yet, so thanks for bearing with me. The code that I based my example off of is compiled to LLVM-IR from: void test_unary_op_anegate(float x, float* result) { *result = (-x); } Generating the following LLVM IR: define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) nounwind { entry: %neg = sub float -0.000000e+000, %x ; [#uses=1] store float %neg, float addrspace(11)* %result ret void } However, when I attempt to run it through my backend which can handle binary math ops correctly I keep asserting on the following item. Cannot yet select: 017B8010: i32 = fneg 017B7E78 What I cannot figure out is why it is attempting to pattern match on an i32 when there are no i32's in my test program. I've tried a custom lowering function that lowers it to dst = sub 0, src0 and forcing it to f32, but it complains that result and the op value types are incorrect. My table descriptor rule is: def FNEG : OneInOneOut; With GPR defined as either an i32 or an f32. On another not, is there any known examples of using Tablegen with a typeless register class? Or with instruction formats where the modifiers are on the registers and the instructions(i.e. mul_x2 GPR0, GPR1_neg, GPR2_abs, which is equivalent to GPR0 = (-GPR1 * abs(GPR2)*2)? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080910/9fc4f656/attachment-0001.html From overminddl1 at gmail.com Wed Sep 10 17:22:18 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Wed, 10 Sep 2008 16:22:18 -0600 Subject: [LLVMdev] Integer questions In-Reply-To: <37DB2460-70B0-44EF-BA18-94EC460E321F@apple.com> References: <3f49a9f40809051242i7382f209xbe1a3849bedb14c5@mail.gmail.com> <200809060007.52512.baldrick@free.fr> <9B841EEA-69D8-462C-AE1F-48EC24530F62@apple.com> <3f49a9f40809081339x167f0e71v2093004d11d05ab4@mail.gmail.com> <45ADCEA9-E6B6-418C-84B9-71B979A7B4E6@apple.com> <3f49a9f40809081630v192a51c1v757eb87e86ddf149@mail.gmail.com> <4BCAAD07-7E64-431F-955E-CD7FE4B90CE2@apple.com> <3f49a9f40809081908r358919bdoab28b3dc7fda71c2@mail.gmail.com> <3f49a9f40809081918w3ea3baa5t137a231cf9713691@mail.gmail.com> <37DB2460-70B0-44EF-BA18-94EC460E321F@apple.com> Message-ID: <3f49a9f40809101522t5d401b16s9734088830f9bf38@mail.gmail.com> > I agree; having an abstract class interface for users to > subclass sounds like over-engineering here. The advantage of having another class handle such a thing is that errors that can be recovered from can continue, where as pretty much any other form of error handling handles it after it already bails. > I don't know what the best approach is. It would need to be something > that doesn't interfere with users who don't need it, and presumably it > would need to be good enough to meet your needs. I just consider some form of error reporting that reports an error by killing the program in some form, "very bad". I would accept anything that just says "Unknown Error", as long as it does not kill the program (why does it do that anyway?), but would prefer some form of detailed reporting so I could at least tell the user what was wrong so they can fix it while the program is running and have it be reloaded in real-time (yes, the format of my little language does allow new code to be added during run-time, as well as updating old code, the style the language is used in allows that to be done with little issue). I do not suppose I could just go the cheap route and replace all the assertions and abort's with a macro that does an assert/abort/exception depending on whether something is define'd or not? Would not break anything, it would act identically to as it does now if no one adds that defined word to their build, and I could get 'good-enough' information from the exception, although with no chance of recover, would have to restart the operation. This is a bit of a monstrous hack, but considering the current form of error reporting is even worse, and this would probably take well less then an hour of work, I would settle for it until something better is made... I do have to ask though, who thought "abort"ing the program was good error reporting? From eli.friedman at gmail.com Wed Sep 10 17:29:30 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 10 Sep 2008 15:29:30 -0700 Subject: [LLVMdev] Custom Lowering and fneg In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB039677B6@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB039677B6@ssanexmb1.amd.com> Message-ID: On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah wrote: > Generating the following LLVM IR: > > define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) > nounwind { > entry: > %neg = sub float -0.000000e+000, %x ; [#uses=1] > store float %neg, float addrspace(11)* %result > ret void > } > > However, when I attempt to run it through my backend which can handle binary > math ops correctly I keep asserting on the following item. > > Cannot yet select: 017B8010: i32 = fneg 017B7E78 That seems strange... you definitely shouldn't be seeing an fneg with an i32 result. What sorts of changes have you made to the SPARC backend? Have you tried looking at the output of "llc -view-dag-combine1-dags" and "llc -view-legalize-dags" to see where exactly this node is getting introduced? > What I cannot figure out is why it is attempting to pattern match on an i32 > when there are no i32's in my test program. With the regular SPARC backend, what ends up happening is the following: 1. The float is passed in an integer register (here's where the i32 first shows up) 2. The DAG combiner notices this, and combines the fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). 3. The store of the bit_convert gets turned into an i32 store, and there are now no more floats in the code. > I've tried a custom lowering function that lowers it to dst = sub 0, src0 > and forcing it to f32, but it complains that result and the op value types > are incorrect. If you have an fneg with an i32 result, something is already messed up. > On another not, is there any known examples of using Tablegen with a > typeless register class? What do you mean? > Or with instruction formats where the modifiers are > on the registers and the instructions(i.e. mul_x2 GPR0, GPR1_neg, GPR2_abs, > which is equivalent to GPR0 = (-GPR1 * abs(GPR2)*2)? No examples I know of, but I don't think there should be any issues using multiclass, as long as there aren't too many possible modifiers; see http://llvm.org/docs/TableGenFundamentals.html and various uses in the code for how that works. -Eli From Micah.Villmow at amd.com Wed Sep 10 18:20:08 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 10 Sep 2008 16:20:08 -0700 Subject: [LLVMdev] Custom Lowering and fneg In-Reply-To: References: <0F538B3E30A440469A53C9CC35C225EB039677B6@ssanexmb1.amd.com> Message-ID: <0F538B3E30A440469A53C9CC35C225EB0396784D@ssanexmb1.amd.com> -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, September 10, 2008 3:30 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah wrote: > Generating the following LLVM IR: > > define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) > nounwind { > entry: > %neg = sub float -0.000000e+000, %x ; [#uses=1] > store float %neg, float addrspace(11)* %result > ret void > } > > However, when I attempt to run it through my backend which can handle binary > math ops correctly I keep asserting on the following item. > > Cannot yet select: 017B8010: i32 = fneg 017B7E78 That seems strange... you definitely shouldn't be seeing an fneg with an i32 result. What sorts of changes have you made to the SPARC backend? Have you tried looking at the output of "llc -view-dag-combine1-dags" and "llc -view-legalize-dags" to see where exactly this node is getting introduced? Thanks I'll get this a try. I've made quite a few changes, introduced many new instructions and formats for my backend and working on getting the various data types to work with all the new instructions. > What I cannot figure out is why it is attempting to pattern match on an i32 > when there are no i32's in my test program. With the regular SPARC backend, what ends up happening is the following: 1. The float is passed in an integer register (here's where the i32 first shows up) 2. The DAG combiner notices this, and combines the fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). 3. The store of the bit_convert gets turned into an i32 store, and there are now no more floats in the code. I removed the SPARC pattern matching instructions for the fneg instruction because I don't want this behavior. The architecture I'm targeting has different performance constraints where floating point performance is better than integer performance, so I need to turn this type of conversion off. > I've tried a custom lowering function that lowers it to dst = sub 0, src0 > and forcing it to f32, but it complains that result and the op value types > are incorrect. If you have an fneg with an i32 result, something is already messed up. > On another not, is there any known examples of using Tablegen with a > typeless register class? What do you mean? The register types that are generated themselves don't hold any type information. How the bits are treated depends on the instruction being generated. My register are 128bit in width that can hold either 32bit floats and ints, or 64 bit floats in scalar or vector form. All the other Target backends seem to have register classes for each specific use case, not a register class that can handle every case, i.e. if a 256bit register is needed, then I just use 2 sequential 128bit registers. Also, my instruction set has basically unlimited registers, I can't really seem a way to model this either. > Or with instruction formats where the modifiers are > on the registers and the instructions(i.e. mul_x2 GPR0, GPR1_neg, GPR2_abs, > which is equivalent to GPR0 = (-GPR1 * abs(GPR2)*2)? No examples I know of, but I don't think there should be any issues using multiclass, as long as there aren't too many possible modifiers; see http://llvm.org/docs/TableGenFundamentals.html and various uses in the code for how that works. Thanks, I'll go back to that and see if I can get it to work how I want. -Eli _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From eli.friedman at gmail.com Wed Sep 10 18:40:47 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 10 Sep 2008 16:40:47 -0700 Subject: [LLVMdev] Custom Lowering and fneg In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB0396784D@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB039677B6@ssanexmb1.amd.com> <0F538B3E30A440469A53C9CC35C225EB0396784D@ssanexmb1.amd.com> Message-ID: On Wed, Sep 10, 2008 at 4:20 PM, Villmow, Micah wrote: >> What I cannot figure out is why it is attempting to pattern match on > an i32 >> when there are no i32's in my test program. > > With the regular SPARC backend, what ends up happening is the following: > 1. The float is passed in an integer register (here's where the i32 > first shows up) > 2. The DAG combiner notices this, and combines the > fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). > 3. The store of the bit_convert gets turned into an i32 store, and > there are now no more floats in the code. > > I removed the SPARC pattern matching instructions for the fneg > instruction because I don't want this behavior. Hmm? I'm not sure what code you're talking about... the code I'm talking about is cross-architecture. See DAGCombiner::visitFNEG in lib/CodeGen/SelectionDAG/DAGCombiner.cpp. >> On another not, is there any known examples of using Tablegen with a >> typeless register class? > > What do you mean? > > The register types that are generated themselves don't hold any type > information. How the bits are treated depends on the instruction being > generated. My register are 128bit in width that can hold either 32bit > floats and ints, or 64 bit floats in scalar or vector form. For this to work, all you have to do is define all your register classes to use the same set of registers. See FR32. FR64, and VR128 (floats, doubles, and vectors in SSE registers) in X86RegisterInfo.td for an example. -Eli From regehr at cs.utah.edu Wed Sep 10 21:34:14 2008 From: regehr at cs.utah.edu (John Regehr) Date: Wed, 10 Sep 2008 20:34:14 -0600 Subject: [LLVMdev] linux llvm-gcc build broken Message-ID: <48C883A6.7030801@cs.utah.edu> See below. This is on Ubuntu Hardy on ia32. Thanks, John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -I/home/regehr/llvm/include -I/home/regehr/llvm/include -DENABLE_LLVM -I/home/regehr/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS ../../gcc/c-incpath.c -o c-incpath.o ../../gcc/c-incpath.c:37: error: conflicting types for ?mempcpy? make[3]: *** [c-incpath.o] Error 1 make[3]: Leaving directory `/home/regehr/llvm-gcc/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/regehr/llvm-gcc/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/regehr/llvm-gcc/build' make: *** [all] Error 2 From viridia at gmail.com Wed Sep 10 22:04:34 2008 From: viridia at gmail.com (Talin) Date: Wed, 10 Sep 2008 20:04:34 -0700 Subject: [LLVMdev] Demangling question In-Reply-To: <200809050851.m858pdoa004150@star.math.spbu.ru> References: <200809050851.m858pdoa004150@star.math.spbu.ru> Message-ID: <48C88AC2.7080805@gmail.com> Anton Korobeynikov wrote: > Hello, Talin > >> In any case, if someone wants to work on this feel free to use this >> code, I've been too busy lately to make a patch. >> > Please, file a PR - I'll take care about this. > Dumb question - what does PR stand for? I tried searching the LLVM documentation and couldn't find a definition. (I thought it might be "Problem Report" - but the "How to submit a bug report" document doesn't use that term.) -- Talin From mrs at apple.com Wed Sep 10 22:14:18 2008 From: mrs at apple.com (Mike Stump) Date: Wed, 10 Sep 2008 20:14:18 -0700 Subject: [LLVMdev] Demangling question In-Reply-To: <48C88AC2.7080805@gmail.com> References: <200809050851.m858pdoa004150@star.math.spbu.ru> <48C88AC2.7080805@gmail.com> Message-ID: <945A3159-688A-4070-B582-D7EA93065BB1@apple.com> On Sep 10, 2008, at 8:04 PM, Talin wrote: > Dumb question - what does PR stand for? > (I thought it might be "Problem Report" Yes. Comes from gcc land, if your curious. From dalej at apple.com Wed Sep 10 22:15:45 2008 From: dalej at apple.com (Dale Johannesen) Date: Wed, 10 Sep 2008 20:15:45 -0700 Subject: [LLVMdev] Demangling question In-Reply-To: <48C88AC2.7080805@gmail.com> References: <200809050851.m858pdoa004150@star.math.spbu.ru> <48C88AC2.7080805@gmail.com> Message-ID: <5D0A1D32-CCCA-4275-8114-AB30B875F27D@apple.com> On Sep 10, 2008, at 8:04 PM, Talin wrote: > Anton Korobeynikov wrote: >> Hello, Talin >> >>> In any case, if someone wants to work on this feel free to use this >>> code, I've been too busy lately to make a patch. >>> >> Please, file a PR - I'll take care about this. >> > Dumb question - what does PR stand for? I tried searching the LLVM > documentation and couldn't find a definition. > > (I thought it might be "Problem Report" - but the "How to submit a bug > report" document doesn't use that term.) It probably is Problem Report, but everybody has been using PR for so long I'm not sure:) Anton meant a bug report in llvm's Bugzilla database: http://llvm.org/bugs/ From eli.friedman at gmail.com Wed Sep 10 22:16:28 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 10 Sep 2008 20:16:28 -0700 Subject: [LLVMdev] Demangling question In-Reply-To: <48C88AC2.7080805@gmail.com> References: <200809050851.m858pdoa004150@star.math.spbu.ru> <48C88AC2.7080805@gmail.com> Message-ID: On Wed, Sep 10, 2008 at 8:04 PM, Talin wrote: > Anton Korobeynikov wrote: >> Hello, Talin >> >>> In any case, if someone wants to work on this feel free to use this >>> code, I've been too busy lately to make a patch. >>> >> Please, file a PR - I'll take care about this. >> > Dumb question - what does PR stand for? I tried searching the LLVM > documentation and couldn't find a definition. > > (I thought it might be "Problem Report" - but the "How to submit a bug > report" document doesn't use that term.) Yeah, that's right (at least roughly)... AFAIK it's a bit of terminology borrowed from gcc. -Eli From evan.cheng at apple.com Thu Sep 11 00:31:51 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 10 Sep 2008 22:31:51 -0700 Subject: [LLVMdev] Determining the names of all the functions in a module In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB039676F1@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB039676F1@ssanexmb1.amd.com> Message-ID: <83671AFC-D560-4F37-8189-F411F8312EEB@apple.com> A Function is a Value. See Value.h, look for getName(), etc. Evan On Sep 10, 2008, at 12:18 PM, Villmow, Micah wrote: > I am attemping to figure out how to access the function names that > are stored in a > module so that I know which function I am currently in. I am > attempting to write a > backend that targets a language that only allows integer function > names and I need > to create mapping between the string and the integer. I?ve looked in > the header files > but I cannot determine how to extract the function name from either > a Function object > or a Module. > > Any tips or ideas would be greatly appreciated. > > Thanks, > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080910/aed896ef/attachment.html From Micah.Villmow at amd.com Thu Sep 11 10:52:14 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Thu, 11 Sep 2008 08:52:14 -0700 Subject: [LLVMdev] Determining the names of all the functions in a module In-Reply-To: <83671AFC-D560-4F37-8189-F411F8312EEB@apple.com> References: <0F538B3E30A440469A53C9CC35C225EB039676F1@ssanexmb1.amd.com> <83671AFC-D560-4F37-8189-F411F8312EEB@apple.com> Message-ID: <0F538B3E30A440469A53C9CC35C225EB039679F7@ssanexmb1.amd.com> Are there any known inheritance graphs of all the classes? That definitely would help in trying to understand the interactions between everything. Micah ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Wednesday, September 10, 2008 10:32 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Determining the names of all the functions in a module A Function is a Value. See Value.h, look for getName(), etc. Evan On Sep 10, 2008, at 12:18 PM, Villmow, Micah wrote: I am attemping to figure out how to access the function names that are stored in a module so that I know which function I am currently in. I am attempting to write a backend that targets a language that only allows integer function names and I need to create mapping between the string and the integer. I've looked in the header files but I cannot determine how to extract the function name from either a Function object or a Module. Any tips or ideas would be greatly appreciated. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 _______________________________________________ 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/20080911/67c28ba3/attachment-0001.html From evan.cheng at apple.com Thu Sep 11 10:55:14 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 11 Sep 2008 08:55:14 -0700 Subject: [LLVMdev] ReplaceUses: curious In-Reply-To: <48C79471.9080401@akya.co.uk> References: <48C79471.9080401@akya.co.uk> Message-ID: <68B5F60B-1CEB-43E0-AD43-F4184EC11B6C@apple.com> On Sep 10, 2008, at 2:33 AM, Dyson Wilkes wrote: > Hi > > I am looking at some of the existing targets to try to understand more > about writing a backend. I was a little puzzled by the use of a method > ReplaceUses in *ISelDAGToDAG.cpp (*= most targets, e.g. ARM, X86..). > I found its definition in the *GenDAGISel.inc file that is > autogenerated from the target description. I can only assume TableGen > emits this method definition for every traget. Is this method > implementation, in some way that I cannot see, specific to a given > target? I cannot see a reason for it not being a method of > SelectionDAGISel and just implemented once? Indeed it's generic. It's defined in DAGISelHeader.h We probably ought to change the name to indicate it's specific to DAG isel though. > > > Whilst the existing targets do offer a newcomer to LLWM a template to > writing a new backend, can anyone point me to other sources of > information to help me get up and running more quickly. I have read > the > various LLVM documents but, for example, the Writing an LLVM Backend > and > TableGen documents are rather high level. Am I going about this in > the > best way, i.e. trawling through the code and doxygen documents etc? > Am > I missing something? There is not a lot of documentation beyond those. Right now, you need to rely on this mailing list and your own experimentation with existing targets. We've been talking about doing a tutorial on writing a target port for LLVM Developer Meeting. But no one has found the time to prepare such a elaborate talk yet. Perhaps next year! :-) Evan > > > Thanks for any help you can give, > > - Dyson > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From joe at x2a.org Thu Sep 11 11:09:35 2008 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Thu, 11 Sep 2008 12:09:35 -0400 Subject: [LLVMdev] Determining the names of all the functions in a module In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB039679F7@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB039676F1@ssanexmb1.amd.com> <83671AFC-D560-4F37-8189-F411F8312EEB@apple.com> <0F538B3E30A440469A53C9CC35C225EB039679F7@ssanexmb1.amd.com> Message-ID: <48C942BF.1050108@x2a.org> Villmow, Micah wrote: > > Are there any known inheritance graphs of all the classes? That > definitely would help in trying to understand the interactions between > everything. > > > > Micah > Look at http://llvm.org/doxygen/hierarchy.html (text version) ...or http://llvm.org/doxygen/inherits.html (graphical version) Or more generally look at TFM: http://llvm.org/docs/ From dpatel at apple.com Thu Sep 11 11:58:42 2008 From: dpatel at apple.com (Devang Patel) Date: Thu, 11 Sep 2008 09:58:42 -0700 Subject: [LLVMdev] linux llvm-gcc build broken In-Reply-To: <48C883A6.7030801@cs.utah.edu> References: <48C883A6.7030801@cs.utah.edu> Message-ID: <061F4402-93A9-4F3C-B2E6-E81450E7DFFE@apple.com> On Sep 10, 2008, at 7:34 PM, John Regehr wrote: > See below. This is on Ubuntu Hardy on ia32. Thanks, I added explicit memcpy decl and it did not work on Ubunty. I'll update my patch to make it darwin specific. - Devang > > > John > > > make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' > gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Wold-style-definition > -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc > -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include > -I../../gcc/../libdecnumber -I../libdecnumber > -I/home/regehr/llvm/include -I/home/regehr/llvm/include -DENABLE_LLVM > -I/home/regehr/llvm/include -D_DEBUG -D_GNU_SOURCE > -D__STDC_LIMIT_MACROS ../../gcc/c-incpath.c -o c-incpath.o > ../../gcc/c-incpath.c:37: error: conflicting types for ?mempcpy? > make[3]: *** [c-incpath.o] Error 1 > make[3]: Leaving directory `/home/regehr/llvm-gcc/build/gcc' > make[2]: *** [all-stage1-gcc] Error 2 > make[2]: Leaving directory `/home/regehr/llvm-gcc/build' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/home/regehr/llvm-gcc/build' > make: *** [all] Error 2 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From matthijs at stdin.nl Thu Sep 11 12:21:00 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Thu, 11 Sep 2008 19:21:00 +0200 Subject: [LLVMdev] Determining the names of all the functions in a module In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB039679F7@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB039676F1@ssanexmb1.amd.com> <83671AFC-D560-4F37-8189-F411F8312EEB@apple.com> <0F538B3E30A440469A53C9CC35C225EB039679F7@ssanexmb1.amd.com> Message-ID: <20080911172100.GB9093@katherina.student.utwente.nl> Hi Micah, > Are there any known inheritance graphs of all the classes? That > definitely would help in trying to understand the interactions between > everything. The images on llvm.org/doxygen and the hierarchical class list should give you a rather complete picture? Or are you looking for something else? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080911/b8c71811/attachment.bin From tjablin at CS.Princeton.EDU Thu Sep 11 12:30:24 2008 From: tjablin at CS.Princeton.EDU (Thomas B. Jablin) Date: Thu, 11 Sep 2008 13:30:24 -0400 (EDT) Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <312287543.281591221154116018.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <35004458.281651221154224067.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Hi, I'm interested in specifying some additional passes to the JIT via the command-line. The enclosed patch allows lli to take compiler passes as command-line arguments in the same way opt does. This is my first submission, so any comments, criticisms, or observations would be very welcome. Thanks. Tom Jablin -------------- next part -------------- A non-text attachment was scrubbed... Name: PassArgumentsForLLI.diff Type: text/x-diff Size: 9399 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080911/17a9d219/attachment.bin From tjablin at CS.Princeton.EDU Thu Sep 11 12:55:09 2008 From: tjablin at CS.Princeton.EDU (Thomas B. Jablin) Date: Thu, 11 Sep 2008 13:55:09 -0400 (EDT) Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <704255883.282551221155685901.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <2030974892.282571221155709832.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Hi, Here is the diff for the pod file that goes with my earlier change. Tom ----- Original Message ----- From: "Thomas B. Jablin" To: "LLVM Developers Mailing List" Sent: Thursday, September 11, 2008 1:30:24 PM GMT -05:00 US/Canada Eastern Subject: [LLVMdev] Specifying Additional Compilation Passes to lli Hi, I'm interested in specifying some additional passes to the JIT via the command-line. The enclosed patch allows lli to take compiler passes as command-line arguments in the same way opt does. This is my first submission, so any comments, criticisms, or observations would be very welcome. Thanks. Tom Jablin _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- A non-text attachment was scrubbed... Name: PassArgumentsForLLIDoc.diff Type: text/x-diff Size: 719 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080911/6e30dc0c/attachment.bin From evan.cheng at apple.com Thu Sep 11 16:21:17 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 11 Sep 2008 14:21:17 -0700 Subject: [LLVMdev] Tail-calling In-Reply-To: <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> Message-ID: <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> Arnold implemented tail call. We should all urge him to continue his work to make it even better. :-) Evan On Sep 9, 2008, at 1:19 AM, OvermindDL1 wrote: >> Tail calls are disabled by default; to enable them, you have to pass >> -tailcallopt to llc. It looks like there's a bug preventing indirect >> tail calls from working... I don't think there's anything >> fundamentally preventing them from working, though. > > I will not be using llc, it will all be through the C++ API. I looked > through the code a bit, but could not see any real direct way to turn > on tall-calls, the only thing I could really find was a single global > (yes, a global... ugh...) that many things referenced, if I set that > then things should use tail-call versions of things. > > What about this indirect bug, is anyone working on it? I would try, > but I am quite certain I do not yet have the LLVM internals knowledge > to (or even where to look). > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tjablin at CS.Princeton.EDU Thu Sep 11 17:14:20 2008 From: tjablin at CS.Princeton.EDU (Thomas B. Jablin) Date: Thu, 11 Sep 2008 18:14:20 -0400 (EDT) Subject: [LLVMdev] recompileAndRelinkFunction? In-Reply-To: <2030974892.282571221155709832.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <1486964513.288431221171260316.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Hi, Are there any users of llvm::ExecutionEngine::recompileAndRelinkFunction? It's not called anywhere in the svn tree, but I thought it might be used by an external Pass. Thanks. Tom From arnold.schwaighofer at gmail.com Thu Sep 11 17:31:16 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Fri, 12 Sep 2008 00:31:16 +0200 Subject: [LLVMdev] Tail-calling In-Reply-To: <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> Message-ID: Tail calls through function pointers should work.If not please send a testcase. I just added the two examples from the bug (1392) that calls for true tail call support. They work on my machine (-tailcallopt needs to be enabled) ;) That would be commit 56127. regards On Thu, Sep 11, 2008 at 11:21 PM, Evan Cheng wrote: > Arnold implemented tail call. We should all urge him to continue his work to > make it even better. :-) > > Evan > > On Sep 9, 2008, at 1:19 AM, OvermindDL1 wrote: > >>> Tail calls are disabled by default; to enable them, you have to pass >>> -tailcallopt to llc. It looks like there's a bug preventing indirect >>> tail calls from working... I don't think there's anything >>> fundamentally preventing them from working, though. >> >> I will not be using llc, it will all be through the C++ API. I looked >> through the code a bit, but could not see any real direct way to turn >> on tall-calls, the only thing I could really find was a single global >> (yes, a global... ugh...) that many things referenced, if I set that >> then things should use tail-call versions of things. >> >> What about this indirect bug, is anyone working on it? I would try, >> but I am quite certain I do not yet have the LLVM internals knowledge >> to (or even where to look). >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From overminddl1 at gmail.com Thu Sep 11 18:33:13 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Thu, 11 Sep 2008 17:33:13 -0600 Subject: [LLVMdev] Tail-calling In-Reply-To: References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> Message-ID: <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> On Thu, Sep 11, 2008 at 4:31 PM, Arnold Schwaighofer wrote: > Tail calls through function pointers should work.If not please send a testcase. > > I just added the two examples from the bug (1392) that calls for true > tail call support. They work on my machine (-tailcallopt needs to be > enabled) ;) > > That would be commit 56127. > > regards Quick question, how do you enable tail calls for the JIT when using the API, not an external app; in my program it is all internal, nothing external is called and the only thing I saw was that one global on a quick look through. From rich at pennware.com Thu Sep 11 20:09:58 2008 From: rich at pennware.com (Richard Pennington) Date: Thu, 11 Sep 2008 20:09:58 -0500 Subject: [LLVMdev] Difficulty with reusing DAG nodes. In-Reply-To: <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> Message-ID: <48C9C166.4040300@pennware.com> I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1); AddToISelQueue(Op2); unsigned Op; Op = (Opcode == ISD::UMUL_LOHI ? Nios2::MULxu : Nios2::MULx); SDNode *Hi = CurDAG->getTargetNode(Op, MVT::Flag, Op1, Op2); SDNode *Lo = CurDAG->getTargetNode(Nios2::MUL, MVT::Flag, Op1, Op2); if (!N.getValue(0).use_empty()) ReplaceUses(N.getValue(0), SDValue(Lo,0)); if (!N.getValue(1).use_empty()) ReplaceUses(N.getValue(1), SDValue(Hi,0)); return NULL; } The code generator complains: nios2-elf-ecc: /home/rich/llvm-trunk-new/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:141: void llvm::ScheduleDAG::BuildSchedUnits(): Assertion `N->getNodeId() == -1 && "Node already inserted!"' failed I'm guessing that's because I'm reusing Op1 and Op2. What is the right way to reuse DAG operands? -Rich From Micah.Villmow at amd.com Thu Sep 11 20:14:41 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Thu, 11 Sep 2008 18:14:41 -0700 Subject: [LLVMdev] Selection Condition Codes Message-ID: <0F538B3E30A440469A53C9CC35C225EB03967CDB@ssanexmb1.amd.com> I am attempting to lower the selectCC instruction to the instruction set of the backend I'm working on and I cannot seem to find a way to correctly implement this instruction. I know how this instruction should get implemented; I just have yet to find a way to do it. I want the select_cc instruction to be lowered into a comparison followed by a conditional move. I've attempted to use a custom rule pasted below, but it keeps giving me an error about the first argument. What I attempted is as follows: class InstFormat pattern> : Instruction { let Namespace = "Inst"; dag OutOperandList = outs; dag InOperandList = ins; let Pattern = pattern; let AsmString = asmstr; } def SDTGenTernaryOp : SDTypeProfile<1, 3, [ SDTCisSameAs<0, 1>,SDTCisSameAs<0, 2>, SDTCisSameAs<0, 3> ]>; def cmov_logical : SDNode<"INSTISD::CMOVLOG", SDTGenTernaryOp>; let PrintMethod = "printCCOperand" in def CCOp : Operand; def CMOVLOG : InstFormat<(outs GPR:$dst), (ins GPR:$LHS, GPR:$RHS, GPR:$TVAL, GPR:$FVAL, CCOp:$cond), "$cond $LHS, $LHS, $RHS\ncmov_logical $dst, $LHS, $TVAL, $FVAL", [(set GPR:$dst, (selectcc GPR:$LHS, GPR:$RHS, GPR:$TVAL, GPR:$FVAL, CCOp:$cond))]>; Maybe I'm approaching this from the wrong way, but I don't think this transformation should be that difficult. Basically I want dst = select $LHS, $RHS, $TVAL, $FVAL, $condOp to be transformed into $condOp tmp, $LHS, $RHS cmov_logical dst, tmp, $TVAL, $FVAL My attempt at doing so with a custom OperationAction also failed. So, what would I need to do to figure out how to implement this correctly? Is there any place you can point me to which shows how to go from a single instruction to multiple consecutive instructions? A function that I can study would be nice since my problem is even though I can look at the other backends, I don't completely understand everything that is going on so I probably overlooked this already. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080911/94270692/attachment.html From eli.friedman at gmail.com Thu Sep 11 21:50:50 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 11 Sep 2008 19:50:50 -0700 Subject: [LLVMdev] Difficulty with reusing DAG nodes. In-Reply-To: <48C9C166.4040300@pennware.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48C9C166.4040300@pennware.com> Message-ID: On Thu, Sep 11, 2008 at 6:09 PM, Richard Pennington wrote: > I'm trying to implement *MUL_LOHI for my processor. > > My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit > multiply. I haven't looked at the rest of the email carefully, but why aren't you just implementing MULHU and MULHS? There's no point to implementing the *MUL_LOHI variants if the processor doesn't have them. -Eli From eli.friedman at gmail.com Thu Sep 11 22:11:36 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 11 Sep 2008 20:11:36 -0700 Subject: [LLVMdev] Selection Condition Codes In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB03967CDB@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB03967CDB@ssanexmb1.amd.com> Message-ID: On Thu, Sep 11, 2008 at 6:14 PM, Villmow, Micah wrote: > I am attempting to lower the selectCC instruction to the instruction set of > the backend I'm working on and I cannot seem to find a way to correctly > implement this instruction. I know how this instruction should get > implemented; I just have yet to find a way to do it. I want the select_cc > instruction to be lowered into a comparison followed by a conditional move. "setOperationAction(ISD::SELECT_CC , MVT::Other, Expand);" should do the trick; that will prevent SELECT_CC instructions from being introduced. This one is easy to miss. > def CMOVLOG : InstFormat<(outs GPR:$dst), (ins GPR:$LHS, GPR:$RHS, > GPR:$TVAL, GPR:$FVAL, CCOp:$cond), The condition isn't properly an input... this seems likely to confuse ISel. I'm not sure, though; I'm not really an expert on patterns, and they can mess up in non-obvious ways. > Maybe I'm approaching this from the wrong way, but I don't think this > transformation should be that difficult. If you need to transform a construct into multiple instructions, there are a few different ways; one is a custom lowering, one is a selection pattern, and another is a custom inserter. Stuffing multiple actual instructions into a single target instruction is generally a bad approach. -Eli From kremenek at apple.com Thu Sep 11 23:30:15 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 11 Sep 2008 21:30:15 -0700 Subject: [LLVMdev] xcodebuild and LLVM In-Reply-To: <48C6CAF1.2040100@cs.uiuc.edu> References: <48BF0BD0.2070609@cs.uiuc.edu> <48C6CAF1.2040100@cs.uiuc.edu> Message-ID: <2F2D1371-4B60-4BE9-A363-83A4F41BFDC1@apple.com> Hi John, I'm not certain if libtool works with LLVM bitcode files, and I don't think that all of the tools that manipulate/inspect object files on Mac OS X understand bitcode files either. I suspect that this will change over time. I believe that Devang and others who implemented LTO on Mac OS X can probably provide you with specific details of tool support for bitcode files. Ted On Sep 9, 2008, at 12:13 PM, John Criswell wrote: > Dear Ted and All, > > Thanks. This has helped some. However, I'm now getting errors from > libtool about an object being modified after free. > > Is libtool supposed to work with LLVM bitcode files? If so, would > grabbing the latest source potentially fix the problem (I'm currently > using XCode 3.1), or will I need a way to convince xcodebuild to use > something other than libtool? > > -- John T. > > Ted Kremenek wrote: >> On Sep 3, 2008, at 3:12 PM, John Criswell wrote: >> >> >>> Dear All, >>> >>> Is there a way to convince xcodebuild to build bitcode files for >>> LLVM >>> for an arbitrary Xcode project? So far, I've been able to get >>> xcodebuild to use LLVM by installing XCode 3.1 and using CC="llvm- >>> gcc" >>> on the command line. I've also managed to get LLVM bitcode >>> generates >>> for intermediate files by using "CC="lvm-gcc -emit-llvm"; however, >>> this >>> gives an error during linking stating that ld does not understand >>> the >>> -emit-llvm option. >>> >>> Thanks in advance. >>> >>> -- John T. >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> In addition to specifying CC, xcodebuild also consults the >> environment >> variables LD and LDPLUSPLUS for your linker commands (for C and C++ >> sources respectively). I would try LD=llvm-gcc and LDPLUSPLUS=llvm- >> g+ >> + respectively. >> _______________________________________________ >> 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 arnold.schwaighofer at gmail.com Fri Sep 12 01:24:12 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Fri, 12 Sep 2008 08:24:12 +0200 Subject: [LLVMdev] Tail-calling In-Reply-To: <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> Message-ID: For marking a call site as a tail call you have to call void setTailCall(bool isTC = true) on the CallInst. The calling convention of the function needs to be CallingConv::Fast (currently only fastcc calls are optimized) and the call has to be in tail position of course. To enable tail call optimization in an embedded vm i guess you would include llvm/Target/TargetOptions.h and set the static variable PerformTailCallOpt to true. Take this with a grain of salt or two since i have never done it ;) but i guess that setting those globals is what cl::ParseCommandLineOptions does in lli/llc.cpp. regards arnold > Quick question, how do you enable tail calls for the JIT when using > the API, not an external app; in my program it is all internal, > nothing external is called and the only thing I saw was that one > global on a quick look through. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From arnold.schwaighofer at gmail.com Fri Sep 12 02:27:30 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Fri, 12 Sep 2008 09:27:30 +0200 Subject: [LLVMdev] Tail-calling In-Reply-To: References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> Message-ID: On Fri, Sep 12, 2008 at 8:24 AM, Arnold Schwaighofer wrote: > For marking a call site as a tail call you have to call void > setTailCall(bool isTC = true) on the CallInst. The calling convention > of the function needs to be CallingConv::Fast (currently only fastcc > calls are optimized) and the call has to be in tail position of > course. The function performing the tail call also needs to be CallingConv::Fast. Some info about tail call optimization is located at . Some examples are in > ls /llvm/test/CodeGen/X86/tailcall* regards arnold From evan.cheng at apple.com Fri Sep 12 03:08:19 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 12 Sep 2008 01:08:19 -0700 Subject: [LLVMdev] Difficulty with reusing DAG nodes. In-Reply-To: <48C9C166.4040300@pennware.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48C9C166.4040300@pennware.com> Message-ID: <3462E8D9-7B49-44BC-AD29-72E3B42D8FD1@apple.com> This isn't due to node reuse. Rather it's the scheduler complaining of a malformed DAG. You should dump out the DAG before scheduling and look for multiple use of a FLAG value. Evan On Sep 11, 2008, at 6:09 PM, Richard Pennington wrote: > I'm trying to implement *MUL_LOHI for my processor. > > My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit > multiply. > > I tried this in ios2ISelDAGToDAG.cpp: > /// Mul/Div with two results > case ISD::SMUL_LOHI: > case ISD::UMUL_LOHI: { > SDValue Op1 = Node->getOperand(0); > SDValue Op2 = Node->getOperand(1); > AddToISelQueue(Op1); > AddToISelQueue(Op2); > > unsigned Op; > Op = (Opcode == ISD::UMUL_LOHI ? Nios2::MULxu : Nios2::MULx); > SDNode *Hi = CurDAG->getTargetNode(Op, MVT::Flag, Op1, Op2); > SDNode *Lo = CurDAG->getTargetNode(Nios2::MUL, MVT::Flag, Op1, > Op2); > if (!N.getValue(0).use_empty()) > ReplaceUses(N.getValue(0), SDValue(Lo,0)); > if (!N.getValue(1).use_empty()) > ReplaceUses(N.getValue(1), SDValue(Hi,0)); > return NULL; > } > > The code generator complains: > nios2-elf-ecc: > /home/rich/llvm-trunk-new/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp: > 141: > void llvm::ScheduleDAG::BuildSchedUnits(): Assertion `N->getNodeId() > == > -1 && "Node already inserted!"' failed > > I'm guessing that's because I'm reusing Op1 and Op2. > What is the right way to reuse DAG operands? > > -Rich > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From Dr.Graef at t-online.de Fri Sep 12 03:22:50 2008 From: Dr.Graef at t-online.de (Albert Graef) Date: Fri, 12 Sep 2008 10:22:50 +0200 Subject: [LLVMdev] Tail-calling In-Reply-To: References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> Message-ID: <48CA26DA.3070600@t-online.de> Arnold Schwaighofer wrote: > Take this with a grain of salt or two since i have never done it ;) > but i guess that setting those globals is what > cl::ParseCommandLineOptions does in lli/llc.cpp. I can confirm that this is actually how it works (fastcc on the function + setTailCall on the call instruction + llvm::PerformTailCallOpt = true). I might add that of course you also have to make sure that the tail call is immediately before a ret instruction. :) Note that it also depends on the JIT for the target architecture whether this is actually supported. I verified that this does work on x86, -64. Not sure about the status on other archs, though, it seems that at least the LLVM 2.2 JIT didn't do any proper tail calls on ppc yet. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From arnold.schwaighofer at gmail.com Fri Sep 12 03:55:41 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Fri, 12 Sep 2008 10:55:41 +0200 Subject: [LLVMdev] Tail-calling In-Reply-To: <48CA26DA.3070600@t-online.de> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48CA26DA.3070600@t-online.de> Message-ID: Hi Albert, nice to see someone is using the tail call stuff. i am responsible for the mess (feature) ;). Tail call optimization currently (llvm 2.3) works (to varying degrees, see http://llvm.org/docs/CodeGenerator.html#tailcallopt) for x86(-64) and ppc32/64. x86 being more mature (testing) than ppc. ppc64 has received the least testing. regards From rich at pennware.com Fri Sep 12 06:12:36 2008 From: rich at pennware.com (Richard Pennington) Date: Fri, 12 Sep 2008 06:12:36 -0500 Subject: [LLVMdev] Difficulty with reusing DAG nodes. In-Reply-To: References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48C9C166.4040300@pennware.com> Message-ID: <48CA4EA4.9090907@pennware.com> Eli Friedman wrote: > I haven't looked at the rest of the email carefully, but why aren't > you just implementing MULHU and MULHS? There's no point to > implementing the *MUL_LOHI variants if the processor doesn't have > them. I have implemented MULHU and MULHS. But if I take out my *MUL_LOHI stuff, the error I get is [~/ellcc/ellcc] main% ./nios2-elf-ecc -S test.c Cannot yet select: 0xaf93a34: i32,i32 = umul_lohi 0xaf9345c, 0xaf93924 What could I be doing to make the code generator think that umul_lohi is legal? -Rich From rlsosborne at googlemail.com Fri Sep 12 06:31:31 2008 From: rlsosborne at googlemail.com (Richard Osborne) Date: Fri, 12 Sep 2008 12:31:31 +0100 Subject: [LLVMdev] Difficulty with reusing DAG nodes. In-Reply-To: <48CA4EA4.9090907@pennware.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48C9C166.4040300@pennware.com> <48CA4EA4.9090907@pennware.com> Message-ID: <48CA5313.90407@googlemail.com> Richard Pennington wrote: > Eli Friedman wrote: > >> I haven't looked at the rest of the email carefully, but why aren't >> you just implementing MULHU and MULHS? There's no point to >> implementing the *MUL_LOHI variants if the processor doesn't have >> them. >> > > I have implemented MULHU and MULHS. But if I take out my *MUL_LOHI > stuff, the error I get is > > [~/ellcc/ellcc] main% ./nios2-elf-ecc -S test.c > Cannot yet select: 0xaf93a34: i32,i32 = umul_lohi 0xaf9345c, 0xaf93924 > > What could I be doing to make the code generator think that umul_lohi is > legal? > > -Rich > In your target lowering you need to set the operation action for ISD::*MUL_LOHI to expand otherwise it will be assumed to be legal. Richard From rich at pennware.com Fri Sep 12 06:41:44 2008 From: rich at pennware.com (Richard Pennington) Date: Fri, 12 Sep 2008 06:41:44 -0500 Subject: [LLVMdev] Difficulty with reusing DAG nodes. In-Reply-To: <48CA5313.90407@googlemail.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48C9C166.4040300@pennware.com> <48CA4EA4.9090907@pennware.com> <48CA5313.90407@googlemail.com> Message-ID: <48CA5578.5070407@pennware.com> Richard Osborne wrote: > Richard Pennington wrote: > In your target lowering you need to set the operation action for > ISD::*MUL_LOHI to expand otherwise it will be assumed to be legal. > > Richard Ah! Thanks! That's the bit I was missing. -Rich From Dr.Graef at t-online.de Fri Sep 12 07:04:53 2008 From: Dr.Graef at t-online.de (Albert Graef) Date: Fri, 12 Sep 2008 14:04:53 +0200 Subject: [LLVMdev] Tail-calling In-Reply-To: References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48CA26DA.3070600@t-online.de> Message-ID: <48CA5AE5.4080907@t-online.de> Arnold Schwaighofer wrote: > nice to see someone is using the tail call stuff. i am responsible for > the mess (feature) ;). Thanks a bunch. Without it, my FPL (http://pure-lang.sf.net) would be much less useful because it doesn't have a built-in loop construct. :) > Tail call optimization currently (llvm 2.3) works (to varying degrees, > see http://llvm.org/docs/CodeGenerator.html#tailcallopt) > for x86(-64) and ppc32/64. x86 being more mature (testing) than ppc. > ppc64 has received the least testing. That's good news, thanks for the info! Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From overminddl1 at gmail.com Fri Sep 12 09:43:49 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Fri, 12 Sep 2008 08:43:49 -0600 Subject: [LLVMdev] Tail-calling In-Reply-To: <48CA5AE5.4080907@t-online.de> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48CA26DA.3070600@t-online.de> <48CA5AE5.4080907@t-online.de> Message-ID: <3f49a9f40809120743i7c904613i9ba94c88e08693ac@mail.gmail.com> Thanks for the confirmation on use. I am needing it to create a C syntax actor based scripting language for my program (I may include an optional assembler and linker for turning the 'cache' files into real loading loadable libraries, but that will be further down the road, I will be adding in pathways for such a thing being added however), I will not use it for loops and such, but I will be slicing functions up at call boundaries of other functions that are capable of 'pausing execution' (with a return statement immediately following, which may never actually be reached in some builds actually, hence tail-call optimization is pretty important). The only platform I need it for personally is x86(-64), and considering the large amount of languages out there already I doubt anyone would really be interested in mine, but if anyone ever was then I would add support for having it compile down to a native executable, which could involve needing multiple architecture support. I am still split on whether I should offer things like a 128-bit native integer on 64-bit platforms, when such things would not be available on a 32-bit platform, or if I should just go with lowest common denominator (just x86) so the code 'just works'... From hendrik at topoi.pooq.com Fri Sep 12 11:35:15 2008 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 12 Sep 2008 16:35:15 +0000 (UTC) Subject: [LLVMdev] Order of fiels and structure usage Message-ID: I'd like to be able to make use of a structure type and its fields before it is completely defined. To be specific, let me ask detailed questions at various stages in the construction of a recursive type. I copy from http://llvm.org/docs/ProgrammersManual.html#TypeResolve // Create the initial outer struct PATypeHolder StructTy = OpaqueType::get(); Is it possible to declare variables of type StructTy at this point? Is it possible to define other structured types that have fields of type StructTy at this point? I'm guessing the answers to these questions are "Yes". std::vector Elts; Elts.push_back(PointerType::get(StructTy)); Is it possible to build an expression that uses the newly generated Elt as field-selector at this point? I'm hoping yes, but I suspect No, because the elments of Elts* are clearly Type* instead of being a field. In particular, if I use the same type twice to make two fields, the corresponding elements of Elts will be indistinguishable. Elts.push_back(Type::Int32Ty); StructType *NewSTy = StructType::get(Elts); Presumably at this point is is definitely possible to declare variables of type NewsTy and use field-selectors from NewSTy. But it's a little too late for my purposes. The types I'm dealing with are not recursive, but of course I'll have to perform the rest of the steps so that the variables I declared long ago finally get well-defined types. // At this point, NewSTy = "{ opaque*, i32 }". Tell VMCore that // the struct and the opaque type are actually the same. cast(StructTy.get())->refineAbstractTypeTo(NewSTy); // NewSTy is potentially invalidated, but StructTy (a PATypeHolder) is // kept up-to-date NewSTy = cast(StructTy.get()); // Add a name for the type to the module symbol table (optional) MyModule->addTypeName("mylist", NewSTy); If the answers to my questions are "yes", I can generate code easily for all the variations on the source language I'm compiling. If any are "no" I'll be significantly constrained in what I'll be able to do easily (i.e., without extra code generation passes and intermediate data structures). -- hendrik From tscud at cray.com Fri Sep 12 11:40:45 2008 From: tscud at cray.com (Tony Scudiero) Date: Fri, 12 Sep 2008 11:40:45 -0500 Subject: [LLVMdev] CPP API User-level Question: Returning multiple values Message-ID: <48CA9B8D.9000606@cray.com> Greetings, I'm working on getting our compiler's interface to LLVM to mimic the way the LLVM-GCC inserts instructions to generate AMD64 ABI compliant code. I'm trying to create ret i64 %mrv, double %double_mrv37 which is basically what LLVM-GCC puts out. However if I use lcc -march=cpp to get the API code I need it has the following line: ReturnInst::Create(int64_t93, label_return); with no reference to the double. I also can't find anything in the doxygen docs for a version of ReturnInst::Create( ) that takes two values for returning, nor could I find anything by generating an intentionally bad call and letting my gen-compiler list the possible ReturnInst which it knows about. Do I have to create the ReturnInst in a different way to do this? Any guidance for how to do this from within the CPP API would be greatly appreciated. Thanks!! -Tony Scudiero From eli.friedman at gmail.com Fri Sep 12 12:40:39 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 12 Sep 2008 10:40:39 -0700 Subject: [LLVMdev] Tail-calling In-Reply-To: <3f49a9f40809120743i7c904613i9ba94c88e08693ac@mail.gmail.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809090119m23290d30y692d979769fc27de@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48CA26DA.3070600@t-online.de> <48CA5AE5.4080907@t-online.de> <3f49a9f40809120743i7c904613i9ba94c88e08693ac@mail.gmail.com> Message-ID: On Fri, Sep 12, 2008 at 7:43 AM, OvermindDL1 wrote: > I am still split on whether I should offer things like a 128-bit > native integer on 64-bit platforms, when such things would not be > available on a 32-bit platform, or if I should just go with lowest > common denominator (just x86) so the code 'just works'... AFAIK, 128-bit integers should work just fine on x86 with LLVM. -Eli From ggreif at gmail.com Fri Sep 12 12:44:47 2008 From: ggreif at gmail.com (heisenbug) Date: Fri, 12 Sep 2008 10:44:47 -0700 (PDT) Subject: [LLVMdev] CPP API User-level Question: Returning multiple values In-Reply-To: <48CA9B8D.9000606@cray.com> References: <48CA9B8D.9000606@cray.com> Message-ID: On Sep 12, 6:40?pm, Tony Scudiero wrote: > Greetings, > ? ? I'm working on getting our compiler's interface to LLVM to mimic the > way the LLVM-GCC inserts instructions to generate AMD64 ABI compliant > code. I'm trying to create > > ? ? ?ret i64 %mrv, double %double_mrv37 > > ? ? which is basically what LLVM-GCC puts out. However if I use lcc > -march=cpp to get the API code I need it has the following line: > > ? ? ReturnInst::Create(int64_t93, label_return); > > ? ? with no reference to the double. I also can't find anything in the > doxygen docs for a version of ReturnInst::Create( ) that takes two > values for returning, nor could I find anything by generating an > intentionally bad call and letting my gen-compiler list the possible > ReturnInst which it knows about. Do I have to create the ReturnInst in a > different way to do this? Any guidance for how to do this from within > the CPP API would be greatly appreciated. Thanks!! Hi Tony, this is probably a bug in the CPP "back end". You have exercised an as of yet untriggered condition and CPP happens to output uncompilable code. Just go to the CppEmitter, modify each string literal the contains "ReturnInst::Create" with a unique comment and rebuild. On your next attempt to compile using llc you will get a nice hint which line in teh emitter is the guilty one. Cheers, Gabor > > ? ? -Tony Scudiero > > _______________________________________________ > LLVM Developers mailing list > LLVM... at cs.uiuc.edu ? ? ? ?http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From eli.friedman at gmail.com Fri Sep 12 13:06:30 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 12 Sep 2008 11:06:30 -0700 Subject: [LLVMdev] Order of fiels and structure usage In-Reply-To: References: Message-ID: On Fri, Sep 12, 2008 at 9:35 AM, Hendrik Boom wrote: > I'd like to be able to make use of a structure type and its fields before > it is completely defined. To be specific, let me ask detailed questions > at various stages in the construction of a recursive type. I copy from > > http://llvm.org/docs/ProgrammersManual.html#TypeResolve > > // Create the initial outer struct > PATypeHolder StructTy = OpaqueType::get(); > > Is it possible to declare variables of type StructTy at this point? I think you can, although you have to be careful; if you don't make sure the variable eventually has a computable size, the module won't be valid. Declaring variables of type pointer to StructTy is completely safe. > std::vector Elts; > Elts.push_back(PointerType::get(StructTy)); > > Is it possible to build an expression that uses the newly generated Elt > as field-selector at this point? I'm hoping yes, but I suspect No, > because the elments of Elts* are clearly Type* instead of being a field. > In particular, if I use the same type twice to make two fields, the > corresponding elements of Elts will be indistinguishable. I'm not following; are you trying to access the first member of NewSTy here? You can't use a type that hasn't been created yet. You might be able to pull some tricks with incomplete types or casts, though. http://llvm.org/docs/LangRef.html#i_getelementptr and http://llvm.org/docs/GetElementPtr.html might be useful here. > Elts.push_back(Type::Int32Ty); > StructType *NewSTy = StructType::get(Elts); > > Presumably at this point is is definitely possible to declare variables > of type NewsTy and use field-selectors from NewSTy. But it's a little > too late for my purposes. Basically, the rule for opaque types is that in a valid module, you can do anything you could do with a declaration like "struct S;" in C. And in a module under construction, I'm pretty sure you can pull some more tricks, like declaring variables with types of unknown size, or accessing structs with members of unknown size. -Eli From tjablin at CS.Princeton.EDU Fri Sep 12 13:12:47 2008 From: tjablin at CS.Princeton.EDU (Thomas B. Jablin) Date: Fri, 12 Sep 2008 14:12:47 -0400 (EDT) Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <360901584.300671221243118937.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <1633568469.300711221243167018.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Hi, Is this the right mailing list for sending in diffs by irregular contributers? Should I send diffs directly to the code owner instead? Tom ----- Original Message ----- From: "Thomas B. Jablin" To: "LLVM Developers Mailing List" Sent: Thursday, September 11, 2008 1:55:09 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to lli Hi, Here is the diff for the pod file that goes with my earlier change. Tom ----- Original Message ----- From: "Thomas B. Jablin" To: "LLVM Developers Mailing List" Sent: Thursday, September 11, 2008 1:30:24 PM GMT -05:00 US/Canada Eastern Subject: [LLVMdev] Specifying Additional Compilation Passes to lli Hi, I'm interested in specifying some additional passes to the JIT via the command-line. The enclosed patch allows lli to take compiler passes as command-line arguments in the same way opt does. This is my first submission, so any comments, criticisms, or observations would be very welcome. Thanks. Tom Jablin _______________________________________________ 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 eli.friedman at gmail.com Fri Sep 12 13:20:42 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 12 Sep 2008 11:20:42 -0700 Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <1633568469.300711221243167018.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> References: <360901584.300671221243118937.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> <1633568469.300711221243167018.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: On Fri, Sep 12, 2008 at 11:12 AM, Thomas B. Jablin wrote: > Hi, > Is this the right mailing list for sending in diffs by irregular contributers? Should I send diffs directly to the code owner instead? > Tom Here is fine; llvm-commits is also fine. It might take a little while for a non-trivial patch to get review. -Eli From sdt at rapidmind.com Fri Sep 12 13:33:11 2008 From: sdt at rapidmind.com (Stefanus Du Toit) Date: Fri, 12 Sep 2008 14:33:11 -0400 Subject: [LLVMdev] Alignment of constant loads Message-ID: Hi, We've noticed that constant loads, e.g. of v4f32 types, are not aligned to the preferred alignment but rather to the ABI alignment, at least on x86. This seems to stem from SelectionDAG::getLoad() being called with an alignment of 0, which then does: if (Alignment == 0) // Ensure that codegen never sees alignment 0 Alignment = getMVTAlignment(VT); Inside getMVTAlignment, the ABI alignment is retrieved for the given VT. It appears that constants are already aligned to the preferred alignment, given this code in ScheduleDAG::AddOperand(): } else if (ConstantPoolSDNode *CP = dyn_cast(Op)) { [...] Align = TM.getTargetData()->getPreferredTypeAlignmentShift(Type); (note there is a curious FIXME there about alignment of vector types -- I think this may be a relic since getPreferredTypeAlignmentShift should not return zero for vector types -- correct me if I'm wrong!) Do you have a suggestion as to how we can make it so that loads for constants are aligned to the preferred alignment, rather than the ABI alignment? We're not sure where this should be "fixed". Thanks! Stefanus -- Stefanus Du Toit RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 From Micah.Villmow at amd.com Fri Sep 12 13:42:53 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Fri, 12 Sep 2008 11:42:53 -0700 Subject: [LLVMdev] Selection Condition Codes In-Reply-To: References: <0F538B3E30A440469A53C9CC35C225EB03967CDB@ssanexmb1.amd.com> Message-ID: <0F538B3E30A440469A53C9CC35C225EB03967EC1@ssanexmb1.amd.com> Eli, Thanks for the tips. I've been able to get something working using a custom instruction inserter, however, I'm still having the problem of linking together the setcc and the select_cc commands. I want to turn the setcc into a comparison and use the results in the select_cc register. However, the comparison information is in the select_cc instruction and the result of the comparison is in the setcc instruction. What I am trying to figure out is using MachineInstruction/MachineBasicBlock, how I can access the previous/next instruction without having to use an iterator and parse over the whole block. Is this possible? I've put comments in the code below to help understand what I'm attempting to do. case INST::SELECT_CC: // Here we want to write a custom instruction inserter for the // select_cc operation. What we want to do is turn this into // a series of instructions that in the end become a compare // and a cmov_logical { MachineOperand Dst = MI->getOperand(0); MachineOperand TrueVal = MI->getOperand(1); MachineOperand FalseVal = MI->getOperand(2); MachineOperand CCFlag = MI->getOperand(3); CC = (INSTCC::CondCodes)MI->getOperand(3).getImm(); // Here I want to get the destination register of SET_CC instruction and place it as the first addReg TODO(Get setcc destination register); BuildMI(BB, TII.get(INST::CMOVLOG_32),Dst.getReg()).addReg(CCFlag.getImm()).addReg(T rueVal.getReg()).addReg(FalseVal.getReg()); } break; case INST::SET_CC: { MachineOperand Dst = MI->getOperand(0); MachineOperand LHS = MI->getOperand(1); MachineOperand RHS = MI->getOperand(2); // I want to get the CCFlag from the select_CC instruction // and place it in the TII.get() field. BuildMI(BB, TII.get(INST::IL_COMPARE_INSTR), Dst.getReg()).addReg(LHS.getReg()).addReg(RHS.getReg()); } default: }; Again, Thanks for any tips you might be able to share. Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Thursday, September 11, 2008 8:12 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Selection Condition Codes On Thu, Sep 11, 2008 at 6:14 PM, Villmow, Micah wrote: > I am attempting to lower the selectCC instruction to the instruction set of > the backend I'm working on and I cannot seem to find a way to correctly > implement this instruction. I know how this instruction should get > implemented; I just have yet to find a way to do it. I want the select_cc > instruction to be lowered into a comparison followed by a conditional move. "setOperationAction(ISD::SELECT_CC , MVT::Other, Expand);" should do the trick; that will prevent SELECT_CC instructions from being introduced. This one is easy to miss. > def CMOVLOG : InstFormat<(outs GPR:$dst), (ins GPR:$LHS, GPR:$RHS, > GPR:$TVAL, GPR:$FVAL, CCOp:$cond), The condition isn't properly an input... this seems likely to confuse ISel. I'm not sure, though; I'm not really an expert on patterns, and they can mess up in non-obvious ways. > Maybe I'm approaching this from the wrong way, but I don't think this > transformation should be that difficult. If you need to transform a construct into multiple instructions, there are a few different ways; one is a custom lowering, one is a selection pattern, and another is a custom inserter. Stuffing multiple actual instructions into a single target instruction is generally a bad approach. -Eli _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gohman at apple.com Fri Sep 12 13:46:55 2008 From: gohman at apple.com (Dan Gohman) Date: Fri, 12 Sep 2008 11:46:55 -0700 Subject: [LLVMdev] CPP API User-level Question: Returning multiple values In-Reply-To: <48CA9B8D.9000606@cray.com> References: <48CA9B8D.9000606@cray.com> Message-ID: <9B0280F5-A0FD-4795-A062-65646114910A@apple.com> On Sep 12, 2008, at 9:40 AM, Tony Scudiero wrote: > Greetings, Hi Tony, This is an area that's undergone some changes recently. The LLVM 2.3 multiple-return-value (MRV) syntax has been replaced by the first-class aggregates syntax in SVN trunk. > > I'm working on getting our compiler's interface to LLVM to mimic > the > way the LLVM-GCC inserts instructions to generate AMD64 ABI compliant > code. I'm trying to create > > ret i64 %mrv, double %double_mrv37 This is LLVM 2.3 MRV syntax. > > > which is basically what LLVM-GCC puts out. However if I use lcc > -march=cpp to get the API code I need it has the following line: > > ReturnInst::Create(int64_t93, label_return); > > with no reference to the double. I also can't find anything in the > doxygen docs for a version of ReturnInst::Create( ) that takes two > values for returning, nor could I find anything by generating an > intentionally bad call and letting my gen-compiler list the possible > ReturnInst which it knows about. Do I have to create the ReturnInst > in a > different way to do this? Any guidance for how to do this from within > the CPP API would be greatly appreciated. Thanks!! I don't know the details about the LLVM 2.3 interface offhand. I believe there's a form of ReturnInst::Create which you can pass multiple values, probably an array of Value*. I can tell you about how to do this with the first-class aggregates approach in svn trunk though. With first-class aggregates, it's necessary to build up the aggregate return value one piece at a time. The LLVM syntax looks like this: define { i64, double } @foo(i64 %x, double %y) nounwind { %a = insertvalue { i64, double } undef, i64 %x, 0 %b = insertvalue { i64, double } %a, double %y, 1 ret { i64, double } %b } See the LangRef.html for details on the insertvalue instruction. The -march=cpp backend in SVN trunk supports this too. Also in svn trunk, if you're using the IRBuilder interface you can use the CreateAggregateRet method, which takes care of creating the InsertValueInsts for you. Dan From eli.friedman at gmail.com Fri Sep 12 14:22:46 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 12 Sep 2008 12:22:46 -0700 Subject: [LLVMdev] Selection Condition Codes In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB03967EC1@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB03967CDB@ssanexmb1.amd.com> <0F538B3E30A440469A53C9CC35C225EB03967EC1@ssanexmb1.amd.com> Message-ID: On Fri, Sep 12, 2008 at 11:42 AM, Villmow, Micah wrote: > However, the > comparison information is in the select_cc instruction and the result of > the comparison is in the setcc instruction. What I am trying to figure > out is using MachineInstruction/MachineBasicBlock, how I can access the > previous/next instruction without having to use an iterator and parse > over the whole block. > > Is this possible? I've put comments in the code below to help understand > what I'm attempting to do. > > > case INST::SELECT_CC: I don't know too much about custom instruction inserters... so I don't have any detailed comments on the code. But how exactly are you defining INST::SET_CC and INST::SELECT_CC? If I'm understanding what you're trying to do correctly, the x86 backend deals with this using a custom lowering; see X86TargetLowering::LowerSELECT in X86ISelLowering.cpp. -Eli From overminddl1 at gmail.com Fri Sep 12 14:27:41 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Fri, 12 Sep 2008 13:27:41 -0600 Subject: [LLVMdev] Tail-calling In-Reply-To: References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <05FF3531-E4A5-482B-B208-B1EE9A016E98@apple.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48CA26DA.3070600@t-online.de> <48CA5AE5.4080907@t-online.de> <3f49a9f40809120743i7c904613i9ba94c88e08693ac@mail.gmail.com> Message-ID: <3f49a9f40809121227k64e2e165l8f924097d13efd9@mail.gmail.com> On Fri, Sep 12, 2008 at 11:40 AM, Eli Friedman wrote: > AFAIK, 128-bit integers should work just fine on x86 with LLVM. Bad example then, I meant I am wondering about how I should have my language handle things that are platform specific, whether I should expose them and let the user make 'best judgment calls' which could break on the distributed system when there are multiple programmers, or if I should just keep it to a limited instruction set that works mostly everywhere. Thoughts? Does the x86 (32-bit) backend really support 128-bit integers, or does LLVM just play nice by splitting it up among registers or something, and if it does then what is the maximum 'reasonable' size for an x86 32-bit integer? From tscud at cray.com Fri Sep 12 15:43:29 2008 From: tscud at cray.com (Tony Scudiero) Date: Fri, 12 Sep 2008 15:43:29 -0500 Subject: [LLVMdev] CPP API User-level Question: Returning multiple values In-Reply-To: <9B0280F5-A0FD-4795-A062-65646114910A@apple.com> References: <48CA9B8D.9000606@cray.com> <9B0280F5-A0FD-4795-A062-65646114910A@apple.com> Message-ID: <48CAD471.7080604@cray.com> Dan, Thanks for the info. Unfortunately for the time being we are using (for the most part) the 2.3 release (with a couple of patches that Dave Greene has applied). The first-class aggregates is one of the things we don't yet have in the LLVM we're working with. I'll look again to see if there's a ReturnInst::Create( ) which I can pass an array of llvm::Value *'s to, but I don't recall having seen one. Unfortunately it's all going to change once we do bring our LLVM up to date with changes made to trunk since the LLVM2.3 release, but do we need to get it working with the LLVM we have for the time being - which means using the 2.3 MRV syntax for the time being. Out of curiosity: does the MRV syntax will still work with first-class aggregates? Thanks! -Tony Scudiero Dan Gohman wrote: > On Sep 12, 2008, at 9:40 AM, Tony Scudiero wrote: > > >> Greetings, >> > > Hi Tony, > > This is an area that's undergone some changes recently. The LLVM 2.3 > multiple-return-value (MRV) syntax has been replaced by the > first-class aggregates syntax in SVN trunk. > > >> I'm working on getting our compiler's interface to LLVM to mimic >> the >> way the LLVM-GCC inserts instructions to generate AMD64 ABI compliant >> code. I'm trying to create >> >> ret i64 %mrv, double %double_mrv37 >> > > This is LLVM 2.3 MRV syntax. > > >> which is basically what LLVM-GCC puts out. However if I use lcc >> -march=cpp to get the API code I need it has the following line: >> >> ReturnInst::Create(int64_t93, label_return); >> >> with no reference to the double. I also can't find anything in the >> doxygen docs for a version of ReturnInst::Create( ) that takes two >> values for returning, nor could I find anything by generating an >> intentionally bad call and letting my gen-compiler list the possible >> ReturnInst which it knows about. Do I have to create the ReturnInst >> in a >> different way to do this? Any guidance for how to do this from within >> the CPP API would be greatly appreciated. Thanks!! >> > > > I don't know the details about the LLVM 2.3 interface offhand. > I believe there's a form of ReturnInst::Create which you can > pass multiple values, probably an array of Value*. > > I can tell you about how to do this with the first-class > aggregates approach in svn trunk though. > > With first-class aggregates, it's necessary to build up the > aggregate return value one piece at a time. The LLVM syntax looks > like this: > > define { i64, double } @foo(i64 %x, double %y) nounwind { > %a = insertvalue { i64, double } undef, i64 %x, 0 > %b = insertvalue { i64, double } %a, double %y, 1 > ret { i64, double } %b > } > > See the LangRef.html for details on the insertvalue instruction. > The -march=cpp backend in SVN trunk supports this too. > > Also in svn trunk, if you're using the IRBuilder interface > you can use the CreateAggregateRet method, which takes care of > creating the InsertValueInsts for you. > > Dan > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From gohman at apple.com Fri Sep 12 16:12:20 2008 From: gohman at apple.com (Dan Gohman) Date: Fri, 12 Sep 2008 14:12:20 -0700 Subject: [LLVMdev] CPP API User-level Question: Returning multiple values In-Reply-To: <48CAD471.7080604@cray.com> References: <48CA9B8D.9000606@cray.com> <9B0280F5-A0FD-4795-A062-65646114910A@apple.com> <48CAD471.7080604@cray.com> Message-ID: <2747EA4F-5B7C-423A-9BCD-669336745E08@apple.com> Hi Tony, I just checked LLVM 2.3 and ReturnInst has these: static ReturnInst* Create(Value * const* retVals, unsigned N, Instruction *InsertBefore) static ReturnInst* Create(Value * const* retVals, unsigned N, BasicBlock *InsertAtEnd) which are what you're looking for. In LLVM trunk, MRV-syntax LLVM assembly files and bitcode files are auto-upgraded to first-class aggregates in the respective readers. However at the C++ API level, clients must be adapted. Dan On Sep 12, 2008, at 1:43 PM, Tony Scudiero wrote: > Dan, > Thanks for the info. Unfortunately for the time being we are using > (for the most part) the 2.3 release (with a couple of patches that > Dave > Greene has applied). The first-class aggregates is one of the things > we > don't yet have in the LLVM we're working with. I'll look again to > see if > there's a ReturnInst::Create( ) which I can pass an array of > llvm::Value > *'s to, but I don't recall having seen one. > Unfortunately it's all going to change once we do bring our LLVM up > to date with changes made to trunk since the LLVM2.3 release, but do > we > need to get it working with the LLVM we have for the time being - > which > means using the 2.3 MRV syntax for the time being. > Out of curiosity: does the MRV syntax will still work with > first-class aggregates? > Thanks! > > -Tony Scudiero > > > Dan Gohman wrote: >> On Sep 12, 2008, at 9:40 AM, Tony Scudiero wrote: >> >> >>> Greetings, >>> >> >> Hi Tony, >> >> This is an area that's undergone some changes recently. The LLVM 2.3 >> multiple-return-value (MRV) syntax has been replaced by the >> first-class aggregates syntax in SVN trunk. >> >> >>> I'm working on getting our compiler's interface to LLVM to mimic >>> the >>> way the LLVM-GCC inserts instructions to generate AMD64 ABI >>> compliant >>> code. I'm trying to create >>> >>> ret i64 %mrv, double %double_mrv37 >>> >> >> This is LLVM 2.3 MRV syntax. >> >> >>> which is basically what LLVM-GCC puts out. However if I use lcc >>> -march=cpp to get the API code I need it has the following line: >>> >>> ReturnInst::Create(int64_t93, label_return); >>> >>> with no reference to the double. I also can't find anything in the >>> doxygen docs for a version of ReturnInst::Create( ) that takes two >>> values for returning, nor could I find anything by generating an >>> intentionally bad call and letting my gen-compiler list the possible >>> ReturnInst which it knows about. Do I have to create the ReturnInst >>> in a >>> different way to do this? Any guidance for how to do this from >>> within >>> the CPP API would be greatly appreciated. Thanks!! >>> >> >> >> I don't know the details about the LLVM 2.3 interface offhand. >> I believe there's a form of ReturnInst::Create which you can >> pass multiple values, probably an array of Value*. >> >> I can tell you about how to do this with the first-class >> aggregates approach in svn trunk though. >> >> With first-class aggregates, it's necessary to build up the >> aggregate return value one piece at a time. The LLVM syntax looks >> like this: >> >> define { i64, double } @foo(i64 %x, double %y) nounwind { >> %a = insertvalue { i64, double } undef, i64 %x, 0 >> %b = insertvalue { i64, double } %a, double %y, 1 >> ret { i64, double } %b >> } >> >> See the LangRef.html for details on the insertvalue instruction. >> The -march=cpp backend in SVN trunk supports this too. >> >> Also in svn trunk, if you're using the IRBuilder interface >> you can use the CreateAggregateRet method, which takes care of >> creating the InsertValueInsts for you. >> >> Dan >> >> _______________________________________________ >> 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 joe at x2a.org Fri Sep 12 18:06:33 2008 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Fri, 12 Sep 2008 19:06:33 -0400 Subject: [LLVMdev] [PATCH] Link in codegen components in llvm-c Message-ID: <48CAF5F9.4080701@x2a.org> This allows the use of shadow stack from the llvm-c API. I am not sure this is the place to insert the include, though. Index: include/llvm-c/ExecutionEngine.h =================================================================== --- include/llvm-c/ExecutionEngine.h (revision 56175) +++ include/llvm-c/ExecutionEngine.h (working copy) @@ -24,6 +24,7 @@ #ifdef __cplusplus extern "C" { +#include "llvm/LinkAllCodegenComponents.h" #endif typedef struct LLVMOpaqueGenericValue *LLVMGenericValueRef; Cheers, Jonathan From christian.plessl at uni-paderborn.de Sat Sep 13 06:05:41 2008 From: christian.plessl at uni-paderborn.de (Christian Plessl) Date: Sat, 13 Sep 2008 13:05:41 +0200 Subject: [LLVMdev] Using annotation attributes In-Reply-To: <20080625133348.GP438@katherina.student.utwente.nl> References: <200806051604.12450.Bart.Coppens@elis.ugent.be> <20080625133348.GP438@katherina.student.utwente.nl> Message-ID: <9F94A3CB-60D2-4692-9CFD-482967FE3F60@uni-paderborn.de> Hi all I have a project where LLVM annotations could be very useful. My current understanding of LLVM in general is still limited, hence a nice interface to annotations or sample code that uses annotations would help me to get started. I was wondering what happened to the proposal for a better interface to handling of annotations, which has been discussed in this thread back in July. Has this proposal lead to any results yet? Best regards, Christian On 25.06.2008, at 15:33, Matthijs Kooijman wrote: > Hi all, > > I've also been developing an interest in using IR annotations for my > compiler. > Some discussion with Bart turns out that he has implemented some > code to parse > the llvm.globals.annotations array, but in no way integrated or > reusable. > We've spent some thought about how this could be done properly, > which I will > share here. > > Firstly, however, I was wondering about the format of the > llvm.globals.annotations array. It does not seem to be defined in > the LLVM > language reference, shouldn't it be? It's name suggests that it is a > reserved > variable name with a fixed type (similar to intrinsic functions?). > > Furthermore, it seems that the AnnotationManager that is currently > implemented > is capable of keeping a list of Annotations for any Annotatable > (currently > only Function). These annotations are kept in memory only and really > have > nothing to do at all with the annotations in the IR. > > Still, it seems that using the AnnotationManager to make the IR > annotations > accessible seems like a decent approach. > > The way I see this is having some pass, or probably the assembly > reader or the > AnnotationManager itself, parsing the llvm.global.annotations > variable and > adding annotations to the corresponding GlobalValues. This would > just leave the > annotations in the IR as well, so that transformation passes would > properly > preserve them (and, just like debug info, sometimes be prevented from > modifying some annotated global values unless they are taught how to > preserve > the annotations). > > By using a subclass of Annotation (say, GlobalAnnotation) we can > distinguish > between annotations that are (or should be) in the IR and (the > existing) > annotations that should be in memory only. This would also allow for > newly > added annotations to be immediately be added to the IR, ensuring > that the > AnnotationManager's view remains consistent with the IR. > > In this way, any annotations added will be implicitely output when > the IR is > outputted, without any special support on the output end. > > A problem I could imagine using this approach would be name > conflicts. Since > any annotation name could come from the IR, these could conflict by > the other > names already in use (such as "CodeGen::MachineFunction" IIRC). This > could be > solved by using a "GlobalAnnotation::" prefix for the name, or > something > similar. > > A completely alternative approach would be to just use a global map to > facilitate annotation lookups, not using AnnotationManager at all. I > can see a > couple of drawbacks here. Firstly, it's a bit confusing that > AnnotationManager > would not handle IR annotations. Some decent comments and/or > renaming could > sovle that. Secondly, there is a speed gain from using > AnnotationManager. > Because annotations are stored at the Annotatable in question, > instead of in a > global map, annotations can be retrieved quickly. Also, annotations > names are > mapped onto integers, allowing for even faster comparisons and > lookups. > > So, any thoughts? > > Gr. > > Matthijs > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gordonhenriksen at me.com Sat Sep 13 08:12:43 2008 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Sat, 13 Sep 2008 09:12:43 -0400 Subject: [LLVMdev] [PATCH] Link in codegen components in llvm-c In-Reply-To: <48CAF5F9.4080701@x2a.org> References: <48CAF5F9.4080701@x2a.org> Message-ID: <06007DE3-61E1-4AE9-BBAB-A55D2E9F08C7@me.com> On 2008-09-12, at 19:06, Jonathan Bastien-Filiatrault wrote: > This allows the use of shadow stack from the llvm-c API. I am not > sure this is the place to insert the include, though. Hi Jonathan, I can't accept this patch. It pulls a bunch of C++ code into what is explicitly a C header, with the wrong linkage to boot. A more appropriate solution would be to add a binding like "void LLVMInitCodeGen(void)", defined alone in a compilation unit that #include's LinkAllCodegenComponents. The AsmWriter also has a similar header, although it isn't necessary for the ShadowStackCollector. To the list: The GC components have no public symbols; they are discoverable only through static ctors. LinkAllCodegenComponents.h introduces a use of a function that has no raison d'?tre save to be used by this header. This prevents the linker from omitting the "unused" compilation unit when linking with the archive. The back ends are packed as objects to avoid this problem. Is there no better way to force the linker to run these static ctors? > Index: include/llvm-c/ExecutionEngine.h > =================================================================== > --- include/llvm-c/ExecutionEngine.h (revision 56175) > +++ include/llvm-c/ExecutionEngine.h (working copy) > @@ -24,6 +24,7 @@ > > #ifdef __cplusplus > extern "C" { > +#include "llvm/LinkAllCodegenComponents.h" > #endif > > typedef struct LLVMOpaqueGenericValue *LLVMGenericValueRef; ? Gordon From gohman at apple.com Sat Sep 13 12:38:53 2008 From: gohman at apple.com (Dan Gohman) Date: Sat, 13 Sep 2008 10:38:53 -0700 (PDT) Subject: [LLVMdev] Alignment of constant loads Message-ID: <55603.76.220.41.203.1221327533.squirrel@webmail.apple.com> On Fri, September 12, 2008 11:33 am, Stefanus Du Toit wrote: > Hi, > > We've noticed that constant loads, e.g. of v4f32 types, are not > aligned to the preferred alignment but rather to the ABI alignment, at > least on x86. On x86 targets it's usually 16 for both preferred and ABI. I guess you're using a target with a lower ABI alignment for vectors? > This seems to stem from SelectionDAG::getLoad() being > called with an alignment of 0, which then does: > > if (Alignment == 0) // Ensure that codegen never sees alignment 0 > Alignment = getMVTAlignment(VT); > > Inside getMVTAlignment, the ABI alignment is retrieved for the given VT. > > It appears that constants are already aligned to the preferred > alignment, given this code in ScheduleDAG::AddOperand(): > > } else if (ConstantPoolSDNode *CP = > dyn_cast(Op)) { > [...] > Align = TM.getTargetData()->getPreferredTypeAlignmentShift(Type); > > (note there is a curious FIXME there about alignment of vector types > -- I think this may be a relic since getPreferredTypeAlignmentShift > should not return zero for vector types -- correct me if I'm wrong!) I'm not sure about that FIXME offhand, but overall it looks like the work this code is doing would be better placed in SelectionDAG::getConstantPool. > Do you have a suggestion as to how we can make it so that loads for > constants are aligned to the preferred alignment, rather than the ABI > alignment? We're not sure where this should be "fixed". It looks like the best way to do this is to visit the handful of places in legalize that create loads from constant pools and add alignment parameters to the getLoad/getExtLoad calls. If you move the handling of Alignment==0 out of ScheduleDAGEmit.cpp and into SelectionDAG::getConstantPool, you can then have legalize read the alignment from the node, instead of making its own decision: cast(CPIdx)->getAlignment() Dan From hendrik at topoi.pooq.com Sat Sep 13 13:09:28 2008 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 13 Sep 2008 18:09:28 +0000 (UTC) Subject: [LLVMdev] Order of fiels and structure usage References: Message-ID: On Fri, 12 Sep 2008 11:06:30 -0700, Eli Friedman wrote: > On Fri, Sep 12, 2008 at 9:35 AM, Hendrik Boom > wrote: >> I'd like to be able to make use of a structure type and its fields >> before it is completely defined. To be specific, let me ask detailed >> questions at various stages in the construction of a recursive type. I >> copy from >> >> http://llvm.org/docs/ProgrammersManual.html#TypeResolve >> >> // Create the initial outer struct >> PATypeHolder StructTy = OpaqueType::get(); >> >> Is it possible to declare variables of type StructTy at this point? > > I think you can, although you have to be careful; if you don't make sure > the variable eventually has a computable size, the module won't be > valid. Of course, eventually they type will ba fully defined. > > Declaring variables of type pointer to StructTy is completely safe. > >> std::vector Elts; >> Elts.push_back(PointerType::get(StructTy)); >> >> Is it possible to build an expression that uses the newly generated Elt >> as field-selector at this point? I'm hoping yes, but I suspect No, >> because the elments of Elts* are clearly Type* instead of being a >> field. In particular, if I use the same type twice to make two fields, >> the corresponding elements of Elts will be indistinguishable. > > I'm not following; are you trying to access the first member of NewSTy > here? You can't use a type that hasn't been created yet. You might be > able to pull some tricks with incomplete types or casts, though. What I want is to be able to use the fields that have already been defined, even though the type isn't complete yet. The vector is all I have at that moment, and it isn't a type. But by the time I have a type it's frozen and I can't add new fields to it. Do I gather that I keep making new types, each slightly larger than the previous ones, cast each pointer to my growing type to the type-of-the- moment, and field-select from it; then finally complete the type when all is known? That might just work, if field-allocation is independent of later fields, but it is ugly. The trouble is that llvm won't believe in fields until the structure is complete, and then it believes in all of them. While that's fine for semantics of the completed module, it makes less sense while the module is under construction. I view type-declaration syntax as being syntax, and I'd like it to be as flexible and modifiable as syntax anywhere else in the parse tree. The time to interpret type declarations as actually defining specific types with known semantics is after the syntax has been constructed, not before. If it's possible to do some of it statically during parse tree construction, that's fine, but it shouldn't be *required*. But it's evidently not the way llvm thinks. > > http://llvm.org/docs/LangRef.html#i_getelementptr and > http://llvm.org/docs/GetElementPtr.html might be useful here. These operations also require a completed tyle. > >> Elts.push_back(Type::Int32Ty); >> StructType *NewSTy = StructType::get(Elts); >> >> Presumably at this point is is definitely possible to declare variables >> of type NewsTy and use field-selectors from NewSTy. But it's a little >> too late for my purposes. > > Basically, the rule for opaque types is that in a valid module, you can > do anything you could do with a declaration like "struct S;" in C. Which is, basically, nothing but point to it and statically know that it's the same or different from (possibly) other types. > And in a module under construction, I'm pretty sure you can pull some > more tricks, like declaring variables with types of unknown size, or > accessing structs with members of unknown size. But not their fields, because llvm doesn't believe in fields of a structure until it has them all. If the elements of Elts were fields of a yet-to-be-identified structure, I'd be able to use them; it would make sense then to use field explicitly in the getelementptr istruction instead of the integers which have to be indexed into a type to obtain them. > > -Eli From eli.friedman at gmail.com Sat Sep 13 13:45:50 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 13 Sep 2008 11:45:50 -0700 Subject: [LLVMdev] Order of fiels and structure usage In-Reply-To: References: Message-ID: On Sat, Sep 13, 2008 at 11:09 AM, Hendrik Boom wrote: > What I want is to be able to use the fields that have already been > defined, even though the type isn't complete yet. The vector Type*> is all I have at that moment, and it isn't a type. But by the > time I have a type it's frozen and I can't add new fields to it. > > Do I gather that I keep making new types, each slightly larger than the > previous ones, cast each pointer to my growing type to the type-of-the- > moment, and field-select from it; then finally complete the type when > all is known? That might just work, if field-allocation is independent > of later fields, but it is ugly. Field-allocation is guaranteed to be independent of later fields, so the casting solution would work. It might be slightly cleaner to define the types recursively... for example, define a struct as { i32 { float { i32* } } }. That way, you wouldn't have a bunch of partial types floating around. -Eli From bonanhuang at gmail.com Sat Sep 13 14:51:55 2008 From: bonanhuang at gmail.com (James Huang) Date: Sat, 13 Sep 2008 15:51:55 -0400 Subject: [LLVMdev] Duplicate Function with duplicated Arguments Message-ID: I'm now writing a pass and I wanna ask a question about how to duplicate the function and add duplicated arguments in llvm, for example: func(int a, char *b) -> func(int a, char *b, int a1, char *b1) I'm now stuck at using "getOrInsertFunction" and how to handle "getArgumentList", please share your opinion, thanks a lot! James From matthijs at stdin.nl Sat Sep 13 15:07:16 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Sat, 13 Sep 2008 22:07:16 +0200 Subject: [LLVMdev] Overzealous PromoteCastOfAllocation In-Reply-To: <643C9D81-4750-48E5-B26C-C7699B04065B@apple.com> References: <20080908155737.GJ32157@katherina.student.utwente.nl> <643C9D81-4750-48E5-B26C-C7699B04065B@apple.com> Message-ID: <20080913200716.GF9093@katherina.student.utwente.nl> Hi Dan, > Changing PromoteCastOfAllocation to not replace aggregate allocas with > non-aggregate allocas if they have GEP users sounds reasonable to me. This sounds reasonable indeed, but still a bit arbitrary. Haven't figured out anything better yet, though. > Finding the maximum alignment is sometimes still useful though, so > it would be nice to update the alignment field of the alloca even if > its type is left unchanged. The maximizing of the alignment is done only looking at the type's ABI alignment, the actual alignment of the alloca instruction is not used. But what you suggest is that if the alloca is casted to some type that has higher alignment, you want that higher allignment propagated to the alloca instruction? I can see why this is useful, since bitcasting to a type with higher alignment can actually produce invalid code, I think? Or how does this work exactly? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080913/a7cc8e2c/attachment.bin From matthijs at stdin.nl Sat Sep 13 15:19:35 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Sat, 13 Sep 2008 22:19:35 +0200 Subject: [LLVMdev] Using annotation attributes In-Reply-To: <9F94A3CB-60D2-4692-9CFD-482967FE3F60@uni-paderborn.de> References: <200806051604.12450.Bart.Coppens@elis.ugent.be> <20080625133348.GP438@katherina.student.utwente.nl> <9F94A3CB-60D2-4692-9CFD-482967FE3F60@uni-paderborn.de> Message-ID: <20080913201935.GG9093@katherina.student.utwente.nl> Hi Christian, > I was wondering what happened to the proposal for a better interface > to handling of annotations, which has been discussed in this thread > back in July. Has this proposal lead to any results yet? So far, I've been using some code hacked up by Bart Coppens, which is very specific and not generically useful, but enough for what we need. I'd look at making something more generic, but this currently has no priority at all. Feel free to code up something nice :-) Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080913/ced3d668/attachment.bin From matthijs at stdin.nl Sat Sep 13 15:38:02 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Sat, 13 Sep 2008 22:38:02 +0200 Subject: [LLVMdev] Duplicate Function with duplicated Arguments In-Reply-To: References: Message-ID: <20080913203802.GH9093@katherina.student.utwente.nl> Hi James, > I'm now writing a pass and I wanna ask a question about how to > duplicate the function and add duplicated arguments in llvm, for > example: > > func(int a, char *b) -> func(int a, char *b, int a1, char *b1) > > I'm now stuck at using "getOrInsertFunction" and how to handle > "getArgumentList", please share your opinion, thanks a lot! I have some code which does something similar. I'll send you an example when I'm office again next monday. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080913/e1db2e44/attachment.bin From hendrik at topoi.pooq.com Sat Sep 13 21:22:09 2008 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 14 Sep 2008 02:22:09 +0000 (UTC) Subject: [LLVMdev] Order of fiels and structure usage References: Message-ID: On Sat, 13 Sep 2008 11:45:50 -0700, Eli Friedman wrote: > On Sat, Sep 13, 2008 at 11:09 AM, Hendrik Boom > wrote: >> What I want is to be able to use the fields that have already been >> defined, even though the type isn't complete yet. The vector> Type*> is all I have at that moment, and it isn't a type. But by the >> time I have a type it's frozen and I can't add new fields to it. >> >> Do I gather that I keep making new types, each slightly larger than the >> previous ones, cast each pointer to my growing type to the type-of-the- >> moment, and field-select from it; then finally complete the type when >> all is known? That might just work, if field-allocation is independent >> of later fields, but it is ugly. > > Field-allocation is guaranteed to be independent of later fields, so the > casting solution would work. Thanks for the idea. I was starting to despair about making the compiler as flexible as I wanted it without abandoning llvm. > > It might be slightly cleaner to define the types recursively... for > example, define a struct as { i32 { float { i32* } } }. That way, you > wouldn't have a bunch of partial types floating around. Just curious -- would struct{struct{i32, i8} i8} take just 6 bytes on the usual architectures? -- hendrik From eli.friedman at gmail.com Sat Sep 13 21:50:44 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 13 Sep 2008 19:50:44 -0700 Subject: [LLVMdev] Order of fiels and structure usage In-Reply-To: References: Message-ID: On Sat, Sep 13, 2008 at 7:22 PM, Hendrik Boom wrote: > Just curious -- would struct{struct{i32, i8} i8} take just 6 bytes on the > usual architectures. No... it would take 12 bytes. Assuming i32 has 4 byte ABI alignment, struct {i32, i8} has to have alignment 4 and size 8, and therefore struct{struct{i32, i8} i8} would have to have alignment 4 and size 8. The rules for LLVM struct alignment and size come from the usual C ABI for structs. struct {i32,i8,i8}, on the other hand, only takes 8 bytes. -Eli From overminddl1 at gmail.com Sat Sep 13 22:51:09 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Sat, 13 Sep 2008 21:51:09 -0600 Subject: [LLVMdev] Tail-calling In-Reply-To: <3f49a9f40809121227k64e2e165l8f924097d13efd9@mail.gmail.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48CA26DA.3070600@t-online.de> <48CA5AE5.4080907@t-online.de> <3f49a9f40809120743i7c904613i9ba94c88e08693ac@mail.gmail.com> <3f49a9f40809121227k64e2e165l8f924097d13efd9@mail.gmail.com> Message-ID: <3f49a9f40809132051p37baef5bt3b684e3cd808982d@mail.gmail.com> This language has functions that will have to be tail-called due to having the ability to 'pause' its callstack, but some functions will not and I was just planning to call them like normal functions. I am wondering, would it be 'faster' (at execution of the compiled code) to just put everything in the tail-call way, or is it still faster to call functions like normal when I can? From julio.martin.hidalgo at gmail.com Sun Sep 14 12:52:37 2008 From: julio.martin.hidalgo at gmail.com (Julio) Date: Sun, 14 Sep 2008 19:52:37 +0200 Subject: [LLVMdev] Prevent a intrinsic to be reordered? Message-ID: <832eb8bb0809141052n593ce2b2ob08e3e933de557c7@mail.gmail.com> Hello, I have an intrinsic that matches to a asm instruction directly. This intrinsic starts a coprocessor that can do anything. If I put another instruction next to it (a multiplication for example), the "llc" reorders and puts the intrinsic after the multiplication. I have tried all: - Setting the instruction like if it takes 256 cycles or 0 cycles. - Setting the instruction with "hasSideEffects" (which is ignored I think) - Setting the instruction as a load, branch, call, etc.... - .... These later things are ignored, I don't know if when the intrinsic is lowered, then it doesn't matter (or perhaps the reorder is made before). Any clues? Thanks. Julio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080914/e2df53f8/attachment.html From dpatel at apple.com Sun Sep 14 13:42:48 2008 From: dpatel at apple.com (Devang Patel) Date: Sun, 14 Sep 2008 11:42:48 -0700 Subject: [LLVMdev] xcodebuild and LLVM In-Reply-To: <2F2D1371-4B60-4BE9-A363-83A4F41BFDC1@apple.com> References: <48BF0BD0.2070609@cs.uiuc.edu> <48C6CAF1.2040100@cs.uiuc.edu> <2F2D1371-4B60-4BE9-A363-83A4F41BFDC1@apple.com> Message-ID: <3A72EC20-3F54-4FF2-A96A-52C97A6B20F3@apple.com> On Sep 11, 2008, at 9:30 PM, Ted Kremenek wrote: > Hi John, > > I'm not certain if libtool works with LLVM bitcode files, and I don't > think that all of the tools that manipulate/inspect object files on > Mac OS X understand bitcode files either. Yes. Right now only ld recognizes LLVM bitcode files. > I suspect that this will > change over time. Yes. - Devang > > > I believe that Devang and others who implemented LTO on Mac OS X can > probably provide you with specific details of tool support for bitcode > files. From asl at math.spbu.ru Sun Sep 14 14:13:59 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 14 Sep 2008 23:13:59 +0400 Subject: [LLVMdev] Prevent a intrinsic to be reordered? In-Reply-To: <832eb8bb0809141052n593ce2b2ob08e3e933de557c7@mail.gmail.com> References: <832eb8bb0809141052n593ce2b2ob08e3e933de557c7@mail.gmail.com> Message-ID: <1221419639.17492.193.camel@aslstation.lan> Hello, Julio > These later things are ignored, I don't know if when the intrinsic is > lowered, then it doesn't matter (or perhaps the reorder is made > before). What is the description of the instruction you're lowering intrinsic into? Have you looked for the instruction flags defined in Target.td file? You instruction should definitely have "isBarrier" flag set. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From overminddl1 at gmail.com Sun Sep 14 17:50:22 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Sun, 14 Sep 2008 16:50:22 -0600 Subject: [LLVMdev] [SPIRIT2] Grammar creation Message-ID: <3f49a9f40809141550y281633c9tf416411cf2dcba68@mail.gmail.com> I have two questions, but the second may not be necessary depending on the answer to this first one; in Spirit2, when creating grammars that include other grammars (that include others and so on and so forth), is it better to construct them in the grammar itself (like any other rule), or is it better to have, say, a singleton of it somewhere and link that in, and if a singleton then would it be thread-safe? From vadve at cs.uiuc.edu Sun Sep 14 23:28:06 2008 From: vadve at cs.uiuc.edu (Vikram S.Adve) Date: Sun, 14 Sep 2008 23:28:06 -0500 Subject: [LLVMdev] Simplifying C++ template error messages Message-ID: <0B989857-5208-4299-BF6D-36A6BAECEE52@cs.uiuc.edu> If anyone is interested, here is a free tool for simplifying GCC's error messages for C++ templates: http://www.bdsoft.com/tools/stlfilt.html I have not used it so this is not an endorsement :-). --Vikram http://llvm.org/~vadve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080914/44fd321b/attachment.html From julio.martin.hidalgo at gmail.com Mon Sep 15 02:16:55 2008 From: julio.martin.hidalgo at gmail.com (Julio) Date: Mon, 15 Sep 2008 09:16:55 +0200 Subject: [LLVMdev] Prevent a intrinsic to be reordered? In-Reply-To: <1221419639.17492.193.camel@aslstation.lan> References: <832eb8bb0809141052n593ce2b2ob08e3e933de557c7@mail.gmail.com> <1221419639.17492.193.camel@aslstation.lan> Message-ID: <832eb8bb0809150016m491686cdg94ac055b29d76b6a@mail.gmail.com> Nothing... I'll show you all the info related to: The intrinsic: def int_soru_sre : Intrinsic<[llvm_void_ty, llvm_i32_ty], [IntrWriteMem]>; The lower instruction (in MIPS): class SORUI op, dag outs, dag ins, string asmstr, list pattern, InstrItinClass itin>: FI { let isBarrier = 1; // or call, hassideefects, ..., nothing work } def SORU_SRE: SORUI<0b110011, (outs), (ins uimm16:$imm), "sre $imm", [(int_soru_sre imm:$imm)], IISoru>; (With IISoru I made all the possible changes: a lot of cycles or none with all the functional units or none) And an example: tail call void @llvm.soru.sre( i32 5 ) mul i32 %b, %a ; :0 [#uses=1] is coded as: mult $2, $5, $4 sre 5 Best regards. Julio 2008/9/14 Anton Korobeynikov > Hello, Julio > > > These later things are ignored, I don't know if when the intrinsic is > > lowered, then it doesn't matter (or perhaps the reorder is made > > before). > What is the description of the instruction you're lowering intrinsic > into? Have you looked for the instruction flags defined in Target.td > file? You instruction should definitely have "isBarrier" flag set. > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080915/5140bf01/attachment.html From matthijs at stdin.nl Mon Sep 15 07:13:05 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Mon, 15 Sep 2008 14:13:05 +0200 Subject: [LLVMdev] Casting between address spaces and address space semantics In-Reply-To: <027CCC7D-C97C-4F77-A543-86CCAFF54289@apple.com> References: <20080722065816.GY32587@katherina.student.utwente.nl> <20080722083606.GE32587@katherina.student.utwente.nl> <792CB930-6B16-401B-B03F-8B17255128CD@apple.com> <20080806162442.GB20166@katherina.student.utwente.nl> <20080807144142.GL20166@katherina.student.utwente.nl> <2815F17F-AC9C-4096-97D4-2FF1D7B025C9@apple.com> <20080811110937.GZ20166@katherina.student.utwente.nl> <027CCC7D-C97C-4F77-A543-86CCAFF54289@apple.com> Message-ID: <20080915121305.GA5166@katherina.student.utwente.nl> Hi Mon Ping, > If I remember correctly, I was also not fond of passing another > TargetAddrSpace reference to the TargetData object. I was hoping that we > could encode the information as a target description string like we do for > ABI information. I just don't want to end up with too many objects that > describe the machine. One can argue that we shouldn't pollute the > TargetData since it describes the ABI alignment, size, and object > layoutbut I feel that this data fits naturally there. If you and other > people feel it is cleaner with a separate pass, I'm fine with it. Perhaps encoding it in TargetData makes sense. However, I was avoiding this for now, since Chris commented a while back that he wanted to have it in TargetData "only if absolutely required". However, thinking of this a bit more I do see your point about TargetData. Another interesting advantage is that it would be a lot easier to make things consistent between clang and LLVM, by simply using the TargetData string that gets embedded in the module. So, I guess embedding this info in TargetData makes more sense. How would this look like? I would think of something like: as1:<2:=3:>4:!3 This would mean address space 1 is a subset of 2, equivalent to 3, a superset of 4 and disjoint with 3. A number of these could be present in a TargetData string, to fully describe the situation. Any relations not described mean disjoint. Relations can also be implicitely defined, ie, as1:<2-as2:<3 also implies as1:<3. I'm not sure if the > should be present, since that's always reversible. Also, ! is probably not so nice for disjoint, any other suggestions? As to implementing this, I'm thinking of a equivalency table (for every address space, store the equivalent address space with the lowest id) and for each of those lowest id spaces in each equivalency group store a set of address spaces that are a subset. This set should be complete, so when the string says A > B > C, the set should store both B and C as subsets of A. This allows for resolving the relation between two address spaces by two lookups in the equivalency table and (one or) two lookups in the subset table. No results in the subset table means the relation is disjoint, then. Any comments on this? Chris, would this be acceptable? > I want to treat my next point with some delicacy as I don't want to start a > religious war. I just want to get clarification from the community on the > use of multiple inheritance for the case of Phases like > AllDisjointAddrspaces. From what I can gather, the use of multiple > inheritance is to separate the interface (TargetAddrSpace) to access data > from the interface of the phase (ImmutablePhase). In this case, will we > ever create a concrete class from TargetAddrSpace that doesn't also derive > from ImmutablePass? If not, I don't think is worth using multiple > inheritance in this case. I think you are right here, changing the inheritance in this way also works fine. >>> For the case of a GetElementPointer, we are replacing a bitcast to a >>> pointer, getelem with a getelem bitcast. The assumption is the latter >>> bitcast will hopefully go away when we iterate through those uses. >> Uh? Is this a comment about what the current code or my patch does, or what >> it should do? I don't understand what you mean here. > My comment was more on what I thought the patch did and I wanted to confirm > that it will cleanup newly generated bit cast that are created. In that case, yes, the newly generated bitcasts should be iteratively cleaned up whenever possible. >> True, anyone actually using address space should make sure that this info >> is correct anyway. So, no need for an unknown default? > That is my feeling. Ok. > No, you got my point even though my example is not a good one. If the > address calculation was using a variable, I don't think we can fold it into > the GEP and we might lose this information. Ie, a variable that is stored to, you mean? In that case, the address space is probably propagated until the store instruction. Perhaps it can even be propagated through the store instruction, so it stores to a bitcasted pointer (ie, bitcast i32 addrspace(2)* * to i32 addrspace(1) * *). I suspect other parts of instcombine might handle this from here and change the variable's type to i32 addrspace(1), if possible. I guess this is something for later on. > The point I was trying to make is that the information needs to be > propagated through any address calculation when possible. Yes, but that shouldn't be too hard to add to the existing code. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080915/e087781e/attachment-0001.bin From tscud at cray.com Mon Sep 15 07:57:15 2008 From: tscud at cray.com (Tony Scudiero) Date: Mon, 15 Sep 2008 07:57:15 -0500 Subject: [LLVMdev] CPP API User-level Question: Returning multiple values In-Reply-To: <2747EA4F-5B7C-423A-9BCD-669336745E08@apple.com> References: <48CA9B8D.9000606@cray.com> <9B0280F5-A0FD-4795-A062-65646114910A@apple.com> <48CAD471.7080604@cray.com> <2747EA4F-5B7C-423A-9BCD-669336745E08@apple.com> Message-ID: <48CE5BAB.4060001@cray.com> Awesome. Thanks Dan. -Tony Dan Gohman wrote: > Hi Tony, > > I just checked LLVM 2.3 and ReturnInst has these: > > static ReturnInst* Create(Value * const* retVals, unsigned N, > Instruction *InsertBefore) > > static ReturnInst* Create(Value * const* retVals, unsigned N, > BasicBlock *InsertAtEnd) > > which are what you're looking for. > > In LLVM trunk, MRV-syntax LLVM assembly files and bitcode files > are auto-upgraded to first-class aggregates in the respective > readers. However at the C++ API level, clients must be adapted. > > Dan > > On Sep 12, 2008, at 1:43 PM, Tony Scudiero wrote: > > >> Dan, >> Thanks for the info. Unfortunately for the time being we are using >> (for the most part) the 2.3 release (with a couple of patches that >> Dave >> Greene has applied). The first-class aggregates is one of the things >> we >> don't yet have in the LLVM we're working with. I'll look again to >> see if >> there's a ReturnInst::Create( ) which I can pass an array of >> llvm::Value >> *'s to, but I don't recall having seen one. >> Unfortunately it's all going to change once we do bring our LLVM up >> to date with changes made to trunk since the LLVM2.3 release, but do >> we >> need to get it working with the LLVM we have for the time being - >> which >> means using the 2.3 MRV syntax for the time being. >> Out of curiosity: does the MRV syntax will still work with >> first-class aggregates? >> Thanks! >> >> -Tony Scudiero >> >> >> Dan Gohman wrote: >> >>> On Sep 12, 2008, at 9:40 AM, Tony Scudiero wrote: >>> >>> >>> >>>> Greetings, >>>> >>>> >>> Hi Tony, >>> >>> This is an area that's undergone some changes recently. The LLVM 2.3 >>> multiple-return-value (MRV) syntax has been replaced by the >>> first-class aggregates syntax in SVN trunk. >>> >>> >>> >>>> I'm working on getting our compiler's interface to LLVM to mimic >>>> the >>>> way the LLVM-GCC inserts instructions to generate AMD64 ABI >>>> compliant >>>> code. I'm trying to create >>>> >>>> ret i64 %mrv, double %double_mrv37 >>>> >>>> >>> This is LLVM 2.3 MRV syntax. >>> >>> >>> >>>> which is basically what LLVM-GCC puts out. However if I use lcc >>>> -march=cpp to get the API code I need it has the following line: >>>> >>>> ReturnInst::Create(int64_t93, label_return); >>>> >>>> with no reference to the double. I also can't find anything in the >>>> doxygen docs for a version of ReturnInst::Create( ) that takes two >>>> values for returning, nor could I find anything by generating an >>>> intentionally bad call and letting my gen-compiler list the possible >>>> ReturnInst which it knows about. Do I have to create the ReturnInst >>>> in a >>>> different way to do this? Any guidance for how to do this from >>>> within >>>> the CPP API would be greatly appreciated. Thanks!! >>>> >>>> >>> I don't know the details about the LLVM 2.3 interface offhand. >>> I believe there's a form of ReturnInst::Create which you can >>> pass multiple values, probably an array of Value*. >>> >>> I can tell you about how to do this with the first-class >>> aggregates approach in svn trunk though. >>> >>> With first-class aggregates, it's necessary to build up the >>> aggregate return value one piece at a time. The LLVM syntax looks >>> like this: >>> >>> define { i64, double } @foo(i64 %x, double %y) nounwind { >>> %a = insertvalue { i64, double } undef, i64 %x, 0 >>> %b = insertvalue { i64, double } %a, double %y, 1 >>> ret { i64, double } %b >>> } >>> >>> See the LangRef.html for details on the insertvalue instruction. >>> The -march=cpp backend in SVN trunk supports this too. >>> >>> Also in svn trunk, if you're using the IRBuilder interface >>> you can use the CreateAggregateRet method, which takes care of >>> creating the InsertValueInsts for you. >>> >>> Dan >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From andrewl at lenharth.org Mon Sep 15 08:12:03 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 15 Sep 2008 08:12:03 -0500 Subject: [LLVMdev] Prevent a intrinsic to be reordered? In-Reply-To: <832eb8bb0809141052n593ce2b2ob08e3e933de557c7@mail.gmail.com> References: <832eb8bb0809141052n593ce2b2ob08e3e933de557c7@mail.gmail.com> Message-ID: <85dfcd7f0809150612k4e8bb105p51c874d684b42f66@mail.gmail.com> On Sun, Sep 14, 2008 at 12:52 PM, Julio wrote: > Hello, I have an intrinsic that matches to a asm instruction directly. This > intrinsic starts a coprocessor that can do anything. > > If I put another instruction next to it (a multiplication for example), the > "llc" reorders and puts the intrinsic after the multiplication. > > I have tried all: > - Setting the instruction like if it takes 256 cycles or 0 cycles. > - Setting the instruction with "hasSideEffects" (which is ignored I think) > - Setting the instruction as a load, branch, call, etc.... > - .... > > These later things are ignored, I don't know if when the intrinsic is > lowered, then it doesn't matter (or perhaps the reorder is made before). > > Any clues? Does your instruction have a flag output? Andrew From bonanhuang at gmail.com Mon Sep 15 08:30:21 2008 From: bonanhuang at gmail.com (James Huang) Date: Mon, 15 Sep 2008 09:30:21 -0400 Subject: [LLVMdev] Duplicate Function with duplicated Arguments In-Reply-To: <20080913203802.GH9093@katherina.student.utwente.nl> References: <20080913203802.GH9093@katherina.student.utwente.nl> Message-ID: Thanks a lot, I appreciate your help. Regards, James On Sat, Sep 13, 2008 at 4:38 PM, Matthijs Kooijman wrote: > Hi James, >> I'm now writing a pass and I wanna ask a question about how to >> duplicate the function and add duplicated arguments in llvm, for >> example: >> >> func(int a, char *b) -> func(int a, char *b, int a1, char *b1) >> >> I'm now stuck at using "getOrInsertFunction" and how to handle >> "getArgumentList", please share your opinion, thanks a lot! > I have some code which does something similar. I'll send you an example when > I'm office again next monday. > > Gr. > > Matthijs > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIzCSqz0nQ5oovr7wRAqtwAJ45agKgB2Af77pLdI6/zz8fSvQ1CwCg1imZ > 71wcyC9cs142r7GgUIifEGQ= > =1HfN > -----END PGP SIGNATURE----- > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From matthijs at stdin.nl Mon Sep 15 09:34:41 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Mon, 15 Sep 2008 16:34:41 +0200 Subject: [LLVMdev] Duplicate Function with duplicated Arguments In-Reply-To: References: Message-ID: <20080915143441.GC5166@katherina.student.utwente.nl> Hi James, > I'm now writing a pass and I wanna ask a question about how to > duplicate the function and add duplicated arguments in llvm, for > example: Here is some example code. This code creates a new function NF that has one extra argument as the original F, named "globals". The variable Globals points to this extra argument. Also, this function adds an extra return value, containing the final value of the struct the globals argument points to. I've flagged the lines which are specific to this pass and probably not useful for you with #. Also, note that this code destroys the old function. In particular, it uses NF->getBasicBlockList().splice(NF->begin(), F->getBasicBlockList()); to move the instruction list from F to NF, effectively crippling F. For doing this without destroying F, you can look at lib/Transforms/Utils/CloneFunction.cpp. In particular the function CloneFunctionInto looks interesting, though there might be functions that can even do more stuff for you. Hope this helps, Matthijs // Start by computing a new prototype for the function, which is the same as // the old function, but has an extra argument. const llvm::FunctionType *FTy = F->getFunctionType(); /* Copy the argument types and add an extra struct */ std::vector Params(FTy->param_begin(), FTy->param_end()); Params.push_back(ArgType); // Make a new parameter attribute list (they are immutable) that has the new // argument marked as byval. Since the parameter attributes include the // return type parameters at index 0, we don't use size() - 1, but just // size() as index. llvm::PAListPtr PAL = F->getParamAttrs().addAttr(Params.size(), llvm::ParamAttr::ByVal); // New return type is simply a struct of the old type and the globals type, // or just the globals type if the original was void const llvm::Type *RetTy = F->getReturnType(); const llvm::Type *NRetTy; if (RetTy == llvm::Type::VoidTy) { NRetTy = ArgType->getElementType(); } else { NRetTy = llvm::StructType::get(RetTy, ArgType->getElementType(), NULL); } // Create the new function type based on the recomputed parameters. llvm::FunctionType *NFTy = llvm::FunctionType::get(NRetTy, Params, FTy->isVarArg()); // Create the new function body and insert it into the module... llvm::Function *NF = llvm::Function::Create(NFTy, F->getLinkage()); NF->copyAttributesFrom(F); NF->setParamAttrs(PAL); F->getParent()->getFunctionList().insert(F, NF); NF->takeName(F); for (llvm::Function::arg_iterator AI = F->arg_begin(), AE = F->arg_end(), NAI = NF->arg_begin(); AI != AE; ++AI, ++NAI) NAI->takeName(AI); llvm::Value *Globals = --NF->arg_end(); Globals->setName("globals"); # // Prepare our result # ArgAndGEPs &Result = GlobalStructs[NF]; # Result.first = Globals; // Since we have now created the new function, splice the body of the old // function right into the new function, leaving the old rotting hulk of the // function empty. NF->getBasicBlockList().splice(NF->begin(), F->getBasicBlockList()); // Now, pimp all return instructions for(llvm::Function::iterator BI = NF->begin(), BE = NF->end(); BI != BE; ++BI) if (llvm::ReturnInst *RI = llvm::dyn_cast(BI->getTerminator())) { // Don't support functions that had multiple return values assert(RI->getNumOperands() < 2); // Insert a new load instruction to return llvm::Value *Load = new llvm::LoadInst(Globals, "globalsret", RI); // Return type was void if (RetTy == llvm::Type::VoidTy) { llvm::ReturnInst::Create(Load, RI); RI->getParent()->getInstList().erase(RI); } else { // Start out with an empty struct llvm::Value *Return = llvm::ConstantAggregateZero::get(NRetTy); DOUT << "Return: " << *Return->getType(); // Insert the original return value in field 0 Return = llvm::InsertValueInst::Create(Return, RI->getOperand(0), 0, "ret", RI); DOUT << "Return: " << *Return->getType(); // Insert the globals return value in field 1 Return = llvm::InsertValueInst::Create(Return, Load, 1, "ret", RI); DOUT << "Return: " << *Return->getType(); // And update the return instruction RI->setOperand(0, Return); } } # // Create GEPs in this function # CreateGEPs(Globals, NF->getEntryBlock().begin(), Result.second); DOUT << *NF; // Replace all uses of the old arguments with the new arguments for (llvm::Function::arg_iterator I = F->arg_begin(), E = F->arg_end(), NI = NF->arg_begin(); I != E; ++I, ++NI) I->replaceAllUsesWith(NI); // Replace all callers while (!F->use_empty()) { llvm::CallSite CS = llvm::CallSite::get(F->use_back()); llvm::Instruction *Call = CS.getInstruction(); llvm::Function *CallingF = Call->getParent()->getParent(); # /* Get the global struct in our caller */ # llvm::Value* CallerGlobals = ModifyFunctionRecursive(CallingF).first; // Copy the existing arguments std::vector Args; Args.reserve(CS.arg_size()); llvm::CallSite::arg_iterator AI = CS.arg_begin(), AE = CS.arg_end(); // First, copy regular arguments for (unsigned i = 0, e = FTy->getNumParams(); i != e; ++i, ++AI) Args.push_back(*AI); // Then, insert the new argument Args.push_back(CallerGlobals); // Lastly, copy any remaining varargs for (; AI != AE; ++AI) Args.push_back(*AI); llvm::Instruction *New; llvm::Instruction *Before = Call; if (llvm::InvokeInst *II = llvm::dyn_cast(Call)) { New = llvm::InvokeInst::Create(NF, II->getNormalDest(), II->getUnwindDest(), Args.begin(), Args.end(), "", Before); llvm::cast(New)->setCallingConv(CS.getCallingConv()); llvm::cast(New)->setParamAttrs(CS.getParamAttrs()); } else { New = llvm::CallInst::Create(NF, Args.begin(), Args.end(), "", Before); llvm::cast(New)->setCallingConv(CS.getCallingConv()); llvm::cast(New)->setParamAttrs(CS.getParamAttrs()); if (llvm::cast(Call)->isTailCall()) llvm::cast(New)->setTailCall(); } if (Call->hasName()) New->takeName(Call); else New->setName(NF->getName() + ".ret"); llvm::Value *GlobalsRet; if (Call->getType() == llvm::Type::VoidTy) { // The original function returned nothing, so the new function returns // only the globals GlobalsRet = New; } else { // Split the values llvm::Value *OrigRet = llvm::ExtractValueInst::Create(New, 0, "origret", Before); GlobalsRet = llvm::ExtractValueInst::Create(New, 1, "globalsret", Before); // Replace all the uses of the original result Call->replaceAllUsesWith(OrigRet); } // Now, store the globals back new llvm::StoreInst(GlobalsRet, CallerGlobals, Before); DOUT << " Call " << *Call << " replaced, function is now " << *Call->getParent()->getParent() << "\n"; // Finally, remove the old call from the program, reducing the use-count of // F. Call->eraseFromParent(); } // Delete the old function F->eraseFromParent(); return Result; } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080915/1f10081b/attachment.bin From christian.plessl at uni-paderborn.de Mon Sep 15 09:38:48 2008 From: christian.plessl at uni-paderborn.de (Christian Plessl) Date: Mon, 15 Sep 2008 16:38:48 +0200 Subject: [LLVMdev] LLVM bindings, scope of llvm-c Message-ID: <3159EA40-EBFA-4635-BCB8-364574D20FE1@uni-paderborn.de> Hi all Last week, I performed some experiments using the python bindings to LLVM (http://code.google.com/p/llvm-py/). The goal of these experiments was to evaluate the usability of LLVM's scripting language bindings for code analysis and transformations. I found that the current version of the python bindings allows for loading, generating, JIT compiling and executing LLVM IR. However, it seems to me that the functionality for analyzing and transforming LLVM IR is still very limited. For example, it is possible to iterate over all instructions in a basic block, but I cannot find a way to get information about instructions themselves, for example getting the opcode, the operands etc. Digging deeper into the bindings and llvm-c which is the base for the llvm-py bindings, revealed that this functionality is currently not present in llvm-c and thus most of the functions in Instruction.h/ User.h/etc cannot be exposed to bindings based on llvm-c. Evidently, llvm-c could be extended to expose more details of the LLVM IR which would allow more powerful program analysis and transformations. But maybe this negates the design goals for llvm-c. - Is llvm-c meant to mirror are larger fraction of the C++ interface to language bindings? - Or is the functionality provided by llvm-c kept intentionally simple for some reason? If the latter is true, will this mean that llvm-c (and scripting language bindings using this interface) are not meant to build sophisticated analysis and transformation functions? I would appreciate, if someone could shed some light on the intended feature set for llvm-c. Best regards, Christian Disclaimer: I'm still new to LLVM and the scripting language interfaces in particular. It might be that I'm getting something wrong or that I'm talking nonsense. From overminddl1 at gmail.com Mon Sep 15 10:07:46 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 15 Sep 2008 09:07:46 -0600 Subject: [LLVMdev] LLVM bindings, scope of llvm-c In-Reply-To: <3159EA40-EBFA-4635-BCB8-364574D20FE1@uni-paderborn.de> References: <3159EA40-EBFA-4635-BCB8-364574D20FE1@uni-paderborn.de> Message-ID: <3f49a9f40809150807t6e68849g54b007884bbf9e4d@mail.gmail.com> On Mon, Sep 15, 2008 at 8:38 AM, Christian Plessl wrote: > /* snip */ There could just as easily be language bindings between C++ and Python, he chose the C bindings probably just because they were easier, but they are most certainly not required. I know that is the case in a few other scripting languages as well. From evan.cheng at apple.com Mon Sep 15 10:42:55 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 15 Sep 2008 08:42:55 -0700 Subject: [LLVMdev] Selection Condition Codes In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB03967EC1@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB03967CDB@ssanexmb1.amd.com> <0F538B3E30A440469A53C9CC35C225EB03967EC1@ssanexmb1.amd.com> Message-ID: Hi Micah, You should not need to select both setcc and select_cc. By its definition select_cc contains the conditional code as well as the two comparison operands. Also, I don't think you need to use a custom instruction inserter. That is only needed if you are converting a single instruction into multiple ones that involve CFG update. You should follow examples in x86 and other targets and do a custom lowering of select_cc instead. Evan On Sep 12, 2008, at 11:42 AM, Villmow, Micah wrote: > Eli, Thanks for the tips. > I've been able to get something working using a custom instruction > inserter, however, I'm still having the problem of linking together > the > setcc and the select_cc commands. I want to turn the setcc into a > comparison and use the results in the select_cc register. However, the > comparison information is in the select_cc instruction and the > result of > the comparison is in the setcc instruction. What I am trying to figure > out is using MachineInstruction/MachineBasicBlock, how I can access > the > previous/next instruction without having to use an iterator and parse > over the whole block. > > Is this possible? I've put comments in the code below to help > understand > what I'm attempting to do. > > > case INST::SELECT_CC: > // Here we want to write a custom instruction inserter for > the > // select_cc operation. What we want to do is turn this > into > // a series of instructions that in the end become a > compare > // and a cmov_logical > { > MachineOperand Dst = MI->getOperand(0); > MachineOperand TrueVal = MI->getOperand(1); > MachineOperand FalseVal = MI->getOperand(2); > MachineOperand CCFlag = MI->getOperand(3); > CC = (INSTCC::CondCodes)MI->getOperand(3).getImm(); > // Here I want to get the destination register > of SET_CC instruction and place it as the first addReg > TODO(Get setcc destination register); > BuildMI(BB, > TII > .get(INST::CMOVLOG_32),Dst.getReg()).addReg(CCFlag.getImm()).addReg(T > rueVal.getReg()).addReg(FalseVal.getReg()); > } > break; > case INST::SET_CC: > { > MachineOperand Dst = MI->getOperand(0); > MachineOperand LHS = MI->getOperand(1); > MachineOperand RHS = MI->getOperand(2); > // I want to get the CCFlag from the select_CC > instruction > // and place it in the TII.get() field. > BuildMI(BB, TII.get(INST::IL_COMPARE_INSTR), > Dst.getReg()).addReg(LHS.getReg()).addReg(RHS.getReg()); > } > default: > }; > > Again, > Thanks for any tips you might be able to share. > > Micah > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Eli Friedman > Sent: Thursday, September 11, 2008 8:12 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Selection Condition Codes > > On Thu, Sep 11, 2008 at 6:14 PM, Villmow, Micah > > wrote: >> I am attempting to lower the selectCC instruction to the instruction > set of >> the backend I'm working on and I cannot seem to find a way to > correctly >> implement this instruction. I know how this instruction should get >> implemented; I just have yet to find a way to do it. I want the > select_cc >> instruction to be lowered into a comparison followed by a conditional > move. > > "setOperationAction(ISD::SELECT_CC , MVT::Other, Expand);" > should do the trick; that will prevent SELECT_CC instructions from > being introduced. This one is easy to miss. > >> def CMOVLOG : InstFormat<(outs GPR:$dst), (ins GPR:$LHS, GPR: >> $RHS, >> GPR:$TVAL, GPR:$FVAL, CCOp:$cond), > > The condition isn't properly an input... this seems likely to confuse > ISel. I'm not sure, though; I'm not really an expert on patterns, and > they can mess up in non-obvious ways. > >> Maybe I'm approaching this from the wrong way, but I don't think this >> transformation should be that difficult. > > If you need to transform a construct into multiple instructions, there > are a few different ways; one is a custom lowering, one is a selection > pattern, and another is a custom inserter. Stuffing multiple actual > instructions into a single target instruction is generally a bad > approach. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From mdevan.foobar at gmail.com Mon Sep 15 11:08:14 2008 From: mdevan.foobar at gmail.com (Mahadevan R) Date: Mon, 15 Sep 2008 21:38:14 +0530 Subject: [LLVMdev] LLVM bindings, scope of llvm-c Message-ID: > From: OvermindDL1 > There could just as easily be language bindings between C++ and > Python, he chose the C bindings probably just because they were > easier, but they are most certainly not required. I know that is the > case in a few other scripting languages as well. He ( I :-) ) chose llvm-c based on the thread starting here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013318.html The current llvm-c bindings are not sufficient for llvm-py, and it "adds" more wrapper functions (intrinsics, passes etc): http://code.google.com/p/llvm-py/source/browse/trunk/llvm/extra.h Regards, -Mahadevan. PS: Please do raise bugs/requests for llvm-py at: http://code.google.com/p/llvm-py/issues/list From evan.cheng at apple.com Mon Sep 15 11:18:03 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 15 Sep 2008 09:18:03 -0700 Subject: [LLVMdev] Prevent a intrinsic to be reordered? In-Reply-To: <832eb8bb0809150016m491686cdg94ac055b29d76b6a@mail.gmail.com> References: <832eb8bb0809141052n593ce2b2ob08e3e933de557c7@mail.gmail.com> <1221419639.17492.193.camel@aslstation.lan> <832eb8bb0809150016m491686cdg94ac055b29d76b6a@mail.gmail.com> Message-ID: <7568CA50-EC35-4113-8BE4-304D5ED45F72@apple.com> Well, consider the multiply doesn't touch memory and is independent on any outputs or side effects of llvm.soru.sre intrinsics, codegen is free to reorder the two. It may require llvm extension to model an instruction that has this level of side effects. One possible short term workaround is to move the intrinsic instruction into its own basic block. But they may not work if codegen prepare sink any instruction past it or when we switch to beyond basic block instruction selection. Evan On Sep 15, 2008, at 12:16 AM, Julio wrote: > Nothing... I'll show you all the info related to: > > The intrinsic: def int_soru_sre : Intrinsic<[llvm_void_ty, > llvm_i32_ty], [IntrWriteMem]>; > > The lower instruction (in MIPS): > class SORUI op, dag outs, dag ins, string asmstr, list > pattern, > InstrItinClass itin>: FI itin> > { > let isBarrier = 1; // or call, hassideefects, ..., nothing work > } > > def SORU_SRE: SORUI<0b110011, (outs), (ins uimm16:$imm), "sre $imm", > [(int_soru_sre imm:$imm)], IISoru>; > > (With IISoru I made all the possible changes: a lot of cycles or > none with all the functional units or none) > > And an example: > tail call void @llvm.soru.sre( i32 5 ) > mul i32 %b, %a ; :0 [#uses=1] > > is coded as: > > mult $2, $5, $4 > sre 5 > > Best regards. > Julio > > 2008/9/14 Anton Korobeynikov > Hello, Julio > > > These later things are ignored, I don't know if when the intrinsic > is > > lowered, then it doesn't matter (or perhaps the reorder is made > > before). > What is the description of the instruction you're lowering intrinsic > into? Have you looked for the instruction flags defined in Target.td > file? You instruction should definitely have "isBarrier" flag set. > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > 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/20080915/4b4b303e/attachment.html From gordonhenriksen at me.com Mon Sep 15 11:27:54 2008 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Mon, 15 Sep 2008 12:27:54 -0400 Subject: [LLVMdev] LLVM bindings, scope of llvm-c In-Reply-To: <3159EA40-EBFA-4635-BCB8-364574D20FE1@uni-paderborn.de> References: <3159EA40-EBFA-4635-BCB8-364574D20FE1@uni-paderborn.de> Message-ID: <4DADB406-1FF7-4520-9E0C-8941DAD3CBC4@me.com> On 2008-09-15, at 10:38, Christian Plessl wrote: > llvm-c could be extended to expose more details of the LLVM IR which > would allow more powerful program analysis and transformations. Yes. > But maybe this negates the design goals for llvm-c. No. > Is the functionality provided by llvm-c kept intentionally simple > for some reason? They are constrained only by contributions. Patches for additional bindings are welcome. The only willful omission from the bindings are "detached" instructions. Instructions must be inserted into a basic block at creation time and can only be moved or erased (remove+delete). Likewise globals, aliases, functions, parameters, basic blocks, etc. This greatly simplifies memory management for garbage collected languages. -- Gordon From evan.cheng at apple.com Mon Sep 15 11:46:16 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 15 Sep 2008 09:46:16 -0700 Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <35004458.281651221154224067.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> References: <35004458.281651221154224067.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <21E5CB40-EBEA-435D-A96B-6C2D3E75F4C7@apple.com> Hi Tom, I don't think this is the right approach. May I ask you what passes you are trying to add? If you just want to run a number of llvm level optimization passes, the right approach is to add your own pass manager instead. Evan On Sep 11, 2008, at 10:30 AM, Thomas B. Jablin wrote: > Hi, > > I'm interested in specifying some additional passes to the JIT via > the command-line. The enclosed patch allows lli to take compiler > passes as command-line arguments in the same way opt does. This is > my first submission, so any comments, criticisms, or observations > would be very welcome. Thanks. > > Tom > Jablin > < > PassArgumentsForLLI > .diff>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tjablin at CS.Princeton.EDU Mon Sep 15 11:56:24 2008 From: tjablin at CS.Princeton.EDU (Thomas B. Jablin) Date: Mon, 15 Sep 2008 12:56:24 -0400 (EDT) Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <1440402172.337021221497514005.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <584716211.337141221497784293.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Evan, My overall goal is to support dynamic optimization in LLVM. In order to do so, I must gather profiling information at runtime, then recompile the profiled functions. Currently, I'm just adding and removing calls into my profiler in a custom pass. What is the advantage of giving the JIT a second profile manager over my current implementation? Thanks. Tom ----- Original Message ----- From: "Evan Cheng" To: "LLVM Developers Mailing List" Sent: Monday, September 15, 2008 12:46:16 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to lli Hi Tom, I don't think this is the right approach. May I ask you what passes you are trying to add? If you just want to run a number of llvm level optimization passes, the right approach is to add your own pass manager instead. Evan On Sep 11, 2008, at 10:30 AM, Thomas B. Jablin wrote: > Hi, > > I'm interested in specifying some additional passes to the JIT via > the command-line. The enclosed patch allows lli to take compiler > passes as command-line arguments in the same way opt does. This is > my first submission, so any comments, criticisms, or observations > would be very welcome. Thanks. > > Tom > Jablin > < > PassArgumentsForLLI > .diff>_______________________________________________ > 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 overminddl1 at gmail.com Mon Sep 15 13:48:40 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 15 Sep 2008 12:48:40 -0600 Subject: [LLVMdev] LLVM bindings, scope of llvm-c In-Reply-To: References: Message-ID: <3f49a9f40809151148l2ec1a623he3267a330476253d@mail.gmail.com> On Mon, Sep 15, 2008 at 10:08 AM, Mahadevan R wrote: > He ( I :-) ) chose llvm-c based on the thread starting here: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013318.html That was actually a continuation of a thread of the same name earlier that month, one that I was part of. I expressed a desire that it should be based on C++ and not the C bindings If it would have been a GSoC project I would have taken up the C++ bindings (I have certainly done enough python modules out of C++ code that I could have breezed through it pretty well, the hardest part would have actually been just figuring out what needed to be bound and what did not since I still do not know LLVM well enough to determine what people should use and what they should not, hence what is internal and not part of the actual API), but without such motivation I had other things I needed to be doing From christian.plessl at uni-paderborn.de Mon Sep 15 14:06:59 2008 From: christian.plessl at uni-paderborn.de (Christian Plessl) Date: Mon, 15 Sep 2008 21:06:59 +0200 Subject: [LLVMdev] LLVM bindings, scope of llvm-c In-Reply-To: <4DADB406-1FF7-4520-9E0C-8941DAD3CBC4@me.com> References: <3159EA40-EBFA-4635-BCB8-364574D20FE1@uni-paderborn.de> <4DADB406-1FF7-4520-9E0C-8941DAD3CBC4@me.com> Message-ID: <9C48FA8B-D5D3-4C0B-9318-18F2465C2916@uni-paderborn.de> >> Is the functionality provided by llvm-c kept intentionally simple >> for some reason? > > They are constrained only by contributions. Patches for additional > bindings are welcome. I see. In summary, the answer to my question seems to be that llvm-c is not restricted on purpose (besides the exception of detached instructions), but functions are added on demand rather than trying to mirror the whole C++ API to C. Thanks to everyone for your answers. This will help me finding the best way to continue my work. Best regards, Christian From paul at rapidmind.com Mon Sep 15 16:45:22 2008 From: paul at rapidmind.com (Paul Redmond) Date: Mon, 15 Sep 2008 17:45:22 -0400 Subject: [LLVMdev] Alignment of constant loads In-Reply-To: <55603.76.220.41.203.1221327533.squirrel@webmail.apple.com> References: <55603.76.220.41.203.1221327533.squirrel@webmail.apple.com> Message-ID: <48CED772.6050608@rapidmind.com> Hi Dan, > It looks like the best way to do this is to visit the handful of > places in legalize that create loads from constant pools and > add alignment parameters to the getLoad/getExtLoad calls. > > If you move the handling of Alignment==0 out of ScheduleDAGEmit.cpp > and into SelectionDAG::getConstantPool, you can then have legalize > read the alignment from the node, instead of making its own > decision: > cast(CPIdx)->getAlignment() > > I followed your suggestion but I've come across a bit of a snag. If you get the alignment in LegalizeDAG using: SDValue CPIdx = DAG.getConstantPool(LLVMC, TLI.getPointerTy()); unsigned Alignment = cast(CPIdx)->getAlignment(); The ConstantPoolSDNode is created using MVT i32 (TLI.getPointerTy()) and the alignment is 4 bytes. It seems there is not enough information to know that the final MVT will be v4f32 so passing the alignment to getLoad/getExtLoad in LegalizeDAG will still generate unaligned loads for constant vectors. Any ideas? thanks, Paul From prakash.prabhu at gmail.com Mon Sep 15 17:15:44 2008 From: prakash.prabhu at gmail.com (Prakash Prabhu) Date: Mon, 15 Sep 2008 18:15:44 -0400 Subject: [LLVMdev] DOTGraphTraits and GraphWriter Message-ID: <85a4cc050809151515i3b088f6awc5265c0b979c6767@mail.gmail.com> Hi all, I have two questions related to .dot graph output. Basically, I have a graph representing a program dependence graph like structure with (a) multiple edges between the same pair of nodes (b) each edge having a special (different) text/label I implemented a template-specialized version of DotGraphTraits for the my graph structure which given a node, uses a map_iterator (similar to the one used in CallGraph) to get the destination node of an outgoing edge. This works fine except that I have no clue how to support (a) and (b) since once the destination node is returned I lose access to the edge and cannot do any text annotation onto an edge of the graph. Is there some other way to achieve (a) and (b) without having to implement my own special version of GraphWriter ? thanks, Prakash From gohman at apple.com Mon Sep 15 17:52:21 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 15 Sep 2008 15:52:21 -0700 Subject: [LLVMdev] Alignment of constant loads In-Reply-To: <48CED772.6050608@rapidmind.com> References: <55603.76.220.41.203.1221327533.squirrel@webmail.apple.com> <48CED772.6050608@rapidmind.com> Message-ID: <30DADD52-CF32-4AFC-85DC-814371B48DC8@apple.com> On Sep 15, 2008, at 2:45 PM, Paul Redmond wrote: > Hi Dan, Hi Paul, > >> It looks like the best way to do this is to visit the handful of >> places in legalize that create loads from constant pools and >> add alignment parameters to the getLoad/getExtLoad calls. >> >> If you move the handling of Alignment==0 out of ScheduleDAGEmit.cpp >> and into SelectionDAG::getConstantPool, you can then have legalize >> read the alignment from the node, instead of making its own >> decision: >> cast(CPIdx)->getAlignment() >> >> > I followed your suggestion but I've come across a bit of a snag. If > you get the alignment in LegalizeDAG using: > > SDValue CPIdx = DAG.getConstantPool(LLVMC, TLI.getPointerTy()); > unsigned Alignment = cast(CPIdx)->getAlignment(); > > The ConstantPoolSDNode is created using MVT i32 (TLI.getPointerTy()) > and the alignment is 4 bytes. It seems there is not enough > information to know that the final MVT will be v4f32 so passing the > alignment to getLoad/getExtLoad in LegalizeDAG will still generate > unaligned loads for constant vectors. > > Any ideas? In SelectionDAG::getConstantPool, while VT is the type of the constant pool entry address, C is the actual constant, so the code should look at C->getType() when it needs to compute the alignment. That should allow it to obtain the desired alignment and set up the ConstantPoolSDNode correctly. Then the LegalizeDAG code you show above should work. Dan From Micah.Villmow at amd.com Mon Sep 15 18:51:54 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Mon, 15 Sep 2008 16:51:54 -0700 Subject: [LLVMdev] TableGen Calling Convention help Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C040B68@ssanexmb1.amd.com> With my backend code gen I want to assign calling parameters to a list of registers, but since I'm targeting a virtual instruction set. I don't want to be limited by the number of registers. Is there a way using TableGen to specify just a starting register to assign to for the CallingConv class and then have it just use sequential registers? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080915/8a513cb1/attachment.html From Micah.Villmow at amd.com Mon Sep 15 17:05:45 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Mon, 15 Sep 2008 15:05:45 -0700 Subject: [LLVMdev] Bad legalization? Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C040B3B@ssanexmb1.amd.com> I am getting an assert on a bad legalization. Assertion failed: Result.getValueType() == Op.getValueType() && "Bad legalization!", file ..\..\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp, line 3976 Can someone explain to me what this means in term of backend code generation, how it might be occurring, and possible ways to fix this? I don't see how the value type of an operation and the result being the same can cause an issue. The IR code in question is as follows: define void @ test_unary_func_absolute_value(i32 %x, i32 addrspace(11)* %result) { entry: %call = tail call i32 (...)* @abs( i32 %x ) ; [#uses=1] store i32 %call, i32 addrspace(11)* %result ret void } declare i32 @abs(...) Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080915/d841b24f/attachment-0001.html From eli.friedman at gmail.com Mon Sep 15 20:56:53 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 15 Sep 2008 18:56:53 -0700 Subject: [LLVMdev] Bad legalization? In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C040B3B@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C040B3B@ssanexmb1.amd.com> Message-ID: On Mon, Sep 15, 2008 at 3:05 PM, Villmow, Micah wrote: > I am getting an assert on a bad legalization. > > Assertion failed: Result.getValueType() == Op.getValueType() && "Bad > legalization!", file ..\..\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp, line > 3976 > > > > Can someone explain to me what this means in term of backend code > generation, how it might be occurring, and possible ways to fix this? I > don't see how the value type of an operation and the result being the same > can cause an issue. This roughly means that the type of the result of running SelectionDAGLegalize::LegalizeOp is not the same as the type of the argument to LegalizeOp. Most likely, your custom legalization messing up, although it's possible there's a bug in SelectionDAGLegalize::LegalizeOp. -Eli From eli.friedman at gmail.com Mon Sep 15 21:46:05 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 15 Sep 2008 19:46:05 -0700 Subject: [LLVMdev] TableGen Calling Convention help In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C040B68@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C040B68@ssanexmb1.amd.com> Message-ID: On Mon, Sep 15, 2008 at 4:51 PM, Villmow, Micah wrote: > With my backend code gen I want to assign calling parameters to a list of > registers, but since I'm targeting a virtual instruction set. I don't want > to be limited by the number of registers. Is there a way using TableGen to > specify just a starting register to assign to for the CallingConv class and > then have it just use sequential registers? No; you'll have to hack it to deal with an infinite register file. The relevant bits are include/llvm/CallingConvLower.h, utils/TableGen/CallingConvEmitter.cpp, and lib/Target/TargetCallingConv.td. None of the current LLVM targets using CodeGen have infinite registers. Although, what exactly is the calling convention? Are the arguments supposed to be in registers r0-rN, where N is the number of arguments? Or is there some way of specifying which registers to pass? Where does the caller save registers? Or does the target use something like SPARC register windows? -Eli From evan.cheng at apple.com Tue Sep 16 01:38:30 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 15 Sep 2008 23:38:30 -0700 Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <584716211.337141221497784293.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> References: <584716211.337141221497784293.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <5842BA5B-2006-4622-9439-BD52463A6517@apple.com> On Sep 15, 2008, at 9:56 AM, Thomas B. Jablin wrote: > Evan, > My overall goal is to support dynamic optimization in LLVM. In > order to do so, I must gather profiling information at runtime, then > recompile the profiled functions. Currently, I'm just adding and > removing calls into my profiler in a custom pass. What is the > advantage of giving the JIT a second profile manager over my current > implementation? Thanks. > Tom It's just a cleaner design. There are well defined pass manager, executionengine, and JIT api's. We don't want to unnecessarily extend them. JITState PM controls the codegen passes. If you want to add LLVM level optimization passes, you can simple use a separate PM to run them. Evan > > > ----- Original Message ----- > From: "Evan Cheng" > To: "LLVM Developers Mailing List" > Sent: Monday, September 15, 2008 12:46:16 PM GMT -05:00 US/Canada > Eastern > Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to lli > > Hi Tom, > > I don't think this is the right approach. May I ask you what passes > you are trying to add? If you just want to run a number of llvm level > optimization passes, the right approach is to add your own pass > manager instead. > > Evan > > On Sep 11, 2008, at 10:30 AM, Thomas B. Jablin wrote: > >> Hi, >> >> I'm interested in specifying some additional passes to the JIT via >> the command-line. The enclosed patch allows lli to take compiler >> passes as command-line arguments in the same way opt does. This is >> my first submission, so any comments, criticisms, or observations >> would be very welcome. Thanks. >> >> Tom >> Jablin >> < >> PassArgumentsForLLI >> .diff>_______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Tue Sep 16 01:47:31 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 15 Sep 2008 23:47:31 -0700 Subject: [LLVMdev] Bad legalization? In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C040B3B@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C040B3B@ssanexmb1.amd.com> Message-ID: <21E4478A-E7EB-4830-8D2F-5969A0072B42@apple.com> On Sep 15, 2008, at 3:05 PM, Villmow, Micah wrote: > I am getting an assert on a bad legalization. > Assertion failed: Result.getValueType() == Op.getValueType() && "Bad > legalization!", file ..\..\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp, > line 3976 > When you run into issues like this, it helps if you provide a bit more information. Please dump out Result, Op, DAG, and / or the DAG before legalization starts. > Can someone explain to me what this means in term of backend code > generation, how it might be occurring, and possible ways to fix > this? I don?t see how the value type of an operation and the result > being the same can cause an issue. Quite the opposite. It's asserting because the value types of op (before legalization) and Result (after) are different. Evan > The IR code in question is as follows: > > define void @ test_unary_func_absolute_value(i32 %x, i32 > addrspace(11)* %result) { > entry: > %call = tail call i32 (...)* @abs( i32 %x ) ; > [#uses=1] > store i32 %call, i32 addrspace(11)* %result > ret void > } > > declare i32 @abs(...) > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080915/2da44ee9/attachment.html From Sachin.Punyani at microchip.com Tue Sep 16 04:06:54 2008 From: Sachin.Punyani at microchip.com (Sachin.Punyani at microchip.com) Date: Tue, 16 Sep 2008 02:06:54 -0700 Subject: [LLVMdev] PHI Elimination problem Message-ID: Hi, The PHI elimination pass calls the function copyRegToReg for copy placement and then later tries to setkill to the temporary virtual register used in copy placement. For this setkill action it looks only in one instruction (last instruction for copyRegToReg) for virtual register with no use. My target has only one register and I can't do copyRegToReg in one instruction only. So I create two instructions (one:SrcReg to Stack , two:Stack to DestReg). The SrcReg here is the temporary virtual register (for PHI elimination) which should be setkill. However, the PHI Elimination pass looks only in last instruction (here: Stack to DestReg) for any NoUse register and does not find any. Therefore the intended setkill does not take place. This causes an assertion failure saying "PHI elimination vreg should have one kill, the PHI itself". Please provide some input on how this can be solved. Regards Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080916/a9acd920/attachment-0001.html From arnold.schwaighofer at gmail.com Tue Sep 16 05:38:21 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Tue, 16 Sep 2008 12:38:21 +0200 Subject: [LLVMdev] Tail-calling In-Reply-To: <3f49a9f40809132051p37baef5bt3b684e3cd808982d@mail.gmail.com> References: <3f49a9f40809081724y5a5947beide3d4209ffb23b2c@mail.gmail.com> <3f49a9f40809111633q3610eabcted9accf30e797538@mail.gmail.com> <48CA26DA.3070600@t-online.de> <48CA5AE5.4080907@t-online.de> <3f49a9f40809120743i7c904613i9ba94c88e08693ac@mail.gmail.com> <3f49a9f40809121227k64e2e165l8f924097d13efd9@mail.gmail.com> <3f49a9f40809132051p37baef5bt3b684e3cd808982d@mail.gmail.com> Message-ID: When tail call optimization is enabled functions with the calling convention fast (fastcc) follow a callee pops arguments convention. This means that every function call (to a fastcc function) will be followed by a sub [n callee pops slots] instruction. Also functions that are tail calling must ensure that they don't overwrite their arguments so there might be additional moves of arguments before a tail call. On Sun, Sep 14, 2008 at 5:51 AM, OvermindDL1 wrote: > This language has functions that will have to be tail-called due to > having the ability to 'pause' its callstack, but some functions will > not and I was just planning to call them like normal functions. I am > wondering, would it be 'faster' (at execution of the compiled code) to > just put everything in the tail-call way, or is it still faster to > call functions like normal when I can? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From tjablin at CS.Princeton.EDU Tue Sep 16 10:44:14 2008 From: tjablin at CS.Princeton.EDU (Thomas B. Jablin) Date: Tue, 16 Sep 2008 11:44:14 -0400 (EDT) Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <289855485.352951221579595505.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <48097099.353131221579854929.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Evan, So, if I understand you correctly, the design you have in mind is to: create a PassManager, pass it to the JIT on construction, and modify runJITOnFunction to run the second PassManager on the Function being jit'd before running the codegen PassManager. Thanks. Tom ----- Original Message ----- From: "Evan Cheng" To: "LLVM Developers Mailing List" Sent: Tuesday, September 16, 2008 2:38:30 AM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to lli On Sep 15, 2008, at 9:56 AM, Thomas B. Jablin wrote: > Evan, > My overall goal is to support dynamic optimization in LLVM. In > order to do so, I must gather profiling information at runtime, then > recompile the profiled functions. Currently, I'm just adding and > removing calls into my profiler in a custom pass. What is the > advantage of giving the JIT a second profile manager over my current > implementation? Thanks. > Tom It's just a cleaner design. There are well defined pass manager, executionengine, and JIT api's. We don't want to unnecessarily extend them. JITState PM controls the codegen passes. If you want to add LLVM level optimization passes, you can simple use a separate PM to run them. Evan > > > ----- Original Message ----- > From: "Evan Cheng" > To: "LLVM Developers Mailing List" > Sent: Monday, September 15, 2008 12:46:16 PM GMT -05:00 US/Canada > Eastern > Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to lli > > Hi Tom, > > I don't think this is the right approach. May I ask you what passes > you are trying to add? If you just want to run a number of llvm level > optimization passes, the right approach is to add your own pass > manager instead. > > Evan > > On Sep 11, 2008, at 10:30 AM, Thomas B. Jablin wrote: > >> Hi, >> >> I'm interested in specifying some additional passes to the JIT via >> the command-line. The enclosed patch allows lli to take compiler >> passes as command-line arguments in the same way opt does. This is >> my first submission, so any comments, criticisms, or observations >> would be very welcome. Thanks. >> >> Tom >> Jablin >> < >> PassArgumentsForLLI >> .diff>_______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From Micah.Villmow at amd.com Tue Sep 16 11:10:35 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Tue, 16 Sep 2008 09:10:35 -0700 Subject: [LLVMdev] TableGen Calling Convention help In-Reply-To: References: <5BA674C5FF7B384A92C2C95D8CC71E1C040B68@ssanexmb1.amd.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0858AD@ssanexmb1.amd.com> Eli, Yeah, I'd say it would be similar to be register rN-rN+J, where J is the number of registers and N is some offset large enough to not conflict with the register allocator. I've found a way to get it done by just specifying the numbers as an offset of the last register defined in RegisterInfo.td, but I'm not sure this is the correct way. I'll take a look at what you mentioned and see if I can figure a way out to do what I want to do. Thanks, Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Monday, September 15, 2008 7:46 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] TableGen Calling Convention help On Mon, Sep 15, 2008 at 4:51 PM, Villmow, Micah wrote: > With my backend code gen I want to assign calling parameters to a list of > registers, but since I'm targeting a virtual instruction set. I don't want > to be limited by the number of registers. Is there a way using TableGen to > specify just a starting register to assign to for the CallingConv class and > then have it just use sequential registers? No; you'll have to hack it to deal with an infinite register file. The relevant bits are include/llvm/CallingConvLower.h, utils/TableGen/CallingConvEmitter.cpp, and lib/Target/TargetCallingConv.td. None of the current LLVM targets using CodeGen have infinite registers. Although, what exactly is the calling convention? Are the arguments supposed to be in registers r0-rN, where N is the number of arguments? Or is there some way of specifying which registers to pass? Where does the caller save registers? Or does the target use something like SPARC register windows? -Eli _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Tue Sep 16 11:30:22 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 16 Sep 2008 09:30:22 -0700 Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <48097099.353131221579854929.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> References: <48097099.353131221579854929.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <33202FAB-BB9B-4F70-883A-DAFF3D14461A@apple.com> On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: > Evan, > So, if I understand you correctly, the design you have in mind is > to: create a PassManager, pass it to the JIT on construction, and > modify runJITOnFunction to run the second PassManager on the > Function being jit'd before running the codegen PassManager. Thanks. Optimiztions should be done before JIT, right? Why not run the optimizations (using the second PM) on the function that's scheduled for JIT before? Perhaps I am not understanding what you are trying to do. Evan > > Tom > > ----- Original Message ----- > From: "Evan Cheng" > To: "LLVM Developers Mailing List" > Sent: Tuesday, September 16, 2008 2:38:30 AM GMT -05:00 US/Canada > Eastern > Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to lli > > > On Sep 15, 2008, at 9:56 AM, Thomas B. Jablin wrote: > >> Evan, >> My overall goal is to support dynamic optimization in LLVM. In >> order to do so, I must gather profiling information at runtime, then >> recompile the profiled functions. Currently, I'm just adding and >> removing calls into my profiler in a custom pass. What is the >> advantage of giving the JIT a second profile manager over my current >> implementation? Thanks. >> Tom > > It's just a cleaner design. There are well defined pass manager, > executionengine, and JIT api's. We don't want to unnecessarily extend > them. JITState PM controls the codegen passes. If you want to add LLVM > level optimization passes, you can simple use a separate PM to run > them. > > Evan > >> >> >> ----- Original Message ----- >> From: "Evan Cheng" >> To: "LLVM Developers Mailing List" >> Sent: Monday, September 15, 2008 12:46:16 PM GMT -05:00 US/Canada >> Eastern >> Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to >> lli >> >> Hi Tom, >> >> I don't think this is the right approach. May I ask you what passes >> you are trying to add? If you just want to run a number of llvm level >> optimization passes, the right approach is to add your own pass >> manager instead. >> >> Evan >> >> On Sep 11, 2008, at 10:30 AM, Thomas B. Jablin wrote: >> >>> Hi, >>> >>> I'm interested in specifying some additional passes to the JIT via >>> the command-line. The enclosed patch allows lli to take compiler >>> passes as command-line arguments in the same way opt does. This is >>> my first submission, so any comments, criticisms, or observations >>> would be very welcome. Thanks. >>> >>> Tom >>> Jablin >>> < >>> PassArgumentsForLLI >>> .diff>_______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Tue Sep 16 11:42:16 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 16 Sep 2008 09:42:16 -0700 Subject: [LLVMdev] PHI Elimination problem In-Reply-To: References: Message-ID: <362593B5-A2AD-4799-96E9-12BA9E21A630@apple.com> On Sep 16, 2008, at 2:06 AM, Sachin.Punyani at microchip.com wrote: > Hi, > > The PHI elimination pass calls the function copyRegToReg for copy > placement and then later tries to setkill to the temporary virtual > register used in copy placement. For this setkill action it looks > only in one instruction (last instruction for copyRegToReg) for > virtual register with no use. > > My target has only one register and I can?t do copyRegToReg in one > instruction only. So I create two instructions (one:SrcReg to > Stack , two:Stack to DestReg). The SrcReg here is the temporary > virtual register (for PHI elimination) which should be setkill. > However, the PHI Elimination pass looks only in last instruction > (here: Stack to DestReg) for any NoUse register and does not find > any. Therefore the intended setkill does not take place. This causes > an assertion failure saying ?PHI elimination vreg should have one > kill, the PHI itself?. > > Please provide some input on how this can be solved. Yes, all places which use copyRegToReg right now assume it creates a single MI. If you want to solve this, you need to change its interface. There are a couple of options: 1. Change copyRegToReg to return by reference a list of instructions, the caller will then be responsible for adding them to the MBB. 2. copyRegToReg returns iterators which point to start and end of the copy sequence. My preference is #1. Thanks, Evan > > Regards > Sachin > _______________________________________________ > 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/20080916/bec6a3ed/attachment-0001.html From dalej at apple.com Tue Sep 16 11:44:35 2008 From: dalej at apple.com (Dale Johannesen) Date: Tue, 16 Sep 2008 09:44:35 -0700 Subject: [LLVMdev] Bad legalization? In-Reply-To: <21E4478A-E7EB-4830-8D2F-5969A0072B42@apple.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C040B3B@ssanexmb1.amd.com> <21E4478A-E7EB-4830-8D2F-5969A0072B42@apple.com> Message-ID: It is conceivable that it's sensitive to the name "abs", try changing it. On Sep 15, 2008, at 11:47 PMPDT, Evan Cheng wrote: > > On Sep 15, 2008, at 3:05 PM, Villmow, Micah wrote: > >> I am getting an assert on a bad legalization. >> Assertion failed: Result.getValueType() == Op.getValueType() && >> "Bad legalization!", file ..\..\lib\CodeGen\SelectionDAG >> \LegalizeDAG.cpp, line 3976 >> > > When you run into issues like this, it helps if you provide a bit > more information. Please dump out Result, Op, DAG, and / or the DAG > before legalization starts. > > >> Can someone explain to me what this means in term of backend code >> generation, how it might be occurring, and possible ways to fix >> this? I don?t see how the value type of an operation and the result >> being the same can cause an issue. > > Quite the opposite. It's asserting because the value types of op > (before legalization) and Result (after) are different. > > Evan > >> The IR code in question is as follows: >> >> define void @ test_unary_func_absolute_value(i32 %x, i32 >> addrspace(11)* %result) { >> entry: >> %call = tail call i32 (...)* @abs( i32 %x ) ; >> [#uses=1] >> store i32 %call, i32 addrspace(11)* %result >> ret void >> } >> >> declare i32 @abs(...) >> >> Micah Villmow >> Systems Engineer >> Advanced Technology & Performance >> Advanced Micro Devices Inc. >> 4555 Great America Pkwy, >> Santa Clara, CA. 95054 >> P: 408-572-6219 >> F: 408-572-6596 >> >> _______________________________________________ >> 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/20080916/66b9b13c/attachment.html From nunoplopes at sapo.pt Tue Sep 16 13:59:12 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Tue, 16 Sep 2008 19:59:12 +0100 Subject: [LLVMdev] missed optimizations In-Reply-To: References: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> Message-ID: <27B44C56390E4C1AB290DADDE40609C4@pc07654> Hi, As a follow up of this thread I've made a patch that implements a simple approach to propagate the function return values as described previously. It can transform e.g. the following program: define i32 @f(...) nounwind { (...) %cond = select i1 %tobool, i32 2, i32 3 ; [#uses=1] ret i32 %cond } define i32 @g(...) nounwind { entry: %call = call i32 (...)* @f() ; [#uses=1] switch i32 %call, label %sw.default [ i32 5, label %sw.bb i32 2, label %sw.bb1 i32 3, label %sw.bb2 ] sw.bb: ; preds = %entry ret i32 -1 sw.bb1: ; preds = %entry ret i32 3 sw.bb2: ; preds = %entry ret i32 55 sw.default: ; preds = %entry ret i32 0 } into: define i32 @g(...) nounwind { entry: %call = call i32 (...)* @f() ; [#uses=1] %cond = icmp eq i32 %call, 2 ; [#uses=1] %retval = select i1 %cond, i32 3, i32 55 ; [#uses=1] ret i32 %retval } This kind of transformation isn't currently done by LLVM (note that here this pass is only removing case statements. other transformations are not of my responsibility :). The patch is available at http://web.ist.utl.pt/nuno.lopes/llvm_function_ret_infer.txt I would love to ear some feedback, so that this pass can eventually be merged to the LLVM tree. In particular I'm not sure if there's a better way to track the possible return values of each function (e.g. is there any code that I can reuse?) Thanks, Nuno From andrewl at lenharth.org Tue Sep 16 14:12:10 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Tue, 16 Sep 2008 14:12:10 -0500 Subject: [LLVMdev] missed optimizations In-Reply-To: <27B44C56390E4C1AB290DADDE40609C4@pc07654> References: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654> <27B44C56390E4C1AB290DADDE40609C4@pc07654> Message-ID: <85dfcd7f0809161212g7872d08auc069f6ddcc3645f0@mail.gmail.com> On Tue, Sep 16, 2008 at 1:59 PM, Nuno Lopes wrote: > Hi, > This kind of transformation isn't currently done by LLVM (note that here > this pass is only removing case statements. other transformations are not of > my responsibility :). > The patch is available at > http://web.ist.utl.pt/nuno.lopes/llvm_function_ret_infer.txt > I would love to ear some feedback, so that this pass can eventually be > merged to the LLVM tree. In particular I'm not sure if there's a better way > to track the possible return values of each function (e.g. is there any code > that I can reuse?) AnalyzeFunction can use BB->getTerminator() rather than iterating over all instructions to find the terminator. After you Analyze all the functions, why not just iterator on the uses of the functions you found you could transform rather than on ever instruction in the module? It seems you should be able to handle any comparison with a constant by using the min or max of your set as appropriate to the cmp. Andrew From tjablin at CS.Princeton.EDU Tue Sep 16 14:17:42 2008 From: tjablin at CS.Princeton.EDU (Thomas B. Jablin) Date: Tue, 16 Sep 2008 15:17:42 -0400 (EDT) Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <1742381231.358161221592577334.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <1225682549.358201221592662506.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> ----- "Evan Cheng" wrote: > On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: > > > Evan, > > So, if I understand you correctly, the design you have in mind is > > to: create a PassManager, pass it to the JIT on construction, and > > modify runJITOnFunction to run the second PassManager on the > > Function being jit'd before running the codegen PassManager. > Thanks. > > Optimiztions should be done before JIT, right? Why not run the > optimizations (using the second PM) on the function that's scheduled > > for JIT before? Perhaps I am not understanding what you are trying to > > do. > > Evan Evan, My goal is to support dynamic optimizations. Typically, a dynamic optimization instruments code at runtime, then when enough profiling information has been gathered the code is recompiled without the instrumentation and with additional optimizations, if appropriate. Sophisticated JITs, like Hotspot, will sometimes compile the same function or code region multiple times in response to profiling information or to specialize code for varying inputs. Consider the following example function: int power(int (*func)(int), int x, int n) { int i; for (i = 0; i < n; i++) { x = power(x); } return x; } Hotspot can replace the indirect function call with an inlined copy of the called function. This transformation is impossible statically, since function pointed to by the first argument is unknown at compile time. In order to employ similar optimizations in LLVM, passes should be specifiable from the lli command-line. Furthermore, passes need to be able to interrogate the execution engine to find the Function corresponding to a pointer to a given function stub. (I have implemented this as well, and will submit it in my next patch.) Finally, the passes will need utility methods for examining the stack frame of the method being called, and for requested that functions be re-examined at each invocation. In the distant future, OSR (On-Stack Replacement) within the LLVM JIT would be nice too. Tom > > > > > Tom > > > > ----- Original Message ----- > > From: "Evan Cheng" > > To: "LLVM Developers Mailing List" > > Sent: Tuesday, September 16, 2008 2:38:30 AM GMT -05:00 US/Canada > > Eastern > > Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to > lli > > > > > > On Sep 15, 2008, at 9:56 AM, Thomas B. Jablin wrote: > > > >> Evan, > >> My overall goal is to support dynamic optimization in LLVM. In > >> order to do so, I must gather profiling information at runtime, > then > >> recompile the profiled functions. Currently, I'm just adding and > >> removing calls into my profiler in a custom pass. What is the > >> advantage of giving the JIT a second profile manager over my > current > >> implementation? Thanks. > >> Tom > > > > It's just a cleaner design. There are well defined pass manager, > > executionengine, and JIT api's. We don't want to unnecessarily > extend > > them. JITState PM controls the codegen passes. If you want to add > LLVM > > level optimization passes, you can simple use a separate PM to run > > > them. > > > > Evan > > > >> > >> > >> ----- Original Message ----- > >> From: "Evan Cheng" > >> To: "LLVM Developers Mailing List" > >> Sent: Monday, September 15, 2008 12:46:16 PM GMT -05:00 US/Canada > >> Eastern > >> Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to > > >> lli > >> > >> Hi Tom, > >> > >> I don't think this is the right approach. May I ask you what > passes > >> you are trying to add? If you just want to run a number of llvm > level > >> optimization passes, the right approach is to add your own pass > >> manager instead. > >> > >> Evan > >> > >> On Sep 11, 2008, at 10:30 AM, Thomas B. Jablin wrote: > >> > >>> Hi, > >>> > >>> I'm interested in specifying some additional passes to the JIT > via > >>> the command-line. The enclosed patch allows lli to take compiler > >>> passes as command-line arguments in the same way opt does. This > is > >>> my first submission, so any comments, criticisms, or observations > >>> would be very welcome. Thanks. > >>> > >>> Tom > >>> Jablin > >>> < > >>> PassArgumentsForLLI > >>> .diff>_______________________________________________ > >>> LLVM Developers mailing list > >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > > 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 gohman at apple.com Tue Sep 16 14:59:17 2008 From: gohman at apple.com (Dan Gohman) Date: Tue, 16 Sep 2008 12:59:17 -0700 Subject: [LLVMdev] DOTGraphTraits and GraphWriter In-Reply-To: <85a4cc050809151515i3b088f6awc5265c0b979c6767@mail.gmail.com> References: <85a4cc050809151515i3b088f6awc5265c0b979c6767@mail.gmail.com> Message-ID: <6F91F79D-EC28-4E7D-929A-7A1EF20BED78@apple.com> Hello Prakash, The SelectionDAG viewers (llc -view-isel-dags etc.) support both multiple edges between the same pair of nodes, and labels at least for each incoming edge. See lib/CodeGen/SelectionDAG/SelectionDAGPrinter.cpp for code you might use as an example, though it is a bit tricky. Dan On Sep 15, 2008, at 3:15 PM, Prakash Prabhu wrote: > Hi all, > > I have two questions related to .dot graph output. Basically, I have a > graph representing a program dependence graph like structure with > (a) multiple edges between the same pair of nodes > (b) each edge having a special (different) text/label > > I implemented a template-specialized version of DotGraphTraits for the > my graph structure which given a node, uses a map_iterator (similar to > the one used in CallGraph) to get the destination node of an outgoing > edge. This works fine except that I have no clue how to support (a) > and (b) since once the destination node is returned I lose access to > the edge and cannot do any text annotation onto an edge of the graph. > > Is there some other way to achieve (a) and (b) without having to > implement my own special version of GraphWriter ? > > thanks, > Prakash > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tjablin at CS.Princeton.EDU Tue Sep 16 15:40:54 2008 From: tjablin at CS.Princeton.EDU (Thomas B. Jablin) Date: Tue, 16 Sep 2008 16:40:54 -0400 (EDT) Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <1225682549.358201221592662506.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <1065956473.360201221597654863.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> ----- "Thomas B. Jablin" wrote: > > int power(int (*func)(int), int x, int n) { > int i; > for (i = 0; i < n; i++) { > x = power(x); > } > return x; > } > Sorry, the body of the loop should read: x = func(x); Tom From prakash.prabhu at gmail.com Tue Sep 16 16:58:59 2008 From: prakash.prabhu at gmail.com (Prakash Prabhu) Date: Tue, 16 Sep 2008 17:58:59 -0400 Subject: [LLVMdev] DOTGraphTraits and GraphWriter In-Reply-To: <6F91F79D-EC28-4E7D-929A-7A1EF20BED78@apple.com> References: <85a4cc050809151515i3b088f6awc5265c0b979c6767@mail.gmail.com> <6F91F79D-EC28-4E7D-929A-7A1EF20BED78@apple.com> Message-ID: <85a4cc050809161458i42dfa5c8ha1c99a3afc29dc34@mail.gmail.com> Hi Dan, Thanks for the reply. I got the labels for each outgoing edge (at the source node's 'structure' field) working. Is there a way to find out the outgoing edge number from EdgeIter. (Basically the Node in my graph has a a bunch of outgoing edges, so that I can just index into that collection within the node to get the appropriate edges' attributes). regards, Prakash On Tue, Sep 16, 2008 at 3:59 PM, Dan Gohman wrote: > Hello Prakash, > > The SelectionDAG viewers (llc -view-isel-dags etc.) support > both multiple edges between the same pair of nodes, and labels > at least for each incoming edge. See > lib/CodeGen/SelectionDAG/SelectionDAGPrinter.cpp for code you > might use as an example, though it is a bit tricky. > > Dan > > On Sep 15, 2008, at 3:15 PM, Prakash Prabhu wrote: > >> Hi all, >> >> I have two questions related to .dot graph output. Basically, I have a >> graph representing a program dependence graph like structure with >> (a) multiple edges between the same pair of nodes >> (b) each edge having a special (different) text/label >> >> I implemented a template-specialized version of DotGraphTraits for the >> my graph structure which given a node, uses a map_iterator (similar to >> the one used in CallGraph) to get the destination node of an outgoing >> edge. This works fine except that I have no clue how to support (a) >> and (b) since once the destination node is returned I lose access to >> the edge and cannot do any text annotation onto an edge of the graph. >> >> Is there some other way to achieve (a) and (b) without having to >> implement my own special version of GraphWriter ? >> >> thanks, >> Prakash >> _______________________________________________ >> 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 wangmp at apple.com Tue Sep 16 17:26:51 2008 From: wangmp at apple.com (Mon Ping Wang) Date: Tue, 16 Sep 2008 15:26:51 -0700 Subject: [LLVMdev] Casting between address spaces and address space semantics In-Reply-To: <20080915121305.GA5166@katherina.student.utwente.nl> References: <20080722065816.GY32587@katherina.student.utwente.nl> <20080722083606.GE32587@katherina.student.utwente.nl> <792CB930-6B16-401B-B03F-8B17255128CD@apple.com> <20080806162442.GB20166@katherina.student.utwente.nl> <20080807144142.GL20166@katherina.student.utwente.nl> <2815F17F-AC9C-4096-97D4-2FF1D7B025C9@apple.com> <20080811110937.GZ20166@katherina.student.utwente.nl> <027CCC7D-C97C-4F77-A543-86CCAFF54289@apple.com> <20080915121305.GA5166@katherina.student.utwente.nl> Message-ID: Hi Matthijs, On Sep 15, 2008, at 5:13 AM, Matthijs Kooijman wrote: > Hi Mon Ping, > >> If I remember correctly, I was also not fond of passing another >> TargetAddrSpace reference to the TargetData object. I was hoping >> that we >> could encode the information as a target description string like we >> do for >> ABI information. I just don't want to end up with too many >> objects that >> describe the machine. One can argue that we shouldn't pollute the >> TargetData since it describes the ABI alignment, size, and object >> layoutbut I feel that this data fits naturally there. If you and >> other >> people feel it is cleaner with a separate pass, I'm fine with it. > > Perhaps encoding it in TargetData makes sense. However, I was > avoiding this > for now, since Chris commented a while back that he wanted to have > it in > TargetData "only if absolutely required". > > However, thinking of this a bit more I do see your point about > TargetData. > Another interesting advantage is that it would be a lot easier to > make things > consistent between clang and LLVM, by simply using the TargetData > string > that gets embedded in the module. > > So, I guess embedding this info in TargetData makes more sense. How > would this > look like? I would think of something like: > > as1:<2:=3:>4:!3 > > This would mean address space 1 is a subset of 2, equivalent to 3, a > superset > of 4 and disjoint with 3. A number of these could be present in a > TargetData > string, to fully describe the situation. Any relations not described > mean > disjoint. Relations can also be implicitely defined, ie, as1:<2- > as2:<3 also > implies as1:<3. > > I'm not sure if the > should be present, since that's always > reversible. Also, > ! is probably not so nice for disjoint, any other suggestions? > I'm thinking it is sufficient to just have subset and equivalence. If superset makes the description more concise, it might be worth to put in. Since the default is disjoint, I don't think we need it. BTW, in the example, I assume you are just showing syntax as the system would flag an error if 1 is equivalent to 3 and disjoint to 3. > As to implementing this, I'm thinking of a equivalency table (for > every > address space, store the equivalent address space with the lowest > id) and for > each of those lowest id spaces in each equivalency group store a set > of > address spaces that are a subset. This set should be complete, so > when the > string says A > B > C, the set should store both B and C as subsets > of A. > > This allows for resolving the relation between two address spaces by > two > lookups in the equivalency table and (one or) two lookups in the > subset table. > No results in the subset table means the relation is disjoint, then. I think this is a reasonable way of going here. > > > Any comments on this? Chris, would this be acceptable? >> I want to treat my next point with some delicacy as I don't want to >> start a >> religious war. I just want to get clarification from the community >> on the >> use of multiple inheritance for the case of Phases like >> AllDisjointAddrspaces. From what I can gather, the use of multiple >> inheritance is to separate the interface (TargetAddrSpace) to >> access data >> from the interface of the phase (ImmutablePhase). In this case, >> will we >> ever create a concrete class from TargetAddrSpace that doesn't also >> derive >> from ImmutablePass? If not, I don't think is worth using multiple >> inheritance in this case. > I think you are right here, changing the inheritance in this way > also works > fine. > >>>> For the case of a GetElementPointer, we are replacing a bitcast >>>> to a >>>> pointer, getelem with a getelem bitcast. The assumption is the >>>> latter >>>> bitcast will hopefully go away when we iterate through those uses. >>> Uh? Is this a comment about what the current code or my patch >>> does, or what >>> it should do? I don't understand what you mean here. >> My comment was more on what I thought the patch did and I wanted to >> confirm >> that it will cleanup newly generated bit cast that are created. > In that case, yes, the newly generated bitcasts should be > iteratively cleaned > up whenever possible. > >>> True, anyone actually using address space should make sure that >>> this info >>> is correct anyway. So, no need for an unknown default? >> That is my feeling. > Ok. > >> No, you got my point even though my example is not a good one. If >> the >> address calculation was using a variable, I don't think we can fold >> it into >> the GEP and we might lose this information. > Ie, a variable that is stored to, you mean? In that case, the > address space is > probably propagated until the store instruction. Perhaps it can even > be > propagated through the store instruction, so it stores to a > bitcasted pointer > (ie, bitcast i32 addrspace(2)* * to i32 addrspace(1) * *). I suspect > other > parts of instcombine might handle this from here and change the > variable's > type to i32 addrspace(1), if possible. I guess this is something for > later on. > I think I meant that the address space information needs to be propagated through any temporary that is used to hold the value that might be using a different address spaces. In general, this isn't difficult but one just have to be aware of it when manipulating pointers. >> The point I was trying to make is that the information needs to be >> propagated through any address calculation when possible. > Yes, but that shouldn't be too hard to add to the existing code. > I agree, Cheers, -- Mon Ping From wangmp at apple.com Tue Sep 16 17:42:22 2008 From: wangmp at apple.com (Mon Ping Wang) Date: Tue, 16 Sep 2008 15:42:22 -0700 Subject: [LLVMdev] llvm memory barrier as a builtin Message-ID: I would like access to LLVM memory barrier instruction as a built-in from clang, which means that I need a name for it. In gcc, I see names like __builtin_ia32_mfence but those refers to X86 SSE instruction that we support. I don't see a gcc name that has the same semantics as our barrier instruction. For a name, I was thinking of __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does anyone object of adding it as built-in or have a better idea for a name? -- Mon Ping From Micah.Villmow at amd.com Tue Sep 16 17:43:54 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Tue, 16 Sep 2008 15:43:54 -0700 Subject: [LLVMdev] Custom Lowering and fneg In-Reply-To: <0F538B3E30A440469A53C9CC35C225EB0396784D@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB039677B6@ssanexmb1.amd.com> <0F538B3E30A440469A53C9CC35C225EB0396784D@ssanexmb1.amd.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0859BB@ssanexmb1.amd.com> Eli, I've been working on this for a few days and still haven't gotten this towork. I've attached my dags that you asked for, and even there it is turning the floating point instruction into an integer return value. IR code just for reference: -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Wednesday, September 10, 2008 4:20 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, September 10, 2008 3:30 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah wrote: > Generating the following LLVM IR: > > define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) > nounwind { > entry: > %neg = sub float -0.000000e+000, %x ; [#uses=1] > store float %neg, float addrspace(11)* %result > ret void > } > > However, when I attempt to run it through my backend which can handle binary > math ops correctly I keep asserting on the following item. > > Cannot yet select: 017B8010: i32 = fneg 017B7E78 That seems strange... you definitely shouldn't be seeing an fneg with an i32 result. What sorts of changes have you made to the SPARC backend? Have you tried looking at the output of "llc -view-dag-combine1-dags" and "llc -view-legalize-dags" to see where exactly this node is getting introduced? Thanks I'll get this a try. I've made quite a few changes, introduced many new instructions and formats for my backend and working on getting the various data types to work with all the new instructions. > What I cannot figure out is why it is attempting to pattern match on an i32 > when there are no i32's in my test program. With the regular SPARC backend, what ends up happening is the following: 1. The float is passed in an integer register (here's where the i32 first shows up) 2. The DAG combiner notices this, and combines the fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). 3. The store of the bit_convert gets turned into an i32 store, and there are now no more floats in the code. I removed the SPARC pattern matching instructions for the fneg instruction because I don't want this behavior. The architecture I'm targeting has different performance constraints where floating point performance is better than integer performance, so I need to turn this type of conversion off. > I've tried a custom lowering function that lowers it to dst = sub 0, src0 > and forcing it to f32, but it complains that result and the op value types > are incorrect. If you have an fneg with an i32 result, something is already messed up. > On another not, is there any known examples of using Tablegen with a > typeless register class? What do you mean? The register types that are generated themselves don't hold any type information. How the bits are treated depends on the instruction being generated. My register are 128bit in width that can hold either 32bit floats and ints, or 64 bit floats in scalar or vector form. All the other Target backends seem to have register classes for each specific use case, not a register class that can handle every case, i.e. if a 256bit register is needed, then I just use 2 sequential 128bit registers. Also, my instruction set has basically unlimited registers, I can't really seem a way to model this either. > Or with instruction formats where the modifiers are > on the registers and the instructions(i.e. mul_x2 GPR0, GPR1_neg, GPR2_abs, > which is equivalent to GPR0 = (-GPR1 * abs(GPR2)*2)? No examples I know of, but I don't think there should be any issues using multiclass, as long as there aren't too many possible modifiers; see http://llvm.org/docs/TableGenFundamentals.html and various uses in the code for how that works. Thanks, I'll go back to that and see if I can get it to work how I want. -Eli _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- A non-text attachment was scrubbed... Name: dag-combine1_test_unary_op_anegate.dot Type: application/octet-stream Size: 4111 bytes Desc: dag-combine1_test_unary_op_anegate.dot Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080916/18014eb8/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: legalize-dags_test_unary_op_anegate.dot Type: application/octet-stream Size: 3924 bytes Desc: legalize-dags_test_unary_op_anegate.dot Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080916/18014eb8/attachment-0001.obj From nunoplopes at sapo.pt Tue Sep 16 17:56:13 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Tue, 16 Sep 2008 23:56:13 +0100 Subject: [LLVMdev] missed optimizations In-Reply-To: <85dfcd7f0809161212g7872d08auc069f6ddcc3645f0@mail.gmail.com> References: <08FE45B71F1F42E8A06E991F7A17F8D7@pc07654><27B44C56390E4C1AB290DADDE40609C4@pc07654> <85dfcd7f0809161212g7872d08auc069f6ddcc3645f0@mail.gmail.com> Message-ID: > On Tue, Sep 16, 2008 at 1:59 PM, Nuno Lopes wrote: >> Hi, >> This kind of transformation isn't currently done by LLVM (note that here >> this pass is only removing case statements. other transformations are not >> of >> my responsibility :). >> The patch is available at >> http://web.ist.utl.pt/nuno.lopes/llvm_function_ret_infer.txt >> I would love to ear some feedback, so that this pass can eventually be >> merged to the LLVM tree. In particular I'm not sure if there's a better >> way >> to track the possible return values of each function (e.g. is there any >> code >> that I can reuse?) > > AnalyzeFunction can use BB->getTerminator() rather than iterating over > all instructions to find the terminator. > > After you Analyze all the functions, why not just iterator on the uses > of the functions you found you could transform rather than on ever > instruction in the module? > > It seems you should be able to handle any comparison with a constant > by using the min or max of your set as appropriate to the cmp. Hi, Thank you for your review. I've updated the patch to reflect your suggestions. I've also completed the ICmp instruction folding. Regards, Nuno From toothbrush at gatech.edu Tue Sep 16 18:01:57 2008 From: toothbrush at gatech.edu (Dane Napier van Dyck) Date: Tue, 16 Sep 2008 19:01:57 -0400 Subject: [LLVMdev] tracing stack variables Message-ID: <48D03AE5.7000808@gatech.edu> I'm trying to discern whether or not stack variables are all accessible through ExecutionEngine.cpp . Initially , I targeted the 'alloca' function as the source for all stack accession data , but I think that the function is too basic : ie , the type data may not be easily accessible from that function's scope . So my next idea was to use ExecutionEngine , because when data is allocated the information I want is already being used to determine allocation space . But I'm don't think stack accessions are included in its scope . I do need global (and static) info but I'm confident everything I need is here . I'm still interested in using XNgine::LoadFromMemory to access my stack variables but I wonder what someone more experienced would do ; Will this cover all of the bases ? ; Can I reference metadata at (or near) the pointer returned by 'alloca' to get the info I need ? thanks , dane van dyck georgia institute of technology From gordonhenriksen at me.com Tue Sep 16 18:45:34 2008 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Tue, 16 Sep 2008 19:45:34 -0400 Subject: [LLVMdev] tracing stack variables In-Reply-To: <48D03AE5.7000808@gatech.edu> References: <48D03AE5.7000808@gatech.edu> Message-ID: On 2008-09-16, at 19:01, Dane Napier van Dyck wrote: > I'm trying to discern whether or not stack variables are all > accessible through ExecutionEngine.cpp . > Initially , I targeted the 'alloca' function as the source for all > stack accession data , but I think that the function is too basic : > ie , the type data may not be easily accessible from that function's > scope . > So my next idea was to use ExecutionEngine , because when data is > allocated the information I want is already being used to determine > allocation space . But I'm don't think stack accessions are included > in its scope . I do need global (and static) info but I'm confident > everything I need is here . > I'm still interested in using XNgine::LoadFromMemory to access my > stack variables but I wonder what someone more experienced would > do ; Will this cover all of the bases ? ; Can I reference metadata > at (or near) the pointer returned by 'alloca' to get the info I need ? Doesn't sound like you're on the right track. What are you attempting to do? GC and debugger spring to mind. If you're doing garbage collection (tracing stack roots), then the shadow stack GC should work equally with the interpreter or the JIT. Slightly more sophisticated and performant GC can be implemented for statically compiled code by implementing a GCStrategy subclass and combining static stack frame metadata with an unwinding runtime to walk the machine stack. http://llvm.org/docs/GarbageCollection.html If you're attempting to inspect the stack as in a debugger, you'll have to use debug information (like gdb does); LLVM can aggressively promote to registers and eliminate stack slots, so your allocas could cease to exist. There may be libraries you can use for this; maybe someone else will chime in. ? Gordon From eli.friedman at gmail.com Tue Sep 16 19:22:06 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 16 Sep 2008 17:22:06 -0700 Subject: [LLVMdev] Custom Lowering and fneg In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0859BB@ssanexmb1.amd.com> References: <0F538B3E30A440469A53C9CC35C225EB039677B6@ssanexmb1.amd.com> <0F538B3E30A440469A53C9CC35C225EB0396784D@ssanexmb1.amd.com> <5BA674C5FF7B384A92C2C95D8CC71E1C0859BB@ssanexmb1.amd.com> Message-ID: On Tue, Sep 16, 2008 at 3:43 PM, Villmow, Micah wrote: > Eli, > I've been working on this for a few days and still haven't gotten this > towork. I've attached my dags that you asked for, and even there it is > turning the floating point instruction into an integer return value. Hmm, that's kind of strange... in that case, there's very little space for it to get messed up. Could you try setting a breakpoint in "llvm::SelectionDAG::getNode(unsigned Opcode, MVT VT, SDValue Operand)" and seeing where the fneg in question is built? -Eli From eli.friedman at gmail.com Tue Sep 16 19:23:38 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 16 Sep 2008 17:23:38 -0700 Subject: [LLVMdev] Custom Lowering and fneg In-Reply-To: References: <0F538B3E30A440469A53C9CC35C225EB039677B6@ssanexmb1.amd.com> <0F538B3E30A440469A53C9CC35C225EB0396784D@ssanexmb1.amd.com> <5BA674C5FF7B384A92C2C95D8CC71E1C0859BB@ssanexmb1.amd.com> Message-ID: On Tue, Sep 16, 2008 at 5:22 PM, Eli Friedman wrote: > On Tue, Sep 16, 2008 at 3:43 PM, Villmow, Micah wrote: >> Eli, >> I've been working on this for a few days and still haven't gotten this >> towork. I've attached my dags that you asked for, and even there it is >> turning the floating point instruction into an integer return value. > > Hmm, that's kind of strange... in that case, there's very little space > for it to get messed up. Could you try setting a breakpoint in > "llvm::SelectionDAG::getNode(unsigned Opcode, MVT VT, SDValue > Operand)" and seeing where the fneg in question is built? Bleh, sorry.., that isn't clear. It's the single-operand variant of SelectionDAG::getNode in llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp. -Eli From lefever at crhc.uiuc.edu Tue Sep 16 20:23:59 2008 From: lefever at crhc.uiuc.edu (Ryan M. Lefever) Date: Tue, 16 Sep 2008 20:23:59 -0500 Subject: [LLVMdev] variable size alloca Message-ID: <48D05C2F.8090004@crhc.uiuc.edu> To what do variable size LLVM alloca instructions get translated, when they are turned into machine code? I compiled a piece of code to bitcode and disassembled it. The disassembled code showed that there were alloca instructions with variable-sized parameters within the bitcode. When I turned the bitcode into machine code, I performed an nm on the result but didn't see any symbols referring to alloca. So, I'm guessing that they don't get translated to an alloca system call. If that's the case, to what do they get translated? Regards, Ryan From eli.friedman at gmail.com Tue Sep 16 20:36:07 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 16 Sep 2008 18:36:07 -0700 Subject: [LLVMdev] variable size alloca In-Reply-To: <48D05C2F.8090004@crhc.uiuc.edu> References: <48D05C2F.8090004@crhc.uiuc.edu> Message-ID: On Tue, Sep 16, 2008 at 6:23 PM, Ryan M. Lefever wrote: > To what do variable size LLVM alloca instructions get translated, when > they are turned into machine code? I compiled a piece of code to > bitcode and disassembled it. The disassembled code showed that there > were alloca instructions with variable-sized parameters within the > bitcode. When I turned the bitcode into machine code, I performed an nm > on the result but didn't see any symbols referring to alloca. So, I'm > guessing that they don't get translated to an alloca system call. If > that's the case, to what do they get translated? It depends on your architecture/operating system, but it normally gets transformed into arithmetic on the stack pointer. -Eli From criswell at uiuc.edu Tue Sep 16 20:34:49 2008 From: criswell at uiuc.edu (John Criswell) Date: Tue, 16 Sep 2008 20:34:49 -0500 Subject: [LLVMdev] variable size alloca In-Reply-To: <48D05C2F.8090004@crhc.uiuc.edu> References: <48D05C2F.8090004@crhc.uiuc.edu> Message-ID: <48D05EB9.9020706@uiuc.edu> Ryan M. Lefever wrote: > To what do variable size LLVM alloca instructions get translated, when > they are turned into machine code? I compiled a piece of code to > bitcode and disassembled it. The disassembled code showed that there > were alloca instructions with variable-sized parameters within the > bitcode. When I turned the bitcode into machine code, I performed an nm > on the result but didn't see any symbols referring to alloca. So, I'm > guessing that they don't get translated to an alloca system call. If > that's the case, to what do they get translated? > It's been a long time since I've looked at machine code generated by LLVM, but if I had to guess, I think it should be lowered into an instruction that adjusts the stack pointer. All alloca does is allocate stack space; an adjustment of the stack pointer (on x86, decreasing it) should suffice once the size of the allocation has been computed. -- John T. > Regards, > Ryan > > _______________________________________________ > 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 Sep 17 01:22:21 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 17 Sep 2008 08:22:21 +0200 Subject: [LLVMdev] llvm memory barrier as a builtin In-Reply-To: References: Message-ID: <200809170822.21648.baldrick@free.fr> > I would like access to LLVM memory barrier instruction as a built-in > from clang, which means that I need a name for it. In gcc, I see names > like __builtin_ia32_mfence but those refers to X86 SSE instruction > that we support. I don't see a gcc name that has the same semantics > as our barrier instruction. For a name, I was thinking of > __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does > anyone object of adding it as built-in or have a better idea for a name? What are the semantic differences? Thanks, Duncan. From eli.friedman at gmail.com Wed Sep 17 01:38:28 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 16 Sep 2008 23:38:28 -0700 Subject: [LLVMdev] llvm memory barrier as a builtin In-Reply-To: <200809170822.21648.baldrick@free.fr> References: <200809170822.21648.baldrick@free.fr> Message-ID: On Tue, Sep 16, 2008 at 11:22 PM, Duncan Sands wrote: >> I would like access to LLVM memory barrier instruction as a built-in >> from clang, which means that I need a name for it. In gcc, I see names >> like __builtin_ia32_mfence but those refers to X86 SSE instruction >> that we support. I don't see a gcc name that has the same semantics >> as our barrier instruction. For a name, I was thinking of >> __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does >> anyone object of adding it as built-in or have a better idea for a name? > > What are the semantic differences? As far as I know, there isn't a difference, just that the intrinsic isn't platform-specific. I think SSE2 mfence is equivalent to "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". -Eli From anh_quang.le at mailbox.tu-dresden.de Wed Sep 17 04:44:02 2008 From: anh_quang.le at mailbox.tu-dresden.de (Le Anh Quang) Date: Wed, 17 Sep 2008 11:44:02 +0200 Subject: [LLVMdev] instruction's type Message-ID: <000001c918a9$eae20370$c0a60a50$@le@mailbox.tu-dresden.de> Hi, I have a question about type in LLVM. Is the type of any instruction's parameter always determinate? E.g. an instruction with OPCODE %tmp = OPCODE X, Y which has two parameters X, Y. So, is there the case, that type of X or Y is unclear? Thanks for any advice Quang From nicolas.geoffray at lip6.fr Wed Sep 17 07:29:35 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Wed, 17 Sep 2008 14:29:35 +0200 Subject: [LLVMdev] instruction's type In-Reply-To: <000001c918a9$eae20370$c0a60a50$@le@mailbox.tu-dresden.de> References: <000001c918a9$eae20370$c0a60a50$@le@mailbox.tu-dresden.de> Message-ID: <48D0F82F.6090903@lip6.fr> Le Anh Quang wrote: > Hi, > I have a question about type in LLVM. Is the type of any instruction's > parameter always determinate? > E.g. an instruction with OPCODE > %tmp = OPCODE X, Y > which has two parameters X, Y. So, is there the case, that type of X or Y is > unclear? > No, OPCODE will require that X and Y have the correct types (e.g. ADD requires that X and Y have the same types) Nicolas > Thanks for any advice > Quang > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From andrewl at lenharth.org Wed Sep 17 07:50:30 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Wed, 17 Sep 2008 07:50:30 -0500 Subject: [LLVMdev] llvm memory barrier as a builtin In-Reply-To: References: Message-ID: <85dfcd7f0809170550o1ae52af2n7acd9e299eb5cd00@mail.gmail.com> On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang wrote: > > I would like access to LLVM memory barrier instruction as a built-in > from clang, which means that I need a name for it. In gcc, I see names > like __builtin_ia32_mfence but those refers to X86 SSE instruction > that we support. I don't see a gcc name that has the same semantics > as our barrier instruction. For a name, I was thinking of > __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does > anyone object of adding it as built-in or have a better idea for a name? __sync_synchronize is the gcc builtin for a memory barrier. Andrew From evan.cheng at apple.com Wed Sep 17 10:55:43 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 17 Sep 2008 08:55:43 -0700 Subject: [LLVMdev] Specifying Additional Compilation Passes to lli In-Reply-To: <1225682549.358201221592662506.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> References: <1225682549.358201221592662506.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <062DBAC0-EFF9-4A90-8438-7D001C1DB36A@apple.com> On Sep 16, 2008, at 12:17 PM, Thomas B. Jablin wrote: > > ----- "Evan Cheng" wrote: > >> On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: >> >>> Evan, >>> So, if I understand you correctly, the design you have in mind is >>> to: create a PassManager, pass it to the JIT on construction, and >>> modify runJITOnFunction to run the second PassManager on the >>> Function being jit'd before running the codegen PassManager. >> Thanks. >> >> Optimiztions should be done before JIT, right? Why not run the >> optimizations (using the second PM) on the function that's scheduled >> >> for JIT before? Perhaps I am not understanding what you are trying to >> >> do. >> >> Evan > > Evan, > My goal is to support dynamic optimizations. Typically, a dynamic > optimization instruments code at runtime, then when enough profiling > information has been gathered the code is recompiled without the > instrumentation and with additional optimizations, if appropriate. > Sophisticated JITs, like Hotspot, will sometimes compile the same > function or code region multiple times in response to profiling > information or to specialize code for varying inputs. Dynamic optimizations are being done by several systems which utilize LLVM JIT. I believe they are use a separate pass manager to control what optimization passes are run at runtime. I'd advise you to do the same. If I understand your requirement correctly, you'd like the JIT to run additional optimization passes when a function is lazily compiled, right? That will require overriding the default JITCompilerFn in JITEmitter.cpp. You'll also have to roll your own lli replacement. Fortunately that's pretty straight forward. Evan > > Consider the following example function: > > int power(int (*func)(int), int x, int n) { > int i; > for (i = 0; i < n; i++) { > x = power(x); > } > return x; > } > > Hotspot can replace the indirect function call with an inlined > copy of the called function. This transformation is impossible > statically, since function pointed to by the first argument is > unknown at compile time. In order to employ similar optimizations in > LLVM, passes should be specifiable from the lli command-line. > Furthermore, passes need to be able to interrogate the execution > engine to find the Function corresponding to a pointer to a given > function stub. (I have implemented this as well, and will submit it > in my next patch.) Finally, the passes will need utility methods for > examining the stack frame of the method being called, and for > requested that functions be re-examined at each invocation. In the > distant future, OSR (On-Stack Replacement) within the LLVM JIT would > be nice too. > Tom > >> >>> >>> Tom >>> >>> ----- Original Message ----- >>> From: "Evan Cheng" >>> To: "LLVM Developers Mailing List" >>> Sent: Tuesday, September 16, 2008 2:38:30 AM GMT -05:00 US/Canada >>> Eastern >>> Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to >> lli >>> >>> >>> On Sep 15, 2008, at 9:56 AM, Thomas B. Jablin wrote: >>> >>>> Evan, >>>> My overall goal is to support dynamic optimization in LLVM. In >>>> order to do so, I must gather profiling information at runtime, >> then >>>> recompile the profiled functions. Currently, I'm just adding and >>>> removing calls into my profiler in a custom pass. What is the >>>> advantage of giving the JIT a second profile manager over my >> current >>>> implementation? Thanks. >>>> Tom >>> >>> It's just a cleaner design. There are well defined pass manager, >>> executionengine, and JIT api's. We don't want to unnecessarily >> extend >>> them. JITState PM controls the codegen passes. If you want to add >> LLVM >>> level optimization passes, you can simple use a separate PM to run >> >>> them. >>> >>> Evan >>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Evan Cheng" >>>> To: "LLVM Developers Mailing List" >>>> Sent: Monday, September 15, 2008 12:46:16 PM GMT -05:00 US/Canada >>>> Eastern >>>> Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to >> >>>> lli >>>> >>>> Hi Tom, >>>> >>>> I don't think this is the right approach. May I ask you what >> passes >>>> you are trying to add? If you just want to run a number of llvm >> level >>>> optimization passes, the right approach is to add your own pass >>>> manager instead. >>>> >>>> Evan >>>> >>>> On Sep 11, 2008, at 10:30 AM, Thomas B. Jablin wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm interested in specifying some additional passes to the JIT >> via >>>>> the command-line. The enclosed patch allows lli to take compiler >>>>> passes as command-line arguments in the same way opt does. This >> is >>>>> my first submission, so any comments, criticisms, or observations >>>>> would be very welcome. Thanks. >>>>> >>>>> Tom >>>>> Jablin >>>>> < >>>>> PassArgumentsForLLI >>>>> .diff>_______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Wed Sep 17 10:59:27 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 17 Sep 2008 08:59:27 -0700 Subject: [LLVMdev] variable size alloca In-Reply-To: <48D05C2F.8090004@crhc.uiuc.edu> References: <48D05C2F.8090004@crhc.uiuc.edu> Message-ID: Look for DYNAMIC_STACKALLOCK in various targets to see how they are handled. When alloca() is used, two things will happen. 1. The alloca will be translated into stack adjustment instruction(s). 2. CodeGen will make sure frame pointer is used even if frame pointer optimization is in effect. Evan On Sep 16, 2008, at 6:23 PM, Ryan M. Lefever wrote: > To what do variable size LLVM alloca instructions get translated, when > they are turned into machine code? I compiled a piece of code to > bitcode and disassembled it. The disassembled code showed that there > were alloca instructions with variable-sized parameters within the > bitcode. When I turned the bitcode into machine code, I performed > an nm > on the result but didn't see any symbols referring to alloca. So, I'm > guessing that they don't get translated to an alloca system call. If > that's the case, to what do they get translated? > > Regards, > Ryan > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From toothbrush at gatech.edu Wed Sep 17 12:07:05 2008 From: toothbrush at gatech.edu (Dane Napier van Dyck) Date: Wed, 17 Sep 2008 13:07:05 -0400 Subject: [LLVMdev] tracing stack variables In-Reply-To: References: <48D03AE5.7000808@gatech.edu> Message-ID: <48D13939.6030007@gatech.edu> Gordon Henriksen wrote: > On 2008-09-16, at 19:01, Dane Napier van Dyck wrote: > >> I'm trying to discern whether or not stack variables are all >> accessible through ExecutionEngine.cpp . >> Initially , I targeted the 'alloca' function as the source for all >> stack accession data , but I think that the function is too basic : >> ie , the type data may not be easily accessible from that function's >> scope . >> So my next idea was to use ExecutionEngine , because when data is >> allocated the information I want is already being used to determine >> allocation space . But I'm don't think stack accessions are included >> in its scope . I do need global (and static) info but I'm confident >> everything I need is here . >> I'm still interested in using XNgine::LoadFromMemory to access my >> stack variables but I wonder what someone more experienced would >> do ; Will this cover all of the bases ? ; Can I reference metadata >> at (or near) the pointer returned by 'alloca' to get the info I need ? > > > Doesn't sound like you're on the right track. What are you attempting > to do? GC and debugger spring to mind. > > If you're doing garbage collection (tracing stack roots), then the > shadow stack GC should work equally with the interpreter or the JIT. > Slightly more sophisticated and performant GC can be implemented for > statically compiled code by implementing a GCStrategy subclass and > combining static stack frame metadata with an unwinding runtime to > walk the machine stack. http://llvm.org/docs/GarbageCollection.html > > If you're attempting to inspect the stack as in a debugger, you'll > have to use debug information (like gdb does); LLVM can aggressively > promote to registers and eliminate stack slots, so your allocas could > cease to exist. There may be libraries you can use for this; maybe > someone else will chime in. > > ? Gordon > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev k Gordon , I'm going to proceed with the debugger library . I don't think I'll instantiate a complete debugger tho , hopefully I can select a partner class without as much overhead . I'm going to look around to see if there is a notification available for stack changes . dane From monping at apple.com Wed Sep 17 12:10:50 2008 From: monping at apple.com (Mon Ping Wang) Date: Wed, 17 Sep 2008 10:10:50 -0700 Subject: [LLVMdev] llvm memory barrier as a builtin In-Reply-To: References: <200809170822.21648.baldrick@free.fr> Message-ID: By semantic difference, I only meant that the memory barrier is more generic that mfence, i..e., it has a different signature that allows us to express various kinds of memory barriers. -- Mon Ping On Sep 16, 2008, at 11:38 PM, Eli Friedman wrote: > On Tue, Sep 16, 2008 at 11:22 PM, Duncan Sands > wrote: >>> I would like access to LLVM memory barrier instruction as a built-in >>> from clang, which means that I need a name for it. In gcc, I see >>> names >>> like __builtin_ia32_mfence but those refers to X86 SSE instruction >>> that we support. I don't see a gcc name that has the same semantics >>> as our barrier instruction. For a name, I was thinking of >>> __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does >>> anyone object of adding it as built-in or have a better idea for a >>> name? >> >> What are the semantic differences? > > As far as I know, there isn't a difference, just that the intrinsic > isn't platform-specific. I think SSE2 mfence is equivalent to > "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From wangmp at apple.com Wed Sep 17 12:19:36 2008 From: wangmp at apple.com (Mon Ping Wang) Date: Wed, 17 Sep 2008 10:19:36 -0700 Subject: [LLVMdev] llvm memory barrier as a builtin In-Reply-To: <85dfcd7f0809170550o1ae52af2n7acd9e299eb5cd00@mail.gmail.com> References: <85dfcd7f0809170550o1ae52af2n7acd9e299eb5cd00@mail.gmail.com> Message-ID: Thanks for the info. My impression is that __sync_synchronize takes no arguments and is the memory barrier, i.e., "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is that right? I would like a little finer control to express just a write barrier (st-st) or a read barrier. -- Mon Ping On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: > On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang > wrote: >> >> I would like access to LLVM memory barrier instruction as a built-in >> from clang, which means that I need a name for it. In gcc, I see >> names >> like __builtin_ia32_mfence but those refers to X86 SSE instruction >> that we support. I don't see a gcc name that has the same semantics >> as our barrier instruction. For a name, I was thinking of >> __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does >> anyone object of adding it as built-in or have a better idea for a >> name? > > __sync_synchronize is the gcc builtin for a memory barrier. > > Andrew > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From Micah.Villmow at amd.com Wed Sep 17 14:57:13 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 17 Sep 2008 12:57:13 -0700 Subject: [LLVMdev] Custom Lowering and fneg In-Reply-To: References: <0F538B3E30A440469A53C9CC35C225EB039677B6@ssanexmb1.amd.com><0F538B3E30A440469A53C9CC35C225EB0396784D@ssanexmb1.amd.com><5BA674C5FF7B384A92C2C95D8CC71E1C0859BB@ssanexmb1.amd.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C085B2A@ssanexmb1.amd.com> Eli, Thanks for the help, I was able to fix my issue. When I was creating a getCopyToReg I was assigning it as an i32. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, September 16, 2008 5:22 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg On Tue, Sep 16, 2008 at 3:43 PM, Villmow, Micah wrote: > Eli, > I've been working on this for a few days and still haven't gotten this > towork. I've attached my dags that you asked for, and even there it is > turning the floating point instruction into an integer return value. Hmm, that's kind of strange... in that case, there's very little space for it to get messed up. Could you try setting a breakpoint in "llvm::SelectionDAG::getNode(unsigned Opcode, MVT VT, SDValue Operand)" and seeing where the fneg in question is built? -Eli _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From Micah.Villmow at amd.com Wed Sep 17 15:06:08 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 17 Sep 2008 13:06:08 -0700 Subject: [LLVMdev] store addrspace qualifier Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C085B2F@ssanexmb1.amd.com> How do I access the address qualifier from the store instruction. Given the following code: define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) nounwind { entry: %neg = sub float -0.000000e+000, %x ; [#uses=1] store float %neg, float addrspace(11)* %result ret void } When I attempt to generate this code, I'm aborting on. Cannot yet select: 017E8230: ch = store 017E7DF0, 017E8098, 017E8010, 017E81A8 <0035A078:0> alignment=4 So I am doing a custom Store function. In my LowerStore function, I get an SDValue w/ opcode of 119(store) and 4 child Operands Operand 0 is the entry token which I assume I can ignore Operand 1 is the source data(%neg), which I finally can handle correctly thanks to Eli Operand 2 is the dst location with two children, an EntryToken and Register(%result I'm guessing) Operand 3 is undef So, how do I find out the address space? The reason being different address spaces are accessed with different registers. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080917/91bcec74/attachment-0001.html From luked at cs.rochester.edu Wed Sep 17 15:14:07 2008 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Wed, 17 Sep 2008 16:14:07 -0400 Subject: [LLVMdev] llvm memory barrier as a builtin In-Reply-To: References: <85dfcd7f0809170550o1ae52af2n7acd9e299eb5cd00@mail.gmail.com> Message-ID: <48D1650F.10903@cs.rochester.edu> Mon Ping Wang wrote: > Thanks for the info. My impression is that __sync_synchronize takes > no arguments and is the memory barrier, i.e., > "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is > that right? That's my understanding as well. > I would like a little finer control to express just a > write barrier (st-st) or a read barrier. My understanding is that the only types of finer grained control in gcc are the __sync_lock_test_and_set and __sync_lock_release which appear to implement acquire/release style barriers. http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins I expect that there will be large changes once the memory model for C++0X is released, and there may be things implemented in gcc branches or even undocumented in the mainline that give you the kind of control you want. It might make sense to allow __sync_synchronize to be overloaded in the same way that LLVM's builtin is for use in clang, with the default version being the full memory barrier. Luke > > -- Mon Ping > > > On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: > >> On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang >> wrote: >>> I would like access to LLVM memory barrier instruction as a built-in >>> from clang, which means that I need a name for it. In gcc, I see >>> names >>> like __builtin_ia32_mfence but those refers to X86 SSE instruction >>> that we support. I don't see a gcc name that has the same semantics >>> as our barrier instruction. For a name, I was thinking of >>> __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does >>> anyone object of adding it as built-in or have a better idea for a >>> name? >> __sync_synchronize is the gcc builtin for a memory barrier. >> >> Andrew >> _______________________________________________ >> 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 michael_reichenbach at freenet.de Wed Sep 17 15:29:12 2008 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Wed, 17 Sep 2008 22:29:12 +0200 Subject: [LLVMdev] bc file not for Windows? Is this feature planed? Message-ID: <48D16898.3050407@freenet.de> Hi! question about: http://llvm.org/docs/GettingStartedVS.html#tutorial "Note: while you cannot do this step on Windows, you can do it on a Unix system and transfer hello.bc to Windows. Important: transfer as a binary file!" Is this feature also planed for Windows? Regards, -mr From michael_reichenbach at freenet.de Wed Sep 17 15:31:44 2008 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Wed, 17 Sep 2008 22:31:44 +0200 Subject: [LLVMdev] bc file only with llvm-gcc3? Message-ID: <48D16930.5040401@freenet.de> question about: http://llvm.org/docs/FAQ.html#translatec++ "With llvm-gcc3, this will generate program and program.bc." Is this llvm-gcc3 only out of date of is it really only llvm-gcc3? I have 'llvm-g++ (GCC) 4.2.1 (Based on Apple Inc. build 5546) (LLVM build)' installed on Ubuntu and followed that guide and it creates indeed no .bc file. Regards, -mr From eli.friedman at gmail.com Wed Sep 17 15:39:38 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 17 Sep 2008 13:39:38 -0700 Subject: [LLVMdev] bc file not for Windows? Is this feature planed? In-Reply-To: <48D16898.3050407@freenet.de> References: <48D16898.3050407@freenet.de> Message-ID: On Wed, Sep 17, 2008 at 1:29 PM, Michael Reichenbach wrote: > Hi! > > question about: > http://llvm.org/docs/GettingStartedVS.html#tutorial > "Note: while you cannot do this step on Windows, you can do it on a Unix > system and transfer hello.bc to Windows. Important: transfer as a binary > file!" > > Is this feature also planed for Windows? See http://llvm.org/releases/download.html#2.3; the download labeled "LLVM-GCC 4.2 Front End Binaries for Mingw32/x86" should do what you want. -Eli From eli.friedman at gmail.com Wed Sep 17 15:46:40 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 17 Sep 2008 13:46:40 -0700 Subject: [LLVMdev] bc file only with llvm-gcc3? In-Reply-To: <48D16930.5040401@freenet.de> References: <48D16930.5040401@freenet.de> Message-ID: On Wed, Sep 17, 2008 at 1:31 PM, Michael Reichenbach wrote: > question about: > http://llvm.org/docs/FAQ.html#translatec++ > "With llvm-gcc3, this will generate program and program.bc." > > Is this llvm-gcc3 only out of date of is it really only llvm-gcc3? Those instructions are out of date; the current version of llvm-gcc doesn't generate bitcode files unless you explicitly ask it to generate them. The correct procedure with a current LLVM and llvm-gcc is something like the following: llvm-g++ a.cpp -c -emit-llvm llvm-g++ b.cpp -c -emit-llvm llvm-link a.bc b.bc -o program.bc llc -march=c program.bc -o program.c gcc program.c -Eli From michael_reichenbach at freenet.de Wed Sep 17 16:36:46 2008 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Wed, 17 Sep 2008 23:36:46 +0200 Subject: [LLVMdev] bc file only with llvm-gcc3? In-Reply-To: References: <48D16930.5040401@freenet.de> Message-ID: <48D1786E.5040409@freenet.de> Eli Friedman schrieb: > On Wed, Sep 17, 2008 at 1:31 PM, Michael Reichenbach > wrote: >> question about: >> http://llvm.org/docs/FAQ.html#translatec++ >> "With llvm-gcc3, this will generate program and program.bc." >> >> Is this llvm-gcc3 only out of date of is it really only llvm-gcc3? > > Those instructions are out of date; the current version of llvm-gcc > doesn't generate bitcode files unless you explicitly ask it to > generate them. The correct procedure with a current LLVM and llvm-gcc > is something like the following: > > llvm-g++ a.cpp -c -emit-llvm > llvm-g++ b.cpp -c -emit-llvm > llvm-link a.bc b.bc -o program.bc > llc -march=c program.bc -o program.c > gcc program.c > > -Eli Thanks for fast response! Currently I am trying what you told me. No matter if I try " llvm-g++ a.cpp -c -emit-llvm " with "LLVM-GCC 4.2 Front End Binaries for Mingw32/x86" on Windows XP or if I am trying it on Ubuntu... Only the a.o file will be created without any error messages. The .bc file will not be created, do you know why? Regards, -mr From dalej at apple.com Wed Sep 17 16:41:54 2008 From: dalej at apple.com (Dale Johannesen) Date: Wed, 17 Sep 2008 14:41:54 -0700 Subject: [LLVMdev] bc file only with llvm-gcc3? In-Reply-To: <48D1786E.5040409@freenet.de> References: <48D16930.5040401@freenet.de> <48D1786E.5040409@freenet.de> Message-ID: On Sep 17, 2008, at 2:36 PMPDT, Michael Reichenbach wrote: > > No matter if I try " > llvm-g++ a.cpp -c -emit-llvm > " with "LLVM-GCC 4.2 Front End Binaries for Mingw32/x86" on Windows XP > or if I am trying it on Ubuntu... > > Only the a.o file will be created without any error messages. The .bc > file will not be created, do you know why? -emit-llvm doesn't change the default name for the -c output. The .o file should be llvm binary IR; if you want it named .bc, use -o a.bc If you're starting out, probably -S -emit-llvm is more useful, you can read that format. From dag at cray.com Wed Sep 17 16:51:16 2008 From: dag at cray.com (David Greene) Date: Wed, 17 Sep 2008 16:51:16 -0500 Subject: [LLVMdev] Instruction MVT::ValueTypes In-Reply-To: <3250CC8D-A534-46F8-A94C-D5ADD12910CB@apple.com> References: <200809021242.41080.dag@cray.com> <200809031514.09156.dag@cray.com> <3250CC8D-A534-46F8-A94C-D5ADD12910CB@apple.com> Message-ID: <200809171651.16377.dag@cray.com> On Wednesday 03 September 2008 15:42, Dan Gohman wrote: > For the case of MOVAPS vs. MOVAPD vs. MOVDQU (assuming you have a > micro-architecture where there's actually a difference), this can be > achieved by having instruction selection select the right instructions. > For example, find code like this in X86InstrSSE.td: > > def : Pat<(alignedloadv2i64 addr:$src), > (MOVAPSrm addr:$src)>, Requires<[HasSSE2]>; > def : Pat<(loadv2i64 addr:$src), > (MOVUPSrm addr:$src)>, Requires<[HasSSE2]>; > > and change it to not select MOVAPS for that microarchitecture, for > example. Unfortunately that doesn't help when, for example, you need to generate spill code. :) -Dave From TWilson at ugobe.com Wed Sep 17 17:00:59 2008 From: TWilson at ugobe.com (Tyler Wilson) Date: Wed, 17 Sep 2008 15:00:59 -0700 Subject: [LLVMdev] Status of LLVM ARM port Message-ID: Good day, I have looked around for this information, but I have not been able to gain a clear understanding: what is the status of the LLVM ARM backend? That is, do the following work: 1. Generating Thumb code: I saw a video online where they describe an issue with using the ARM Thumb back-end 2. Generating code for ARM9 (ARMv5?) or ARM7 (ARMv4): again, the same presentation mentioned that it only generated ARMv6 or 7. Does the back end work on older ARM processors today? I have seen the notes on the Apple provided bits to the project, but those were form early-mid 2007, and I have not seen a clear declaration on what is marked as working or not. Thank you, Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080917/f7469edd/attachment-0001.html From michael_reichenbach at freenet.de Wed Sep 17 17:39:26 2008 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Thu, 18 Sep 2008 00:39:26 +0200 Subject: [LLVMdev] bc file only with llvm-gcc3? In-Reply-To: References: <48D16930.5040401@freenet.de> <48D1786E.5040409@freenet.de> Message-ID: <48D1871E.8050802@freenet.de> Dale Johannesen schrieb: > On Sep 17, 2008, at 2:36 PMPDT, Michael Reichenbach wrote: >> No matter if I try " >> llvm-g++ a.cpp -c -emit-llvm >> " with "LLVM-GCC 4.2 Front End Binaries for Mingw32/x86" on Windows XP >> or if I am trying it on Ubuntu... >> >> Only the a.o file will be created without any error messages. The .bc >> file will not be created, do you know why? > > -emit-llvm doesn't change the default name for the -c output. > The .o file should be llvm binary IR; if you want it named .bc, use -o > a.bc > If you're starting out, probably -S -emit-llvm is more useful, you can > read that format. Ok, I understand so far. I have a partially working example now. llvm-g++ a.cpp -c -emit-llvm llvm-g++ b.cpp -c -emit-llvm llvm-link a.o b.o -o program.bc llc -march=c program.bc -o program.c gcc program.c program.c will contain some non-human generated code. But it doesn't compile with gcc. There is an error, gcc complaints about undefined reference to std::cout and such (the code was just a very small example with cout). It hasn't be converted into "C only" code, can you tell me why? Regards, -mr From wangmp at apple.com Wed Sep 17 17:45:29 2008 From: wangmp at apple.com (Mon Ping Wang) Date: Wed, 17 Sep 2008 15:45:29 -0700 Subject: [LLVMdev] store addrspace qualifier In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C085B2F@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C085B2F@ssanexmb1.amd.com> Message-ID: <63BED151-B7C7-4B30-9399-5A587140F143@apple.com> The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > How do I access the address qualifier from the store instruction. > Given the following code: > > define void @test_unary_op_anegate(float %x, float addrspace(11)* > %result) nounwind { > entry: > %neg = sub float -0.000000e+000, %x ; > [#uses=1] > store float %neg, float addrspace(11)* %result > ret void > } > When I attempt to generate this code, I?m aborting on. > Cannot yet select: 017E8230: ch = store 017E7DF0, 017E8098, > 017E8010, 017E81A8 <0035A078:0> alignment=4 > So I am doing a custom Store function. > In my LowerStore function, I get an SDValue w/ opcode of 119(store) > and 4 child Operands > Operand 0 is the entry token which I assume I can ignore > Operand 1 is the source data(%neg), which I finally can handle > correctly thanks to Eli > Operand 2 is the dst location with two children, an EntryToken and > Register(%result I?m guessing) > Operand 3 is undef > > So, how do I find out the address space? The reason being different > address spaces are accessed with different registers. > > Thanks, > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080917/94701a56/attachment.html From samuraileumas at yahoo.com Wed Sep 17 18:02:57 2008 From: samuraileumas at yahoo.com (Samuel Crow) Date: Wed, 17 Sep 2008 16:02:57 -0700 (PDT) Subject: [LLVMdev] bc file only with llvm-gcc3? In-Reply-To: <48D1871E.8050802@freenet.de> Message-ID: <724222.31273.qm@web62004.mail.re1.yahoo.com> Hello Michael, If you're just trying to run the code you can skip the llc and gcc states and go directly to lli. PowerPC and Intel x86 are the only architectures supported by the jit compiler right now but it should work fine from Windows. The C output backend needs some work since C isn't a low-level language enough to compile the abstractions of LLVM Assembly code. --Sam Crow --- On Wed, 9/17/08, Michael Reichenbach wrote: > From: Michael Reichenbach > Subject: Re: [LLVMdev] bc file only with llvm-gcc3? > To: "LLVM Developers Mailing List" > Date: Wednesday, September 17, 2008, 5:39 PM > Dale Johannesen schrieb: > > On Sep 17, 2008, at 2:36 PMPDT, Michael Reichenbach > wrote: > >> No matter if I try " > >> llvm-g++ a.cpp -c -emit-llvm > >> " with "LLVM-GCC 4.2 Front End Binaries > for Mingw32/x86" on Windows XP > >> or if I am trying it on Ubuntu... > >> > >> Only the a.o file will be created without any > error messages. The .bc > >> file will not be created, do you know why? > > > > -emit-llvm doesn't change the default name for the > -c output. > > The .o file should be llvm binary IR; if you want it > named .bc, use -o > > a.bc > > If you're starting out, probably -S -emit-llvm is > more useful, you can > > read that format. > > Ok, I understand so far. > > I have a partially working example now. > > llvm-g++ a.cpp -c -emit-llvm > llvm-g++ b.cpp -c -emit-llvm > llvm-link a.o b.o -o program.bc > llc -march=c program.bc -o program.c > gcc program.c > > program.c will contain some non-human generated code. But > it doesn't > compile with gcc. There is an error, gcc complaints about > undefined > reference to std::cout and such (the code was just a very > small example > with cout). > > It hasn't be converted into "C only" code, > can you tell me why? > > Regards, > -mr > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From eli.friedman at gmail.com Wed Sep 17 18:10:53 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 17 Sep 2008 16:10:53 -0700 Subject: [LLVMdev] bc file only with llvm-gcc3? In-Reply-To: <48D1871E.8050802@freenet.de> References: <48D16930.5040401@freenet.de> <48D1786E.5040409@freenet.de> <48D1871E.8050802@freenet.de> Message-ID: On Wed, Sep 17, 2008 at 3:39 PM, Michael Reichenbach wrote: > program.c will contain some non-human generated code. But it doesn't > compile with gcc. There is an error, gcc complaints about undefined > reference to std::cout and such (the code was just a very small example > with cout). > > It hasn't be converted into "C only" code, can you tell me why? If your code uses the C++ library, you'll need to link it against a C++ library. That has nothing to do with the language of the code. -Eli From luismarques at gmail.com Wed Sep 17 18:14:06 2008 From: luismarques at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Marques?=) Date: Thu, 18 Sep 2008 00:14:06 +0100 Subject: [LLVMdev] link bytecode files into a native executable with debug info Message-ID: <408520e0809171614g7c89db19scd45bc401feb3c8f@mail.gmail.com> Hello, If you have one or more bytecode files with debug info, how do you generate a native executable still with debug info? I tried, for instance, this: llvm-ld -native -disable-opt -o exec file1.bc file2.bc but it doesn't seem to work. Thanks, Lu?s From gohman at apple.com Wed Sep 17 18:48:01 2008 From: gohman at apple.com (Dan Gohman) Date: Wed, 17 Sep 2008 16:48:01 -0700 Subject: [LLVMdev] Overzealous PromoteCastOfAllocation In-Reply-To: <20080913200716.GF9093@katherina.student.utwente.nl> References: <20080908155737.GJ32157@katherina.student.utwente.nl> <643C9D81-4750-48E5-B26C-C7699B04065B@apple.com> <20080913200716.GF9093@katherina.student.utwente.nl> Message-ID: <3F55EB60-20C6-4379-BDD2-DCE178E909BA@apple.com> On Sep 13, 2008, at 1:07 PM, Matthijs Kooijman wrote: > >> Finding the maximum alignment is sometimes still useful though, so >> it would be nice to update the alignment field of the alloca even if >> its type is left unchanged. > The maximizing of the alignment is done only looking at the type's ABI > alignment, the actual alignment of the alloca instruction is not used. > > But what you suggest is that if the alloca is casted to some type > that has > higher alignment, you want that higher allignment propagated to the > alloca > instruction? I can see why this is useful, since bitcasting to a > type with > higher alignment can actually produce invalid code, I think? Or how > does this > work exactly? I haven't studied the code you're talking about in detail. I was just observing that the compiler allocates the storage for alloca, so it can use whatever alignment it wants, so it makes sense to use the greatest value that any of the users would want. Dan From tonic at nondot.org Wed Sep 17 19:33:49 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Wed, 17 Sep 2008 17:33:49 -0700 (PDT) Subject: [LLVMdev] 2.4 Code Freeze Reminder - Oct. 6th Message-ID: LLVM Developers, The 2.4 code freeze is October 6th (9PM PDT). Please plan to check in any major changes at least one week before this deadline. The full release schedule is on the LLVM website. If you have any questions, please let me know. Thanks! -Tanya From wangmp at apple.com Wed Sep 17 19:02:35 2008 From: wangmp at apple.com (Mon Ping Wang) Date: Wed, 17 Sep 2008 17:02:35 -0700 Subject: [LLVMdev] llvm memory barrier as a builtin In-Reply-To: <48D1650F.10903@cs.rochester.edu> References: <85dfcd7f0809170550o1ae52af2n7acd9e299eb5cd00@mail.gmail.com> <48D1650F.10903@cs.rochester.edu> Message-ID: <4A86D38F-64F5-4FFE-B3BE-8EB1C9623D40@apple.com> Hi Luke, What you say makes sense but I'm not sure it is a good way to go. If we are using a gcc function name __sync_synchronize, I generally feel like we should support it with exactly the same signature and not try to extend it. Otherwise, it might lead to some confusion in the future unless they also plan to extend it the same way. -- Mon Ping On Sep 17, 2008, at 1:14 PM, Luke Dalessandro wrote: > Mon Ping Wang wrote: >> Thanks for the info. My impression is that __sync_synchronize takes >> no arguments and is the memory barrier, i.e., >> "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is >> that right? > > That's my understanding as well. > >> I would like a little finer control to express just a >> write barrier (st-st) or a read barrier. > > My understanding is that the only types of finer grained control in > gcc > are the __sync_lock_test_and_set and __sync_lock_release which > appear to > implement acquire/release style barriers. > > http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins > > I expect that there will be large changes once the memory model for > C++0X is released, and there may be things implemented in gcc branches > or even undocumented in the mainline that give you the kind of control > you want. > > It might make sense to allow __sync_synchronize to be overloaded in > the > same way that LLVM's builtin is for use in clang, with the default > version being the full memory barrier. > > Luke > >> >> -- Mon Ping >> >> >> On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: >> >>> On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang >>> wrote: >>>> I would like access to LLVM memory barrier instruction as a built- >>>> in >>>> from clang, which means that I need a name for it. In gcc, I see >>>> names >>>> like __builtin_ia32_mfence but those refers to X86 SSE instruction >>>> that we support. I don't see a gcc name that has the same >>>> semantics >>>> as our barrier instruction. For a name, I was thinking of >>>> __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does >>>> anyone object of adding it as built-in or have a better idea for a >>>> name? >>> __sync_synchronize is the gcc builtin for a memory barrier. >>> >>> Andrew >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From luked at cs.rochester.edu Wed Sep 17 20:02:30 2008 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Wed, 17 Sep 2008 21:02:30 -0400 Subject: [LLVMdev] llvm memory barrier as a builtin In-Reply-To: <4A86D38F-64F5-4FFE-B3BE-8EB1C9623D40@apple.com> References: <85dfcd7f0809170550o1ae52af2n7acd9e299eb5cd00@mail.gmail.com> <48D1650F.10903@cs.rochester.edu> <4A86D38F-64F5-4FFE-B3BE-8EB1C9623D40@apple.com> Message-ID: <48D1A8A6.2000205@cs.rochester.edu> Mon Ping Wang wrote: > Hi Luke, > > What you say makes sense but I'm not sure it is a good way to go. If > we are using a gcc function name __sync_synchronize, I generally feel > like we should support it with exactly the same signature and not try > to extend it. Otherwise, it might lead to some confusion in the future > unless they also plan to extend it the same way. Nono, I definitely agree. I was just offering it as an option. I highly doubt that they intend to make any changes along these lines. My (very uneducated) expression is that they are more inclined to simply implement the upcoming memory model directly, rather than offering very fine grained barriers to user level code. The back end will clearly have to spit out whatever asm barriers are required in order to convince the particular hardware to play along. Luke > > -- Mon Ping > > > On Sep 17, 2008, at 1:14 PM, Luke Dalessandro wrote: > >> Mon Ping Wang wrote: >>> Thanks for the info. My impression is that __sync_synchronize takes >>> no arguments and is the memory barrier, i.e., >>> "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is >>> that right? >> That's my understanding as well. >> >>> I would like a little finer control to express just a >>> write barrier (st-st) or a read barrier. >> My understanding is that the only types of finer grained control in >> gcc >> are the __sync_lock_test_and_set and __sync_lock_release which >> appear to >> implement acquire/release style barriers. >> >> http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins >> >> I expect that there will be large changes once the memory model for >> C++0X is released, and there may be things implemented in gcc branches >> or even undocumented in the mainline that give you the kind of control >> you want. >> >> It might make sense to allow __sync_synchronize to be overloaded in >> the >> same way that LLVM's builtin is for use in clang, with the default >> version being the full memory barrier. >> >> Luke >> >>> -- Mon Ping >>> >>> >>> On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: >>> >>>> On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang >>>> wrote: >>>>> I would like access to LLVM memory barrier instruction as a built- >>>>> in >>>>> from clang, which means that I need a name for it. In gcc, I see >>>>> names >>>>> like __builtin_ia32_mfence but those refers to X86 SSE instruction >>>>> that we support. I don't see a gcc name that has the same >>>>> semantics >>>>> as our barrier instruction. For a name, I was thinking of >>>>> __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does >>>>> anyone object of adding it as built-in or have a better idea for a >>>>> name? >>>> __sync_synchronize is the gcc builtin for a memory barrier. >>>> >>>> Andrew >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From michael_reichenbach at freenet.de Thu Sep 18 04:35:32 2008 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Thu, 18 Sep 2008 11:35:32 +0200 Subject: [LLVMdev] bc file only with llvm-gcc3? In-Reply-To: <724222.31273.qm@web62004.mail.re1.yahoo.com> References: <724222.31273.qm@web62004.mail.re1.yahoo.com> Message-ID: <48D220E4.60605@freenet.de> Nope, I planed to convert into C code, compilable with a C compiler. -mr Samuel Crow schrieb: > Hello Michael, > > If you're just trying to run the code you can skip the llc and gcc states and go directly to lli. PowerPC and Intel x86 are the only architectures supported by the jit compiler right now but it should work fine from Windows. The C output backend needs some work since C isn't a low-level language enough to compile the abstractions of LLVM Assembly code. > > --Sam Crow > > --- On Wed, 9/17/08, Michael Reichenbach wrote: > >> From: Michael Reichenbach >> Subject: Re: [LLVMdev] bc file only with llvm-gcc3? >> To: "LLVM Developers Mailing List" >> Date: Wednesday, September 17, 2008, 5:39 PM >> Dale Johannesen schrieb: >>> On Sep 17, 2008, at 2:36 PMPDT, Michael Reichenbach >> wrote: >>>> No matter if I try " >>>> llvm-g++ a.cpp -c -emit-llvm >>>> " with "LLVM-GCC 4.2 Front End Binaries >> for Mingw32/x86" on Windows XP >>>> or if I am trying it on Ubuntu... >>>> >>>> Only the a.o file will be created without any >> error messages. The .bc >>>> file will not be created, do you know why? >>> -emit-llvm doesn't change the default name for the >> -c output. >>> The .o file should be llvm binary IR; if you want it >> named .bc, use -o >>> a.bc >>> If you're starting out, probably -S -emit-llvm is >> more useful, you can >>> read that format. >> Ok, I understand so far. >> >> I have a partially working example now. >> >> llvm-g++ a.cpp -c -emit-llvm >> llvm-g++ b.cpp -c -emit-llvm >> llvm-link a.o b.o -o program.bc >> llc -march=c program.bc -o program.c >> gcc program.c >> >> program.c will contain some non-human generated code. But >> it doesn't >> compile with gcc. There is an error, gcc complaints about >> undefined >> reference to std::cout and such (the code was just a very >> small example >> with cout). >> >> It hasn't be converted into "C only" code, >> can you tell me why? >> >> Regards, >> -mr From michael_reichenbach at freenet.de Thu Sep 18 04:38:58 2008 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Thu, 18 Sep 2008 11:38:58 +0200 Subject: [LLVMdev] bc file only with llvm-gcc3? In-Reply-To: References: <48D16930.5040401@freenet.de> <48D1786E.5040409@freenet.de> <48D1871E.8050802@freenet.de> Message-ID: <48D221B2.6050401@freenet.de> Eli Friedman schrieb: > On Wed, Sep 17, 2008 at 3:39 PM, Michael Reichenbach > wrote: >> program.c will contain some non-human generated code. But it doesn't >> compile with gcc. There is an error, gcc complaints about undefined >> reference to std::cout and such (the code was just a very small example >> with cout). >> >> It hasn't be converted into "C only" code, can you tell me why? > > If your code uses the C++ library, you'll need to link it against a > C++ library. That has nothing to do with the language of the code. > > -Eli I was only using the C++ standard lib. It doesn't need to be linked because it's only a header. Better said, it can't be linked with the std lib, never heard that it's needed to link it. Btw the code compiles and runs for sure with a g++ and also with llvm-g++. Only the converted C output contains still references to C++. How can I remove them? -mr From chrsayer at dibcom.fr Thu Sep 18 05:15:26 2008 From: chrsayer at dibcom.fr (SAYER Christian) Date: Thu, 18 Sep 2008 12:15:26 +0200 (CEST) Subject: [LLVMdev] Beginner needs some glue between Kaleidoscope and other docs Message-ID: <6200759.61221732926889.OPEN-XCHANGE.WebMail.tomcat@dibcom9> Hi Folks, I am just starting to get familiar with the llvm framework, thank you at first for this nice tool which seems really powerful! I have studied so far the Kaleidoscope example and other docs at llvm.org and try to figure out which would be the "right" way (well I suppose there are many) to integrate the framework into my compiler project, but there is still quite a gap between the tutorial and the multitude of things that can be found in the docs... What I want to do: The source language could be considered as a basic subset of C, with some custom "instructions", and without expressions, only statements. I write instructions here because most of the statements map quite directly to the hardware. I would like llvm to do some optimizations like constant propagation, loop optimization etc. , and register allocation on the standard arithmetic/logic subset of instructions. Finally, it should emit a (specified, non standard) assembler code. What I think I'll have to do: -straight forward parse and pass to llvm IR. Actually I don't even see the need of an AST since there aren't any expressions to resolve. Additionally, the source typically generated code. At this point I think I'll have to extend the IRBuilder to support the custom instructions. -run standard optimization passes on the IR code. Add custom optimization passes to support custom instruction optimization. -add information and/or code about the target hardware (registers, ...) to llvm to make it able to allocate registers. add a backend to llvm to support my instruction set and assembler syntax. (i.e. write a lib/Target/MyProc) Please, could you comment on this approach? Given the fact that my source and target are way less complex than e.g. C/x86, llvm should have enough (if not too many : ) facilities to achieve this. Thank you, Christian From asl at math.spbu.ru Thu Sep 18 07:54:22 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 18 Sep 2008 16:54:22 +0400 Subject: [LLVMdev] bc file only with llvm-gcc3? In-Reply-To: <48D221B2.6050401@freenet.de> References: <48D16930.5040401@freenet.de> <48D1786E.5040409@freenet.de> <48D1871E.8050802@freenet.de> <48D221B2.6050401@freenet.de> Message-ID: <1221742462.6509.8.camel@aslstation.lan> > I was only using the C++ standard lib. It doesn't need to be linked > because it's only a header. Better said, it can't be linked with the std > lib, never heard that it's needed to link it. Your program does need to have libstdc++ to linked it. > Btw the code compiles and runs for sure with a g++ and also with llvm-g++. Right, because they provide all needed extra magic libraries to linker. This will surely fail for you: g++ foo.cpp -o foo.o gcc foo.o > Only the converted C output contains still references to C++. How can I > remove them? You cannot, since you're compiling C++ sources and using C++ standard library. You've mentioned this explicitly before: > There is an error, gcc complaints about undefined > reference to std::cout and such (the code was just a very small > example with cout). Once again: you have C source code but with calls to C++ standard library (just as normal C calls). Thus you need to link libstdc++ in! -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From Sachin.Punyani at microchip.com Thu Sep 18 09:12:15 2008 From: Sachin.Punyani at microchip.com (Sachin.Punyani at microchip.com) Date: Thu, 18 Sep 2008 07:12:15 -0700 Subject: [LLVMdev] Illegal pointer type Message-ID: Hi, What changes would be required in LLVM to support illegal pointer type? Regards Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080918/36e53cde/attachment.html From Micah.Villmow at amd.com Thu Sep 18 10:42:04 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Thu, 18 Sep 2008 08:42:04 -0700 Subject: [LLVMdev] store addrspace qualifier In-Reply-To: <63BED151-B7C7-4B30-9399-5A587140F143@apple.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C085B2F@ssanexmb1.amd.com> <63BED151-B7C7-4B30-9399-5A587140F143@apple.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C085C67@ssanexmb1.amd.com> Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the getBasePtr().Val of the StoreSDNode to a SrcValueSDNode it asserts on: Assertion failed: isa(Val) && "cast() argument of incompatible type!" This is what I'm attempting: SDValue LangTargetLowering::LowerSTORE(SDValue Op, SelectionDAG& DAG){ const StoreSDNode* storeOp = dyn_cast(Op.Val); const SDValue& dstPtr = storeOp->getBasePtr(); const SrcValueSDNode* svdstVal = cast(dstPtr.Val); const Value* dstVal = svdstVal->getValue(); int addressSpace = ADDRESS_NONE; const Type* dstType = dstVal->getType(); if (isa(dstType)) { const PointerType* ptrType = cast(dstType); addressSpace = ptrType->getAddressSpace(); } printf("Addr: %d\n", addressSpace); SDValue Res; .... return Res; } Any idea what I'm doing wrong or how I can get this to work correctly? Thanks, Micah ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Mon Ping Wang Sent: Wednesday, September 17, 2008 3:45 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] store addrspace qualifier The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: How do I access the address qualifier from the store instruction. Given the following code: define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) nounwind { entry: %neg = sub float -0.000000e+000, %x ; [#uses=1] store float %neg, float addrspace(11)* %result ret void } When I attempt to generate this code, I'm aborting on. Cannot yet select: 017E8230: ch = store 017E7DF0, 017E8098, 017E8010, 017E81A8 <0035A078:0> alignment=4 So I am doing a custom Store function. In my LowerStore function, I get an SDValue w/ opcode of 119(store) and 4 child Operands Operand 0 is the entry token which I assume I can ignore Operand 1 is the source data(%neg), which I finally can handle correctly thanks to Eli Operand 2 is the dst location with two children, an EntryToken and Register(%result I'm guessing) Operand 3 is undef So, how do I find out the address space? The reason being different address spaces are accessed with different registers. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 _______________________________________________ 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/20080918/34a92294/attachment-0001.html From chrsayer at dibcom.fr Thu Sep 18 10:44:19 2008 From: chrsayer at dibcom.fr (SAYER Christian) Date: Thu, 18 Sep 2008 17:44:19 +0200 (CEST) Subject: [LLVMdev] Scope and symbol table Message-ID: <2829043.71221752659190.OPEN-XCHANGE.WebMail.tomcat@dibcom9> Hi, the llvm programmer's manual states in the symbol table paragraph: >The ValueSymbolTable class provides a symbol table that the >Function and Module classes use for naming value definitions and >call setName on a value, which will autoinsert it into the appropriate >symbol table So I conclude the following: -for Values, this intrinsic symbol table provides a function scope and any other scope may be achieved e.g. by some kind of "name mangling" -for Functions, it provides a Module scope, which may be extended by linking Modules. Is this correct? Regards, Christian From criswell at cs.uiuc.edu Thu Sep 18 10:45:46 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Thu, 18 Sep 2008 10:45:46 -0500 Subject: [LLVMdev] Web Server Restart Message-ID: <48D277AA.8080504@cs.uiuc.edu> Dear All, The web server on llvm.org seems to have started going really slowly. I'm going to restart it in 5 minutes (10:50 am CDT) to see if that fixes the problem. -- John T. From criswell at cs.uiuc.edu Thu Sep 18 10:52:00 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Thu, 18 Sep 2008 10:52:00 -0500 Subject: [LLVMdev] Web Server Restart In-Reply-To: <48D277AA.8080504@cs.uiuc.edu> References: <48D277AA.8080504@cs.uiuc.edu> Message-ID: <48D27920.3030905@cs.uiuc.edu> Dear LLVMers, The web server restart seems to have worked and fixed the problem. If you notice anything that isn't working, please email llvmdev. -- John T. John Criswell wrote: > Dear All, > > The web server on llvm.org seems to have started going really slowly. > I'm going to restart it in 5 minutes (10:50 am CDT) to see if that fixes > the problem. > > -- John T. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From criswell at cs.uiuc.edu Thu Sep 18 11:08:47 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Thu, 18 Sep 2008 11:08:47 -0500 Subject: [LLVMdev] Web Server Problems Persist Message-ID: <48D27D0F.6070804@cs.uiuc.edu> Dear All, Our web server problems are persisting. I may need to restart the web server while diagnosing the problem. I'll send email once I'm done. -- John T. From criswell at cs.uiuc.edu Thu Sep 18 11:15:54 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Thu, 18 Sep 2008 11:15:54 -0500 Subject: [LLVMdev] Web Server Problems Persist In-Reply-To: <48D27D0F.6070804@cs.uiuc.edu> References: <48D27D0F.6070804@cs.uiuc.edu> Message-ID: <48D27EBA.2000107@cs.uiuc.edu> John Criswell wrote: > Dear All, > > Our web server problems are persisting. I may need to restart the web > server while diagnosing the problem. I'll send email once I'm done. > Okay. I think it's working now. The web server was getting a lot of traffic that was maxing out the maximum number of Apache processes, but the traffic seems to have ceased, and a restart of the web server has things going again. If you run into problems, please email llvmdev. I'll periodically check llvm.org to make sure it's still up. -- John T. > -- John T. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From tonic at nondot.org Thu Sep 18 12:10:23 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Thu, 18 Sep 2008 10:10:23 -0700 (PDT) Subject: [LLVMdev] Doxygen Updated Message-ID: All, I've upgraded our doxygen to 1.5.6. Please let me know if you see any problems. Thanks, Tanya From gessel at apple.com Thu Sep 18 12:14:48 2008 From: gessel at apple.com (Daniel M Gessel) Date: Thu, 18 Sep 2008 13:14:48 -0400 Subject: [LLVMdev] store addrspace qualifier In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C085C67@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C085B2F@ssanexmb1.amd.com> <63BED151-B7C7-4B30-9399-5A587140F143@apple.com> <5BA674C5FF7B384A92C2C95D8CC71E1C085C67@ssanexmb1.amd.com> Message-ID: Micah, I'm working on more or less the same problem. I'm exploring the following: const Type* dstType = storeOp->getSrcValue()->getType(); New to this myself, but I think getSrcValue() (in MemSDNode, a base for StoreSDNode) returns a Value object which refers back to the original IR, where there's more detailed type info. I see cases where the MemSDNode will get a NULL SrcValue (I see it in getStore/getLoad calls in LegalizeDAG.cpp), but these all seem to be referring to the stack. So, I'm thinking: const Value* v = storeOp->getSrcValue(); if( !v ) { addressSpace = stackAddressSpace; } else { const Type* dstType = storeOp->getSrcValue()->getType(); ... } Dan On Sep 18, 2008, at 11:42 AM, Villmow, Micah wrote: > Mon Ping, > Thanks for the tip, but I can?t for the life of me seem to get the > Value from a StoreSDNode. From looking at the SelectionDAGNodes > header file, the only class that has the getValue function call is > SrcValueSDNode that returns a Value type. The only class that has > getType is a ConstantPoolSDNode. I don?t think that > ConstantPoolSDNode is what I want and when I try to cast the > getBasePtr().Val of the StoreSDNode to a SrcValueSDNode it asserts on: > Assertion failed: isa(Val) && "cast() argument of > incompatible type!" > > This is what I?m attempting: > SDValue LangTargetLowering::LowerSTORE(SDValue Op, SelectionDAG& DAG){ > const StoreSDNode* storeOp = dyn_cast(Op.Val); > const SDValue& dstPtr = storeOp->getBasePtr(); > const SrcValueSDNode* svdstVal = cast(dstPtr.Val); > const Value* dstVal = svdstVal->getValue(); > int addressSpace = ADDRESS_NONE; > const Type* dstType = dstVal->getType(); > if (isa(dstType)) { > const PointerType* ptrType = cast(dstType); > addressSpace = ptrType->getAddressSpace(); > } > printf("Addr: %d\n", addressSpace); > SDValue Res; > ?. > return Res; > } > > Any idea what I?m doing wrong or how I can get this to work correctly? > > Thanks, > Micah > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of Mon Ping Wang > Sent: Wednesday, September 17, 2008 3:45 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] store addrspace qualifier > > > The address qualifier is stored in the type of %result. From that > operand, you can get the Value and then call getType. The type for > result should be a PointerType which you cast to a PointerType and > get the getAddressSpace e.g. cast(Ty)->getAddressSpace() > > -- Mon Ping > > > On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > > > How do I access the address qualifier from the store instruction. > Given the following code: > > define void @test_unary_op_anegate(float %x, float addrspace(11)* > %result) nounwind { > entry: > %neg = sub float -0.000000e+000, %x ; > [#uses=1] > store float %neg, float addrspace(11)* %result > ret void > } > When I attempt to generate this code, I?m aborting on. > Cannot yet select: 017E8230: ch = store 017E7DF0, 017E8098, > 017E8010, 017E81A8 <0035A078:0> alignment=4 > So I am doing a custom Store function. > In my LowerStore function, I get an SDValue w/ opcode of 119(store) > and 4 child Operands > Operand 0 is the entry token which I assume I can ignore > Operand 1 is the source data(%neg), which I finally can handle > correctly thanks to Eli > Operand 2 is the dst location with two children, an EntryToken and > Register(%result I?m guessing) > Operand 3 is undef > > So, how do I find out the address space? The reason being different > address spaces are accessed with different registers. > > Thanks, > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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 monping at apple.com Thu Sep 18 12:18:12 2008 From: monping at apple.com (Mon Ping Wang) Date: Thu, 18 Sep 2008 10:18:12 -0700 Subject: [LLVMdev] store addrspace qualifier In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C085C67@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C085B2F@ssanexmb1.amd.com> <63BED151-B7C7-4B30-9399-5A587140F143@apple.com> <5BA674C5FF7B384A92C2C95D8CC71E1C085C67@ssanexmb1.amd.com> Message-ID: Hi Micah, I forgot that you are at a StoreSDNode. You can get the value directly from that node. Try something like storeOp->getSrcValue()->getType() That should give you the type of the memory location. -- Mon Ping On Sep 18, 2008, at 8:42 AM, Villmow, Micah wrote: > Mon Ping, > Thanks for the tip, but I can?t for the life of me seem to get the > Value from a StoreSDNode. From looking at the SelectionDAGNodes > header file, the only class that has the getValue function call is > SrcValueSDNode that returns a Value type. The only class that has > getType is a ConstantPoolSDNode. I don?t think that > ConstantPoolSDNode is what I want and when I try to cast the > getBasePtr().Val of the StoreSDNode to a SrcValueSDNode it asserts on: > Assertion failed: isa(Val) && "cast() argument of > incompatible type!" > > This is what I?m attempting: > SDValue LangTargetLowering::LowerSTORE(SDValue Op, SelectionDAG& DAG){ > const StoreSDNode* storeOp = dyn_cast(Op.Val); > const SDValue& dstPtr = storeOp->getBasePtr(); > const SrcValueSDNode* svdstVal = cast(dstPtr.Val); > const Value* dstVal = svdstVal->getValue(); > int addressSpace = ADDRESS_NONE; > const Type* dstType = dstVal->getType(); > if (isa(dstType)) { > const PointerType* ptrType = cast(dstType); > addressSpace = ptrType->getAddressSpace(); > } > printf("Addr: %d\n", addressSpace); > SDValue Res; > ?. > return Res; > } > > Any idea what I?m doing wrong or how I can get this to work correctly? > > Thanks, > Micah > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of Mon Ping Wang > Sent: Wednesday, September 17, 2008 3:45 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] store addrspace qualifier > > > The address qualifier is stored in the type of %result. From that > operand, you can get the Value and then call getType. The type for > result should be a PointerType which you cast to a PointerType and > get the getAddressSpace e.g. cast(Ty)->getAddressSpace() > > -- Mon Ping > > > On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > > > How do I access the address qualifier from the store instruction. > Given the following code: > > define void @test_unary_op_anegate(float %x, float addrspace(11)* > %result) nounwind { > entry: > %neg = sub float -0.000000e+000, %x ; > [#uses=1] > store float %neg, float addrspace(11)* %result > ret void > } > When I attempt to generate this code, I?m aborting on. > Cannot yet select: 017E8230: ch = store 017E7DF0, 017E8098, > 017E8010, 017E81A8 <0035A078:0> alignment=4 > So I am doing a custom Store function. > In my LowerStore function, I get an SDValue w/ opcode of 119(store) > and 4 child Operands > Operand 0 is the entry token which I assume I can ignore > Operand 1 is the source data(%neg), which I finally can handle > correctly thanks to Eli > Operand 2 is the dst location with two children, an EntryToken and > Register(%result I?m guessing) > Operand 3 is undef > > So, how do I find out the address space? The reason being different > address spaces are accessed with different registers. > > Thanks, > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080918/3dc0b0ed/attachment-0001.html From evan.cheng at apple.com Thu Sep 18 13:14:50 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 18 Sep 2008 11:14:50 -0700 Subject: [LLVMdev] Status of LLVM ARM port In-Reply-To: References: Message-ID: On Sep 17, 2008, at 3:00 PM, Tyler Wilson wrote: > Good day, > > I have looked around for this information, but I have not been able > to gain a clear understanding: what is the status of the LLVM ARM > backend? That is, do the following work: > > 1. Generating Thumb code: I saw a video online where they > describe an issue with using the ARM Thumb back-end Thumb works. But it generate poor code. > 2. Generating code for ARM9 (ARMv5?) or ARM7 (ARMv4): again, > the same presentation mentioned that it only generated ARMv6 or 7. > Does the back end work on older ARM processors today? ARM v6 is known to work well. I am not sure about v4 and v5. They should mostly work, but I don't test them. There is no support for v7. > > I have seen the notes on the Apple provided bits to the project, but > those were form early-mid 2007, and I have not seen a clear > declaration on what is marked as working or not. There hasn't been a lot of activities in ARM target. Patches welcome! Evan > > Thank you, > Tyler > _______________________________________________ > 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/20080918/7889591d/attachment.html From michael_reichenbach at freenet.de Thu Sep 18 14:22:09 2008 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Thu, 18 Sep 2008 21:22:09 +0200 Subject: [LLVMdev] converting C++ to C question In-Reply-To: <1221742462.6509.8.camel@aslstation.lan> References: <48D16930.5040401@freenet.de> <48D1786E.5040409@freenet.de> <48D1871E.8050802@freenet.de> <48D221B2.6050401@freenet.de> <1221742462.6509.8.camel@aslstation.lan> Message-ID: <48D2AA61.8090602@freenet.de> Please bare with me. :) Just to ensure I got nothing wrong. I can write in C++ + use C++ std lib + use other C++ libs and see if it compiles with a C++ compiler. After it's working I use llvm to do some magic and I get C code that I can compile with a standard C compiler on any platform? That's what I planed to do. Regards, -mr From luked at cs.rochester.edu Thu Sep 18 14:31:10 2008 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Thu, 18 Sep 2008 15:31:10 -0400 Subject: [LLVMdev] converting C++ to C question In-Reply-To: <48D2AA61.8090602@freenet.de> References: <48D16930.5040401@freenet.de> <48D1786E.5040409@freenet.de> <48D1871E.8050802@freenet.de> <48D221B2.6050401@freenet.de> <1221742462.6509.8.camel@aslstation.lan> <48D2AA61.8090602@freenet.de> Message-ID: <48D2AC7E.5070606@cs.rochester.edu> Michael Reichenbach wrote: > Please bare with me. :) Just to ensure I got nothing wrong. > > I can write in C++ + use C++ std lib + use other C++ libs and see if it > compiles with a C++ compiler. > > After it's working I use llvm to do some magic and I get C code that I > can compile with a standard C compiler on any platform? That's what I > planed to do. It's not the compiler that's causing the problem. All of the C++-isms are getting converted into C, which you can then compile with a C compiler. This includes things like new/delete, operator overloading, etc. The problem is that you are using code found in the standard C++ library which the linker can't find at link time. When you use the g++ driver to do linking, it knows about the standard library and "does the right thing" during linking. If you use the system linker you need to tell it where to find the standard C++ library. You do this in LLVM by passing -lstdc++ to llvm-ld during linking. So the answer to your question is "yes" you can generate C code that will compile on any platform, but in order to link it correctly you need to link in the C++ library on that platform. Hope this helps. Luke > > Regards, > -mr > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From asl at math.spbu.ru Thu Sep 18 15:27:44 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 19 Sep 2008 00:27:44 +0400 Subject: [LLVMdev] converting C++ to C question In-Reply-To: <48D2AA61.8090602@freenet.de> References: <48D16930.5040401@freenet.de> <48D1786E.5040409@freenet.de> <48D1871E.8050802@freenet.de> <48D221B2.6050401@freenet.de> <1221742462.6509.8.camel@aslstation.lan> <48D2AA61.8090602@freenet.de> Message-ID: <1221769664.6509.20.camel@aslstation.lan> Hello, Michael > After it's working I use llvm to do some magic and I get C code that I > can compile with a standard C compiler on any platform? That's what I > planed to do. Luke already answered one part of your question. Another part is that you cannot run resulting C code on *any* platform: inside bytecode you will have all sort of frontend-related stuff encoded implicitely: sizes of integers, endian-related things, struct layout, etc. LLVM IR obtained from C/C++ is not portable. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From Micah.Villmow at amd.com Thu Sep 18 18:04:05 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Thu, 18 Sep 2008 16:04:05 -0700 Subject: [LLVMdev] Custom Opcodes versus built-in opcodes Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9E71@ssanexmb1.amd.com> I am using lowering instructions and using custom opcodes that I can more easily directly map to my backend. These opcodes are then used to emit a custom set of instructions into the MachineBasicBlock. I've been able to get one to work correctly, however, I've ran into an issue where my second one is being confused as a FRAMEADDR opcode instead of my opcode. DValue InstTargetLowering::LowerBR_CC(SDValue Op, SelectionDAG& DAG){ MVT VT = Op.getValueType(); SDValue Chain = Op.getOperand(0); SDValue LHS = Op.getOperand(2); SDValue RHS = Op.getOperand(3); SDValue Jump = Op.getOperand(4); bool logical_nz = getLogicalNZ(cmpOpcode); SDValue CmpValue; unsigned int brOpcode = CUSTOM::BRANCH_NZERO; CmpValue = DAG.getNode(CUSTOM::CMP, LHS.getValueType(), Chain, DAG.getConstant(cmpOpcode, MVT::i32), LHS, RHS); return DAG.getNode(brOpcode, VT, Chain, Jump, CmpValue); } What I want to happen is to take the branch w/ condition codes and convert it into a comparison and then a branch based on the result to the BasicBlock in the Jump SDValue. What I expect to occur after this function returns is for the SDValue that I created to be matched with my BRANCH_NZERO instruction in my InstrInfo.td file. Instead what is occurring is that it is mapping it for some reason to the FRAMEADDR built-in instruction and running LowerFRAMEADDR. Both instructions are enumerated to the same value, but they are part of different namespaces. Any idea on how I can resolve this issue? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080918/ea4e6fee/attachment-0001.html From isanbard at gmail.com Thu Sep 18 18:08:06 2008 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 18 Sep 2008 16:08:06 -0700 Subject: [LLVMdev] Illegal pointer type In-Reply-To: References: Message-ID: <16e5fdf90809181608m5ba8abd3u17c1119f6b4422d3@mail.gmail.com> On Thu, Sep 18, 2008 at 7:12 AM, wrote: > What changes would be required in LLVM to support illegal pointer type? > Hi Sachin, The question's a bit broad. And I don't think the answer you want is as simple as "don't run the legalizer" (which probably won't work). Do you have a more specific question? -bw From isanbard at gmail.com Thu Sep 18 18:16:27 2008 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 18 Sep 2008 16:16:27 -0700 Subject: [LLVMdev] Custom Opcodes versus built-in opcodes In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9E71@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9E71@ssanexmb1.amd.com> Message-ID: <16e5fdf90809181616m42655b9ehcde637aca62e920@mail.gmail.com> On Thu, Sep 18, 2008 at 4:04 PM, Villmow, Micah wrote: > I am using lowering instructions and using custom opcodes that I can more > easily directly map to my backend. These opcodes are then used to emit a > custom set of instructions into the MachineBasicBlock. I've been able to get > one to work correctly, however, I've ran into an issue where my second one > is being confused as a FRAMEADDR opcode instead of my opcode. > [snip] > > What I want to happen is to take the branch w/ condition codes and convert > it into a comparison and then a branch based on the result to the BasicBlock > in the Jump SDValue. What I expect to occur after this function returns is > for the SDValue that I created to be matched with my BRANCH_NZERO > instruction in my InstrInfo.td file. Instead what is occurring is that it is > mapping it for some reason to the FRAMEADDR built-in instruction and running > LowerFRAMEADDR. Both instructions are enumerated to the same value, but they > are part of different namespaces. > That's the problem. The "LowerFRAMEADDR" is called depending on the enumeration's value, not on the namespace it's in. I can think of two ways to solve this: a) Change the enumeration of your BRANCH_NZERO instructions, or 2) Add your BRANCH_NZERO to the same namespace as FRAMEADDR. -bw From clattner at apple.com Thu Sep 18 19:40:01 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 18 Sep 2008 17:40:01 -0700 Subject: [LLVMdev] xcodebuild and LLVM In-Reply-To: <3A72EC20-3F54-4FF2-A96A-52C97A6B20F3@apple.com> References: <48BF0BD0.2070609@cs.uiuc.edu> <48C6CAF1.2040100@cs.uiuc.edu> <2F2D1371-4B60-4BE9-A363-83A4F41BFDC1@apple.com> <3A72EC20-3F54-4FF2-A96A-52C97A6B20F3@apple.com> Message-ID: On Sep 14, 2008, at 11:42 AM, Devang Patel wrote: > > On Sep 11, 2008, at 9:30 PM, Ted Kremenek wrote: > >> Hi John, >> >> I'm not certain if libtool works with LLVM bitcode files, and I don't >> think that all of the tools that manipulate/inspect object files on >> Mac OS X understand bitcode files either. > > Yes. Right now only ld recognizes LLVM bitcode files. > > >> I suspect that this will >> change over time. > > Yes. In fact, Xcode 3.1.1 was recently released, and you can get it from here (with an ADC account): https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20214 Xcode 3.1.1 fixes a large number of LTO bugs and a bunch of additional tools in the toolchain now understand LLVM bc files. -Chris From elder at cs.wisc.edu Fri Sep 19 04:41:19 2008 From: elder at cs.wisc.edu (Matt Elder) Date: Fri, 19 Sep 2008 04:41:19 -0500 Subject: [LLVMdev] Using VirtRegMap Message-ID: <48D373BF.70201@cs.wisc.edu> I'm trying to piece together a few assignments for a graduate-level compilers class using LLVM; among these is a register allocator. I'd like to provide a register allocator that, given a partially-allocated VirtRegMap, will perform trivial register allocation (as in RegAllocSimple) on the remaining, unmapped virtual registers. To make a long story short, I want to map a single virtual register to various physical registers at different times, keeping the relevant value in memory all along. Can VirtRegMap do this cleanly, or should I avoid this abstraction and issue stores and loads manually, through TargetInstrInfo? Thanks, - Matt Elder From Sachin.Punyani at microchip.com Fri Sep 19 07:01:58 2008 From: Sachin.Punyani at microchip.com (Sachin.Punyani at microchip.com) Date: Fri, 19 Sep 2008 05:01:58 -0700 Subject: [LLVMdev] Illegal pointer type In-Reply-To: <16e5fdf90809181608m5ba8abd3u17c1119f6b4422d3@mail.gmail.com> References: <16e5fdf90809181608m5ba8abd3u17c1119f6b4422d3@mail.gmail.com> Message-ID: > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Bill Wendling > Sent: Friday, September 19, 2008 4:38 AM > > On Thu, Sep 18, 2008 at 7:12 AM, wrote: > > What changes would be required in LLVM to support illegal pointer type? > > > Hi Sachin, > > The question's a bit broad. And I don't think the answer you want is > as simple as "don't run the legalizer" (which probably won't work). Do > you have a more specific question? I am trying to ask a broad question. My target has 16 bit pointers but register size is 8 bit only. What changes in LLVM would be required to support 16 bit pointers on 8 bit registers? Regards Sachin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Fri Sep 19 11:37:20 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 19 Sep 2008 09:37:20 -0700 Subject: [LLVMdev] Using VirtRegMap In-Reply-To: <48D373BF.70201@cs.wisc.edu> References: <48D373BF.70201@cs.wisc.edu> Message-ID: <791D5FF8-3753-46D1-BB41-9A93F1511304@apple.com> On Sep 19, 2008, at 2:41 AM, Matt Elder wrote: > I'm trying to piece together a few assignments for a graduate-level > compilers class using LLVM; among these is a register allocator. I'd > like to provide a register allocator that, given a partially-allocated > VirtRegMap, will perform trivial register allocation (as in > RegAllocSimple) on the remaining, unmapped virtual registers. > > To make a long story short, I want to map a single virtual register to > various physical registers at different times, keeping the relevant > value in memory all along. Can VirtRegMap do this cleanly, or should I > avoid this abstraction and issue stores and loads manually, through > TargetInstrInfo? Please avoid using VirtRegMap. It's very tied to the current register allocation pieces and not easily reusable. One of my mission in life is to kill it. Evan > > > Thanks, > - Matt Elder > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From grosbach at apple.com Fri Sep 19 11:57:18 2008 From: grosbach at apple.com (Jim Grosbach) Date: Fri, 19 Sep 2008 09:57:18 -0700 Subject: [LLVMdev] Illegal pointer type In-Reply-To: References: <16e5fdf90809181608m5ba8abd3u17c1119f6b4422d3@mail.gmail.com> Message-ID: <886C2575-42F6-4A59-8521-9180B1455564@apple.com> > I am trying to ask a broad question. My target has 16 bit pointers but > register size is 8 bit only. What changes in LLVM would be required to > support 16 bit pointers on 8 bit registers? The target will need to to multi-byte arithmetic on non-pointer types as well. The size of the accumulator shouldn't need to be tied directly to the size of an integer or the size of a pointer in the back end. Are you asking about how to write a back-end for an 8-bit target in general? About whether changes would be required in the LLVM IR specification to support one? Something else entirely? From evan.cheng at apple.com Fri Sep 19 12:12:09 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 19 Sep 2008 10:12:09 -0700 Subject: [LLVMdev] Illegal pointer type In-Reply-To: References: <16e5fdf90809181608m5ba8abd3u17c1119f6b4422d3@mail.gmail.com> Message-ID: <496E0559-D0B3-4564-9FFC-E898F3458BAB@apple.com> I am assuming a 16-bit value will be stored in a pair of 8-bit registers? If so, add pseudo register which represent pairs of 8-bit registers. Add them to a pseudo register class. This allows you to mark i16 "legal". The difficult part is then to figure out how to lower these 16-bit operations into 8-bit ones. You probably need to custom lower a bunch of them with target specific code. Evan On Sep 19, 2008, at 5:01 AM, Sachin.Punyani at microchip.com wrote: > > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >> bounces at cs.uiuc.edu] > On >> Behalf Of Bill Wendling >> Sent: Friday, September 19, 2008 4:38 AM >> >> On Thu, Sep 18, 2008 at 7:12 AM, > wrote: >>> What changes would be required in LLVM to support illegal pointer > type? >>> >> Hi Sachin, >> >> The question's a bit broad. And I don't think the answer you want is >> as simple as "don't run the legalizer" (which probably won't work). >> Do >> you have a more specific question? > > I am trying to ask a broad question. My target has 16 bit pointers but > register size is 8 bit only. What changes in LLVM would be required to > support 16 bit pointers on 8 bit registers? > > Regards > Sachin > >> _______________________________________________ >> 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 Micah.Villmow at amd.com Fri Sep 19 12:33:29 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Fri, 19 Sep 2008 10:33:29 -0700 Subject: [LLVMdev] Custom Opcodes versus built-in opcodes In-Reply-To: <16e5fdf90809181616m42655b9ehcde637aca62e920@mail.gmail.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9E71@ssanexmb1.amd.com> <16e5fdf90809181616m42655b9ehcde637aca62e920@mail.gmail.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9F62@ssanexmb1.amd.com> -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bill Wendling Sent: Thursday, September 18, 2008 4:16 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Opcodes versus built-in opcodes On Thu, Sep 18, 2008 at 4:04 PM, Villmow, Micah wrote: > I am using lowering instructions and using custom opcodes that I can more > easily directly map to my backend. These opcodes are then used to emit a > custom set of instructions into the MachineBasicBlock. I've been able to get > one to work correctly, however, I've ran into an issue where my second one > is being confused as a FRAMEADDR opcode instead of my opcode. > [snip] > > What I want to happen is to take the branch w/ condition codes and convert > it into a comparison and then a branch based on the result to the BasicBlock > in the Jump SDValue. What I expect to occur after this function returns is > for the SDValue that I created to be matched with my BRANCH_NZERO > instruction in my InstrInfo.td file. Instead what is occurring is that it is > mapping it for some reason to the FRAMEADDR built-in instruction and running > LowerFRAMEADDR. Both instructions are enumerated to the same value, but they > are part of different namespaces. > That's the problem. The "LowerFRAMEADDR" is called depending on the enumeration's value, not on the namespace it's in. I can think of two ways to solve this: a) Change the enumeration of your BRANCH_NZERO instructions, or 2) Add your BRANCH_NZERO to the same namespace as FRAMEADDR. The problem with both of these solutions is that the opcodes are dynamically generated with tablegen and thus I cannot change the enumeration as I don't set the enumeration. Also changing the namespace doesn't change the enumeration. I think this can probably be classified as a bug in tablegen. It shouldn't be generating enumerated opcode values with the same values as built in opcodes. -bw _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From clattner at apple.com Fri Sep 19 12:49:04 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 19 Sep 2008 10:49:04 -0700 Subject: [LLVMdev] Custom Opcodes versus built-in opcodes In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9E71@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9E71@ssanexmb1.amd.com> Message-ID: <13E862FB-66D8-4F81-A896-B0EDCA321744@apple.com> On Sep 18, 2008, at 4:04 PM, Villmow, Micah wrote: > I am using lowering instructions and using custom opcodes that I can > more easily directly map to my backend. These opcodes are then used > to emit a custom set of instructions into the MachineBasicBlock. > I?ve been able to get one to work correctly, however, I?ve ran into > an issue where my second one is being confused as a FRAMEADDR opcode > instead of my opcode. Make sure to use DAG.getTargetNode() with custom opcodes. "target" nodes are encoded with an implicit delta added to their enum value. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080919/6530bb94/attachment.html From dag at cray.com Fri Sep 19 13:08:09 2008 From: dag at cray.com (David Greene) Date: Fri, 19 Sep 2008 13:08:09 -0500 Subject: [LLVMdev] mem2reg Question Message-ID: <200809191308.09376.dag@cray.com> I have a question about PromoteMem2Reg::RewriteSingleStoreAlloca. Specifically, this bit of code: // If the store dominates the block and if we haven't processed it yet, // do so now. We can't handle the case where the store doesn't dominate a // block because there may be a path between the store and the use, but we // may need to insert phi nodes to handle dominance properly. if (!StoringGlobalVal && !dominates(OnlyStore->getParent(), UseBlock)) continue; This prevents mem2reg from forwarding the single store to uses that it does not dominate. Why is this only prevented when NOT storing to global values? I would think it would be exactly the opposite. A global value may have some value coming into the Function so I don't see how mem2reg can forward store values that don't dominate uses. On the other hand, local values that have a use not dominated by the store means there's a potential use-before-def, the program is invalid, and the compiler is free to do whatever it wants (assuming this is what the language semantics say). The condition above looks exactly opposite of what we want. Thoughts? -Dave From dag at cray.com Fri Sep 19 13:15:17 2008 From: dag at cray.com (David Greene) Date: Fri, 19 Sep 2008 13:15:17 -0500 Subject: [LLVMdev] Using VirtRegMap In-Reply-To: <791D5FF8-3753-46D1-BB41-9A93F1511304@apple.com> References: <48D373BF.70201@cs.wisc.edu> <791D5FF8-3753-46D1-BB41-9A93F1511304@apple.com> Message-ID: <200809191315.17242.dag@cray.com> On Friday 19 September 2008 11:37, Evan Cheng wrote: > Please avoid using VirtRegMap. It's very tied to the current register > allocation pieces and not easily reusable. One of my mission in life > is to kill it. Im surprised to see this. I found it rather easy to re-use for custom register allocators. -Dave From Micah.Villmow at amd.com Fri Sep 19 13:35:15 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Fri, 19 Sep 2008 11:35:15 -0700 Subject: [LLVMdev] Custom Opcodes versus built-in opcodes In-Reply-To: <13E862FB-66D8-4F81-A896-B0EDCA321744@apple.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9E71@ssanexmb1.amd.com> <13E862FB-66D8-4F81-A896-B0EDCA321744@apple.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9F81@ssanexmb1.amd.com> ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Friday, September 19, 2008 10:49 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Opcodes versus built-in opcodes On Sep 18, 2008, at 4:04 PM, Villmow, Micah wrote: I am using lowering instructions and using custom opcodes that I can more easily directly map to my backend. These opcodes are then used to emit a custom set of instructions into the MachineBasicBlock. I've been able to get one to work correctly, however, I've ran into an issue where my second one is being confused as a FRAMEADDR opcode instead of my opcode. Make sure to use DAG.getTargetNode() with custom opcodes. "target" nodes are encoded with an implicit delta added to their enum value. Is this documented anywhere that getTargetNode is the preferred method to use in a Custom Lowering function? Even the other backends use getNode in their lowering functions with custom opcodes. This is from SparcISelLowering.cpp CompareFlag = DAG.getNode(SPISD::CMPFCC, MVT::Flag, LHS, RHS); if (SPCC == ~0U) SPCC = FPCondCCodeToFCC(CC); Opc = SPISD::BRFCC; } return DAG.getNode(Opc, MVT::Other, Chain, Dest, DAG.getConstant(SPCC, MVT::i32), CompareFlag); Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080919/f6487803/attachment-0001.html From clattner at apple.com Fri Sep 19 13:46:42 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 19 Sep 2008 11:46:42 -0700 Subject: [LLVMdev] Custom Opcodes versus built-in opcodes In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9F81@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9E71@ssanexmb1.amd.com> <13E862FB-66D8-4F81-A896-B0EDCA321744@apple.com> <5BA674C5FF7B384A92C2C95D8CC71E1C0B9F81@ssanexmb1.amd.com> Message-ID: <3C0EDD34-FE69-44F7-9759-B7AA3364D179@apple.com> On Sep 19, 2008, at 11:35 AM, Villmow, Micah wrote: > Make sure to use DAG.getTargetNode() with custom opcodes. "target" > nodes are encoded with an implicit delta added to their enum value. > > Is this documented anywhere that getTargetNode is the preferred > method to use in a Custom Lowering function? Even the other backends > use getNode in their lowering functions with custom opcodes. > This is from SparcISelLowering.cpp > CompareFlag = DAG.getNode(SPISD::CMPFCC, MVT::Flag, LHS, RHS); > if (SPCC == ~0U) SPCC = FPCondCCodeToFCC(CC); > Opc = SPISD::BRFCC; > } > return DAG.getNode(Opc, MVT::Other, Chain, Dest, > DAG.getConstant(SPCC, MVT::i32), CompareFlag); Actually, I'm wrong, sorry about that. It looks like the encoding is in the definition of the enum: enum { FIRST_NUMBER = ISD::BUILTIN_OP_END+SP::INSTRUCTION_LIST_END, CMPICC, // Compare two GPR operands, set icc. CMPFCC, // Compare two FP operands, set fcc. BRICC, // Branch to dest on icc condition BRFCC, // Branch to dest on fcc condition ... Are your "targetISD" enums properly defined with the offset? getTargetNode is required when passing in MachineInstr opcode numbers at isel time. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080919/d109daf6/attachment.html From Micah.Villmow at amd.com Fri Sep 19 14:13:21 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Fri, 19 Sep 2008 12:13:21 -0700 Subject: [LLVMdev] Custom Opcodes versus built-in opcodes In-Reply-To: <3C0EDD34-FE69-44F7-9759-B7AA3364D179@apple.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9E71@ssanexmb1.amd.com><13E862FB-66D8-4F81-A896-B0EDCA321744@apple.com><5BA674C5FF7B384A92C2C95D8CC71E1C0B9F81@ssanexmb1.amd.com> <3C0EDD34-FE69-44F7-9759-B7AA3364D179@apple.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0B9F94@ssanexmb1.amd.com> ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Friday, September 19, 2008 11:47 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Opcodes versus built-in opcodes On Sep 19, 2008, at 11:35 AM, Villmow, Micah wrote: Make sure to use DAG.getTargetNode() with custom opcodes. "target" nodes are encoded with an implicit delta added to their enum value. Is this documented anywhere that getTargetNode is the preferred method to use in a Custom Lowering function? Even the other backends use getNode in their lowering functions with custom opcodes. This is from SparcISelLowering.cpp CompareFlag = DAG.getNode(SPISD::CMPFCC, MVT::Flag, LHS, RHS); if (SPCC == ~0U) SPCC = FPCondCCodeToFCC(CC); Opc = SPISD::BRFCC; } return DAG.getNode(Opc, MVT::Other, Chain, Dest, DAG.getConstant(SPCC, MVT::i32), CompareFlag); Actually, I'm wrong, sorry about that. It looks like the encoding is in the definition of the enum: enum { FIRST_NUMBER = ISD::BUILTIN_OP_END+SP::INSTRUCTION_LIST_END, CMPICC, // Compare two GPR operands, set icc. CMPFCC, // Compare two FP operands, set fcc. BRICC, // Branch to dest on icc condition BRFCC, // Branch to dest on fcc condition ... Are your "targetISD" enums properly defined with the offset? getTargetNode is required when passing in MachineInstr opcode numbers at isel time. Ahhh! Thanks. Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080919/482d7a39/attachment.html From scott.llvm at h4ck3r.net Fri Sep 19 16:16:47 2008 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Fri, 19 Sep 2008 14:16:47 -0700 Subject: [LLVMdev] non-signed integer Type Message-ID: <84decce20809191416i4495f59sada3ac113925da48@mail.gmail.com> Hi Is there any rationale written down for why integer types don't carry (perhaps optional) signs somewhere? I feel like I might have read it somewhere before (and I see that it used to exist pre 2.0), but I can't find anything now. Relatedly, is there a reasonable way to attach user-data to a type or something? It feels very cumbersome to have to wrap all values and types in my front end. For example, I know I want to load a function argument, either sign-extend or zero-extend it, and then store it into a local. I have to mirror LLVM's object model for types, values, functions, etc. because I can't just get the parameter value from the function, ask it for it's type, and convert it in the correct way. thanks, scott From eli.friedman at gmail.com Fri Sep 19 17:07:10 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 19 Sep 2008 15:07:10 -0700 Subject: [LLVMdev] non-signed integer Type In-Reply-To: <84decce20809191416i4495f59sada3ac113925da48@mail.gmail.com> References: <84decce20809191416i4495f59sada3ac113925da48@mail.gmail.com> Message-ID: On Fri, Sep 19, 2008 at 2:16 PM, Scott Graham wrote: > Is there any rationale written down for why integer types don't carry > (perhaps optional) signs somewhere? http://nondot.org/sabre/LLVMNotes/TypeSystemChanges.txt > Relatedly, is there a reasonable way to attach user-data to a type or > something? It feels very cumbersome to have to wrap all values and > types in my front end. For example, I know I want to load a function > argument, either sign-extend or zero-extend it, and then store it into > a local. I have to mirror LLVM's object model for types, values, > functions, etc. because I can't just get the parameter value from the > function, ask it for it's type, and convert it in the correct way. http://llvm.org/docs/LangRef.html#int_general might be helpful? If you just need it while you're doing the translation, though, you could just keep around additional information for variables in your own data structures. -Eli From dag at cray.com Fri Sep 19 17:11:43 2008 From: dag at cray.com (David Greene) Date: Fri, 19 Sep 2008 17:11:43 -0500 Subject: [LLVMdev] PassManager Dependence Question Message-ID: <200809191711.43309.dag@cray.com> Let's say I have an analysis pass that's dependent on another analysis pass (getAnalysisUsage does the appropraite things). So Pass Y depends on Pass X. If some transformation pass depends on Pass Y and Pass Y has not been invalidated by another other pass BUT Pass X _has_ been invalidated by some other pass, what happens? I can imagine two likely paths in the current implementation of PassManager: 1. Pass Y is not re-run because it is considered up-to-date 2. Pass Y is re-run after Pass X because Pass X is out-of-date Which one of these happens? What I'd really like to do is have Pass X re-run but not Pass Y. Pass Y only uses some bookkeeping from Pass X to speed itself up. Having Pass X not re-run could cause Pass Y to give wrong answers, but once Pass X is up-to-date, Pass Y will be fine. Is this at all possible? -Dave From eli.friedman at gmail.com Fri Sep 19 17:17:56 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 19 Sep 2008 15:17:56 -0700 Subject: [LLVMdev] mem2reg Question In-Reply-To: <200809191308.09376.dag@cray.com> References: <200809191308.09376.dag@cray.com> Message-ID: On Fri, Sep 19, 2008 at 11:08 AM, David Greene wrote: > \Why is this only prevented when NOT storing > to global values? It's not a question of storing *to* a global value, but storing a global value into the alloca. If there's only a single store to an alloca, there are only two possible values that can be extracted from the alloca: the value stored, and undef. Assuming it's well-defined, it's always correct to use the value stored, because undef can be anything. The reason for the check is question is that the stored value might not dominate the use. This is only possible, however, if the stored value is an instruction; dominance doesn't make sense if StoringGlobalVal is true. -Eli From dag at cray.com Fri Sep 19 17:20:31 2008 From: dag at cray.com (David Greene) Date: Fri, 19 Sep 2008 17:20:31 -0500 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: <200809191711.43309.dag@cray.com> References: <200809191711.43309.dag@cray.com> Message-ID: <200809191720.31980.dag@cray.com> On Friday 19 September 2008 17:11, David Greene wrote: > What I'd really like to do is have Pass X re-run but not Pass Y. Pass Y > only uses some bookkeeping from Pass X to speed itself up. Having Pass X > not re-run could cause Pass Y to give wrong answers, but once Pass X is > up-to-date, Pass Y will be fine. To make this a bit more concrete: I noticed that the Verifier takes a VERY long time on large programs. This appears to be due to its checking of defs dominating uses. When a def and use are in the same BasicBlock, DominatorTrees iterates over the block until it finds one or the other. Since Verifier does this for each Instruction, this is an n^2 algorithm. Now, I could go and rewrite Verifier to be a little smarter about how it checks this (with a fair amount of pain, I would add) but that doesn't help all of the other passes that want to know if two instructions have a dominance relationship. So I thought about adding a pass that simply numbers Instructions, have DominatorTrees depend on that pass and then the dominates() question can just return whether one Instruction number is > the other. The number will get out of date as soon as Instructions are added or reordered (deleting instructions should be ok), but I don't want to go and recalculate all dominator information. I just need to update the numbering. -Dave From dpatel at apple.com Fri Sep 19 17:26:26 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 19 Sep 2008 15:26:26 -0700 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: <200809191711.43309.dag@cray.com> References: <200809191711.43309.dag@cray.com> Message-ID: On Sep 19, 2008, at 3:11 PM, David Greene wrote: > Let's say I have an analysis pass that's dependent on another > analysis pass > (getAnalysisUsage does the appropraite things). > > So Pass Y depends on Pass X. > > If some transformation pass depends on Pass Y and Pass Y has not been > invalidated by another other pass BUT Pass X _has_ been invalidated > by some > other pass, what happens? > > I can imagine two likely paths in the current implementation of > PassManager: > > 1. Pass Y is not re-run because it is considered up-to-date > > 2. Pass Y is re-run after Pass X because Pass X is out-of-date > > Which one of these happens? 1) will happen. - Devang > > > What I'd really like to do is have Pass X re-run but not Pass Y. > Pass Y only > uses some bookkeeping from Pass X to speed itself up. Having Pass X > not re-run could cause Pass Y to give wrong answers, but once Pass X > is > up-to-date, Pass Y will be fine. > > Is this at all possible? > > -Dave > _______________________________________________ > 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 Fri Sep 19 17:28:06 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 19 Sep 2008 15:28:06 -0700 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: <200809191720.31980.dag@cray.com> References: <200809191711.43309.dag@cray.com> <200809191720.31980.dag@cray.com> Message-ID: On Sep 19, 2008, at 3:20 PM, David Greene wrote: > On Friday 19 September 2008 17:11, David Greene wrote: > >> What I'd really like to do is have Pass X re-run but not Pass Y. >> Pass Y >> only uses some bookkeeping from Pass X to speed itself up. Having >> Pass X >> not re-run could cause Pass Y to give wrong answers, but once Pass >> X is >> up-to-date, Pass Y will be fine. > > To make this a bit more concrete: > > I noticed that the Verifier takes a VERY long time on large > programs. This > appears to be due to its checking of defs dominating uses. When a def > and use are in the same BasicBlock, DominatorTrees iterates over the > block until it finds one or the other. Since Verifier does this for > each > Instruction, this is an n^2 algorithm. > > Now, I could go and rewrite Verifier to be a little smarter about > how it > checks this (with a fair amount of pain, I would add) but that > doesn't help > all of the other passes that want to know if two instructions have a > dominance > relationship. > > So I thought about adding a pass that simply numbers Instructions, > have > DominatorTrees depend on that pass and then the dominates() question > can just > return whether one Instruction number is > the other. > > The number will get out of date as soon as Instructions are added or > reordered > (deleting instructions should be ok), At this point isn't dominator info dirty ? In other words, Y in your example is invalidated here. - Devang > but I don't want to go and recalculate > all dominator information. I just need to update the numbering. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dag at cray.com Fri Sep 19 17:28:16 2008 From: dag at cray.com (David Greene) Date: Fri, 19 Sep 2008 17:28:16 -0500 Subject: [LLVMdev] mem2reg Question In-Reply-To: References: <200809191308.09376.dag@cray.com> Message-ID: <200809191728.17102.dag@cray.com> On Friday 19 September 2008 17:17, Eli Friedman wrote: > On Fri, Sep 19, 2008 at 11:08 AM, David Greene wrote: > > \Why is this only prevented when NOT storing > > to global values? > > It's not a question of storing *to* a global value, but storing a > global value into the alloca. If there's only a single store to an Ah, ok. > alloca, there are only two possible values that can be extracted from > the alloca: the value stored, and undef. Assuming it's well-defined, > it's always correct to use the value stored, because undef can be > anything. I agree. > The reason for the check is question is that the stored value might > not dominate the use. This is only possible, however, if the stored Yes, that's the case I am seeing. > value is an instruction; dominance doesn't make sense if > StoringGlobalVal is true. Ok, so you're saying that because we're storing a global value, by definition it DOES dominate the use because it's a global (and thus live-in to the Function). Is that right? In the case I'm seeing, the "global value" is a constant. So I guess it's ok to forward that constant value to the use even though the store does not dominate it (as you say, undef can be anything). All right, this makes sense to me. But why is it any different if the stored value is from an instruction? We're storiung some value into an alloca (under a condition in this case) and the alloca later gets used in a place not dominated by the store (outside the condition in this case). Who cares where the value being stored came from? -Dave From dag at cray.com Fri Sep 19 17:35:59 2008 From: dag at cray.com (David Greene) Date: Fri, 19 Sep 2008 17:35:59 -0500 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: References: <200809191711.43309.dag@cray.com> Message-ID: <200809191736.00017.dag@cray.com> On Friday 19 September 2008 17:26, Devang Patel wrote: > On Sep 19, 2008, at 3:11 PM, David Greene wrote: > > Let's say I have an analysis pass that's dependent on another > > analysis pass > > (getAnalysisUsage does the appropraite things). > > > > So Pass Y depends on Pass X. > > > > If some transformation pass depends on Pass Y and Pass Y has not been > > invalidated by another other pass BUT Pass X _has_ been invalidated > > by some > > other pass, what happens? > > > > I can imagine two likely paths in the current implementation of > > PassManager: > > > > 1. Pass Y is not re-run because it is considered up-to-date > > > > 2. Pass Y is re-run after Pass X because Pass X is out-of-date > > > > Which one of these happens? > > 1) will happen. Ok, that's bad for me. Is there some way to query whether a Pass is up-to-date? -Dave From dag at cray.com Fri Sep 19 17:38:25 2008 From: dag at cray.com (David Greene) Date: Fri, 19 Sep 2008 17:38:25 -0500 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: References: <200809191711.43309.dag@cray.com> <200809191720.31980.dag@cray.com> Message-ID: <200809191738.25258.dag@cray.com> On Friday 19 September 2008 17:28, Devang Patel wrote: > On Sep 19, 2008, at 3:20 PM, David Greene wrote: > > On Friday 19 September 2008 17:11, David Greene wrote: > >> What I'd really like to do is have Pass X re-run but not Pass Y. > >> Pass Y > >> only uses some bookkeeping from Pass X to speed itself up. Having > >> Pass X > >> not re-run could cause Pass Y to give wrong answers, but once Pass > >> X is > >> up-to-date, Pass Y will be fine. > > > > To make this a bit more concrete: > > > > I noticed that the Verifier takes a VERY long time on large > > programs. This > > appears to be due to its checking of defs dominating uses. When a def > > and use are in the same BasicBlock, DominatorTrees iterates over the > > block until it finds one or the other. Since Verifier does this for > > each > > Instruction, this is an n^2 algorithm. > > > > Now, I could go and rewrite Verifier to be a little smarter about > > how it > > checks this (with a fair amount of pain, I would add) but that > > doesn't help > > all of the other passes that want to know if two instructions have a > > dominance > > relationship. > > > > So I thought about adding a pass that simply numbers Instructions, > > have > > DominatorTrees depend on that pass and then the dominates() question > > can just > > return whether one Instruction number is > the other. > > > > The number will get out of date as soon as Instructions are added or > > reordered > > (deleting instructions should be ok), > > At this point isn't dominator info dirty ? In other words, Y in your > example is invalidated here. I don't think so because the control flow graph hasn't necessarily been updated. If the whole dominator information is recalculated when only Instructions are manipulated, that's rather wasteful. I'll allow that it _may_ be invalidated in the current implementation but there's no reason it _must_ be. I want to protect myself against future performance enhancements. :) -Dave From dpatel at apple.com Fri Sep 19 17:50:44 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 19 Sep 2008 15:50:44 -0700 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: <200809191738.25258.dag@cray.com> References: <200809191711.43309.dag@cray.com> <200809191720.31980.dag@cray.com> <200809191738.25258.dag@cray.com> Message-ID: <33824659-7243-44B1-9885-D14E5C55A308@apple.com> On Sep 19, 2008, at 3:38 PM, David Greene wrote: >>> So I thought about adding a pass that simply numbers Instructions, >>> have >>> DominatorTrees depend on that pass and then the dominates() question >>> can just >>> return whether one Instruction number is > the other. >>> >>> The number will get out of date as soon as Instructions are added or >>> reordered >>> (deleting instructions should be ok), >> >> At this point isn't dominator info dirty ? In other words, Y in your >> example is invalidated here. > > I don't think so because the control flow graph hasn't necessarily > been > updated. Well, one of the domiantor info interface is bool dominates(Instruction *A, Instruction *B); This will return invalid results. So yes, the info is dirty. > If the whole dominator information is recalculated when only > Instructions are manipulated, that's rather wasteful. This is a question of how to update and maintain dom info. properly. The pass that is modifying instructions should update "number" appropriately in your scheme. Many loop passes goes through a length to maintain dominator info. > I'll allow that it > _may_ be invalidated in the current implementation well, I just realized that dom info is claimed as CFG pass so it is possible that some pass is not invalidating dom info while modifying BB instructions. IMO, this is a bug which should be fixed. - Devang > but there's no reason > it _must_ be. I want to protect myself against future performance > enhancements. :) > From dag at cray.com Fri Sep 19 18:03:40 2008 From: dag at cray.com (David Greene) Date: Fri, 19 Sep 2008 18:03:40 -0500 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: <33824659-7243-44B1-9885-D14E5C55A308@apple.com> References: <200809191711.43309.dag@cray.com> <200809191738.25258.dag@cray.com> <33824659-7243-44B1-9885-D14E5C55A308@apple.com> Message-ID: <200809191803.40482.dag@cray.com> On Friday 19 September 2008 17:50, Devang Patel wrote: > On Sep 19, 2008, at 3:38 PM, David Greene wrote: > >>> So I thought about adding a pass that simply numbers Instructions, > >>> have > >>> DominatorTrees depend on that pass and then the dominates() question > >>> can just > >>> return whether one Instruction number is > the other. > >>> > >>> The number will get out of date as soon as Instructions are added or > >>> reordered > >>> (deleting instructions should be ok), > >> > >> At this point isn't dominator info dirty ? In other words, Y in your > >> example is invalidated here. > > > > I don't think so because the control flow graph hasn't necessarily > > been > > updated. > > Well, one of the domiantor info interface is > bool dominates(Instruction *A, Instruction *B); > This will return invalid results. So yes, the info is dirty. Not right now it isn't. Right now dominators simply iterates through instructions. In my proposed scheme, it would be dirty only in the sense that the numbering is dirty. As soon as the numbering is updated, dominator information is up-to-date. > > If the whole dominator information is recalculated when only > > Instructions are manipulated, that's rather wasteful. > > This is a question of how to update and maintain dom info. properly. > The pass that is modifying instructions should update "number" > appropriately in your scheme. Many loop passes goes through a length > to maintain dominator info. No way I'm going to go through every Pass, check if it manipulates instructions, and update the numbering info if it does. I'd rather have dominators check whenther numbering is up-to-date and update the numbering itself if it's not, on-the-fly. > > I'll allow that it > > _may_ be invalidated in the current implementation > > well, I just realized that dom info is claimed as CFG pass so it is > possible that some pass is not invalidating dom info while modifying > BB instructions. IMO, this is a bug which should be fixed. No, right now it is not a bug since it computes dominance between instructions in the same basic block on-the-fly. Once that changes, then yes, something needs to be updated (the numbering, in my proposal). -Dave From eslee3 at uiuc.edu Fri Sep 19 18:14:47 2008 From: eslee3 at uiuc.edu (Edward Lee) Date: Fri, 19 Sep 2008 18:14:47 -0500 Subject: [LLVMdev] Disappearing Machine Basic Blocks (for new instruction) Message-ID: I have a new instruction that takes 2 labels, and in SelectionDAGISel, I have it doing "CurMBB->addSuccessor()" for both machine blocks. The DAG node it creates also takes both blocks as SDOperands. When I lower to x86, the not-fallthrough block disappears. If I run llc with --fast, the blocks stay around, so it must be an optimization pass of some sort that doesn't realize my new instruction is branch-like. How do I tell LLVM to not delete the target blocks of my instruction? Here's a list of files I've modified so far: M llvm-2.3/include/llvm/CodeGen/SelectionDAGNodes.h M llvm-2.3/include/llvm/Instruction.def M llvm-2.3/include/llvm/Instructions.h M llvm-2.3/include/llvm/Support/InstVisitor.h M llvm-2.3/lib/AsmParser/LLLexer.cpp M llvm-2.3/lib/AsmParser/llvmAsmParser.cpp.cvs M llvm-2.3/lib/AsmParser/llvmAsmParser.h.cvs M llvm-2.3/lib/AsmParser/llvmAsmParser.y M llvm-2.3/lib/AsmParser/llvmAsmParser.y.cvs M llvm-2.3/lib/Bitcode/Reader/BitcodeReader.cpp M llvm-2.3/lib/Bitcode/Writer/BitcodeWriter.cpp M llvm-2.3/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp M llvm-2.3/lib/CodeGen/SelectionDAG/SelectionDAG.cpp M llvm-2.3/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp M llvm-2.3/lib/Target/TargetSelectionDAG.td M llvm-2.3/lib/Target/X86/X86InstrInfo.td M llvm-2.3/lib/VMCore/Instruction.cpp M llvm-2.3/lib/VMCore/Instructions.cpp Ed From dpatel at apple.com Fri Sep 19 18:16:37 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 19 Sep 2008 16:16:37 -0700 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: <200809191803.40482.dag@cray.com> References: <200809191711.43309.dag@cray.com> <200809191738.25258.dag@cray.com> <33824659-7243-44B1-9885-D14E5C55A308@apple.com> <200809191803.40482.dag@cray.com> Message-ID: On Sep 19, 2008, at 4:03 PM, David Greene wrote: >> Well, one of the domiantor info interface is >> bool dominates(Instruction *A, Instruction *B); >> This will return invalid results. So yes, the info is dirty. > > Not right now it isn't. Right now dominators simply iterates through > instructions. Aha... OK. > In my proposed scheme, it would be dirty only in the sense that > the numbering is dirty. As soon as the numbering is updated, > dominator > information is up-to-date. > >>> If the whole dominator information is recalculated when only >>> Instructions are manipulated, that's rather wasteful. >> >> This is a question of how to update and maintain dom info. properly. >> The pass that is modifying instructions should update "number" >> appropriately in your scheme. Many loop passes goes through a length >> to maintain dominator info. > > No way I'm going to go through every Pass, check if it manipulates > instructions, and update the numbering info if it does. I'd rather > have > dominators check whenther numbering is up-to-date and update the > numbering > itself if it's not, on-the-fly. Well, then pass manager is not involved here at all in your scheme. - Devang From evan.cheng at apple.com Fri Sep 19 18:24:11 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 19 Sep 2008 16:24:11 -0700 Subject: [LLVMdev] Using VirtRegMap In-Reply-To: <200809191315.17242.dag@cray.com> References: <48D373BF.70201@cs.wisc.edu> <791D5FF8-3753-46D1-BB41-9A93F1511304@apple.com> <200809191315.17242.dag@cray.com> Message-ID: Ok. Everyone has different idea about "easy". :-) But VirtRegMap is going to be remove one of these days. And it's not going to like partially allocated virtual registers. So I don't think it's a good fit for Matt. Evan On Sep 19, 2008, at 11:15 AM, David Greene wrote: > On Friday 19 September 2008 11:37, Evan Cheng wrote: > >> Please avoid using VirtRegMap. It's very tied to the current register >> allocation pieces and not easily reusable. One of my mission in life >> is to kill it. > > Im surprised to see this. I found it rather easy to re-use for custom > register allocators. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dag at cray.com Fri Sep 19 18:29:33 2008 From: dag at cray.com (David Greene) Date: Fri, 19 Sep 2008 18:29:33 -0500 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: References: <200809191711.43309.dag@cray.com> <200809191803.40482.dag@cray.com> Message-ID: <200809191829.33320.dag@cray.com> On Friday 19 September 2008 18:16, Devang Patel wrote: > > No way I'm going to go through every Pass, check if it manipulates > > instructions, and update the numbering info if it does. I'd rather > > have > > dominators check whenther numbering is up-to-date and update the > > numbering > > itself if it's not, on-the-fly. > > Well, then pass manager is not involved here at all in your scheme. But PassManager should be able to tell me whether the numbering is up-to-date if the numbering is itself an analysis pass. I just don't know if there's an API to that information yet. -Dave From clattner at apple.com Fri Sep 19 18:41:38 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 19 Sep 2008 16:41:38 -0700 Subject: [LLVMdev] non-signed integer Type In-Reply-To: <84decce20809191416i4495f59sada3ac113925da48@mail.gmail.com> References: <84decce20809191416i4495f59sada3ac113925da48@mail.gmail.com> Message-ID: <56EF92C6-881E-41E0-9D59-BCB2AC475D57@apple.com> On Sep 19, 2008, at 2:16 PM, Scott Graham wrote: > Hi > > Is there any rationale written down for why integer types don't carry > (perhaps optional) signs somewhere? I feel like I might have read it > somewhere before (and I see that it used to exist pre 2.0), but I > can't find anything now. There is some motivation in this talk: http://llvm.org/pubs/2007-07-25-LLVM-2.0-and-Beyond.html -Chris From dpatel at apple.com Fri Sep 19 18:42:23 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 19 Sep 2008 16:42:23 -0700 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: <200809191829.33320.dag@cray.com> References: <200809191711.43309.dag@cray.com> <200809191803.40482.dag@cray.com> <200809191829.33320.dag@cray.com> Message-ID: <32F3D0D1-2E70-4877-89E7-8ACCB50BFD15@apple.com> On Sep 19, 2008, at 4:29 PM, David Greene wrote: > On Friday 19 September 2008 18:16, Devang Patel wrote: > >>> No way I'm going to go through every Pass, check if it manipulates >>> instructions, and update the numbering info if it does. I'd rather >>> have >>> dominators check whenther numbering is up-to-date and update the >>> numbering >>> itself if it's not, on-the-fly. >> >> Well, then pass manager is not involved here at all in your scheme. > > But PassManager should be able to tell me whether the numbering is > up-to-date > if the numbering is itself an analysis pass. I just don't know if > there's an > API to that information yet. Right now, pass manager does not provide such API. Note, pass manager does not dynamically schedule passes. - Devang From evan.cheng at apple.com Fri Sep 19 19:11:17 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 19 Sep 2008 17:11:17 -0700 Subject: [LLVMdev] Disappearing Machine Basic Blocks (for new instruction) In-Reply-To: References: Message-ID: <4B84092A-B8E3-4C5B-B6A5-FB32804CF809@apple.com> For anyone to have any shot of answering your question, you need to provide more information. To start, please figure out which pass deleted the block, what does the machine function looks like before and after. Evan On Sep 19, 2008, at 4:14 PM, Edward Lee wrote: > I have a new instruction that takes 2 labels, and in SelectionDAGISel, > I have it doing "CurMBB->addSuccessor()" for both machine blocks. The > DAG node it creates also takes both blocks as SDOperands. > > When I lower to x86, the not-fallthrough block disappears. If I run > llc with --fast, the blocks stay around, so it must be an optimization > pass of some sort that doesn't realize my new instruction is > branch-like. > > How do I tell LLVM to not delete the target blocks of my instruction? > > Here's a list of files I've modified so far: > M llvm-2.3/include/llvm/CodeGen/SelectionDAGNodes.h > M llvm-2.3/include/llvm/Instruction.def > M llvm-2.3/include/llvm/Instructions.h > M llvm-2.3/include/llvm/Support/InstVisitor.h > M llvm-2.3/lib/AsmParser/LLLexer.cpp > M llvm-2.3/lib/AsmParser/llvmAsmParser.cpp.cvs > M llvm-2.3/lib/AsmParser/llvmAsmParser.h.cvs > M llvm-2.3/lib/AsmParser/llvmAsmParser.y > M llvm-2.3/lib/AsmParser/llvmAsmParser.y.cvs > M llvm-2.3/lib/Bitcode/Reader/BitcodeReader.cpp > M llvm-2.3/lib/Bitcode/Writer/BitcodeWriter.cpp > M llvm-2.3/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp > M llvm-2.3/lib/CodeGen/SelectionDAG/SelectionDAG.cpp > M llvm-2.3/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp > M llvm-2.3/lib/Target/TargetSelectionDAG.td > M llvm-2.3/lib/Target/X86/X86InstrInfo.td > M llvm-2.3/lib/VMCore/Instruction.cpp > M llvm-2.3/lib/VMCore/Instructions.cpp > > Ed > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From eli.friedman at gmail.com Fri Sep 19 19:21:53 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 19 Sep 2008 17:21:53 -0700 Subject: [LLVMdev] mem2reg Question In-Reply-To: <200809191728.17102.dag@cray.com> References: <200809191308.09376.dag@cray.com> <200809191728.17102.dag@cray.com> Message-ID: On Fri, Sep 19, 2008 at 3:28 PM, David Greene wrote: > Ok, so you're saying that because we're storing a global value, by > definition it DOES dominate the use because it's a global (and > thus live-in to the Function). Is that right? Yes. > But why is it any different if the stored value is from an instruction? We're > storiung some value into an alloca (under a condition in this case) and the > alloca later gets used in a place not dominated by the store (outside the > condition in this case). Who cares where the value being stored came from? The issue isn't really whether the store dominates the use, but whether the value being stored dominates the use. The code is correct because dominance is transitive; since the store dominates the use, the value stored must also dominate the use. -Eli From clattner at apple.com Fri Sep 19 22:38:13 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 19 Sep 2008 20:38:13 -0700 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: <200809191720.31980.dag@cray.com> References: <200809191711.43309.dag@cray.com> <200809191720.31980.dag@cray.com> Message-ID: <092C9A0C-D012-416B-BF03-832C5282074A@apple.com> On Sep 19, 2008, at 3:20 PM, David Greene wrote: > On Friday 19 September 2008 17:11, David Greene wrote: > >> What I'd really like to do is have Pass X re-run but not Pass Y. >> Pass Y >> only uses some bookkeeping from Pass X to speed itself up. Having >> Pass X >> not re-run could cause Pass Y to give wrong answers, but once Pass >> X is >> up-to-date, Pass Y will be fine. > > To make this a bit more concrete: > > I noticed that the Verifier takes a VERY long time on large > programs. This > appears to be due to its checking of defs dominating uses. When a def > and use are in the same BasicBlock, DominatorTrees iterates over the > block until it finds one or the other. Since Verifier does this for > each > Instruction, this is an n^2 algorithm. The verifier case is easy to fix. Can you please send me a testcase? -Chris From clattner at apple.com Fri Sep 19 23:12:14 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 19 Sep 2008 21:12:14 -0700 Subject: [LLVMdev] Some thoughts on metadata, debug info, TBAA, annotations etc Message-ID: Hi All, I'd like to propose some extensions to LLVM that will make it substantially faster at manipulating debug info, and will make the general annotation mechanisms in LLVM much richer: http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt Thoughts welcome, -Chris From clattner at apple.com Fri Sep 19 23:51:29 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 19 Sep 2008 21:51:29 -0700 Subject: [LLVMdev] Proposal : Function Notes In-Reply-To: <20080823135841.GB2657@katherina.student.utwente.nl> References: <28ED9D84-B1D6-4B3C-8A3F-DA2EF7ACDE3A@apple.com> <20080823135841.GB2657@katherina.student.utwente.nl> Message-ID: <357F1685-D539-49BC-83E8-76CDFE24B251@apple.com> On Aug 23, 2008, at 6:58 AM, Matthijs Kooijman wrote: > Hi Devang, > >> All supported notes must be documented in LLVM language reference. > Does this also mean that undocumented / unsupported notes are > invalid? In > particular, when I have a custom frontend and backend, using custom > notes > could be a great way to communicate between those, if the LLVM IR > would allow > unknown notes. As mentioned before Devang's proposal is not really suited for that. The notes should be considered to be part of the LLVM IR, and documented in langref (Devang, did you do this?). The metadata proposal I sent out would be a more appropriate way of handling cases where front-ends want to propagate arbitrary information. http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt -Chris From romixlev at yahoo.com Sat Sep 20 02:13:11 2008 From: romixlev at yahoo.com (Roman Levenstein) Date: Sat, 20 Sep 2008 00:13:11 -0700 (PDT) Subject: [LLVMdev] Using VirtRegMap Message-ID: <95784.76953.qm@web56308.mail.re3.yahoo.com> Hi Evan, > Ok. Everyone has different idea about "easy". :-) I second your opinion that it is not very easy to use and it is very tightly coupled with the current linear scan register allocator implementation. > But VirtRegMap is going to be remove one of these days. When are you going to do that? Are you going to remove it from the source tree? Will it be replaced with something similar, e.g. with another kind of spiller and register tracking mechamism? Please keep in mind that some other allocators being currently developed use VirtRegMap with all its pros and cons. These allocators include an iterated coalescing graph colorging register allocator (Lang), a chordal graph register allocator (Fernando), a puzzle solving register allocator (Fernando), a PQBP register allocaor (Lang) and an extended linear scan register allocator (Roman). May be there are some other allocators as well. And BTW, some other parts of the LLVM API related to register allocation are also used by other register allocators. So, any major changes to them may break them as well. Therefore it would be nice to get a better understanding and common view on how to proceed with the VirtRegMap with regard to removing, improving or replacing it with something different. Thanks, Roman > Evan > > On Sep 19, 2008, at 11:15 AM, David Greene wrote: > > > On Friday 19 September 2008 11:37, Evan Cheng wrote: > > > >> Please avoid using VirtRegMap. It's very tied to the current register > >> allocation pieces and not easily reusable. One of my mission in life > >> is to kill it. > > > > Im surprised to see this. I found it rather easy to re-use for custom > > register allocators. > > > > -Dave > > _______________________________________________ > > 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 __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com From Sanjiv.Gupta at microchip.com Sat Sep 20 09:12:20 2008 From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com) Date: Sat, 20 Sep 2008 07:12:20 -0700 Subject: [LLVMdev] Illegal pointer type References: <16e5fdf90809181608m5ba8abd3u17c1119f6b4422d3@mail.gmail.com> <496E0559-D0B3-4564-9FFC-E898F3458BAB@apple.com> Message-ID: >I am assuming a 16-bit value will be stored in a pair of 8-bit > registers? One related question is how to make sure that the correct register pair is allocated to the16-bit quantity when using two 8-bit operations. In other words, how we can make sure that the 16-bit pointer is stored into [AH, AL] and not in [AH, BL] ? i.e. GR8 = [ AH, BH, AL, BL]; GR16 = [AX, BX] ; // AX, BX are subreg pairs of ah,al and bh, bl the DAG looks like Wrapper:i16 (GR16) = MoveToHi:i8 (GR8) , MoveToLo:i8 (GR8) Now how to make sure that if MoveToHi gets AH , then 1. MoveToLo should get AL, 2. the Wrapper should get AX - Sanjiv On Sep 19, 2008, at 5:01 AM, Sachin.Punyani at microchip.com wrote: > > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >> bounces at cs.uiuc.edu] > On >> Behalf Of Bill Wendling >> Sent: Friday, September 19, 2008 4:38 AM >> >> On Thu, Sep 18, 2008 at 7:12 AM, > wrote: >>> What changes would be required in LLVM to support illegal pointer > type? >>> >> Hi Sachin, >> >> The question's a bit broad. And I don't think the answer you want is >> as simple as "don't run the legalizer" (which probably won't work). >> Do >> you have a more specific question? > > I am trying to ask a broad question. My target has 16 bit pointers but > register size is 8 bit only. What changes in LLVM would be required to > support 16 bit pointers on 8 bit registers? > > Regards > Sachin > >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 6091 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080920/863380b2/attachment-0001.bin From geforce8800 at gmail.com Sat Sep 20 10:08:54 2008 From: geforce8800 at gmail.com (Cloud Strife) Date: Sat, 20 Sep 2008 23:08:54 +0800 Subject: [LLVMdev] Has anyone sucessfully compile the llvm code using visual studio 2005? Message-ID: HI everyone. I am using visual studio 2005 and windows xp to compile the llvm project. I downloaded the project with svn client. I thought this action may gurantee my code is up to date and integrate. However, after I opened the solution located in the win32 directory and build the solution, the visual studio output many many errors, and even few projects can be compiled to generate runable .exe files. I miss the powerful experiment tools to experience the power of llvm. :-( If anyone here has sucessfully compile the llvm source code on windows xp by visual studio 2005 sp1, would you please tell me what is needed to set up to make a neat and integrate compilation? At least, some command line tools should be generated to be played around. Thank you very much for any advice. Good luck. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080920/95415fe2/attachment.html From ofv at wanadoo.es Sat Sep 20 10:55:48 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Sat, 20 Sep 2008 17:55:48 +0200 Subject: [LLVMdev] Has anyone sucessfully compile the llvm code using visual studio 2005? References: Message-ID: "Cloud Strife" writes: > HI everyone. > I am using visual studio 2005 and windows xp to compile the llvm project. I > downloaded the project with svn client. I thought this action may gurantee > my code is up to date and integrate. The VS build is maintained regularly, but not continuously. > However, after I opened the solution located in the win32 directory and > build the solution, the visual studio output many many errors, and even few > projects can be compiled to generate runable .exe files. I miss the powerful > experiment tools to experience the power of llvm. :-( It would be useful if you posted the first error messages you found. > If anyone here has sucessfully compile the llvm source code on windows xp by > visual studio 2005 sp1, would you please tell me what is needed to set up to > make a neat and integrate compilation? At least, some command line tools > should be generated to be played around. If you need LLVM on Windows ASAP, try building with MinGW/MSYS. -- Oscar From ofv at wanadoo.es Sat Sep 20 11:04:22 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Sat, 20 Sep 2008 18:04:22 +0200 Subject: [LLVMdev] Has anyone sucessfully compile the llvm code using visual studio 2005? References: Message-ID: "Cloud Strife" writes: > HI everyone. > I am using visual studio 2005 and windows xp to compile the llvm project. I > downloaded the project with svn client. I thought this action may gurantee > my code is up to date and integrate. Forgot to mention: if you want stability, don't use the development sources, download a LLVM release source tarball. Those pass through a QA phase. The latest release (2.3) should compile without problems with VC 2005. -- Oscar From jonathandeanharrop at googlemail.com Sat Sep 20 12:57:17 2008 From: jonathandeanharrop at googlemail.com (Jon Harrop) Date: Sat, 20 Sep 2008 18:57:17 +0100 Subject: [LLVMdev] first two chapters for the ocaml bindings in svn In-Reply-To: <1ef034530803310156j47e8c491l69fe7720f75c837f@mail.gmail.com> References: <1ef034530803270130h3dfb407fv721a7128e817709c@mail.gmail.com> <1ef034530803300304g303635fej32d3d05a41f087fd@mail.gmail.com> <1ef034530803310156j47e8c491l69fe7720f75c837f@mail.gmail.com> Message-ID: <200809201857.17223.jon@ffconsultancy.com> On Monday 31 March 2008 09:56:45 Erick Tryzelaar wrote: > The full series of the ocaml tutorial is done! You can find it here: > > http://llvm.org/docs/tutorial/ > > Please let me know if you have any comments, bugs, suggestions, and > etc. I'll send a mail to the ocaml mailing list tomorrow to drum up > some interest from the other ocaml users. I think your new OCaml tutorials and the original C++ ones are absolutely brilliant! I do have one minor concern and that is that 25% of the tutorial covers lexing and parsing which is unrelated to LLVM. I would have expected a trivial dozen-line parser in OCaml following by lots of LLVM-specific stuff instead. I also have two main requests for further tutorials: . More about performance, e.g. what might a compiler using LLVM be expected to do itself in order to obtain decent performance and how easily can competitive performance (e.g. comparable with gcc) be obtained for simple examples. . More about GC, e.g. a walkthrough of a really simple implementation for a garbage collected language like the old LLVM-based Scheme implementation with the Cheney semispace collector. Fantastic work so far though. Thank you! -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e From cedric.venet at laposte.net Sat Sep 20 13:06:49 2008 From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=) Date: Sat, 20 Sep 2008 20:06:49 +0200 Subject: [LLVMdev] Has anyone sucessfully compile the llvm code using visual studio 2005? In-Reply-To: References: Message-ID: <48D53BB9.9050302@laposte.net> updated, 56390 compile without problem (VS2005, winXP). post your errors next time and try to correct them yourself and make a patch (you should be able to correct them yourself if you want to mess up with llvm, just add the new files to the projects). regards, C?dric Cloud Strife a ?crit : > HI everyone. > I am using visual studio 2005 and windows xp to compile the llvm project. I > downloaded the project with svn client. I thought this action may gurantee > my code is up to date and integrate. > > However, after I opened the solution located in the win32 directory and > build the solution, the visual studio output many many errors, and even few > projects can be compiled to generate runable .exe files. I miss the powerful > experiment tools to experience the power of llvm. :-( > > If anyone here has sucessfully compile the llvm source code on windows xp by > visual studio 2005 sp1, would you please tell me what is needed to set up to > make a neat and integrate compilation? At least, some command line tools > should be generated to be played around. > > Thank you very much for any advice. Good luck. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ahmadsharif at hotmail.com Sat Sep 20 14:12:54 2008 From: ahmadsharif at hotmail.com (madiyaan) Date: Sat, 20 Sep 2008 12:12:54 -0700 (PDT) Subject: [LLVMdev] Run-time optimization using profile data Message-ID: <19588300.post@talk.nabble.com> Hello: I am new to llvm. I am looking for an example somewhere, or a walkthrough/guide on how to do runtime optimization using llvm. Ideally, I would like to: 1. Compile the program from C to LLVM or native with LLVM information embedded in the binary. 2. Run the binary under LLVM's interpreter, and profile the data. I hope LLVM has support for all this, and I don't have to insert my own instructions for profiling. 3. A callback that gets called when a function or a basic block gets hot. Ideally, I would like to transform this basic block and connected ones in the graph. So ideally, I would like my function to get called if a trace or a collection of basic blocks gets hot. 4. I would like to do some transformations in the IR. i.e. from LLVM->LLVM transforms on the aforementioned hot regions/blocks. 5. I would then like to have control over the JIT as well. In the above LLVM->LLVM transform, I would have placed some "special" instructions (like maybe illegal opcodes, or something like that), and once the JIT is about to translate those, my routine should get called. I will then transform those instructions into "special" native instructions. 6. I then want to execute the newly written binary and remove profile instrumentation, but leave my special native instructions intact. I would like to know if there is such an example in the LLVM package. If not, where in the cpp files should I begin hacking to do each of these steps. Regards, -- View this message in context: http://www.nabble.com/Run-time-optimization-using-profile-data-tp19588300p19588300.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From ofv at wanadoo.es Sat Sep 20 16:22:14 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Sat, 20 Sep 2008 23:22:14 +0200 Subject: [LLVMdev] State of CMake build system. Message-ID: A non-text attachment was scrubbed... Name: cmake.patch Type: text/x-patch Size: 73604 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080920/c6f9a716/attachment-0001.bin From eli.friedman at gmail.com Sat Sep 20 17:28:01 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 20 Sep 2008 15:28:01 -0700 Subject: [LLVMdev] Run-time optimization using profile data In-Reply-To: <19588300.post@talk.nabble.com> References: <19588300.post@talk.nabble.com> Message-ID: On Sat, Sep 20, 2008 at 12:12 PM, madiyaan wrote: > Hello: > > I am new to llvm. I am looking for an example somewhere, or a > walkthrough/guide on how to do runtime optimization using llvm. Ideally, I > would like to: > > 1. Compile the program from C to LLVM or native with LLVM information > embedded in the binary. > 2. Run the binary under LLVM's interpreter, and profile the data. I hope > LLVM has support for all this, and I don't have to insert my own > instructions for profiling. That isn't too hard. It isn't really getting used, but there's some code for this in the LLVM tree. See llvm/lib/Transforms/Instrumentation, and the related runtime support in llvm/runtime/libprofile. > 3. A callback that gets called when a function or a basic block gets hot. > Ideally, I would like to transform this basic block and connected ones in > the graph. So ideally, I would like my function to get called if a trace or > a collection of basic blocks gets hot. > > 4. I would like to do some transformations in the IR. i.e. from LLVM->LLVM > transforms on the aforementioned hot regions/blocks. There's isn't really any existing code for this, but there isn't anything fundamentally tricky about it; it's just a matter of writing code to analyze the profile data and a transformation pass which uses the data. > 5. I would then like to have control over the JIT as well. In the above > LLVM->LLVM transform, I would have placed some "special" instructions (like > maybe illegal opcodes, or something like that), and once the JIT is about to > translate those, my routine should get called. I will then transform those > instructions into "special" native instructions. You want to have the JIT recompile the code as it's running? The JIT doesn't currently support that, and it's relatively tricky to write. Messing with code generation to add platform-specific intrinsics isn't too hard; you'd need to provide more details to say anything specific, though. > 6. I then want to execute the newly written binary and remove profile > instrumentation, but leave my special native instructions intact. Stripping out the instrumentation should be a very simple transformation pass. -Eli From geforce8800 at gmail.com Sat Sep 20 23:28:16 2008 From: geforce8800 at gmail.com (Cloud Strife) Date: Sun, 21 Sep 2008 12:28:16 +0800 Subject: [LLVMdev] Has anyone sucessfully compile the llvm code using visual Message-ID: Thank you very much for your reply. However, my question is not completely solved. I svned the latest version of the llvm. After I open in the visual studio 2005, the building errors are still there and there was not any .exe executable file output. I set the Fibonacci project under the solution as my startup project and issue the debug-run command. However, the vs 2005 just prompted me that the .exe missing. Some of the errors are transcripted here: 1>------ Build started: Project: VMCore, Configuration: Debug Win32 ------ 1>Performing TableGen Step 1>Building Intrinsics.td code emitter with tblgen 1>Project : error PRJ0019: A tool returned an error code from "Performing TableGen Step" 1>Creating browse information file... 1>Microsoft Browse Information Maintenance Utility Version 8.00.50727 1>Copyright (C) Microsoft Corporation. All rights reserved. 1>BSCMAKE: error BK1506 : cannot open file '.\win32\debug\AutoUpgrade.sbr': No such file or directory 1>Build log was saved at "file://c:\Documents and Settings\Administrator\llvm\win32\VMCore\Win32\Debug\BuildLog.htm" 1>VMCore - 2 error(s), 0 warning(s) 2>------ Build started: Project: CodeGen, Configuration: Debug Win32 ------ 3>------ Build started: Project: Transforms, Configuration: Debug Win32 ------ 2>Compiling... 3>Compiling... 2>GCStrategy.cpp 3>RSProfiling.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>DeadArgumentElimination.cpp 2>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 2>IntrinsicLowering.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>GlobalOpt.cpp 2>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 2>MachineModuleInfo.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>InlineAlways.cpp 2>c:\Documents and Settings\Administrator\llvm\include\llvm/Support/AlignOf.h(26) : warning C4624: 'llvm::AlignmentCalcImpl' : destructor could not be generated because a base class destructor is inaccessible 2> with 2> [ 2> T=llvm::MachineInstr 2> ] 2> c:\Documents and Settings\Administrator\llvm\include\llvm/Support/AlignOf.h(38) : see reference to class template instantiation 'llvm::AlignmentCalcImpl' being compiled 2> with 2> [ 2> T=llvm::MachineInstr 2> ] 2> c:\Documents and Settings\Administrator\llvm\include\llvm/CodeGen/MachineFunction.h(88) : see reference to class template instantiation 'llvm::AlignOf' being compiled 2> with 2> [ 2> T=llvm::MachineInstr 2> ] 2>c:\Documents and Settings\Administrator\llvm\include\llvm/Support/AlignOf.h(26) : warning C4624: 'llvm::AlignmentCalcImpl' : destructor could not be generated because a base class destructor is inaccessible 2> with 2> [ 2> T=llvm::MachineBasicBlock 2> ] 2> c:\Documents and Settings\Administrator\llvm\include\llvm/Support/AlignOf.h(38) : see reference to class template instantiation 'llvm::AlignmentCalcImpl' being compiled 2> with 2> [ 2> T=llvm::MachineBasicBlock 2> ] 2> c:\Documents and Settings\Administrator\llvm\include\llvm/CodeGen/MachineFunction.h(91) : see reference to class template instantiation 'llvm::AlignOf' being compiled 2> with 2> [ 2> T=llvm::MachineBasicBlock 2> ] 2>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 2>ShadowStackGC.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>InlineSimple.cpp 2>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 2>SelectionDAG.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>LowerSetJmp.cpp 2>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 2>SelectionDAGBuild.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>DeadStoreElimination.cpp 2>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 2>SelectionDAGISel.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>InstructionCombining.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>JumpThreading.cpp 2>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 2>Generating Code... 2>Creating browse information file... 2>Microsoft Browse Information Maintenance Utility Version 8.00.50727 2>Copyright (C) Microsoft Corporation. All rights reserved. 2>BSCMAKE: error BK1506 : cannot open file '.\win32\debug\GCStrategy.sbr': No such file or directory 2>Build log was saved at "file://c:\Documents and Settings\Administrator\llvm\win32\CodeGen\Win32\Debug\BuildLog.htm" 2>CodeGen - 8 error(s), 2 warning(s) 4>------ Build started: Project: Analysis, Configuration: Debug Win32 ------ 4>Compiling... 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>LoopStrengthReduce.cpp 4>BasicAliasAnalysis.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>LoopUnroll.cpp 4>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 4>ConstantFolding.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>MemCpyOptimizer.cpp 4>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 4>ValueTracking.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>ScalarReplAggregates.cpp 4>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 4>Generating Code... 4>Creating browse information file... 4>Microsoft Browse Information Maintenance Utility Version 8.00.50727 4>Copyright (C) Microsoft Corporation. All rights reserved. 4>BSCMAKE: error BK1506 : cannot open file '.\win32\debug\BasicAliasAnalysis.sbr': No such file or directory 4>Build log was saved at "file://c:\Documents and Settings\Administrator\llvm\win32\Analysis\Win32\Debug\BuildLog.htm" 4>Analysis - 4 error(s), 0 warning(s) 5>------ Build started: Project: ExecutionEngine, Configuration: Debug Win32 ------ 5>ExecutionEngine : warning PRJ0009 : Build log could not be opened for writing. 5>Make sure that the file is not open by another process and is not write-protected. 5>Compiling... 5>Execution.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>TailDuplication.cpp 5>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 5>Interpreter.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>CodeExtractor.cpp 5>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 5>Generating Code... 5>Creating browse information file... 5>Microsoft Browse Information Maintenance Utility Version 8.00.50727 5>Copyright (C) Microsoft Corporation. All rights reserved. 5>BSCMAKE: error BK1506 : cannot open file '.\win32\debug\Execution.sbr': No such file or directory 5>Build log was saved at "file://c:\Documents and Settings\Administrator\llvm\win32\ExecutionEngine\Win32\Debug\BuildLog.htm" 5>ExecutionEngine - 3 error(s), 1 warning(s) 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>InlineCost.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>InlineFunction.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>Local.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>LowerInvoke.cpp 3>c:\Documents and Settings\Administrator\llvm\include\llvm/Intrinsics.h(39) : fatal error C1083: Cannot open include file: 'llvm/Intrinsics.gen': No such file or directory 3>Generating Code... 3>Creating browse information file... 3>Microsoft Browse Information Maintenance Utility Version 8.00.50727 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>BSCMAKE: error BK1506 : cannot open file '.\win32\debug\RSProfiling.sbr': No such file or directory 3>Build log was saved at "file://c:\Documents and Settings\Administrator\llvm\win32\Transforms\Win32\Debug\BuildLog.htm" 3>Transforms - 20 error(s), 0 warning(s) 6>------ Build started: Project: x86, Configuration: Debug Win32 ------ 6>Performing TableGen Step 6>Building X86.td register names with tblgen 6>Building X86.td register information header with tblgen 6>Building X86.td register information implementation with tblgen 6>Building X86.td instruction names with tblgen 6>Building X86.td instruction information with tblgen 6>Building X86.td assembly writer with tblgen 6>Building X86.td assembly writer #1 with tblgen 6>Building X86.td instruction selector implementation with tblgen 6>Project : error PRJ0019: A tool returned an error code from "Performing TableGen Step" 6>Creating browse information file... 6>Microsoft Browse Information Maintenance Utility Version 8.00.50727 6>Copyright (C) Microsoft Corporation. All rights reserved. 6>BSCMAKE: error BK1506 : cannot open file '.\win32\debug\X86ELFWriterInfo.sbr': No such file or directory 6>Build log was saved at "file://c:\Documents and Settings\Administrator\llvm\win32\x86\Win32\Debug\BuildLog.htm" 6>x86 - 2 error(s), 0 warning(s) 7>------ Build started: Project: Fibonacci, Configuration: Debug Win32 ------ 7>Linking... 7>LINK : fatal error LNK1104: cannot open file 'c:\Documents.obj' 7>Build log was saved at "file://c:\Documents and Settings\Administrator\llvm\win32\Fibonacci\Win32\Debug\BuildLog.htm" 7>Fibonacci - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 7 failed, 6 up-to-date, 0 skipped ========== I will try harder to dig into the environment setting to see if there is anything blowing the project. Thank you all the same. -- Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080921/cb0592b8/attachment-0001.html From ofv at wanadoo.es Sun Sep 21 00:32:09 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Sun, 21 Sep 2008 07:32:09 +0200 Subject: [LLVMdev] Has anyone sucessfully compile the llvm code using visual References: Message-ID: "Cloud Strife" writes: > Thank you very much for your reply. > However, my question is not completely solved. > I svned the latest version of the llvm. After I open in the visual studio > 2005, the building errors are still there and there was not any .exe > executable file output. > I set the Fibonacci project under the solution as my startup project and > issue the debug-run command. However, the vs 2005 just prompted me that the > .exe missing. The error messages you posted indicate that tblgen.exe was not built. Either the build failed or it is not on the list of (direct or indirect) dependencies for Fibonacci. Instead of building a specific project, try a Build All. [snip] -- Oscar From abergeron at gmail.com Sun Sep 21 01:24:48 2008 From: abergeron at gmail.com (Arnaud Bergeron) Date: Sun, 21 Sep 2008 02:24:48 -0400 Subject: [LLVMdev] OpenBSD port in progress Message-ID: While building an OpenBSD port for LLVM 2.3 I encountered a few issues. The first one is that the system compiler $ gcc -v Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd4.3/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) Fails to build TableGen correctly which then crashes while processing the tables for ARM. I fixed this by using gcc 4.2.0 The second one is that there are 8 tests failing, but none of them seems to fail for reason linked to LLVM itself but rather peculiarities like grep not working the same way. simple.patch is for the 3 simple cases where plain grep is used but regexp patterns are expected to be matched. This only works on GNU grep. I fixed this by using grep -E. maybe.patch is for the 2 cases where \< and \> are used. On linux these match the end and the start of a word. To get equivalent behavior on OpenBSD you have to use [[:<:]] and [[:>:]] and this doesn't work on linux (or mac). Seeing how they are used, they could be either removed (which is what maybe.patch does) or replaced by simple non-word character matching. The other three failures are more involved. The first one is Feature/load_module.ll. It fails because the library is called LLVMHello.so.0.0 rather than LLVMHello.so. I have a local patch that renames the lib in the test that I doubt should be applied to the tree. The second one is Transforms/SimplifyLibCalls/floor.ll. nearbyint is not replaced by nearbyintf since neither function is defined in the OpenBSD libm. The other two are replaced fine though. My crude solution was to remove checking for nearbyintf. The third one is Assembler/2004-02-01-NegativeZero.ll. This fails because the constants are printed as positive zeros. I know there is a bug in libc on OpenBSD 4.3 that makes it print negative zeros as positive. It will be fixed in the next release and if this is linked then there is no concern. Arnaud -------------- next part -------------- A non-text attachment was scrubbed... Name: simple.patch Type: application/octet-stream Size: 1717 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080921/40916a6a/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: maybe.patch Type: application/octet-stream Size: 786 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080921/40916a6a/attachment-0001.obj From cedric.venet at laposte.net Sun Sep 21 03:13:57 2008 From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=) Date: Sun, 21 Sep 2008 10:13:57 +0200 Subject: [LLVMdev] Has anyone sucessfully compile the llvm code using visual In-Reply-To: References: Message-ID: <48D60245.5060308@laposte.net> ?scar Fuentes a ?crit : > "Cloud Strife" writes: > >> Thank you very much for your reply. >> However, my question is not completely solved. >> I svned the latest version of the llvm. After I open in the visual studio >> 2005, the building errors are still there and there was not any .exe >> executable file output. >> I set the Fibonacci project under the solution as my startup project and >> issue the debug-run command. However, the vs 2005 just prompted me that the >> .exe missing. > > The error messages you posted indicate that tblgen.exe was not > built. Either the build failed or it is not on the list of (direct or > indirect) dependencies for Fibonacci. Instead of building a specific > project, try a Build All. > > [snip] > I wonder if the fact that your path contain space could make the build fail. Some path may not be correctly escaped... You may also want to try build all a few times. The project files are a little complex, because some file are generated with tablegen and I think the only way to acces these info is to manually edit the project file. From ofv at wanadoo.es Sun Sep 21 09:12:39 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Sun, 21 Sep 2008 16:12:39 +0200 Subject: [LLVMdev] Has anyone sucessfully compile the llvm code using visual In-Reply-To: (Cloud Strife's message of "Sun, 21 Sep 2008 15:45:03 +0800") References: Message-ID: [please keep discussion on-list. thanks] "Cloud Strife" writes: > Thank you very much for your help. Now this problem has been solved and I > have got a workable project. > > I am trying the example in the llvm\docs\tutorial\LangImpl4.html > . However, after I put the whole source code into my customized project, > there is an error output from visual studio saying:"error C2955: > 'llvm::IRBuilder' : use of class template requires template argument list". > ---------->static IRBuilder Builder; try static IRBuilder<> Builder; > I went to the definition of the IRBuilder object and found the template > declaration was:" > template > class IRBuilder{ > ....} > " > It seems that the class has default parameters for the template, how could > this error happen? > > Thank you very much for any advise. Good luck. -- Oscar From ofv at wanadoo.es Sun Sep 21 11:27:03 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Sun, 21 Sep 2008 18:27:03 +0200 Subject: [LLVMdev] State of CMake build system. References: Message-ID: A non-text attachment was scrubbed... Name: cmake.patch Type: text/x-patch Size: 73590 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080921/687284b5/attachment-0001.bin From gohman at apple.com Sun Sep 21 11:34:47 2008 From: gohman at apple.com (Dan Gohman) Date: Sun, 21 Sep 2008 09:34:47 -0700 (PDT) Subject: [LLVMdev] OpenBSD port in progress In-Reply-To: References: Message-ID: <60891.76.220.41.203.1222014887.squirrel@webmail.apple.com> On Sat, September 20, 2008 11:24 pm, Arnaud Bergeron wrote: > maybe.patch is for the 2 cases where \< and \> are used. On linux > these match the end and the start of a word. To get equivalent > behavior on OpenBSD you have to use [[:<:]] and [[:>:]] and this > doesn't work on linux (or mac). Seeing how they are used, they could > be either removed (which is what maybe.patch does) or replaced by > simple non-word character matching. Replacing them would be better than removing them. In these two tests, the patterns should be preceded and followed by tab characters. Thanks, Dan From dpatel at apple.com Sun Sep 21 11:58:10 2008 From: dpatel at apple.com (Devang Patel) Date: Sun, 21 Sep 2008 09:58:10 -0700 Subject: [LLVMdev] Proposal : Function Notes In-Reply-To: <357F1685-D539-49BC-83E8-76CDFE24B251@apple.com> References: <28ED9D84-B1D6-4B3C-8A3F-DA2EF7ACDE3A@apple.com> <20080823135841.GB2657@katherina.student.utwente.nl> <357F1685-D539-49BC-83E8-76CDFE24B251@apple.com> Message-ID: <437EF6FF-CD75-49A2-8D81-EA36F0CABE26@apple.com> On Sep 19, 2008, at 9:51 PM, Chris Lattner wrote: > As mentioned before Devang's proposal is not really suited for that. > The notes should be considered to be part of the LLVM IR, and > documented in langref (Devang, did you do this?). Yes, briefly. http://llvm.org/docs/LangRef.html#notes - Devang From clattner at apple.com Sun Sep 21 13:16:28 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 21 Sep 2008 11:16:28 -0700 Subject: [LLVMdev] State of CMake build system. In-Reply-To: References: Message-ID: On Sep 20, 2008, at 2:22 PM, ?scar Fuentes wrote: > IMHO, the CMake-based build system is almost complete enough to > replace > current MSVC++ project files (modulo some community review and > bug-fixing). Is this enough for adding it to the LLVM repo? Yes. >> From the point of view of a MSVC++ user, the new build system is >> trivial > to maintain: you can add a new library or tool executable in less time > that it takes to open the project file on MSVC++, it covers VC++ 2003, > 2005 and 2008, generating project files or NMake makefiles on demand > and > it just requires a text editor for maintenance. This sounds great. I think the right approach is to check it in, and then give the people with a stake in windows development a chance to try it out. Assuming it works well (i.e., it is an improvement over the existing project files), we can then nuke the windows project files. Eventually, it would be great to keep extending it to support development on every platform, maybe we can kill off the xcode project files and even the makefiles someday. Thanks for working on this ?scar! -Chris From abergeron at gmail.com Sun Sep 21 13:28:57 2008 From: abergeron at gmail.com (Arnaud Bergeron) Date: Sun, 21 Sep 2008 14:28:57 -0400 Subject: [LLVMdev] OpenBSD port in progress In-Reply-To: References: Message-ID: Since the initial mail, I found out that gcc doesn't like amd64/X86_64. I made a table of versions and the problems encountered 3.3.5 (any optimization): it does to "llvm[3]: Building ARM.td instruction selector implementation with tblgen", then tblgen crashes [1] 4.2.0 (-O0): 2 failures in tests 4.2.0 (-O1): it goes to "llvm[3]: Building ARM.td instruction selector implementation with tblgen", then tblgen crashes[1] 4.2.0 (-O2): random parts of the tests fail 4.2.0 (-O3): 2 failures in tests (the same as with -O1) [1] the crash log for tblgen assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node type!"" failed: file "CodeGenDAGPatterns.cpp", line 932, function "ApplyTypeConstraints" gmake[3]: *** [/usr/ports/mystuff/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target/ARM/Release/ARMGenInstrInfo.inc.tmp] Abort trap (core dumped) If anybody has an idea of how to fix this (other than using another version of gcc because I am sick of compiling), I would appreciate. I can offer backtraces or shell access if anybody is interested, just ask me what you need. Arnaud From shap at eros-os.com Sun Sep 21 13:34:42 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Sun, 21 Sep 2008 14:34:42 -0400 Subject: [LLVMdev] State of CMake build system. In-Reply-To: References: Message-ID: <1222022082.19619.7.camel@shaptop.om-md.eros-os.com> On Sun, 2008-09-21 at 11:16 -0700, Chris Lattner wrote: > Thanks for working on this ?scar! >From me as well. In fact, your success at this has me looking again at CMake for some other things as well. shap From shap at eros-os.com Sun Sep 21 13:45:37 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Sun, 21 Sep 2008 14:45:37 -0400 Subject: [LLVMdev] Misunderstanding vector Message-ID: <1222022737.19619.15.camel@shaptop.om-md.eros-os.com> I was re-reading the specification for extractelement and friends, and I notice that the index is restricted to i32. Since vectors might clearly have a larger number of elements on 64-bit platforms, I wonder if I am misunderstanding the intended use of these instructions. Is this indeed intended for vector and structure access in general, or is intended to support (only) more specialized SIMD usage? My real reason for asking is that we would like to remove the "Word" type (basically: uintptr_t) from the BitC language core, but we currently specify arrays and vectors as indexed by Word. If we can get away with specifying the same core type for indices (probably int64) on all targets without a bad efficiency compromise, I would like to do that, so I'm trying to understand how LLVM handles this issue. Thanks shap From asl at math.spbu.ru Sun Sep 21 13:57:58 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 21 Sep 2008 22:57:58 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?T3BlbkJTRCBwb3J0IGluIHByb2dyZXNz?= Message-ID: <200809211857.m8LIvwOS049538@star.math.spbu.ru> Hello, > If anybody has an idea of how to fix this (other than using another > version of gcc because I am sick of compiling), I would appreciate. I > can offer backtraces or shell access if anybody is interested, just > ask me what you need. This was fixed couple of months ago. Please consider using current svn top of tree, not 2.3 release. -- WBR, Anton Korobeynikov From abergeron at gmail.com Sun Sep 21 14:09:23 2008 From: abergeron at gmail.com (Arnaud Bergeron) Date: Sun, 21 Sep 2008 15:09:23 -0400 Subject: [LLVMdev] OpenBSD port in progress In-Reply-To: <200809211857.m8LIvwOS049538@star.math.spbu.ru> References: <200809211857.m8LIvwOS049538@star.math.spbu.ru> Message-ID: 2008/9/21 Anton Korobeynikov : > Hello, > >> If anybody has an idea of how to fix this (other than using another >> version of gcc because I am sick of compiling), I would appreciate. I >> can offer backtraces or shell access if anybody is interested, just >> ask me what you need. > This was fixed couple of months ago. Please consider using current svn > top of tree, not 2.3 release. I'll try this for myself, but the official ports policy is to use stable releases. > -- > WBR, Anton Korobeynikov > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From ofv at wanadoo.es Sun Sep 21 14:16:40 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Sun, 21 Sep 2008 21:16:40 +0200 Subject: [LLVMdev] State of CMake build system. References: <1222022082.19619.7.camel@shaptop.om-md.eros-os.com> Message-ID: <4p49s413.fsf@telefonica.net> "Jonathan S. Shapiro" writes: > On Sun, 2008-09-21 at 11:16 -0700, Chris Lattner wrote: >> Thanks for working on this ?scar! > >>From me as well. In fact, your success at this has me looking again at > CMake for some other things as well. You're welcome, guys. -- Oscar From clattner at apple.com Sun Sep 21 14:49:18 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 21 Sep 2008 12:49:18 -0700 Subject: [LLVMdev] Misunderstanding vector In-Reply-To: <1222022737.19619.15.camel@shaptop.om-md.eros-os.com> References: <1222022737.19619.15.camel@shaptop.om-md.eros-os.com> Message-ID: <404C8FA4-C5C3-4118-B61F-E4009CE18BC1@apple.com> On Sep 21, 2008, at 11:45 AM, Jonathan S. Shapiro wrote: > I was re-reading the specification for extractelement and friends, > and I > notice that the index is restricted to i32. Since vectors might > clearly > have a larger number of elements on 64-bit platforms, I wonder if I am > misunderstanding the intended use of these instructions. > > Is this indeed intended for vector and structure access in general, or > is intended to support (only) more specialized SIMD usage? They are intended for SIMD usage. You will get very poor performance if you try to use extremely large vectors with LLVM. Use arrays instead. -Chris From samuraileumas at yahoo.com Sun Sep 21 18:44:07 2008 From: samuraileumas at yahoo.com (Samuel Crow) Date: Sun, 21 Sep 2008 16:44:07 -0700 (PDT) Subject: [LLVMdev] OpenBSD port in progress In-Reply-To: Message-ID: <194944.73846.qm@web62004.mail.re1.yahoo.com> LLVM 2.4 should be available in a month (October 30) according to the schedule on the LLVM website. --- On Sun, 9/21/08, Arnaud Bergeron wrote: > From: Arnaud Bergeron > Subject: Re: [LLVMdev] OpenBSD port in progress > To: "Anton Korobeynikov" , "LLVM Developers Mailing List" > Date: Sunday, September 21, 2008, 2:09 PM > 2008/9/21 Anton Korobeynikov : > > Hello, > > > >> If anybody has an idea of how to fix this (other > than using another > >> version of gcc because I am sick of compiling), I > would appreciate. I > >> can offer backtraces or shell access if anybody is > interested, just > >> ask me what you need. > > This was fixed couple of months ago. Please consider > using current svn > > top of tree, not 2.3 release. > > I'll try this for myself, but the official ports policy > is to use > stable releases. > > > -- > > WBR, Anton Korobeynikov > > _______________________________________________ > > 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 edilee at gmail.com Sun Sep 21 18:46:56 2008 From: edilee at gmail.com (Edward Lee) Date: Sun, 21 Sep 2008 18:46:56 -0500 Subject: [LLVMdev] Disappearing Machine Basic Blocks (for new instruction) In-Reply-To: <4B84092A-B8E3-4C5B-B6A5-FB32804CF809@apple.com> References: <4B84092A-B8E3-4C5B-B6A5-FB32804CF809@apple.com> Message-ID: On Fri, Sep 19, 2008 at 7:11 PM, Evan Cheng wrote: > please figure out which pass deleted the block It seems like it was MachineBasicBlock::CorrectExtraCFGEdges that eventually removed the successor link, and that method was conditionally called after checking X86InstrInfo::AnalyzeBranch in the branch folder. Setting my instruction to be branch-like in X86InstrInfo.td makes the 2 target blocks stay around. Ed From evan.cheng at apple.com Mon Sep 22 02:00:27 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 22 Sep 2008 00:00:27 -0700 Subject: [LLVMdev] Illegal pointer type In-Reply-To: References: <16e5fdf90809181608m5ba8abd3u17c1119f6b4422d3@mail.gmail.com> <496E0559-D0B3-4564-9FFC-E898F3458BAB@apple.com> Message-ID: <0101B424-5B90-4C03-B13F-911783AD3B4C@apple.com> On Sep 20, 2008, at 7:12 AM, Sanjiv.Gupta at microchip.com wrote: >> I am assuming a 16-bit value will be stored in a pair of 8-bit >> registers? > > One related question is how to make sure that the correct register > pair is allocated to the16-bit quantity when using two 8-bit > operations. > In other words, how we can make sure that the 16-bit pointer is > stored into [AH, AL] and not in [AH, BL] ? By using pseudo i16 registers which map to legal pairs [AH, AL]. That is, you can specify a pseudo register AX and it has sub-registers AH, AL. Evan > > > i.e. > GR8 = [ AH, BH, AL, BL]; > GR16 = [AX, BX] ; // AX, BX are subreg pairs of ah,al and bh, bl > > the DAG looks like Wrapper:i16 (GR16) = MoveToHi:i8 (GR8) , > MoveToLo:i8 (GR8) > > Now how to make sure that if MoveToHi gets AH , then > 1. MoveToLo should get AL, > 2. the Wrapper should get AX > > - Sanjiv > > > On Sep 19, 2008, at 5:01 AM, Sachin.Punyani at microchip.com wrote: > >> >> >>> -----Original Message----- >>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >>> bounces at cs.uiuc.edu] >> On >>> Behalf Of Bill Wendling >>> Sent: Friday, September 19, 2008 4:38 AM >>> >>> On Thu, Sep 18, 2008 at 7:12 AM, >> wrote: >>>> What changes would be required in LLVM to support illegal pointer >> type? >>>> >>> Hi Sachin, >>> >>> The question's a bit broad. And I don't think the answer you want is >>> as simple as "don't run the legalizer" (which probably won't work). >>> Do >>> you have a more specific question? >> >> I am trying to ask a broad question. My target has 16 bit pointers >> but >> register size is 8 bit only. What changes in LLVM would be required >> to >> support 16 bit pointers on 8 bit registers? >> >> Regards >> Sachin >> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From baldrick at free.fr Mon Sep 22 02:42:38 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 22 Sep 2008 09:42:38 +0200 Subject: [LLVMdev] Misunderstanding vector In-Reply-To: <1222022737.19619.15.camel@shaptop.om-md.eros-os.com> References: <1222022737.19619.15.camel@shaptop.om-md.eros-os.com> Message-ID: <200809220942.39163.baldrick@free.fr> On Sunday 21 September 2008 20:45:37 Jonathan S. Shapiro wrote: > I was re-reading the specification for extractelement and friends, and I > notice that the index is restricted to i32. Since vectors might clearly > have a larger number of elements on 64-bit platforms, I wonder if I am > misunderstanding the intended use of these instructions. The code generator cannot handle vectors with more than 16383 (?) elements. Even so, I'm not sure it makes much sense to use vectors with more than a handful of elements. Ciao, Duncan. From shap at eros-os.com Mon Sep 22 07:12:56 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Mon, 22 Sep 2008 08:12:56 -0400 Subject: [LLVMdev] Misunderstanding vector In-Reply-To: <200809220942.39163.baldrick@free.fr> References: <1222022737.19619.15.camel@shaptop.om-md.eros-os.com> <200809220942.39163.baldrick@free.fr> Message-ID: <1222085579.5239.0.camel@shaptop.om-md.eros-os.com> On Mon, 2008-09-22 at 09:42 +0200, Duncan Sands wrote: > On Sunday 21 September 2008 20:45:37 Jonathan S. Shapiro wrote: > > I was re-reading the specification for extractelement and friends, and I > > notice that the index is restricted to i32. Since vectors might clearly > > have a larger number of elements on 64-bit platforms, I wonder if I am > > misunderstanding the intended use of these instructions. > > The code generator cannot handle vectors with more than 16383 (?) > elements. Even so, I'm not sure it makes much sense to use vectors > with more than a handful of elements. I understood Chris to say that these instructions were for SIMD machines, and if the limit you mention applies to SIMD I'm not worried. Does that limit also apply to arrays? shap From baldrick at free.fr Mon Sep 22 07:29:13 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 22 Sep 2008 14:29:13 +0200 Subject: [LLVMdev] Misunderstanding vector In-Reply-To: <1222085579.5239.0.camel@shaptop.om-md.eros-os.com> References: <1222022737.19619.15.camel@shaptop.om-md.eros-os.com> <200809220942.39163.baldrick@free.fr> <1222085579.5239.0.camel@shaptop.om-md.eros-os.com> Message-ID: <200809221429.13214.baldrick@free.fr> > > The code generator cannot handle vectors with more than 16383 (?) > > elements. Even so, I'm not sure it makes much sense to use vectors > > with more than a handful of elements. > > I understood Chris to say that these instructions were for SIMD > machines, and if the limit you mention applies to SIMD I'm not worried. > Does that limit also apply to arrays? No it doesn't, it is vector specific. There may be limits on arrays, but I don't know what they are. Ciao, Duncan. From matthijs at stdin.nl Mon Sep 22 09:33:38 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Mon, 22 Sep 2008 16:33:38 +0200 Subject: [LLVMdev] Doxygen Updated In-Reply-To: References: Message-ID: <20080922143338.GI15228@katherina.student.utwente.nl> Hi Tanya, > I've upgraded our doxygen to 1.5.6. Please let me know if you see any > problems. I think the doxygen.css in the repository is no longer consistent with the HTML emitted by Doxygen. I'm not sure how it was before and in which doxygen version the HTML changed, though. What I am seeing now is that the list of member descriptions on a class page all have the same font size (both prototypes, descriptions and headers) and no visual cues as to where one stops and the next one begins. I'm not sure what LLVM-specific changes were made to the css file, but it might make sense to just start afresh with Doxygen's default css file again. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080922/6498ee8a/attachment.bin From clattner at apple.com Mon Sep 22 10:41:30 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 08:41:30 -0700 Subject: [LLVMdev] Misunderstanding vector In-Reply-To: <200809221429.13214.baldrick@free.fr> References: <1222022737.19619.15.camel@shaptop.om-md.eros-os.com> <200809220942.39163.baldrick@free.fr> <1222085579.5239.0.camel@shaptop.om-md.eros-os.com> <200809221429.13214.baldrick@free.fr> Message-ID: On Sep 22, 2008, at 5:29 AM, Duncan Sands wrote: >>> The code generator cannot handle vectors with more than 16383 (?) >>> elements. Even so, I'm not sure it makes much sense to use vectors >>> with more than a handful of elements. >> >> I understood Chris to say that these instructions were for SIMD >> machines, and if the limit you mention applies to SIMD I'm not >> worried. >> Does that limit also apply to arrays? > > No it doesn't, it is vector specific. There may be limits on > arrays, but > I don't know what they are. Arrays can be up to 2^63 in size if I recall. -Chris From yonggangluo at hotmail.com Mon Sep 22 12:36:51 2008 From: yonggangluo at hotmail.com (=?gb2312?B?wt7TwrjV?=) Date: Tue, 23 Sep 2008 01:36:51 +0800 Subject: [LLVMdev] A question. Message-ID: I found that LLVM were using Binutils to assemble the Assembly Code to the Machine Code, so I have a question, why LLVM don't direct generate the machine code? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080923/b7e42591/attachment.html From bergner at vnet.ibm.com Mon Sep 22 13:19:11 2008 From: bergner at vnet.ibm.com (Peter Bergner) Date: Mon, 22 Sep 2008 13:19:11 -0500 Subject: [LLVMdev] Chaitin/Briggs register allocator Message-ID: <1222107551.9520.8.camel@sjoa> I seem to recall that LLVM had a Chaitin/Briggs register allocator, but looking at today's source, I only see a Linear Scan and some basic block allocators. Does anyone know if a Chaitin/Briggs allocator for LLVM exists and is available? Peter From evan.cheng at apple.com Mon Sep 22 13:43:03 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 22 Sep 2008 11:43:03 -0700 Subject: [LLVMdev] Chaitin/Briggs register allocator In-Reply-To: <1222107551.9520.8.camel@sjoa> References: <1222107551.9520.8.camel@sjoa> Message-ID: There isn't one available to the public as far as I know. Evan On Sep 22, 2008, at 11:19 AM, Peter Bergner wrote: > I seem to recall that LLVM had a Chaitin/Briggs register allocator, > but looking > at today's source, I only see a Linear Scan and some basic block > allocators. > Does anyone know if a Chaitin/Briggs allocator for LLVM exists and > is available? > > Peter > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Mon Sep 22 14:12:31 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 22 Sep 2008 12:12:31 -0700 Subject: [LLVMdev] Run-time optimization using profile data In-Reply-To: References: <19588300.post@talk.nabble.com> Message-ID: <0A050A46-5E84-4454-ABA4-0B6CFA248E06@apple.com> On Sep 20, 2008, at 3:28 PM, Eli Friedman wrote: > >> 5. I would then like to have control over the JIT as well. In the >> above >> LLVM->LLVM transform, I would have placed some "special" >> instructions (like >> maybe illegal opcodes, or something like that), and once the JIT is >> about to >> translate those, my routine should get called. I will then >> transform those >> instructions into "special" native instructions. > > You want to have the JIT recompile the code as it's running? The JIT > doesn't currently support that, and it's relatively tricky to write. You are not the first user of JIT that wants something like this. There is definite interests in having an alternative call back mechanism. I think there are two issues: 1. Replace the default lazy compilation callback, e.g. see X86JITInfo.cpp: static TargetJITInfo::JITCompilerFn JITCompilerFunction with a custom one that can run dynamic optimization passes which make use of the profile data. 2. Add custom logic to determine when a call instruction is replaced with a call to a stub which would in turn invoke the compilation callback. Evan > > > Messing with code generation to add platform-specific intrinsics isn't > too hard; you'd need to provide more details to say anything specific, > though. > >> 6. I then want to execute the newly written binary and remove profile >> instrumentation, but leave my special native instructions intact. > > Stripping out the instrumentation should be a very simple > transformation pass. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From vadve at cs.uiuc.edu Mon Sep 22 14:22:07 2008 From: vadve at cs.uiuc.edu (Vikram S. Adve) Date: Mon, 22 Sep 2008 14:22:07 -0500 Subject: [LLVMdev] Some thoughts on metadata, debug info, TBAA, annotations etc In-Reply-To: References: Message-ID: <87A8032C-2335-4C1B-815C-AFD1CD31D98A@cs.uiuc.edu> Having a clean mechanism for TBAA would be valuable (long term) for our parallelization project. Different high-level parallel languages have rich "non-aliasing" information available, usually encoded (or encodable) as pointer types, and we would like to be able to communicate these down to the LLVM passes. --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Sep 19, 2008, at 11:12 PM, Chris Lattner wrote: > Hi All, > > I'd like to propose some extensions to LLVM that will make it > substantially faster at manipulating debug info, and will make the > general annotation mechanisms in LLVM much richer: > http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt > > Thoughts welcome, > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gordonhenriksen at me.com Mon Sep 22 16:12:43 2008 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Mon, 22 Sep 2008 17:12:43 -0400 Subject: [LLVMdev] A question. In-Reply-To: References: Message-ID: On Sep 22, 2008, at 13:36, ??? wrote: > I found that LLVM were using Binutils to assemble the Assembly Code > to the Machine Code, so I have a question, why LLVM don't direct > generate the machine code? There was a protracted and rather uninteresting discussion of this matter on this list some months ago. I'll summarize the outcome of that thread briefly: LLVM does generate machine code directly in the JIT. For static compilation, no contributor has felt the need to eliminate the dependency on an external assembler. Why is this? First and foremost, an LLVM assembler would not materially advance the state of the art. At the same time, it would require significant platform- specific knowledge to author. It could easily constitute a considerable maintenance burden. On Windows, where an assembler is not generally installed, a built-in assembler would be seen by some as a valuable component. However, when distributing a static compiler, bundling an assembler with it is a perfectly reasonable option. If GPL licensing is an issue, consult a lawyer. But I do observe that many closed-source compilers exist which use the system assembler, which is often gas. There do exist partial implementations of direct machine code generators if you find this to be an area important enough to contribute. You can find them in lib/CodeGen/{ELF,MachO}Writer.cpp. Please review the list archives if you want more detail. -- Gordon From gohman at apple.com Mon Sep 22 16:35:12 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 22 Sep 2008 14:35:12 -0700 Subject: [LLVMdev] DOTGraphTraits and GraphWriter In-Reply-To: <85a4cc050809161458i42dfa5c8ha1c99a3afc29dc34@mail.gmail.com> References: <85a4cc050809151515i3b088f6awc5265c0b979c6767@mail.gmail.com> <6F91F79D-EC28-4E7D-929A-7A1EF20BED78@apple.com> <85a4cc050809161458i42dfa5c8ha1c99a3afc29dc34@mail.gmail.com> Message-ID: <4E344738-286A-45BB-88DC-505ACAA18FC7@apple.com> Hi Prakash, I don't know of an easy way to do this, other than to use random-access iterators so you can compute the distance between the edge and the beginning of the list of edges. Dan On Sep 16, 2008, at 2:58 PM, Prakash Prabhu wrote: > Hi Dan, > > Thanks for the reply. I got the labels for each outgoing edge (at the > source node's 'structure' field) working. Is there a way to find out > the outgoing edge number from EdgeIter. (Basically the Node in my > graph has a a bunch of outgoing edges, so that I can just index into > that collection within the node to get the appropriate edges' > attributes). > > regards, > Prakash > > On Tue, Sep 16, 2008 at 3:59 PM, Dan Gohman wrote: >> Hello Prakash, >> >> The SelectionDAG viewers (llc -view-isel-dags etc.) support >> both multiple edges between the same pair of nodes, and labels >> at least for each incoming edge. See >> lib/CodeGen/SelectionDAG/SelectionDAGPrinter.cpp for code you >> might use as an example, though it is a bit tricky. >> >> Dan >> >> On Sep 15, 2008, at 3:15 PM, Prakash Prabhu wrote: >> >>> Hi all, >>> >>> I have two questions related to .dot graph output. Basically, I >>> have a >>> graph representing a program dependence graph like structure with >>> (a) multiple edges between the same pair of nodes >>> (b) each edge having a special (different) text/label >>> >>> I implemented a template-specialized version of DotGraphTraits for >>> the >>> my graph structure which given a node, uses a map_iterator >>> (similar to >>> the one used in CallGraph) to get the destination node of an >>> outgoing >>> edge. This works fine except that I have no clue how to support (a) >>> and (b) since once the destination node is returned I lose access to >>> the edge and cannot do any text annotation onto an edge of the >>> graph. >>> >>> Is there some other way to achieve (a) and (b) without having to >>> implement my own special version of GraphWriter ? >>> >>> thanks, >>> Prakash >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gohman at apple.com Mon Sep 22 16:50:49 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 22 Sep 2008 14:50:49 -0700 Subject: [LLVMdev] Overzealous PromoteCastOfAllocation In-Reply-To: <20080913200716.GF9093@katherina.student.utwente.nl> References: <20080908155737.GJ32157@katherina.student.utwente.nl> <643C9D81-4750-48E5-B26C-C7699B04065B@apple.com> <20080913200716.GF9093@katherina.student.utwente.nl> Message-ID: On Sep 13, 2008, at 1:07 PM, Matthijs Kooijman wrote: > Hi Dan, > >> Changing PromoteCastOfAllocation to not replace aggregate allocas >> with >> non-aggregate allocas if they have GEP users sounds reasonable to me. > This sounds reasonable indeed, but still a bit arbitrary. Haven't > figured out > anything better yet, though. > >> Finding the maximum alignment is sometimes still useful though, so >> it would be nice to update the alignment field of the alloca even if >> its type is left unchanged. > The maximizing of the alignment is done only looking at the type's ABI > alignment, the actual alignment of the alloca instruction is not used. > > But what you suggest is that if the alloca is casted to some type > that has > higher alignment, you want that higher allignment propagated to the > alloca > instruction? I can see why this is useful, since bitcasting to a > type with > higher alignment can actually produce invalid code, I think? Or how > does this > work exactly? Oh, ok. So code that takes an alloca, bitcasts the address to a higher alignment, and then does a load or store at the higher alignment, is invoking undefined behavior. The alignment attribute on a load or store is an assertion about the actual alignment of the memory. Dan From mierle at gmail.com Mon Sep 22 16:51:59 2008 From: mierle at gmail.com (Keir Mierle) Date: Mon, 22 Sep 2008 14:51:59 -0700 Subject: [LLVMdev] LLVM sprint RFC Message-ID: Hi all, I'd like to coordinate a LLVM sprint at Google in Mountain View. I discussed this with Chris at the LLVM developers day, but didn't get around to figuring out the logistics until now. I'm emailing here to take a survey of what works best for people: 1. Pick all that work for you: weekdays, weekends, evenings. 2. Pick a time frame that you like best: October, early December, January (or later!). 3. (Optional) List a couple of items you'd like to work on. Once a general timeframe is established I'll send out a list of candidate dates. Depending on how successful the sprint is, it could be made a regular event. Note: If you're new to LLVM, that's no problem. Sprints are usually dual purpose; get useful work done and also get new developers booted. Typically this is accomplished by pairing people on tasks, where one coder is less experienced in that area than the other Thanks! Keir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080922/de701f8d/attachment.html From Micah.Villmow at amd.com Mon Sep 22 17:01:38 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Mon, 22 Sep 2008 15:01:38 -0700 Subject: [LLVMdev] Tablegen address space Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA127@ssanexmb1.amd.com> Is there a known way to get pattern matching on the address space from tablegen? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080922/bab04a8c/attachment.html From scott.llvm at h4ck3r.net Mon Sep 22 19:59:48 2008 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Mon, 22 Sep 2008 17:59:48 -0700 Subject: [LLVMdev] reload of pointers after GC Message-ID: <84decce20809221759s4192d347p507f10de954a56ac@mail.gmail.com> Hi I'm using a GC that's pretty similar to the OCaml one. It records stack locations using llvm.gcroot, and dumps out a frametable describing the live stack offsets so that the GC runtime can walk them as required. I'm on 2.3, not svn head. I'm having some trouble with pointers being cached in registers across function calls (at least x86 backend, haven't tried others yet). The steps are: 1. Allocate an array (A) in the GC heap 2. Do operations on A 3. Allocate another object (B) in the GC heap 4. Do some more operations on A (actually, pass to the constructor of B) In this case, the pointer is stored back to the stack before the call to the second allocation. During the second allocation, memory is exhausted and the collector must relocate some objects. It moves stuff around, including A, and fixes up the stack pointer to A. So, up to here, all good. But, upon returning, the pointer value isn't reloaded from the stack, and so points to (now) garbage. It seems that simply passing the address of a stack variable to any function (llvm.gcroot or otherwise) would be enough to require reloading registers after any future function call since the data could have been changed, so I'm wondering whether I'm missing something. I haven't made a standalone repro .ll yet, I just wanted to understand if this was expected or not first. Does this seem like it should be enough? Or are there extra invalidations that I need to do somewhere? thanks, scott From clattner at apple.com Mon Sep 22 23:22:59 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 21:22:59 -0700 Subject: [LLVMdev] Tablegen address space In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA127@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA127@ssanexmb1.amd.com> Message-ID: On Sep 22, 2008, at 3:01 PM, Villmow, Micah wrote: > Is there a known way to get pattern matching on the address space > from tablegen? For an addressing mode? Have you tried using a Pat pattern or ComplexPattern? These allow you to put in C++ code to check whatever you want. -Chris > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080922/232f7bfe/attachment.html From matthijs at stdin.nl Tue Sep 23 04:04:23 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Tue, 23 Sep 2008 11:04:23 +0200 Subject: [LLVMdev] Web Server Problems Persist In-Reply-To: <48D27EBA.2000107@cs.uiuc.edu> References: <48D27D0F.6070804@cs.uiuc.edu> <48D27EBA.2000107@cs.uiuc.edu> Message-ID: <20080923090423.GK15228@katherina.student.utwente.nl> Hi John, > If you run into problems, please email llvmdev. I'll periodically check > llvm.org to make sure it's still up. I'm seeing long delays on llvm.org again. Pages are served eventually, but it takes minutes for each requests. Are there any dynamic scripts on the server that can eat a lot of resources? I think the nightly tester result pages would qualify? Perhaps search engine crawlers hit the nightly tester results every now and then? I see that there is a robots.txt that should fix this, but perhaps there are other scripts missing from it? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080923/0d58b77e/attachment-0001.bin From matthijs at stdin.nl Tue Sep 23 06:16:03 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Tue, 23 Sep 2008 13:16:03 +0200 Subject: [LLVMdev] Overzealous PromoteCastOfAllocation In-Reply-To: References: <20080908155737.GJ32157@katherina.student.utwente.nl> <643C9D81-4750-48E5-B26C-C7699B04065B@apple.com> <20080913200716.GF9093@katherina.student.utwente.nl> Message-ID: <20080923111603.GL15228@katherina.student.utwente.nl> Hi Dan, > Oh, ok. So code that takes an alloca, bitcasts the address to a higher > alignment, Since alignment is not a property of a type, I don't think you can "bitcast to a higher alignment" as such. I still understand what you mean, though :-) > and then does a load or store at the higher alignment, is > invoking undefined behavior. The alignment attribute on a load or store > is an assertion about the actual alignment of the memory. Should this undefined behaviour be caught by the verifier, or is it ok for it to exist? In any case, since this behaviour is undefined, it's not quite needed for the instcombine pass to propagate the ABI alignment from a type bitcasted to upwards into the alloca instruction, as you suggested. The frontend generating the IR should have done this already when needed (when a load with that higher alignment uses the bitcasted value, or the bitcasted value is passed to another function, which requires ABI alignment). I've now created a patch that makes sure that any struct typed alloca is never changed by instcombine, unless all it's uses are bitcasts to the same type. This seems like the most sane way to do things. This change did expose some alignment-related bug in llvm-gcc, see PR2823. This means that committing preserve-struct.diff will result in a test-suite failure (at least SingleSource/UnitTests/Vector/divides, I haven't finished testing Multisource yet), but this is caused by llvm-gcc, not instcombine. Related to this issue, I've created two more patches. I'm including them here for review, comments are welcome. I'm not sure if these patches actually make a lot of difference in real world applications and they are not yet sufficient to make scalarrepl do its work completely in our example code (lots of struct passing and the resulting memmoves), but they will at least make the resulting code more logical and make it possible to get there. I've tested these patches against the dejagnu tests and the test-suite, finding only two failures. The first is the one regarding PR2823 referenced above. The second one is concerning MultiSource/Benchmarks/MiBench/security-blowfish, for some reason opt emits an invalid bitcode file (the bitcode reader asserts). From playing with the debugger, it seems a store instruction is asked to store a an i8* to an [8 x i8]*. However, since the verifier doesn't catch this before outputting the bitcode, it's probably something more involved. I'll look into this issue a bit closer later (currently I don't even know which of the three patches causes it). Anyway, review of these patches and opinions as to their usefulness would be welcome! Gr. Matthijs -------------- next part -------------- Index: test/Transforms/InstCombine/2008-09-22-small-struct-memmove.ll =================================================================== --- test/Transforms/InstCombine/2008-09-22-small-struct-memmove.ll (revision 0) +++ test/Transforms/InstCombine/2008-09-22-small-struct-memmove.ll (revision 0) @@ -0,0 +1,23 @@ +; This checks if instcombine replaces small struct memmoves with loads and +; stores of a struct, instead of using a equally sized integer. + +; RUN: llvm-as < %s | opt -instcombine | llvm-dis > %t +; Use . instead of % in grep, since %s in %struct gets replaced... +; RUN: cat %t | grep {load .struct.two*} + +%struct.two = type <{ i16, i16 }> + +; Dummy function to give %S another use below. +declare void @fill(%struct.two*) + +define void @main(%struct.two* %D) { +entry: + %S = alloca %struct.two + call void @fill (%struct.two* %S) + %tmpS = bitcast %struct.two* %S to i8* + %tmpD = bitcast %struct.two* %D to i8* + call void @llvm.memmove.i32(i8* %tmpD, i8* %tmpS, i32 4, i32 1) + ret void +} + +declare void @llvm.memmove.i32(i8*, i8*, i32, i32) nounwind Index: lib/Transforms/Scalar/InstructionCombining.cpp =================================================================== --- lib/Transforms/Scalar/InstructionCombining.cpp (revision 56433) +++ lib/Transforms/Scalar/InstructionCombining.cpp (working copy) @@ -8707,7 +8800,7 @@ break; } - if (SrcETy->isSingleValueType()) + if (SrcETy->isFirstClassType()) NewPtrTy = PointerType::getUnqual(SrcETy); } } -------------- next part -------------- Index: test/Transforms/InstCombine/2008-09-22-preserve-struct-alloca.ll =================================================================== --- test/Transforms/InstCombine/2008-09-22-preserve-struct-alloca.ll (revision 0) +++ test/Transforms/InstCombine/2008-09-22-preserve-struct-alloca.ll (revision 0) @@ -0,0 +1,27 @@ +; This checks if instcombine leaves struct alloca's intact. It used to change +; the below alloca to an alloca i32, which doesn't really make sense (and can in +; a lot of cases confuse other passes such as scalarrepl. +; Now, instcombine only touches struct alloca's when all uses are bitcasts to +; the same type. + +; RUN: llvm-as < %s | opt -instcombine | llvm-dis > %t +; RUN: cat %t | grep {alloca .struct.two} + +%struct.two = type <{ i16, i16 }> + +; Dummy function to give %S another use below. +declare void @fill(%struct.two*) + +define void @main(%struct.two* %D) { +entry: + %S = alloca %struct.two + call void @fill (%struct.two* %S) + ; Copy %S to %D byt loading and storing an i32. This is written this way + ; to lure instcombine into replacing the alloca above with an alloca + ; i32. + %tmpS = bitcast %struct.two* %S to i32* + %tmpD = bitcast %struct.two* %D to i32* + %val = load i32* %tmpS + store i32 %val, i32* %tmpD + ret void +} Index: lib/Transforms/Scalar/InstructionCombining.cpp =================================================================== --- lib/Transforms/Scalar/InstructionCombining.cpp (revision 56433) +++ lib/Transforms/Scalar/InstructionCombining.cpp (working copy) @@ -6946,6 +6951,17 @@ // increasing the alignment of the resultant allocation. If we keep it the // same, we open the door to infinite loops of various kinds. if (!AI.hasOneUse() && CastElTyAlign == AllocElTyAlign) return 0; + + // If the allocation has a struct type and has other uses than casts to + // PTy, don't change the alloca. Changing it would prevent passes like + // scalarrepl from doing their work later on. + if (!AI.hasOneUse() && isa(AllocElTy)) + for (Value::use_iterator UI = AI.use_begin(), UE = AI.use_end(); + UI != UE; ++UI) { + CastInst *CI = dyn_cast(UI); + if (!CI || CI->getDestTy() != PTy) + return 0; + } uint64_t AllocElTySize = TD->getABITypeSize(AllocElTy); uint64_t CastElTySize = TD->getABITypeSize(CastElTy); -------------- next part -------------- Index: test/Transforms/ScalarRepl/2008-09-22-vector-gep.ll =================================================================== --- test/Transforms/ScalarRepl/2008-09-22-vector-gep.ll (revision 0) +++ test/Transforms/ScalarRepl/2008-09-22-vector-gep.ll (revision 0) @@ -0,0 +1,24 @@ +; This test checks to see if scalarrepl also works when a gep with all zeroes is +; used instead of a bitcast to prepare a memmove pointer argument. Previously, +; this would not work when there was a vector involved in the struct, preventing +; scalarrepl from removing the alloca below. + +; RUN: llvm-as < %s | opt -scalarrepl | llvm-dis > %t +; RUN: cat %t | not grep alloca + +%struct.two = type <{ < 2 x i8 >, i16 }> + +define void @main(%struct.two* %D, i16 %V) { +entry: + %S = alloca %struct.two + %S.2 = getelementptr %struct.two* %S, i32 0, i32 1 + store i16 %V, i16* %S.2 + ; This gep is effectively a bitcast to i8*, but is sometimes generated + ; because the type of the first element in %struct.two is i8. + %tmpS = getelementptr %struct.two* %S, i32 0, i32 0, i32 0 + %tmpD = bitcast %struct.two* %D to i8* + call void @llvm.memmove.i32(i8* %tmpD, i8* %tmpS, i32 4, i32 1) + ret void +} + +declare void @llvm.memmove.i32(i8*, i8*, i32, i32) nounwind Index: lib/Transforms/Scalar/ScalarReplAggregates.cpp =================================================================== --- lib/Transforms/Scalar/ScalarReplAggregates.cpp (revision 56433) +++ lib/Transforms/Scalar/ScalarReplAggregates.cpp (working copy) @@ -530,8 +530,9 @@ return MarkUnsafe(Info); } } + + bool hasVector = false; - // Walk through the GEP type indices, checking the types that this indexes // into. for (; I != E; ++I) { @@ -539,22 +540,29 @@ if (isa(*I)) continue; - // Don't SROA pointers into vectors. - if (isa(*I)) - return MarkUnsafe(Info); - - // Otherwise, we must have an index into an array type. Verify that this is - // an in-range constant integer. Specifically, consider A[0][i]. We - // cannot know that the user isn't doing invalid things like allowing i to - // index an out-of-range subscript that accesses A[1]. Because of this, we - // have to reject SROA of any accesses into structs where any of the - // components are variables. ConstantInt *IdxVal = dyn_cast(I.getOperand()); if (!IdxVal) return MarkUnsafe(Info); - if (IdxVal->getZExtValue() >= cast(*I)->getNumElements()) + + // Are all indices still zero? + IsAllZeroIndices &= IdxVal->isZero(); + + if (isa(*I)) { + // Otherwise, we must have an index into an array type. Verify that this is + // an in-range constant integer. Specifically, consider A[0][i]. We + // cannot know that the user isn't doing invalid things like allowing i to + // index an out-of-range subscript that accesses A[1]. Because of this, we + // have to reject SROA of any accesses into structs where any of the + // components are variables. + if (IdxVal->getZExtValue() >= cast(*I)->getNumElements()) + return MarkUnsafe(Info); + } + + // Note if we've seen a vector type yet + hasVector |= isa(*I); + + // Don't SROA pointers into vectors, unless all indices are zero. + if (hasVector && !IsAllZeroIndices) return MarkUnsafe(Info); - - IsAllZeroIndices &= IdxVal->isZero(); } // If there are any non-simple uses of this getelementptr, make sure to reject @@ -661,6 +669,11 @@ // It is likely that OtherPtr is a bitcast, if so, remove it. if (BitCastInst *BC = dyn_cast(OtherPtr)) OtherPtr = BC->getOperand(0); + // All zero GEPs are effectively casts + if (GetElementPtrInst *GEP = dyn_cast(OtherPtr)) + if (GEP->hasAllZeroIndices()) + OtherPtr = GEP->getOperand(0); + if (ConstantExpr *BCE = dyn_cast(OtherPtr)) if (BCE->getOpcode() == Instruction::BitCast) OtherPtr = BCE->getOperand(0); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080923/a03107a9/attachment.bin From sanjiv.gupta at microchip.com Tue Sep 23 06:52:38 2008 From: sanjiv.gupta at microchip.com (sanjiv gupta) Date: Tue, 23 Sep 2008 17:22:38 +0530 Subject: [LLVMdev] A question about instruction operands. In-Reply-To: References: Message-ID: <1222170758.3156.6.camel@idc-lt-i00171.microchip.com> I have a question: In the pattern below from X86 def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), "inc{b}\tdst", [(set GR8:$dst, (add GR8:$src, 1))]>; Since we are emitting only "inc $dst", What makes sure that the $src and $dst are same register? - Sanjiv From rlsosborne at googlemail.com Tue Sep 23 07:33:15 2008 From: rlsosborne at googlemail.com (Richard Osborne) Date: Tue, 23 Sep 2008 13:33:15 +0100 Subject: [LLVMdev] A question about instruction operands. In-Reply-To: <1222170758.3156.6.camel@idc-lt-i00171.microchip.com> References: <1222170758.3156.6.camel@idc-lt-i00171.microchip.com> Message-ID: <48D8E20B.5010509@googlemail.com> sanjiv gupta wrote: > I have a question: > In the pattern below from X86 > > def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), > "inc{b}\tdst", > [(set GR8:$dst, (add GR8:$src, 1))]>; > > Since we are emitting only "inc $dst", > What makes sure that the $src and $dst are same register? > > - Sanjiv It's enclosed inside : let isTwoAddress = 1 in { ... } (you'll need to scroll up a fair amount to find this). Richard From sanjiv.gupta at microchip.com Tue Sep 23 07:55:16 2008 From: sanjiv.gupta at microchip.com (sanjiv gupta) Date: Tue, 23 Sep 2008 18:25:16 +0530 Subject: [LLVMdev] A question about instruction operands. In-Reply-To: <48D8E20B.5010509@googlemail.com> References: <1222170758.3156.6.camel@idc-lt-i00171.microchip.com> <48D8E20B.5010509@googlemail.com> Message-ID: <1222174516.3156.15.camel@idc-lt-i00171.microchip.com> On Tue, 2008-09-23 at 13:33 +0100, Richard Osborne wrote: > sanjiv gupta wrote: > > I have a question: > > In the pattern below from X86 > > > > def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), > > "inc{b}\tdst", > > [(set GR8:$dst, (add GR8:$src, 1))]>; > > > > Since we are emitting only "inc $dst", > > What makes sure that the $src and $dst are same register? > > > > - Sanjiv > It's enclosed inside : > > let isTwoAddress = 1 in { > ... > } > > (you'll need to scroll up a fair amount to find this). > That means, it gets converted to dst = src; dst = dst + 1; Right ? - Sanjiv > Richard > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From criswell at uiuc.edu Tue Sep 23 07:56:12 2008 From: criswell at uiuc.edu (John Criswell) Date: Tue, 23 Sep 2008 07:56:12 -0500 Subject: [LLVMdev] Bulk Download: Please Stop Message-ID: <48D8E76C.3040504@uiuc.edu> Dear All, Someone (hopefully one of you) is doing a mass download of materials from llvm.org. Mass downloads are generally fine, but in this case, they're hitting the server so hard that it's using all available Apache processes, preventing access by other LLVM users. Since these accesses appear legitimate, I assume that there is no ill intent. However, these accesses are, in fact, creating a Denial of Service for everyone else. If this is you, *please* throttle back your download program or terminate it. Also, your download program appears broken because you're downloading the same files over and over again. To everyone else, since the web server isn't responding to the community at large, I'm going to restart it to kill off connections from this bulk download. Thanks. -- John T. From rlsosborne at googlemail.com Tue Sep 23 08:30:21 2008 From: rlsosborne at googlemail.com (Richard Osborne) Date: Tue, 23 Sep 2008 14:30:21 +0100 Subject: [LLVMdev] A question about instruction operands. In-Reply-To: <1222174516.3156.15.camel@idc-lt-i00171.microchip.com> References: <1222170758.3156.6.camel@idc-lt-i00171.microchip.com> <48D8E20B.5010509@googlemail.com> <1222174516.3156.15.camel@idc-lt-i00171.microchip.com> Message-ID: <48D8EF6D.60509@googlemail.com> sanjiv gupta wrote: > On Tue, 2008-09-23 at 13:33 +0100, Richard Osborne wrote: > >> sanjiv gupta wrote: >> >>> I have a question: >>> In the pattern below from X86 >>> >>> def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), >>> "inc{b}\tdst", >>> [(set GR8:$dst, (add GR8:$src, 1))]>; >>> >>> Since we are emitting only "inc $dst", >>> What makes sure that the $src and $dst are same register? >>> >>> - Sanjiv >>> >> It's enclosed inside : >> >> let isTwoAddress = 1 in { >> ... >> } >> >> (you'll need to scroll up a fair amount to find this). >> >> > That means, it gets converted to > dst = src; > dst = dst + 1; > > Right ? > > - Sanjiv > Yes, I believe the two address instruction pass performs exactly this transformation. Richard From gordonhenriksen at me.com Tue Sep 23 08:39:04 2008 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Tue, 23 Sep 2008 09:39:04 -0400 Subject: [LLVMdev] reload of pointers after GC In-Reply-To: <84decce20809221759s4192d347p507f10de954a56ac@mail.gmail.com> References: <84decce20809221759s4192d347p507f10de954a56ac@mail.gmail.com> Message-ID: Hi Scott, On Sep 22, 2008, at 20:59, Scott Graham wrote: > I'm using a GC that's pretty similar to the OCaml one. It records > stack locations using llvm.gcroot, and dumps out a frametable > describing the live stack offsets so that the GC runtime can walk > them as required. I'm on 2.3, not svn head. > > I'm having some trouble with pointers being cached in registers > across function calls (at least x86 backend, haven't tried others > yet). Are you reusing the same SSA variables, or reloading from the gcroot? Copying collectors require that you reload before each use (or, more specifically, between each call that could invoke the collector). e.g., ; object obj; %root = alloca call void llvm.gcroot(%root) ; obj = new Object; %obj.1 = gcalloc() store %obj.1 -> %obj.root ; danger(); // Could invoke the collector! call void danger() ; use(obj); %obj.2 = load %obj.root call void use(%obj.2) ; Not %obj.1! ; danger(); // Could invoke the collector! call void danger() ; use(obj); %obj.3 = load %obj.root call void use(%obj.3) ; Not %obj.2! Of particular danger is that naive code generation for something like f(obj, g()) would retain an SSA value for obj over the call to g(). > It seems that simply passing the address of a stack variable to any > function (llvm.gcroot or otherwise) That's the basis for the llvm.gcroot model. > I haven't made a standalone repro .ll yet This would be helpful. ? Gordon From Sanjiv.Gupta at microchip.com Tue Sep 23 11:05:37 2008 From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com) Date: Tue, 23 Sep 2008 09:05:37 -0700 Subject: [LLVMdev] A question about instruction operands. In-Reply-To: <48D8EF6D.60509@googlemail.com> References: <1222170758.3156.6.camel@idc-lt-i00171.microchip.com> <48D8E20B.5010509@googlemail.com><1222174516.3156.15.camel@idc-lt-i00171.microchip.com> <48D8EF6D.60509@googlemail.com> Message-ID: > >>> > >> It's enclosed inside : > >> > >> let isTwoAddress = 1 in { > >> ... > >> } > >> > >> (you'll need to scroll up a fair amount to find this). > >> > >> > > That means, it gets converted to > > dst = src; > > dst = dst + 1; > > > > Right ? > > > > - Sanjiv > > > Yes, I believe the two address instruction pass performs exactly this > transformation. > Thanks. How do I communicate if my CopyRegToReg instruction clobbers a register of another register class? Is it through let Defs = [REG] { ... } while defining the instr pattern? - Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tonic at nondot.org Tue Sep 23 11:33:14 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 23 Sep 2008 09:33:14 -0700 (PDT) Subject: [LLVMdev] Web Server Problems Persist In-Reply-To: <20080923090423.GK15228@katherina.student.utwente.nl> References: <48D27D0F.6070804@cs.uiuc.edu> <48D27EBA.2000107@cs.uiuc.edu> <20080923090423.GK15228@katherina.student.utwente.nl> Message-ID: >> If you run into problems, please email llvmdev. I'll periodically check >> llvm.org to make sure it's still up. > I'm seeing long delays on llvm.org again. Pages are served eventually, but it > takes minutes for each requests. > > Are there any dynamic scripts on the server that can eat a lot of resources? I > think the nightly tester result pages would qualify? Perhaps search engine > crawlers hit the nightly tester results every now and then? I see that there > is a robots.txt that should fix this, but perhaps there are other scripts > missing from it? Valid web spiders are not the issue. We have had problems with people using WGET in the past. I'll look into this today. Thanks, Tanya From Micah.Villmow at amd.com Tue Sep 23 12:44:30 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Tue, 23 Sep 2008 10:44:30 -0700 Subject: [LLVMdev] Store patterns accepting i32 only? Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA279@ssanexmb1.amd.com> I'm trying to write a store pattern that accepts both i32 and f32, however, when tablegen generates the code, it only generates the code for i32 only. def ADDR : ComplexPattern; def MEM : Operand { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops GPR, GPR); } def global_st : SDNode<"AMDILISD::GLOBAL_STORE", SDTStore, [SDNPHasChain, SDNPMayLoad, SDNPMemOperand]>; def global_store : PatFrag<(ops node:$val, node:$ptr), (st node:$val, node:$ptr), [{ return isGlobalStore(dyn_cast(N)); }]>; def GLOBALSTORE : OneInOneOut; I want this same pattern to be able to accept all the types for val that GPR is mapped to(i32, i64, f32, f64). Is there any way I can modify this so that it do what I want? Here is a snippet of the generated code with the items bolded that I don't want generated: if (Predicate_global_store(N.Val)) { SDValue N1 = N.getOperand(1); SDValue N2 = N.getOperand(2); SDValue CPTmp0; SDValue CPTmp1; if (SelectADDR(N, N2, CPTmp0, CPTmp1)) { // Pattern: (st:void GPR:i32:$val, ADDR:i32:$ptr)<> // Emits: (GLOBALSTORE_i32:void GPR:i32:$val, ADDR:i32:$ptr) // Pattern complexity = 13 cost = 1 size = 0 if (N1.Val->getValueType(0) == MVT::i32 && N2.Val->getValueType(0) == MVT::i32) { return Emit_14(N, AMDIL::GLOBALSTORE_i32, CPTmp0, CPTmp1); } } Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080923/9619612b/attachment.html From scott.llvm at h4ck3r.net Tue Sep 23 12:51:15 2008 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Tue, 23 Sep 2008 10:51:15 -0700 Subject: [LLVMdev] reload of pointers after GC In-Reply-To: References: <84decce20809221759s4192d347p507f10de954a56ac@mail.gmail.com> Message-ID: <84decce20809231051o7a59153dh255477cc4cb8921a@mail.gmail.com> > Are you reusing the same SSA variables, or reloading from the gcroot? > Copying collectors require that you reload before each use (or, more > specifically, between each call that could invoke the collector). e.g., Ah, of course. I keep thinking of the SSA variables as C-type variables, rather than values. Thanks (yet again!) Gordon. > Of particular danger is that naive code generation for something like > f(obj, g()) would retain an SSA value for obj over the call to g(). Yeah, that would be my problem. It would be quite fair to describe my code generation as naive. :) scott From Micah.Villmow at amd.com Tue Sep 23 13:00:10 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Tue, 23 Sep 2008 11:00:10 -0700 Subject: [LLVMdev] Tablegen strings Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA286@ssanexmb1.amd.com> I have a tablegen string that I want to add a modifier to the registers that are being matched. For example a simple match on fneg: def FNEG : OneInOneOut; I want to place a modifier directly after $src0 in the string so that no space is between the string and the matched register. I.e. I want to generate "mov $dst, $src0_neg", however, by putting the _neg right after $src0 forces it to attempt to match against src0_neg instead of just src0. Where can I find the rules for the string pattern matcher so that I can added arbitrary strings into my definition. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080923/81d8bfb0/attachment-0001.html From dag at cray.com Tue Sep 23 13:26:47 2008 From: dag at cray.com (David Greene) Date: Tue, 23 Sep 2008 13:26:47 -0500 Subject: [LLVMdev] Multi-Instruction Patterns Message-ID: <200809231326.47393.dag@cray.com> Are there any examples of using tablegen to generate multiple machine instructions from a single pattern? Or do these cases always have to be manually expanded? -Dave From prakash.prabhu at gmail.com Tue Sep 23 13:33:19 2008 From: prakash.prabhu at gmail.com (Prakash Prabhu) Date: Tue, 23 Sep 2008 14:33:19 -0400 Subject: [LLVMdev] DOTGraphTraits and GraphWriter In-Reply-To: <4E344738-286A-45BB-88DC-505ACAA18FC7@apple.com> References: <85a4cc050809151515i3b088f6awc5265c0b979c6767@mail.gmail.com> <6F91F79D-EC28-4E7D-929A-7A1EF20BED78@apple.com> <85a4cc050809161458i42dfa5c8ha1c99a3afc29dc34@mail.gmail.com> <4E344738-286A-45BB-88DC-505ACAA18FC7@apple.com> Message-ID: <85a4cc050809231133j3edd59f0w75321b800f476b8a@mail.gmail.com> Hi Dan, I remodelled my graph to have more information from the source node field of each outgoing edge rather than an edge itself, so now I no longer need to use EdgeIter specfically. Thanks! - Prakash On Mon, Sep 22, 2008 at 5:35 PM, Dan Gohman wrote: > Hi Prakash, > > I don't know of an easy way to do this, other than to use random-access > iterators so you can compute the distance between the edge and the > beginning of the list of edges. > > Dan > > On Sep 16, 2008, at 2:58 PM, Prakash Prabhu wrote: > >> Hi Dan, >> >> Thanks for the reply. I got the labels for each outgoing edge (at the >> source node's 'structure' field) working. Is there a way to find out >> the outgoing edge number from EdgeIter. (Basically the Node in my >> graph has a a bunch of outgoing edges, so that I can just index into >> that collection within the node to get the appropriate edges' >> attributes). >> >> regards, >> Prakash >> >> On Tue, Sep 16, 2008 at 3:59 PM, Dan Gohman wrote: >>> Hello Prakash, >>> >>> The SelectionDAG viewers (llc -view-isel-dags etc.) support >>> both multiple edges between the same pair of nodes, and labels >>> at least for each incoming edge. See >>> lib/CodeGen/SelectionDAG/SelectionDAGPrinter.cpp for code you >>> might use as an example, though it is a bit tricky. >>> >>> Dan >>> >>> On Sep 15, 2008, at 3:15 PM, Prakash Prabhu wrote: >>> >>>> Hi all, >>>> >>>> I have two questions related to .dot graph output. Basically, I >>>> have a >>>> graph representing a program dependence graph like structure with >>>> (a) multiple edges between the same pair of nodes >>>> (b) each edge having a special (different) text/label >>>> >>>> I implemented a template-specialized version of DotGraphTraits for >>>> the >>>> my graph structure which given a node, uses a map_iterator >>>> (similar to >>>> the one used in CallGraph) to get the destination node of an >>>> outgoing >>>> edge. This works fine except that I have no clue how to support (a) >>>> and (b) since once the destination node is returned I lose access to >>>> the edge and cannot do any text annotation onto an edge of the >>>> graph. >>>> >>>> Is there some other way to achieve (a) and (b) without having to >>>> implement my own special version of GraphWriter ? >>>> >>>> thanks, >>>> Prakash >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From gohman at apple.com Tue Sep 23 13:52:51 2008 From: gohman at apple.com (Dan Gohman) Date: Tue, 23 Sep 2008 11:52:51 -0700 Subject: [LLVMdev] Overzealous PromoteCastOfAllocation In-Reply-To: <20080923111603.GL15228@katherina.student.utwente.nl> References: <20080908155737.GJ32157@katherina.student.utwente.nl> <643C9D81-4750-48E5-B26C-C7699B04065B@apple.com> <20080913200716.GF9093@katherina.student.utwente.nl> <20080923111603.GL15228@katherina.student.utwente.nl> Message-ID: On Sep 23, 2008, at 4:16 AM, Matthijs Kooijman wrote: > >> and then does a load or store at the higher alignment, is >> invoking undefined behavior. The alignment attribute on a load or >> store >> is an assertion about the actual alignment of the memory. > Should this undefined behaviour be caught by the verifier, or is it > ok for it > to exist? I don't think so. It's not the Verifier's job to diagnose undefined behavior. The IR in this case is valid, so the verifier should accept it. For better or worse, stores to null pointers are pretty common in LLVM IR. The most common source of these is unreachable code, and bugpoint, but those are important use cases :-). However, it might be interesting to have a separate undefined-behavior-detector pass. An LLVM pass wouldn't likely be usable as an user-level bug finder; clang's static analysis is much better positioned to do that kind of thing. But an LLVM pass would be able to find bugs in front-ends and optimization passes. > In any case, since this behaviour is undefined, it's not quite > needed for the > instcombine pass to propagate the ABI alignment from a type > bitcasted to > upwards into the alloca instruction, as you suggested. The frontend > generating > the IR should have done this already when needed (when a load with > that higher > alignment uses the bitcasted value, or the bitcasted value is passed > to > another function, which requires ABI alignment). Your analysis sounds correct. I misunderstood the situation before. > I've now created a patch that makes sure that any struct typed > alloca is never > changed by instcombine, unless all it's uses are bitcasts to the > same type. > This seems like the most sane way to do things. This change did > expose some > alignment-related bug in llvm-gcc, see PR2823. This means that > committing > preserve-struct.diff will result in a test-suite failure (at least > SingleSource/UnitTests/Vector/divides, I haven't finished testing > Multisource > yet), but this is caused by llvm-gcc, not instcombine. > > Related to this issue, I've created two more patches. I'm including > them here > for review, comments are welcome. I'm not sure if these patches > actually make > a lot of difference in real world applications and they are not yet > sufficient > to make scalarrepl do its work completely in our example code (lots > of struct > passing and the resulting memmoves), but they will at least make the > resulting > code more logical and make it possible to get there. > > I've tested these patches against the dejagnu tests and the test- > suite, > finding only two failures. The first is the one regarding PR2823 > referenced > above. The second one is concerning > MultiSource/Benchmarks/MiBench/security-blowfish, for some reason > opt emits an > invalid bitcode file (the bitcode reader asserts). From playing with > the > debugger, it seems a store instruction is asked to store a an i8* to > an > [8 x i8]*. However, since the verifier doesn't catch this before > outputting > the bitcode, it's probably something more involved. I'll look into > this issue > a bit closer later (currently I don't even know which of the three > patches > causes it). > > Anyway, review of these patches and opinions as to their usefulness > would be > welcome! I haven't read your patches yet, but it sounds like you're heading in a positive direction here :-). Dan From Micah.Villmow at amd.com Tue Sep 23 14:44:21 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Tue, 23 Sep 2008 12:44:21 -0700 Subject: [LLVMdev] Determining the register type of a MachineOperand Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA2B2@ssanexmb1.amd.com> How do I determine what type of register(i.e. i32, f32, etc..) I am accessing from a MachineOperand? I.e. how do I get to the MVT struct, or equivalent information, from a MachineOperand object? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080923/3aa3e5c0/attachment.html From clattner at apple.com Tue Sep 23 18:02:32 2008 From: clattner at apple.com (Chris Lattner) Date: Tue, 23 Sep 2008 16:02:32 -0700 Subject: [LLVMdev] Tablegen strings In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA286@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA286@ssanexmb1.amd.com> Message-ID: <7B6F144D-D505-41CB-ACF2-9A66A4FA8266@apple.com> On Sep 23, 2008, at 11:00 AM, Villmow, Micah wrote: > I have a tablegen string that I want to add a modifier to the > registers that are being matched. > > For example a simple match on fneg: > def FNEG : OneInOneOut $src0), > ?mov $dst, $src0?, [(set GPR:$dst, (fneg GPR:$src0))]>; > > I want to place a modifier directly after $src0 in the string so > that no space is between the string > and the matched register. I.e. I want to generate ?mov $dst, > $src0_neg?, however, by putting the > _neg right after $src0 forces it to attempt to match against > src0_neg instead of just src0. Where > can I find the rules for the string pattern matcher so that I can > added arbitrary strings into my > definition. Try using ${src0}_neg -Chris > > Thanks, > > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080923/f9bca2e3/attachment-0001.html From clattner at apple.com Tue Sep 23 18:03:33 2008 From: clattner at apple.com (Chris Lattner) Date: Tue, 23 Sep 2008 16:03:33 -0700 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: <200809231326.47393.dag@cray.com> References: <200809231326.47393.dag@cray.com> Message-ID: <1AD682B2-EA38-4DD7-A303-BC139C626BAA@apple.com> On Sep 23, 2008, at 11:26 AM, David Greene wrote: > Are there any examples of using tablegen to generate multiple machine > instructions from a single pattern? Or do these cases always have > to be > manually expanded? PPC has a bunch of examples, for example: // Arbitrary immediate support. Implement in terms of LIS/ORI. def : Pat<(i32 imm:$imm), (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>; // ADD an arbitrary immediate. def : Pat<(add GPRC:$in, imm:$imm), (ADDIS (ADDI GPRC:$in, (LO16 imm:$imm)), (HA16 imm:$imm))>; // OR an arbitrary immediate. def : Pat<(or GPRC:$in, imm:$imm), (ORIS (ORI GPRC:$in, (LO16 imm:$imm)), (HI16 imm:$imm))>; // XOR an arbitrary immediate. def : Pat<(xor GPRC:$in, imm:$imm), (XORIS (XORI GPRC:$in, (LO16 imm:$imm)), (HI16 imm:$imm))>; -Chris From clattner at apple.com Tue Sep 23 18:05:16 2008 From: clattner at apple.com (Chris Lattner) Date: Tue, 23 Sep 2008 16:05:16 -0700 Subject: [LLVMdev] Store patterns accepting i32 only? In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA279@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA279@ssanexmb1.amd.com> Message-ID: On Sep 23, 2008, at 10:44 AM, Villmow, Micah wrote: > I?m trying to write a store pattern that accepts both i32 and f32, > however, when tablegen generates the code, it only generates the > code for i32 only. > > def ADDR : ComplexPattern; > def MEM : Operand { > let PrintMethod = "printMemOperand"; > let MIOperandInfo = (ops GPR, GPR); > } > def global_st : SDNode<"AMDILISD::GLOBAL_STORE", SDTStore, > [SDNPHasChain, SDNPMayLoad, SDNPMemOperand]>; > > def global_store : PatFrag<(ops node:$val, node:$ptr), > (st node:$val, node:$ptr), [{ > return isGlobalStore(dyn_cast(N)); > }]>; > def GLOBALSTORE : OneInOneOut $ptr), > "mov g[$ptr], $val", > [(global_store GPR:$val, ADDR:$ptr)]>; > > I want this same pattern to be able to accept all the types for val > that GPR is mapped to(i32, i64, f32, f64). > Is there any way I can modify this so that it do what I want? You probably want to use a multipattern ("defm"). This allows a single "line" of TD file to expand into multiple 'def's. Take a look at the X86 SSE instructions for some examples of this. Also, the tblgen document has some info as well, -Chris > > Here is a snippet of the generated code with the items bolded that I > don?t want generated: > if (Predicate_global_store(N.Val)) { > SDValue N1 = N.getOperand(1); > SDValue N2 = N.getOperand(2); > SDValue CPTmp0; > SDValue CPTmp1; > if (SelectADDR(N, N2, CPTmp0, CPTmp1)) { > > // Pattern: (st:void GPR:i32:$val, > ADDR:i32:$ptr)<> > // Emits: (GLOBALSTORE_i32:void GPR:i32:$val, ADDR:i32:$ptr) > // Pattern complexity = 13 cost = 1 size = 0 > if (N1.Val->getValueType(0) == MVT::i32 && > N2.Val->getValueType(0) == MVT::i32) { > return Emit_14(N, AMDIL::GLOBALSTORE_i32, CPTmp0, CPTmp1); > } > } > > Thanks, > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080923/559e9266/attachment.html From mrs at apple.com Tue Sep 23 19:11:37 2008 From: mrs at apple.com (Mike Stump) Date: Tue, 23 Sep 2008 17:11:37 -0700 Subject: [LLVMdev] llvm broken? Message-ID: /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/CodeGenPrepare.cpp: In member function ?bool::CodeGenPrepare::OptimizeInlineAsmInst (llvm::Instruction*, llvm::CallSite, llvm::DenseMap, llvm::DenseMapInfo >&)?: /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/CodeGenPrepare.cpp: 966: error: no matching function for call to ?llvm::TargetLowering::ComputeConstraintToUse (llvm::TargetLowering::AsmOperandInfo&, llvm::SDValue) const? /Volumes/mrs5/net/llvm/llvm/include/llvm/Target/TargetLowering.h:1177: note: candidates are: virtual void llvm::TargetLowering::ComputeConstraintToUse (llvm::TargetLowering::AsmOperandInfo&, llvm::SDValue, bool, llvm::SelectionDAG*) const make[3]: *** [/Volumes/mrs5/net/llvm/llvm-build/lib/Transforms/Scalar/ Debug/CodeGenPrepare.o] Error 1 ? From mrs at apple.com Tue Sep 23 19:17:23 2008 From: mrs at apple.com (Mike Stump) Date: Tue, 23 Sep 2008 17:17:23 -0700 Subject: [LLVMdev] Bulk Download: Please Stop In-Reply-To: <48D8E76C.3040504@uiuc.edu> References: <48D8E76C.3040504@uiuc.edu> Message-ID: <42BE508A-409F-438E-850D-5E515914E56D@apple.com> On Sep 23, 2008, at 5:56 AM, John Criswell wrote: > Someone (hopefully one of you) is doing a mass download of materials > from llvm.org. Sometimes people don't understand the consequences of doing things... If the IP address is in the 17.x.x.x range, I'd be happy to track them down and help them out. From scott.llvm at h4ck3r.net Tue Sep 23 20:09:33 2008 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Tue, 23 Sep 2008 18:09:33 -0700 Subject: [LLVMdev] State of CMake build system. In-Reply-To: References: Message-ID: <84decce20809231809s43259692oa2b76ef66f36de1c@mail.gmail.com> On Sun, Sep 21, 2008 at 9:27 AM, ?scar Fuentes wrote: > This is an updated version of the patch that fixes some issues on VC++ > builds. Hi, FYI I just tried this (from r56534). I get an "error" (below) from cmake (2.6.1) about Intrinsics.gen but it seems to write out sln/vcproj anyway. Project.sln opens and builds OK (modulo a build error in llvmc2 that looks build-system agnostic). Nice work! Also, I get around 10k lines of warnings (not that that's different than previously). Would it be desirable to silence those on VS builds given that it might be easier now since the solutions are generated? My suggested list would be: 4146, 4503, 4996, 4800, 4244, 4624, 4355, 4715 if there's somewhere easy to paste that. I think those are unlikely to be interesting assuming the main development on OSX/Linux is catching genuine problems, and would help reduce noise a lot. There's a handful of others, but I'm not especially confident that they're harmless. scott ----------------- D:\llvm>cmake -G "Visual Studio 8 2005" -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found Perl: C:/Perl/bin/perl.exe -- Configuring using MSVC hack. -- Found Bison: C:/utils/bin/bison.exe -- bitreader -- asmparser -- bitreader -- X86 -- archive -- archive -- archive -- ipo -- bitreader -- linker -- jit -- linking jit -- ipo -- debugger -- asmparser -- bitreader -- support -- jit -- linking jit -- Configuring done -- Generating done CMake Error: Unknown Target referenced : D:/llvm/include/llvm/Intrinsics.gen CMake Error: Target: LLVMVMCore depends on unknown target: D:/llvm/include/llvm/Intrinsics.gen -- Build files have been written to: D:/llvm From greened at obbligato.org Tue Sep 23 21:17:53 2008 From: greened at obbligato.org (David Greene) Date: Tue, 23 Sep 2008 21:17:53 -0500 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: <1AD682B2-EA38-4DD7-A303-BC139C626BAA@apple.com> References: <200809231326.47393.dag@cray.com> <1AD682B2-EA38-4DD7-A303-BC139C626BAA@apple.com> Message-ID: <48D9A351.9080404@obbligato.org> Chris Lattner wrote: > On Sep 23, 2008, at 11:26 AM, David Greene wrote: > >> Are there any examples of using tablegen to generate multiple machine >> instructions from a single pattern? Or do these cases always have >> to be >> manually expanded? > > PPC has a bunch of examples, for example: > > // Arbitrary immediate support. Implement in terms of LIS/ORI. > def : Pat<(i32 imm:$imm), > (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>; Yep, I actually found some x86 ones buried in the .td files. :) So now I have a couple of other questions. I wrote a pattern that looks something like the above in form, but how do I tell the selection DAG to prefer my pattern over another that already exists. I can't easily just disable that other pattern because it generates Machine Instruction opcode enums that are assumed to be available in other parts of the x86 codegen. So given two patterns that match the same thing, what's the tiebreaker? I thought it was order in the .td file but that doesn't appear to be the case. I put my pattern first and it isn't selected. I change the other pattern slightly so it won't match anything and then my pattern gets used (so I know my pattern is valid). Also, I really wanted to express this pattern as transforming from one DAG to another, not down to machine instructions. I saw this in x86InstSSE.td: // FIXME: may not be able to eliminate this movss with coalescing the src and // dest register classes are different. We really want to write this pattern // like this: // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))), // (f32 FR32:$src)>; (this is actually a very useful and important pattern, I wish it was available!) I had actually written my pattern in a similar style before I found this. When I tried to build, tblgen complained about the pattern being of an unknown type (didn't match Instruction or SDNodeXForm). I'm assuming there's some missing tblgen support here and that's why this pattern is commented out. Is that right? Are there plans to add tblgen support for these kinds of patterns? -Dave From ofv at wanadoo.es Tue Sep 23 21:21:21 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Wed, 24 Sep 2008 04:21:21 +0200 Subject: [LLVMdev] State of CMake build system. References: <84decce20809231809s43259692oa2b76ef66f36de1c@mail.gmail.com> Message-ID: Hello Scott. "Scott Graham" writes: > I just tried this (from r56534). I get an "error" (below) from cmake > (2.6.1) about Intrinsics.gen but it seems to write out sln/vcproj > anyway. That should be fixed now. > Project.sln opens and builds OK (modulo a build error in llvmc2 that > looks build-system agnostic). Nice work! The failure on llvmc2 is, possibly, due to a missing file name on its CMakeLists.txt. This has been corrected as well. Last time I checked the MSVC++ 2005 build there was some VC-specific C++ error on a tool. I don't know if this was corrected. Anyways, right now the build is broken on all platforms due to an error that, most likely, was allowed to pass the developer's checks by a bug on the make-based build system. CMake catched the problem on the spot :-) > Also, I get around 10k lines of warnings (not that that's different > than previously). Would it be desirable to silence those on VS builds > given that it might be easier now since the solutions are generated? > My suggested list would be: 4146, 4503, 4996, 4800, 4244, 4624, 4355, > 4715 if there's somewhere easy to paste that. I think those are > unlikely to be interesting assuming the main development on OSX/Linux > is catching genuine problems, and would help reduce noise a lot. > There's a handful of others, but I'm not especially confident that > they're harmless. Until very recently, I used /w (ignore all warnings) on the VC++ build. Strictly speaking, warnings should be fixed on the source code, not just moved under the carpet, but I agree with you: this attitude seems not realistic for the VC++ LLVM users, so I'll silence the warnings you list. OTOH, it seems to me that the development LLVM is too gcc-centric, diagnostics from other compilers should be looked with special attention, so we should take care on not shutting down interesting warnings. Thank you! -- Oscar From evan.cheng at apple.com Wed Sep 24 02:10:42 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 24 Sep 2008 00:10:42 -0700 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: <48D9A351.9080404@obbligato.org> References: <200809231326.47393.dag@cray.com> <1AD682B2-EA38-4DD7-A303-BC139C626BAA@apple.com> <48D9A351.9080404@obbligato.org> Message-ID: On Sep 23, 2008, at 7:17 PM, David Greene wrote: > Chris Lattner wrote: >> On Sep 23, 2008, at 11:26 AM, David Greene wrote: >> >>> Are there any examples of using tablegen to generate multiple >>> machine >>> instructions from a single pattern? Or do these cases always have >>> to be >>> manually expanded? >> >> PPC has a bunch of examples, for example: >> >> // Arbitrary immediate support. Implement in terms of LIS/ORI. >> def : Pat<(i32 imm:$imm), >> (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>; > > Yep, I actually found some x86 ones buried in the .td files. :) > > So now I have a couple of other questions. > > I wrote a pattern that looks something like the above in form, but how > do I tell the selection DAG to prefer my pattern over another that > already exists. I can't easily just disable that other pattern > because > it generates Machine Instruction opcode enums that are assumed to be > available in other parts of the x86 codegen. Try AddedComplexity = n to increase "goodness" of the pattern. It's a bit of a hack. > > > So given two patterns that match the same thing, what's the > tiebreaker? > I thought it was order in the .td file but that doesn't appear to be > the > case. I put my pattern first and it isn't selected. I change the > other > pattern slightly so it won't match anything and then my pattern gets > used (so I know my pattern is valid). > > Also, I really wanted to express this pattern as transforming from one > DAG to another, not down to machine instructions. I saw this in > x86InstSSE.td: > > // FIXME: may not be able to eliminate this movss with coalescing the > src and > // dest register classes are different. We really want to write this > pattern > // like this: > // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))), > // (f32 FR32:$src)>; > > (this is actually a very useful and important pattern, I wish it was > available!) Right. It would be nice to be able to eliminate the unnecessary movss. It hasn't shown up on my radar so I haven't really thought out the right way to model this. I can see a couple of options: 1. Treat these instructions as cross register class copies. The src and dst classes are different (VR128 and FR32) but "compatible". 2. Model it as extract_subreg which coalescer can eliminate. #2 is conceptually correct. The problem is 128 bit XMM0 is the same register as 32 bit (or 64 bit) XMM0. So it's not possible to define the super-register / sub-register relationship. That leaves us with #1. I have added support to coalesce cross-class copies (see CrossClassJoin in SimpleRegisterCoalescing.cpp). Unfortunately, it breaks a few tests and I haven't had the time to look into them. If that's done, we just need to add the concept of "compatible register classes" and mark MOVPS2SSrr as a copy and *it should just work*. Evan > > > I had actually written my pattern in a similar style before I found > this. When I tried to build, tblgen complained about the pattern > being > of an unknown type (didn't match Instruction or SDNodeXForm). > > I'm assuming there's some missing tblgen support here and that's why > this pattern is commented out. Is that right? Are there plans to add > tblgen support for these kinds of patterns? > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From geforce8800 at gmail.com Wed Sep 24 02:27:40 2008 From: geforce8800 at gmail.com (Cloud Strife) Date: Wed, 24 Sep 2008 15:27:40 +0800 Subject: [LLVMdev] What can llvm provide when writing a new compiler? Message-ID: Hi everyone. Because there is still a little confusion about the huge document, I want to know what llvm can provide when we customize our new compiler? For example, a normal compiler includes lexer, parser, intermediate code generator , optimizer and target code generator. According to llvm documents, it seems that llvm can provide a better intermediate code presentation. And what else can it provide? Assuming my new lanuage is very unusual, should I write all the parts( lexer, parser, intermediate code generator , optimizer and target code generator) by myself? If so, is there any convenient method / scheme to do so? Because I heard that the biggest advantage of llvm is its flexible and quick-development for new language. If anyone knows the answer, would you please give me a reply or recommend the chapters which can answer my questions? Thank you very much for any help or any advise. -- Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080924/f2ebc7a0/attachment.html From nicholas at mxc.ca Wed Sep 24 02:44:33 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Wed, 24 Sep 2008 00:44:33 -0700 Subject: [LLVMdev] What can llvm provide when writing a new compiler? In-Reply-To: References: Message-ID: <48D9EFE1.3070703@mxc.ca> Cloud Strife wrote: > Hi everyone. > Because there is still a little confusion about the huge document, I > want to know what llvm can provide when we customize our new compiler? > For example, a normal compiler includes lexer, parser, intermediate code > generator , optimizer and target code generator. According to llvm > documents, it seems that llvm can provide a better intermediate code > presentation. And what else can it provide? Optimizer and target codegen. We also provide an IR file format (both binary and textual). You provide the lexer and parser, and you write the code that turns your language into LLVM IR. Note that the codegen is capable of generating both assembly files on disk and of JITting. The optimizations are capable of doing interprocedural optimizations. Someone might want to put these pieces together in a program that ships some IR, generates some IR on the fly, and then link-time-optimizes them and JITs the result. > Assuming my new lanuage is very unusual, should I write all the > parts( lexer, parser, intermediate code generator , optimizer and target > code generator) by myself? If so, is there any convenient method / > scheme to do so? Because I heard that the biggest advantage of llvm is > its flexible and quick-development for new language. At some point your language has to become a sequence of operations executed in order, which can in turn be expressed in LLVM IR. Leave it to LLVM to perform your optimization and codegen. I don't know what document you're referring to, but the LLVM IR is really quite compact. Do read it: http://llvm.org/docs/LangRef.html . Nick > If anyone knows the answer, would you please give me a reply or > recommend the chapters which can answer my questions? Thank you very > much for any help or any advise. > > > > -- > Best regards. > > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From geforce8800 at gmail.com Wed Sep 24 03:18:42 2008 From: geforce8800 at gmail.com (Cloud Strife) Date: Wed, 24 Sep 2008 16:18:42 +0800 Subject: [LLVMdev] LLVMdev Digest, Vol 51, Issue 76 In-Reply-To: References: Message-ID: Thank you very much for replying. Then I have another question: Before I start, I want to choose the best platform to develop my project. Would you please tell what is the best OS platform to develop the llvm project? There are several choices: Mac OS X, FreeBSD, Linux and Windows. Your opinion is eagerly expected. Thank you :-) > Message: 7 > Date: Wed, 24 Sep 2008 00:44:33 -0700 > From: Nick Lewycky > Subject: Re: [LLVMdev] What can llvm provide when writing a new > compiler? > To: LLVM Developers Mailing List > Message-ID: <48D9EFE1.3070703 at mxc.ca> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Cloud Strife wrote: > > Hi everyone. > > Because there is still a little confusion about the huge document, I > > want to know what llvm can provide when we customize our new compiler? > > For example, a normal compiler includes lexer, parser, intermediate code > > generator , optimizer and target code generator. According to llvm > > documents, it seems that llvm can provide a better intermediate code > > presentation. And what else can it provide? > > Optimizer and target codegen. We also provide an IR file format (both > binary and textual). You provide the lexer and parser, and you write the > code that turns your language into LLVM IR. > > Note that the codegen is capable of generating both assembly files on > disk and of JITting. The optimizations are capable of doing > interprocedural optimizations. Someone might want to put these pieces > together in a program that ships some IR, generates some IR on the fly, > and then link-time-optimizes them and JITs the result. > > > Assuming my new lanuage is very unusual, should I write all the > > parts( lexer, parser, intermediate code generator , optimizer and target > > code generator) by myself? If so, is there any convenient method / > > scheme to do so? Because I heard that the biggest advantage of llvm is > > its flexible and quick-development for new language. > > At some point your language has to become a sequence of operations > executed in order, which can in turn be expressed in LLVM IR. Leave it > to LLVM to perform your optimization and codegen. > > I don't know what document you're referring to, but the LLVM IR is > really quite compact. Do read it: http://llvm.org/docs/LangRef.html . > > Nick > > > If anyone knows the answer, would you please give me a reply or > > recommend the chapters which can answer my questions? Thank you very > > much for any help or any advise. > > > > > > > > -- > > Best regards. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > ------------------------------ > > _______________________________________________ > LLVMdev mailing list > LLVMdev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > End of LLVMdev Digest, Vol 51, Issue 76 > *************************************** > -- Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080924/12761f04/attachment.html From edwintorok at gmail.com Wed Sep 24 03:25:08 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Wed, 24 Sep 2008 11:25:08 +0300 Subject: [LLVMdev] LLVMdev Digest, Vol 51, Issue 76 In-Reply-To: References: Message-ID: <48D9F964.7040407@gmail.com> On 2008-09-24 11:18, Cloud Strife wrote: > Thank you very much for replying. Then I have another question: > Before I start, I want to choose the best platform to develop my > project. Would you please tell what is the best OS platform to develop > the llvm project? There are several choices: Mac OS X, FreeBSD, Linux > and Windows. > > Your opinion is eagerly expected. Thank you :-) > I think that depends on what platform you like more, and what platform you are more familiar with. Best regards, --Edwin From shap at eros-os.com Wed Sep 24 04:33:13 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 24 Sep 2008 05:33:13 -0400 Subject: [LLVMdev] What can llvm provide when writing a new compiler? In-Reply-To: References: Message-ID: <1222248793.6747.3.camel@vmx> On Wed, 2008-09-24 at 15:27 +0800, Cloud Strife wrote: > I want to know what llvm can provide when we customize our new compiler? Cloud: There are some fairly good tutorials on the LLVM site. Looking them over would answer your question thoroughly. shap From andrii.vasyliev at gmail.com Wed Sep 24 09:31:07 2008 From: andrii.vasyliev at gmail.com (Andrii Vasyliev) Date: Wed, 24 Sep 2008 17:31:07 +0300 Subject: [LLVMdev] LLVM and C++ Message-ID: Hi I want to use LLVM to generate a code working with C++ objects. I've got basics of LLVM IR generation from Kaleidoscope and other tutorials. Then I tried to llvm-dis'assemble llvm-gcc'ompiled C++ program and I see how to generate all this strangely named functions and how to run constructors and destructors. So I can imagine how to generate C++ compatible code with LLVM. But it seems to be a bit tricky... So I'm interested is there a simpler way? Thanks for any suggestions From nicolas at capens.net Wed Sep 24 09:35:46 2008 From: nicolas at capens.net (Nicolas Capens) Date: Wed, 24 Sep 2008 16:35:46 +0200 Subject: [LLVMdev] mem2reg optimization In-Reply-To: <200808111605.20053.dag@cray.com> References: <000401c8fbc2$b48680c0$1d938240$@net> <200808111605.20053.dag@cray.com> Message-ID: <001f01c91e52$d5a12870$80e37950$@net> Hi Dave, Did that patch of yours ever make it into trunk? I can't seem to find any related checkin for PromoteMemoryToRegister.cpp. I've been doing some extra profiling lately and the RewriteSingleStoreAlloca function alone is taking a whopping 63% of execution time. Thanks! Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David Greene Sent: Monday, 11 August, 2008 23:05 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] mem2reg optimization On Monday 11 August 2008 09:58, Nicolas Capens wrote: > Hi all, > > > > While profiling LLVM I noticed that a significant amount of time is spent > in the RewriteSingleStoreAlloca function. Especially for fairly long basic > blocks, linearly searching for uses before a store isn't fast. So I was > wondering if there isn't a faster way to locate these uses? YES! I just finished a patch 2 hours ago to fix this. I'll get it in ASAP. mem2reg totally dropped off the radar once I did this. -Dave _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gohman at apple.com Wed Sep 24 10:44:05 2008 From: gohman at apple.com (Dan Gohman) Date: Wed, 24 Sep 2008 08:44:05 -0700 (PDT) Subject: [LLVMdev] Multi-Instruction Patterns Message-ID: <49945.76.220.41.203.1222271045.squirrel@webmail.apple.com> On Wed, September 24, 2008 12:10 am, Evan Cheng wrote: > > On Sep 23, 2008, at 7:17 PM, David Greene wrote: > >> Chris Lattner wrote: >>> On Sep 23, 2008, at 11:26 AM, David Greene wrote: >>> >>>> Are there any examples of using tablegen to generate multiple >>>> machine >>>> instructions from a single pattern? Or do these cases always have >>>> to be >>>> manually expanded? >>> >>> PPC has a bunch of examples, for example: >>> >>> // Arbitrary immediate support. Implement in terms of LIS/ORI. >>> def : Pat<(i32 imm:$imm), >>> (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>; >> >> Yep, I actually found some x86 ones buried in the .td files. :) >> >> So now I have a couple of other questions. >> >> I wrote a pattern that looks something like the above in form, but how >> do I tell the selection DAG to prefer my pattern over another that >> already exists. I can't easily just disable that other pattern >> because >> it generates Machine Instruction opcode enums that are assumed to be >> available in other parts of the x86 codegen. > > Try AddedComplexity = n to increase "goodness" of the pattern. It's a > bit of a hack. > >> >> >> So given two patterns that match the same thing, what's the >> tiebreaker? >> I thought it was order in the .td file but that doesn't appear to be >> the >> case. I put my pattern first and it isn't selected. I change the >> other >> pattern slightly so it won't match anything and then my pattern gets >> used (so I know my pattern is valid). >> >> Also, I really wanted to express this pattern as transforming from one >> DAG to another, not down to machine instructions. I saw this in >> x86InstSSE.td: >> >> // FIXME: may not be able to eliminate this movss with coalescing the >> src and >> // dest register classes are different. We really want to write this >> pattern >> // like this: >> // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))), >> // (f32 FR32:$src)>; >> >> (this is actually a very useful and important pattern, I wish it was >> available!) > > Right. It would be nice to be able to eliminate the unnecessary > movss. It hasn't shown up on my radar so I haven't really thought out > the right way to model this. I can see a couple of options: > > 1. Treat these instructions as cross register class copies. The src > and dst classes are different (VR128 and FR32) but "compatible". > 2. Model it as extract_subreg which coalescer can eliminate. > > #2 is conceptually correct. The problem is 128 bit XMM0 is the same > register as 32 bit (or 64 bit) XMM0. So it's not possible to define > the super-register / sub-register relationship. I don't understand the problem with subregs here. Is it just a naming issue? That can be solved by introducing alternate names, like XMM0_32 and XMM0_64, for each of the subregs. They could still be printed as "xmm0" in the assembly output of course. Dan From dag at cray.com Wed Sep 24 11:06:59 2008 From: dag at cray.com (David Greene) Date: Wed, 24 Sep 2008 11:06:59 -0500 Subject: [LLVMdev] mem2reg optimization In-Reply-To: <001f01c91e52$d5a12870$80e37950$@net> References: <000401c8fbc2$b48680c0$1d938240$@net> <200808111605.20053.dag@cray.com> <001f01c91e52$d5a12870$80e37950$@net> Message-ID: <200809241107.00123.dag@cray.com> On Wednesday 24 September 2008 09:35, Nicolas Capens wrote: > Hi Dave, > > Did that patch of yours ever make it into trunk? I can't seem to find any > related checkin for PromoteMemoryToRegister.cpp. I've been doing some extra > profiling lately and the RewriteSingleStoreAlloca function alone is taking > a whopping 63% of execution time. I will commit it today along with some other things. I've been having a lot of trouble building llvm-gcc but I think I've struggled enouigh now and will just hope our testing on this end has been enough. Thanks for the prod. -Dave From dag at cray.com Wed Sep 24 11:15:12 2008 From: dag at cray.com (David Greene) Date: Wed, 24 Sep 2008 11:15:12 -0500 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: References: <200809231326.47393.dag@cray.com> <48D9A351.9080404@obbligato.org> Message-ID: <200809241115.12889.dag@cray.com> On Wednesday 24 September 2008 02:10, Evan Cheng wrote: > > I wrote a pattern that looks something like the above in form, but how > > do I tell the selection DAG to prefer my pattern over another that > > already exists. I can't easily just disable that other pattern > > because > > it generates Machine Instruction opcode enums that are assumed to be > > available in other parts of the x86 codegen. > > Try AddedComplexity = n to increase "goodness" of the pattern. It's a > bit of a hack. Ah, AddedComplexity == goodness. I thought it == badness so I'd tried to add it to the pattern I wanted to disable. Thanks for the pointer. > 1. Treat these instructions as cross register class copies. The src > and dst classes are different (VR128 and FR32) but "compatible". This seems reasonable. > 2. Model it as extract_subreg which coalescer can eliminate. > > #2 is conceptually correct. The problem is 128 bit XMM0 is the same > register as 32 bit (or 64 bit) XMM0. So it's not possible to define > the super-register / sub-register relationship. I'm not seeing how this is "conceptually correct." It's a vector extract, not a subregister. It's just that we want to reuse the same register. Perhaps the answer is to add vector extract support to the coalescer, in the same way you added subregister support. I don't understand the nitty gritty of that, though. > That leaves us with #1. I have added support to coalesce cross-class > copies (see CrossClassJoin in SimpleRegisterCoalescing.cpp). Yep. > Unfortunately, it breaks a few tests and I haven't had the time to > look into them. If that's done, we just need to add the concept of > "compatible register classes" and mark MOVPS2SSrr as a copy and *it > should just work*. What about getting tblgen support for the pattern in the .td file? That would be another way to tackle this and would open up a whole bunch of other opportunities. Instcombine could be entirely expressed as a set of tblgen patterns, for example, which is desireable from a maintenance perspective and well as new development. It's much easier to write patterns than to go through all of the manual examination that currently exists in instcombine. -Dave From dag at cray.com Wed Sep 24 11:19:25 2008 From: dag at cray.com (David Greene) Date: Wed, 24 Sep 2008 11:19:25 -0500 Subject: [LLVMdev] What can llvm provide when writing a new compiler? In-Reply-To: References: Message-ID: <200809241119.25448.dag@cray.com> On Wednesday 24 September 2008 02:27, Cloud Strife wrote: > Hi everyone. > Because there is still a little confusion about the huge document, I want > to know what llvm can provide when we customize our new compiler? > For example, a normal compiler includes lexer, parser, intermediate code > generator , optimizer and target code generator. According to llvm > documents, it seems that llvm can provide a better intermediate code > presentation. And what else can it provide? Codegen, codegen, codegen. Oh, and optimizations too. :) > Assuming my new lanuage is very unusual, should I write all the parts( > lexer, parser, intermediate code generator , optimizer and target code > generator) by myself? If so, is there any convenient method / scheme to do > so? Because I heard that the biggest advantage of llvm is its flexible and > quick-development for new language. If you're targeting x86, for example, you do NOT want to write your own codegen! If you do, good luck digesting five volumes of ISA material. :) This is generally true for other architectures as well. Reuse, reuse, reuse. LLVM is well-designed to allow you to do that. Take advantage of it. Does LLVM have its shortcomings? Sure. But I can guarantee it has fewer shortcomings than a custom codegen would have down the road. Because there's a community working on it, itr's been forced to be designed in a flexible and reuseable way. Development process is a significant advantage of LLVM and open source in general, one that I think is greatly undervalued. -Dave From Micah.Villmow at amd.com Wed Sep 24 11:22:34 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 24 Sep 2008 09:22:34 -0700 Subject: [LLVMdev] Store patterns accepting i32 only? In-Reply-To: References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA279@ssanexmb1.amd.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA3DD@ssanexmb1.amd.com> The problem with that is I still have to write multiple multipatterns, and in this particular case, I want the pattern to match all types of the GPR register class, not just a single one of that class per sub-pattern. The GPR register class has 32bit and 64 bit scalars along with 32, 64, and 128 bit vector types. So the number of patterns I would have to write is very large even with a multipattern but the instruction produces for all of these types is the exact same, "mov g[$ptr], $val". Any other ideas that might work before I get started with the multipattern stuff? Thanks, Micah ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, September 23, 2008 4:05 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Store patterns accepting i32 only? On Sep 23, 2008, at 10:44 AM, Villmow, Micah wrote: I'm trying to write a store pattern that accepts both i32 and f32, however, when tablegen generates the code, it only generates the code for i32 only. def ADDR : ComplexPattern; def MEM : Operand { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops GPR, GPR); } def global_st : SDNode<"AMDILISD::GLOBAL_STORE", SDTStore, [SDNPHasChain, SDNPMayLoad, SDNPMemOperand]>; def global_store : PatFrag<(ops node:$val, node:$ptr), (st node:$val, node:$ptr), [{ return isGlobalStore(dyn_cast(N)); }]>; def GLOBALSTORE : OneInOneOut; I want this same pattern to be able to accept all the types for val that GPR is mapped to(i32, i64, f32, f64). Is there any way I can modify this so that it do what I want? You probably want to use a multipattern ("defm"). This allows a single "line" of TD file to expand into multiple 'def's. Take a look at the X86 SSE instructions for some examples of this. Also, the tblgen document has some info as well, -Chris Here is a snippet of the generated code with the items bolded that I don't want generated: if (Predicate_global_store(N.Val)) { SDValue N1 = N.getOperand(1); SDValue N2 = N.getOperand(2); SDValue CPTmp0; SDValue CPTmp1; if (SelectADDR(N, N2, CPTmp0, CPTmp1)) { // Pattern: (st:void GPR:i32:$val, ADDR:i32:$ptr)<> // Emits: (GLOBALSTORE_i32:void GPR:i32:$val, ADDR:i32:$ptr) // Pattern complexity = 13 cost = 1 size = 0 if (N1.Val->getValueType(0) == MVT::i32 && N2.Val->getValueType(0) == MVT::i32) { return Emit_14(N, AMDIL::GLOBALSTORE_i32, CPTmp0, CPTmp1); } } Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 _______________________________________________ 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/20080924/f90bd544/attachment-0001.html From evan.cheng at apple.com Wed Sep 24 12:13:05 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 24 Sep 2008 10:13:05 -0700 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: <49945.76.220.41.203.1222271045.squirrel@webmail.apple.com> References: <49945.76.220.41.203.1222271045.squirrel@webmail.apple.com> Message-ID: <1F0B2A6F-2AC8-43EF-9AA8-5BA4A39C570D@apple.com> On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >>> >>> >>> So given two patterns that match the same thing, what's the >>> tiebreaker? >>> I thought it was order in the .td file but that doesn't appear to be >>> the >>> case. I put my pattern first and it isn't selected. I change the >>> other >>> pattern slightly so it won't match anything and then my pattern gets >>> used (so I know my pattern is valid). >>> >>> Also, I really wanted to express this pattern as transforming from >>> one >>> DAG to another, not down to machine instructions. I saw this in >>> x86InstSSE.td: >>> >>> // FIXME: may not be able to eliminate this movss with coalescing >>> the >>> src and >>> // dest register classes are different. We really want to write this >>> pattern >>> // like this: >>> // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))), >>> // (f32 FR32:$src)>; >>> >>> (this is actually a very useful and important pattern, I wish it was >>> available!) >> >> Right. It would be nice to be able to eliminate the unnecessary >> movss. It hasn't shown up on my radar so I haven't really thought >> out >> the right way to model this. I can see a couple of options: >> >> 1. Treat these instructions as cross register class copies. The src >> and dst classes are different (VR128 and FR32) but "compatible". >> 2. Model it as extract_subreg which coalescer can eliminate. >> >> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >> the super-register / sub-register relationship. > > I don't understand the problem with subregs here. Is it just a > naming issue? That can be solved by introducing alternate names, > like XMM0_32 and XMM0_64, for each of the subregs. They could > still be printed as "xmm0" in the assembly output of course. Right. That's a workable solution. However, it still adds complexity: XMM0_32 = MOVPS2SSrr XMM0 We need to teach the allocator that the two registers are the "same" and this is a identity copy. Evan > > > Dan > > > _______________________________________________ > 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/20080924/21a3b1a6/attachment.html From clattner at apple.com Wed Sep 24 12:16:20 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 24 Sep 2008 10:16:20 -0700 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: <49945.76.220.41.203.1222271045.squirrel@webmail.apple.com> References: <49945.76.220.41.203.1222271045.squirrel@webmail.apple.com> Message-ID: <2EBB37FF-D96F-4041-8A49-8C06C0664801@apple.com> On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >> the super-register / sub-register relationship. > > I don't understand the problem with subregs here. Is it just a > naming issue? That can be solved by introducing alternate names, > like XMM0_32 and XMM0_64, for each of the subregs. They could > still be printed as "xmm0" in the assembly output of course. this is what the PPC64 backend does. "X0" (64-bit GPR) and "R0" (32- bit GPR) both print as "r0". -Chris From evan.cheng at apple.com Wed Sep 24 12:20:48 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 24 Sep 2008 10:20:48 -0700 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: <200809241115.12889.dag@cray.com> References: <200809231326.47393.dag@cray.com> <48D9A351.9080404@obbligato.org> <200809241115.12889.dag@cray.com> Message-ID: On Sep 24, 2008, at 9:15 AM, David Greene wrote: > >> 1. Treat these instructions as cross register class copies. The src >> and dst classes are different (VR128 and FR32) but "compatible". > > This seems reasonable. > >> 2. Model it as extract_subreg which coalescer can eliminate. >> >> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >> the super-register / sub-register relationship. > > I'm not seeing how this is "conceptually correct." It's a vector > extract, not > a subregister. It's just that we want to reuse the same register. It is though. Sub-register is a machine specific concept. It means vector_extract can be modeled as subreg_extract on this machine. Nothing is wrong with thatt. > > > Perhaps the answer is to add vector extract support to the > coalescer, in > the same way you added subregister support. I don't understand the > nitty > gritty of that, though. I don't think that's a good idea. Conceptually vector_extract is very different from a move. > > >> That leaves us with #1. I have added support to coalesce cross-class >> copies (see CrossClassJoin in SimpleRegisterCoalescing.cpp). > > Yep. As Dan pointed out, #2 is also a workable solution. > >> Unfortunately, it breaks a few tests and I haven't had the time to >> look into them. If that's done, we just need to add the concept of >> "compatible register classes" and mark MOVPS2SSrr as a copy and *it >> should just work*. > > What about getting tblgen support for the pattern in the .td file? > That would > be another way to tackle this and would open up a whole bunch of other > opportunities. Instcombine could be entirely expressed as a set of > tblgen > patterns, for example, which is desireable from a maintenance > perspective > and well as new development. It's much easier to write patterns > than to go > through all of the manual examination that currently exists in > instcombine. I don't think that would work. We still have to model the value as being produced by an instruction. So either we have to select it to a target specific instruction or a target independent instruction (i.e. extract_subreg). After thinking about this some more, I think #2 is a better solution. Adding XMM0_32 etc. teaches codegen that only lower 32-bits of the registers are used. Perhaps this can open up additional optimization opportunities. On the other hand, adding these registers means introducing more aliasing which has compile time implication. Evan > > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Wed Sep 24 12:22:22 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 24 Sep 2008 10:22:22 -0700 Subject: [LLVMdev] Determining the register type of a MachineOperand In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA2B2@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA2B2@ssanexmb1.amd.com> Message-ID: <99189444-A4C8-43AA-BE07-BD78CB16E73B@apple.com> You can get to the MachineInstr from a MachineOperand. Then get to its TargetInstrDesc and TargetOperandInfo which has register class information. Evan On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: > How do I determine what type of register(i.e. i32, f32, etc..) I am > accessing from a MachineOperand? I.e. how do I get to the MVT > struct, or equivalent information, from a MachineOperand object? > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080924/fe29457f/attachment.html From evan.cheng at apple.com Wed Sep 24 12:24:50 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 24 Sep 2008 10:24:50 -0700 Subject: [LLVMdev] A question about instruction operands. In-Reply-To: <48D8E20B.5010509@googlemail.com> References: <1222170758.3156.6.camel@idc-lt-i00171.microchip.com> <48D8E20B.5010509@googlemail.com> Message-ID: BTW, please use the operand constraint syntax instead of the deprecated isTwoAddress syntax: let Constraints = "$src1 = $dst" in Evan On Sep 23, 2008, at 5:33 AM, Richard Osborne wrote: > sanjiv gupta wrote: >> I have a question: >> In the pattern below from X86 >> >> def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), >> "inc{b}\tdst", >> [(set GR8:$dst, (add GR8:$src, 1))]>; >> >> Since we are emitting only "inc $dst", >> What makes sure that the $src and $dst are same register? >> >> - Sanjiv > It's enclosed inside : > > let isTwoAddress = 1 in { > ... > } > > (you'll need to scroll up a fair amount to find this). > > Richard > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Wed Sep 24 12:26:18 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 24 Sep 2008 10:26:18 -0700 Subject: [LLVMdev] A question about instruction operands. In-Reply-To: References: <1222170758.3156.6.camel@idc-lt-i00171.microchip.com> <48D8E20B.5010509@googlemail.com> <1222174516.3156.15.camel@idc-lt-i00171.microchip.com> <48D8EF6D.60509@googlemail.com> Message-ID: <5FE9A2AD-4C4F-4412-B6BA-53A68B3B3748@apple.com> On Sep 23, 2008, at 9:05 AM, Sanjiv.Gupta at microchip.com wrote: >>>>> >>>> It's enclosed inside : >>>> >>>> let isTwoAddress = 1 in { >>>> ... >>>> } >>>> >>>> (you'll need to scroll up a fair amount to find this). >>>> >>>> >>> That means, it gets converted to >>> dst = src; >>> dst = dst + 1; >>> >>> Right ? >>> >>> - Sanjiv >>> >> Yes, I believe the two address instruction pass performs exactly this >> transformation. >> > Thanks. > How do I communicate if my CopyRegToReg instruction clobbers a > register > of another register class? Is it through let Defs = [REG] { ... } > while > defining the instr pattern? That won't work. You don't know what physical registers are clobbered until you know the register assignments, right? One possibility is to add implicit defs when you create these instructions. Evan > > > - Sanjiv > >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sanjiv.gupta at microchip.com Wed Sep 24 12:53:04 2008 From: sanjiv.gupta at microchip.com (sanjiv gupta) Date: Wed, 24 Sep 2008 23:23:04 +0530 Subject: [LLVMdev] A question about instruction operands. In-Reply-To: <5FE9A2AD-4C4F-4412-B6BA-53A68B3B3748@apple.com> References: <1222170758.3156.6.camel@idc-lt-i00171.microchip.com> <48D8E20B.5010509@googlemail.com> <1222174516.3156.15.camel@idc-lt-i00171.microchip.com> <48D8EF6D.60509@googlemail.com> <5FE9A2AD-4C4F-4412-B6BA-53A68B3B3748@apple.com> Message-ID: <1222278784.5792.3.camel@idc-lt-i00171.microchip.com> On Wed, 2008-09-24 at 10:26 -0700, Evan Cheng wrote: > > How do I communicate if my CopyRegToReg instruction clobbers a > > register > > of another register class? Is it through let Defs = [REG] { ... } > > while > > defining the instr pattern? > > That won't work. You don't know what physical registers are clobbered > until you know the register assignments, right? One possibility is to > add implicit defs when you create these instructions. > In our case that isn't a problem because we have only one register. > Evan > > > > > > > - Sanjiv > > > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From Micah.Villmow at amd.com Wed Sep 24 13:27:42 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 24 Sep 2008 11:27:42 -0700 Subject: [LLVMdev] Accessor function setFPImm in MachineOperand Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA42B@ssanexmb1.amd.com> I need to modify the FPImmediate in the MachineOperand but there is no accessor function for this variable. Any other way of doing this without creating a new operand via CreateFPImm? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080924/a06ea779/attachment.html From echristo at apple.com Wed Sep 24 13:33:25 2008 From: echristo at apple.com (Eric Christopher) Date: Wed, 24 Sep 2008 11:33:25 -0700 Subject: [LLVMdev] LLVM and C++ In-Reply-To: References: Message-ID: <488F0B44-337D-4AC1-9A8B-2723920399A6@apple.com> On Sep 24, 2008, at 7:31 AM, Andrii Vasyliev wrote: > Hi > > I want to use LLVM to generate a code working with C++ objects. > > I've got basics of LLVM IR generation from Kaleidoscope and other > tutorials. > Then I tried to llvm-dis'assemble llvm-gcc'ompiled C++ program and I > see > how to generate all this strangely named functions and how to run > constructors and destructors. So I can imagine how to generate C++ > compatible code with LLVM. But it seems to be a bit tricky... > So I'm interested is there a simpler way? The easiest way is to wrap construction/destruction/operations in C functions and then call those - or compile them the .ll and inline them as appropriate etc. -eric From evan.cheng at apple.com Wed Sep 24 13:34:19 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 24 Sep 2008 11:34:19 -0700 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: <2EBB37FF-D96F-4041-8A49-8C06C0664801@apple.com> References: <49945.76.220.41.203.1222271045.squirrel@webmail.apple.com> <2EBB37FF-D96F-4041-8A49-8C06C0664801@apple.com> Message-ID: On Sep 24, 2008, at 10:16 AM, Chris Lattner wrote: > On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >>> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >>> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >>> the super-register / sub-register relationship. >> >> I don't understand the problem with subregs here. Is it just a >> naming issue? That can be solved by introducing alternate names, >> like XMM0_32 and XMM0_64, for each of the subregs. They could >> still be printed as "xmm0" in the assembly output of course. > > this is what the PPC64 backend does. "X0" (64-bit GPR) and "R0" (32- > bit GPR) both print as "r0". Somewhat different scenario there. On PPC64, these are actually distinct registers, right? Evan > > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From Micah.Villmow at amd.com Wed Sep 24 14:15:52 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 24 Sep 2008 12:15:52 -0700 Subject: [LLVMdev] Determining the register type of a MachineOperand In-Reply-To: <99189444-A4C8-43AA-BE07-BD78CB16E73B@apple.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA2B2@ssanexmb1.amd.com> <99189444-A4C8-43AA-BE07-BD78CB16E73B@apple.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA435@ssanexmb1.amd.com> This only has the register class information, not the register type information. My register class has multiple register types and I need to know how to differentiate which register type of my register class of the current register. The information in the MVT data type is what I need, i.e. the position in the GPRVT array of each register. Something equivalent to MVT getValueType() but for registers. Thanks, ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Wednesday, September 24, 2008 10:22 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Determining the register type of a MachineOperand You can get to the MachineInstr from a MachineOperand. Then get to its TargetInstrDesc and TargetOperandInfo which has register class information. Evan On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: How do I determine what type of register(i.e. i32, f32, etc..) I am accessing from a MachineOperand? I.e. how do I get to the MVT struct, or equivalent information, from a MachineOperand object? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 _______________________________________________ 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/20080924/a0483607/attachment-0001.html From dag at cray.com Wed Sep 24 15:06:01 2008 From: dag at cray.com (David Greene) Date: Wed, 24 Sep 2008 15:06:01 -0500 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: References: <200809231326.47393.dag@cray.com> <200809241115.12889.dag@cray.com> Message-ID: <200809241506.01702.dag@cray.com> On Wednesday 24 September 2008 12:20, Evan Cheng wrote: > > I'm not seeing how this is "conceptually correct." It's a vector > > extract, not > > a subregister. It's just that we want to reuse the same register. > > It is though. Sub-register is a machine specific concept. It means > vector_extract can be modeled as subreg_extract on this machine. > Nothing is wrong with thatt. I didn't mean to imply anything was "wrong." It just strikes me as kind of strange, in a mind-warping kind of way. :) > > Perhaps the answer is to add vector extract support to the > > coalescer, in > > the same way you added subregister support. I don't understand the > > nitty > > gritty of that, though. > > I don't think that's a good idea. Conceptually vector_extract is very > different from a move. Ok, I agree. > >> That leaves us with #1. I have added support to coalesce cross-class > >> copies (see CrossClassJoin in SimpleRegisterCoalescing.cpp). > > > > Yep. > > As Dan pointed out, #2 is also a workable solution. Yes, I like Dan's proposal. > > What about getting tblgen support for the pattern in the .td file? > > That would > > be another way to tackle this and would open up a whole bunch of other > > opportunities. Instcombine could be entirely expressed as a set of > > tblgen > > patterns, for example, which is desireable from a maintenance > > perspective > > and well as new development. It's much easier to write patterns > > than to go > > through all of the manual examination that currently exists in > > instcombine. > > I don't think that would work. We still have to model the value as > being produced by an instruction. So either we have to select it to a > target specific instruction or a target independent instruction (i.e. > extract_subreg). That's right. The pattern doesn't know if the rest of the vector is going to be used elsewhere so we need dataflow information and that implies it needs to be done in the coalescer (or some other transformation pass). > After thinking about this some more, I think #2 is a better solution. > Adding XMM0_32 etc. teaches codegen that only lower 32-bits of the > registers are used. Perhaps this can open up additional optimization > opportunities. On the other hand, adding these registers means > introducing more aliasing which has compile time implication. What about XMM0_64? What about things like AVX which applies the GPR aliasing scheme to vectors? I think this is the right way to go but we need to do things in a comprehensive way so we can expand as needed. -Dave From prakash.prabhu at gmail.com Wed Sep 24 15:22:37 2008 From: prakash.prabhu at gmail.com (Prakash Prabhu) Date: Wed, 24 Sep 2008 16:22:37 -0400 Subject: [LLVMdev] Memory Altering/Accessing Instructions Message-ID: <85a4cc050809241322p482cefe6k857f6018453d1985@mail.gmail.com> Hi all, Would it be correct to say that the only instructions in LLVM IR that modify/access memory potentially are the following: (1) LoadInst : Ref (2) StoreInst : Mod (3) VAArgInst : Ref (?) (4) AllocaInst : Mod (5) MallocInst : Mod (6) FreeInst : Mod (7) CallInst : Mod/Ref ? Also, my earlier impression was that the GEP instruction only computes the effective address and does not modify/access any memory location. Is that true ? If I have missed other instructions that could alter/modify memory, please let me know. Thanks for your time. - Prakash From wangmp at apple.com Wed Sep 24 15:23:28 2008 From: wangmp at apple.com (Mon Ping Wang) Date: Wed, 24 Sep 2008 13:23:28 -0700 Subject: [LLVMdev] Determining the register type of a MachineOperand In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA435@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA2B2@ssanexmb1.amd.com> <99189444-A4C8-43AA-BE07-BD78CB16E73B@apple.com> <5BA674C5FF7B384A92C2C95D8CC71E1C0BA435@ssanexmb1.amd.com> Message-ID: <1413AD2F-BF58-481C-8F0A-34F2803F300E@apple.com> To my knowledge, I don't think there is an easy way to get the MVT information from a MachineOperand. Why do you need it for? In my mind, the MachineInstr and its associated operands represent a physical machine instruction and I typically want to think of those as machine opcodes and machine register files. I am typically interested in the mapping of MVTs to register classes when I'm generating machine instructions. Note that a register class may map to multiple MVTs depending on your description. -- Mon Ping On Sep 24, 2008, at 12:15 PM, Villmow, Micah wrote: > This only has the register class information, not the register type > information. > > My register class has multiple register types and I need to know how > to differentiate which register type of my register class of the > current register. > The information in the MVT data type is what I need, i.e. the > position in the GPRVT array of each register. > > Something equivalent to MVT getValueType() but for registers. > > Thanks, > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of Evan Cheng > Sent: Wednesday, September 24, 2008 10:22 AM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Determining the register type of a > MachineOperand > > You can get to the MachineInstr from a MachineOperand. Then get to > its TargetInstrDesc and TargetOperandInfo which has register class > information. > > Evan > > On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: > > > How do I determine what type of register(i.e. i32, f32, etc..) I am > accessing from a MachineOperand? I.e. how do I get to the MVT > struct, or equivalent information, from a MachineOperand object? > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080924/d76a01d8/attachment.html From clattner at apple.com Wed Sep 24 15:42:31 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 24 Sep 2008 13:42:31 -0700 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: References: <49945.76.220.41.203.1222271045.squirrel@webmail.apple.com> <2EBB37FF-D96F-4041-8A49-8C06C0664801@apple.com> Message-ID: On Sep 24, 2008, at 11:34 AM, Evan Cheng wrote: > > On Sep 24, 2008, at 10:16 AM, Chris Lattner wrote: > >> On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >>>> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >>>> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >>>> the super-register / sub-register relationship. >>> >>> I don't understand the problem with subregs here. Is it just a >>> naming issue? That can be solved by introducing alternate names, >>> like XMM0_32 and XMM0_64, for each of the subregs. They could >>> still be printed as "xmm0" in the assembly output of course. >> >> this is what the PPC64 backend does. "X0" (64-bit GPR) and "R0" (32- >> bit GPR) both print as "r0". > > Somewhat different scenario there. On PPC64, these are actually > distinct registers, right? No, the 32-bit GPR is a subreg (low 32-bits) of the 64-bit register. IIRC, storing to the 32-bit GPR clears out the top half. This seems very analogous to the SSE case. However, in full disclosure, we never fixed the coalescing performance issue for PPC64. -Chris From clattner at apple.com Wed Sep 24 15:43:29 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 24 Sep 2008 13:43:29 -0700 Subject: [LLVMdev] Accessor function setFPImm in MachineOperand In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA42B@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA42B@ssanexmb1.amd.com> Message-ID: <9B213B9D-AE28-49CF-AD17-D85E3710BAF9@apple.com> On Sep 24, 2008, at 11:27 AM, Villmow, Micah wrote: > I need to modify the FPImmediate in the MachineOperand but there is > no accessor function for this variable. Any other way of doing this > without creating a new operand via CreateFPImm? If you just need a new accessor, please submit a patch: we'd be happy to add it. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080924/5d0b5260/attachment.html From criswell at cs.uiuc.edu Wed Sep 24 15:57:38 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 24 Sep 2008 15:57:38 -0500 Subject: [LLVMdev] Memory Altering/Accessing Instructions In-Reply-To: <85a4cc050809241322p482cefe6k857f6018453d1985@mail.gmail.com> References: <85a4cc050809241322p482cefe6k857f6018453d1985@mail.gmail.com> Message-ID: <48DAA9C2.7090601@cs.uiuc.edu> Prakash Prabhu wrote: > Hi all, > > Would it be correct to say that the only instructions in LLVM IR that > modify/access memory potentially are the following: > I believe that every instruction has a mayWriteToMemory()/mayReadToMemory() method that you can use to determine this information. See http://llvm.org/doxygen/classllvm_1_1Instruction.html (the LLVM doxygen info on llvm::Instruction) for more details. I believe these methods describe whether memory is read/written in a way visible from the LLVM IR; I don't believe they'll take into account things like read/writes due to register spills created by the code generator. > (1) LoadInst : Ref > (2) StoreInst : Mod > (3) VAArgInst : Ref (?) > (4) AllocaInst : Mod > (5) MallocInst : Mod > (6) FreeInst : Mod > (7) CallInst : Mod/Ref ? > > Also, my earlier impression was that the GEP instruction only computes > the effective address and does not modify/access any memory location. > Is that true ? > This is correct. > If I have missed other instructions that could alter/modify memory, > please let me know. > > Thanks for your time. > -- John T. > - Prakash > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From Gobaan_Raveendran at amis.com Wed Sep 24 16:09:13 2008 From: Gobaan_Raveendran at amis.com (Gobaan_Raveendran at amis.com) Date: Wed, 24 Sep 2008 17:09:13 -0400 Subject: [LLVMdev] Named Address Spaces In-Reply-To: Message-ID: Hello, I am a student trying to find out if LLVM can be used for the Embedded C architecture that I will be developing tools for at work. In LLVM 2.2 Christopher Lamb contributed support for Multiple Address Spaces into the LLVM IR, and I was wondering if llvm-gcc is able to use this functionallity. If so, what syntax is used to assign address spaces, and what files are needed for the address spaces to be defined in the backend. If not, how do users capitalize on this functionallity? Thank you for your time, - Gobi From tonic at nondot.org Wed Sep 24 16:17:19 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Wed, 24 Sep 2008 14:17:19 -0700 (PDT) Subject: [LLVMdev] Oct 6th - 2.4 Code Freeze (2nd reminder) Message-ID: LLVM Developers, Less than 2 weeks to go! The 2.4 code freeze is October 6th (9PM PDT). Please plan to check in any major changes at least one week before this deadline. The full release schedule is on the LLVM website. If you have any questions, please let me know. Thanks! -Tanya From matthijs at stdin.nl Wed Sep 24 16:48:55 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Wed, 24 Sep 2008 23:48:55 +0200 Subject: [LLVMdev] Named Address Spaces In-Reply-To: References: Message-ID: <20080924214855.GX15228@katherina.student.utwente.nl> Hi Gobi, > I am a student trying to find out if LLVM can be used for the Embedded C > architecture that I will be developing tools for at work. In LLVM 2.2 > Christopher Lamb contributed support for Multiple Address Spaces into the > LLVM IR, and I was wondering if llvm-gcc is able to use this > functionallity. If so, what syntax is used to assign address spaces, and You should look at the addrspace attribute. IIRC, the syntax is as follows: __attribute__(( addrspace(10) )) int foo; This should allocate foo in address space 10 (though I'm not 100% sure about the syntax and don't have examples at hand). > what files are needed for the address spaces to be defined in the backend. > If not, how do users capitalize on this functionallity? clang and LLVM IRC only support numbered address spaces, no names. There is no need to define anything to get address spaces in the IR. You should probably do something to make a backend actually use the address space information, though I don't know what, where, or if there are any backends using this info already. Perhaps others can comment? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080924/b992c0c0/attachment.bin From dag at cray.com Wed Sep 24 19:11:07 2008 From: dag at cray.com (David Greene) Date: Wed, 24 Sep 2008 19:11:07 -0500 Subject: [LLVMdev] Cannot Select ConstantFP on x86 Message-ID: <200809241911.07519.dag@cray.com> I just ran into this today with x86-64: Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> As far as I can tell, DAGCombiner comes along and sees an sint_to_fp of the constant 1 and hapilly folds it into a ConstantFP<1>. ISel then blows up because there's no pattern for it. Does this look familiar to anyone? I don't see any relevant bugs in the database. -Dave From gohman at apple.com Wed Sep 24 19:55:12 2008 From: gohman at apple.com (Dan Gohman) Date: Wed, 24 Sep 2008 17:55:12 -0700 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: References: <49945.76.220.41.203.1222271045.squirrel@webmail.apple.com> <2EBB37FF-D96F-4041-8A49-8C06C0664801@apple.com> Message-ID: <77C81CDA-234D-44D1-95C2-DAD36E088799@apple.com> On Sep 24, 2008, at 1:42 PM, Chris Lattner wrote: > > On Sep 24, 2008, at 11:34 AM, Evan Cheng wrote: > >> >> On Sep 24, 2008, at 10:16 AM, Chris Lattner wrote: >> >>> On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >>>>> #2 is conceptually correct. The problem is 128 bit XMM0 is the >>>>> same >>>>> register as 32 bit (or 64 bit) XMM0. So it's not possible to >>>>> define >>>>> the super-register / sub-register relationship. >>>> >>>> I don't understand the problem with subregs here. Is it just a >>>> naming issue? That can be solved by introducing alternate names, >>>> like XMM0_32 and XMM0_64, for each of the subregs. They could >>>> still be printed as "xmm0" in the assembly output of course. >>> >>> this is what the PPC64 backend does. "X0" (64-bit GPR) and >>> "R0" (32- >>> bit GPR) both print as "r0". >> >> Somewhat different scenario there. On PPC64, these are actually >> distinct registers, right? > > No, the 32-bit GPR is a subreg (low 32-bits) of the 64-bit register. > IIRC, storing to the 32-bit GPR clears out the top half. > > This seems very analogous to the SSE case. However, in full > disclosure, we never fixed the coalescing performance issue for PPC64. There's a performance issue, maybe related, with 32-bit subregs of 64-bit GPRs on x86-64 too. CodeGen does eliminate some subreg-related copies, and actually it's improved in this aspect since LLVM 2.3, but there remain more opportunities for improvement. Dan From eslee3 at uiuc.edu Wed Sep 24 23:58:43 2008 From: eslee3 at uiuc.edu (Edward Lee) Date: Wed, 24 Sep 2008 23:58:43 -0500 Subject: [LLVMdev] Detecting mutex locks (and unlocks) Message-ID: Is there a "standard" way to check for a lock acquire and release for a transformation pass? Assuming the locks aren't inline asm, so llvm-gcc can compile __sync_lock_test_and_set builtin to llvm.atomic.swap, one could potentially look for IntrinsicInst with the appropriate IntrinsicID. But there's many ways to acquire a lock just using the atomic builtins [1] -- not to mention how a lock implements a blocking acquire. The lock release could use __sync_lock_release, which is converted into a regular function call of appropriate size, or the lock could just do a plain write of an i8 0 assuming a byte size memory location. I did a quick search and noticed some code using __sync_lock_test_and_set(&lock, 0) to exchange in a 0. [1] http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html Ed From yonggangluo at hotmail.com Thu Sep 25 00:02:39 2008 From: yonggangluo at hotmail.com (=?UTF-8?B?572X5YuH5Yia?=) Date: Thu, 25 Sep 2008 13:02:39 +0800 Subject: [LLVMdev] A question, About how to reading the historical mailling-? In-Reply-To: References: Message-ID: I want to know this. Is this possible? Thanks From matthijs at stdin.nl Thu Sep 25 01:44:09 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Thu, 25 Sep 2008 08:44:09 +0200 Subject: [LLVMdev] A question, About how to reading the historical mailling-? In-Reply-To: References: Message-ID: <20080925064409.GY15228@katherina.student.utwente.nl> Hi anonymous, > I want to know this. Is this possible? Thanks I assume you mean you want to read the archives of the mailinglist? There is an "archives" link on top of each list info page, e.g. http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev (similar for the other mailing list). Hope this helps, Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080925/48a501a6/attachment.bin From pertti.kellomaki at tut.fi Thu Sep 25 03:20:24 2008 From: pertti.kellomaki at tut.fi (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=) Date: Thu, 25 Sep 2008 11:20:24 +0300 Subject: [LLVMdev] A question, About how to reading the historical mailling-? In-Reply-To: <20080925064409.GY15228@katherina.student.utwente.nl> References: <20080925064409.GY15228@katherina.student.utwente.nl> Message-ID: <48DB49C8.7040901@tut.fi> Matthijs Kooijman wrote: > I assume you mean you want to read the archives of the mailinglist? There is > an "archives" link on top of each list info page, e.g. > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev On a related note, is there a way to search the archives? They do not seem to be visible to Google, at least Google searches do not find stuff in the archives. For example, there was a thread on Thunderbird in January, yet "site:lists.cs.uiuc.edu thunderbird" does not show up anything. I did not see search functionality on the mailman page of the list either. -- Pertti From rlsosborne at googlemail.com Thu Sep 25 03:39:06 2008 From: rlsosborne at googlemail.com (Richard Osborne) Date: Thu, 25 Sep 2008 09:39:06 +0100 Subject: [LLVMdev] A question, About how to reading the historical mailling-? In-Reply-To: <48DB49C8.7040901@tut.fi> References: <20080925064409.GY15228@katherina.student.utwente.nl> <48DB49C8.7040901@tut.fi> Message-ID: <48DB4E2A.3050302@googlemail.com> Pertti Kellom?ki wrote: > Matthijs Kooijman wrote: > >> I assume you mean you want to read the archives of the mailinglist? There is >> an "archives" link on top of each list info page, e.g. >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > On a related note, is there a way to search the archives? They do not > seem to be visible to Google, at least Google searches do not find > stuff in the archives. For example, there was a thread on Thunderbird > in January, yet "site:lists.cs.uiuc.edu thunderbird" does not show > up anything. I did not see search functionality on the mailman page > of the list either. > gmane provides a searchable mailing list archive which I've found very useful: http://dir.gmane.org/gmane.comp.compilers.llvm.devel Richard From sanjiv.gupta at microchip.com Thu Sep 25 05:56:10 2008 From: sanjiv.gupta at microchip.com (sanjiv gupta) Date: Thu, 25 Sep 2008 16:26:10 +0530 Subject: [LLVMdev] Named Address Spaces In-Reply-To: <20080924214855.GX15228@katherina.student.utwente.nl> References: <20080924214855.GX15228@katherina.student.utwente.nl> Message-ID: <1222340170.3167.5.camel@idc-lt-i00171.microchip.com> > though I don't know what, where, or if there are any backends using this info > already. Perhaps others can comment? > We plan to use the address space info in backend to support the "rom" address space for our target in near future. - Sanjiv From nicolas at capens.net Thu Sep 25 07:40:07 2008 From: nicolas at capens.net (Nicolas Capens) Date: Thu, 25 Sep 2008 14:40:07 +0200 Subject: [LLVMdev] mem2reg optimization In-Reply-To: <200809241107.00123.dag@cray.com> References: <000401c8fbc2$b48680c0$1d938240$@net> <200808111605.20053.dag@cray.com> <001f01c91e52$d5a12870$80e37950$@net> <200809241107.00123.dag@cray.com> Message-ID: <002d01c91f0b$d8510720$88f31560$@net> Hi Dave, As an exercise I tried to fix this myself, and I think I have a working patch (attached). My own tests are all working wonderfully, and at fantastic performance! I'm looking forward to your patch to see whether we used the same approach or whether things could be improved further. Anyway, I've re-profiled the code and found ComputeLiveInBlocks to be the main hotspot now. Again it uses a linear search over the instructions so there's a chance this can be optimized as well... Kind regards, Nicolas -----Original Message----- From: David Greene [mailto:dag at cray.com] Sent: Wednesday, 24 September, 2008 18:07 To: Nicolas Capens Cc: 'LLVM Developers Mailing List' Subject: Re: [LLVMdev] mem2reg optimization On Wednesday 24 September 2008 09:35, Nicolas Capens wrote: > Hi Dave, > > Did that patch of yours ever make it into trunk? I can't seem to find any > related checkin for PromoteMemoryToRegister.cpp. I've been doing some extra > profiling lately and the RewriteSingleStoreAlloca function alone is taking > a whopping 63% of execution time. I will commit it today along with some other things. I've been having a lot of trouble building llvm-gcc but I think I've struggled enouigh now and will just hope our testing on this end has been enough. Thanks for the prod. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: PromoteMemoryToRegister.patch Type: application/octet-stream Size: 2695 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080925/6cf39542/attachment.obj From nicolas at capens.net Thu Sep 25 07:49:43 2008 From: nicolas at capens.net (Nicolas Capens) Date: Thu, 25 Sep 2008 14:49:43 +0200 Subject: [LLVMdev] mem2reg optimization In-Reply-To: <002d01c91f0b$d8510720$88f31560$@net> References: <000401c8fbc2$b48680c0$1d938240$@net> <200808111605.20053.dag@cray.com> <001f01c91e52$d5a12870$80e37950$@net> <200809241107.00123.dag@cray.com> <002d01c91f0b$d8510720$88f31560$@net> Message-ID: <000601c91f0d$2f5c16d0$8e144470$@net> I forgot to ask: I found that uses appear to be stored in reverse order (i.e. use_begin() gives us an iterator that starts with the last use and incrementing it brings us to the first one). Is that correct and is it something I can always rely on for analysis? Thanks. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Nicolas Capens Sent: Thursday, 25 September, 2008 14:40 To: 'David Greene' Cc: 'LLVM Developers Mailing List' Subject: Re: [LLVMdev] mem2reg optimization Hi Dave, As an exercise I tried to fix this myself, and I think I have a working patch (attached). My own tests are all working wonderfully, and at fantastic performance! I'm looking forward to your patch to see whether we used the same approach or whether things could be improved further. Anyway, I've re-profiled the code and found ComputeLiveInBlocks to be the main hotspot now. Again it uses a linear search over the instructions so there's a chance this can be optimized as well... Kind regards, Nicolas -----Original Message----- From: David Greene [mailto:dag at cray.com] Sent: Wednesday, 24 September, 2008 18:07 To: Nicolas Capens Cc: 'LLVM Developers Mailing List' Subject: Re: [LLVMdev] mem2reg optimization On Wednesday 24 September 2008 09:35, Nicolas Capens wrote: > Hi Dave, > > Did that patch of yours ever make it into trunk? I can't seem to find > any related checkin for PromoteMemoryToRegister.cpp. I've been doing > some extra > profiling lately and the RewriteSingleStoreAlloca function alone is > taking a whopping 63% of execution time. I will commit it today along with some other things. I've been having a lot of trouble building llvm-gcc but I think I've struggled enouigh now and will just hope our testing on this end has been enough. Thanks for the prod. -Dave From andrii.vasyliev at gmail.com Thu Sep 25 08:20:21 2008 From: andrii.vasyliev at gmail.com (Andrii Vasyliev) Date: Thu, 25 Sep 2008 16:20:21 +0300 Subject: [LLVMdev] Kaleidoscope doesn't work properly Message-ID: Hi I hope this is a proper place to put my question. I've compiled Kaleidoscope from "Adding JIT and Optimizer Support" tutorial. Basically it works just fine but when I try to run extern'ed putchard function it aborts. Please, tell me what am I doing wrong? Here is more information: My PC runs FreeBSD. I've copied the toy source code exactly and didn't change it. Here is the log: # ./toy ready> extern putchard(x); ready> Read extern: declare double @putchard(double) ready> def asd (a) putchard(a); ready> Read function definition: define double @asd(double %a) { entry: %calltmp = call double @putchard( double %a ) ; [#uses=1] ret double %calltmp } ready> asd(120); ready> ERROR: Program used external function 'putchard' which could not be resolved! Abort (core dumped) Here is the backtrace from the toy.core: (gdb) backtrace #0 0x4889cbb7 in kill () from /lib/libc.so.7 #1 0x4868d146 in raise () from /lib/libthr.so.3 #2 0x4889b76a in abort () from /lib/libc.so.7 #3 0x0831f8a0 in llvm::JIT::getPointerToNamedFunction () #4 0x0832177a in llvm::JIT::getPointerToFunction () #5 0x083275a2 in (anonymous namespace)::JITEmitter::getPointerToGlobal () #6 0x083280e4 in (anonymous namespace)::JITEmitter::finishFunction () #7 0x0805f8d0 in (anonymous namespace)::Emitter::runOnMachineFunction () #8 0x081deee8 in llvm::MachineFunctionPass::runOnFunction () #9 0x08561cd7 in llvm::FPPassManager::runOnFunction () #10 0x08562185 in llvm::FunctionPassManagerImpl::run () #11 0x08562337 in llvm::FunctionPassManager::run () #12 0x0831f9ec in llvm::JIT::runJITOnFunction () #13 0x08321847 in llvm::JIT::getPointerToFunction () #14 0x0804f680 in MainLoop () at toy.cpp:508 #15 0x0804ff12 in main () at toy.cpp:590 From marchesin at icps.u-strasbg.fr Thu Sep 25 08:51:49 2008 From: marchesin at icps.u-strasbg.fr (Stephane Marchesin) Date: Thu, 25 Sep 2008 15:51:49 +0200 Subject: [LLVMdev] Generating instruction bundles ? Message-ID: <6a89f9d50809250651k320bd036v78fa8fc396ccc783@mail.gmail.com> Hi, I'm retargetting llvm for a new architecture, basiclaly a target that has v4f32 registers and a few operations, so it's mostly common stuff. However, it also has some kind of options on top of the operations, kinda like VLIW. For example, there is an addition operation, but there is also a source operand negation bit which you can set. So you can implement SUB using the ADD opcode (and there is actually no SUB opcode proper). Besides negating the source operands, there are also bits to take the absolute value of the source operands as input, bits to scale the result by power of 2 constants, and bits to do arbitrary shuffling of the 4 components. Now obviously I'd like to take advantage of that. I have taken a look at the ia64 target which has similar requirements, and seen that it gets around the problem by using an external optimizing assembler that reorders and packs instructions into bundles. However since my requirements are so simple I'm hoping I can do everything inside llvm (and I'm only interested in JIT anyway). So I guess the question became obvious by now: how can I do this in llvm? I've been thinking about a couple of solutions: - Use the tablegen template system to generate all the variants for eacho operation (with/without absolute value, with/without negation, with/without post-scaling, with/without all kinds of shuffling, and all combinations of those). Is this possible ? We're talking about approximately 70000 variants per instruction here, approximately 300 if we ignore the shuffling which has 256 combinations by itself. - Use an additional pass that reorders and packs instructions together (similary to what the ia64 optimizing assembler does), maybe relying on the instruction scheduler to place the instructions for me. - Rewrite some of tablegen to support that feature. I'm under the impression it would be a lot of work for a very specific case, but I could be wrong here. Ideas ? Thanks in advance, Stephane From marks at dcs.gla.ac.uk Thu Sep 25 09:10:32 2008 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Thu, 25 Sep 2008 15:10:32 +0100 Subject: [LLVMdev] llvm-as and implicit value naming References: Message-ID: <58577CAC1C0FB34DAA24FA9DC76613F101664D70@ex1.ad.dcs.gla.ac.uk> Hi everyone, I don't know if this is a bug or I am misunderstanding things. I couldn't find anything in the Bugzilla database. The following code: 1 @sp = external global i8** ; 2 3 define void @test(i8* %x) { 4 entry: 5 load i8*** @sp ; :1 6 getelementptr i8** %1, i32 1 ; :2 7 store i8** %2, i8*** @sp, align 4 8 ret void 9 } causes llvm-as (version 2.3) to choke: llvm-as: test.ll:7,0: Reference to an invalid definition: #2 of type 'i8 * *' There are variations, such as: 1 @sp = external global i8** ; 2 3 define void @test(i32 %X) { 4 entry: 5 load i8*** @sp ; :1 6 getelementptr i8** %1, i32 -1 ; :2 7 store i8** %2, i8*** @sp, align 4 8 inttoptr i32 %X to i8* ; :3 9 store i8* %3, i8** %2, align 4 10 ret void 11} which produces llvm-as: test.ll:9,0: Numbered value (%2) of type 'i8 *' does not match expected type, 'i8 * *' I originally found this error when trying to assemble code produce by the PrintModule pass manager on code (many thousands of lines long) that had passed verification. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 2994 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080925/e59ae21d/attachment.bin From luked at cs.rochester.edu Thu Sep 25 09:28:20 2008 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Thu, 25 Sep 2008 10:28:20 -0400 Subject: [LLVMdev] confused about llvm.memory.barrier Message-ID: <48DBA004.6020309@cs.rochester.edu> When I request a write-before-read memory barrier on x86 I would expect to get an assembly instruction that would enforce this ordering (mfence, xchg, cas), but it just turns into a nop. 1. ; ModuleID = 'test.bc' 2. target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128" 3. target triple = "i686-apple-darwin9" 4. @a = external global i32 ; [#uses=1] 5. @b = external global i32 ; [#uses=1] 6. 7. define i32 @_Z3foov() nounwind { 8. entry: 9. store i32 1, i32* @a, align 4 10. tail call void @llvm.memory.barrier(i1 true, i1 true, \ i1 true, i1 true, \ i1 false) 11. %0 = load i32* @b, align 4 ; [#uses=1] 12. ret i32 %0 13. } 14. 15. declare void @llvm.memory.barrier(i1, i1, i1, i1, i1) nounwind compiled with: 1. llc -mcpu=core2 -mattr=+sse2,+sse3 -f -o test.s test.bc becomes 1. .text 2. .align 4,0x90 3. .globl __Z3foov 4. __Z3foov: 5. movl L_a$non_lazy_ptr, %eax 6. movl $1, (%eax) 7. nop 8. movl L_b$non_lazy_ptr, %eax 9. movl (%eax), %eax 10. ret 11. 12. .section __IMPORT,__pointers,non_lazy_symbol_pointers 13. L_a$non_lazy_ptr: 14. .indirect_symbol _a 15. .long 0 16. L_b$non_lazy_ptr: 17. .indirect_symbol _b 18. .long 0 19. .subsections_via_symbols Is the problem related to the fact that I get i386 from uname -m? If so, how can I tell override this setting during compilation? Thanks, Luke From skaflotten at gmail.com Thu Sep 25 09:29:25 2008 From: skaflotten at gmail.com (srs) Date: Thu, 25 Sep 2008 16:29:25 +0200 Subject: [LLVMdev] Kaleidoscope doesn't work properly In-Reply-To: References: Message-ID: <48DBA045.2090104@gmail.com> Link with -rdynamic or provide a mapping. /Stein Roger Andrii Vasyliev wrote: > Hi > > I hope this is a proper place to put my question. > > I've compiled Kaleidoscope from "Adding JIT and Optimizer Support" tutorial. > Basically it works just fine but when I try to run extern'ed putchard > function it aborts. > Please, tell me what am I doing wrong? > > Here is more information: > My PC runs FreeBSD. > I've copied the toy source code exactly and didn't change it. > > Here is the log: > # ./toy > ready> extern putchard(x); > ready> Read extern: > declare double @putchard(double) > > ready> def asd (a) putchard(a); > ready> Read function definition: > define double @asd(double %a) { > entry: > %calltmp = call double @putchard( double %a ) ; > [#uses=1] > ret double %calltmp > } > > ready> asd(120); > ready> ERROR: Program used external function 'putchard' which could > not be resolved! > Abort (core dumped) > > Here is the backtrace from the toy.core: > (gdb) backtrace > #0 0x4889cbb7 in kill () from /lib/libc.so.7 > #1 0x4868d146 in raise () from /lib/libthr.so.3 > #2 0x4889b76a in abort () from /lib/libc.so.7 > #3 0x0831f8a0 in llvm::JIT::getPointerToNamedFunction () > #4 0x0832177a in llvm::JIT::getPointerToFunction () > #5 0x083275a2 in (anonymous namespace)::JITEmitter::getPointerToGlobal () > #6 0x083280e4 in (anonymous namespace)::JITEmitter::finishFunction () > #7 0x0805f8d0 in (anonymous namespace)::Emitter::runOnMachineFunction () > #8 0x081deee8 in llvm::MachineFunctionPass::runOnFunction () > #9 0x08561cd7 in llvm::FPPassManager::runOnFunction () > #10 0x08562185 in llvm::FunctionPassManagerImpl::run () > #11 0x08562337 in llvm::FunctionPassManager::run () > #12 0x0831f9ec in llvm::JIT::runJITOnFunction () > #13 0x08321847 in llvm::JIT::getPointerToFunction () > #14 0x0804f680 in MainLoop () at toy.cpp:508 > #15 0x0804ff12 in main () at toy.cpp:590 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From shap at eros-os.com Thu Sep 25 09:41:11 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Thu, 25 Sep 2008 10:41:11 -0400 Subject: [LLVMdev] confused about llvm.memory.barrier In-Reply-To: <48DBA004.6020309@cs.rochester.edu> References: <48DBA004.6020309@cs.rochester.edu> Message-ID: <1222353674.4726.8.camel@shaptop.om-md.eros-os.com> On Thu, 2008-09-25 at 10:28 -0400, Luke Dalessandro wrote: > When I request a write-before-read memory barrier on x86 I would expect > to get an assembly instruction that would enforce this ordering (mfence, > xchg, cas), but it just turns into a nop. In its usual configuration, an x86 family CPU implements a strong memory ordering constraint for all loads and stores, so as long as the ordering of the read and write operations is preserved no atomic operation is required between them. XCHG and CAS only become necessary when you are coordinating reads and writes across processors. MFENCE similarly. So the current behavior of LLVM is correct, but there is a valid concern hiding here: there exist programs that intentionally alter the strong ordering contract in high-performance applications for the sake of performance, and in those applications it really is necessary to do some operation that suitably serializes the memory subsystem on the processor. The LLVM team may already have a better answer for this, but my first reaction is that this is effectively a different target architecture. My second, and possibly more interesting reaction is that a) There needs to be some means (through annotation) to insist that these instructions are not removed. Perhaps some means already exists; I have not looked. b) It might be interesting to examine whether coherency behavior could be handled as an attribute of address spaces in LLVM. Offhand, this would seem to require a notion of address spaces that are exact duplicates of each other except for coherency behavior, but there might be some cleaner way to handle that. The entire LLVM address space notion intrigues me, and I just haven't had any chance to dig in to it. shap From andrii.vasyliev at gmail.com Thu Sep 25 09:42:21 2008 From: andrii.vasyliev at gmail.com (Andrii Vasyliev) Date: Thu, 25 Sep 2008 17:42:21 +0300 Subject: [LLVMdev] Kaleidoscope doesn't work properly In-Reply-To: <48DBA045.2090104@gmail.com> References: <48DBA045.2090104@gmail.com> Message-ID: Thanks, -rdynamic helps! It's a pity that it's not written in the tutorial. Also I'm interested how can I provide a mapping? 2008/9/25 srs : > Link with -rdynamic or provide a mapping. From prakash.prabhu at gmail.com Thu Sep 25 09:47:13 2008 From: prakash.prabhu at gmail.com (Prakash Prabhu) Date: Thu, 25 Sep 2008 10:47:13 -0400 Subject: [LLVMdev] Memory Altering/Accessing Instructions In-Reply-To: <48DAA9C2.7090601@cs.uiuc.edu> References: <85a4cc050809241322p482cefe6k857f6018453d1985@mail.gmail.com> <48DAA9C2.7090601@cs.uiuc.edu> Message-ID: <85a4cc050809250747p5761de78p30be1a6c56ca9dd3@mail.gmail.com> Hi John, Thanks for the reply. I am planning to use this information as a part of Analysis, so I guess it should be ok since it is before code generation. - Prakash On Wed, Sep 24, 2008 at 4:57 PM, John Criswell wrote: > Prakash Prabhu wrote: >> Hi all, >> >> Would it be correct to say that the only instructions in LLVM IR that >> modify/access memory potentially are the following: >> > I believe that every instruction has a > mayWriteToMemory()/mayReadToMemory() method that you can use to > determine this information. See > http://llvm.org/doxygen/classllvm_1_1Instruction.html (the LLVM doxygen > info on llvm::Instruction) for more details. I believe these methods > describe whether memory is read/written in a way visible from the LLVM > IR; I don't believe they'll take into account things like read/writes > due to register spills created by the code generator. > >> (1) LoadInst : Ref >> (2) StoreInst : Mod >> (3) VAArgInst : Ref (?) >> (4) AllocaInst : Mod >> (5) MallocInst : Mod >> (6) FreeInst : Mod >> (7) CallInst : Mod/Ref ? >> >> Also, my earlier impression was that the GEP instruction only computes >> the effective address and does not modify/access any memory location. >> Is that true ? >> > This is correct. > >> If I have missed other instructions that could alter/modify memory, >> please let me know. >> >> Thanks for your time. >> > -- John T. >> - Prakash >> _______________________________________________ >> 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 luked at cs.rochester.edu Thu Sep 25 10:01:43 2008 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Thu, 25 Sep 2008 11:01:43 -0400 Subject: [LLVMdev] confused about llvm.memory.barrier In-Reply-To: <1222353674.4726.8.camel@shaptop.om-md.eros-os.com> References: <48DBA004.6020309@cs.rochester.edu> <1222353674.4726.8.camel@shaptop.om-md.eros-os.com> Message-ID: <48DBA7D7.5070702@cs.rochester.edu> Jonathan S. Shapiro wrote: > On Thu, 2008-09-25 at 10:28 -0400, Luke Dalessandro wrote: >> When I request a write-before-read memory barrier on x86 I would expect >> to get an assembly instruction that would enforce this ordering (mfence, >> xchg, cas), but it just turns into a nop. > > In its usual configuration, an x86 family CPU implements a strong memory > ordering constraint for all loads and stores, so as long as the ordering > of the read and write operations is preserved no atomic operation is > required between them. XCHG and CAS only become necessary when you are > coordinating reads and writes across processors. MFENCE similarly. IA32 (http://www.intel.com/products/processor/manuals/318147.pdf) always allows load bypassing. I found the problem. llvm-gcc compiles __sync_synchronize() ("a full memory barrier") as: 1. tail call void @llvm.memory.barrier(i1 true, i1 true, i1 true, i1 true, i1 false) As pointed out on IRC, that 5th parameter being false is what is generating the nop. If I go in and manually change it to true I get the mfence. Did llvm.memory.barrier always have 5 parameters? What's the purpose of the 5th? Why isn't requesting a ls barrier enough? I think this might be a change that llvm-gcc doesn't know about yet (yet == r56496). Luke > > So the current behavior of LLVM is correct, but there is a valid concern > hiding here: there exist programs that intentionally alter the strong > ordering contract in high-performance applications for the sake of > performance, and in those applications it really is necessary to do some > operation that suitably serializes the memory subsystem on the > processor. > > The LLVM team may already have a better answer for this, but my first > reaction is that this is effectively a different target architecture. My > second, and possibly more interesting reaction is that > > a) There needs to be some means (through annotation) to insist that > these instructions are not removed. Perhaps some means already > exists; I have not looked. > > b) It might be interesting to examine whether coherency behavior > could be handled as an attribute of address spaces in LLVM. > Offhand, this would seem to require a notion of address spaces that > are exact duplicates of each other except for coherency behavior, > but there might be some cleaner way to handle that. > > The entire LLVM address space notion intrigues me, and I just haven't > had any chance to dig in to it. > > > shap > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gessel at apple.com Thu Sep 25 10:18:20 2008 From: gessel at apple.com (Daniel M Gessel) Date: Thu, 25 Sep 2008 11:18:20 -0400 Subject: [LLVMdev] Generating instruction bundles ? In-Reply-To: <6a89f9d50809250651k320bd036v78fa8fc396ccc783@mail.gmail.com> References: <6a89f9d50809250651k320bd036v78fa8fc396ccc783@mail.gmail.com> Message-ID: <0F021509-4BAB-477C-98F6-487CA6BAEDA7@apple.com> I'm targeting an machine where the operands have a number of operations that are orthogonal to the instruction, but have the good fortune of there being an aggressively optimizing post pass. I've considered the same option - "folding" the operand options into the instructions, but as you point out, this causes an explosion in the number of instructions. Because of the post pass, I can afford to sequence operand options, and count on later optimization. However, it would be nice for me (necessary for you) to be more direct. I think an extended set of control bits in operands would be the most natural approach (to those of us used to working with such machines, at least), but you'd like to be able to have transformations in tablegen that let you do things like (fneg operand) -> operand with negate bit flipped I'm not sure exactly how this could be expressed (I'm admittedly new to compilers in general, LLVM in particular, so my limitations generally get in the way before LLVM's - my knowledge is more in the target machine). Dan On Sep 25, 2008, at 9:51 AM, Stephane Marchesin wrote: > Hi, > > I'm retargetting llvm for a new architecture, basiclaly a target that > has v4f32 registers and a few operations, so it's mostly common stuff. > However, it also has some kind of options on top of the operations, > kinda like VLIW. For example, there is an addition operation, but > there is also a source operand negation bit which you can set. So you > can implement SUB using the ADD opcode (and there is actually no SUB > opcode proper). Besides negating the source operands, there are also > bits to take the absolute value of the source operands as input, bits > to scale the result by power of 2 constants, and bits to do arbitrary > shuffling of the 4 components. Now obviously I'd like to take > advantage of that. > > I have taken a look at the ia64 target which has similar requirements, > and seen that it gets around the problem by using an external > optimizing assembler that reorders and packs instructions into > bundles. However since my requirements are so simple I'm hoping I can > do everything inside llvm (and I'm only interested in JIT anyway). > > So I guess the question became obvious by now: how can I do this in > llvm? I've been thinking about a couple of solutions: > - Use the tablegen template system to generate all the variants for > eacho operation (with/without absolute value, with/without negation, > with/without post-scaling, with/without all kinds of shuffling, and > all combinations of those). Is this possible ? We're talking about > approximately 70000 variants per instruction here, approximately 300 > if we ignore the shuffling which has 256 combinations by itself. > - Use an additional pass that reorders and packs instructions together > (similary to what the ia64 optimizing assembler does), maybe relying > on the instruction scheduler to place the instructions for me. > - Rewrite some of tablegen to support that feature. I'm under the > impression it would be a lot of work for a very specific case, but I > could be wrong here. > > Ideas ? > > Thanks in advance, > Stephane > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From Dr.Graef at t-online.de Thu Sep 25 10:27:04 2008 From: Dr.Graef at t-online.de (Albert Graef) Date: Thu, 25 Sep 2008 17:27:04 +0200 Subject: [LLVMdev] Kaleidoscope doesn't work properly In-Reply-To: References: Message-ID: <48DBADC8.6080008@t-online.de> Andrii Vasyliev wrote: > I've compiled Kaleidoscope from "Adding JIT and Optimizer Support" tutorial. > Basically it works just fine but when I try to run extern'ed putchard > function it aborts. > Please, tell me what am I doing wrong? Have you tried to link with -rdynamic (Linux-specific, not needed on OSX or Windows)? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From evan.cheng at apple.com Thu Sep 25 10:59:22 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 25 Sep 2008 08:59:22 -0700 Subject: [LLVMdev] Generating instruction bundles ? In-Reply-To: <6a89f9d50809250651k320bd036v78fa8fc396ccc783@mail.gmail.com> References: <6a89f9d50809250651k320bd036v78fa8fc396ccc783@mail.gmail.com> Message-ID: On Sep 25, 2008, at 6:51 AM, Stephane Marchesin wrote: > > So I guess the question became obvious by now: how can I do this in > llvm? I've been thinking about a couple of solutions: > - Use the tablegen template system to generate all the variants for > eacho operation (with/without absolute value, with/without negation, > with/without post-scaling, with/without all kinds of shuffling, and > all combinations of those). Is this possible ? We're talking about > approximately 70000 variants per instruction here, approximately 300 > if we ignore the shuffling which has 256 combinations by itself. > - Use an additional pass that reorders and packs instructions together > (similary to what the ia64 optimizing assembler does), maybe relying > on the instruction scheduler to place the instructions for me. > - Rewrite some of tablegen to support that feature. I'm under the > impression it would be a lot of work for a very specific case, but I > could be wrong here. LLVM codegen is missing some pieces for wide machines. So you should expect to roll up your sleeves and write your own. :-) I am not sure if I completely understand the description. Is an instruction bundle made up of fixed number operations? If so, you could model each operation as a separate machine instruction. You can add a "bundle formation" (using e.g. bottom up greedy or clustering technique) pass to reorder instructions to form the bundles. Evan > > > Ideas ? > > Thanks in advance, > Stephane > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Thu Sep 25 11:01:41 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 25 Sep 2008 09:01:41 -0700 Subject: [LLVMdev] Cannot Select ConstantFP on x86 In-Reply-To: <200809241911.07519.dag@cray.com> References: <200809241911.07519.dag@cray.com> Message-ID: <96610EBC-7AAE-40CD-85B1-3B085E940337@apple.com> On Sep 24, 2008, at 5:11 PM, David Greene wrote: > I just ran into this today with x86-64: > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > of the > constant 1 and hapilly folds it into a ConstantFP<1>. ISel then > blows up > because there's no pattern for it. Sounds like a bug if dag combiner is doing this after legalization. DAG combiner should never form anything that's illegal after legalization has completed. Evan > > > Does this look familiar to anyone? I don't see any relevant bugs in > the > database. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Thu Sep 25 11:32:41 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 25 Sep 2008 09:32:41 -0700 Subject: [LLVMdev] Multi-Instruction Patterns In-Reply-To: <200809241506.01702.dag@cray.com> References: <200809231326.47393.dag@cray.com> <200809241115.12889.dag@cray.com> <200809241506.01702.dag@cray.com> Message-ID: <694D031B-F34B-4A27-BB81-94334FFB6CDF@apple.com> On Sep 24, 2008, at 1:06 PM, David Greene wrote: >>> >> >> As Dan pointed out, #2 is also a workable solution. > > Yes, I like Dan's proposal. Hmmm... Perhaps Dan should implement this. :-) > > >>> What about getting tblgen support for the pattern in the .td file? >>> That would >>> be another way to tackle this and would open up a whole bunch of >>> other >>> opportunities. Instcombine could be entirely expressed as a set of >>> tblgen >>> patterns, for example, which is desireable from a maintenance >>> perspective >>> and well as new development. It's much easier to write patterns >>> than to go >>> through all of the manual examination that currently exists in >>> instcombine. >> >> I don't think that would work. We still have to model the value as >> being produced by an instruction. So either we have to select it to a >> target specific instruction or a target independent instruction (i.e. >> extract_subreg). > > That's right. The pattern doesn't know if the rest of the vector is > going to > be used elsewhere so we need dataflow information and that implies > it needs to > be done in the coalescer (or some other transformation pass). > >> After thinking about this some more, I think #2 is a better solution. >> Adding XMM0_32 etc. teaches codegen that only lower 32-bits of the >> registers are used. Perhaps this can open up additional optimization >> opportunities. On the other hand, adding these registers means >> introducing more aliasing which has compile time implication. > > What about XMM0_64? What about things like AVX which applies the > GPR aliasing > scheme to vectors? I think this is the right way to go but we need > to do > things in a comprehensive way so we can expand as needed. They will be handled the same way. Please file a bug. We'll get to it. Thanks, Evan > > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From marchesin at icps.u-strasbg.fr Thu Sep 25 11:58:26 2008 From: marchesin at icps.u-strasbg.fr (Stephane Marchesin) Date: Thu, 25 Sep 2008 18:58:26 +0200 Subject: [LLVMdev] Generating instruction bundles ? In-Reply-To: References: <6a89f9d50809250651k320bd036v78fa8fc396ccc783@mail.gmail.com> Message-ID: <6a89f9d50809250958h336aa8e1hed3572e90b9602a7@mail.gmail.com> On Thu, Sep 25, 2008 at 5:59 PM, Evan Cheng wrote: > > On Sep 25, 2008, at 6:51 AM, Stephane Marchesin wrote: > > > LLVM codegen is missing some pieces for wide machines. So you should > expect to roll up your sleeves and write your own. :-) Yeah, I'm not sure if that could be tackled by a newcomer though... > > I am not sure if I completely understand the description. Is an > instruction bundle made up of fixed number operations? Well, the bundle has one "major" operation (add, mul, mad...) and a couple of "additional" operations that will modify the inputs/outputs of the major operation. It's not exactly VLIW in that the additional operations don't change the value of a register, but instead change the inputs and outputs of the major operation. Or to put it differently, you could see the additional operations as some kind of data routing to and from the major operation. And yes, there is always exactly one major operation, and there are bits allocated for each of the additional operations for each input/output. So you can do abs+neg+shuffle on all inputs and scaling on the output, and the instruction is still 128 bit. > If so, you > could model each operation as a separate machine instruction. You can > add a "bundle formation" (using e.g. bottom up greedy or clustering > technique) pass to reorder instructions to form the bundles. Yes, that's the second point I had in mind. That solution is becoming increasingly interesting to me since I don't think I can tackle modifying llvm overnight :) Stephane From Micah.Villmow at amd.com Thu Sep 25 12:49:09 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Thu, 25 Sep 2008 10:49:09 -0700 Subject: [LLVMdev] Going from argument to register and back Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C12E1C4@ssanexmb1.amd.com> I am having trouble trying to figure out two pieces of information from attempting to map arguments to registers. How do I determine, based on the argument name, which register the value is supposed to be assigned to? I can hard-coded it currently and it will be correct 100% of the time with the current set of assumptions, but I would rather determine it dynamically so that I can change my assumptions and still get the right results. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080925/ee679c43/attachment.html From dag at cray.com Thu Sep 25 13:15:14 2008 From: dag at cray.com (David Greene) Date: Thu, 25 Sep 2008 13:15:14 -0500 Subject: [LLVMdev] mem2reg optimization In-Reply-To: <002d01c91f0b$d8510720$88f31560$@net> References: <000401c8fbc2$b48680c0$1d938240$@net> <200809241107.00123.dag@cray.com> <002d01c91f0b$d8510720$88f31560$@net> Message-ID: <200809251315.15499.dag@cray.com> On Thursday 25 September 2008 07:40, Nicolas Capens wrote: > Hi Dave, > > As an exercise I tried to fix this myself, and I think I have a working > patch (attached). My own tests are all working wonderfully, and at > fantastic performance! > > I'm looking forward to your patch to see whether we used the same approach > or whether things could be improved further. > > Anyway, I've re-profiled the code and found ComputeLiveInBlocks to be the > main hotspot now. Again it uses a linear search over the instructions so > there's a chance this can be optimized as well... I don't quite understand how the logic of your patch is the same. In the original code, we're looking for a Load that uses the alloca before it is stored. Your code loops through the use list, first looking for the use that is the store. It then keeps going and if it sees a match with a load, it prevents promotion. Are use lists guaranteed to be ordered in reverse instruction order? That is instructions that use values later appear earlier in the use list? Can we really rely on ordering of the use list? My patch builds a map from BasicBlock to lists of loads and stores in that block in an initialization phase along with ordering information about the loads and stores. RewriteSingleStoreAlloca then queries that information to determine if a load appears before the single store. I like your approach of using the use lists but I'm not sure the ordering is guaranteed. If it is, your approach is superior. -Dave From tjablin at CS.Princeton.EDU Thu Sep 25 17:04:54 2008 From: tjablin at CS.Princeton.EDU (Thomas B. Jablin) Date: Thu, 25 Sep 2008 18:04:54 -0400 (EDT) Subject: [LLVMdev] CallTargets Analysis Incorrect In-Reply-To: <1482329862.57471222376508415.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Message-ID: <1761334330.58171222380294054.JavaMail.root@suckerpunch-mbx-0.CS.Princeton.EDU> Hi, The call target pass in the poolalloc suite yields an incorrect output for the following short test program: #include struct OP { void (*func)(struct OP*); }; void bar(struct OP *op); void foo(struct OP *op) { printf("Foo\n"); op->func = bar; } void bar(struct OP *op) { printf("Bar\n"); op->func = foo; } int main(int argc, char **argv) { int i; struct OP op; op.func = foo; for(i = 0; i < 10; ++i) { op.func(&op); } return 0; } Specifically, pass indicates that indirect function call in the main function may call the foo method and that the the list of callees is complete. In fact, the indirect function call can target both the foo and bar methods, so the list should be marked incomplete, or should include the other callees. Thanks. Tom From clattner at apple.com Thu Sep 25 19:12:22 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 25 Sep 2008 17:12:22 -0700 Subject: [LLVMdev] Cannot Select ConstantFP on x86 In-Reply-To: <200809241911.07519.dag@cray.com> References: <200809241911.07519.dag@cray.com> Message-ID: <4379EE22-393C-4D93-931E-8F722AA2D0F6@apple.com> On Sep 24, 2008, at 5:11 PM, David Greene wrote: > I just ran into this today with x86-64: > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > of the > constant 1 and hapilly folds it into a ConstantFP<1>. ISel then > blows up > because there's no pattern for it. > > Does this look familiar to anyone? I don't see any relevant bugs in > the > database. Do you have a testcase? It sounds like something that would be easy to fix. -Chris From haohui.mai at gmail.com Thu Sep 25 22:07:18 2008 From: haohui.mai at gmail.com (Haohui Mai) Date: Thu, 25 Sep 2008 22:07:18 -0500 Subject: [LLVMdev] Kaleidoscope doesn't work properly In-Reply-To: References: <48DBA045.2090104@gmail.com> Message-ID: <4697D7BA-8251-4DB8-8DFC-3D8C1C85412F@gmail.com> I've already filed a bug report but nobody cares :-( Is it possible to fix the documentation? Because I think the tutorial is really important to beginners, which should not be misleading. -- Haohui On Sep 25, 2008, at 9:42 AM, Andrii Vasyliev wrote: > Thanks, -rdynamic helps! It's a pity that it's not written in the > tutorial. > > Also I'm interested how can I provide a mapping? > > 2008/9/25 srs : >> Link with -rdynamic or provide a mapping. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ofv at wanadoo.es Thu Sep 25 22:34:38 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Fri, 26 Sep 2008 05:34:38 +0200 Subject: [LLVMdev] Kaleidoscope doesn't work properly References: <48DBA045.2090104@gmail.com> <4697D7BA-8251-4DB8-8DFC-3D8C1C85412F@gmail.com> Message-ID: Haohui Mai writes: > I've already filed a bug report but nobody cares :-( > > Is it possible to fix the documentation? Because I think the tutorial > is really important to beginners, which should not be misleading. > >> Thanks, -rdynamic helps! It's a pity that it's not written in the >> tutorial. >> >> Also I'm interested how can I provide a mapping? >> >>> Link with -rdynamic or provide a mapping. Which is the id number of the bug you filed? I don't see any bugs related to Kaleidoscope on the last two days. And be reassured that people here care about bugs, but they are not *that* fast that *always* fixes them on less than 24 hours :-) -- Oscar From clattner at apple.com Thu Sep 25 23:54:54 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 25 Sep 2008 21:54:54 -0700 Subject: [LLVMdev] Kaleidoscope doesn't work properly In-Reply-To: <4697D7BA-8251-4DB8-8DFC-3D8C1C85412F@gmail.com> References: <48DBA045.2090104@gmail.com> <4697D7BA-8251-4DB8-8DFC-3D8C1C85412F@gmail.com> Message-ID: <0AA4C86F-5EFB-4F83-A5B2-CF725E6C3C7C@apple.com> On Sep 25, 2008, at 8:07 PM, Haohui Mai wrote: > I've already filed a bug report but nobody cares :-( > > Is it possible to fix the documentation? Because I think the tutorial > is really important to beginners, which should not be misleading. Please suggest a change to apply (either in patch form, or "add these words here in the tutorial") and I'll be happy to do it. -Chris From haohui.mai at gmail.com Thu Sep 25 23:54:58 2008 From: haohui.mai at gmail.com (Haohui Mai) Date: Thu, 25 Sep 2008 23:54:58 -0500 Subject: [LLVMdev] Kaleidoscope doesn't work properly In-Reply-To: References: <48DBA045.2090104@gmail.com> <4697D7BA-8251-4DB8-8DFC-3D8C1C85412F@gmail.com> Message-ID: <48dc6b3a.1c1d640a.250f.ffffa6cd@mx.google.com> Not exactly the same, but I think it is the same problem. http://llvm.org/bugs/show_bug.cgi?id=2712 -- Haohui -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ?scar Fuentes Sent: Thursday, September 25, 2008 10:35 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Kaleidoscope doesn't work properly Haohui Mai writes: > I've already filed a bug report but nobody cares :-( > > Is it possible to fix the documentation? Because I think the tutorial > is really important to beginners, which should not be misleading. > >> Thanks, -rdynamic helps! It's a pity that it's not written in the >> tutorial. >> >> Also I'm interested how can I provide a mapping? >> >>> Link with -rdynamic or provide a mapping. Which is the id number of the bug you filed? I don't see any bugs related to Kaleidoscope on the last two days. And be reassured that people here care about bugs, but they are not *that* fast that *always* fixes them on less than 24 hours :-) -- Oscar _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From mattgiuca at gmail.com Fri Sep 26 01:05:45 2008 From: mattgiuca at gmail.com (Matt Giuca) Date: Thu, 25 Sep 2008 23:05:45 -0700 (PDT) Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: References: Message-ID: <19683007.post@talk.nabble.com> Marc de Kruijf wrote: > > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > really weird stuff -- unwinds are ending up in seemingly arbitrary > places... > definitely not inside the caller's unwind block My target is x86. > > As a simple test, I tried to compile the following code and I got a > segmentation fault. It looks good to me. Can someone help me out or is > this a bug? > Marc, I tried the exact same example as you did, and got the same issue. If you look at the generated x86 machine code, it looks like unwind is compiled into nothing at all: > foo: > .Leh_func_begin1: > > .Llabel1: > .size foo, .-foo > .Leh_func_end1: > (Note that there isn't even a return instruction). This means your execution just falls through into the following function without unwinding its own stack frame. In the above example, this causes it to fall into main and push another stack frame for main, over and over again until it runs out of stack space and segfaults. I can't find any information about cxa_throw at all, not even a type signature. If I could, could I just call it as if it were unwind, and it would be caught by invoke? The function cxa_throw appears to be in libstdc++ in GCC - I can find it in the object file, but not the source code documentation. Calling it instead of the LLVM "unwind" instruction seems like an epically nasty hack; totally undocumented and platform-specific. Maybe I'm misunderstanding the unwind instruction. The http://llvm.org/pubs/2004-01-30-CGO-LLVM.pdf 2004 paper describes exceptions in some detail. They use some front-end specific code for allocating the exception (eg. __llvm_cxxeh_throw), but then call unwind to actually unwind the stack. Are you saying that you need to do something (like call cxa_throw) in*stead* of calling unwind, or as well as calling unwind? In other words, if LLVM didn't have this "bug", should Marc's code work fine, or is there still something else needed? This discovery is pretty disappointing ... I've been reading the LLVM documentation for a few days, and everything I've read led me to believe it had built-in exception handling. If unwind is supposed to work the way Marc and I are assuming, but in fact just compiles into nothing, then this really ought to be documented, and the assembler should give a warning or something if you use it. As it stands, there's no warning that the unwind instruction is totally being ignored (which is made particularly nasty because it's recognised as a block terminator, and therefore it allows successful compilation even when not followed by a ret instruction, where an empty statement would not). In the mean time, can anyone suggest a fix for Marc's dummy example which works in the current version of LLVM (even if it's platform specific)? -- View this message in context: http://www.nabble.com/Unwinds-Gone-Wild-tp18747589p19683007.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From clattner at apple.com Fri Sep 26 01:52:33 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 25 Sep 2008 23:52:33 -0700 Subject: [LLVMdev] llvm-as and implicit value naming In-Reply-To: <58577CAC1C0FB34DAA24FA9DC76613F101664D70@ex1.ad.dcs.gla.ac.uk> References: <58577CAC1C0FB34DAA24FA9DC76613F101664D70@ex1.ad.dcs.gla.ac.uk> Message-ID: <211FDAF9-E280-4D1C-942E-4F77763C2D54@apple.com> On Sep 25, 2008, at 7:10 AM, Mark Shannon wrote: > Hi everyone, > > I don't know if this is a bug or I am misunderstanding things. > I couldn't find anything in the Bugzilla database. > > The following code: > > 1 @sp = external global i8** ; > 2 > 3 define void @test(i8* %x) { > 4 entry: > 5 load i8*** @sp ; :1 > 6 getelementptr i8** %1, i32 1 ; :2 > 7 store i8** %2, i8*** @sp, align 4 > 8 ret void > 9 } > > causes llvm-as (version 2.3) to choke: > llvm-as: test.ll:7,0: Reference to an invalid definition: #2 of type > 'i8 * *' First, note that the comments ("; ...") are completely ignored. I assume that there was another line, that you deleted. Because of that, line #5 actually defines %0 (not %1). Because of that, line 6 defines %1, and there is no %2. > There are variations, such as: > > 1 @sp = external global i8** ; > 2 > 3 define void @test(i32 %X) { > 4 entry: > 5 load i8*** @sp ; :1 > 6 getelementptr i8** %1, i32 -1 ; :2 > 7 store i8** %2, i8*** @sp, align 4 > 8 inttoptr i32 %X to i8* ; :3 > 9 store i8* %3, i8** %2, align 4 > 10 ret void > 11} > > which produces > llvm-as: test.ll:9,0: Numbered value (%2) of type 'i8 *' does not > match expected type, 'i8 * *' This is the same sort of thing, because you're off by one, you're referring to the wrong value. -Chris From baldrick at free.fr Fri Sep 26 02:49:12 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 26 Sep 2008 09:49:12 +0200 Subject: [LLVMdev] confused about llvm.memory.barrier In-Reply-To: <1222353674.4726.8.camel@shaptop.om-md.eros-os.com> References: <48DBA004.6020309@cs.rochester.edu> <1222353674.4726.8.camel@shaptop.om-md.eros-os.com> Message-ID: <200809260949.12999.baldrick@free.fr> Consider the following example (A and B are global variables that initially contain 0): Processor 1: store 1, A x = load B Processor 2: store 1, B y = load A Is it possible to end up with x = 0 and y = 0? Yes! This is exactly the example in table 2.3.a of http://www.intel.com/products/processor/manuals/318147.pdf. Yet it seems impossible to use gcc memory barriers to prevent this, since they compile to nothing on x86... Ciao, Duncan. From baldrick at free.fr Fri Sep 26 03:00:54 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 26 Sep 2008 10:00:54 +0200 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <19683007.post@talk.nabble.com> References: <19683007.post@talk.nabble.com> Message-ID: <200809261000.54992.baldrick@free.fr> > If you look at the generated x86 machine code, it looks like unwind is > compiled into nothing at all: Yes, unwind is currently not supported by the code generators. This is bad, but not that easy to fix (hopefully one day...). > I can't find any information about cxa_throw at all, not even a type > signature. If I could, could I just call it as if it were unwind, and it > would be caught by invoke? cxa_throw comes from the gcc C++ runtime. In order to see how to throw and catch things correctly using it, compile some C++ examples down to bitcode using llvm-g++. > This discovery is pretty disappointing ... I've been reading the LLVM > documentation for a few days, and everything I've read led me to believe it > had built-in exception handling. If unwind is supposed to work the way Marc > and I are assuming, but in fact just compiles into nothing, then this really > ought to be documented, and the assembler should give a warning or something > if you use it. As it stands, there's no warning that the unwind instruction > is totally being ignored (which is made particularly nasty because it's > recognised as a block terminator, and therefore it allows successful > compilation even when not followed by a ret instruction, where an empty > statement would not). The exception handling stuff needed by llvm-gcc is fully supported. Once that was done I guess everyone took a breather and kind of forgot about unwind :) I agree that it would be better to have the code generators abort if they see an unwind. > In the mean time, can anyone suggest a fix for Marc's dummy example which > works in the current version of LLVM (even if it's platform specific)? You currently have to use a gcc library routine. At some point cxa_throw and the analogous routines for other languages end up calling _Unwind_RaiseException. You may want to use that along with the C personality __gcc_personality_v0. Ciao, Duncan. From baldrick at free.fr Fri Sep 26 03:02:49 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 26 Sep 2008 10:02:49 +0200 Subject: [LLVMdev] llvm-as and implicit value naming In-Reply-To: <211FDAF9-E280-4D1C-942E-4F77763C2D54@apple.com> References: <58577CAC1C0FB34DAA24FA9DC76613F101664D70@ex1.ad.dcs.gla.ac.uk> <211FDAF9-E280-4D1C-942E-4F77763C2D54@apple.com> Message-ID: <200809261002.49132.baldrick@free.fr> Using the -instnamer pass (via opt) is a good way to give everything a name and avoid this kind of trouble when making modifications by hand. Ciao, Duncan. From Gobaan_Raveendran at amis.com Thu Sep 25 13:29:55 2008 From: Gobaan_Raveendran at amis.com (Gobi) Date: Thu, 25 Sep 2008 18:29:55 +0000 (UTC) Subject: [LLVMdev] Named Address Spaces References: <20080924214855.GX15228@katherina.student.utwente.nl> <1222340170.3167.5.camel@idc-lt-i00171.microchip.com> Message-ID: > We plan to use the address space info in backend to support the "rom" > address space for our target in near future. This will likely relate to what I am doing, however, my manager and I are currently trying to plan the entire toolchain, and key aspects involve both propogating debug information and verifying variables using named address spaces. From dag at cray.com Fri Sep 26 10:38:39 2008 From: dag at cray.com (David Greene) Date: Fri, 26 Sep 2008 10:38:39 -0500 Subject: [LLVMdev] Determining the register type of a MachineOperand In-Reply-To: <1413AD2F-BF58-481C-8F0A-34F2803F300E@apple.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA2B2@ssanexmb1.amd.com> <5BA674C5FF7B384A92C2C95D8CC71E1C0BA435@ssanexmb1.amd.com> <1413AD2F-BF58-481C-8F0A-34F2803F300E@apple.com> Message-ID: <200809261038.40052.dag@cray.com> On Wednesday 24 September 2008 15:23, Mon Ping Wang wrote: > To my knowledge, I don't think there is an easy way to get the MVT > information from a MachineOperand. Why do you need it for? In my See the thread I started on this very topic. Spilling is one place you'd like to have this information. > mind, the MachineInstr and its associated operands represent a > physical machine instruction and I typically want to think of those as > machine opcodes and machine register files. I am typically interested > in the mapping of MVTs to register classes when I'm generating machine > instructions. Note that a register class may map to multiple MVTs > depending on your description. Right, but the instruction opcode should give a clue about what the bits represent. That mapping is what's currently missing. -Dave From dag at cray.com Fri Sep 26 10:41:57 2008 From: dag at cray.com (David Greene) Date: Fri, 26 Sep 2008 10:41:57 -0500 Subject: [LLVMdev] mem2reg optimization In-Reply-To: <200809251315.15499.dag@cray.com> References: <000401c8fbc2$b48680c0$1d938240$@net> <002d01c91f0b$d8510720$88f31560$@net> <200809251315.15499.dag@cray.com> Message-ID: <200809261041.57779.dag@cray.com> On Thursday 25 September 2008 13:15, David Greene wrote: > My patch builds a map from BasicBlock to lists of loads and stores in that > block in an initialization phase along with ordering information about the > loads and stores. RewriteSingleStoreAlloca then queries that information > to determine if a load appears before the single store. > > I like your approach of using the use lists but I'm not sure the ordering > is guaranteed. If it is, your approach is superior. I got my patch updated to work with TOT. Here it is. Comments welcome. I still prefer Nicolas' solution if his use list ordering assumption is valid. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: mem2reg.patch Type: text/x-diff Size: 24366 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080926/314910ae/attachment.bin From dag at cray.com Fri Sep 26 10:43:00 2008 From: dag at cray.com (David Greene) Date: Fri, 26 Sep 2008 10:43:00 -0500 Subject: [LLVMdev] Cannot Select ConstantFP on x86 In-Reply-To: <4379EE22-393C-4D93-931E-8F722AA2D0F6@apple.com> References: <200809241911.07519.dag@cray.com> <4379EE22-393C-4D93-931E-8F722AA2D0F6@apple.com> Message-ID: <200809261043.01095.dag@cray.com> On Thursday 25 September 2008 19:12, Chris Lattner wrote: > On Sep 24, 2008, at 5:11 PM, David Greene wrote: > > I just ran into this today with x86-64: > > > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > > of the > > constant 1 and hapilly folds it into a ConstantFP<1>. ISel then > > blows up > > because there's no pattern for it. > > > > Does this look familiar to anyone? I don't see any relevant bugs in > > the > > database. > > Do you have a testcase? It sounds like something that would be easy > to fix. I have a fix (yes, it was trivial). I'll have to see about a testcase as it's proprietary code. -Dave From andrewl at lenharth.org Fri Sep 26 10:56:09 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Fri, 26 Sep 2008 10:56:09 -0500 Subject: [LLVMdev] mem2reg optimization In-Reply-To: <200809261041.57779.dag@cray.com> References: <000401c8fbc2$b48680c0$1d938240$@net> <002d01c91f0b$d8510720$88f31560$@net> <200809251315.15499.dag@cray.com> <200809261041.57779.dag@cray.com> Message-ID: <85dfcd7f0809260856n39bd0c90j7ea479c1e673760b@mail.gmail.com> On Fri, Sep 26, 2008 at 10:41 AM, David Greene wrote: > On Thursday 25 September 2008 13:15, David Greene wrote: >> I like your approach of using the use lists but I'm not sure the ordering >> is guaranteed. If it is, your approach is superior. > > I got my patch updated to work with TOT. Here it is. Comments welcome. > I still prefer Nicolas' solution if his use list ordering assumption is valid. Isn't the ordering an artifact of the creation of the users? If you run mem2reg after other optimizations, why would you still have any ordering guarantees? Andrew From Micah.Villmow at amd.com Fri Sep 26 10:59:18 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Fri, 26 Sep 2008 08:59:18 -0700 Subject: [LLVMdev] Determining the register type of a MachineOperand In-Reply-To: <200809261038.40052.dag@cray.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA2B2@ssanexmb1.amd.com><5BA674C5FF7B384A92C2C95D8CC71E1C0BA435@ssanexmb1.amd.com><1413AD2F-BF58-481C-8F0A-34F2803F300E@apple.com> <200809261038.40052.dag@cray.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C12E374@ssanexmb1.amd.com> Yes, Another reason this is useful is for register-type specific representations of said register. For example, all my registers are 128bit vector registers, however, if I am only dealing with 32 bit vector registers, I can add write/read masks that tell the underlying hardware not to work on the whole register, but just a subset of the components. 32bit scalar mov: mov r1.x___, r0.x000 64bit scalar mov: mov r1.xy__, r0.xy00 96bit scalar mov: mov r1.xyz_, r0.xyz0 128bit scalar mov: mov r1, r0 If I had the register type information at code generation time, then I can use the exact same tablegen pattern for all my register types and would only need to add the write/read masks in the printer instead of multiple patterns. Multiply this by over 100 opcodes and I save A LOT of work. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David Greene Sent: Friday, September 26, 2008 8:39 AM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Determining the register type of a MachineOperand On Wednesday 24 September 2008 15:23, Mon Ping Wang wrote: > To my knowledge, I don't think there is an easy way to get the MVT > information from a MachineOperand. Why do you need it for? In my See the thread I started on this very topic. Spilling is one place you'd like to have this information. > mind, the MachineInstr and its associated operands represent a > physical machine instruction and I typically want to think of those as > machine opcodes and machine register files. I am typically interested > in the mapping of MVTs to register classes when I'm generating machine > instructions. Note that a register class may map to multiple MVTs > depending on your description. Right, but the instruction opcode should give a clue about what the bits represent. That mapping is what's currently missing. -Dave _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dag at cray.com Fri Sep 26 11:00:48 2008 From: dag at cray.com (David Greene) Date: Fri, 26 Sep 2008 11:00:48 -0500 Subject: [LLVMdev] confused about llvm.memory.barrier In-Reply-To: <1222353674.4726.8.camel@shaptop.om-md.eros-os.com> References: <48DBA004.6020309@cs.rochester.edu> <1222353674.4726.8.camel@shaptop.om-md.eros-os.com> Message-ID: <200809261100.48846.dag@cray.com> On Thursday 25 September 2008 09:41, Jonathan S. Shapiro wrote: > In its usual configuration, an x86 family CPU implements a strong memory > ordering constraint for all loads and stores, so as long as the ordering > of the read and write operations is preserved no atomic operation is > required between them. XCHG and CAS only become necessary when you are > coordinating reads and writes across processors. MFENCE similarly. That's not quite true. If you use non-temporal stores you need a way to generate a real mfence. > So the current behavior of LLVM is correct, but there is a valid concern > hiding here: there exist programs that intentionally alter the strong > ordering contract in high-performance applications for the sake of > performance, and in those applications it really is necessary to do some > operation that suitably serializes the memory subsystem on the > processor. This is going to become more and more common on x86. > The LLVM team may already have a better answer for this, but my first > reaction is that this is effectively a different target architecture. My > second, and possibly more interesting reaction is that No, it's not a separate target architecture. That would be overkill. > a) There needs to be some means (through annotation) to insist that > these instructions are not removed. Perhaps some means already > exists; I have not looked. As Luke discovered, it's the argument to llvm.memory.barrier that make the difference. See X86InstrSSE.td. > b) It might be interesting to examine whether coherency behavior > could be handled as an attribute of address spaces in LLVM. > Offhand, this would seem to require a notion of address spaces that > are exact duplicates of each other except for coherency behavior, > but there might be some cleaner way to handle that. That's an interesting thought as that's exactly how WC and non-WC memory is described in the Opteron manuals. -Dave From dag at cray.com Fri Sep 26 11:02:29 2008 From: dag at cray.com (David Greene) Date: Fri, 26 Sep 2008 11:02:29 -0500 Subject: [LLVMdev] PassManager Dependence Question In-Reply-To: <092C9A0C-D012-416B-BF03-832C5282074A@apple.com> References: <200809191711.43309.dag@cray.com> <200809191720.31980.dag@cray.com> <092C9A0C-D012-416B-BF03-832C5282074A@apple.com> Message-ID: <200809261102.29886.dag@cray.com> On Friday 19 September 2008 22:38, Chris Lattner wrote: > > I noticed that the Verifier takes a VERY long time on large > > programs. This > > appears to be due to its checking of defs dominating uses. When a def > > and use are in the same BasicBlock, DominatorTrees iterates over the > > block until it finds one or the other. Since Verifier does this for > > each > > Instruction, this is an n^2 algorithm. > > The verifier case is easy to fix. Can you please send me a testcase? Not the one I have, unfortunately. It's code we can't release. I can try to write an artificial test. Can you outline the fix in general? -Dave From wanderon at comcast.net Fri Sep 26 11:10:57 2008 From: wanderon at comcast.net (Wayne Anderson) Date: Fri, 26 Sep 2008 10:10:57 -0600 Subject: [LLVMdev] Stacker Example Message-ID: <14998BCC-172D-4FF9-A458-81B5D86BA492@comcast.net> Hello, I was wondering what happened to the "Stacker" example. The old link to it "http://llvm.org/docs/Stacker.html" is dead. Thanks, Wayne ________________ Wayne Anderson From dag at cray.com Fri Sep 26 11:13:30 2008 From: dag at cray.com (David Greene) Date: Fri, 26 Sep 2008 11:13:30 -0500 Subject: [LLVMdev] mem2reg optimization In-Reply-To: <85dfcd7f0809260856n39bd0c90j7ea479c1e673760b@mail.gmail.com> References: <000401c8fbc2$b48680c0$1d938240$@net> <200809261041.57779.dag@cray.com> <85dfcd7f0809260856n39bd0c90j7ea479c1e673760b@mail.gmail.com> Message-ID: <200809261113.31125.dag@cray.com> On Friday 26 September 2008 10:56, Andrew Lenharth wrote: > On Fri, Sep 26, 2008 at 10:41 AM, David Greene wrote: > > On Thursday 25 September 2008 13:15, David Greene wrote: > >> I like your approach of using the use lists but I'm not sure the > >> ordering is guaranteed. If it is, your approach is superior. > > > > I got my patch updated to work with TOT. Here it is. Comments welcome. > > I still prefer Nicolas' solution if his use list ordering assumption is > > valid. > > Isn't the ordering an artifact of the creation of the users? If you I think so. > run mem2reg after other optimizations, why would you still have any > ordering guarantees? Yes, that's exactly what I'm worried about and why I didn't use the use lists in my solution. I'll check in my patch if folks find it acceptable. It was done pretty quickly so I may make another pass over it to clean it up a bit. -Dave From cedric.venet at laposte.net Fri Sep 26 12:05:52 2008 From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=) Date: Fri, 26 Sep 2008 19:05:52 +0200 Subject: [LLVMdev] Stacker Example In-Reply-To: <14998BCC-172D-4FF9-A458-81B5D86BA492@comcast.net> References: <14998BCC-172D-4FF9-A458-81B5D86BA492@comcast.net> Message-ID: <48DD1670.2020702@laposte.net> Wayne Anderson a ?crit : > Hello, > > I was wondering what happened to the "Stacker" example. The old link > to it "http://llvm.org/docs/Stacker.html" is dead. > > > Thanks, > > > Wayne > AFAIK, it has been removed because it was too out of date and kaleidoscope replaced it. C?dric From clattner at apple.com Fri Sep 26 16:59:00 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 26 Sep 2008 14:59:00 -0700 Subject: [LLVMdev] Named Address Spaces In-Reply-To: References: <20080924214855.GX15228@katherina.student.utwente.nl> <1222340170.3167.5.camel@idc-lt-i00171.microchip.com> Message-ID: <8D75F021-6F20-4DB7-8507-AAD055BDCAF3@apple.com> On Sep 25, 2008, at 11:29 AM, Gobi wrote: >> We plan to use the address space info in backend to support the "rom" >> address space for our target in near future. > > This will likely relate to what I am doing, however, my manager and > I are > currently trying to plan the entire toolchain, and key aspects > involve both > propogating debug information and verifying variables using named > address > spaces. Debug info is represented with explicit metadata in the llvm IR, its representation of addr spaces would be orthogonal to how codegen and optimizers hack on it. -Chris From clattner at apple.com Fri Sep 26 16:59:34 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 26 Sep 2008 14:59:34 -0700 Subject: [LLVMdev] Cannot Select ConstantFP on x86 In-Reply-To: <200809261043.01095.dag@cray.com> References: <200809241911.07519.dag@cray.com> <4379EE22-393C-4D93-931E-8F722AA2D0F6@apple.com> <200809261043.01095.dag@cray.com> Message-ID: <57186AB8-6E85-4A23-888A-02F0126FEC1D@apple.com> On Sep 26, 2008, at 8:43 AM, David Greene wrote: >> >> Do you have a testcase? It sounds like something that would be easy >> to fix. > > I have a fix (yes, it was trivial). I'll have to see about a > testcase as it's > proprietary code. Usually, proprietary testcases can be reduced and simplified to the point where they are innocuous, -Chris From mrs at apple.com Fri Sep 26 18:30:35 2008 From: mrs at apple.com (Mike Stump) Date: Fri, 26 Sep 2008 16:30:35 -0700 Subject: [LLVMdev] build failure in Attributes.h Message-ID: I'm seeing a build failure... In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/ Attributes.cpp:14: /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member function 'llvm::Attributes llvm::AttrListPtr::getParamAttributes(unsigned int) const': /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h:152: error: 'assert' was not declared in this scope make[1]: *** [/Volumes/mrs5/net/llvm/llvm-build/lib/VMCore/Debug/ Attributes.o] Error 1 ? From echristo at apple.com Fri Sep 26 18:38:52 2008 From: echristo at apple.com (Eric Christopher) Date: Fri, 26 Sep 2008 16:38:52 -0700 Subject: [LLVMdev] build failure in Attributes.h In-Reply-To: References: Message-ID: <8B9923F2-2E93-4FAA-9E10-81B52CFC6A1F@apple.com> On Sep 26, 2008, at 4:30 PM, Mike Stump wrote: > I'm seeing a build failure... > > In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/ > Attributes.cpp:14: > /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member > function 'llvm::Attributes > llvm::AttrListPtr::getParamAttributes(unsigned int) const': > /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h:152: error: > 'assert' was not declared in this scope > make[1]: *** [/Volumes/mrs5/net/llvm/llvm-build/lib/VMCore/Debug/ > Attributes.o] Error 1 Not seeing it here and I just updated to head. Try that. -eric From isanbard at gmail.com Fri Sep 26 18:39:49 2008 From: isanbard at gmail.com (Bill Wendling) Date: Fri, 26 Sep 2008 16:39:49 -0700 Subject: [LLVMdev] build failure in Attributes.h In-Reply-To: References: Message-ID: <16e5fdf90809261639t508c824fk736f25c23cfd4817@mail.gmail.com> On Fri, Sep 26, 2008 at 4:30 PM, Mike Stump wrote: > I'm seeing a build failure... > > In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/ > Attributes.cpp:14: > /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member > function 'llvm::Attributes > llvm::AttrListPtr::getParamAttributes(unsigned int) const': > /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h:152: error: > 'assert' was not declared in this scope > make[1]: *** [/Volumes/mrs5/net/llvm/llvm-build/lib/VMCore/Debug/ > Attributes.o] Error 1 > Weird. I'm not seeing this... -bw From id999 at gmx.de Mon Sep 22 14:16:10 2008 From: id999 at gmx.de (=?ISO-8859-1?Q?Marc_St=F6ttinger?=) Date: Mon, 22 Sep 2008 21:16:10 +0200 Subject: [LLVMdev] Problems with written function pass Message-ID: <12E7CEB9-DA39-4F17-9F24-B4427DAC7564@gmx.de> Hello, my name is Marc. I wrote a llvm function pass by using the "hello world" tutorial. But this selfwritten pass (GA_VHDL_Pass) dependes on another function pass (GenomePass). GenomePass also dependes on two other function passes. The Pass GenomePass generates an object, which is used in my GA-VHDL_Pass. When I compile my Make file I always get this error message: /work0/llvm-2.2/Debug/bin/opt --load /work0/llvm-2.2/Debug/lib/ MParSchedule.so --load /work0/llvm-2.2/Debug/lib/LLVMblockNrs.so -- load /work0/llvm-2.2/Debug/lib/Genome.so --load /work0/llvm-2.2/Debug/ lib/GA_VHDL_Pass.so -GA_VHDL_Pass -mem2reg -verify -f -o opt.o a.out.bc opt: Pass.cpp:157: void::PassRegistrar::RegisterPass (llvm::PassInfo&): Assertion `Inserted && "Pass registered multiple times!"' failed. make: *** [opt.o] Aborted I do not find the problem causing this, so perhaps some of you know the problem and a good solution. Here is the written Code of GA_VHDL_Pass: //#include "llvm/Pass.h" //#include "llvm/Function.h" #include "../../Analysis/genome/GenomePass.cpp" using namespace llvm; namespace llvm{ class GA_VHDL_Pass: public FunctionPass { private: GenomePass* GP; Genome* fitG; public: static char ID; // Pass identification, replacement for typeid GA_VHDL_Pass() : FunctionPass((intptr_t)&ID) {} virtual bool runOnFunction(Function &F) { GP = &getAnalysis(); fitG=GP->lookup(&F); std::cerr<<"test"<(); }; }; char GA_VHDL_Pass::ID = 0; } namespace{ RegisterPass X("GA_VHDL_Pass", "Create VHDL- Code out of a genome",false); } Followed by the Makefile: RELEASE=$(shell /work0/llvm-2.2/Debug/bin/llvm-config --build-mode) .PHONY: opt_out .PHONY: opt.o.ll #.PHONY: opte .PHONY: opt.o #opt_run:opt.o.s opt.o.ll opt_run: opt opt.o.ll cat opt.o.ll # opt.o.ll: opt.o /work0/llvm-2.2/$(RELEASE)/bin/llvm-dis -o opt.o.ll opt.o opt.o: a.out.bc /work0/llvm-2.2/$(RELEASE)/bin/opt --load /work0/llvm-2.2/$ (RELEASE)/lib/MParSchedule.so --load /work0/llvm-2.2/$(RELEASE)/lib/ LLVMblockNrs.so --load /work0/llvm-2.2/$(RELEASE)/lib/Genome.so -- load /work0/llvm-2.2/$(RELEASE)/lib/GA_VHDL_Pass.so -GA_VHDL_Pass - mem2reg -verify -f -o opt.o a.out.bc a.out.bc: testpass.c /work0/llvm-gcc/install/bin/llvm-gcc -c -emit-llvm testpass.c -o a.out.bc clean: rm a.out.bc opt.o opt.o.ll Thanks for your help, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080922/27cc3a36/attachment-0001.html From nicolas.capens at gmail.com Fri Sep 26 17:47:43 2008 From: nicolas.capens at gmail.com (Nicolas Capens) Date: Sat, 27 Sep 2008 00:47:43 +0200 Subject: [LLVMdev] mem2reg optimization In-Reply-To: <85dfcd7f0809260856n39bd0c90j7ea479c1e673760b@mail.gmail.com> References: <000401c8fbc2$b48680c0$1d938240$@net> <002d01c91f0b$d8510720$88f31560$@net> <200809251315.15499.dag@cray.com> <200809261041.57779.dag@cray.com> <85dfcd7f0809260856n39bd0c90j7ea479c1e673760b@mail.gmail.com> Message-ID: <3DFA0564-64FB-4D2D-9827-6C28C11E2114@gmail.com> Hi Andrew, I can't see any reason not to run mem2reg as the first pass (except maybe run a CFG simplify first, which doesn't alter the use list as far as I know). Also, I doubt that any pass can actually make a valid change in the order of loads and stores. And finally, why would any pass want to change the order of the use list in the first place? Only passes that create new stores and/or loads and don't insert them into the use list in the same reverse order could cause problems. But as far as I know that's only during codegen (e.g. specific instructions that need an operand to be in memory, and spills and loads added during register allocation). Anyway, my experience with LLVM is quite limited so I might be overlooking something important. So if Dave's solution works in all cases and has comparable performance then that's obviously better. I'll try to compare performance early next week and keep you posted. Kind regards, Nicolas On 26 Sep 2008, at 17:56, "Andrew Lenharth" wrote: > On Fri, Sep 26, 2008 at 10:41 AM, David Greene wrote: >> On Thursday 25 September 2008 13:15, David Greene wrote: >>> I like your approach of using the use lists but I'm not sure the >>> ordering >>> is guaranteed. If it is, your approach is superior. >> >> I got my patch updated to work with TOT. Here it is. Comments >> welcome. >> I still prefer Nicolas' solution if his use list ordering >> assumption is valid. > > Isn't the ordering an artifact of the creation of the users? If you > run mem2reg after other optimizations, why would you still have any > ordering guarantees? > > Andrew > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dalej at apple.com Fri Sep 26 18:41:46 2008 From: dalej at apple.com (Dale Johannesen) Date: Fri, 26 Sep 2008 16:41:46 -0700 Subject: [LLVMdev] build failure in Attributes.h In-Reply-To: References: Message-ID: Works for me. Presumably #including will fix it though? On Sep 26, 2008, at 4:30 PMPDT, Mike Stump wrote: > I'm seeing a build failure... > > In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/ > Attributes.cpp:14: > /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member > function 'llvm::Attributes > llvm::AttrListPtr::getParamAttributes(unsigned int) const': > /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h:152: error: > 'assert' was not declared in this scope > make[1]: *** [/Volumes/mrs5/net/llvm/llvm-build/lib/VMCore/Debug/ > Attributes.o] Error 1 > > ? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From isanbard at gmail.com Fri Sep 26 19:04:41 2008 From: isanbard at gmail.com (Bill Wendling) Date: Fri, 26 Sep 2008 17:04:41 -0700 Subject: [LLVMdev] build failure in Attributes.h In-Reply-To: References: Message-ID: <16e5fdf90809261704r372917a2hc4dd0f65c3fbda89@mail.gmail.com> Ah! I think it's a SnowLeopard thing. -bw On Fri, Sep 26, 2008 at 4:41 PM, Dale Johannesen wrote: > Works for me. Presumably #including will fix it though? > > On Sep 26, 2008, at 4:30 PMPDT, Mike Stump wrote: > >> I'm seeing a build failure... >> >> In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/ >> Attributes.cpp:14: >> /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member >> function 'llvm::Attributes >> llvm::AttrListPtr::getParamAttributes(unsigned int) const': >> /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h:152: error: >> 'assert' was not declared in this scope >> make[1]: *** [/Volumes/mrs5/net/llvm/llvm-build/lib/VMCore/Debug/ >> Attributes.o] Error 1 >> >> ? >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From nunoplopes at sapo.pt Fri Sep 26 19:17:27 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Sat, 27 Sep 2008 01:17:27 +0100 Subject: [LLVMdev] SwitchInstr::removeCase() doesn't remove PHINodes' predecessors Message-ID: Hi, I've been writing an optimization pass (described on the ML previously). Sometimes this pass removes some case entries from switch instructions, which cause an abort because removeCase() doesn't fix the PHINodes predecessors when needed. e.g.: define i32 @foo() nounwind { ifthen: %call = call i32 @bar() switch i32 %call, label %myphi [ i32 0, label %ifelse i32 1, label %ifelse ] ifelse: br label %myphi myphi: %ret.0 = phi i32 [ 0, %ifthen ], [ 1, %ifelse ] ret i32 %ret.0 } Suppose I remove the default target (i.e. replace it with other target BB). I get the following error: PHINode should have one entry for each predecessor of its parent basic block! %ret.0 = phi i32 [ 0, %ifthen ], [ 1, %ifelse ] ; [#uses=1] Broken module found, compilation aborted! This is because myphi is not reachable from ifthen anymore. My question is: is this a bug (or missing feature) or do I need to take care of the PHI Nodes myself? If it is the later what's the best way to handle that? (from what I could see I would need to iterate over all the instructions in the target BB and fix PHI Nodes if the target block becomes unreachable). Thanks, Nuno From ashish.bijlani at gmail.com Fri Sep 26 21:19:59 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Fri, 26 Sep 2008 22:19:59 -0400 Subject: [LLVMdev] compile linux kernel Message-ID: Hi, I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all possible? I get "Not an ELF" error. I pass "-emit-llvm" option to spit LLVM IR, which can be JITed at runtime $ make CROSS_COMPILE=llvm- CFLAGS="-O2 -emit-llvm" Error: not ELF make[2]: *** [scripts/mod/elfconfig.h] Error 1 make[1]: *** [scripts/mod] Error 2 make: *** [scripts] Error 2 using the verbose option - $ make V=1 CROSS_COMPILE=llvm- CFLAGS="-O2 -emit-llvm" /bin/bash scripts/checksyscalls.sh llvm-gcc -Wp,-MD,./.missing-syscalls.d -nostdinc -isystem /home/ashish/llvm/llvm-gcc4.2-2.3.source/obj/../install/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -O2 -emit-llvm -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(missing_syscalls)" -D"KBUILD_MODNAME=KBUILD_STR(missing_syscalls)" make -f scripts/Makefile.build obj=scripts make -f scripts/Makefile.build obj=scripts/genksyms make -f scripts/Makefile.build obj=scripts/mod scripts/mod/mk_elfconfig x86_64 < scripts/mod/empty.o > scripts/mod/elfconfig.h Error: not ELF make[2]: *** [scripts/mod/elfconfig.h] Error 1 make[1]: *** [scripts/mod] Error 2 make: *** [scripts] Error 2 $cat scripts/Makefile.build hostprogs-y := modpost mk_elfconfig always := $(hostprogs-y) empty.o modpost-objs := modpost.o file2alias.o sumversion.o # dependencies on generated files need to be listed explicitly $(obj)/modpost.o $(obj)/file2alias.o $(obj)/sumversion.o: $(obj)/elfconfig.h quiet_cmd_elfconfig = MKELF $@ cmd_elfconfig = $(obj)/mk_elfconfig $(ARCH) < $< > $@ $(obj)/elfconfig.h: $(obj)/empty.o $(obj)/mk_elfconfig FORCE $(call if_changed,elfconfig) targets += elfconfig.h It seems like Makefile.build is trying to make an ELF file out of scripts/mod/empty.o which has been compiled using LLVM to emit LLVM code. How to fix this? Am I missing something? Please help. Thanks, Ashish From viridia at gmail.com Fri Sep 26 21:33:18 2008 From: viridia at gmail.com (Talin) Date: Fri, 26 Sep 2008 19:33:18 -0700 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <200809261000.54992.baldrick@free.fr> References: <19683007.post@talk.nabble.com> <200809261000.54992.baldrick@free.fr> Message-ID: <48DD9B6E.3070702@gmail.com> Duncan Sands wrote: >> I can't find any information about cxa_throw at all, not even a type >> signature. If I could, could I just call it as if it were unwind, and it >> would be caught by invoke? >> > > cxa_throw comes from the gcc C++ runtime. In order to see how to throw > and catch things correctly using it, compile some C++ examples down to > bitcode using llvm-g++. > So what about those of us who are implementing frontends that have no connection with gcc or the c++ runtime at all? Are we out of luck as far as unwind is concerned? -- Talin From nicholas at mxc.ca Sat Sep 27 01:44:25 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Fri, 26 Sep 2008 23:44:25 -0700 Subject: [LLVMdev] SwitchInstr::removeCase() doesn't remove PHINodes' predecessors In-Reply-To: References: Message-ID: <48DDD649.7040302@mxc.ca> Nuno Lopes wrote: > PHINode should have one entry for each predecessor of its parent basic > block! > %ret.0 = phi i32 [ 0, %ifthen ], [ 1, %ifelse ] ; > [#uses=1] > Broken module found, compilation aborted! > > This is because myphi is not reachable from ifthen anymore. My question is: > is this a bug (or missing feature) or do I need to take care of the PHI > Nodes myself? You get to take care of it yourself. If it is the later what's the best way to handle that? (from > what I could see I would need to iterate over all the instructions in the > target BB and fix PHI Nodes if the target block becomes unreachable). TargetBB->removePredecessor(SwitchBB). Note that you should call this before you call removeCase! Nick From edwintorok at gmail.com Sat Sep 27 02:13:04 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sat, 27 Sep 2008 10:13:04 +0300 Subject: [LLVMdev] compile linux kernel In-Reply-To: References: Message-ID: <48DDDD00.2050002@gmail.com> On 2008-09-27 05:19, Ashish Bijlani wrote: > Hi, > > I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all > possible? I get "Not an ELF" error. I pass "-emit-llvm" option to spit > LLVM IR, which can be JITed at runtime > > If you want to build a kernel you can't use the JIT anyway, so why not just build native code? Best regards, --Edwin From mattgiuca at gmail.com Sat Sep 27 03:48:45 2008 From: mattgiuca at gmail.com (Matt Giuca) Date: Sat, 27 Sep 2008 01:48:45 -0700 (PDT) Subject: [LLVMdev] Stacker Example In-Reply-To: <14998BCC-172D-4FF9-A458-81B5D86BA492@comcast.net> References: <14998BCC-172D-4FF9-A458-81B5D86BA492@comcast.net> Message-ID: <19700903.post@talk.nabble.com> Wayne Anderson-4 wrote: > > I was wondering what happened to the "Stacker" example. The old link > to it "http://llvm.org/docs/Stacker.html" is dead. > It's still available in the 2.3 archive: http://llvm.org/releases/2.3/docs/Stacker.html http://llvm.org/releases/2.3/docs/Stacker.html It must have been removed since the 2.3 release. -- View this message in context: http://www.nabble.com/Stacker-Example-tp19691748p19700903.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From nunoplopes at sapo.pt Sat Sep 27 05:13:23 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Sat, 27 Sep 2008 11:13:23 +0100 Subject: [LLVMdev] SwitchInstr::removeCase() doesn't remove PHINodes' predecessors In-Reply-To: <48DDD649.7040302@mxc.ca> References: <48DDD649.7040302@mxc.ca> Message-ID: <885955C445F646C580DCE3684A1CF065@pc07654> >> PHINode should have one entry for each predecessor of its parent basic >> block! >> %ret.0 = phi i32 [ 0, %ifthen ], [ 1, %ifelse ] ; >> [#uses=1] >> Broken module found, compilation aborted! >> >> This is because myphi is not reachable from ifthen anymore. My question >> is: >> is this a bug (or missing feature) or do I need to take care of the PHI >> Nodes myself? > > You get to take care of it yourself. > > If it is the later what's the best way to handle that? (from >> what I could see I would need to iterate over all the instructions in the >> target BB and fix PHI Nodes if the target block becomes unreachable). > > TargetBB->removePredecessor(SwitchBB). Note that you should call this > before you call removeCase! Ok, thank you! It's working now. I was afraid that removePredecessor() wouldn't work if the switchBB had more than one jump to the TargetBB, but it works :) Thanks, Nuno From isanbard at gmail.com Sat Sep 27 07:20:04 2008 From: isanbard at gmail.com (Bill Wendling) Date: Sat, 27 Sep 2008 05:20:04 -0700 Subject: [LLVMdev] llvm broken? In-Reply-To: References: Message-ID: These should be fixed now. -bw On Sep 23, 2008, at 5:11 PM, Mike Stump wrote: > /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/CodeGenPrepare.cpp: > In member function > ?bool::CodeGenPrepare::OptimizeInlineAsmInst > (llvm::Instruction*, llvm::CallSite, llvm::DenseMap llvm::Value*, llvm::DenseMapInfo, > llvm::DenseMapInfo >&)?: > /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/CodeGenPrepare.cpp: > 966: error: no matching function for call to > ?llvm::TargetLowering::ComputeConstraintToUse > (llvm::TargetLowering::AsmOperandInfo&, llvm::SDValue) const? > /Volumes/mrs5/net/llvm/llvm/include/llvm/Target/TargetLowering.h:1177: > note: candidates are: virtual void > llvm::TargetLowering::ComputeConstraintToUse > (llvm::TargetLowering::AsmOperandInfo&, llvm::SDValue, bool, > llvm::SelectionDAG*) const > make[3]: *** [/Volumes/mrs5/net/llvm/llvm-build/lib/Transforms/Scalar/ > Debug/CodeGenPrepare.o] Error 1 > > ? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ashish.bijlani at gmail.com Sat Sep 27 10:29:59 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Sat, 27 Sep 2008 11:29:59 -0400 Subject: [LLVMdev] compile linux kernel In-Reply-To: <48DDDD00.2050002@gmail.com> References: <48DDDD00.2050002@gmail.com> Message-ID: I plan to use virtualization infrastructure to JIT VM Kernel Code. Michael Engel has done that in the past to have dynamic aspect in the Kernel: http://llvm.org/pubs/2005-03-14-ACP4IS-AspectsKernel.pdf He used L4 based Hypervisor and Virtual Machines. Can this not be done or am I missing something? -Ashish On Sat, Sep 27, 2008 at 3:13 AM, T?r?k Edwin wrote: > On 2008-09-27 05:19, Ashish Bijlani wrote: >> Hi, >> >> I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all >> possible? I get "Not an ELF" error. I pass "-emit-llvm" option to spit >> LLVM IR, which can be JITed at runtime >> >> > > If you want to build a kernel you can't use the JIT anyway, so why not > just build native code? > > Best regards, > --Edwin > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From edwintorok at gmail.com Sat Sep 27 10:45:12 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sat, 27 Sep 2008 18:45:12 +0300 Subject: [LLVMdev] compile linux kernel In-Reply-To: References: <48DDDD00.2050002@gmail.com> Message-ID: <48DE5508.4010808@gmail.com> On 2008-09-27 18:29, Ashish Bijlani wrote: > I plan to use virtualization infrastructure to JIT VM Kernel Code. > Michael Engel has done that in the past to have dynamic aspect in the > Kernel: http://llvm.org/pubs/2005-03-14-ACP4IS-AspectsKernel.pdf > > He used L4 based Hypervisor and Virtual Machines. Can this not be done > or am I missing something? > I think you'll need to modify the kernel build scripts to not expect ELF output, such as mk_elfconfig. LLVM outputs its own bytecode format when you use -emit-llvm, and not an ELF format. Best regards, --Edwin From ashish.bijlani at gmail.com Sat Sep 27 11:03:01 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Sat, 27 Sep 2008 12:03:01 -0400 Subject: [LLVMdev] compile linux kernel In-Reply-To: <48DE5508.4010808@gmail.com> References: <48DDDD00.2050002@gmail.com> <48DE5508.4010808@gmail.com> Message-ID: can kernel b JITed using hypervisor at runtime??? also can llvm be run on l4 as native L4 application? which flavor of l4 does it support? any doc on how to go about it? should i just remove mk_elf from the makefile?? i actually tried removing mk_elf from the build scripts but then it fails when it doesn't find global symbols emitted during preprocessing using ## e.g. per_cpu_## in percpu.h in the kernel. thanks, ashish On Sat, Sep 27, 2008 at 11:45 AM, T?r?k Edwin wrote: > On 2008-09-27 18:29, Ashish Bijlani wrote: >> I plan to use virtualization infrastructure to JIT VM Kernel Code. >> Michael Engel has done that in the past to have dynamic aspect in the >> Kernel: http://llvm.org/pubs/2005-03-14-ACP4IS-AspectsKernel.pdf >> >> He used L4 based Hypervisor and Virtual Machines. Can this not be done >> or am I missing something? >> > > I think you'll need to modify the kernel build scripts to not expect ELF > output, such as mk_elfconfig. > LLVM outputs its own bytecode format when you use -emit-llvm, and not an > ELF format. > > Best regards, > --Edwin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From andrewl at lenharth.org Sat Sep 27 18:03:28 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sat, 27 Sep 2008 18:03:28 -0500 Subject: [LLVMdev] compile linux kernel In-Reply-To: References: Message-ID: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> On Fri, Sep 26, 2008 at 9:19 PM, Ashish Bijlani wrote: > Hi, > > I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all > possible? Yes, but it requires significant hacking, and the result for 2.6 is a mostly bitcode kernel with a few userspace shared libraries linked in as objcode (yes, the kernel builds .so files and includes them in the binary). There are a few changes here and there you can make to the kernel code to produce significantly nicer bitcodes too (e.g. rather than having module level asm that makes symbols weak, you can just have gcc do it). The modification to the make system is not difficult, but it requires some work and an understanding of the kernel build system. Andrew From ashish.bijlani at gmail.com Sat Sep 27 18:34:20 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Sat, 27 Sep 2008 19:34:20 -0400 Subject: [LLVMdev] compile linux kernel In-Reply-To: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> Message-ID: Thanks for the help. I've a couple of questions though: How does LLVM deal with inline assembly? I'm trying to compile kernel and I get this error probably because LLVM is not able to handle inline assembly. I'm using LLVM-2.3 code snippet from "arch/x86_64/kernel/asm-offsets.c" .... #define DEFINE(sym, val) \ asm volatile("\n->" #sym " %0 " #val : : "i" (val)) .... DEFINE(__NR_syscall_max, sizeof(syscalls) - 1); return 0; # make CROSS_COMPILE=llvm- V=1 llvm-gcc -Wp,-MD,arch/x86_64/kernel/.syscall.o.d -nostdinc -isystem /home/ashish/llvm/llvm-gcc4.2-2.3.source/obj/../install/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -emit-llvm -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2 -mtune=generic -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(syscall)" -D"KBUILD_MODNAME=KBUILD_STR(syscall)" -c -o arch/x86_64/kernel/.tmp_syscall.o arch/x86_64/kernel/syscall.c arch/x86_64/kernel/syscall.c:22: error: '__NR_syscall_max' undeclared here (not in a function) arch/x86_64/kernel/syscall.c:24: error: array index in initializer not of integer type arch/x86_64/kernel/syscall.c:24: error: (near initialization for 'sys_call_table') In file included from arch/x86_64/kernel/syscall.c:25: include/asm-x86_64/unistd.h:16: error: array index in non-array initializer include/asm-x86_64/unistd.h:16: error: (near initialization for 'sys_call_table') include/asm-x86_64/unistd.h:18: error: array index in non-array initializer Note that I use "-emit-llvm" option with llvm-gcc. Is this correct of am I missing something? How can I fix this error? Thanks, Ashish On Sat, Sep 27, 2008 at 7:03 PM, Andrew Lenharth wrote: > On Fri, Sep 26, 2008 at 9:19 PM, Ashish Bijlani > wrote: >> Hi, >> >> I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all >> possible? > > Yes, but it requires significant hacking, and the result for 2.6 is a > mostly bitcode kernel with a few userspace shared libraries linked in > as objcode (yes, the kernel builds .so files and includes them in the > binary). There are a few changes here and there you can make to the > kernel code to produce significantly nicer bitcodes too (e.g. rather > than having module level asm that makes symbols weak, you can just > have gcc do it). > > The modification to the make system is not difficult, but it requires > some work and an understanding of the kernel build system. > > Andrew > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From dalej at apple.com Sat Sep 27 19:16:47 2008 From: dalej at apple.com (Dale Johannesen) Date: Sat, 27 Sep 2008 17:16:47 -0700 Subject: [LLVMdev] compile linux kernel In-Reply-To: References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> Message-ID: On Sep 27, 2008, at 4:34 PM, Ashish Bijlani wrote: > Thanks for the help. I've a couple of questions though: > > How does LLVM deal with inline assembly? It's been implemented piece by piece on an as-needed basis. At this point most of the things people actually use should work. llvm-gcc has seen the Linux kernel, so most usages in there ought to work. The symptoms here look more like a preprocessor problem than an asm problem. Your asm snippet works fine with llvm's top of tree, and I suspect the real problem is something else. If you compile with -save- temps what does the .i file look like? > I'm trying to compile kernel and I get this error probably because > LLVM is not able to handle inline assembly. I'm using LLVM-2.3 > > code snippet from "arch/x86_64/kernel/asm-offsets.c" > .... > > #define DEFINE(sym, val) \ > asm volatile("\n->" #sym " %0 " #val : : "i" (val)) > .... > > DEFINE(__NR_syscall_max, sizeof(syscalls) - 1); > return 0; > > # make CROSS_COMPILE=llvm- V=1 > > llvm-gcc -Wp,-MD,arch/x86_64/kernel/.syscall.o.d -nostdinc -isystem > /home/ashish/llvm/llvm-gcc4.2-2.3.source/obj/../install/lib/gcc/ > x86_64-unknown-linux-gnu/4.2.1/include > -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -emit-llvm > -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing > -fno-common -Werror-implicit-function-declaration -O2 -mtune=generic > -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare > -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx > -mno-sse2 -mno-3dnow -maccumulate-outgoing-args > -fomit-frame-pointer -g -fno-stack-protector > -Wdeclaration-after-statement -Wno-pointer-sign > -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(syscall)" > -D"KBUILD_MODNAME=KBUILD_STR(syscall)" -c -o > arch/x86_64/kernel/.tmp_syscall.o arch/x86_64/kernel/syscall.c > arch/x86_64/kernel/syscall.c:22: error: '__NR_syscall_max' undeclared > here (not in a function) > arch/x86_64/kernel/syscall.c:24: error: array index in initializer not > of integer type > arch/x86_64/kernel/syscall.c:24: error: (near initialization for > 'sys_call_table') > In file included from arch/x86_64/kernel/syscall.c:25: > include/asm-x86_64/unistd.h:16: error: array index in non-array > initializer > include/asm-x86_64/unistd.h:16: error: (near initialization for > 'sys_call_table') > include/asm-x86_64/unistd.h:18: error: array index in non-array > initializer > > Note that I use "-emit-llvm" option with llvm-gcc. Is this correct of > am I missing something? > How can I fix this error? > > Thanks, > Ashish > > On Sat, Sep 27, 2008 at 7:03 PM, Andrew Lenharth > wrote: >> On Fri, Sep 26, 2008 at 9:19 PM, Ashish Bijlani >> wrote: >>> Hi, >>> >>> I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all >>> possible? >> >> Yes, but it requires significant hacking, and the result for 2.6 is a >> mostly bitcode kernel with a few userspace shared libraries linked in >> as objcode (yes, the kernel builds .so files and includes them in the >> binary). There are a few changes here and there you can make to the >> kernel code to produce significantly nicer bitcodes too (e.g. rather >> than having module level asm that makes symbols weak, you can just >> have gcc do it). >> >> The modification to the make system is not difficult, but it requires >> some work and an understanding of the kernel build system. >> >> Andrew >> _______________________________________________ >> 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 ashish.bijlani at gmail.com Sat Sep 27 20:08:44 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Sat, 27 Sep 2008 21:08:44 -0400 Subject: [LLVMdev] compile linux kernel In-Reply-To: References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> Message-ID: Thanks. I actually checked the IR code generated, it seems inline assembly is being handled correctly. The preprocessing is also being done correctly. Here is the asm-offsets.i file snippet.. ... builtin_offsetof(struct crypto_tfm,__crt_ctx))); asm volatile("\n->" : : ); asm volatile("\n->" "__NR_syscall_max" " %0 " "sizeof(syscalls) - 1" : : "i" (sizeof(syscalls) - 1)); return 0; } .... and here is the IR code snippet - ... tail call void asm sideeffect "\0A->__NR_syscall_max $0 sizeof(syscalls) - 1", "i,~{dirflag},~{fpsr},~{flags}"( i64 285 ) nounwind ret i32 0 } .... However, the build system is trying to generate asm-offset.s from asm-offset.c and then it populates asm-offsets.h header file for correct values. Here is the code from Kbuild - "define cmd_offsets (set -e; \ echo "#ifndef __ASM_OFFSETS_H__"; \ echo "#define __ASM_OFFSETS_H__"; \ echo "/*"; \ echo " * DO NOT MODIFY."; \ echo " *"; \ echo " * This file was generated by Kbuild"; \ echo " *"; \ echo " */"; \ echo ""; \ sed -ne $(sed-y) $<; \ echo ""; \ echo "#endif" ) > $@ endef " Since this does "sed" on asm-offsets.s file and retrieves the offsets of the symbols, it fails when it gets LLVM generated "asm-offsets.s" IR file. As a result the asm-offsets.h file generated is empty and doesn't contain the symbol __NR_SYSCALLS_max. If I use GCC to generate asm-offsets.s file, then the build system go ahead but fails when it generates .so files as Andrew pointed out. ... llvm-gcc -m elf_x86_64 -nostdlib -fPIC -shared -Wl,-soname=linux-vdso.so.1 -Wl,--hash-style=sysv -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 -Wl,-T,arch/x86_64/vdso/vdso.lds arch/x86_64/vdso/vdso-start.o arch/x86_64/vdso/vdso-note.o arch/x86_64/vdso/vclock_gettime.o arch/x86_64/vdso/vgetcpu.o arch/x86_64/vdso/vvar.o -o arch/x86_64/vdso/vdso.so arch/x86_64/vdso/vvar.o: file not recognized: File format not recognized collect2: ld returned 1 exit status .... Now, If the build systems generates .so files, then it will be difficult o actually generate fully arch-independent kernel code, isn't it? thanks, ashish On Sat, Sep 27, 2008 at 8:16 PM, Dale Johannesen wrote: > > On Sep 27, 2008, at 4:34 PM, Ashish Bijlani wrote: > >> Thanks for the help. I've a couple of questions though: >> >> How does LLVM deal with inline assembly? > > It's been implemented piece by piece on an as-needed basis. At this > point most of the things people actually use should work. llvm-gcc > has seen the Linux kernel, so most usages in there ought to work. > > The symptoms here look more like a preprocessor problem than an asm > problem. Your asm snippet works fine with llvm's top of tree, and I > suspect the real problem is something else. If you compile with -save- > temps what does the .i file look like? > >> I'm trying to compile kernel and I get this error probably because >> LLVM is not able to handle inline assembly. I'm using LLVM-2.3 >> >> code snippet from "arch/x86_64/kernel/asm-offsets.c" >> .... >> >> #define DEFINE(sym, val) \ >> asm volatile("\n->" #sym " %0 " #val : : "i" (val)) >> .... >> >> DEFINE(__NR_syscall_max, sizeof(syscalls) - 1); >> return 0; >> >> # make CROSS_COMPILE=llvm- V=1 >> >> llvm-gcc -Wp,-MD,arch/x86_64/kernel/.syscall.o.d -nostdinc -isystem >> /home/ashish/llvm/llvm-gcc4.2-2.3.source/obj/../install/lib/gcc/ >> x86_64-unknown-linux-gnu/4.2.1/include >> -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -emit-llvm >> -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing >> -fno-common -Werror-implicit-function-declaration -O2 -mtune=generic >> -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare >> -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx >> -mno-sse2 -mno-3dnow -maccumulate-outgoing-args >> -fomit-frame-pointer -g -fno-stack-protector >> -Wdeclaration-after-statement -Wno-pointer-sign >> -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(syscall)" >> -D"KBUILD_MODNAME=KBUILD_STR(syscall)" -c -o >> arch/x86_64/kernel/.tmp_syscall.o arch/x86_64/kernel/syscall.c >> arch/x86_64/kernel/syscall.c:22: error: '__NR_syscall_max' undeclared >> here (not in a function) >> arch/x86_64/kernel/syscall.c:24: error: array index in initializer not >> of integer type >> arch/x86_64/kernel/syscall.c:24: error: (near initialization for >> 'sys_call_table') >> In file included from arch/x86_64/kernel/syscall.c:25: >> include/asm-x86_64/unistd.h:16: error: array index in non-array >> initializer >> include/asm-x86_64/unistd.h:16: error: (near initialization for >> 'sys_call_table') >> include/asm-x86_64/unistd.h:18: error: array index in non-array >> initializer >> >> Note that I use "-emit-llvm" option with llvm-gcc. Is this correct of >> am I missing something? >> How can I fix this error? >> >> Thanks, >> Ashish >> >> On Sat, Sep 27, 2008 at 7:03 PM, Andrew Lenharth >> wrote: >>> On Fri, Sep 26, 2008 at 9:19 PM, Ashish Bijlani >>> wrote: >>>> Hi, >>>> >>>> I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all >>>> possible? >>> >>> Yes, but it requires significant hacking, and the result for 2.6 is a >>> mostly bitcode kernel with a few userspace shared libraries linked in >>> as objcode (yes, the kernel builds .so files and includes them in the >>> binary). There are a few changes here and there you can make to the >>> kernel code to produce significantly nicer bitcodes too (e.g. rather >>> than having module level asm that makes symbols weak, you can just >>> have gcc do it). >>> >>> The modification to the make system is not difficult, but it requires >>> some work and an understanding of the kernel build system. >>> >>> Andrew >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From andrewl at lenharth.org Sat Sep 27 21:43:18 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sat, 27 Sep 2008 21:43:18 -0500 Subject: [LLVMdev] compile linux kernel In-Reply-To: References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> Message-ID: <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani wrote: > If I use GCC to generate asm-offsets.s file, then the build system go > ahead but fails when it generates .so files as Andrew pointed out. You have to generate this with gcc. .c -> .s and .s -> .o need gcc, .c -> .o can use llvm-gcc. The combination has to be fixed up in final linking. > Now, If the build systems generates .so files, then it will be > difficult o actually generate fully arch-independent kernel code, > isn't it? A llvm compiled kernel is in no way arch-independent. It is very very arch dependent. Andrew From ashish.bijlani at gmail.com Sun Sep 28 00:07:23 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Sun, 28 Sep 2008 01:07:23 -0400 Subject: [LLVMdev] compile linux kernel In-Reply-To: <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> Message-ID: does that mean .o generated with gcc (.c -> .s and .s -> .o) will not contain llvm ir? i meant, final kernel bitcode ir arch independent and can be JIT with any arch-specific backend. Is it not the case? thanks, ashish On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth wrote: > On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani > wrote: >> If I use GCC to generate asm-offsets.s file, then the build system go >> ahead but fails when it generates .so files as Andrew pointed out. > > You have to generate this with gcc. .c -> .s and .s -> .o need gcc, > .c -> .o can use llvm-gcc. The combination has to be fixed up in > final linking. > >> Now, If the build systems generates .so files, then it will be >> difficult o actually generate fully arch-independent kernel code, >> isn't it? > > A llvm compiled kernel is in no way arch-independent. It is very very > arch dependent. > > Andrew > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From dberlin at dberlin.org Sun Sep 28 01:20:31 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Sun, 28 Sep 2008 02:20:31 -0400 Subject: [LLVMdev] compile linux kernel In-Reply-To: References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> Message-ID: <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> No, this is not the case. Just because you compile something to LLVM IR does not make the thing you compiled work on every architecture. You may even be able to retarget it to any architecture (it depends), but this in no way means the result will *actually work*. The LLVM IR generated by llvm-gcc is very architecture dependent. Theoretically you could make a C compiler that was mostly C compliant and produced architecture independent LLVM IR. llvm-gcc is not this compiler, however. On Sun, Sep 28, 2008 at 1:07 AM, Ashish Bijlani wrote: > does that mean .o generated with gcc (.c -> .s and .s -> .o) will not > contain llvm ir? > > i meant, final kernel bitcode ir arch independent and can be JIT with > any arch-specific backend. Is it not the case? > > thanks, > ashish > > On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth wrote: >> On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani >> wrote: >>> If I use GCC to generate asm-offsets.s file, then the build system go >>> ahead but fails when it generates .so files as Andrew pointed out. >> >> You have to generate this with gcc. .c -> .s and .s -> .o need gcc, >> .c -> .o can use llvm-gcc. The combination has to be fixed up in >> final linking. >> >>> Now, If the build systems generates .so files, then it will be >>> difficult o actually generate fully arch-independent kernel code, >>> isn't it? >> >> A llvm compiled kernel is in no way arch-independent. It is very very >> arch dependent. >> >> Andrew >> _______________________________________________ >> 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 matthijs at stdin.nl Sun Sep 28 13:39:51 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Sun, 28 Sep 2008 20:39:51 +0200 Subject: [LLVMdev] Problems with written function pass In-Reply-To: <12E7CEB9-DA39-4F17-9F24-B4427DAC7564@gmx.de> References: <12E7CEB9-DA39-4F17-9F24-B4427DAC7564@gmx.de> Message-ID: <20080928183951.GE15228@katherina.student.utwente.nl> Hi Marc, > void::PassRegistrar::RegisterPass(llvm::PassInfo&): Assertion > `Inserted && "Pass registered multiple times!"' failed. This means you register your pass twice, ie you have the RegisterPass variable in more than one compile unit. > #include "../../Analysis/genome/GenomePass.cpp" You shouldn't do this, assuming that GenomePass.cpp contains the implementation for GenomePass, you will get it (and the associated RegisterPass) compiled twice. Instead, seperate your GenomePass.cpp into a .h file in the include/ directory, which contains the class declaration and a .cpp file which contains method implementations and the RegisterPass variable. Then include the .h file, including a .cpp file is almost always an error. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080928/be2e5aee/attachment.bin From matthijs at stdin.nl Sun Sep 28 13:42:54 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Sun, 28 Sep 2008 20:42:54 +0200 Subject: [LLVMdev] Overzealous PromoteCastOfAllocation In-Reply-To: References: <20080908155737.GJ32157@katherina.student.utwente.nl> <643C9D81-4750-48E5-B26C-C7699B04065B@apple.com> <20080913200716.GF9093@katherina.student.utwente.nl> <20080923111603.GL15228@katherina.student.utwente.nl> Message-ID: <20080928184254.GF15228@katherina.student.utwente.nl> > I haven't read your patches yet, but it sounds like you're heading in a > positive direction here :-). Would you manage to have a look at them today? I'll be working again tomorrow, so feedback would be appreciated (though I think that your today will be sunday, while my tomorrow will be monday :-) Anyway, I'll also send these patches llvm-commits, for others to review. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080928/5b990f0e/attachment.bin From ashish.bijlani at gmail.com Sun Sep 28 13:57:29 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Sun, 28 Sep 2008 14:57:29 -0400 Subject: [LLVMdev] linker script Message-ID: Hi, I'm trying to compile linux kernel with llvm to generate llvm ir (bitcode). It seems like llvm-ld doesn't accept any linker scripts. How do I deal with vmlinux.lds in such a case? How did people who have compiled linux kernel with llvm deal with this in the past? Thanks, Ashish From akarhu3 at gatech.edu Sun Sep 28 15:11:36 2008 From: akarhu3 at gatech.edu (Karhu, Abhinav R) Date: Sun, 28 Sep 2008 16:11:36 -0400 (EDT) Subject: [LLVMdev] Problem with running the program using LLVM In-Reply-To: <1939341241.3174651222632663566.JavaMail.root@mail7.gatech.edu> Message-ID: <878470305.3174761222632696232.JavaMail.root@mail7.gatech.edu> Hey All, I am running into a problem with running the program using LLVM JIT. I get the following error. lli: error loading program 'Hel.bc': Bitcode stream should be a multiple of 4 bytes in length. Hel.bc is the bytecode for my simple HelloWorld program. Please give me some insight into this. Thanks -- Abhinav Karhu MS Computer Science Georgia Institute of Technology From asl at math.spbu.ru Sun Sep 28 15:38:42 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Mon, 29 Sep 2008 00:38:42 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?UHJvYmxlbSB3aXRoIHJ1bm5pbmcgdGhlIHByb2dyYW0g?= =?koi8-r?b?dXNpbmcgTExWTQ==?= Message-ID: <200809282038.m8SKcg5s000495@star.math.spbu.ru> > Hel.bc is the bytecode for my simple HelloWorld program. Please give me some insight into this. Sorry, telepathy module is broken today. How this bytecode was produced? Why do you think your Hel.bc file is a bytecode (lli thinks it isn't)? -- WBR, Anton Korobeynikov From shackan at gmail.com Sun Sep 28 16:49:51 2008 From: shackan at gmail.com (P. Durante) Date: Sun, 28 Sep 2008 23:49:51 +0200 Subject: [LLVMdev] compile linux kernel In-Reply-To: References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> Message-ID: <9307f5f20809281449r343dd095wbed30721f7a364c2@mail.gmail.com> > Now, If the build systems generates .so files, then it will be > difficult o actually generate fully arch-independent kernel code, > isn't it? > Even if the LLVM IR itself was guaranteed to be architecture-transparent (it isn't), all architectures use different kernel code, there's no way to make a vmlinux binary which has the code for all the architectures at once. Even compiling the UML (using ARCH=um), where the kernel runs in userspace like a regular program, won't make a 'universal binary' as it depends on some x86[_64] inline assembly. From ashish.bijlani at gmail.com Sun Sep 28 17:06:04 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Sun, 28 Sep 2008 18:06:04 -0400 Subject: [LLVMdev] llvm-ld hangs Message-ID: Hi, I'm trying to compile UML with LLVM. However, LLVM-LD hangs whiile linking modules. It's consuming 99% of the CPU llvm-ld -v -r -o kernel/built-in.o kernel/sched.o kernel/fork.o kernel/exec_domain.o kernel/panic.o kernel/printk.o kernel/profile.o kernel/exit.o kernel/itimer.o kernel/time.o kernel/softirq.o kernel/resource.o kernel/sysctl.o kernel/capability.o kernel/ptrace.o kernel/timer.o kernel/user.o kernel/user_namespace.o kernel/signal.o kernel/sys.o kernel/kmod.o kernel/workqueue.o kernel/pid.o kernel/rcupdate.o kernel/extable.o kernel/params.o kernel/posix-timers.o kernel/kthread.o kernel/wait.o kernel/kfifo.o kernel/sys_ni.o kernel/posix-cpu-timers.o kernel/mutex.o kernel/hrtimer.o kernel/rwsem.o kernel/latency.o kernel/nsproxy.o kernel/srcu.o kernel/die_notifier.o kernel/utsname.o kernel/time/built-in.o kernel/futex.o kernel/rtmutex.o kernel/uid16.o kernel/kallsyms.o kernel/acct.o kernel/configs.o kernel/ksysfs.o kernel/softlockup.o kernel/irq/built-in.o kernel/utsname_sysctl.o Linking bitcode file 'kernel/sched.o' Linked in file 'kernel/sched.o' Linking bitcode file 'kernel/fork.o' Linked in file 'kernel/fork.o' Linking bitcode file 'kernel/exec_domain.o' Linked in file 'kernel/exec_domain.o' Linking bitcode file 'kernel/panic.o' Linked in file 'kernel/panic.o' Linking bitcode file 'kernel/printk.o' Linked in file 'kernel/printk.o' Linking bitcode file 'kernel/profile.o' Linked in file 'kernel/profile.o' Linking bitcode file 'kernel/exit.o' Using GDB I could figure out that it is causing stack overflow (some loop in the code between 0x495be5 and 0x495da7) .... #47 0x0000000000495be5 in ?? () #48 0x0000000000495da7 in ?? () #49 0x0000000000495a24 in ?? () #50 0x0000000000495da7 in ?? () #51 0x0000000000495be5 in ?? () #52 0x0000000000495da7 in ?? () #53 0x0000000000495be5 in ?? () #54 0x0000000000495da7 in ?? () #55 0x0000000000495be5 in ?? () #56 0x0000000000495da7 in ?? () #57 0x0000000000495be5 in ?? () #58 0x0000000000495da7 in ?? () #59 0x0000000000495be5 in ?? () #60 0x0000000000495da7 in ?? () #61 0x0000000000495be5 in ?? () #62 0x0000000000495da7 in ?? () #63 0x0000000000495be5 in ?? () #64 0x000000000049609a in ?? () #65 0x000000000049ab6f in llvm::Linker::LinkModules () #66 0x0000000000491643 in llvm::Linker::LinkInFile () #67 0x0000000000491e57 in llvm::Linker::LinkInFiles () #68 0x00000000004727df in main () any ideas what could be wrong here? thanks. From ashish.bijlani at gmail.com Sun Sep 28 17:08:07 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Sun, 28 Sep 2008 18:08:07 -0400 Subject: [LLVMdev] llvm-ld hangs In-Reply-To: References: Message-ID: Forgot to mention that I'm trying to generate LLVM IR. I've also faced this problem while compiling linux kernel with LLVM to generate LLVM IR. On Sun, Sep 28, 2008 at 6:06 PM, Ashish Bijlani wrote: > Hi, > > I'm trying to compile UML with LLVM. However, LLVM-LD hangs whiile > linking modules. It's consuming 99% of the CPU > > llvm-ld -v -r -o kernel/built-in.o kernel/sched.o kernel/fork.o > kernel/exec_domain.o kernel/panic.o kernel/printk.o kernel/profile.o > kernel/exit.o kernel/itimer.o kernel/time.o kernel/softirq.o > kernel/resource.o kernel/sysctl.o kernel/capability.o kernel/ptrace.o > kernel/timer.o kernel/user.o kernel/user_namespace.o kernel/signal.o > kernel/sys.o kernel/kmod.o kernel/workqueue.o kernel/pid.o > kernel/rcupdate.o kernel/extable.o kernel/params.o > kernel/posix-timers.o kernel/kthread.o kernel/wait.o kernel/kfifo.o > kernel/sys_ni.o kernel/posix-cpu-timers.o kernel/mutex.o > kernel/hrtimer.o kernel/rwsem.o kernel/latency.o kernel/nsproxy.o > kernel/srcu.o kernel/die_notifier.o kernel/utsname.o > kernel/time/built-in.o kernel/futex.o kernel/rtmutex.o kernel/uid16.o > kernel/kallsyms.o kernel/acct.o kernel/configs.o kernel/ksysfs.o > kernel/softlockup.o kernel/irq/built-in.o kernel/utsname_sysctl.o > Linking bitcode file 'kernel/sched.o' > Linked in file 'kernel/sched.o' > Linking bitcode file 'kernel/fork.o' > Linked in file 'kernel/fork.o' > Linking bitcode file 'kernel/exec_domain.o' > Linked in file 'kernel/exec_domain.o' > Linking bitcode file 'kernel/panic.o' > Linked in file 'kernel/panic.o' > Linking bitcode file 'kernel/printk.o' > Linked in file 'kernel/printk.o' > Linking bitcode file 'kernel/profile.o' > Linked in file 'kernel/profile.o' > Linking bitcode file 'kernel/exit.o' > > Using GDB I could figure out that it is causing stack overflow (some > loop in the code between 0x495be5 and 0x495da7) > > .... > #47 0x0000000000495be5 in ?? () > #48 0x0000000000495da7 in ?? () > #49 0x0000000000495a24 in ?? () > #50 0x0000000000495da7 in ?? () > #51 0x0000000000495be5 in ?? () > #52 0x0000000000495da7 in ?? () > #53 0x0000000000495be5 in ?? () > #54 0x0000000000495da7 in ?? () > #55 0x0000000000495be5 in ?? () > #56 0x0000000000495da7 in ?? () > #57 0x0000000000495be5 in ?? () > #58 0x0000000000495da7 in ?? () > #59 0x0000000000495be5 in ?? () > #60 0x0000000000495da7 in ?? () > #61 0x0000000000495be5 in ?? () > #62 0x0000000000495da7 in ?? () > #63 0x0000000000495be5 in ?? () > #64 0x000000000049609a in ?? () > #65 0x000000000049ab6f in llvm::Linker::LinkModules () > #66 0x0000000000491643 in llvm::Linker::LinkInFile () > #67 0x0000000000491e57 in llvm::Linker::LinkInFiles () > #68 0x00000000004727df in main () > > any ideas what could be wrong here? thanks. > From clattner at apple.com Sun Sep 28 18:05:00 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 28 Sep 2008 16:05:00 -0700 Subject: [LLVMdev] llvm-ld hangs In-Reply-To: References: Message-ID: <05269314-0D8F-4736-ADB4-CFFC324A6377@apple.com> On Sep 28, 2008, at 3:08 PM, Ashish Bijlani wrote: > Forgot to mention that I'm trying to generate LLVM IR. I've also faced > this problem while compiling linux kernel with LLVM to generate LLVM > IR. Please file a bug with the two .o files that cause the problem when linked. The bug report should look like: "This causes llvm-ld to hang: llvm-ld a.o b.o" and include a.o and b.o as attachments. -Chris From akarhu3 at gatech.edu Sun Sep 28 19:15:01 2008 From: akarhu3 at gatech.edu (Karhu, Abhinav R) Date: Sun, 28 Sep 2008 20:15:01 -0400 (EDT) Subject: [LLVMdev] Problem running the program Message-ID: <459436169.3208341222647301420.JavaMail.root@mail7.gatech.edu> I have compiled the program using the following option. llvm-gcc --emit-llvm Hello.c -o Hel.bc I have used llvm in the past but this sort of problem is new for me. I dont know how to go about it. Thanks for the reply. -- Abhinav Karhu MS Computer Science Georgia Institute of Technology From kumare3 at cc.gatech.edu Sun Sep 28 20:43:05 2008 From: kumare3 at cc.gatech.edu (Ketan Pundlik Umare) Date: Sun, 28 Sep 2008 21:43:05 -0400 (EDT) Subject: [LLVMdev] Hi Cache Miss and Branch Misprediction Message-ID: <608144716.260291222652585272.JavaMail.root@pinky.cc.gatech.edu> Hi Guys, I am an absolute newbie to the compiler community. I am experimenting a little bit with llvm. I have a few small questions, i would be really great if someone could help me. 1. Can i find out (is there something already built), if the previous instruction / or some instruction was a cache miss. Basically i want to detect cache misses and instructions that are causing this 2. Can i find if there was a branch misprediction? 3. Can i find if a branch was taken or not taken? It would be really great if someone could answer this for me. Thank you Ketan Georgia Institue of Technology From brendan at brendanyounger.com Sun Sep 28 20:54:36 2008 From: brendan at brendanyounger.com (Brendan Younger) Date: Sun, 28 Sep 2008 21:54:36 -0400 Subject: [LLVMdev] Problem running the program In-Reply-To: <459436169.3208341222647301420.JavaMail.root@mail7.gatech.edu> References: <459436169.3208341222647301420.JavaMail.root@mail7.gatech.edu> Message-ID: <8EC8FB4F-A718-4F11-9465-B7A032F267E5@brendanyounger.com> On Sep 28, 2008, at 8:15 PM, Karhu, Abhinav R wrote: > I have compiled the program using the following option. > > llvm-gcc --emit-llvm Hello.c -o Hel.bc > > I have used llvm in the past but this sort of problem is new for me. > I dont know how to go about it. The documentation states that -emit-llvm has no effect without the -c or -S options. What you want is llvm-gcc -emit-llvm -c -o Hello.bc Hello.c or if you want to see the textual representation of the IR, try llvm-gcc -emit-llvm -S -o Hello.ll Hello.c Brendan From yim6 at illinois.edu Sun Sep 28 23:50:45 2008 From: yim6 at illinois.edu (Keun Soo Yim) Date: Sun, 28 Sep 2008 23:50:45 -0500 Subject: [LLVMdev] Linux Kernel Compile for Sparc v8 Arch Message-ID: <000501c921ee$f02db470$d0891d50$@edu> Does anyone succeed at compiling Linux kernel for Sparc v8 architecture? I am currently trying to expand the regime of LLVM to Sparc kernel codes. The following is the initial error messages. Any comment is welcomed. #1. Inline Assembly Code: register struct thread_info *current_thread_info_reg asm("g6"); Error Message: include/asm/thread_info.h:77: error: invalid register name for 'current_thread_info_reg' #2. Link error for single C file Error Message: /tmp/ccQBRbb6.s:2226: Error: symbol `lstat64' is already defined /tmp/ccQBRbb6.s:2242: Error: symbol `stat64' is already defined /tmp/ccQBRbb6.s:2280: Error: symbol `fstat64' is already defined -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080928/a500eb96/attachment.html From baldrick at free.fr Mon Sep 29 01:50:39 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 29 Sep 2008 08:50:39 +0200 Subject: [LLVMdev] Problems with written function pass In-Reply-To: <12E7CEB9-DA39-4F17-9F24-B4427DAC7564@gmx.de> References: <12E7CEB9-DA39-4F17-9F24-B4427DAC7564@gmx.de> Message-ID: <200809290850.40099.baldrick@free.fr> Hi Marc, I think this problem came up before, but I don't recall the solution. Try searching the mailing list archives. Best wishes, Duncan. From nicholas at mxc.ca Mon Sep 29 02:21:31 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Mon, 29 Sep 2008 00:21:31 -0700 Subject: [LLVMdev] Hi Cache Miss and Branch Misprediction In-Reply-To: <608144716.260291222652585272.JavaMail.root@pinky.cc.gatech.edu> References: <608144716.260291222652585272.JavaMail.root@pinky.cc.gatech.edu> Message-ID: <48E081FB.2080704@mxc.ca> Ketan Pundlik Umare wrote: > Hi Guys, > I am an absolute newbie to the compiler community. I am experimenting a little bit with llvm. > I have a few small questions, i would be really great if someone could help me. It sounds like what you want is valgrind --tool=cachegrind (or --tool=callgrind). See http://valgrind.org/ > 1. Can i find out (is there something already built), if the previous instruction / or some instruction was a cache miss. Basically i want to detect cache misses and instructions that are causing this > > 2. Can i find if there was a branch misprediction? > > 3. Can i find if a branch was taken or not taken? > > It would be really great if someone could answer this for me. I suppose you could instrument the existing LLVM JIT to collect this sort of information. Realize that much of LLVM works in the LLVM IR language, and we just 'lower' to assembly. LLVM 'passes' which modify code work by editing the IR, not the assembly, so things like 'branch prediction' and whatnot don't exist at that level. If you want to do it with LLVM, you'll likely need to build most of the infrastructure yourself. If you're interested in what we do have, see llvm/tools/llvm-prof.cpp, llvm/runtime/libprofile and llvm/utils/profile.pl . I have no idea what state this stuff is in, quite possibly bitrotted. Nick Lewycky From nicolas.geoffray at lip6.fr Mon Sep 29 02:24:19 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 29 Sep 2008 09:24:19 +0200 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <48DD9B6E.3070702@gmail.com> References: <19683007.post@talk.nabble.com> <200809261000.54992.baldrick@free.fr> <48DD9B6E.3070702@gmail.com> Message-ID: <48E082A3.8090900@lip6.fr> Talin wrote: > > > So what about those of us who are implementing frontends that have no > connection with gcc or the c++ runtime at all? Are we out of luck as far > as unwind is concerned? > > Yes you are :) Currently, if you want exceptions using the JIT or static compilation, you need the libgcc runtime (or an equivalent implementation of an unwinding runtime). Or you can use the interpreter, which works with invoke/unwind. Cheers, Nicolas > -- Talin > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From bluehive at gmail.com Mon Sep 29 02:39:39 2008 From: bluehive at gmail.com (vishal kanaujia) Date: Mon, 29 Sep 2008 13:09:39 +0530 Subject: [LLVMdev] llvm-gcc : why no optimization? Message-ID: <6be88c3b0809290039k21ffcb7dh169e04d21fc0e6a4@mail.gmail.com> Hi all, I am a newbie to LLVM and tried experimenting compile a small C program with it. This is what I did: 1. Wrote a simple C program with some dead code. 2. compiled it with llvm-gcc. [$ llvm-gcc -emit-llvm -S deadc.c] 3. Fetched it to assembler. [$ llvm-as deadc.s] 4. [$ opt -analyze -ade deadc.s.bc] [Ran without -analyze switch also: $opt -o final_opt -verify-each -globaldce -f deadc.s] Here I always get the message "Printing analysis 'Dead Global Elimination': Pass::print not implemented for pass: 'Dead Global Elimination'!" 5. Now after step 4, I get a final binary and I disassemble it to see the effect of optimization and lo ! Actually there was no sign of optimization and each piece of code was intact? [llvm-dis final_opt] Am I missing something here? Please let me know. Thanks, Vishal PS: Here is the version information $ llvm-gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../llvm-gcc4.2-2.3.source/configure --prefix=/mounts/zion/disks/0/localhome/tbrethou/2.3/test/llvm-gcc/install --program-prefix=llvm- --enable-llvm=/mounts/zion/disks/0/localhome/tbrethou/2.3/test/llvm-2.3/ --enable-languages=c,c++ --disable-shared --disable-bootstrap Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5555) (LLVM build 2.3) $ /usr/local/bin/opt -version Low Level Virtual Machine (http://llvm.org/): llvm version 2.3 Optimized build with assertions. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080929/613579bd/attachment-0001.html From overminddl1 at gmail.com Mon Sep 29 02:41:48 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 29 Sep 2008 01:41:48 -0600 Subject: [LLVMdev] Integer handling Message-ID: <3f49a9f40809290041h6e19bc8fj446608a0bbef1273@mail.gmail.com> I have ended up making a rather complicated type system to handle quite a few things, all stemming from the fact that the integer type has no sign information (even if it did not use it, would be nice to look at it in my code generator to so I can put out one function type or another when something like udiv/sdiv is called). I essentially have a variant that holds either an llvm::Type* (which at this point pretty much just holds the primitives, like the floating point types, labels, etc...), or it holds a structure I made that just holds an llvm::Type integer, but represents that integer as unsigned (where-as if it is in the llvm::Type part of the variant it is treated as signed), and a few other things. The other things include basically any type that can hold any other type, from arrays to structs and so forth. It was easy enough, I had made on the order of a crap-ton of static_visitors to handle the variant in all its very fast, but still overwhelming uglyness. I have got to the point where I need need to represent the function type, this has suddenly introduced a whole new class of uglyness to handle as the types can propagate into the blocks and so forth. I am just wondering if I am missing some very simple way to handle this. Such as, is there any way in LLVM to 'typedef' (not alias) one of the integer types (say, an i32) to be another 'type' in such a way that my codegen can read it and handle the output instructions different. I have even been thinking of just doing something as simple as making it so even bitsized integers are considered signed and odd are unsigned (then converting the odd ones to an even on a word boundary, so a signed and unsigned i32 would be generated the same when finished being compiled, but would be represented during creation as the signed being i32 and the unsigned as an i33, or vice-versa, whichever). Does anyone have any ideas about handling this in a much cleaner way that does not involve creating my own entire type system? How do others handle this, or do other even expose multiple integer types or just handle them all as signed or something? My mind is starting to go numb from all the type system creation over the past three days (which, although is very powerful, added quite a few features over llvm that I do not really need, but still...), and I cannot even get to my point of starting to split up functions into parts until I get either my type system sorted through it (which will probably take another week... at least), or I dump it all and use some more 'llvm'ish way? From baldrick at free.fr Mon Sep 29 02:50:54 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 29 Sep 2008 09:50:54 +0200 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <48DD9B6E.3070702@gmail.com> References: <200809261000.54992.baldrick@free.fr> <48DD9B6E.3070702@gmail.com> Message-ID: <200809290950.54254.baldrick@free.fr> > So what about those of us who are implementing frontends that have no > connection with gcc or the c++ runtime at all? Are we out of luck as far > as unwind is concerned? For the moment, yes. If unwind gets implemented one day (I have a plan, but no time right now), the implementation is sure to call routines in the gcc runtime. Ciao, Duncan. From overminddl1 at gmail.com Mon Sep 29 03:13:17 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 29 Sep 2008 02:13:17 -0600 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <200809290950.54254.baldrick@free.fr> References: <200809261000.54992.baldrick@free.fr> <48DD9B6E.3070702@gmail.com> <200809290950.54254.baldrick@free.fr> Message-ID: <3f49a9f40809290113i1980c9c5ree81ea786c9c6a4e@mail.gmail.com> On Mon, Sep 29, 2008 at 1:50 AM, Duncan Sands wrote: > /* snip */ Just for another voice in here. 'unwind' and its kin would also be useful for me, especially since this is on platforms without GCC (nor is GCC used in any way in any step anywhere). Why does it generate GCC only constructs anyway, that does not sound very much like the multi-platform that LLVM is targeting. From shap at eros-os.com Mon Sep 29 04:13:15 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Mon, 29 Sep 2008 05:13:15 -0400 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <200809290950.54254.baldrick@free.fr> References: <200809261000.54992.baldrick@free.fr> <48DD9B6E.3070702@gmail.com> <200809290950.54254.baldrick@free.fr> Message-ID: <1222679595.18981.27.camel@vmx> On Mon, 2008-09-29 at 09:50 +0200, Duncan Sands wrote: > For the moment, yes. If unwind gets implemented one day (I have a plan, > but no time right now), the implementation is sure to call routines in > the gcc runtime. As a transient solution that makes sense, but it seems desirable to have a generalized unwind scheme that is not tied to libgcc. shap From baldrick at free.fr Mon Sep 29 04:02:15 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 29 Sep 2008 11:02:15 +0200 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <3f49a9f40809290113i1980c9c5ree81ea786c9c6a4e@mail.gmail.com> References: <200809290950.54254.baldrick@free.fr> <3f49a9f40809290113i1980c9c5ree81ea786c9c6a4e@mail.gmail.com> Message-ID: <200809291102.15392.baldrick@free.fr> Hi, > Why does it generate GCC only constructs anyway, that does not sound > very much like the multi-platform that LLVM is targeting. since libgcc is available everywhere llvm is, it's as multi-platform as llvm! If we didn't use libgcc then we'd have to introduce an llvm runtime library. Since it would just duplicate the functionality of libgcc, it would introduce an additional maintenance burden without bringing any real advantage AFAICS. Ciao, Duncan. From nicolas.geoffray at lip6.fr Mon Sep 29 04:31:55 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 29 Sep 2008 11:31:55 +0200 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <3f49a9f40809290113i1980c9c5ree81ea786c9c6a4e@mail.gmail.com> References: <200809261000.54992.baldrick@free.fr> <48DD9B6E.3070702@gmail.com> <200809290950.54254.baldrick@free.fr> <3f49a9f40809290113i1980c9c5ree81ea786c9c6a4e@mail.gmail.com> Message-ID: <48E0A08B.6000604@lip6.fr> I guess Duncan's answer in this thread is the best answer to give: <> So yes, ultimately, unwind will be supported and clang/llvm should provide its own unwinding runtime. Patches welcome :) Cheers, Nicolas OvermindDL1 wrote: > On Mon, Sep 29, 2008 at 1:50 AM, Duncan Sands wrote: > >> /* snip */ >> > > Just for another voice in here. 'unwind' and its kin would also be > useful for me, especially since this is on platforms without GCC (nor > is GCC used in any way in any step anywhere). > > Why does it generate GCC only constructs anyway, that does not sound > very much like the multi-platform that LLVM is targeting. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From rene at exactcode.de Mon Sep 29 04:44:16 2008 From: rene at exactcode.de (=?ISO-8859-1?Q?Ren=E9_Rebe?=) Date: Mon, 29 Sep 2008 11:44:16 +0200 Subject: [LLVMdev] compile linux kernel In-Reply-To: <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> Message-ID: <48E0A370.9070208@exactcode.de> And the code of the Linux kernel compiled by LLVM is also very arch depended, despite any loader and hw access will not work inside the standard LLVM JIT, all the MMU and low-level access stuff will make no sense on a machine other than what was enabled while compiling the kernel. E.g. you would need a whole virtualized HW architecture ala Qemu (et al.) along the JIT. Of course in theory one could setup such an infrastructure to JIT low level, kernel and driver code, just throwing the i386 linux kernel source on LLVM will not bring you there. Yours, Daniel Berlin wrote: > No, this is not the case. > > Just because you compile something to LLVM IR does not make the thing > you compiled work on every architecture. > You may even be able to retarget it to any architecture (it depends), > but this in no way means the result will *actually work*. > The LLVM IR generated by llvm-gcc is very architecture dependent. > Theoretically you could make a C compiler that was mostly C compliant > and produced architecture independent LLVM IR. > llvm-gcc is not this compiler, however. > > On Sun, Sep 28, 2008 at 1:07 AM, Ashish Bijlani > wrote: > >> does that mean .o generated with gcc (.c -> .s and .s -> .o) will not >> contain llvm ir? >> >> i meant, final kernel bitcode ir arch independent and can be JIT with >> any arch-specific backend. Is it not the case? >> >> thanks, >> ashish >> >> On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth wrote: >> >>> On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani >>> wrote: >>> >>>> If I use GCC to generate asm-offsets.s file, then the build system go >>>> ahead but fails when it generates .so files as Andrew pointed out. >>>> >>> You have to generate this with gcc. .c -> .s and .s -> .o need gcc, >>> .c -> .o can use llvm-gcc. The combination has to be fixed up in >>> final linking. >>> >>> >>>> Now, If the build systems generates .so files, then it will be >>>> difficult o actually generate fully arch-independent kernel code, >>>> isn't it? >>>> >>> A llvm compiled kernel is in no way arch-independent. It is very very >>> arch dependent. >>> >>> Andrew >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name From matthijs at stdin.nl Mon Sep 29 04:49:51 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Mon, 29 Sep 2008 11:49:51 +0200 Subject: [LLVMdev] llvm-gcc : why no optimization? In-Reply-To: <6be88c3b0809290039k21ffcb7dh169e04d21fc0e6a4@mail.gmail.com> References: <6be88c3b0809290039k21ffcb7dh169e04d21fc0e6a4@mail.gmail.com> Message-ID: <20080929094951.GJ15228@katherina.student.utwente.nl> Hi Vishal, you might want to post the C code you were using. I suspect you wrote a function which is dead, but forgot to declare it static? If a function is not static, it is externally visible, so it's alive even when it's not referenced internally. You might want to look at the "internalize" pass as well, to make this process automatic for programs with a main function defined. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080929/8272c983/attachment.bin From shap at eros-os.com Mon Sep 29 04:53:19 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Mon, 29 Sep 2008 05:53:19 -0400 Subject: [LLVMdev] compile linux kernel In-Reply-To: <48E0A370.9070208@exactcode.de> References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> Message-ID: <1222681999.29370.8.camel@vmx> Watching this thread, it occurs to me that the "V" in "LLVM" is creating confusion. So far as I know, LLVM is the first project to use "virtual" to refer to the instruction set of the intermediate form. I understand why this labeling made sense (sort of), but it was unfortunate. The machine is abstract, not virtual, and the use of "virtual" here is so out of keeping with any other use of the term that it really does generate confusion. Is this worth a FAQ entry? From arabinda.v at samsung.com Mon Sep 29 05:07:16 2008 From: arabinda.v at samsung.com (ARABINDA VERMA) Date: Mon, 29 Sep 2008 10:07:16 +0000 (GMT) Subject: [LLVMdev] LLVM and dynamic binary translator Message-ID: <2107270.59331222682835973.JavaMail.weblogic@epml01> Hello List, I am a newbie regarding LLVM and need some information on LLVM. I am working on dynamic binary translation and I am looking into if LLVM can be used for the purpose. The goal here is to generate highly optimized translated (host) code from target code. I have following questions. 1. Can LLVM be used in a dynamic binary translator? Dynamic translator translators target code for an architecture (say PPC) to host code (say x86) and execute it. 2. Can LLVM understand disassembled target code and generate optimized host code? 3. If yes to (1) and (2), where I can find more information? 4. How complex the task would be? (any idea!!) I appreciate your help. Thanks and regards Arabinda From asl at math.spbu.ru Mon Sep 29 05:49:14 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Mon, 29 Sep 2008 14:49:14 +0400 (MSD) Subject: [LLVMdev] =?koi8-r?b?TExWTSBhbmQgZHluYW1pYyBiaW5hcnkgdHJhbnNsYXRv?= =?koi8-r?b?cg==?= Message-ID: <200809291049.m8TAnEuc047797@star.math.spbu.ru> Hello, > 1. Can LLVM be used in a dynamic binary translator? Dynamic translator translators target code for an architecture (say PPC) to host code (say x86) and execute it. Yes, see llvm-qemu project (2007 GSoC). > 2. Can LLVM understand disassembled target code and generate optimized host code? No, it's not a job of LLVM. You have to convert binary code for your platform into LLVM IR by yourself. > 4. How complex the task would be? (any idea!!) It depends, how complex and insane your source platform, how you will use produced code, etc. In any way, I don't see generic way to do so 'statically', only via execution (think about indirect/computed jumps, for example). -- WBR, Anton Korobeynikov From m.kooijman at student.utwente.nl Mon Sep 29 05:52:16 2008 From: m.kooijman at student.utwente.nl (Matthijs Kooijman) Date: Mon, 29 Sep 2008 12:52:16 +0200 Subject: [LLVMdev] LLVM and dynamic binary translator In-Reply-To: <2107270.59331222682835973.JavaMail.weblogic@epml01> References: <2107270.59331222682835973.JavaMail.weblogic@epml01> Message-ID: <20080929105215.GN15228@katherina.student.utwente.nl> Hi Arabinda, > 1. Can LLVM be used in a dynamic binary translator? Dynamic translator > translators target code for an architecture (say PPC) to host code (say x86) > and execute it. There has been some discussion about this within the past two months on this list, IIRC. You should try searching the archives for that discussion. IIRC, the outcome is that transforming binary code into LLVM IR is very, very tricky, and almost impossible to do right for any possible input binary. Others can problem comment a bit more on the topic, I'm just repeating what I heard other people say on this list :-) Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080929/f2db8603/attachment.bin From mattgiuca at gmail.com Mon Sep 29 07:58:32 2008 From: mattgiuca at gmail.com (Matt Giuca) Date: Mon, 29 Sep 2008 05:58:32 -0700 (PDT) Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <200809291102.15392.baldrick@free.fr> References: <19683007.post@talk.nabble.com> <200809261000.54992.baldrick@free.fr> <48DD9B6E.3070702@gmail.com> <200809290950.54254.baldrick@free.fr> <3f49a9f40809290113i1980c9c5ree81ea786c9c6a4e@mail.gmail.com> <200809291102.15392.baldrick@free.fr> Message-ID: <19723406.post@talk.nabble.com> Duncan Sands wrote: > > since libgcc is available everywhere llvm is, it's as multi-platform > as llvm! If we didn't use libgcc then we'd have to introduce an llvm > runtime library. Since it would just duplicate the functionality of > libgcc, it would introduce an additional maintenance burden without > bringing any real advantage AFAICS. > So if there's to be a dependency on libgcc anyway, why not (at least for the time being) have the unwind instruction simply compile into a call to __cxa_throw or whatever libgcc-based mechanism you're thinking of. (Surely there's some boilerplate code to make this work, assuming libgcc is available?) It would be better than compiling to nothing, as it does now. (Though maybe I'm not understanding the complexity of what's involved; it sounds to me like you're just calling a library function). Thanks for all the helpful responses, devs. -- View this message in context: http://www.nabble.com/Unwinds-Gone-Wild-tp18747589p19723406.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From baldrick at free.fr Mon Sep 29 08:11:14 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 29 Sep 2008 15:11:14 +0200 Subject: [LLVMdev] confused about llvm.memory.barrier In-Reply-To: <1222353674.4726.8.camel@shaptop.om-md.eros-os.com> References: <48DBA004.6020309@cs.rochester.edu> <1222353674.4726.8.camel@shaptop.om-md.eros-os.com> Message-ID: <200809291511.14641.baldrick@free.fr> > In its usual configuration, an x86 family CPU implements a strong memory > ordering constraint for all loads and stores, so as long as the ordering > of the read and write operations is preserved no atomic operation is > required between them. XCHG and CAS only become necessary when you are > coordinating reads and writes across processors. MFENCE similarly. So... gcc's memory barriers are of no use on a multi-processor system? These are pretty common nowadays, so that sounds very bad... Ciao, Duncan. From christian.plessl at uni-paderborn.de Mon Sep 29 08:18:44 2008 From: christian.plessl at uni-paderborn.de (Christian Plessl) Date: Mon, 29 Sep 2008 15:18:44 +0200 Subject: [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel) In-Reply-To: <1222681999.29370.8.camel@vmx> References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> <1222681999.29370.8.camel@vmx> Message-ID: On 29.09.2008, at 11:53, Jonathan S. Shapiro wrote: > Watching this thread, it occurs to me that the "V" in "LLVM" is > creating > confusion. So far as I know, LLVM is the first project to use > "virtual" > to refer to the instruction set of the intermediate form. I understand > why this labeling made sense (sort of), but it was unfortunate. The > machine is abstract, not virtual, and the use of "virtual" here is so > out of keeping with any other use of the term that it really does > generate confusion. The topic whether LLVM bitcode is independent of the target platform was raised several times on the mailing list, but it was never discussed in detail. I would appreciate learning more about the following questions: - Is the architecture dependence of LLVM IR only an artifact of llvm- gcc producing architecture dependent results? - What architecture-specific features are present in the IR that prevent running the same LLVM bitcode on different architectures? > Is this worth a FAQ entry? I would definitely appreciate such a FAQ entry. Best regards, Christian From andrewl at lenharth.org Mon Sep 29 08:25:19 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 29 Sep 2008 08:25:19 -0500 Subject: [LLVMdev] compile linux kernel In-Reply-To: References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> Message-ID: <85dfcd7f0809290625m2c6a8c97y5273131525b3a726@mail.gmail.com> On Sun, Sep 28, 2008 at 12:07 AM, Ashish Bijlani wrote: > does that mean .o generated with gcc (.c -> .s and .s -> .o) will not > contain llvm ir? The kernel uses .c -> .s steps to build target dependent asm including things such as struct offsets. The kernel has some .s files (often including the ones generated from .c files) that are target dependent. Finally simple things such as interrupt controllers and clocks and io architecture and mmu control are all target independent. > i meant, final kernel bitcode ir arch independent and can be JIT with > any arch-specific backend. Is it not the case? The SVA project (http://sva.cs.uiuc.edu/SVA_files/page0002.html see top two papers) made inroads on this with significant extensions to the instruction set to virtualize many hardware elements the OS must deal with. Andrew > thanks, > ashish > > On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth wrote: >> On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani >> wrote: >>> If I use GCC to generate asm-offsets.s file, then the build system go >>> ahead but fails when it generates .so files as Andrew pointed out. >> >> You have to generate this with gcc. .c -> .s and .s -> .o need gcc, >> .c -> .o can use llvm-gcc. The combination has to be fixed up in >> final linking. >> >>> Now, If the build systems generates .so files, then it will be >>> difficult o actually generate fully arch-independent kernel code, >>> isn't it? >> >> A llvm compiled kernel is in no way arch-independent. It is very very >> arch dependent. >> >> Andrew >> _______________________________________________ >> 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 andrewl at lenharth.org Mon Sep 29 08:46:58 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 29 Sep 2008 08:46:58 -0500 Subject: [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel) In-Reply-To: References: <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> <1222681999.29370.8.camel@vmx> Message-ID: <85dfcd7f0809290646m149e7db0h10de346b1b0de01a@mail.gmail.com> On Mon, Sep 29, 2008 at 8:18 AM, Christian Plessl wrote: > - Is the architecture dependence of LLVM IR only an artifact of llvm- > gcc producing architecture dependent results? No. It also is an artifact of code compiling architecture and OS dependent features based on what they detect at configure time It is an artifact of compiling non-type safe languages. It is an artifact of system headers including inline asm. It is an artifact of the endianness of the system. > - What architecture-specific features are present in the IR that > prevent running the same LLVM bitcode on different architectures? A better question is: what architecture-abstracting features would make writing target independent LLVM bitcode easier? There is 1 that I think is critical, and 3 more that would make life much easier (though technically redundant). hton and ntoh intrinsics. These are needed to allow target code to deal with endianness in a target independent way. (Ok, you could potentially write code that detected endiannes at runtime and chose multiversioned code based on that, but that is ugly and optimization prohibiting). redundant, but greatly simplifying: iptr aliased type. There are legitamate cases where you want to perform arithmetic and comparisons on pointers that the semantics of GEP make illegal so the only way to do so in a target independent way is to either cast to an int you hope is >= than any pointer, or violate the GEP semantics (which is generally works). GBP instruction (GetBasePointer). The inverse of a GEP. A GEP selects an offset into a object in a target independent way based on the type. What GBP would do would be to get a pointer to the base of an object based on a pointer to field, a type, and the same specifier as the GEP would use to get the field. x == GBP (GEP x, 0, 1, 1), typeof(x), 0, 1, 1 This would make upcasts or any conversion from an embedded object to a parent object not need arch dependent offsets and raw pointer manipulation. (yes you could figure out the offset from GEP off null trick and use raw pointer manipulation and casts) sizeof instruction. Again, you can use the GEP off null trick, but this isn't very obvious, but since it doesn't involve raw pointer manipulation. Andrew From andrewl at lenharth.org Mon Sep 29 09:02:14 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 29 Sep 2008 09:02:14 -0500 Subject: [LLVMdev] linker script In-Reply-To: References: Message-ID: <85dfcd7f0809290702o245b5179h25184ac7e22f24f6@mail.gmail.com> On Sun, Sep 28, 2008 at 1:57 PM, Ashish Bijlani wrote: > Hi, > > I'm trying to compile linux kernel with llvm to generate llvm ir > (bitcode). It seems like llvm-ld doesn't accept any linker scripts. > How do I deal with vmlinux.lds in such a case? How did people who have > compiled linux kernel with llvm deal with this in the past? You need to add a bytecode linker stage before that. You still need the linker script for correctness, but you must use it in the final link stage after you have generated a native .o file from the bitcode. By the way, it you are still planning on jitting the kernel, you should be warned that the linker script creates globals and arrays that are referenced by the kernel code but otherwise will appear nowhere in your bitcode... You will have to rewrite the kernel's initialization infastructure or write a pass to fix up the bitcode or both. Andrew From andrewl at lenharth.org Mon Sep 29 09:07:55 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 29 Sep 2008 09:07:55 -0500 Subject: [LLVMdev] llvm-ld hangs In-Reply-To: References: Message-ID: <85dfcd7f0809290707v326c4d17wdfe20bae8c145423@mail.gmail.com> On Sun, Sep 28, 2008 at 5:06 PM, Ashish Bijlani wrote: > Hi, > > I'm trying to compile UML with LLVM. However, LLVM-LD hangs whiile > linking modules. It's consuming 99% of the CPU > llvm-ld -v -r -o kernel/built-in.o kernel/sched.o kernel/fork.o Are you using trunk or the last release? That directory was the cause of this bug, which is fixed in head: http://llvm.org/bugs/show_bug.cgi?id=1860 This bug may also be of interest since it came from compiling that directory too, but possibly should now be marked worksforme now: http://llvm.org/bugs/show_bug.cgi?id=2124 Andrew From samuraileumas at yahoo.com Mon Sep 29 09:11:09 2008 From: samuraileumas at yahoo.com (Samuel Crow) Date: Mon, 29 Sep 2008 07:11:09 -0700 (PDT) Subject: [LLVMdev] Virtrual instruction set was: re:compile linux kernel In-Reply-To: <1222681999.29370.8.camel@vmx> Message-ID: <278734.40868.qm@web62006.mail.re1.yahoo.com> Hello Jonathan, Actually it is the second project that I know of that used the term Virtual to describe the intermediate instruction set. Virtual Processor was part of a failed attempt by the Tao Group and Amiga Inc. to bring a common set of runtimes and instruction sets to handheld devices (called AmigaDE). Later, certain optimizations appeared in Java allowing it to catch on instead. In an effort to minimize their losses, Amiga released a subset of it with a hosted operating system called AmigaAnywhere and a few titles were released on it. To make a long story short, VP Assembler was replaced by some GCC cross-compilers and renamed AmigaAnywhere 2.0 . For more information about this, refer to http://amiga.com/developers/ . This is trivia however as there isn't even a Wikipedia article about VP Assembler now. --Sam --- On Mon, 9/29/08, Jonathan S. Shapiro wrote: > From: Jonathan S. Shapiro > Subject: Re: [LLVMdev] compile linux kernel > To: "LLVM Developers Mailing List" > Date: Monday, September 29, 2008, 4:53 AM > Watching this thread, it occurs to me that the "V" > in "LLVM" is creating > confusion. So far as I know, LLVM is the first project to > use "virtual" > to refer to the instruction set of the intermediate form. I > understand > why this labeling made sense (sort of), but it was > unfortunate. The > machine is abstract, not virtual, and the use of > "virtual" here is so > out of keeping with any other use of the term that it > really does > generate confusion. > > Is this worth a FAQ entry? > > _______________________________________________ > 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 Sep 29 09:40:03 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 29 Sep 2008 16:40:03 +0200 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <19723406.post@talk.nabble.com> References: <200809291102.15392.baldrick@free.fr> <19723406.post@talk.nabble.com> Message-ID: <200809291640.03698.baldrick@free.fr> > So if there's to be a dependency on libgcc anyway, why not (at least for the > time being) have the unwind instruction simply compile into a call to > __cxa_throw or whatever libgcc-based mechanism you're thinking of. (Surely > there's some boilerplate code to make this work, assuming libgcc is > available?) It would be better than compiling to nothing, as it does now. Sure, but someone has to sit down and do it. > (Though maybe I'm not understanding the complexity of what's involved; it > sounds to me like you're just calling a library function). The devil is in the details :) For example, the gcc throw routine expects you to pass it a suitably initialized object. That object has to be allocated somewhere, which basically means the heap or in a per-cpu global (can't be on the stack, because the stack is being unwound!). Getting more complicated already! When unwinding stops you have to free that memory. However if the landing pad already contains a dwarf exception handler (eg: you unwound to a C++ handler) that code will already deal with freeing the memory (the C++ personality does do some handling of "foreign" exceptions IIRC), so you have to identify "naked" landing pads and insert appropriate code there. Anyway, it's not the end of the world, just pointing out that it requires some thinking and work to get a solution that works right and interacts nicely with the Ada/C++/XYZ exception handling code. Ciao, Duncan. From evan.cheng at apple.com Mon Sep 29 10:51:57 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 29 Sep 2008 08:51:57 -0700 Subject: [LLVMdev] Going from argument to register and back In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C12E1C4@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C12E1C4@ssanexmb1.amd.com> Message-ID: On Sep 25, 2008, at 10:49 AM, Villmow, Micah wrote: > I am having trouble trying to figure out two pieces of information > from attempting to map arguments to registers. > How do I determine, based on the argument name, which register the > value is supposed to be assigned to? > I can hard-coded it currently and it will be correct 100% of the > time with the current set of assumptions, > but I would rather determine it dynamically so that I can change my > assumptions and still get the right results. Why would you want to map arguments to registers based on names? Calling conventions are encoded in td files such X86CallingConv.td. Parameter registers etc. are determined from argument number / type, not names. Evan > > Thanks, > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > 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/20080929/5a2a1a9a/attachment.html From evan.cheng at apple.com Mon Sep 29 11:01:02 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 29 Sep 2008 09:01:02 -0700 Subject: [LLVMdev] Determining the register type of a MachineOperand In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C12E374@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C0BA2B2@ssanexmb1.amd.com> <5BA674C5FF7B384A92C2C95D8CC71E1C0BA435@ssanexmb1.amd.com> <1413AD2F-BF58-481C-8F0A-34F2803F300E@apple.com> <200809261038.40052.dag@cray.com> <5BA674C5FF7B384A92C2C95D8CC71E1C12E374@ssanexmb1.amd.com> Message-ID: Sounds like you should specify a few class of pseudo registers mapped to the same set of registers. This is something we are considering for x86. That is, have xmm0_64, xmm0_32, and xmm0 all mapping to xmm0. If the first one is used, it means only the lower 64-bits are needed. An alternative is to encode such information in the opcode or as a pseudo immediate operand. Or, in the worst case, you can just iterate through all the uses / defs to determine the type Type information just doesn't belong on MachineOperand's. They belong to machine instructions, i.e. how they are defined / used. Evan On Sep 26, 2008, at 8:59 AM, Villmow, Micah wrote: > Yes, > Another reason this is useful is for register-type specific > representations of said register. > > For example, all my registers are 128bit vector registers, however, > if I > am only dealing with 32 bit vector registers, I can add write/read > masks > that tell the underlying hardware not to work on the whole register, > but > just a subset of the components. > 32bit scalar mov: mov r1.x___, r0.x000 > 64bit scalar mov: mov r1.xy__, r0.xy00 > 96bit scalar mov: mov r1.xyz_, r0.xyz0 > 128bit scalar mov: mov r1, r0 > > If I had the register type information at code generation time, then I > can use the exact same tablegen pattern for all my register types and > would only need to add the write/read masks in the printer instead of > multiple patterns. > > Multiply this by over 100 opcodes and I save A LOT of work. > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of David Greene > Sent: Friday, September 26, 2008 8:39 AM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Determining the register type of a > MachineOperand > > On Wednesday 24 September 2008 15:23, Mon Ping Wang wrote: >> To my knowledge, I don't think there is an easy way to get the MVT >> information from a MachineOperand. Why do you need it for? In my > > See the thread I started on this very topic. Spilling is one place > you'd like > to have this information. > >> mind, the MachineInstr and its associated operands represent a >> physical machine instruction and I typically want to think of those >> as >> machine opcodes and machine register files. I am typically >> interested >> in the mapping of MVTs to register classes when I'm generating >> machine >> instructions. Note that a register class may map to multiple MVTs >> depending on your description. > > Right, but the instruction opcode should give a clue about what the > bits > > represent. That mapping is what's currently missing. > > -Dave > _______________________________________________ > 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 Micah.Villmow at amd.com Mon Sep 29 11:10:48 2008 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Mon, 29 Sep 2008 09:10:48 -0700 Subject: [LLVMdev] Going from argument to register and back In-Reply-To: References: <5BA674C5FF7B384A92C2C95D8CC71E1C12E1C4@ssanexmb1.amd.com> Message-ID: <5BA674C5FF7B384A92C2C95D8CC71E1C12E599@ssanexmb1.amd.com> One of the requirements for the backend that I am targeting is certain meta-data needs to be returned to the runtime. This includes the mapping between parameters and the locations this data is expected to be stored at. This is mainly because there are multiple address spaces and each one is mapped differently but all are assigned registers from the same register class. So this mapping needs to be known at compile time and passed in the generated code to the runtime to be processed before execution. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, September 29, 2008 8:52 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Going from argument to register and back On Sep 25, 2008, at 10:49 AM, Villmow, Micah wrote: I am having trouble trying to figure out two pieces of information from attempting to map arguments to registers. How do I determine, based on the argument name, which register the value is supposed to be assigned to? I can hard-coded it currently and it will be correct 100% of the time with the current set of assumptions, but I would rather determine it dynamically so that I can change my assumptions and still get the right results. Why would you want to map arguments to registers based on names? Calling conventions are encoded in td files such X86CallingConv.td. Parameter registers etc. are determined from argument number / type, not names. Evan Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 _______________________________________________ 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/20080929/e5455801/attachment.html From dag at cray.com Mon Sep 29 11:21:58 2008 From: dag at cray.com (David Greene) Date: Mon, 29 Sep 2008 11:21:58 -0500 Subject: [LLVMdev] Cannot Select ConstantFP on x86 In-Reply-To: <57186AB8-6E85-4A23-888A-02F0126FEC1D@apple.com> References: <200809241911.07519.dag@cray.com> <200809261043.01095.dag@cray.com> <57186AB8-6E85-4A23-888A-02F0126FEC1D@apple.com> Message-ID: <200809291121.58465.dag@cray.com> On Friday 26 September 2008 16:59, Chris Lattner wrote: > On Sep 26, 2008, at 8:43 AM, David Greene wrote: > >> Do you have a testcase? It sounds like something that would be easy > >> to fix. > > > > I have a fix (yes, it was trivial). I'll have to see about a > > testcase as it's > > proprietary code. > > Usually, proprietary testcases can be reduced and simplified to the > point where they are innocuous, Yep, that's what I'm trying to do. -Dave From kumare3 at cc.gatech.edu Mon Sep 29 11:29:41 2008 From: kumare3 at cc.gatech.edu (Ketan Pundlik Umare) Date: Mon, 29 Sep 2008 12:29:41 -0400 (EDT) Subject: [LLVMdev] Hi Cache Miss and Branch Misprediction In-Reply-To: <48E081FB.2080704@mxc.ca> Message-ID: <75063092.265401222705781519.JavaMail.root@pinky.cc.gatech.edu> Thanx a lot Nick!!! I will try to look at it and let you know. Thank you Ketan ----- Original Message ----- From: "Nick Lewycky" To: "LLVM Developers Mailing List" Sent: Monday, September 29, 2008 3:21:31 AM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] Hi Cache Miss and Branch Misprediction Ketan Pundlik Umare wrote: > Hi Guys, > I am an absolute newbie to the compiler community. I am experimenting a little bit with llvm. > I have a few small questions, i would be really great if someone could help me. It sounds like what you want is valgrind --tool=cachegrind (or --tool=callgrind). See http://valgrind.org/ > 1. Can i find out (is there something already built), if the previous instruction / or some instruction was a cache miss. Basically i want to detect cache misses and instructions that are causing this > > 2. Can i find if there was a branch misprediction? > > 3. Can i find if a branch was taken or not taken? > > It would be really great if someone could answer this for me. I suppose you could instrument the existing LLVM JIT to collect this sort of information. Realize that much of LLVM works in the LLVM IR language, and we just 'lower' to assembly. LLVM 'passes' which modify code work by editing the IR, not the assembly, so things like 'branch prediction' and whatnot don't exist at that level. If you want to do it with LLVM, you'll likely need to build most of the infrastructure yourself. If you're interested in what we do have, see llvm/tools/llvm-prof.cpp, llvm/runtime/libprofile and llvm/utils/profile.pl . I have no idea what state this stuff is in, quite possibly bitrotted. Nick Lewycky _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ashish.bijlani at gmail.com Mon Sep 29 12:01:02 2008 From: ashish.bijlani at gmail.com (Ashish Bijlani) Date: Mon, 29 Sep 2008 13:01:02 -0400 Subject: [LLVMdev] llvm-ld hangs [[FIXED]] Message-ID: Thanks Andrew. I downloaded the latest LLVM release version 2.3. This was indeed a bug in LLVM that I've. I fixed it using the patch you specified. Thanks!! There are no recursive loops anymore. On Mon, Sep 29, 2008 at 10:07 AM, Andrew Lenharth wrote: > On Sun, Sep 28, 2008 at 5:06 PM, Ashish Bijlani > wrote: >> Hi, >> >> I'm trying to compile UML with LLVM. However, LLVM-LD hangs whiile >> linking modules. It's consuming 99% of the CPU >> llvm-ld -v -r -o kernel/built-in.o kernel/sched.o kernel/fork.o > > Are you using trunk or the last release? > That directory was the cause of this bug, which is fixed in head: > http://llvm.org/bugs/show_bug.cgi?id=1860 > This bug may also be of interest since it came from compiling that > directory too, but possibly should now be marked worksforme now: > http://llvm.org/bugs/show_bug.cgi?id=2124 > > Andrew > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From clattner at apple.com Mon Sep 29 13:04:16 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 29 Sep 2008 11:04:16 -0700 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <48E0A08B.6000604@lip6.fr> References: <200809261000.54992.baldrick@free.fr> <48DD9B6E.3070702@gmail.com> <200809290950.54254.baldrick@free.fr> <3f49a9f40809290113i1980c9c5ree81ea786c9c6a4e@mail.gmail.com> <48E0A08B.6000604@lip6.fr> Message-ID: <59EAA45D-BF22-496C-AF81-40020617D5FA@apple.com> On Sep 29, 2008, at 2:31 AM, Nicolas Geoffray wrote: > I guess Duncan's answer in this thread is the best answer to give: > > < done I guess everyone took a breather and kind of forgot about > unwind>> > > So yes, ultimately, unwind will be supported and clang/llvm should > provide its own unwinding runtime. I have tentative plans to bring over a libunwind-based solution to the clang version of "libgcc" when C++ is farther along in clang. -Chris From akarhu3 at gatech.edu Mon Sep 29 13:57:53 2008 From: akarhu3 at gatech.edu (Karhu, Abhinav R) Date: Mon, 29 Sep 2008 14:57:53 -0400 (EDT) Subject: [LLVMdev] Problem running program with LLVM JIT Message-ID: <1674617516.3630461222714673502.JavaMail.root@mail7.gatech.edu> Hey all, I compiled the code using both the -c and -S options. I can get the human readable IR but I still cannot run it using lli. The output of the IR looks like this. Can some of the information tell me about why the program is not running. ; ModuleID = 'Hel.c' target datalayout = "e-p:32:32" target endian = little target pointersize = 32 target triple = "i686-pc-linux-gnu" %str = internal constant [10 x sbyte] c"Hey there\00" ; <[10 x sbyte]*> [#uses=1] implementation ; Functions: int %main() { entry: %retval = alloca int, align 4 ; [#uses=2] %tmp = alloca int, align 4 ; [#uses=2] These are the lines of code I guess which will have all the information that is causing the error. Some enlightenment on this please. -- Abhinav Karhu MS Computer Science Georgia Institute of Technology From sherief at mganin.com Mon Sep 29 14:03:43 2008 From: sherief at mganin.com (Sherief N. Farouk) Date: Mon, 29 Sep 2008 15:03:43 -0400 Subject: [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel) In-Reply-To: <85dfcd7f0809290646m149e7db0h10de346b1b0de01a@mail.gmail.com> References: <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> <1222681999.29370.8.camel@vmx> <85dfcd7f0809290646m149e7db0h10de346b1b0de01a@mail.gmail.com> Message-ID: <001301c92266$1865e7b0$4931b710$@com> > hton and ntoh intrinsics. These are needed to allow target code to > deal with endianness in a target independent way. (Ok, you could > potentially write code that detected endiannes at runtime and chose > multiversioned code based on that, but that is ugly and optimization > prohibiting). > Why not add types with explicit endianess? A trick I use for reading binary files across platforms is to define the types int32, int32_le and int32_be : int32 is platform-native, _le and _be are little and big endian, respectively. I use and #ifdef in my types.hpp to determine which of _le and _be is a typedef for the standard uint32, and the other is implemented as a class with operator int32(). "add i32_be %X, 8" looks elegant to me, and quite easy (for someone writing the ir output to a text file, like me :) to bolt on to existing code. - Sherief From overminddl1 at gmail.com Mon Sep 29 14:05:49 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 29 Sep 2008 13:05:49 -0600 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <200809291701.24294.baldrick@free.fr> References: <200809291102.15392.baldrick@free.fr> <3f49a9f40809290759y41646774hd33a44ea94a7eed4@mail.gmail.com> <200809291701.24294.baldrick@free.fr> Message-ID: <3f49a9f40809291205t1f007fr613dc42390a224a2@mail.gmail.com> Whoops, did not send to list: On Mon, Sep 29, 2008 at 9:01 AM, Duncan Sands wrote: > libgcc is also available for windows. Really? What license? What restrictions? Any speed impact over the VC runtimes? From criswell at cs.uiuc.edu Mon Sep 29 14:09:48 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 29 Sep 2008 14:09:48 -0500 Subject: [LLVMdev] Problem running program with LLVM JIT In-Reply-To: <1674617516.3630461222714673502.JavaMail.root@mail7.gatech.edu> References: <1674617516.3630461222714673502.JavaMail.root@mail7.gatech.edu> Message-ID: <48E127FC.6050401@cs.uiuc.edu> Karhu, Abhinav R wrote: > Hey all, > I compiled the code using both the -c and -S options. I can get the human readable IR but I still cannot run it using lli. > You need to assemble the human-readable IR into bitcode before it can be executed with lli. To assemble the bitcode, use the llvm-as tool. FYI, using the -c option with -emit-llvm option in llvm-gcc/llvm-g++ will automatically generate an LLVM bitcode file instead of an LLVM assembly file. You may find this faster than compiling to LLVM assembly, then assembling with llvm-as, and then running with lli. The following worked for me on my Linux machine: llvm-gcc -c -emit-llvm test.c lli test.o -- John T. > The output of the IR looks like this. Can some of the information tell me about why the program is not running. > > ; ModuleID = 'Hel.c' > target datalayout = "e-p:32:32" > target endian = little > target pointersize = 32 > target triple = "i686-pc-linux-gnu" > %str = internal constant [10 x sbyte] c"Hey there\00" ; <[10 x sbyte]*> [#uses=1] > > implementation ; Functions: > > int %main() { > entry: > %retval = alloca int, align 4 ; [#uses=2] > %tmp = alloca int, align 4 ; [#uses=2] > > These are the lines of code I guess which will have all the information that is causing the error. > > Some enlightenment on this please. > > -- > Abhinav Karhu > MS Computer Science > Georgia Institute of Technology > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From shap at eros-os.com Mon Sep 29 14:21:23 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Mon, 29 Sep 2008 15:21:23 -0400 Subject: [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel) In-Reply-To: <001301c92266$1865e7b0$4931b710$@com> References: <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> <1222681999.29370.8.camel@vmx> <85dfcd7f0809290646m149e7db0h10de346b1b0de01a@mail.gmail.com> <001301c92266$1865e7b0$4931b710$@com> Message-ID: <1222716083.3688.34.camel@shaptop.om-md.eros-os.com> On Mon, 2008-09-29 at 15:03 -0400, Sherief N. Farouk wrote: > Why not add types with explicit endianess?... The issues with architecture dependency are far broader than byte order. LLVM in its current form is simply not intended to be machine neutral. Quite the contrary: it is heavily machine dependent! From eli.friedman at gmail.com Mon Sep 29 14:23:55 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 29 Sep 2008 12:23:55 -0700 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <3f49a9f40809291205t1f007fr613dc42390a224a2@mail.gmail.com> References: <200809291102.15392.baldrick@free.fr> <3f49a9f40809290759y41646774hd33a44ea94a7eed4@mail.gmail.com> <200809291701.24294.baldrick@free.fr> <3f49a9f40809291205t1f007fr613dc42390a224a2@mail.gmail.com> Message-ID: On Mon, Sep 29, 2008 at 12:05 PM, OvermindDL1 wrote: > On Mon, Sep 29, 2008 at 9:01 AM, Duncan Sands wrote: >> libgcc is also available for windows. > Really? What license? What restrictions? Any speed impact over the > VC runtimes? Don't know about perf, but I think the standard libgcc should just work. AFAIK, mingw-gcc uses it. -Eli From eli.friedman at gmail.com Mon Sep 29 14:28:58 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 29 Sep 2008 12:28:58 -0700 Subject: [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel) In-Reply-To: <85dfcd7f0809290646m149e7db0h10de346b1b0de01a@mail.gmail.com> References: <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> <1222681999.29370.8.camel@vmx> <85dfcd7f0809290646m149e7db0h10de346b1b0de01a@mail.gmail.com> Message-ID: On Mon, Sep 29, 2008 at 6:46 AM, Andrew Lenharth wrote: > hton and ntoh intrinsics. You can write these portably already; just store to an i32, cast the pointer to i8, read out the bytes, then reconstruct the i32. If I recall correctly, scalarrepl+instcombine should be able to eliminate the abstraction if they have target information. -Eli From andrewl at lenharth.org Mon Sep 29 15:27:53 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 29 Sep 2008 15:27:53 -0500 Subject: [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel) In-Reply-To: References: <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> <1222681999.29370.8.camel@vmx> <85dfcd7f0809290646m149e7db0h10de346b1b0de01a@mail.gmail.com> Message-ID: <85dfcd7f0809291327v52f3658bt4e890e0b71761513@mail.gmail.com> On Mon, Sep 29, 2008 at 2:28 PM, Eli Friedman wrote: > On Mon, Sep 29, 2008 at 6:46 AM, Andrew Lenharth wrote: >> hton and ntoh intrinsics. > > You can write these portably already; just store to an i32, cast the > pointer to i8, read out the bytes, then reconstruct the i32. If I > recall correctly, scalarrepl+instcombine should be able to eliminate > the abstraction if they have target information. You can write these portably, but instcombine will does not eliminate the abstraction (it should raise it to a bswap). Bug: http://llvm.org/bugs/show_bug.cgi?id=2842 Andrew From scott.llvm at h4ck3r.net Mon Sep 29 15:29:35 2008 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Mon, 29 Sep 2008 13:29:35 -0700 Subject: [LLVMdev] Integer handling In-Reply-To: <3f49a9f40809290041h6e19bc8fj446608a0bbef1273@mail.gmail.com> References: <3f49a9f40809290041h6e19bc8fj446608a0bbef1273@mail.gmail.com> Message-ID: <84decce20809291329r167a620cn95c4b700b451ce88@mail.gmail.com> On Mon, Sep 29, 2008 at 12:41 AM, OvermindDL1 wrote: > I have ended up making a rather complicated type system to handle > quite a few things, all stemming from the fact that the integer type > has no sign information (even if it did not use it, would be nice to > look at it in my code generator to so I can put out one function type > [snip] Hi, I had the same problem, but I don't have a great solution I'm afraid. If you search the archives there was a suggestion to perhaps look at the annotation intrinsics, but those weren't helpful for me. You'll also find some rationale as to why the sign information is removed: basically because it makes the backend cleaner/simpler/smaller. It's a bit unfortunate, but as far as I understand, you have to just deal with having two type systems in the front end. scott From evan.cheng at apple.com Mon Sep 29 15:54:24 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 29 Sep 2008 13:54:24 -0700 Subject: [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel) In-Reply-To: <1222716083.3688.34.camel@shaptop.om-md.eros-os.com> References: <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> <1222681999.29370.8.camel@vmx> <85dfcd7f0809290646m149e7db0h10de346b1b0de01a@mail.gmail.com> <001301c92266$1865e7b0$4931b710$@com> <1222716083.3688.34.camel@shaptop.om-md.eros-os.com> Message-ID: <297B4D29-1D66-4D7A-9453-518E37BD4A4A@apple.com> On Sep 29, 2008, at 12:21 PM, Jonathan S. Shapiro wrote: > On Mon, 2008-09-29 at 15:03 -0400, Sherief N. Farouk wrote: >> Why not add types with explicit endianess?... > > The issues with architecture dependency are far broader than byte > order. > LLVM in its current form is simply not intended to be machine neutral. > Quite the contrary: it is heavily machine dependent! That statement is inaccurate. LLVM the language itself is machine neutral. The system as a whole hasn't figured out a way to represent target dependent information in a machine neutral way. Evan > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From clattner at apple.com Mon Sep 29 16:11:46 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 29 Sep 2008 14:11:46 -0700 Subject: [LLVMdev] Integer handling In-Reply-To: <84decce20809291329r167a620cn95c4b700b451ce88@mail.gmail.com> References: <3f49a9f40809290041h6e19bc8fj446608a0bbef1273@mail.gmail.com> <84decce20809291329r167a620cn95c4b700b451ce88@mail.gmail.com> Message-ID: <271EA739-6E2E-4BD5-AD66-645BBA944187@apple.com> On Sep 29, 2008, at 1:29 PM, Scott Graham wrote: > On Mon, Sep 29, 2008 at 12:41 AM, OvermindDL1 > wrote: >> I have ended up making a rather complicated type system to handle >> quite a few things, all stemming from the fact that the integer type >> has no sign information (even if it did not use it, would be nice to >> look at it in my code generator to so I can put out one function type >> [snip] > > It's a bit unfortunate, but as far as I understand, you have to just > deal with having two type systems in the front end. Yes, the answer is to have your own type system in your front-end. We designed the LLVM IR to be optimizable, not to let you avoid defining a type system :) -Chris From sherief at mganin.com Mon Sep 29 16:12:54 2008 From: sherief at mganin.com (Sherief N. Farouk) Date: Mon, 29 Sep 2008 17:12:54 -0400 Subject: [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel) In-Reply-To: <1222716083.3688.34.camel@shaptop.om-md.eros-os.com> References: <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> <1222681999.29370.8.camel@vmx> <85dfcd7f0809290646m149e7db0h10de346b1b0de01a@mail.gmail.com> <001301c92266$1865e7b0$4931b710$@com> <1222716083.3688.34.camel@shaptop.om-md.eros-os.com> Message-ID: <001a01c92278$26255310$726ff930$@com> > The issues with architecture dependency are far broader than byte order. > LLVM in its current form is simply not intended to be machine neutral. > Quite the contrary: it is heavily machine dependent! > I wasn't suggesting this to make LLVM able to compile architecture-neutral kernels or the such. While I disagree with the machine-dependent statement, my suggestion was just proposed in response to the following: " hton and ntoh intrinsics. These are needed to allow target code to deal with endianness in a target independent way.". I just based it on how I try to write endianness-neutral code in C++ even when dealing with endian-dependent binary formats. - Sherief From clattner at apple.com Mon Sep 29 16:19:09 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 29 Sep 2008 14:19:09 -0700 Subject: [LLVMdev] Architecture Dependency of LLVM bitcode In-Reply-To: References: <85dfcd7f0809271603gc5a678bx5129a45dfb9943f5@mail.gmail.com> <85dfcd7f0809271943k74a9d81fybbe254ba635b0179@mail.gmail.com> <4aca3dc20809272320n6554f63v8acbe0efbd26bef1@mail.gmail.com> <48E0A370.9070208@exactcode.de> <1222681999.29370.8.camel@vmx> Message-ID: <96F20988-5CAD-4483-9431-FB12A1BBC427@apple.com> On Sep 29, 2008, at 6:18 AM, Christian Plessl wrote: > On 29.09.2008, at 11:53, Jonathan S. Shapiro wrote: >> Watching this thread, it occurs to me that the "V" in "LLVM" is >> creating >> confusion. So far as I know, LLVM is the first project to use >> "virtual" >> to refer to the instruction set of the intermediate form. I >> understand >> why this labeling made sense (sort of), but it was unfortunate. The >> machine is abstract, not virtual, and the use of "virtual" here is so >> out of keeping with any other use of the term that it really does >> generate confusion. > > The topic whether LLVM bitcode is independent of the target platform > was raised several times on the mailing list, Wow, there is a lot of FUD and misinformation on this thread. > but it was never > discussed in detail. I would appreciate learning more about the > following questions: > > - Is the architecture dependence of LLVM IR only an artifact of llvm- > gcc producing architecture dependent results? No, it inherent to any C compiler. The preprocessor introduces target specific details and things just go downhill from there: http://llvm.org/docs/tutorial/LangImpl8.html#targetindep If you start from a target-independent *language*, you can generate target independent LLVM IR. > - What architecture-specific features are present in the IR that > prevent running the same LLVM bitcode on different architectures? Many things are target independent, but the most significant is that LLVM allows unrestricted pointer casting. An example that allows the programmer to "see" the underlying endianness of the target is C code like this: int X = ... char C = *(char*)&X A language that is target independent (java, perl, ...) would not allow the programmer to express such things. >> Is this worth a FAQ entry? > > I would definitely appreciate such a FAQ entry. Patches welcome :) -Chris From clattner at apple.com Mon Sep 29 16:20:00 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 29 Sep 2008 14:20:00 -0700 Subject: [LLVMdev] Going from argument to register and back In-Reply-To: <5BA674C5FF7B384A92C2C95D8CC71E1C12E599@ssanexmb1.amd.com> References: <5BA674C5FF7B384A92C2C95D8CC71E1C12E1C4@ssanexmb1.amd.com> <5BA674C5FF7B384A92C2C95D8CC71E1C12E599@ssanexmb1.amd.com> Message-ID: <4F71B8EE-B51D-4AFA-9E3C-033D18110F6B@apple.com> On Sep 29, 2008, at 9:10 AM, Villmow, Micah wrote: > One of the requirements for the backend that I am targeting is > certain meta-data needs to be returned to the runtime. This includes > the mapping between parameters and the locations this data is > expected to be stored at. This is mainly because there are multiple > address spaces and each one is mapped differently but all are > assigned registers from the same register class. So this mapping > needs to be known at compile time and passed in the generated code > to the runtime to be processed before execution. The typical solution to this is to have a one "load" instruction for each address space. The load for address space #17 knows that it is for that addr space. Instruction selection handles its generation, and the asmprinter hook can print whatever metadata you want. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080929/3486cec4/attachment-0001.html From overminddl1 at gmail.com Mon Sep 29 16:48:30 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 29 Sep 2008 15:48:30 -0600 Subject: [LLVMdev] Integer handling In-Reply-To: <271EA739-6E2E-4BD5-AD66-645BBA944187@apple.com> References: <3f49a9f40809290041h6e19bc8fj446608a0bbef1273@mail.gmail.com> <84decce20809291329r167a620cn95c4b700b451ce88@mail.gmail.com> <271EA739-6E2E-4BD5-AD66-645BBA944187@apple.com> Message-ID: <3f49a9f40809291448q140929fek9084a2b06c91d63e@mail.gmail.com> I know why it was removed, and it does make sense, just would be nice if there was an option to be able to get two pointer to a specific llvm::IntegerType, functionally they would be identical, but for user code (hence, my code) would be useful as I could match it for the different ones at generate different code for each. With some discussion with others I think we came up with an acceptable method (which allows me to completely kill my type duplication system, thank god). I am going to go down the area of Java/Python/Lua/whatever_else and just have normal operators (/, shifts, etc...) act as if the integers are signed. But there will also be named ops (udiv/sdiv) which can be used in place of a symbol op (such as /) to be explicit for those who really need unsigned usage. I plan for the operators to actually all be named (so instead of + someone could put add instead for example), and am just allowing the symbol ones to allow it to be easier to pick up for non-such-low-level-programmers. I think it is a decent enough compromise (and it was not entirely my idea, I like the back-end ugly coding, not front-end pretty syntax :) ). The main issue I was having with my type system was not that is was hard (I think it is actually well designed and powerful), it just caused me to have to write 'wrappers' around near everything in llvm, from functions and blocks to expressions and all, it literally just started snowballing, and since I am programming by myself, I need something a little more efficient in this case... Either way, what do you think of the above style for handling integers now, think it will work? See any major issues with it? You think people would have trouble using that style? From heguojin at ict.ac.cn Mon Sep 29 16:52:41 2008 From: heguojin at ict.ac.cn (ORC_developer) Date: Mon, 29 Sep 2008 16:52:41 -0500 Subject: [LLVMdev] Can I use x-86 front end to generate .bc file for another architecture Message-ID: <001501c9227d$b3aaa050$1affe0f0$@ac.cn> Hi. I successfully build llvm backend2.3 for sparc/solaris, but failed to build LLVM front end of Sparc/Solaris. I'm wondering if there is any option I can use with X-86 version of llvm-gcc front end to generate .bc file for sparc backend. Suppose I have the include files. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080929/c471d45a/attachment.html From clattner at apple.com Mon Sep 29 16:58:07 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 29 Sep 2008 14:58:07 -0700 Subject: [LLVMdev] Can I use x-86 front end to generate .bc file for another architecture In-Reply-To: <001501c9227d$b3aaa050$1affe0f0$@ac.cn> References: <001501c9227d$b3aaa050$1affe0f0$@ac.cn> Message-ID: On Sep 29, 2008, at 2:52 PM, ORC_developer wrote: > Hi. > I successfully build llvm backend2.3 for sparc/solaris, but failed > to build LLVM front end of Sparc/Solaris. > > I?m wondering if there is any option I can use with X-86 version of > llvm-gcc front end to generate .bc file for sparc backend. Suppose > I have the include files. > Sure you can, but the code won't work in general. See the other thread about arch portability and also: http://llvm.org/docs/tutorial/LangImpl8.html#targetindep -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080929/ceefa36a/attachment.html From heguojin at ict.ac.cn Mon Sep 29 17:07:17 2008 From: heguojin at ict.ac.cn (ORC_developer) Date: Mon, 29 Sep 2008 17:07:17 -0500 Subject: [LLVMdev] Can I use x-86 front end to generate .bc file for another architecture In-Reply-To: References: <001501c9227d$b3aaa050$1affe0f0$@ac.cn> Message-ID: <002601c9227f$bde9b1d0$39bd1570$@ac.cn> What's the option of llvm-gcc to use then? Is it just to specify -I or -B like gcc does? From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Monday, September 29, 2008 4:58 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Can I use x-86 front end to generate .bc file for another architecture On Sep 29, 2008, at 2:52 PM, ORC_developer wrote: Hi. I successfully build llvm backend2.3 for sparc/solaris, but failed to build LLVM front end of Sparc/Solaris. I'm wondering if there is any option I can use with X-86 version of llvm-gcc front end to generate .bc file for sparc backend. Suppose I have the include files. Sure you can, but the code won't work in general. See the other thread about arch portability and also: http://llvm.org/docs/tutorial/LangImpl8.html#targetindep -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080929/2c7255fd/attachment.html From mrs at apple.com Mon Sep 29 19:25:32 2008 From: mrs at apple.com (Mike Stump) Date: Mon, 29 Sep 2008 17:25:32 -0700 Subject: [LLVMdev] Cannot Select ConstantFP on x86 In-Reply-To: <200809291121.58465.dag@cray.com> References: <200809241911.07519.dag@cray.com> <200809261043.01095.dag@cray.com> <57186AB8-6E85-4A23-888A-02F0126FEC1D@apple.com> <200809291121.58465.dag@cray.com> Message-ID: <73F62543-623C-4BE9-937A-99D3DD63FFEA@apple.com> On Sep 29, 2008, at 9:21 AM, David Greene wrote: >> Usually, proprietary testcases can be reduced and simplified to the >> point where they are innocuous, > > Yep, that's what I'm trying to do. Have you run delta? From mrs at apple.com Mon Sep 29 19:30:53 2008 From: mrs at apple.com (Mike Stump) Date: Mon, 29 Sep 2008 17:30:53 -0700 Subject: [LLVMdev] Hi Cache Miss and Branch Misprediction In-Reply-To: <608144716.260291222652585272.JavaMail.root@pinky.cc.gatech.edu> References: <608144716.260291222652585272.JavaMail.root@pinky.cc.gatech.edu> Message-ID: <208806C2-0AD2-4B12-9701-AE46DC423B9A@apple.com> On Sep 28, 2008, at 6:43 PM, Ketan Pundlik Umare wrote: > I am an absolute newbie to the compiler community. I am > experimenting a little bit with llvm. > I have a few small questions, i would be really great if someone > could help me. > > 1. Can i find out (is there something already built), if the > previous instruction / or some instruction was a cache miss. > Basically i want to detect cache misses and instructions that are > causing this Well, you could time it, though, doing that alters the code of course. Small time, in cache, bigger time, in farther away cache, bigger time, in dram, bigger time, page fault. No one in the real world does this. Instead the use tools like Shark or vtune. You can say, show me all the instructions that missed cache and how often they missed. > 2. Can i find if there was a branch misprediction? Likewise. Though, I'm trying to recall if mispredictions where one of the things one could watch for on x86. google around for performance counters on x86. > 3. Can i find if a branch was taken or not taken? :-) gcov will tell you this today. From mrs at apple.com Mon Sep 29 19:37:51 2008 From: mrs at apple.com (Mike Stump) Date: Mon, 29 Sep 2008 17:37:51 -0700 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: <1222679595.18981.27.camel@vmx> References: <200809261000.54992.baldrick@free.fr> <48DD9B6E.3070702@gmail.com> <200809290950.54254.baldrick@free.fr> <1222679595.18981.27.camel@vmx> Message-ID: On Sep 29, 2008, at 2:13 AM, Jonathan S. Shapiro wrote: > On Mon, 2008-09-29 at 09:50 +0200, Duncan Sands wrote: >> For the moment, yes. If unwind gets implemented one day (I have a >> plan, >> but no time right now), the implementation is sure to call routines >> in >> the gcc runtime. > > As a transient solution that makes sense, but it seems desirable to > have > a generalized unwind scheme that is not tied to libgcc. Ok, but, realize that in order to be platform abi compatible with gcc/g ++, one _must_ do certain things. If you had a totally different scheme that didn't interoperate with gcc/g++, then, you break the platform abi. If one can throw out such compatibility, then, well, it just doesn't matter. From shap at eros-os.com Mon Sep 29 20:22:06 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Mon, 29 Sep 2008 21:22:06 -0400 Subject: [LLVMdev] Unwinds Gone Wild In-Reply-To: References: <200809261000.54992.baldrick@free.fr> <48DD9B6E.3070702@gmail.com> <200809290950.54254.baldrick@free.fr> <1222679595.18981.27.camel@vmx> Message-ID: <1222737726.27467.1.camel@vmx> On Mon, 2008-09-29 at 17:37 -0700, Mike Stump wrote: > Ok, but, realize that in order to be platform abi compatible with gcc/g > ++, one _must_ do certain things. If you had a totally different > scheme that didn't interoperate with gcc/g++, then, you break the > platform abi. If one can throw out such compatibility, then, well, it > just doesn't matter. Yep. Since I'm going to need to deal with this charming ball of barbed wire in the BitC documentation, are there any good pointers toward things I need to get my head around concerning libunwind? shap From nicholas at mxc.ca Mon Sep 29 21:17:26 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Mon, 29 Sep 2008 19:17:26 -0700 Subject: [LLVMdev] Problem running program with LLVM JIT In-Reply-To: <1674617516.3630461222714673502.JavaMail.root@mail7.gatech.edu> References: <1674617516.3630461222714673502.JavaMail.root@mail7.gatech.edu> Message-ID: <48E18C36.10006@mxc.ca> Karhu, Abhinav R wrote: > The output of the IR looks like this. Can some of the information tell me about why the program is not running. > > ; ModuleID = 'Hel.c' > target datalayout = "e-p:32:32" > target endian = little > target pointersize = 32 > target triple = "i686-pc-linux-gnu" > %str = internal constant [10 x sbyte] c"Hey there\00" ; <[10 x sbyte]*> [#uses=1] > > implementation ; Functions: > > int %main() { > entry: > %retval = alloca int, align 4 ; [#uses=2] > %tmp = alloca int, align 4 ; [#uses=2] > > These are the lines of code I guess which will have all the information that is causing the error. Whoa, that syntax is ancient. This is pre-2.0 syntax, at least. Make sure you don't have mixed versions of LLVM or LLVM-GCC installed. Nick From overminddl1 at gmail.com Mon Sep 29 21:17:41 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 29 Sep 2008 20:17:41 -0600 Subject: [LLVMdev] Hi Cache Miss and Branch Misprediction In-Reply-To: <208806C2-0AD2-4B12-9701-AE46DC423B9A@apple.com> References: <608144716.260291222652585272.JavaMail.root@pinky.cc.gatech.edu> <208806C2-0AD2-4B12-9701-AE46DC423B9A@apple.com> Message-ID: <3f49a9f40809291917m60c5495dte863124c47f2488c@mail.gmail.com> On Mon, Sep 29, 2008 at 6:30 PM, Mike Stump wrote: > /* snip */ AMD's CodeAnalyst is free and quite wonderful at this job. Shows details about just about anything the CPU reports (and on newer AMD CPU's there is an even more ridiculous amount of information) about every little function call, time they took, multiple profiling modes, etc... From mattgiuca at gmail.com Mon Sep 29 21:49:46 2008 From: mattgiuca at gmail.com (Matt Giuca) Date: Mon, 29 Sep 2008 19:49:46 -0700 (PDT) Subject: [LLVMdev] Integer handling In-Reply-To: <3f49a9f40809291448q140929fek9084a2b06c91d63e@mail.gmail.com> References: <3f49a9f40809290041h6e19bc8fj446608a0bbef1273@mail.gmail.com> <84decce20809291329r167a620cn95c4b700b451ce88@mail.gmail.com> <271EA739-6E2E-4BD5-AD66-645BBA944187@apple.com> <3f49a9f40809291448q140929fek9084a2b06c91d63e@mail.gmail.com> Message-ID: <19735288.post@talk.nabble.com> OvermindDL1 wrote: > > I know why it was removed, and it does make sense, just would be nice > if there was an option to be able to get two pointer to a specific > llvm::IntegerType, functionally they would be identical, but for user > code (hence, my code) would be useful as I could match it for the > different ones at generate different code for each. > Well a language doesn't need to know whether an int is signed or unsigned if all the operators are aware of the sign of its operands. Such is the case with most assembly languages, and now LLVM. It makes the assembly cleaner (because types are used only for checking, not for overloading operations). And it seems you're going this way with your language (based on what you said in the most recent post). The thing is that high level languages really should encode signed/unsigned into the type system (or simply deal only with signed integers, as many languages do). You don't want your human programmers having to worry about the signedness of an int each time they do anything with it. OvermindDL1 wrote: > > With some discussion with others I think we came up with an acceptable > method (which allows me to completely kill my type duplication system, > thank god). > *snip* > Either way, what do you think of the above style for handling integers > now, think it will work? See any major issues with it? You think > people would have trouble using that style? > Well it will certainly w