From romixlev at yahoo.com Fri Feb 1 02:05:50 2008 From: romixlev at yahoo.com (Roman Levenstein) Date: Fri, 1 Feb 2008 09:05:50 +0100 (CET) Subject: [LLVMdev] Some questions about live intervals In-Reply-To: Message-ID: <324787.86409.qm@web56310.mail.re3.yahoo.com> Hi Fernando, > Hi, Roman, > > we have an implementation of an allocator for LLVM that, like > Sarkar's, allows to split live ranges at any program point. You can > find > its description here: > > http://compilers.cs.ucla.edu/fernando/publications/drafts/long_PereiraPalsberg07.pdf > I've read your paper already. It is a very interesting approach! But my impression was that it is rather complex solution and requires quite some bits of implementation. I also looked at your sources. Looks like they introduce a lot of new code into LLVM. IMHO, one of the attractive parts of Sarkar's algorithm is its simplicity. It almost does not require any significant changes in the LLVM code-base and is also conceptually a bit simpler. > we have an implementation of an allocator for LLVM that, like > Sarkar's, allows to split live ranges at any program point. Actually, Sarkar's algorithm can split only at block boundaries, as far as I understand. This can be an obstacle for very long basic blocks. One of the interesting ideas could be to introduce live-range splitting into his algorithm. BTW, since I was also working on Wimmer's linear scan algorithm (which is sort of implemented, works on simple test-cases and requires a lot of code clean-up and refactoring), I also have the LiveInterval splitting code in place and it can be done at any program point. > We have the code implemented in LLVM 2.1, and it passes all the tests > that I have tried. Cool! I'm not that far yet :-( > If you need help testing and debugging your allocator, I can > help you. Thank you very much for offering this. I'll most likely come back to you, once I'm that far. > We have a debugger that was very useful when trying to find errors in > our implementation. I've seen references to it on your page. But this debugger is in Java, or? So, one has to dump the results of register allocation and input problem and it would do some checks, or? > Also, to implement Sarkar's ELS, you will need to > swap live ranges at the boundaries of basic blocks. This is a little > tricky once you have registers of different size, and I can help you > with it. Actually, I already implemented something very similar for Wimmer's linear scan. The main issue was to order the copies in the right way and to introduce stores/loads to handle circular dependencies. Or do you say that register classes of different sizes introduce additional problems? Thanks, Roman Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go From fernando at CS.UCLA.EDU Fri Feb 1 02:19:12 2008 From: fernando at CS.UCLA.EDU (Fernando Magno Quintao Pereira) Date: Fri, 1 Feb 2008 00:19:12 -0800 (PST) Subject: [LLVMdev] Some questions about live intervals In-Reply-To: <324787.86409.qm@web56310.mail.re3.yahoo.com> References: <324787.86409.qm@web56310.mail.re3.yahoo.com> Message-ID: > Actually, Sarkar's algorithm can split only at block boundaries, as far > as I understand. This can be an obstacle for very long basic blocks. > One of the interesting ideas could be to introduce live-range splitting > into his algorithm. As far as I understand it, it can also split in the interior of basic blocks, because of pre-colored registers, otherwise it would not be optimal. > I've seen references to it on your page. But this debugger is in Java, > or? So, one has to dump the results of register allocation and input > problem and it would do some checks, or? It is implemented in Java. You must dump some output and run the debugger on this output. > Actually, I already implemented something very similar for Wimmer's > linear scan. The main issue was to order the copies in the right way > and to introduce stores/loads to handle circular dependencies. Or do > you say that register classes of different sizes introduce additional > problems? Well, it makes it a little bit more complicated, but only a little bit. A problem that I had was when the lower and higher bits of registers were swapped. For instance, when implementing the parallel copy: BH <= AL || AX <= BX you will need two swaps (or three copies), instead of only one swap if there were no aliasing. best, Fernando From nicolas.geoffray at lip6.fr Fri Feb 1 03:24:35 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Fri, 01 Feb 2008 10:24:35 +0100 Subject: [LLVMdev] Exception handling in JIT In-Reply-To: <393ABC27-9C1A-4B51-84EB-6F842BA37FA1@apple.com> References: <475D7CC0.9010605@lip6.fr> <27026429-F8CF-41B0-86CF-A487EA14890C@apple.com> <475FCB4B.4090304@lip6.fr> <393ABC27-9C1A-4B51-84EB-6F842BA37FA1@apple.com> Message-ID: <47A2E553.8020501@lip6.fr> Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080201/38ce7f01/attachment-0001.pl From romixlev at yahoo.com Fri Feb 1 10:31:52 2008 From: romixlev at yahoo.com (Roman Levenstein) Date: Fri, 1 Feb 2008 17:31:52 +0100 (CET) Subject: [LLVMdev] Some questions about live intervals In-Reply-To: Message-ID: <205883.89954.qm@web56304.mail.re3.yahoo.com> > > Actually, Sarkar's algorithm can split only at block boundaries, as > far as I understand. This can be an obstacle for very long basic > blocks. > > One of the interesting ideas could be to introduce live-range > splitting into his algorithm. > > As far as I understand it, it can also split in the interior of basic > blocks, because of pre-colored registers, otherwise it would not be > optimal. Well, I cannot find anything about in my copy of the paper. The paper neither talk about splitting in the interior of basicc blocks, nor about handling of pre-colored registers. And Sarkar also does not claim the optimality of the algorithm. He claims that it is inherently more scalable and efficient, i.e. linear as compared to O(n^2) for Graph coloring. But of course this is required and I'm going to extend the algorithm to support it by doing splitting before pre-colored uses. BTW, there are some other missing features in the Sarkar's algorithm. For example, it spills only whole intervals, which is very similar to typical GC regallocs, but not very efficient. I think, some of the known methods for live-range splitting around high-pressure regions in GC world, can be also applied here. This should improve the quality of allocation. Actually, I'm wondering if interval-splitting, handling of pre-colored registers, handling of high-pressure regions would slow down the algorithm to a very big extent or not? > > I've seen references to it on your page. But this debugger is in > Java, or? So, one has to dump the results of register allocation and > input problem and it would do some checks, or? > > It is implemented in Java. You must dump some output and run the > debugger on this output. OK. Then my understanding was correct. > > Actually, I already implemented something very similar for Wimmer's > > linear scan. The main issue was to order the copies in the right > way and to introduce stores/loads to handle circular dependencies. Or > do you say that register classes of different sizes introduce > additional problems? > > Well, it makes it a little bit more complicated, but only a little > bit. A problem that I had was when the lower and higher bits of > registers were swapped. Oh, now I see. My version of Wimmer's algorithm was written before LLVM introduced support for sub-regs. Therefore I didn't have this problem ;-) But now I have to cope with it. Anyway, I think it is a minor extension. I guess, I should just take aliasing information into account when ordering register moves. -Roman Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie?s mit dem neuen Yahoo! Mail. www.yahoo.de/mail From Alireza.Moshtaghi at microchip.com Fri Feb 1 11:28:26 2008 From: Alireza.Moshtaghi at microchip.com (Alireza.Moshtaghi at microchip.com) Date: Fri, 1 Feb 2008 10:28:26 -0700 Subject: [LLVMdev] C embedded extensions and LLVM In-Reply-To: <9A4DD193-F800-470C-B453-816114933F14@gmail.com> References: <81191030-97C7-4C88-886B-97B2FEF2F526@gmail.com><2599E358-427A-419A-9F60-88F535FA12F7@nondot.org><35B66ACF-FF27-4614-91EC-ADABD9002A1B@gmail.com> <9A4DD193-F800-470C-B453-816114933F14@gmail.com> Message-ID: Christopher, Thank you for all the work :-) Regarding the regression testing, it is in our plan to contribute into LLVM. The current state of our project is not in the form that we can do this at this time though, but I'm hoping that we can get some minimal functionality into LLVM before LLVM 2.3 (at most LLVM 2.4) release. Looks like you have also (at least on your local project) taken care of the front-end. We are currently working on normal address space, but probably in the next month we will start working on the support for rom access. So the front-end modifications are not necessary right away but it'd be nice to have them before that time. In the mean time, I will take a look and try to understand your modifications, and I'm sure that I'll be back with some questions. Regards A. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Christopher Lamb Sent: Wednesday, January 30, 2008 10:59 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] C embedded extensions and LLVM Alireza, I have added full support for embedded C address spaces to the LLVM IR (see http://llvm.org/docs/LangRef.html#t_pointer). I have not added any support for the fractional types and their operators, though I think this would simply require adding the necessary intrinsics, which is one of the easier things to add to LLVM. Given that LLVM takes the approach of modeling these kinds of type differences as differing operations rather than different types in it's type system it should be fairly straight forward to add them if needed. As far as front-end support goes, I do have changes to my local clang tree which add attributes for address spaces which have been working for my purposes. However since my initial work my free time has become more scarce and I haven't had the opportunity to clean up the patches and submit them back to the tree. The lack of a public back end with which to consume the generated IR with embedded C extensions and validate the front end is also a problem. Without such a platform it will be difficult for the LLVM project to guarantee that the functionality stays working going forward. Do you mind sharing more details about your project, particularly how soon you need the front end support and if you would be able to provide a way (ideally contributed back to LLVM) to regress these features going forward? -- Christopher Lamb On Jan 30, 2008, at 9:53 AM, wrote: Thank you Chris, That is great news... So his modifications are in llvm-2.2? How has Christopher tested them? Are there attributes or intrinsics that I can also use? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, January 29, 2008 9:23 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] C embedded extensions and LLVM On Jan 29, 2008, at 9:56 AM, References: <95030.63606.qm@web56309.mail.re3.yahoo.com> Message-ID: <39292179-AC6F-4D45-940B-00231DCF40DE@apple.com> On Jan 31, 2008, at 5:05 AM, Roman Levenstein wrote: > Hi, > > I'm trying to sketch an LLVM-based implementation of the Extended > Linear Scan algorithm, described in this Vivek Sarkar's paper: > http://www.cs.rice.edu/~vs3/PDF/cc2007.pdf > Sarkar reports that this version of Linear Scan produces better code > than graph-coloring regallocs and is also much faster (15x to 68x). > > I already started work on the implementation of this algorithm and > have > a few hopefully rather simple questions: > > 1) What is the easiest way to understand which MBB a given instruction > index belongs to? All the required information is available in the > MBB2IdxMap of the LiveIntervalAnalysis class. Would it be useful to > add > a small function getMBBFromIndex() to this class? Sure there is a reverse map (actually just a vector) Idx2MBBMap. Just add a query. > > > 2) Is there any simple way to iterate over all instructions, where a > given live interval is live? This functionality is required by many > register allocation algorithms. I think having some special iterator > functions for that in the LiveIntervalAnalysis class could be very > useful for this purpose. And implementation should be fairly > straightforward by using the information about the beginning and end > points of live ranges. Well yes, See addIntervalForSpills. Iterating through the liveranges, then for each liverange iterate through every instruction index. It's not very inefficient though. > > > 3) This question is related to the previous one. For computation of > spill costs by some register allocation algorithms, it is required to > iterate over all uses/defs of a given live interval between two points > of execution A and B. Does LLVM already maintain such a def/use list > at > the MachineInstr level? Or should I really inspect each instruction? MachineRegisterInfo now contains the use / def information. The register allocator passes have not been changed to make use of them yet. > > > 4) What would be the easiest and the most efficient way to get the set > of live intervals that are live at a given point of execution P, i.e. > at instruction with number P? Of course, one could do one linear scan > of all intervals and remember for each point P the set of live > intervals. But this solution may require a lot of memory in case of > very big functions. May be there are some better/faster possibilities > available? There isn't an efficient way right now. I think you can keep some sort of interference graph to help with this? Perhaps you can use class RegallocQuery in RegisterCoalescer.h for this? David would know since he contributed this. > > > As for (1) and (2), I could implement and provide patches for it, if > you think this is desirable. Yes, thanks. Evan > > > Thanks, > Roman > > > > Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. > www.yahoo.de/go > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From bmayne at 21technologies.com Fri Feb 1 14:03:13 2008 From: bmayne at 21technologies.com (Ben Mayne) Date: Fri, 1 Feb 2008 14:03:13 -0600 Subject: [LLVMdev] Code Extractor Issue Message-ID: <54D41E91F26CF6488C7088C89D9160F8317DA3@21ctexg01.21technologies.com> I'm having an issue with the CodeExtractor. When I try to extract the lone basic block from the following function, I get an assertion error. define i32 @test(i32 %x) { %tmp = call i32 @test3( i32 %x ) ; [#uses=1] ret i32 %tmp } The assertion error is: lli: Dominators.cpp:71: void llvm::DominatorTree::splitBlock(llvm::BasicBlock*): Assertion `NewBB->getTerminator()->getNumSuccessors() == 1 && "NewBB should have a single successor!"' failed. lli((anonymous namespace)::PrintStackTrace()+0x22)[0x87f7cb8] lli((anonymous namespace)::SignalHandler(int)+0x110)[0x87f7f7c] /lib/tls/libc.so.6[0x59fa48] /lib/tls/libc.so.6(abort+0x129)[0x5a1319] /lib/tls/libc.so.6(__assert_fail+0x101)[0x598f41] lli(llvm::DominatorTree::splitBlock(llvm::BasicBlock*)+0xb7)[0x874edff] lli[0x86b2672] lli[0x86b2b15] lli(llvm::ExtractCodeRegion(llvm::DominatorTree&, std::vector > const&, bool)+0x39)[0x86b321d] I just updated to llvm-2.1 from llvm-1.9 where I was never having this problem. I don't understand exactly what it's complaining about (maybe the fact that the terminator instruction is a 'ret' instruction?, but I don't see why it couldn't handle this kind of a block). Thanks, Ben Mayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080201/e4b0e519/attachment.html From dag at cray.com Fri Feb 1 15:38:10 2008 From: dag at cray.com (David Greene) Date: Fri, 1 Feb 2008 15:38:10 -0600 Subject: [LLVMdev] Some questions about live intervals In-Reply-To: <39292179-AC6F-4D45-940B-00231DCF40DE@apple.com> References: <95030.63606.qm@web56309.mail.re3.yahoo.com> <39292179-AC6F-4D45-940B-00231DCF40DE@apple.com> Message-ID: <200802011538.10191.dag@cray.com> On Friday 01 February 2008 13:54, Evan Cheng wrote: > There isn't an efficient way right now. I think you can keep some sort > of interference graph to help with this? Perhaps you can use class > RegallocQuery in RegisterCoalescer.h for this? David would know since > he contributed this. RegallocQuery is just an abstract interface class. The intent is for it to be the gateway through which queries to the register allocator are sent. One such query is whether two intervals interfere. The "guts" of the computation is up to some other piece of code, however. A naive implementation might return intA.overlaps(intB), for the interference query, for example. I hadn't thought about a query to return the set of intervals live at a particular point, but that's a good idea. I actually have a number of changes to this interface queued up waiting for upstream submittal. Some of the changes could be contraversial, though, so it might take a bit of iteration to make it happen. It's also tied in with some major coalescing refactoring that I did to allow more code shaing. I also want to get that submitted upstream but it's a huge patch and will take a while to get processed. The bottom line is that RegallocQuery doesn't do any computation on its own. It's only purpose is to allow the register allocator to be decoupled from the rest of the compiler internals. -Dave From ofv at wanadoo.es Fri Feb 1 14:53:29 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Fri, 01 Feb 2008 21:53:29 +0100 Subject: [LLVMdev] Making dll's on MinGW. Message-ID: As the LLVM build does not create dll's on Windows, two problems arises: 1. Static linking creates big executables. 2. Link time is long. We can create dll's on MinGW using a feature of binutils that mimics .so files on GNU/Linux. The process is very simple. On a MSYS or Cygwin shell (make sure MinGW binaries are on the path before Cygwin's). Read all message before rolling up your sleeves. I'm using LLVM 2.1, g++ 4.2.1-dw2 (mingw32-2), ld 2.18.50.20080109. 1. Go to the /lib directory of your LLVM install. 2. Make a subdirectory there. Let's call it `temp'. 3. Copy to `temp' all LLVM object files that you need on your project (LLVMX86.o, LLVMExecutionEngine.o and LLVMJIT.o for me). 4. cd to `temp'. 5. Execute this: for f in ../lib*.a ; do ar x $f ; done If you are working on the LLVM's debug install, do: rm Debugger.o ProgramInfo.o RuntimeInfo.o SourceFile.o SourceLanguage*.o 6. Then: g++ -shared --export-all-symbols -o LLVM.dll *.o -lpsapi -ldbghelp This may require several minutes and use approx. 0.5 GB. If you are working on LLVM's debug install, it is a good idea to name the dll LLVMd.dll or something to differentiate it from the release build. 7. This creates LLVM.dll. Move it to LLVM's /lib directory. Put a copy somewhere on your PATH. 8. On your application's makefile, remove all references to files on LLVM's /lib directory (libraries, LLVMX86.o, etc) and just use -lLLVM. This way we have a single big dll that we use just like an .so file on GNU/Linux. Link times decreases dramatically (using the debug build, link time decreases to ~10%). Caveats: For some reason, while doing this process for the debug intall of LLVM, the creation of the dll fails with this: d:/dev/lib/llvm-2.1-d/lib/m $ g++ -shared --export-all-symbols -o LLVMd.dll *.o -lpsapi -ldbghelp ProgramInfo.o: In function `~SourceFileInfo': d:/dev/lib/llvm-2.1/lib/Debugger/ProgramInfo.cpp:123: multiple definition of `llvm::SourceFileInfo::~SourceFileInfo()' MachineModuleInfo.o:d:/dev/lib/llvm-2.1/include/llvm/CodeGen/MachineModuleInfo.h:865: first defined here collect2: ld returned 1 exit status This is "fixed" by ignoring libLLVMDebugger.a or its contents on step 5, as indicated. SourceFileInfo does not declare a destructor, but one is defined in ProgramInfo.cpp. I don't know wath is going here. It would be good to create dll's "the Windows way", which works for VC++ too, but this requires modification of the source code. I expect to address this on a future message. HTH. -- Oscar From vadve at uiuc.edu Fri Feb 1 20:09:55 2008 From: vadve at uiuc.edu (Vikram S.Adve) Date: Fri, 1 Feb 2008 20:09:55 -0600 Subject: [LLVMdev] Fwd: [LLVMbugs] [Bug 1971] New: EQUIVALENCE not supported in llvm-gfortran Message-ID: Anton, I didn't know that EQUIVALENCE is the only unsupported major Fortran feature, as this bug says. Can you give me an update on the status of the Fortran front-end and what the near-term goals are? I am getting more requests from academics doing HPC compilers and it would be useful to know where Fortran support stands. Other llvmdev'ers may be interested too. Thanks, --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org/ Begin forwarded message: > From: "bugzilla-daemon at cs.uiuc.edu" > Date: February 1, 2008 5:08:12 AM CST > To: "llvmbugs at cs.uiuc.edu" > Subject: [LLVMbugs] [Bug 1971] New: EQUIVALENCE not supported in > llvm-gfortran > > http://llvm.org/bugs/show_bug.cgi?id=1971 > > Summary: EQUIVALENCE not supported in llvm-gfortran > Product: tools > Version: trunk > Platform: PC > OS/Version: Linux > Status: NEW > Severity: enhancement > Priority: P2 > Component: llvm-gcc > AssignedTo: unassignedbugs at nondot.org > ReportedBy: asl at math.spbu.ru > CC: llvmbugs at cs.uiuc.edu > > > Created an attachment (id=1365) > --> (http://llvm.org/bugs/attachment.cgi?id=1365) > Testcase > > Current gimple=>LLVM IR lowering does not support handling of fortran > EQUIVALENCE blocks. This looks like the last 'lack of feature' bug > know so far. > > Testcase from polyhedron attached. > > > -- > Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. > _______________________________________________ > LLVMbugs mailing list > LLVMbugs at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs > --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/20080201/10c14177/attachment-0001.html From scottm at rushg.aero.org Fri Feb 1 20:52:07 2008 From: scottm at rushg.aero.org (Scott Michel) Date: Fri, 01 Feb 2008 18:52:07 -0800 Subject: [LLVMdev] no build, no joy In-Reply-To: <038EF8B5-6624-4A20-8419-48C15AD08DB8@apple.com> References: <038EF8B5-6624-4A20-8419-48C15AD08DB8@apple.com> Message-ID: <47A3DAD7.90608@rush.aero.org> Mike Stump wrote: > On Jan 30, 2008, at 2:10 PM, Mike Stump wrote: > >>/Volumes/mrs5/net/llvm/llvm-build/lib/Target/CellSPU/ >>SPUGenDAGISel.inc: In member function ?llvm::SDNode* >>SPUDAGToDAGISel::Emit_5(const llvm::SDOperand&, unsigned int, unsigned >>int, llvm::MVT::ValueType, llvm::MVT::ValueType)?: > > > Merely rming the file makes it work again. Would be nice if the rules > were always incremental clean... Mike: Actually, there was a tblgen bug fix where tblgen was gratuitously renaming variables when it hadn't actually created a temporary (see bug 1951.) Tmp2 is obviously never created. Not sure why SPUGenDAGISel.inc didn't get rebuilt (it's tblgen-ed). -scooter From asl at math.spbu.ru Sat Feb 2 01:11:48 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sat, 02 Feb 2008 10:11:48 +0300 Subject: [LLVMdev] Fwd: [LLVMbugs] [Bug 1971] New: EQUIVALENCE not supported in llvm-gfortran In-Reply-To: References: Message-ID: <1201936308.10814.174.camel@asl.dorms.spbu.ru> Vikram, > I didn't know that EQUIVALENCE is the only unsupported major Fortran > feature, as this bug says. Can you give me an update on the status of > the Fortran front-end and what the near-term goals are? Ok. I was going to post something soon after 2.2 release, but let's do it now. LLVM 2.2 will contain (as a part of llvm-gcc 4.2) a port of gfortran compiler to the LLVM rails. This port is mainly for trying/testing and reporting bugs against it. Currently I'm seeing 1-2 fails in polyhedron suite. One of them is due to lack of EQUIVALENCE support. Another big missed feature is lack of 128bit codegen, but this is not a llvm-gfortran issue only. Also, it was reported, that there had been 2-3 ICEs in CFP2006, I'm going to fix them sometimes (or, at least to reduce them to the PRs). I don't have any personal goals connected with gfortran - I really just don't know the FORTRAN at all :) If there will be some questions one can surely feel free to ask them, fill PRs, etc. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From lee225 at uiuc.edu Sat Feb 2 01:51:46 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Sat, 2 Feb 2008 01:51:46 -0600 (CST) Subject: [LLVMdev] Question to Chris Message-ID: <20080202015146.BBC09843@expms2.cites.uiuc.edu> Dear Prof.Adve and Bill, I deeply appreciate your comments and concerns. (Please forgive my late response. I've tried some more cases to make this issue) As Prof.Adve mentioned, I need to explain exactly what my problem is, but I have no good ability that I can explain it in this plain text space. For this reason, I made a .pdf file and linked it as follows: https://netfiles.uiuc.edu/lee225/www/MakingLoops.pdf Would you please explain to me how I can access to this problem in a better way if you can figure out? Once again, I really appreciate your time and favor, Bill and Prof.Adve. Truly yours, Seung J. Lee ---- Original message ---- >Date: Mon, 28 Jan 2008 09:39:52 -0600 >From: "Vikram S. Adve" >Subject: Re: [LLVMdev] Question to Chris >To: LLVM Developers Mailing List > >Bill, > >Depending on what Seung's problem is, converting *out* of SSA form may >actually be the wrong thing to do. Seung needs to explain exactly >problem he is unable solve using SSA form. > >--Vikram >http://www.cs.uiuc.edu/~vadve >http://llvm.org/ > > From kchan at cs.hku.hk Sat Feb 2 03:25:38 2008 From: kchan at cs.hku.hk (=?BIG5?B?S2luc29uIENoYW4gs6+zx6tI?=) Date: Sat, 2 Feb 2008 17:25:38 +0800 Subject: [LLVMdev] Problem Compiling llvm-gcc 4.2 References: Message-ID: <379E1FAC-F236-499D-955D-5D6B47C38316@cs.hku.hk> >> Dear All, I have been trying for days but still cannot break this barrier. May I get your help? I have compiled llvm-2.1 successfully and make install. When I proceed with llvm-gcc-4.2-2.1, however, I keep getting linking error as attached. Some functions with totally different content conflict with each other in linking process. That is a Linux box (Debian, with 2.6.23-1 Kernel) and I have already tried combinations of --disable-shared and/or --disable-multilib. It get stuck at the same point. Thanks to Chris, I just realized Java is not supported but have no idea how to disable it. I have read the README.LLVM and got no clue. (Maybe my English is not good enough - I am not native speaker.) Once again, thank you all for the great work. Idea of LLVM is really attractive to forget about. Regards, Kinson --- /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/prev- gcc/xgcc -B/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- linux-gnu/prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -g - O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style- definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o jc1 \ java/parse.o java/class.o java/decl.o java/expr.o java/ constants.o java/lang.o java/typeck.o java/except.o java/verify-glue.o java/verify-impl.o java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o java/mangle_name.o java/builtins.o java/ resource.o java/jcf-write.o java/buffer.o java/check-init.o java/jcf- depend.o java/jcf-path.o java/boehm.o java/java-gimplify.o main.o libbackend.a ../libcpp/libcpp.a attribs.o stub-objc.o stub-c.o -L../ zlib -lz ../libcpp/libcpp.a ../libiberty/libiberty.a ../ libdecnumber/libdecnumber.a /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/prev- gcc/xgcc -B/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- linux-gnu/prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -g - O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style- definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o cc1obj- dummy \ objc/objc-lang.o objc/objc-act.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c- opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o c- gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o libbackend.a ../libcpp/libcpp.a ../libcpp/ libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a build/genchecksum cc1-dummy > cc1-checksum.c build/genchecksum cc1obj-dummy > cc1obj-checksum.c attribs.o: In function `decl_attributes': /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ gcc/../.././gcc/attribs.c:138: multiple definition of `decl_attributes' java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- linux-gnu/gcc/../.././gcc/java/lang.c:844: first defined here stub-objc.o: In function `objc_is_class_name': /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ gcc/../.././gcc/stub-objc.c:34: multiple definition of `objc_is_class_name' java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- linux-gnu/gcc/../.././gcc/java/lang.c:856: first defined here stub-objc.o: In function `objc_v2_component_ref_field_offset': /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ gcc/../.././gcc/stub-objc.c:474: multiple definition of `objc_v2_component_ref_field_offset' java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- linux-gnu/gcc/../.././gcc/java/lang.c:880: first defined here stub-objc.o: In function `objc_v2_bitfield_ivar_bitpos': /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ gcc/../.././gcc/stub-objc.c:480: multiple definition of `objc_v2_bitfield_ivar_bitpos' java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- linux-gnu/gcc/../.././gcc/java/lang.c:872: first defined here stub-objc.o: In function `objc_method_decl': /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ gcc/../.././gcc/stub-objc.c:494: multiple definition of `objc_method_decl' java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- linux-gnu/gcc/../.././gcc/java/lang.c:863: first defined here stub-objc.o: In function `objc_create_init_utf16_var': /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ gcc/../.././gcc/stub-objc.c:576: multiple definition of `objc_create_init_utf16_var' java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- linux-gnu/gcc/../.././gcc/java/lang.c:888: first defined here stub-objc.o: In function `objc_anonymous_local_objc_name': /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ gcc/../.././gcc/stub-objc.c:583: multiple definition of `objc_anonymous_local_objc_name' java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- linux-gnu/gcc/../.././gcc/java/lang.c:895: first defined here From resistor at mac.com Sat Feb 2 03:41:43 2008 From: resistor at mac.com (Owen Anderson) Date: Sat, 2 Feb 2008 03:41:43 -0600 Subject: [LLVMdev] Problem Compiling llvm-gcc 4.2 In-Reply-To: <379E1FAC-F236-499D-955D-5D6B47C38316@cs.hku.hk> References: <379E1FAC-F236-499D-955D-5D6B47C38316@cs.hku.hk> Message-ID: You need to pass a --enable-languages=c,c++ to the initial configure invocation. --Owen On Feb 2, 2008, at 3:25 AM, Kinson Chan ??? wrote: >>> > > Dear All, > > I have been trying for days but still cannot break this barrier. May I > get your help? > > I have compiled llvm-2.1 successfully and make install. When I proceed > with llvm-gcc-4.2-2.1, however, I keep getting linking error as > attached. Some functions with totally different content conflict with > each other in linking process. > > That is a Linux box (Debian, with 2.6.23-1 Kernel) and I have already > tried combinations of --disable-shared and/or --disable-multilib. It > get stuck at the same point. > > Thanks to Chris, I just realized Java is not supported but have no > idea how to disable it. I have read the README.LLVM and got no clue. > (Maybe my English is not good enough - I am not native speaker.) > > Once again, thank you all for the great work. Idea of LLVM is really > attractive to forget about. > > Regards, > Kinson > > --- > /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/prev- > gcc/xgcc -B/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- > linux-gnu/prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -g - > O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- > prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style- > definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o jc1 \ > java/parse.o java/class.o java/decl.o java/expr.o java/ > constants.o java/lang.o java/typeck.o java/except.o java/verify-glue.o > java/verify-impl.o java/zextract.o java/jcf-io.o java/win32-host.o > java/jcf-parse.o java/mangle.o java/mangle_name.o java/builtins.o > java/ > resource.o java/jcf-write.o java/buffer.o java/check-init.o java/jcf- > depend.o java/jcf-path.o java/boehm.o java/java-gimplify.o main.o > libbackend.a ../libcpp/libcpp.a attribs.o stub-objc.o stub-c.o -L../ > zlib -lz ../libcpp/libcpp.a ../libiberty/libiberty.a ../ > libdecnumber/libdecnumber.a > /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/prev- > gcc/xgcc -B/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- > linux-gnu/prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -g - > O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- > prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style- > definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o cc1obj- > dummy \ > objc/objc-lang.o objc/objc-act.o attribs.o c-errors.o c-lex.o > c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c- > opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o > c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o > c- > gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ > main.o libbackend.a ../libcpp/libcpp.a ../libcpp/ > libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a > build/genchecksum cc1-dummy > cc1-checksum.c > build/genchecksum cc1obj-dummy > cc1obj-checksum.c > attribs.o: In function `decl_attributes': > /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ > gcc/../.././gcc/attribs.c:138: multiple definition of > `decl_attributes' > java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- > linux-gnu/gcc/../.././gcc/java/lang.c:844: first defined here > stub-objc.o: In function `objc_is_class_name': > /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ > gcc/../.././gcc/stub-objc.c:34: multiple definition of > `objc_is_class_name' > java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- > linux-gnu/gcc/../.././gcc/java/lang.c:856: first defined here > stub-objc.o: In function `objc_v2_component_ref_field_offset': > /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ > gcc/../.././gcc/stub-objc.c:474: multiple definition of > `objc_v2_component_ref_field_offset' > java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- > linux-gnu/gcc/../.././gcc/java/lang.c:880: first defined here > stub-objc.o: In function `objc_v2_bitfield_ivar_bitpos': > /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ > gcc/../.././gcc/stub-objc.c:480: multiple definition of > `objc_v2_bitfield_ivar_bitpos' > java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- > linux-gnu/gcc/../.././gcc/java/lang.c:872: first defined here > stub-objc.o: In function `objc_method_decl': > /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ > gcc/../.././gcc/stub-objc.c:494: multiple definition of > `objc_method_decl' > java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- > linux-gnu/gcc/../.././gcc/java/lang.c:863: first defined here > stub-objc.o: In function `objc_create_init_utf16_var': > /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ > gcc/../.././gcc/stub-objc.c:576: multiple definition of > `objc_create_init_utf16_var' > java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- > linux-gnu/gcc/../.././gcc/java/lang.c:888: first defined here > stub-objc.o: In function `objc_anonymous_local_objc_name': > /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/ > gcc/../.././gcc/stub-objc.c:583: multiple definition of > `objc_anonymous_local_objc_name' > java/lang.o:/home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown- > linux-gnu/gcc/../.././gcc/java/lang.c:895: first defined here > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2555 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080202/76f47f19/attachment.bin From baldrick at free.fr Sat Feb 2 03:58:04 2008 From: baldrick at free.fr (Duncan Sands) Date: Sat, 2 Feb 2008 10:58:04 +0100 Subject: [LLVMdev] Problem Compiling llvm-gcc 4.2 In-Reply-To: <379E1FAC-F236-499D-955D-5D6B47C38316@cs.hku.hk> References: <379E1FAC-F236-499D-955D-5D6B47C38316@cs.hku.hk> Message-ID: <200802021058.04803.baldrick@free.fr> Try configuring with --disable-multilib Ciao, Duncan. From bobby at sharedrealm.com Sat Feb 2 04:10:03 2008 From: bobby at sharedrealm.com (Robert G. Jakabosky) Date: Sat, 2 Feb 2008 02:10:03 -0800 Subject: [LLVMdev] Problem Compiling llvm-gcc 4.2 In-Reply-To: <379E1FAC-F236-499D-955D-5D6B47C38316@cs.hku.hk> References: <379E1FAC-F236-499D-955D-5D6B47C38316@cs.hku.hk> Message-ID: <200802020210.03912.bobby@sharedrealm.com> On Saturday 02, Kinson Chan ??? wrote: > That is a Linux box (Debian, with 2.6.23-1 Kernel) and I have already > tried combinations of --disable-shared and/or --disable-multilib. It > get stuck at the same point. >From the make messages it looks like you are compiling on x86_64 linux. I had lots of problems compile llvm-gcc-4.2 from svn on x86_64. Just today I got it to work by diabling bootstrap with "--diable-bootstrap". It might also be needed to compile the 2.1 release version of llvm-gcc-4.2 Here is my configure command: ../llvm-gcc-4.2/configure --prefix=/opt/llvm --enable-llvm=/opt/llvm-top/build.llvm-2.1/ --enable-languages=c,c++ --enable-checking --disable-shared --disable-multilib --disable-bootstrap That is for a debug build. I haven't try a relase build yet, but it should only require removing the "--enable-checking" option. Also there is a bug about this problem: http://llvm.org/bugs/show_bug.cgi?id=1711 I added comments to that bug and a patch to get the latest svn revision to build on Linux x86_64. I am using Gentoo Linux with kernel 2.6.23 and gcc 4.2.2 -- Robert G. Jakabosky From kchan at cs.hku.hk Sat Feb 2 04:31:16 2008 From: kchan at cs.hku.hk (=?BIG5?B?S2luc29uIENoYW4gs6+zx6tI?=) Date: Sat, 2 Feb 2008 18:31:16 +0800 Subject: [LLVMdev] Persisting Problem Compiling llvm-gcc 4.2 Message-ID: Dear All, Thank you for the prompt suggestion in compiling llvm-gcc. I have just tried the following: llvm-gcc4.2-2.1-source$ make clean llvm-gcc4.2-2.1-source$ ./configure --disable-multilib --disable- shared --enable-languages=c,c++ llvm-gcc4.2-2.1-source$ make -j32 And still the code for Java is compiled and clashes with others in the linker. I have tried removing the ./gcc/java folder and then it fails at stage-1. I guess I missed some tricks disabling Java compilation. Once again, thank you for your help. Regards, Kinson From echristo at apple.com Sat Feb 2 04:54:51 2008 From: echristo at apple.com (Eric Christopher) Date: Sat, 2 Feb 2008 02:54:51 -0800 Subject: [LLVMdev] Persisting Problem Compiling llvm-gcc 4.2 In-Reply-To: References: Message-ID: <8C8FBDA8-3EF4-485C-B1DF-AA050B6D890A@apple.com> On Feb 2, 2008, at 2:31 AM, Kinson Chan ??? wrote: > Dear All, > > Thank you for the prompt suggestion in compiling llvm-gcc. I have just > tried the following: > > llvm-gcc4.2-2.1-source$ make clean > llvm-gcc4.2-2.1-source$ ./configure --disable-multilib --disable- > shared --enable-languages=c,c++ Don't use ./configure. Set up another build directory and then something like: .../source/configure ... Note that I make no claims this will fix your problem, but it'll be a good start :) -eric From tonic at nondot.org Sat Feb 2 12:03:13 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sat, 2 Feb 2008 10:03:13 -0800 Subject: [LLVMdev] Question to Chris In-Reply-To: <20080202015146.BBC09843@expms2.cites.uiuc.edu> References: <20080202015146.BBC09843@expms2.cites.uiuc.edu> Message-ID: <01BD4596-802C-4FED-8195-95A722A68E2F@nondot.org> Ok, here are a few suggestions and comments: 1) LLVM has the capabilities to do everything that you are trying to re-implement. 2) Have you looked at the C backend? It recreates loops. It may not create "for" loops but you can hack on it to do that. 3) The way you are converting out of SSA is wrong. You will suffer from lost copies. You should look at using demotePHI(). see include/ llvm/Transforms/Utils/Local.h 4) LLVM will compute your trip counts for you, use LoopInfo. You need to be in SSA form to do this. -Tanya On Feb 1, 2008, at 11:51 PM, Seung Jae Lee wrote: > Dear Prof.Adve and Bill, > > I deeply appreciate your comments and concerns. > (Please forgive my late response. I've tried some more cases to > make this issue) > > As Prof.Adve mentioned, I need to explain exactly what my problem > is, but I have no good ability that I can explain it in this plain > text space. > > For this reason, I made a .pdf file and linked it as follows: > > https://netfiles.uiuc.edu/lee225/www/MakingLoops.pdf > > Would you please explain to me how I can access to this problem in > a better way if you can figure out? > > Once again, I really appreciate your time and favor, Bill and > Prof.Adve. > > Truly yours, > Seung J. Lee > > > ---- Original message ---- >> Date: Mon, 28 Jan 2008 09:39:52 -0600 >> From: "Vikram S. Adve" >> Subject: Re: [LLVMdev] Question to Chris >> To: LLVM Developers Mailing List >> >> Bill, >> >> Depending on what Seung's problem is, converting *out* of SSA form >> may >> actually be the wrong thing to do. Seung needs to explain exactly >> problem he is unable solve using SSA form. >> >> --Vikram >> http://www.cs.uiuc.edu/~vadve >> http://llvm.org/ >> >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Sat Feb 2 12:41:50 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 2 Feb 2008 10:41:50 -0800 Subject: [LLVMdev] Persisting Problem Compiling llvm-gcc 4.2 In-Reply-To: <8C8FBDA8-3EF4-485C-B1DF-AA050B6D890A@apple.com> References: <8C8FBDA8-3EF4-485C-B1DF-AA050B6D890A@apple.com> Message-ID: On Feb 2, 2008, at 2:54 AM, Eric Christopher wrote: > > On Feb 2, 2008, at 2:31 AM, Kinson Chan ??? wrote: > >> Dear All, >> >> Thank you for the prompt suggestion in compiling llvm-gcc. I have >> just >> tried the following: >> >> llvm-gcc4.2-2.1-source$ make clean >> llvm-gcc4.2-2.1-source$ ./configure --disable-multilib --disable- >> shared --enable-languages=c,c++ > > Don't use ./configure. Set up another build directory and then > something like: > > .../source/configure ... > > Note that I make no claims this will fix your problem, but it'll be a > good start :) More generally, you really do need to follow the instructions in README.LLVM. -Chris From cstraehle at googlemail.com Sat Feb 2 11:58:41 2008 From: cstraehle at googlemail.com (Christoph Straehle) Date: Sat, 2 Feb 2008 18:58:41 +0100 Subject: [LLVMdev] another llvm-gcc-4.2 compilation problem Message-ID: hi, i also have problems compiling llvm-gcc (current svn version). llvm is current llvm svn. i tried to use every gcc version from 4.0 to 4.3 to compile llvm-gcc. i configured llvm-gcc like this (and tried every other combination of disable-shared, disable-multilib and bootstrap) : ../llvm-gcc/configure --prefix=/usr --enable-llvm=/usr --enable-languages=c,c++ --disable-shared --disable-multilib --disable-bootstrap this error occurs during link time : libbackend.a(llvm-backend.o):(.rodata._ZTC11oFILEstream0_So[vtable for oFILEstream]+0xc): undefined reference to `std::basic_ostream >::~basic_ostream()' libbackend.a(llvm-backend.o):(.rodata._ZTC11oFILEstream0_So[vtable for oFILEstream]+0x10): undefined reference to `std::basic_ostream >::~basic_ostream()' libbackend.a(llvm-backend.o):(.rodata._ZTC11oFILEstream0_So[vtable for oFILEstream]+0x20): undefined reference to `virtual thunk to std::basic_ostream >::~basic_ostream()' libbackend.a(llvm-backend.o):(.rodata._ZTC11oFILEstream0_So[vtable for oFILEstream]+0x24): undefined reference to `virtual thunk to std::basic_ostream >::~basic_ostream()' libbackend.a(llvm-backend.o):(.rodata._ZTVN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEE[vtable for __gnu_cxx::stdio_filebuf >]+0x30): undefined reference to `std::basic_streambuf >::uflow()' libbackend.a(llvm-convert.o): In function `TreeToLLVM::CreateTemporary(llvm::Type const*)': llvm-convert.cpp:(.text+0x427): undefined reference to `std::basic_string, std::allocator >::~basic_string()' llvm-convert.cpp:(.text+0x491): undefined reference to `std::basic_string, std::allocator >::~basic_string()' llvm-convert.cpp:(.text+0x532): undefined reference to `std::basic_string, std::allocator >::~basic_string()' llvm-convert.cpp:(.text+0x548): undefined reference to `std::basic_string, std::allocator >::~basic_string()' libbackend.a(llvm-convert.o): In function `TreeToLLVM::getIndirectGotoBlock()': .............. is the current llvm-gcc broken on linux or am i missing something here ? greetings -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080202/03ba3288/attachment.html From mrs at apple.com Sat Feb 2 13:31:46 2008 From: mrs at apple.com (Mike Stump) Date: Sat, 2 Feb 2008 11:31:46 -0800 Subject: [LLVMdev] Question to Chris In-Reply-To: <20080202015146.BBC09843@expms2.cites.uiuc.edu> References: <20080202015146.BBC09843@expms2.cites.uiuc.edu> Message-ID: <02B3B017-BA86-47D3-8B6F-9DAE01329E54@apple.com> On Feb 1, 2008, at 11:51 PM, Seung Jae Lee wrote: > As Prof.Adve mentioned, I need to explain exactly what my problem > is, but I have no good ability that I can explain it in this plain > text space. Let me rephrase your question for you. You can then see the right question, and the answer for it. The question is, why is, why can't I change: bb8: sum_1 = i_0_pn + sum_0_pn; br bool %exitcond, label %bb10, label %bb3 into bb8: br bool %exitcond, label %bb10, label %bb3 sum_1 = i_0_pn + sum_0_pn; ? The answer is, because that is an invalid transform. A: B; C; has to be transformed into: B; A: C; (where the motion of B is copy it to the other side of all control flows into A) When you do this, you'll notice you get: $ cat t.c int foo() { unsigned indvar_next27, indvar_next; int sum_1, sum_0_pn, i_0_pn; //entry: unsigned indvar26 = 0; int sum_0_pn_ph = 0; //brlabel %bb8_outer //bb8_outer: for (indvar_next27=0; indvar_next27 != 10; ){ int i_0_0_ph = (int) indvar26; unsigned indvar= 0; int sum_0_pn = sum_0_pn_ph; int i_0_pn = i_0_0_ph; //brlabel %bb8 //bb8: sum_1 = i_0_pn + sum_0_pn; /* LOOK HERE */ for (;indvar!=3;){ //%exitcond= setequint%indvar, 3 //brbool %exitcond, label %bb10, label %bb3 //bb3: indvar_next= indvar+ 1; indvar= indvar_next; sum_0_pn = sum_1; i_0_pn = 2; sum_1 = i_0_pn + sum_0_pn; /* LOOK HERE */ //brlabel %bb8 } //bb10: indvar_next27 = indvar26 + 1; //%exitcond28 = setequint%indvar_next27, 10 indvar26 = indvar_next27; sum_0_pn_ph = sum_1; //brbool %exitcond28, label %bb16, label %bb8_outer } //bb16: return sum_1; } int main() { printf("%d\n", foo()); } $ gcc t.c t.c: In function ?main?: t.c:40: warning: incompatible implicit declaration of built-in function ?printf? $ ./a.out 105 The cost of the .pdf file outweighed the benefit for me. I can see the pretty graphs in the straight text code. If you want to help me see them further, just indent. The short answer is you can't guess at valid transforms. You have to know they are valid, or prove the are valid. The only way to get: for (;C;) { S } is to transform: top: if (!C) goto end; S goto top; end: into it. If you have any other form, it is wrong to transform into it. You _must_transform into the form just above first, and then that form goes into the for statement. At the end of the day, you have a set of valid transforms, each one of which you can talk about and audit separately. If you have any bugs, they are never in the valid transforms, and the invalid ones stand out to people skilled in the art. So, if you had written down the transform you were using, we could have identified it. You didn't, so, we could not. I didn't check your other loop for correctness, or any of the other implied transforms that you used for correctness. If you want to ensure it is correct, you can run large amount of code through it and check the results (I'd call that the industrial approach) and hope it is approximately right, or, you have to reason about each and every transform you're using and hopefully even prove each one. The latter approach I'd call the academic approach. :-) You're splitting and moving phi nodes seems reasonable. The transform of: top: S; goto top; into for (;;) { S; } is valid. What isn't valid is putting the induction variable into the condition slot and calling it done. You must first transform it into the form given above. To do that, you have to use other transforms, each one of which you should write down and list and prove is valid. If you want us to audit each transform for you, write them all down, one by one. From ramon.garcia.f at gmail.com Sat Feb 2 19:48:27 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Sun, 3 Feb 2008 02:48:27 +0100 Subject: [LLVMdev] Introducing myself, and Java project. Message-ID: Hello, I am Ramon Garcia Fernandez. My interest in LLVM is to develop an interface for Java virtual machine bytecodes, so that Java programs can be run under LLVM. You may ask why not using the Java virtual machine. Although it may be improved, there are some misfeatures in it. This is what I have learned. It makes the communication with native code too expensive. Passing an array from native to the virtual machine or vice versa requires a copy of the data. Why? you may ask. Because Java uses garbage collectors based on copying. Thus the position of an object may be moved by the virtual machine. The implementation of generational garbage collection in Java uses areas of memory for each generation, so that when an object changes from the young generation to the old its storage must be moved. This may give some performance advantage, by making young objects close in memory, but with the cost of making exchange of data with native code expensive. In particular, data copying is required for reading and writing files, sending or receiving data from the network, or drawing. Since Java is not often used for numerical analysis or tasks that require little data exchange with the outside world, I disagree that the implementation with a copying collector is good for most applications. A more obvious problem is, of course, that it is not possible to compile Java code statically and save the result in the disk. So I am starting to write a compiler of Java bytecode to LLVM bytecode. For now I am designing, dealing with things such as how to assign stack positions to the operands of each instruction. My target is to deliver something simple. Operations such as classloader creation and dynamic class loading will not be supported. Hoping that this is the start of a long term cooperation, Ramon From ramon.garcia.f+llvm at gmail.com Sat Feb 2 19:55:24 2008 From: ramon.garcia.f+llvm at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Sun, 3 Feb 2008 02:55:24 +0100 Subject: [LLVMdev] Java project, and introducing myself. Message-ID: Hello, I am Ramon Garcia Fernandez. My interest in LLVM is to develop an interface for Java virtual machine bytecodes, so that Java programs can be run under LLVM. You may ask why not using the Java virtual machine. Although it may be improved, there are some misfeatures in it. This is what I have learned. It makes the communication with native code too expensive. Passing an array from native to the virtual machine or vice versa requires a copy of the data. Why? you may ask. Because Java uses garbage collectors based on copying. Thus the position of an object may be moved by the virtual machine. The implementation of generational garbage collection in Java uses areas of memory for each generation, so that when an object changes from the young generation to the old its storage must be moved. This may give some performance advantage, by making young objects close in memory, but with the cost of making exchange of data with native code expensive. In particular, data copying is required for reading and writing files, sending or receiving data from the network, or drawing. Since Java is not often used for numerical analysis or tasks that require little data exchange with the outside world, I disagree that the implementation with a copying collector is good for most applications. A more obvious problem is, of course, that it is not possible to compile Java code statically and save the result in the disk. So I am starting to write a compiler of Java bytecode to LLVM bytecode. For now I am designing, dealing with things such as how to assign stack positions to the operands of each instruction. My target is to deliver something simple. Operations such as classloader creation and dynamic class loading will not be supported. Hoping that this is the start of a long term cooperation, Ramon From tonic at nondot.org Sat Feb 2 20:09:02 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sat, 2 Feb 2008 18:09:02 -0800 Subject: [LLVMdev] Introducing myself, and Java project. In-Reply-To: References: Message-ID: Have you looked at the this? http://llvm.org/viewvc/llvm-project/java/trunk/ Someone started a Java frontend. Perhaps you could finish it? -Tanya On Feb 2, 2008, at 5:48 PM, Ram?n Garc?a wrote: > Hello, I am Ramon Garcia Fernandez. My interest in LLVM is to develop > an interface for Java virtual machine bytecodes, so that Java programs > can be run under LLVM. > > You may ask why not using the Java virtual machine. Although it may be > improved, there are some misfeatures in it. This is what I have > learned. It makes the communication with native code too expensive. > Passing an array from native to the virtual machine or vice versa > requires a copy of the data. Why? you may ask. Because Java uses > garbage collectors based on copying. Thus the position of an object > may be moved by the virtual machine. The implementation of > generational garbage collection in Java uses areas of memory for each > generation, so that when an object changes from the young generation > to the old its storage must be moved. This may give some performance > advantage, by making young objects close in memory, but with the cost > of making exchange of data with native code expensive. In particular, > data copying is required for reading and writing files, sending or > receiving data from the network, or drawing. Since Java is not often > used for numerical analysis or tasks that require little data exchange > with the outside world, I disagree that the implementation with a > copying collector is good for most applications. > > A more obvious problem is, of course, that it is not possible to > compile Java code statically and save the result in the disk. > > So I am starting to write a compiler of Java bytecode to LLVM > bytecode. For now I am designing, dealing with things such as how to > assign stack positions to the operands of each instruction. > > My target is to deliver something simple. Operations such as > classloader creation and dynamic class loading will not be supported. > > Hoping that this is the start of a long term cooperation, > > Ramon > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ramon.garcia.f at gmail.com Sat Feb 2 20:50:36 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Sun, 3 Feb 2008 03:50:36 +0100 Subject: [LLVMdev] Introducing myself, and Java project. In-Reply-To: References: Message-ID: No, I didn't, I am going to look at it. On Feb 3, 2008 3:09 AM, Tanya Lattner wrote: > Have you looked at the this? > http://llvm.org/viewvc/llvm-project/java/trunk/ Ramon From emikulic at gmail.com Sun Feb 3 01:49:46 2008 From: emikulic at gmail.com (Emil Mikulic) Date: Sun, 3 Feb 2008 18:49:46 +1100 Subject: [LLVMdev] 2.2 Prerelease available for testing In-Reply-To: References: Message-ID: <20080203074946.GA47549@dmr.ath.cx> Target: FreeBSD 6.2-STABLE on i386 autoconf says: configure:2122: checking build system type configure:2140: result: i386-unknown-freebsd6.2 [...] configure:2721: gcc -v >&5 Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 [...] objdir != srcdir, for both llvm and gcc. Release build. llvm-gcc 4.2 from source. LLVM's "gmake check" summary: # of expected passes 2520 # of expected failures 7 The llvm-test nightly report is attached. I had to manually kill tramp3d-v4.native after ~1hr of CPU time. --Emil -------------- next part -------------- Program | GCCAS Bytecode LLC compile LLC-BETA compile JIT codegen | GCC CBE LLC LLC-BETA JIT | GCC/CBE GCC/LLC GCC/LLC-BETA LLC/LLC-BETA MultiSource/Applications/Burg/burg | 1.1897 193516 1.1707 * 1.1251 | 0.00 0.00 0.00 * 1.20 | - - n/a n/a MultiSource/Applications/JM/ldecod/ldecod | 4.3928 928536 4.9749 * 4.3618 | 0.68 0.59 0.68 * 5.39 | 1.15 1.00 n/a n/a MultiSource/Applications/JM/lencod/lencod | 13.9789 2170084 11.9103 * 9.7473 | 19.46 21.31 15.04 * 25.28 | 0.91 1.29 n/a n/a MultiSource/Applications/SIBsim4/SIBsim4 | 0.7892 135704 0.8438 * 0.8100 | 6.06 9.54 7.63 * 8.64 | 0.64 0.79 n/a n/a MultiSource/Applications/SPASS/SPASS | 13.6981 2049720 9.0829 * 6.1641 | 29.53 29.37 29.03 * 36.25 | 1.01 1.02 n/a n/a MultiSource/Applications/aha/aha | 0.0623 9880 0.0593 * 0.0565 | 4.86 5.15 5.43 * 5.47 | 0.94 0.90 n/a n/a MultiSource/Applications/d/make_dparser | 2.3353 452528 1.7279 * 1.4561 | 0.07 0.08 0.07 * 1.72 | - - n/a n/a MultiSource/Applications/hbd/hbd | 0.4479 125216 0.6032 * 0.5202 | 0.01 0.01 0.00 * 0.57 | - - n/a n/a MultiSource/Applications/hexxagon/hexxagon | 0.2775 46588 0.2197 * 0.2089 | 26.35 13.96 13.62 * 13.22 | 1.89 1.93 n/a n/a MultiSource/Applications/kimwitu++/kc | 11.1178 2907236 10.9595 * 6.0439 | 0.32 0.32 0.32 * 7.17 | 1.00 1.00 n/a n/a MultiSource/Applications/lambda-0.1.3/lambda | 0.5119 112884 0.5464 * 0.4060 | 11.14 11.95 9.39 * 10.98 | 0.93 1.19 n/a n/a MultiSource/Applications/minisat/minisat | 0.4849 75528 0.3157 * * | 20.19 23.77 20.28 * * | 0.85 1.00 n/a n/a MultiSource/Applications/oggenc/oggenc | 2.7222 997184 * * * | 0.36 * * * * | n/a n/a n/a n/a MultiSource/Applications/sgefa/sgefa | 0.1360 20560 0.1257 * 0.1229 | 3.95 4.33 2.77 * 2.89 | 0.91 1.43 n/a n/a MultiSource/Applications/siod/siod | 1.8358 582112 3.2327 * 1.4213 | 6.49 8.10 6.13 * 7.62 | 0.80 1.06 n/a n/a MultiSource/Applications/spiff/spiff | 0.3883 69384 0.4121 * * | 9.93 10.00 9.95 * * | 0.99 1.00 n/a n/a MultiSource/Applications/treecc/treecc | 1.4932 375824 1.9689 * 0.5528 | 0.00 0.00 0.00 * 0.62 | - - n/a n/a MultiSource/Applications/viterbi/viterbi | 0.0542 6944 0.0405 * 0.0393 | 21.15 38.19 19.29 * 19.40 | 0.55 1.10 n/a n/a MultiSource/Benchmarks/ASCI_Purple/SMG2000/smg2000 | 3.4553 637348 4.8566 * 4.0849 | 10.71 12.59 10.20 * 14.23 | 0.85 1.05 n/a n/a MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1 | 0.0767 10752 0.0642 * 0.0680 | 4.10 4.27 4.28 * 4.40 | 0.96 0.96 n/a n/a MultiSource/Benchmarks/Fhourstones/fhourstones | 0.0965 17520 0.0809 * 0.0790 | 4.12 3.87 3.28 * 3.45 | 1.06 1.26 n/a n/a MultiSource/Benchmarks/FreeBench/analyzer/analyzer | 0.0824 13252 0.0717 * 0.0685 | 0.13 0.21 0.11 * 0.19 | 0.62 1.18 n/a n/a MultiSource/Benchmarks/FreeBench/distray/distray | 0.0589 14428 0.0645 * 0.0622 | 0.58 0.80 0.35 * 0.43 | 0.72 1.66 n/a n/a MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow | 0.1444 26912 0.1834 * 0.1526 | 1.91 2.05 2.23 * 2.41 | 0.93 0.86 n/a n/a MultiSource/Benchmarks/FreeBench/mason/mason | 0.0586 15632 0.0610 * 0.0584 | 1.36 0.58 0.61 * 0.67 | 2.34 2.23 n/a n/a MultiSource/Benchmarks/FreeBench/neural/neural | 0.0828 11800 0.0720 * 0.0702 | 0.25 0.27 0.48 * 0.56 | 0.93 0.52 n/a n/a MultiSource/Benchmarks/FreeBench/pcompress2/pcompress2 | 0.0848 15556 0.0809 * 0.0790 | 0.47 0.48 0.68 * 0.76 | 0.98 0.69 n/a n/a MultiSource/Benchmarks/FreeBench/pifft/pifft | 0.4160 99264 0.6636 * 0.6371 | 0.31 0.35 0.31 * 1.00 | 0.89 1.00 n/a n/a MultiSource/Benchmarks/MallocBench/cfrac/cfrac | 0.4226 113596 0.4637 * 0.4274 | 4.75 4.60 4.56 * 5.01 | 1.03 1.04 n/a n/a MultiSource/Benchmarks/MallocBench/espresso/espresso | 2.6235 602160 3.1388 * 1.9914 | 0.99 1.08 0.98 * 3.16 | 0.92 1.01 n/a n/a MultiSource/Benchmarks/MallocBench/gs/gs | 2.4592 533088 2.5566 * 1.1136 | 0.09 0.10 0.10 * 1.39 | - - n/a n/a MultiSource/Benchmarks/McCat/01-qbsort/qbsort | 0.0221 4284 0.0243 * 0.0235 | 0.14 0.14 0.14 * 0.16 | 1.00 1.00 n/a n/a MultiSource/Benchmarks/McCat/03-testtrie/testtrie | 0.0427 5496 0.0319 * 0.0319 | 0.02 0.01 0.01 * 0.06 | - - n/a n/a MultiSource/Benchmarks/McCat/04-bisect/bisect | 0.0278 5120 0.0304 * 0.0294 | 0.20 0.79 0.22 * 0.26 | 0.25 0.91 n/a n/a MultiSource/Benchmarks/McCat/05-eks/eks | 0.1282 9560 0.0719 * 0.0702 | 0.01 0.01 0.01 * 0.09 | - - n/a n/a MultiSource/Benchmarks/McCat/08-main/main | 0.1193 20472 0.0847 * 0.0773 | 0.23 0.18 0.20 * 0.29 | 1.28 1.15 n/a n/a MultiSource/Benchmarks/McCat/09-vor/vor | 0.1595 32312 0.1413 * 0.1336 | 0.27 0.34 0.35 * 0.45 | 0.79 0.77 n/a n/a MultiSource/Benchmarks/McCat/12-IOtest/iotest | 0.0346 3148 0.0178 * 0.0169 | 1.51 0.86 0.41 * 0.44 | 1.76 3.68 n/a n/a MultiSource/Benchmarks/McCat/15-trie/trie | 0.0244 4424 0.0259 * 0.0249 | 0.00 0.00 0.00 * 0.04 | - - n/a n/a MultiSource/Benchmarks/McCat/17-bintr/bintr | 0.0311 6456 0.0327 * 0.0322 | 0.20 0.19 0.20 * 0.24 | 1.05 1.00 n/a n/a MultiSource/Benchmarks/McCat/18-imp/imp | 0.1560 32092 0.1639 * 0.1594 | 0.17 0.20 0.20 * 0.38 | 0.85 0.85 n/a n/a MultiSource/Benchmarks/MiBench/automotive-basicmath/automotive-basicmath | 0.0290 5776 0.0376 * 0.0361 | 0.96 0.96 0.93 * 0.98 | 1.00 1.03 n/a n/a MultiSource/Benchmarks/MiBench/automotive-bitcount/automotive-bitcount | 0.0322 4208 0.0205 * 0.0205 | 0.20 0.26 0.22 * 0.25 | 0.77 0.91 n/a n/a MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan | 0.3937 96220 0.4484 * 0.4162 | 0.15 0.14 0.12 * 0.56 | 1.07 1.25 n/a n/a MultiSource/Benchmarks/MiBench/consumer-jpeg/consumer-jpeg | 2.0645 304916 1.3907 * 0.6100 | 0.01 0.00 0.00 * 0.71 | - - n/a n/a MultiSource/Benchmarks/MiBench/consumer-lame/consumer-lame | 1.9625 455064 1.9053 * * | 0.64 * 0.61 * * | n/a 1.05 n/a n/a MultiSource/Benchmarks/MiBench/consumer-typeset/consumer-typeset | 10.1016 2170048 8.7610 * 6.9806 | 0.38 0.37 0.38 * 7.90 | 1.03 1.00 n/a n/a MultiSource/Benchmarks/MiBench/network-dijkstra/network-dijkstra | 0.0176 3460 0.0197 * 0.0196 | 0.07 0.07 0.06 * 0.08 | - - n/a n/a MultiSource/Benchmarks/MiBench/network-patricia/network-patricia | 0.0343 5444 0.0300 * 0.0287 | 0.22 0.24 0.25 * 0.26 | 0.92 0.88 n/a n/a MultiSource/Benchmarks/MiBench/office-ispell/office-ispell | 1.1963 203000 1.0589 * 0.2566 | 0.00 0.00 0.00 * 0.28 | - - n/a n/a MultiSource/Benchmarks/MiBench/office-stringsearch/office-stringsearch | 0.0456 13604 0.0100 * 0.0099 | 0.00 0.00 0.00 * 0.03 | - - n/a n/a MultiSource/Benchmarks/MiBench/security-blowfish/security-blowfish | 0.1599 48472 0.1635 * 0.0804 | 0.00 0.00 0.00 * 0.10 | - - n/a n/a MultiSource/Benchmarks/MiBench/security-rijndael/security-rijndael | 1.1191 70760 0.1431 * 0.1004 | 0.15 0.15 0.11 * 0.25 | 1.00 1.36 n/a n/a MultiSource/Benchmarks/MiBench/security-sha/security-sha | 0.0264 5180 0.0246 * 0.0238 | 0.04 0.04 0.03 * 0.06 | - - n/a n/a MultiSource/Benchmarks/MiBench/telecomm-CRC32/telecomm-CRC32 | 0.0125 3636 0.0096 * 0.0092 | 0.15 0.13 0.12 * 0.13 | 1.15 1.25 n/a n/a MultiSource/Benchmarks/MiBench/telecomm-FFT/telecomm-fft | 0.0326 5992 0.0373 * 0.0360 | 0.10 0.10 0.10 * 0.15 | 1.00 1.00 n/a n/a MultiSource/Benchmarks/MiBench/telecomm-adpcm/telecomm-adpcm | 0.0156 2604 0.0096 * 0.0092 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm-gsm | 0.5413 111788 0.3766 * 0.2866 | 0.39 0.41 0.34 * 0.67 | 0.95 1.15 n/a n/a MultiSource/Benchmarks/Olden/bh/bh | 0.1476 24124 0.1227 * 0.1173 | 8.08 8.22 7.15 * 7.52 | 0.98 1.13 n/a n/a MultiSource/Benchmarks/Olden/bisort/bisort | 0.0283 7092 0.0457 * 0.0447 | 1.79 1.89 1.54 * 1.63 | 0.95 1.16 n/a n/a MultiSource/Benchmarks/Olden/em3d/em3d | 0.0557 7584 0.0449 * 0.0448 | 6.61 7.63 7.05 * 7.23 | 0.87 0.94 n/a n/a MultiSource/Benchmarks/Olden/health/health | 0.0472 10148 0.0446 * 0.0439 | 0.66 0.73 0.57 * 0.62 | 0.90 1.16 n/a n/a MultiSource/Benchmarks/Olden/mst/mst | 0.0494 6068 0.0348 * 0.0339 | 0.40 0.39 0.38 * 0.42 | 1.03 1.05 n/a n/a MultiSource/Benchmarks/Olden/perimeter/perimeter | 0.0359 9532 0.0608 * 0.0551 | 0.56 0.63 0.61 * 0.71 | 0.89 0.92 n/a n/a MultiSource/Benchmarks/Olden/power/power | 0.0558 11576 0.0536 * 0.0512 | 6.62 5.69 3.44 * 3.44 | 1.16 1.92 n/a n/a MultiSource/Benchmarks/Olden/treeadd/treeadd | 0.0079 2592 0.0170 * 0.0167 | 7.58 7.23 7.31 * 7.36 | 1.05 1.04 n/a n/a MultiSource/Benchmarks/Olden/tsp/tsp | 0.0550 10908 0.0506 * 0.0503 | 2.83 8.89 2.61 * 2.65 | 0.32 1.08 n/a n/a MultiSource/Benchmarks/Olden/voronoi/voronoi | 0.1492 36924 0.1308 * 0.1283 | 0.84 1.15 0.75 * 0.93 | 0.73 1.12 n/a n/a MultiSource/Benchmarks/OptimizerEval/optimizer-eval | 0.1862 38784 0.2298 * 0.2440 | 87.94 90.57 98.20 * 97.25 | 0.97 0.90 n/a n/a MultiSource/Benchmarks/Prolangs-C++/NP/np | 0.0034 1176 0.0036 * 0.0033 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/city/city | 0.2161 29744 0.0947 * 0.0727 | 0.02 0.01 0.01 * 0.10 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/deriv1/deriv1 | 0.0449 10612 0.0375 * 0.0280 | 0.00 0.00 0.00 * 0.03 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/deriv2/deriv2 | 0.0627 12864 0.0572 * 0.0426 | 0.00 0.00 0.00 * 0.06 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/employ/employ | 0.1161 16148 0.0763 * 0.0283 | 0.00 0.00 0.00 * 0.04 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/family/family | 0.0262 4128 0.0131 * 0.0114 | 0.00 0.00 0.00 * 0.02 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/fsm/fsm | 0.0322 2308 0.0087 * 0.0083 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/garage/garage | 0.0505 6860 0.0339 * 0.0307 | 0.00 0.00 0.00 * 0.04 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/life/life | 0.0430 7120 0.0351 * 0.0330 | 3.66 3.89 4.09 * 3.97 | 0.94 0.89 n/a n/a MultiSource/Benchmarks/Prolangs-C++/objects/objects | 0.0825 13216 0.0666 * 0.0115 | 0.00 0.00 0.00 * 0.02 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/ocean/ocean | 0.0984 13460 0.0553 * 0.0422 | 0.17 0.16 0.16 * 0.22 | 1.06 1.06 n/a n/a MultiSource/Benchmarks/Prolangs-C++/office/office | 0.0257 5872 0.0163 * 0.0159 | 0.00 0.00 0.00 * 0.03 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/primes/primes | 0.0135 1716 0.0062 * 0.0061 | 1.17 1.30 1.19 * 1.15 | 0.90 0.98 n/a n/a MultiSource/Benchmarks/Prolangs-C++/shapes/shapes | 0.0776 17112 0.0799 * 0.0608 | 0.00 0.00 0.00 * 0.08 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/simul/simul | 0.0706 4580 0.0264 * 0.0114 | 0.02 0.01 0.01 * 0.03 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/trees/trees | 0.0905 15916 0.0494 * 0.0369 | 0.00 0.00 0.00 * 0.05 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C++/vcirc/vcirc | 0.0170 1916 0.0065 * 0.0059 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/TimberWolfMC/timberwolfmc | 3.1184 770364 4.3001 * 0.6510 | 0.00 0.00 0.00 * 0.70 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/agrep/agrep | 0.7183 138476 0.7390 * 0.2720 | 0.00 0.00 0.00 * 0.30 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/allroots/allroots | 0.0229 4636 0.0248 * 0.0240 | 0.00 0.00 0.00 * 0.03 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/assembler/assembler | 0.2920 82104 0.4514 * 0.3182 | 0.00 0.00 0.00 * 0.35 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/bison/mybison | 0.9403 246216 1.5809 * 1.5258 | 0.00 0.01 0.01 * 1.63 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/cdecl/cdecl | 0.2041 65624 0.5193 * 0.5121 | 0.00 0.00 0.00 * 0.55 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/compiler/compiler | 0.2544 64912 0.3592 * 0.0815 | 0.00 0.00 0.00 * 0.09 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/fixoutput/fixoutput | 0.0221 7672 0.0620 * 0.0519 | 0.00 0.00 0.00 * 0.05 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/football/football | 0.4918 97860 0.5812 * 0.0488 | 0.00 0.00 0.00 * 0.06 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/gnugo/gnugo | 0.2251 50244 0.2824 * 0.1260 | 0.00 0.00 0.00 * 0.14 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/loader/loader | 0.1275 32456 0.1768 * 0.1199 | 0.00 0.00 0.00 * 0.13 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/simulator/simulator | 0.4515 90164 0.4355 * 0.0464 | 0.00 0.00 0.00 * 0.06 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/unix-smail/unix-smail | 0.2554 56552 0.3575 * 0.2546 | 0.00 0.00 0.00 * 0.28 | - - n/a n/a MultiSource/Benchmarks/Prolangs-C/unix-tbl/unix-tbl | 0.5634 118120 0.6196 * 0.2287 | 0.00 0.00 0.00 * 0.25 | - - n/a n/a MultiSource/Benchmarks/Ptrdist/anagram/anagram | 0.0555 10576 0.0498 * 0.0470 | 1.91 2.39 1.72 * 1.80 | 0.80 1.11 n/a n/a MultiSource/Benchmarks/Ptrdist/bc/bc | 0.5895 154636 0.8729 * 0.7950 | 1.65 1.59 1.54 * 2.40 | 1.04 1.07 n/a n/a MultiSource/Benchmarks/Ptrdist/ft/ft | 0.1060 11200 0.0459 * 0.0448 | 1.77 1.76 1.78 * 1.90 | 1.01 0.99 n/a n/a MultiSource/Benchmarks/Ptrdist/ks/ks | 0.0689 14560 0.0744 * 0.0724 | 1.66 3.23 3.08 * 2.00 | 0.51 0.54 n/a n/a MultiSource/Benchmarks/Ptrdist/yacr2/yacr2 | 0.2985 54124 0.3530 * 0.3457 | 1.89 2.65 2.49 * 3.11 | 0.71 0.76 n/a n/a MultiSource/Benchmarks/SciMark2-C/scimark2 | 0.1291 24252 0.1433 * 0.1381 | 24.09 33.88 26.33 * 26.41 | 0.71 0.91 n/a n/a MultiSource/Benchmarks/llubenchmark/llu | 0.0173 4508 0.0258 * 0.0252 | 12.06 12.21 12.07 * 12.11 | 0.99 1.00 n/a n/a MultiSource/Benchmarks/mediabench/adpcm/rawcaudio/rawcaudio | 0.0158 2924 0.0117 * 0.0113 | 0.01 0.00 0.01 * 0.03 | - - n/a n/a MultiSource/Benchmarks/mediabench/adpcm/rawdaudio/rawdaudio | 0.0158 2604 0.0096 * 0.0092 | 0.01 0.00 0.01 * 0.02 | - - n/a n/a MultiSource/Benchmarks/mediabench/g721/g721encode/encode | 0.1092 18684 0.0882 * 0.0661 | 0.14 0.13 0.11 * 0.20 | 1.08 1.27 n/a n/a MultiSource/Benchmarks/mediabench/gsm/toast/toast | 0.5415 111788 0.3754 * 0.2730 | 0.04 0.05 0.04 * 0.36 | - - n/a n/a MultiSource/Benchmarks/mediabench/jpeg/jpeg-6a/cjpeg | 2.0011 235216 1.0764 * 0.6262 | 0.00 0.00 0.00 * 0.72 | - - n/a n/a MultiSource/Benchmarks/mediabench/mpeg2/mpeg2dec/mpeg2decode | 0.8181 150652 0.7900 * 0.5895 | 0.06 0.04 0.04 * 0.68 | - - n/a n/a MultiSource/Benchmarks/sim/sim | 0.1671 47032 0.2660 * 0.2560 | 12.90 16.16 11.95 * 12.33 | 0.80 1.08 n/a n/a MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 | 17.1437 3106240 * * * | 3087.78 * * * * | n/a n/a n/a n/a SingleSource/Benchmarks/CoyoteBench/almabench | 0.0213 11396 0.0294 * 0.0287 | 38.31 36.35 28.09 * 27.65 | 1.05 1.36 n/a n/a SingleSource/Benchmarks/CoyoteBench/fftbench | 0.1059 21900 0.0889 * 0.0805 | 32.45 21.41 20.18 * 19.99 | 1.52 1.61 n/a n/a SingleSource/Benchmarks/CoyoteBench/huffbench | 0.0369 7052 0.0437 * 0.0430 | 61.51 65.44 45.74 * 47.57 | 0.94 1.34 n/a n/a SingleSource/Benchmarks/CoyoteBench/lpbench | 0.0332 5072 0.0323 * 0.0317 | 14.16 17.64 13.37 * 13.45 | 0.80 1.06 n/a n/a SingleSource/Benchmarks/Dhrystone/dry | 0.0255 1136 0.0048 * 0.0047 | 11.92 0.71 0.55 * 0.61 | 16.79 21.67 n/a n/a SingleSource/Benchmarks/Dhrystone/fldry | 0.0256 1316 0.0055 * 0.0053 | 17.66 14.99 3.47 * 3.48 | 1.18 5.09 n/a n/a SingleSource/Benchmarks/McGill/chomp | 0.0670 7540 0.0475 * 0.0454 | 6.66 6.85 6.82 * 6.78 | 0.97 0.98 n/a n/a SingleSource/Benchmarks/McGill/exptree | 0.0401 6480 0.0384 * 0.0373 | 0.00 0.00 0.00 * 0.05 | - - n/a n/a SingleSource/Benchmarks/McGill/misr | 0.0245 3596 0.0165 * 0.0156 | 1.23 1.33 1.04 * 1.07 | 0.92 1.18 n/a n/a SingleSource/Benchmarks/McGill/queens | 0.0223 5896 0.0300 * 0.0291 | 4.55 4.30 3.69 * 3.74 | 1.06 1.23 n/a n/a SingleSource/Benchmarks/Misc-C++/bigfib | 0.2803 29528 0.1121 * 0.0871 | 1.06 * 1.11 * 1.15 | n/a 0.95 n/a n/a SingleSource/Benchmarks/Misc-C++/mandel-text | 0.0182 3204 0.0157 * 0.0150 | 3.76 11.95 4.03 * 4.05 | 0.31 0.93 n/a n/a SingleSource/Benchmarks/Misc-C++/oopack_v1p8 | 0.0697 11920 0.0566 * 0.0530 | 0.54 1.47 0.65 * 0.72 | 0.37 0.83 n/a n/a SingleSource/Benchmarks/Misc-C++/ray | 0.1097 17496 0.0580 * 0.0498 | 29.18 27.51 7.87 * 7.97 | 1.06 3.71 n/a n/a SingleSource/Benchmarks/Misc-C++/sphereflake | 0.0709 12336 * * * | 24.24 * * * * | n/a n/a n/a n/a SingleSource/Benchmarks/Misc-C++/stepanov_v1p2 | 0.1606 9508 0.0464 * 0.0446 | 15.01 14.75 11.67 * 12.47 | 1.02 1.29 n/a n/a SingleSource/Benchmarks/Misc/ReedSolomon | 0.1246 15612 0.0852 * 0.0817 | 23.87 26.17 11.76 * 12.43 | 0.91 2.03 n/a n/a SingleSource/Benchmarks/Misc/flops | 0.0369 11000 0.0461 * 0.0443 | 17.51 19.41 17.69 * 17.85 | 0.90 0.99 n/a n/a SingleSource/Benchmarks/Misc/mandel | 0.0086 1452 0.0068 * 0.0064 | 4.06 5.46 5.63 * 5.84 | 0.74 0.72 n/a n/a SingleSource/Benchmarks/Misc/oourafft | * * * * * | 0.00 * * * * | n/a n/a n/a n/a SingleSource/Benchmarks/Misc/pi | 0.0059 1180 0.0053 * 0.0046 | 2.62 3.53 1.63 * 1.65 | 0.74 1.61 n/a n/a SingleSource/Benchmarks/Misc/richards_benchmark | 0.0380 7948 0.0316 * 0.0309 | 1.80 1.82 1.66 * 1.88 | 0.99 1.08 n/a n/a SingleSource/Benchmarks/Misc/whetstone | 0.0323 4596 0.0299 * 0.0289 | 8.19 8.28 6.28 * 6.46 | 0.99 1.30 n/a n/a SingleSource/Benchmarks/Shootout-C++/ackermann | 0.0081 3944 0.0144 * 0.0141 | 4.12 3.26 3.51 * 3.42 | 1.26 1.17 n/a n/a SingleSource/Benchmarks/Shootout-C++/ary | 0.0475 4508 0.0143 * 0.0165 | 0.22 0.21 0.22 * 0.31 | 1.05 1.00 n/a n/a SingleSource/Benchmarks/Shootout-C++/ary2 | 0.0426 5328 0.0178 * 0.0199 | 0.22 0.22 0.19 * 0.31 | 1.00 1.16 n/a n/a SingleSource/Benchmarks/Shootout-C++/ary3 | 0.0533 4768 0.0161 * 0.0181 | 4.91 5.14 4.94 * 5.01 | 0.96 0.99 n/a n/a SingleSource/Benchmarks/Shootout-C++/except | 0.0168 4340 0.0131 * * | 0.73 * 0.75 * * | n/a 0.97 n/a n/a SingleSource/Benchmarks/Shootout-C++/fibo | 0.0088 3316 0.0101 * 0.0099 | 10.28 5.99 5.11 * 5.13 | 1.72 2.01 n/a n/a SingleSource/Benchmarks/Shootout-C++/hash | 0.1452 11752 0.0398 * 0.0428 | 3.60 3.54 3.52 * 3.65 | 1.02 1.02 n/a n/a SingleSource/Benchmarks/Shootout-C++/hash2 | 0.1407 16672 0.0617 * 0.0664 | 7.49 6.70 6.57 * 6.80 | 1.12 1.14 n/a n/a SingleSource/Benchmarks/Shootout-C++/heapsort | 0.0149 3804 0.0134 * 0.0132 | 8.01 18.79 6.17 * 6.25 | 0.43 1.30 n/a n/a SingleSource/Benchmarks/Shootout-C++/hello | 0.0044 2632 0.0046 * 0.0042 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Benchmarks/Shootout-C++/lists | 0.0923 9296 0.0301 * 0.0312 | 23.83 24.00 23.73 * 21.70 | 0.99 1.00 n/a n/a SingleSource/Benchmarks/Shootout-C++/lists1 | 0.1233 11592 0.0425 * 0.0443 | 0.79 0.73 0.76 * 0.79 | 1.08 1.04 n/a n/a SingleSource/Benchmarks/Shootout-C++/matrix | 0.0332 5140 0.0198 * 0.0198 | 5.88 5.50 7.01 * 7.05 | 1.07 0.84 n/a n/a SingleSource/Benchmarks/Shootout-C++/methcall | 0.0252 5164 0.0168 * 0.0164 | 16.35 16.47 11.02 * 11.34 | 0.99 1.48 n/a n/a SingleSource/Benchmarks/Shootout-C++/moments | 0.1002 10704 0.0453 * 0.0441 | 0.71 0.97 0.64 * 0.78 | 0.73 1.11 n/a n/a SingleSource/Benchmarks/Shootout-C++/nestedloop | 0.0128 3388 0.0107 * 0.0108 | 12.04 0.24 0.29 * 0.31 | 50.17 41.52 n/a n/a SingleSource/Benchmarks/Shootout-C++/objinst | 0.0224 6100 0.0213 * 0.0194 | 31.61 30.32 30.26 * 18.12 | 1.04 1.04 n/a n/a SingleSource/Benchmarks/Shootout-C++/random | 0.0092 3012 0.0069 * 0.0067 | 18.35 18.24 7.76 * 7.77 | 1.01 2.36 n/a n/a SingleSource/Benchmarks/Shootout-C++/reversefile | 0.1133 12164 0.0453 * 0.0475 | 0.00 0.00 0.00 * 0.05 | - - n/a n/a SingleSource/Benchmarks/Shootout-C++/sieve | 0.0982 6560 0.0222 * 0.0245 | 4.94 5.76 5.77 * 5.73 | 0.86 0.86 n/a n/a SingleSource/Benchmarks/Shootout-C++/spellcheck | 0.1200 15220 0.0501 * 0.0361 | 0.00 0.00 0.00 * 0.05 | - - n/a n/a SingleSource/Benchmarks/Shootout-C++/strcat | 0.0112 3392 0.0090 * 0.0107 | 0.77 0.75 0.83 * 0.82 | 1.03 0.93 n/a n/a SingleSource/Benchmarks/Shootout-C++/sumcol | 0.0063 3276 0.0073 * 0.0070 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Benchmarks/Shootout-C++/wc | 0.0111 3584 0.0110 * 0.0103 | 0.00 0.00 0.00 * 0.02 | - - n/a n/a SingleSource/Benchmarks/Shootout-C++/wordfreq | 0.2529 24524 0.0968 * 0.0538 | 0.00 0.00 0.00 * 0.07 | - - n/a n/a SingleSource/Benchmarks/Shootout/ackermann | 0.0046 1336 0.0093 * 0.0091 | 0.01 0.01 0.01 * 0.03 | - - n/a n/a SingleSource/Benchmarks/Shootout/ary3 | 0.0050 1128 0.0069 * 0.0068 | 4.87 5.08 4.97 * 5.02 | 0.96 0.98 n/a n/a SingleSource/Benchmarks/Shootout/fib2 | 0.0045 1212 0.0076 * 0.0073 | 10.31 5.99 5.18 * 5.19 | 1.72 1.99 n/a n/a SingleSource/Benchmarks/Shootout/hash | 0.0271 3772 0.0196 * 0.0190 | 9.06 9.04 9.08 * 9.13 | 1.00 1.00 n/a n/a SingleSource/Benchmarks/Shootout/heapsort | 0.0113 2252 0.0112 * 0.0108 | 7.92 18.68 6.24 * 6.18 | 0.42 1.27 n/a n/a SingleSource/Benchmarks/Shootout/hello | 0.0015 536 0.0018 * 0.0019 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Benchmarks/Shootout/lists | 0.0315 4336 0.0200 * 0.0194 | 13.19 13.39 12.08 * 10.82 | 0.99 1.09 n/a n/a SingleSource/Benchmarks/Shootout/matrix | 0.0286 5196 0.0208 * 0.0203 | 6.27 8.60 4.61 * 4.64 | 0.73 1.36 n/a n/a SingleSource/Benchmarks/Shootout/methcall | 0.0126 1864 0.0108 * 0.0106 | 13.00 12.95 8.85 * 8.87 | 1.00 1.47 n/a n/a SingleSource/Benchmarks/Shootout/nestedloop | 0.0087 1300 0.0087 * 0.0084 | 12.98 0.24 0.29 * 0.31 | 54.08 44.76 n/a n/a SingleSource/Benchmarks/Shootout/objinst | 0.0125 2996 0.0185 * 0.0179 | 20.83 21.27 20.08 * 17.86 | 0.98 1.04 n/a n/a SingleSource/Benchmarks/Shootout/random | 0.0046 800 0.0043 * 0.0039 | 13.07 13.08 5.17 * 5.18 | 1.00 2.53 n/a n/a SingleSource/Benchmarks/Shootout/sieve | 0.0056 1184 0.0064 * 0.0058 | 12.70 16.63 12.48 * 12.52 | 0.76 1.02 n/a n/a SingleSource/Benchmarks/Shootout/strcat | 0.0054 1264 0.0072 * 0.0067 | 1.07 1.26 1.06 * 0.98 | 0.85 1.01 n/a n/a SingleSource/Benchmarks/Stanford/Bubblesort | 0.0110 1568 0.0076 * 0.0075 | 0.05 0.06 0.06 * 0.07 | - - n/a n/a SingleSource/Benchmarks/Stanford/IntMM | 0.0164 1608 0.0109 * 0.0106 | 0.00 0.00 0.00 * 0.02 | - - n/a n/a SingleSource/Benchmarks/Stanford/Oscar | 0.0271 3520 0.0216 * 0.0209 | 0.00 0.00 0.00 * 0.03 | - - n/a n/a SingleSource/Benchmarks/Stanford/Perm | 0.0132 3332 0.0167 * 0.0163 | 0.04 0.03 0.04 * 0.06 | - - n/a n/a SingleSource/Benchmarks/Stanford/Puzzle | 0.0710 4936 0.0224 * 0.0219 | 0.23 0.24 0.23 * 0.26 | 0.96 1.00 n/a n/a SingleSource/Benchmarks/Stanford/Queens | 0.0151 1988 0.0136 * 0.0131 | 0.05 0.05 0.06 * 0.08 | - - n/a n/a SingleSource/Benchmarks/Stanford/Quicksort | 0.0128 1984 0.0113 * 0.0108 | 0.07 0.08 0.07 * 0.08 | - - n/a n/a SingleSource/Benchmarks/Stanford/RealMM | 0.0169 1700 0.0117 * 0.0110 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Benchmarks/Stanford/Towers | 0.0189 7272 0.0327 * 0.0318 | 0.02 0.03 0.03 * 0.07 | - - n/a n/a SingleSource/Benchmarks/Stanford/Treesort | 0.0138 2348 0.0124 * 0.0124 | 0.15 0.15 0.15 * 0.18 | 1.00 1.00 n/a n/a SingleSource/Regression/C++/2003-05-14-array-init | 0.0019 528 0.0020 * 0.0020 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/2003-05-14-expr_stmt | 0.0028 456 0.0014 * 0.0013 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/2003-06-08-BaseType | 0.0047 468 0.0015 * 0.0013 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/2003-06-08-VirtualFunctions | 0.0080 592 0.0015 * 0.0015 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/2003-06-13-Crasher | 0.0044 428 0.0013 * 0.0016 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/2003-08-20-EnumSizeProblem | 0.0024 428 0.0015 * 0.0014 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C++/2003-09-29-NonPODsByValue | 0.0064 688 0.0020 * 0.0021 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/BuiltinTypeInfo | 0.0026 700 0.0022 * 0.0022 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C++/EH/ConditionalExpr | 0.0080 1052 0.0053 * 0.0065 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/EH/ctor_dtor_count | 0.0070 992 0.0035 * * | 0.00 * 0.00 * * | n/a - n/a n/a SingleSource/Regression/C++/EH/ctor_dtor_count-2 | 0.0074 2028 * * * | 0.00 * * * * | n/a n/a n/a n/a SingleSource/Regression/C++/EH/dead_try_block | 0.0028 512 0.0019 * 0.0018 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C++/EH/exception_spec_test | 0.0059 2460 0.0140 * * | 0.00 * 0.00 * * | n/a - n/a n/a SingleSource/Regression/C++/EH/function_try_block | 0.0169 3800 0.0218 * * | 0.00 * 0.00 * * | n/a - n/a n/a SingleSource/Regression/C++/EH/simple_rethrow | 0.0065 1436 0.0059 * * | 0.00 * 0.00 * * | n/a - n/a n/a SingleSource/Regression/C++/EH/simple_throw | 0.0034 1004 0.0038 * * | 0.00 * 0.00 * * | n/a - n/a n/a SingleSource/Regression/C++/EH/throw_rethrow_test | 0.0071 2036 0.0104 * * | 0.00 * 0.00 * * | n/a - n/a n/a SingleSource/Regression/C++/global_ctor | 0.0089 1164 0.0060 * 0.0056 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/global_type | 0.0010 428 0.0014 * 0.0014 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/ofstream_ctor | 0.0025 2508 0.0022 * 0.0021 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/pointer_member | 0.0023 556 0.0019 * 0.0019 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C++/pointer_method | 0.0071 1544 0.0068 * 0.0067 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C++/short_circuit_dtor | 0.0077 768 0.0022 * 0.0022 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/2003-05-14-initialize-string | 0.0013 620 0.0022 * 0.0021 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/2003-05-21-BitfieldHandling | 0.0020 572 0.0018 * 0.0013 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/2003-05-21-UnionBitfields | 0.0037 532 0.0019 * 0.0019 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/2003-05-21-UnionTest | 0.0031 772 0.0025 * 0.0023 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/2003-05-22-LocalTypeTest | 0.0017 576 0.0019 * 0.0018 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/2003-05-22-VarSizeArray | 0.0025 528 0.0020 * 0.0018 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/2003-05-23-TransparentUnion | 0.0059 524 0.0021 * 0.0017 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/2003-06-16-InvalidInitializer | 0.0012 428 0.0014 * 0.0013 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/2003-06-16-VolatileError | 0.0015 428 0.0013 * 0.0013 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/2003-10-12-GlobalVarInitializers | 0.0021 620 0.0021 * 0.0021 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/2004-02-03-AggregateCopy | 0.0018 540 0.0020 * 0.0019 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/2004-03-15-IndirectGoto | 0.0035 840 0.0047 * 0.0046 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/2004-08-12-InlinerAndAllocas | 0.0043 852 0.0041 * 0.0038 | 0.00 0.01 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/2005-05-06-LongLongSignedShift | 0.0017 572 0.0023 * 0.0023 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/2008-01-07-LongDouble | 0.0016 548 0.0021 * 0.0020 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/ConstructorDestructorAttributes | 0.0021 712 0.0037 * 0.0035 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/DuffsDevice | 0.0098 1328 0.0049 * 0.0047 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/PR1386 | 0.0029 820 0.0030 * 0.0029 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/PR491 | 0.0041 532 0.0014 * 0.0014 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/PR640 | 0.0083 1464 0.0068 * 0.0066 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/badidx | 0.0034 848 0.0043 * 0.0041 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/bigstack | 0.0172 3328 0.0153 * 0.0147 | 0.00 0.00 0.00 * 0.02 | - - n/a n/a SingleSource/Regression/C/callargs | 0.0031 884 0.0035 * 0.0034 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/casts | 0.0078 4252 0.0194 * 0.0190 | 0.00 0.00 0.00 * 0.02 | - - n/a n/a SingleSource/Regression/C/globalrefs | 0.0035 1008 0.0042 * 0.0040 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/matrixTranspose | 0.0103 1356 0.0069 * 0.0067 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/pointer_arithmetic | 0.0038 460 0.0014 * 0.0014 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/sumarray | 0.0067 892 0.0045 * 0.0044 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/sumarray2d | 0.0100 1060 0.0059 * 0.0059 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/sumarraymalloc | 0.0102 1052 0.0057 * 0.0056 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/Regression/C/test_indvars | 0.0125 1448 0.0076 * 0.0074 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/Regression/C/testtrace | 0.0076 1256 0.0056 * 0.0054 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2002-04-17-PrintfChar | 0.0027 540 0.0020 * 0.0020 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2002-05-02-ArgumentTest | 0.0024 596 0.0022 * 0.0021 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2002-05-02-CastTest | 0.0039 1580 0.0080 * 0.0077 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2002-05-02-CastTest1 | 0.0016 552 0.0020 * 0.0020 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2002-05-02-CastTest2 | 0.0018 652 0.0029 * 0.0028 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2002-05-02-CastTest3 | 0.0023 660 0.0029 * 0.0027 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2002-05-02-ManyArguments | 0.0026 660 0.0026 * 0.0023 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2002-05-03-NotTest | 0.0039 624 0.0023 * 0.0023 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2002-05-19-DivTest | 0.0038 720 0.0043 * 0.0041 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2002-08-02-CastTest | 0.0029 532 0.0020 * 0.0019 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2002-08-02-CastTest2 | 0.0027 572 0.0024 * 0.0021 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2002-08-19-CodegenBug | 0.0027 528 0.0019 * 0.0019 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2002-10-09-ArrayResolution | 0.0027 596 0.0025 * 0.0024 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2002-10-12-StructureArgs | 0.0035 988 0.0031 * 0.0029 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2002-10-12-StructureArgsSimple | 0.0027 768 0.0024 * 0.0024 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2002-10-13-BadLoad | 0.0027 532 0.0023 * 0.0019 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2002-12-13-MishaTest | 0.0047 540 0.0020 * 0.0019 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2003-04-22-Switch | 0.0039 768 0.0045 * 0.0045 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-05-02-DependentPHI | 0.0030 816 0.0032 * 0.0031 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-05-07-VarArgs | 0.0086 2820 0.0128 * 0.0119 | 0.00 0.00 0.00 * 0.02 | - - n/a n/a SingleSource/UnitTests/2003-05-12-MinIntProblem | 0.0045 532 0.0019 * 0.0019 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-05-14-AtExit | 0.0028 656 0.0034 * 0.0032 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-05-26-Shorts | 0.0051 2016 0.0078 * 0.0079 | 0.00 0.00 0.00 * 0.02 | - - n/a n/a SingleSource/UnitTests/2003-05-31-CastToBool | 0.0077 1056 0.0065 * 0.0064 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-05-31-LongShifts | 0.0049 936 0.0054 * 0.0052 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-07-06-IntOverflow | 0.0062 792 0.0026 * 0.0025 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2003-07-08-BitOpsTest | 0.0031 548 0.0020 * 0.0020 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2003-07-09-LoadShorts | 0.0041 1508 0.0059 * 0.0058 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2003-07-09-SignedArgs | 0.0073 1248 0.0056 * 0.0054 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-07-10-SignConversions | 0.0031 756 0.0027 * 0.0028 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-08-05-CastFPToUint | 0.0040 664 0.0025 * 0.0023 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2003-08-11-VaListArg | 0.0108 3092 0.0166 * 0.0157 | 0.00 0.00 0.00 * 0.02 | - - n/a n/a SingleSource/UnitTests/2003-08-20-FoldBug | 0.0029 528 0.0019 * 0.0018 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-09-18-BitFieldTest | 0.0022 568 0.0020 * 0.0018 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2003-10-13-SwitchTest | 0.0021 596 0.0027 * 0.0027 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2003-10-29-ScalarReplBug | 0.0035 532 0.0019 * 0.0021 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2004-02-02-NegativeZero | 0.0026 616 0.0027 * 0.0026 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2004-06-20-StaticBitfieldInit | 0.0023 572 0.0020 * 0.0020 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2004-11-28-GlobalBoolLayout | 0.0025 856 0.0032 * 0.0031 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2005-05-11-Popcount-ffs-fls | 0.0213 3084 0.0137 * 0.0131 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2005-05-12-Int64ToFP | 0.0024 656 0.0042 * 0.0038 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2005-05-13-SDivTwo | 0.0031 628 0.0029 * 0.0027 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2005-07-15-Bitfield-ABI | 0.0030 556 0.0019 * 0.0018 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2005-07-17-INT-To-FP | 0.0038 976 0.0064 * 0.0060 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2005-11-29-LongSwitch | 0.0040 532 0.0019 * 0.0019 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2006-01-23-InitializedBitField | 0.0097 5560 0.0069 * 0.0067 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2006-01-23-UnionInit | 0.0080 2016 0.0059 * 0.0055 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2006-01-29-SimpleIndirectCall | 0.0032 748 0.0043 * 0.0029 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2006-02-04-DivRem | 0.0039 696 0.0035 * 0.0033 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2006-12-01-float_varg | 0.0015 600 0.0025 * 0.0022 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2006-12-04-DynAllocAndRestore | 0.0057 656 0.0027 * 0.0025 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2006-12-07-Compare64BitConstant | 0.0023 540 0.0018 * 0.0020 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2006-12-11-LoadConstants | 0.1270 3848 0.0452 * 0.0452 | 0.00 0.00 0.00 * 0.05 | - - n/a n/a SingleSource/UnitTests/2007-01-04-KNR-Args | 0.0037 616 0.0032 * 0.0028 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2007-03-02-VaCopy | 0.0036 800 0.0034 * 0.0032 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/2007-04-10-BitfieldTest | 0.0018 548 0.0021 * 0.0019 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/2007-04-25-weak | 0.0019 516 0.0021 * * | 0.00 0.00 0.00 * * | - - n/a n/a SingleSource/UnitTests/FloatPrecision | 0.0028 572 0.0022 * 0.0021 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/SignlessTypes/cast | 0.0148 3064 0.0428 * 0.0421 | 0.03 0.03 0.03 * 0.08 | - - n/a n/a SingleSource/UnitTests/SignlessTypes/cast-bug | 0.0030 628 0.0029 * 0.0029 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/SignlessTypes/cast2 | 0.0033 528 0.0019 * 0.0019 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/SignlessTypes/ccc | 0.0041 696 0.0028 * 0.0031 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/SignlessTypes/div | 0.0278 1328 0.0053 * 0.0051 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/SignlessTypes/factor | 0.0079 1172 0.0063 * 0.0061 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/SignlessTypes/rem | 0.0587 13088 0.1490 * 0.1455 | 0.00 0.00 0.00 * 0.15 | - - n/a n/a SingleSource/UnitTests/SignlessTypes/shr | 0.0182 1436 0.0051 * 0.0050 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/StructModifyTest | 0.0029 668 0.0027 * 0.0026 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a SingleSource/UnitTests/TestLoop | 0.0051 684 0.0036 * 0.0034 | 0.00 0.00 0.00 * 0.01 | - - n/a n/a SingleSource/UnitTests/Threads/tls | 0.0021 888 0.0044 * * | 0.00 0.00 0.00 * * | - - n/a n/a SingleSource/UnitTests/Vector/SSE/sse.expandfft | 0.0402 8592 * * * | 1.50 * * * * | n/a n/a n/a n/a SingleSource/UnitTests/Vector/SSE/sse.isamax | 0.0172 3560 0.0148 * 0.0141 | 0.00 * 0.00 * 0.02 | n/a - n/a n/a SingleSource/UnitTests/Vector/SSE/sse.stepfft | 0.0449 8264 * * * | 1.84 * * * * | n/a n/a n/a n/a SingleSource/UnitTests/Vector/build | 0.0034 1008 * * * | 0.00 * * * * | n/a n/a n/a n/a SingleSource/UnitTests/Vector/build2 | 0.0134 1572 * * * | 0.00 * * * * | n/a n/a n/a n/a SingleSource/UnitTests/Vector/divides | 0.0052 1328 0.0054 * 0.0050 | 0.00 * 0.00 * 0.01 | n/a - n/a n/a SingleSource/UnitTests/Vector/multiplies | 0.0139 2152 * * * | 0.00 * * * * | n/a n/a n/a n/a SingleSource/UnitTests/Vector/simple | 0.0080 2072 * * * | 0.00 * * * * | n/a n/a n/a n/a SingleSource/UnitTests/Vector/sumarray | 0.0054 992 * * * | 0.00 * * * * | n/a n/a n/a n/a SingleSource/UnitTests/Vector/sumarray-dbl | 0.0057 1064 * * * | 0.00 * * * * | n/a n/a n/a n/a SingleSource/UnitTests/printargs | 0.0032 724 0.0036 * 0.0035 | 0.00 0.00 0.00 * 0.00 | - - n/a n/a From sabre at nondot.org Sun Feb 3 02:02:35 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 3 Feb 2008 00:02:35 -0800 Subject: [LLVMdev] 2.2 Prerelease available for testing In-Reply-To: <20080203074946.GA47549@dmr.ath.cx> References: <20080203074946.GA47549@dmr.ath.cx> Message-ID: <8142930F-1FA8-4527-8EBA-AF5F20ACA4BC@nondot.org> On Feb 2, 2008, at 11:49 PM, Emil Mikulic wrote: > The llvm-test nightly report is attached. > I had to manually kill tramp3d-v4.native after ~1hr of CPU time. FWIW, I think it makes sense to remove tramp3d-v4 from the 2.2 branch. -Chris From emikulic at gmail.com Sun Feb 3 02:56:31 2008 From: emikulic at gmail.com (Emil Mikulic) Date: Sun, 3 Feb 2008 19:56:31 +1100 Subject: [LLVMdev] 2.2 Prerelease available for testing In-Reply-To: <89158DF8-AB2D-49AD-BF32-0825F4EEF91E@nondot.org> References: <20080128031251.GA16012@dmr.ath.cx> <89158DF8-AB2D-49AD-BF32-0825F4EEF91E@nondot.org> Message-ID: <20080203085631.GA10497@dmr.ath.cx> On Tue, Jan 29, 2008 at 09:17:37PM -0800, Tanya Lattner wrote: > Can you bugpoint MultiSource/Benchmarks/MiBench/security-rijndael/ > security-rijndael? > % cd MultiSource/Benchmarks/MiBench/security-rijndael/security-rijndael > % make bugpoint-llc Apparently not. =( bugpoint tries to create a shared object, which isn't working on amd64. --Emil From wmatyjewicz at fastmail.fm Sun Feb 3 12:33:34 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Sun, 03 Feb 2008 19:33:34 +0100 Subject: [LLVMdev] Question to Chris In-Reply-To: <01BD4596-802C-4FED-8195-95A722A68E2F@nondot.org> References: <20080202015146.BBC09843@expms2.cites.uiuc.edu> <01BD4596-802C-4FED-8195-95A722A68E2F@nondot.org> Message-ID: <47A608FE.6050700@fastmail.fm> Seung, > 3) The way you are converting out of SSA is wrong. You will suffer > from lost copies. You should look at using demotePHI(). see include/ > llvm/Transforms/Utils/Local.h Using demotePHI() to remove PHI nodes should be the easiest way. However, if you want to keep values in registers, you must take into account the problem mentioned above, and also the "swap problem". You might take a look at this article, for example: http://www.cs.ucsb.edu/~ckrintz/papers/spe98-ssaconstruct-deconstruct.pdf.gz to see when these problems appear and how to deal with them. If you address these issues, I think, your algorithm to remove PHI nodes should be okay. -Wojtek From wmatyjewicz at fastmail.fm Sun Feb 3 13:54:24 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Sun, 03 Feb 2008 20:54:24 +0100 Subject: [LLVMdev] Question to Chris In-Reply-To: <20080202015146.BBC09843@expms2.cites.uiuc.edu> References: <20080202015146.BBC09843@expms2.cites.uiuc.edu> Message-ID: <47A61BF0.6010600@fastmail.fm> Seung, > Would you please explain to me how I can access to this problem in a better way if you can figure out? Here are my thoughts on your first question: "how to make it count correctly for the reconstruction of loops?". I believe it can't be done for an arbitrary loop. However, IIRC from previous posts your loops are simple - for example: they don't contain any breaks, gotos. I think, your reconstruction could be done for two forms of loops that are very common: 1) rotated canonical loop (bb8.outer in your example): The loop has only one backedge, and an induction variable counting from 0 with step 1. The only basic block that branches out of the loop (so called, exiting block) is the backedge. header: %i = phi [ 0, %preheader ], [ %i.next, %body ] ... br label %body ;%header and %body may be the same block body: ... %i.next = add %i, 1 %c = seteq %i.next, %n br %c, label %exit, label %header exit: ... The loop iteration count is %n. In this case, it means that _every_ basic block is executed %n times. Your current version of reconstruction seems to be okay for loops in this form. 2) unrotated canonical loop (bb8 in your example): The loop has only one backedge and an induction variable counting from 0 with step 1. The only basic block that branches out of the loop is the loop header. header: %i = phi [ 0, %preheader ], [ %i.next, %body ] ... %c = seteq %i, %n br %c, label %exit, label %body body: ... %i.next = add %i, 1 br label %header exit: ... The loop iteration count is also %n. However, this time it means that the loop header is executed %n times, while the rest of blocks - %n-1 times. The reconstruction should take it into account. For example, it could make a "for" loop from all loop basic blocks setting the iteration count to %n-1, and then insert a copy of the loop header with %i==%n after the "for". I also suggest taking look at the LoopInfo pass. It has many useful methods to analyze loops. To determine the loop iteration count you may use the ScalarEvolution pass as well. -Wojtek From christopher.lamb at gmail.com Sun Feb 3 20:39:25 2008 From: christopher.lamb at gmail.com (Christopher Lamb) Date: Sun, 3 Feb 2008 18:39:25 -0800 Subject: [LLVMdev] C embedded extensions and LLVM In-Reply-To: References: <81191030-97C7-4C88-886B-97B2FEF2F526@gmail.com><2599E358-427A-419A-9F60-88F535FA12F7@nondot.org><35B66ACF-FF27-4614-91EC-ADABD9002A1B@gmail.com> <9A4DD193-F800-470C-B453-816114933F14@gmail.com> Message-ID: <40C8CA86-0E4C-46EE-A941-AD344F3C4450@gmail.com> On Feb 1, 2008, at 9:28 AM, wrote: > Christopher, > > Thank you for all the work J > I'm glad you're finding it useful. > Regarding the regression testing, it is in our plan to contribute > into LLVM. The current state of our project is not in the form that > we can do this at this time though, but I?m hoping that we can get > some minimal functionality into LLVM before LLVM 2.3 (at most LLVM > 2.4) release. > Sounds good! > Looks like you have also (at least on your local project) taken > care of the front-end. We are currently working on normal address > space, but probably in the next month we will start working on the > support for rom access. So the front-end modifications are not > necessary right away but it?d be nice to have them before that time. > I've just submitted my modifications to clang to support address space qualifiers. The work is rather experimental at the moment, but hopefully you will find it a useful starting point. > In the mean time, I will take a look and try to understand your > modifications, and I?m sure that I?ll be back with some questions. > > > Regards > > A. > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of Christopher Lamb > Sent: Wednesday, January 30, 2008 10:59 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] C embedded extensions and LLVM > > > Alireza, > > > I have added full support for embedded C address spaces to the LLVM > IR (see http://llvm.org/docs/LangRef.html#t_pointer). I have not > added any support for the fractional types and their operators, > though I think this would simply require adding the necessary > intrinsics, which is one of the easier things to add to LLVM. Given > that LLVM takes the approach of modeling these kinds of type > differences as differing operations rather than different types in > it's type system it should be fairly straight forward to add them > if needed. > > > As far as front-end support goes, I do have changes to my local > clang tree which add attributes for address spaces which have been > working for my purposes. However since my initial work my free time > has become more scarce and I haven't had the opportunity to clean > up the patches and submit them back to the tree. > > > The lack of a public back end with which to consume the generated > IR with embedded C extensions and validate the front end is also a > problem. Without such a platform it will be difficult for the LLVM > project to guarantee that the functionality stays working going > forward. > > > Do you mind sharing more details about your project, particularly > how soon you need the front end support and if you would be able to > provide a way (ideally contributed back to LLVM) to regress these > features going forward? > > > -- > > Christopher Lamb > > > On Jan 30, 2008, at 9:53 AM, > wrote: > > > > > Thank you Chris, > > That is great news... > > So his modifications are in llvm-2.2? > > How has Christopher tested them? Are there attributes or intrinsics > that > > I can also use? > > > A. > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > > On Behalf Of Chris Lattner > > Sent: Tuesday, January 29, 2008 9:23 PM > > To: LLVM Developers Mailing List > > Subject: Re: [LLVMdev] C embedded extensions and LLVM > > > On Jan 29, 2008, at 9:56 AM, > > >> wrote: >> >> Christopher, >> >> It has been a while since we last talked about C embedded extensions >> >> in >> >> LLVM, I was moving back and froth from project to project and didn't >> >> get >> >> a chance to follow up. I was wondering if you have made any >> changes to >> >> LLVM IR and if so what has been added. And how can I contribute? >> > > My understanding is that Christopher's patches have all landed in > > llvm, so the IR is capable of capturing and propagating the address > > space information. However, we have no front-end that correctly > > generates this. My understanding is that Christopher has patches in > > progress to add this to clang, but I'm not sure what the state of > > these is. It would be great to get have help getting this into clang. > > > -Chris > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080203/2f1f4d26/attachment-0001.html From ramon.garcia.f+llvm at gmail.com Sun Feb 3 21:09:55 2008 From: ramon.garcia.f+llvm at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Mon, 4 Feb 2008 04:09:55 +0100 Subject: [LLVMdev] Introducing myself, and Java project. In-Reply-To: References: Message-ID: I have just worked with this code. The architecture is fine, and I think that this code should be reused, It needs updating, however, because it does not compile with LLVM 2.1 (I prefer to use a stable version to focus my work, and port to LLVM 2.2 later). I have seen that one incompatibility is that this Java frontend requires C++ with exceptions, but LLVM is compiled with -fno-exceptions. For now, I am compiling with -fexceptions. Should exceptions be removed from the code of the Java frontend? Then, I have doubts about whether the changes for getting it built are correct or not. I will make more questions later. This could be a work plan: * Getting the java frontend built. * Implement exception handling (jsr/ret bytecodes) * Implement garbage collection. * Support JAR files. This should get an usable Java implementation. But there is still very hard work to be done. The difficult part is dynamic class loading, reflection and creation of classloaders. This would enable to use LLVM for Java server applications such as Tomcat or JBoss. I am not sure if this work is possible without funding a full time position. Just some questions to think about it. To what extent does LLVM support dynamic code loading? Is it posible to get code loaded at runtime? Could this break assumptions made by interprocedural optimization? (A function may be called in unexpected ways) Another difficult part is optimization. In order to get good performance, references should be converted to values whenever possible. Recent virtual machines support scape analysis, so that local references can be converted into values, and be stored and released in the stack. This should be generalized to references that are class members. Java code is particular hard to optimize because any function call is a virtual function call. Is inlining posible? Only if one makes assumptions about any code using some class, that no other class is going to override the called method. Programmers could declare methods final, but this is rarely done. Assumptions may be checked for all loaded classes, but, for classes not yet loaded (and which may be loaded dynamically), who nows? But this is for very long term feature. For now, let us have fun completing the doable parts. Best regards, Ramon From ted at tedneward.com Mon Feb 4 02:00:15 2008 From: ted at tedneward.com (Ted Neward) Date: Mon, 4 Feb 2008 00:00:15 -0800 Subject: [LLVMdev] Introducing myself, and Java project. In-Reply-To: References: Message-ID: <033b01c86703$fdba31a0$f92e94e0$@com> You probably want to sit down and have a long talk with Jeroen Frijters, the principal behind the IKVM project. Note that you will have to deal with ClassLoaders at some level, regardless of what you'd prefer. > A more obvious problem is, of course, that it is not possible to > compile Java code statically and save the result in the disk. > That is untrue--last time I checked, gcj does this out of the box. Several other tools used to (TowerJ, I think its name was), but the demand for this turned out to be nil and they folded. Most of Java's appeal lies in its ability to dynamically link libraries. And quite frankly, the overhead of passing native data across that JNI boundary is generally pretty tiny, unless you do some truly idiotic things in either your Java or your JNI/C++ code. I still wouldn't want to do it in a tight loop, mind you, but it's generally not more than a handful of assembly instructions. (This is what I've been told, anyway--I haven't pored over the OpenJDK sources to find the actual code that does the translation.) Having said that, I think a JVM->LLVM bytecode converter is a really cool idea. But I think you're ultimately going to come to the same decision IKVM did, which is to support ClassLoading as well as static loading. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Ram?n Garc?a > Sent: Saturday, February 02, 2008 5:48 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] Introducing myself, and Java project. > > Hello, I am Ramon Garcia Fernandez. My interest in LLVM is to develop > an interface for Java virtual machine bytecodes, so that Java programs > can be run under LLVM. > > You may ask why not using the Java virtual machine. Although it may be > improved, there are some misfeatures in it. This is what I have > learned. It makes the communication with native code too expensive. > Passing an array from native to the virtual machine or vice versa > requires a copy of the data. Why? you may ask. Because Java uses > garbage collectors based on copying. Thus the position of an object > may be moved by the virtual machine. The implementation of > generational garbage collection in Java uses areas of memory for each > generation, so that when an object changes from the young generation > to the old its storage must be moved. This may give some performance > advantage, by making young objects close in memory, but with the cost > of making exchange of data with native code expensive. In particular, > data copying is required for reading and writing files, sending or > receiving data from the network, or drawing. Since Java is not often > used for numerical analysis or tasks that require little data exchange > with the outside world, I disagree that the implementation with a > copying collector is good for most applications. > > A more obvious problem is, of course, that it is not possible to > compile Java code statically and save the result in the disk. > > So I am starting to write a compiler of Java bytecode to LLVM > bytecode. For now I am designing, dealing with things such as how to > assign stack positions to the operands of each instruction. > > My target is to deliver something simple. Operations such as > classloader creation and dynamic class loading will not be supported. > > Hoping that this is the start of a long term cooperation, > > Ramon > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: > 2/2/2008 1:50 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: 2/2/2008 1:50 PM From penberg at cs.helsinki.fi Mon Feb 4 02:13:53 2008 From: penberg at cs.helsinki.fi (Pekka Enberg) Date: Mon, 4 Feb 2008 10:13:53 +0200 Subject: [LLVMdev] Introducing myself, and Java project. In-Reply-To: References: Message-ID: <84144f020802040013w39939a77t7a00e52552c63232@mail.gmail.com> Hi Ramon, On Feb 4, 2008 5:09 AM, Ram?n Garc?a wrote: > Java code is particular hard to optimize because any function call is > a virtual function call. Is inlining posible? It's possible if you do "method devirtualization" optimization first. No idea if LLVM supports that, though. Pekka From tonic at nondot.org Mon Feb 4 02:17:49 2008 From: tonic at nondot.org (Tanya Lattner) Date: Mon, 4 Feb 2008 00:17:49 -0800 Subject: [LLVMdev] Introducing myself, and Java project. In-Reply-To: References: Message-ID: <034E644C-4D85-481E-BC8D-FF85C9BD5225@nondot.org> On Feb 3, 2008, at 7:09 PM, Ram?n Garc?a wrote: > I have just worked with this code. The architecture is fine, and I > think that this code should be reused, > It needs updating, however, because it does not compile with LLVM 2.1 > (I prefer to use a stable version > to focus my work, and port to LLVM 2.2 later). > LLVM 2.2 comes out in a week, I would recommend using that over 2.1 if you must use a release. You can use the pre-releases to get started. However, if you are going to be actively developing you should use llvm svn. -Tanya > I have seen that one incompatibility is that this Java frontend > requires C++ with exceptions, but LLVM is compiled with > -fno-exceptions. For now, I am compiling with -fexceptions. Should > exceptions be removed from the code of the Java frontend? > > Then, I have doubts about whether the changes for getting it built are > correct or not. I will make more questions later. > > This could be a work plan: > > * Getting the java frontend built. > > * Implement exception handling (jsr/ret bytecodes) > > * Implement garbage collection. > > * Support JAR files. > > This should get an usable Java implementation. But there is still very > hard work to be done. The difficult part is dynamic class loading, > reflection and creation of classloaders. This would enable to use LLVM > for Java server applications such as Tomcat or JBoss. I am not sure if > this work is possible without funding a full time position. Just some > questions to think about it. To what extent does LLVM support dynamic > code loading? Is it posible to get code loaded at runtime? Could this > break assumptions made by interprocedural optimization? (A function > may be called in unexpected ways) > > Another difficult part is optimization. In order to get good > performance, references should be converted to values whenever > possible. Recent virtual machines support scape analysis, so that > local references can be converted into values, and be stored and > released in the stack. This should be generalized to references that > are class members. > > Java code is particular hard to optimize because any function call is > a virtual function call. Is inlining posible? Only if one makes > assumptions about any code using some class, that no other class is > going to override the called method. Programmers could declare methods > final, but this is rarely done. Assumptions may be checked for all > loaded classes, but, for classes not yet loaded (and which may be > loaded dynamically), who nows? > > But this is for very long term feature. For now, let us have fun > completing the doable parts. > > Best regards, > > Ramon > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From arvind.ayyangar at gmail.com Mon Feb 4 04:09:37 2008 From: arvind.ayyangar at gmail.com (Arvind Ayyangar) Date: Mon, 4 Feb 2008 15:39:37 +0530 Subject: [LLVMdev] llc fails to generate code for arm In-Reply-To: <9c10c9f0801280648l73151c66mac83dc1550703e5a@mail.gmail.com> References: <9c10c9f0801280648l73151c66mac83dc1550703e5a@mail.gmail.com> Message-ID: Hi Sorry for the late reply.. I managed to build the latest release of llvm. Now I get the following error when I try creating the bitcode file: llvm-gcc: --emit-llvm is not supported in this configuration. The configure options were : /home/arvind/llvm/llvm-gcc4.2-2.1.source/configure --prefix=/opt/llvm/ --enable-threads --disable-nls --disable-shared --enable-languages=c --enable-sjlj-exceptions --program-prefix=llvm- On Jan 28, 2008 8:18 PM, Lauro Ramos Venancio wrote: > HI Arvind, > > I think you are using an old llc version. VarArg support was > implemented a long time ago. > > Lauro > > 2008/1/28, Arvind Ayyangar : > > > Hi all, > > I had little success installing llvm inside scratchbox for an ARM > > build so have been trying to generate assembly code for arm using the > > llc utility. However, llc fails to generate code for arm. Output is as > > below... > > > > > > arvind at zeus:~/tools/llvm/del$ llc main.bc -o mainarm -filetype=asm > > -march=arm -f > > llc: ARMISelDAGToDAG.cpp:73: llvm::SDOperand > > LowerCALL(llvm::SDOperand, llvm::SelectionDAG&): Assertion `isVarArg > > == false && "VarArg not supported"' failed. > > llc[0x85335ac] > > [0xffffe420] > > [0xffffe410] > > /lib/tls/i686/cmov/libc.so.6(gsignal+0x50)[0xb7d5bdf0] > > /lib/tls/i686/cmov/libc.so.6(abort+0x101)[0xb7d5d641] > > /lib/tls/i686/cmov/libc.so.6(__assert_fail+0xfb)[0xb7d5543b] > > llc[0x82aaeed] > > Aborted (core dumped) > > arvind at zeus:~/tools/llvm/del$ > > > > However, i manage to generate code for other architectures like sparc, > > ppc, etc.. Is any additional setup required ? > > > > > > Thanks in advance > > > > > > -- > > Arvind > > _______________________________________________ > > 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 > -- Cheers Arvind From baldrick at free.fr Mon Feb 4 05:15:23 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 4 Feb 2008 12:15:23 +0100 Subject: [LLVMdev] llc fails to generate code for arm In-Reply-To: References: <9c10c9f0801280648l73151c66mac83dc1550703e5a@mail.gmail.com> Message-ID: <200802041215.26119.baldrick@free.fr> Hi, > Now I get the following error when I try creating the bitcode file: > > llvm-gcc: --emit-llvm is not supported in this configuration. > > The configure options were : > /home/arvind/llvm/llvm-gcc4.2-2.1.source/configure > --prefix=/opt/llvm/ --enable-threads --disable-nls --disable-shared > --enable-languages=c --enable-sjlj-exceptions --program-prefix=llvm- you forgot --enable-llvm=path_to_llvm_objects Ciao, Duncan. From ramon.garcia.f at gmail.com Mon Feb 4 10:37:51 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Mon, 4 Feb 2008 17:37:51 +0100 Subject: [LLVMdev] Introducing myself, and Java project. In-Reply-To: <033b01c86703$fdba31a0$f92e94e0$@com> References: <033b01c86703$fdba31a0$f92e94e0$@com> Message-ID: Sorry for the confusion about the JNI overhead, perhaps I wasn't clear. The big overhead of calling JNI happens if one passes an array because in this case data must be copied (the JNI interface allows the implementation to choose, but the current JDK implementation always copies data). This mean that for a Java application to read data from a file, to fetch bytes from a network connection, or to paint a bitmap in the screen, data must be first copied from virtual machine memory to native memory, and then the operation is done. The reason is that the implementation of garbage collection which copies objects, and thus native code cannot assume that the memory position of an object or array is fixed. See, for instance, the specification of GetArrayElements, http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/functions.html#wp17382 The interface allows the virtual machine implementation to copy or not, but the current implementation always copies array data. Ramon > And quite frankly, the overhead of passing native data across that JNI > boundary is generally pretty tiny, unless you do some truly idiotic things > in either your Java or your JNI/C++ code. I still wouldn't want to do it in > a tight loop, mind you, but it's generally not more than a handful of > assembly instructions. (This is what I've been told, anyway--I haven't pored > over the OpenJDK sources to find the actual code that does the translation.) > > Having said that, I think a JVM->LLVM bytecode converter is a really cool > idea. But I think you're ultimately going to come to the same decision IKVM > did, which is to support ClassLoading as well as static loading. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > > On Behalf Of Ram?n Garc?a > > Sent: Saturday, February 02, 2008 5:48 PM > > To: llvmdev at cs.uiuc.edu > > Subject: [LLVMdev] Introducing myself, and Java project. > > > > Hello, I am Ramon Garcia Fernandez. My interest in LLVM is to develop > > an interface for Java virtual machine bytecodes, so that Java programs > > can be run under LLVM. > > > > You may ask why not using the Java virtual machine. Although it may be > > improved, there are some misfeatures in it. This is what I have > > learned. It makes the communication with native code too expensive. > > Passing an array from native to the virtual machine or vice versa > > requires a copy of the data. Why? you may ask. Because Java uses > > garbage collectors based on copying. Thus the position of an object > > may be moved by the virtual machine. The implementation of > > generational garbage collection in Java uses areas of memory for each > > generation, so that when an object changes from the young generation > > to the old its storage must be moved. This may give some performance > > advantage, by making young objects close in memory, but with the cost > > of making exchange of data with native code expensive. In particular, > > data copying is required for reading and writing files, sending or > > receiving data from the network, or drawing. Since Java is not often > > used for numerical analysis or tasks that require little data exchange > > with the outside world, I disagree that the implementation with a > > copying collector is good for most applications. > > > > A more obvious problem is, of course, that it is not possible to > > compile Java code statically and save the result in the disk. > > > > So I am starting to write a compiler of Java bytecode to LLVM > > bytecode. For now I am designing, dealing with things such as how to > > assign stack positions to the operands of each instruction. > > > > My target is to deliver something simple. Operations such as > > classloader creation and dynamic class loading will not be supported. > > > > Hoping that this is the start of a long term cooperation, > > > > Ramon > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: > > 2/2/2008 1:50 PM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: 2/2/2008 > 1:50 PM > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From 3.14159 at gmx.net Mon Feb 4 11:20:31 2008 From: 3.14159 at gmx.net (thomas weidner) Date: Mon, 04 Feb 2008 18:20:31 +0100 Subject: [LLVMdev] 2.2 garbage collector questions Message-ID: Hello, i want to implement a common lisp subset using llvm for fun. This requires the use of a garbage collector. I read the docs, but many things are still unclear to me. 1. how are collectors supposed to find all living objects? there is llvm.gcroot for marking objects on the stack,but how do collectors crawl heap objects? I did not see a way to provide custom mark functions. Are collectors supposed to rely on the type informations provided by llvm? 2. what about gcreading and gcwriting objects of a different type than i8*? 3. No Intrinsic for allocating gc memory? 4. When passing a gc managed pointer to a c function,how should that function access the pointer? directly? there seem to be functions for that in the runtime/ source directory,but it also seems to be meant for the llvm c frontend? (and not for use in an extra c library) 5. some collectors update pointers upon read/write access, can the llvm gc api provide this? sorry for so many questions (and sorry if some of them may be stupid). thanks in advance for help. thomas From dag at cray.com Mon Feb 4 11:31:28 2008 From: dag at cray.com (David Greene) Date: Mon, 4 Feb 2008 11:31:28 -0600 Subject: [LLVMdev] RFC: GLIBCXX_DEBUG ScheduleDAG Patch In-Reply-To: <200801211041.01832.dag@cray.com> References: <200712171217.52176.dag@cray.com> <200801211041.01832.dag@cray.com> Message-ID: <200802041131.28740.dag@cray.com> On Monday 21 January 2008 10:41, David Greene wrote: > > >> Can you clarify? Is this 1.7% slowdown of scheduling time or overall > > >> codegen time? If it's the later, then it seems a bit too much. Also, > > >> please test it with all the MultiSource/Applications. > > > > > > It's 1.7% overall. > > > > That seems somewhat steep. Can you see how much of the scheduling > > slow down there is? > > I got some times from the nightly report, so this is overall compile time. > > The worst slowdown is on timberwolfmc "llc compile" which has a 5% > slowdown. The JIT slows down 6%. > > Everything else looks to be 1% or less. In some cases the times with > the change are better, probably because this change gets rid of the "pop > everything off and push it back on" way of recreating the heap.[ Just want to send a ping on this. This patch is still waiting to go in. Is the compile time hit too much? Note that sometimes compile time improves with this patch. I'd like to get this in ASAP so I can start merging other things back to upstream. -Dave From ramon.garcia.f at gmail.com Mon Feb 4 11:10:05 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Mon, 4 Feb 2008 18:10:05 +0100 Subject: [LLVMdev] Introducing myself, and Java project. In-Reply-To: <034E644C-4D85-481E-BC8D-FF85C9BD5225@nondot.org> References: <034E644C-4D85-481E-BC8D-FF85C9BD5225@nondot.org> Message-ID: Thanks. I have just downloaded LLVM tag release 2.2. From time to time, I will try working with SVN trunk release. But please understand that I would rather avoid fighting with compilation problems or temporary bugs that would distract me. > LLVM 2.2 comes out in a week, I would recommend using that over 2.1 > if you must use a release. You can use the pre-releases to get > started. However, if you are going to be actively developing you > should use llvm svn. > > -Tanya > From gordonhenriksen at mac.com Mon Feb 4 12:13:54 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Mon, 4 Feb 2008 13:13:54 -0500 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: References: Message-ID: Hi Thomas, On Feb 4, 2008, at 12:20, thomas weidner wrote: > i want to implement a common lisp subset using llvm for fun. Welcome! > This requires the use of a garbage collector. I read the docs, but > many things are still unclear to me. One of the important things to recognize about LLVM's GC support is that it only provides facilities which must be provided by the compiler back end. There are many other necessary facilities which must be provided by a complete language implementation. For the parts of the system where it doesn't need to be involved, LLVM simply gets out of your way. > 1. how are collectors supposed to find all living objects? there is > llvm.gcroot for marking objects on the stack,but how do collectors > crawl heap objects? I did not see a way to provide custom mark > functions. Are collectors supposed to rely on the type informations > provided by llvm? Registering roots (e.g. globals) is a facility your runtime should provide. You could use a module initializer to call into the runtime and accomplish this. Traversing the object graph is also outside of LLVM's scope. Your code would need to emit whatever metadata is necessary for it to correctly traverse the graph at runtime. > 2. what about gcreading and gcwriting objects of a different type > than i8*? Simply bitcast to/from i8*. If you don't need write barriers, you would be advised to ignore gcread and gcwrite entirely, since currently they will only pessimize your code as compared to direct loads and stores. > 3. No Intrinsic for allocating gc memory? Again, that's a feature of the runtime. Simply write a function to do so. For efficiency, your compiler may want to inline part of allocation if you're using a bumpptr allocator. > 4. When passing a gc managed pointer to a c function,how should that > function access the pointer? directly? Generally speaking, yes, directly. If you are using a moving collector and need to pin or copy an object, LLVM neither helps nor hinders your efforts. > there seem to be functions for that in the runtime/ source > directory,but it also seems to be meant for the llvm c frontend? > (and not for use in an extra c library) I'm not sure what you mean here. > 5. some collectors update pointers upon read/write access, can the > llvm gc api provide this? gcread easily allows the pointer loaded from the derived pointer to be updated when it is read. Updating the object pointer from gcread or gcwrite may be possible, but is not straightforward within the framework. Have fun, Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080204/7726e2cc/attachment.html From evan.cheng at apple.com Mon Feb 4 15:08:49 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 4 Feb 2008 13:08:49 -0800 Subject: [LLVMdev] RFC: GLIBCXX_DEBUG ScheduleDAG Patch In-Reply-To: <200802041131.28740.dag@cray.com> References: <200712171217.52176.dag@cray.com> <200801211041.01832.dag@cray.com> <200802041131.28740.dag@cray.com> Message-ID: <228D50E5-4932-4A43-9809-D84CB250EE6A@apple.com> Have you tested this on SPEC (especially spec2006)? JIT slow down of 6% is really too steep a price to pay. I'll test this patch when I find some time. Evan On Feb 4, 2008, at 9:31 AM, David Greene wrote: > On Monday 21 January 2008 10:41, David Greene wrote: > >>>>> Can you clarify? Is this 1.7% slowdown of scheduling time or >>>>> overall >>>>> codegen time? If it's the later, then it seems a bit too much. >>>>> Also, >>>>> please test it with all the MultiSource/Applications. >>>> >>>> It's 1.7% overall. >>> >>> That seems somewhat steep. Can you see how much of the scheduling >>> slow down there is? >> >> I got some times from the nightly report, so this is overall >> compile time. >> >> The worst slowdown is on timberwolfmc "llc compile" which has a 5% >> slowdown. The JIT slows down 6%. >> >> Everything else looks to be 1% or less. In some cases the times with >> the change are better, probably because this change gets rid of the >> "pop >> everything off and push it back on" way of recreating the heap.[ > > Just want to send a ping on this. This patch is still waiting to go > in. Is > the compile time hit too much? Note that sometimes compile time > improves with this patch. > > I'd like to get this in ASAP so I can start merging other things > back to > upstream. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From lee225 at uiuc.edu Mon Feb 4 15:29:13 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Mon, 4 Feb 2008 15:29:13 -0600 (CST) Subject: [LLVMdev] Question to Chris Message-ID: <20080204152913.BBE62677@expms2.cites.uiuc.edu> I appreciate your suggestions, some follow-up questions though.... >1) LLVM has the capabilities to do everything that you are trying to >re-implement. >2) Have you looked at the C backend? It recreates loops. It may not >create "for" loops but you can hack on it to do that. I wonder if you mean "goto elimination technique" by Ana Maria Erosa ( http://citeseer.ist.psu.edu/317208.html ) for this? >3) The way you are converting out of SSA is wrong. You will suffer >from lost copies. You should look at using demotePHI(). see include/ >llvm/Transforms/Utils/Local.h I use LLVM 1.9 where I can't find demotePHI(). Is it a function available at later versions? >4) LLVM will compute your trip counts for you, use LoopInfo. You >need to be in SSA form to do this. > >-Tanya > Do you mean -loops pass, right? Thank you in advance. Best regards, Seung From evan.cheng at apple.com Mon Feb 4 16:15:24 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 4 Feb 2008 14:15:24 -0800 Subject: [LLVMdev] Exception handling in JIT In-Reply-To: <47A2E553.8020501@lip6.fr> References: <475D7CC0.9010605@lip6.fr> <27026429-F8CF-41B0-86CF-A487EA14890C@apple.com> <475FCB4B.4090304@lip6.fr> <393ABC27-9C1A-4B51-84EB-6F842BA37FA1@apple.com> <47A2E553.8020501@lip6.fr> Message-ID: <91B9A606-4221-43A3-9468-FF255CCBEC60@apple.com> Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index: include/llvm/ExecutionEngine/ExecutionEngine.h > =================================================================== > --- include/llvm/ExecutionEngine/ExecutionEngine.h (revision 46612) > +++ include/llvm/ExecutionEngine/ExecutionEngine.h (working copy) > @@ -85,6 +85,11 @@ > /// pointer is invoked to create it. If this returns null, the JIT > will abort. > void* (*LazyFunctionCreator)(const std::string &); > > + /// ExceptionTableRegister - If Exception Handling is set, the > JIT will > + /// register dwarf tables with this function > + typedef void (*EERegisterFn)(void*); > + static EERegisterFn ExceptionTableRegister; > + > public: > /// lock - This lock is protects the ExecutionEngine, JIT, > JITResolver and > /// JITEmitter classes. It must be held while changing the > internal state of > @@ -246,6 +251,18 @@ > void InstallLazyFunctionCreator(void* (*P)(const std::string &)) { > LazyFunctionCreator = P; > } > + > + /// InstallExceptionTableRegister - The JIT will use the given > function > + /// to register the exception tables it generates. > + static void InstallExceptionTableRegister(void (*F)(void*)) { > + ExceptionTableRegister = F; > + } > + > + /// RegisterTable - Registers the given pointer as an exception > table. It uses > + /// the ExceptionTableRegister function. > + static void RegisterTable(void* res) { > + ExceptionTableRegister(res); > + } > > protected: > explicit ExecutionEngine(ModuleProvider *P); > Index: include/llvm/ExecutionEngine/JITMemoryManager.h > =================================================================== > --- include/llvm/ExecutionEngine/JITMemoryManager.h (revision 46612) > +++ include/llvm/ExecutionEngine/JITMemoryManager.h (working copy) > @@ -89,6 +89,17 @@ > /// deallocateMemForFunction - Free JIT memory for the specified > function. > /// This is never called when the JIT is currently emitting a > function. > virtual void deallocateMemForFunction(const Function *F) = 0; > + > + /// startExceptionTable - When we finished JITing the function, > if exception > + /// handling is set, we emit the exception table. > + virtual unsigned char* startExceptionTable(const Function* F, > + uintptr_t &ActualSize) > = 0; > + > + /// endExceptionTable - This method is called when the JIT is > done emitting > + /// the exception table. > + virtual void endExceptionTable(const Function *F, unsigned char > *TableStart, > + unsigned char *TableEnd, > + unsigned char* FrameRegister) = 0; > }; > > } // end namespace llvm. > Index: include/llvm/CodeGen/MachineCodeEmitter.h > =================================================================== > --- include/llvm/CodeGen/MachineCodeEmitter.h (revision 46612) > +++ include/llvm/CodeGen/MachineCodeEmitter.h (working copy) > @@ -26,6 +26,7 @@ > class MachineConstantPool; > class MachineJumpTableInfo; > class MachineFunction; > +class MachineModuleInfo; > class MachineRelocation; > class Value; > class GlobalValue; > @@ -136,6 +137,72 @@ > CurBufferPtr = BufferEnd; > } > > + > + /// emitULEB128Bytes - This callback is invoked when a ULEB128 > needs to be > + /// written to the output stream. > + void emitULEB128Bytes(unsigned Value) { > + do { > + unsigned char Byte = Value & 0x7f; > + Value >>= 7; > + if (Value) Byte |= 0x80; > + emitByte(Byte); > + } while (Value); > + } > + > + /// emitSLEB128Bytes - This callback is invoked when a SLEB128 > needs to be > + /// written to the output stream. > + void emitSLEB128Bytes(int Value) { > + int Sign = Value >> (8 * sizeof(Value) - 1); > + bool IsMore; > + > + do { > + unsigned char Byte = Value & 0x7f; > + Value >>= 7; > + IsMore = Value != Sign || ((Byte ^ Sign) & 0x40) != 0; > + if (IsMore) Byte |= 0x80; > + emitByte(Byte); > + } while (IsMore); > + } > + > + /// emitString - This callback is invoked when a String needs to be > + /// written to the output stream. > + void emitString(const std::string &String) { > + for (unsigned i = 0, N = String.size(); i < N; ++i) { > + unsigned char C = String[i]; > + emitByte(C); > + } > + emitByte(0); > + } > + > + /// emitInt32 - Emit a int32 directive. > + void emitInt32(int Value) { > + if (CurBufferPtr+4 <= BufferEnd) { > + *((uint32_t*)CurBufferPtr) = Value; > + CurBufferPtr += 4; > + } else { > + CurBufferPtr = BufferEnd; > + } > + } > + > + /// emitInt64 - Emit a int64 directive. > + void emitInt64(uint64_t Value) { > + if (CurBufferPtr+8 <= BufferEnd) { > + *((uint64_t*)CurBufferPtr) = Value; > + CurBufferPtr += 8; > + } else { > + CurBufferPtr = BufferEnd; > + } > + } > + > + /// emitAt - Emit Value in Addr > + void emitAt(uintptr_t *Addr, uintptr_t Value) { > + if (Addr >= (uintptr_t*)BufferBegin && Addr < > (uintptr_t*)BufferEnd) > + (*Addr) = Value; > + } > + > + /// emitLabel - Emits a label > + virtual void emitLabel(uint64_t LabelID) = 0; > + > /// allocateSpace - Allocate a block of space in the current > output buffer, > /// returning null (and setting conditions to indicate buffer > overflow) on > /// failure. Alignment is the alignment in bytes of the buffer > desired. > @@ -194,6 +261,15 @@ > /// emitted. > /// > virtual intptr_t getMachineBasicBlockAddress(MachineBasicBlock > *MBB) const= 0; > + > + /// getLabelAddress - Return the address of the specified > LabelID, only usable > + /// after the LabelID has been emitted. > + /// > + virtual intptr_t getLabelAddress(uint64_t LabelID) const = 0; > + > + /// Specifies the MachineModuleInfo object. This is used for > exception handling > + /// purposes. > + virtual void setModuleInfo(MachineModuleInfo* Info) = 0; > }; > > } // End llvm namespace > Index: lib/CodeGen/LLVMTargetMachine.cpp > =================================================================== > --- lib/CodeGen/LLVMTargetMachine.cpp (revision 46612) > +++ lib/CodeGen/LLVMTargetMachine.cpp (working copy) > @@ -186,8 +186,8 @@ > > PM.add(createGCLoweringPass()); > > - // FIXME: Implement the invoke/unwind instructions! > - PM.add(createLowerInvokePass(getTargetLowering())); > + if (!ExceptionHandling) > + PM.add(createLowerInvokePass(getTargetLowering())); > > // Make sure that no unreachable blocks are instruction selected. > PM.add(createUnreachableBlockEliminationPass()); > Index: lib/CodeGen/ELFWriter.cpp > =================================================================== > --- lib/CodeGen/ELFWriter.cpp (revision 46612) > +++ lib/CodeGen/ELFWriter.cpp (working copy) > @@ -98,6 +98,21 @@ > return 0; > } > > + virtual intptr_t getLabelAddress(uint64_t Label) const { > + assert(0 && "Label address not implementated yet!"); > + abort(); > + return 0; > + } > + > + virtual void emitLabel(uint64_t LabelID) { > + assert(0 && "emit Label not implementated yet!"); > + abort(); > + } > + > + > + virtual void setModuleInfo(llvm::MachineModuleInfo* MMI) { } > + > + > /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! > void startFunctionStub(unsigned StubSize, unsigned Alignment = > 1) { > assert(0 && "JIT specific function called!"); > Index: lib/CodeGen/MachOWriter.cpp > =================================================================== > --- lib/CodeGen/MachOWriter.cpp (revision 46612) > +++ lib/CodeGen/MachOWriter.cpp (working copy) > @@ -125,6 +125,20 @@ > return MBBLocations[MBB->getNumber()]; > } > > + virtual intptr_t getLabelAddress(uint64_t Label) const { > + assert(0 && "get Label not implemented"); > + abort(); > + return 0; > + } > + > + virtual void emitLabel(uint64_t LabelID) { > + assert(0 && "emit Label not implemented"); > + abort(); > + } > + > + > + virtual void setModuleInfo(llvm::MachineModuleInfo* MMI) { } > + > /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! > virtual void startFunctionStub(unsigned StubSize, unsigned > Alignment = 1) { > assert(0 && "JIT specific function called!"); > Index: lib/Target/PowerPC/PPCCodeEmitter.cpp > =================================================================== > --- lib/Target/PowerPC/PPCCodeEmitter.cpp (revision 46612) > +++ lib/Target/PowerPC/PPCCodeEmitter.cpp (working copy) > @@ -20,6 +20,7 @@ > #include "llvm/CodeGen/MachineCodeEmitter.h" > #include "llvm/CodeGen/MachineFunctionPass.h" > #include "llvm/CodeGen/MachineInstrBuilder.h" > +#include "llvm/CodeGen/MachineModuleInfo.h" > #include "llvm/CodeGen/Passes.h" > #include "llvm/Support/Debug.h" > #include "llvm/Support/Compiler.h" > @@ -38,6 +39,11 @@ > /// getMachineOpValue - evaluates the MachineOperand of a given > MachineInstr > /// > int getMachineOpValue(MachineInstr &MI, MachineOperand &MO); > + > + void getAnalysisUsage(AnalysisUsage &AU) const { > + AU.addRequired(); > + MachineFunctionPass::getAnalysisUsage(AU); > + } > > public: > static char ID; > @@ -82,6 +88,8 @@ > assert((MF.getTarget().getRelocationModel() != Reloc::Default || > MF.getTarget().getRelocationModel() != Reloc::Static) && > "JIT relocation model must be set to static or default!"); > + > + MCE.setModuleInfo(&getAnalysis()); > do { > MovePCtoLROffset = 0; > MCE.startFunction(MF); > @@ -101,6 +109,9 @@ > default: > MCE.emitWordBE(getBinaryCodeForInstr(*I)); > break; > + case TargetInstrInfo::LABEL: > + MCE.emitLabel(MI.getOperand(0).getImm()); > + break; > case PPC::IMPLICIT_DEF_GPRC: > case PPC::IMPLICIT_DEF_G8RC: > case PPC::IMPLICIT_DEF_F8: > Index: lib/Target/X86/X86CodeEmitter.cpp > =================================================================== > --- lib/Target/X86/X86CodeEmitter.cpp (revision 46612) > +++ lib/Target/X86/X86CodeEmitter.cpp (working copy) > @@ -23,6 +23,7 @@ > #include "llvm/CodeGen/MachineCodeEmitter.h" > #include "llvm/CodeGen/MachineFunctionPass.h" > #include "llvm/CodeGen/MachineInstr.h" > +#include "llvm/CodeGen/MachineModuleInfo.h" > #include "llvm/CodeGen/Passes.h" > #include "llvm/Function.h" > #include "llvm/ADT/Statistic.h" > @@ -61,6 +62,11 @@ > > void emitInstruction(const MachineInstr &MI, > const TargetInstrDesc *Desc); > + > + void getAnalysisUsage(AnalysisUsage &AU) const { > + AU.addRequired(); > + MachineFunctionPass::getAnalysisUsage(AU); > + } > > private: > void emitPCRelativeBlockAddress(MachineBasicBlock *MBB); > @@ -104,10 +110,13 @@ > assert((MF.getTarget().getRelocationModel() != Reloc::Default || > MF.getTarget().getRelocationModel() != Reloc::Static) && > "JIT relocation model must be set to static or default!"); > + > + MCE.setModuleInfo(&getAnalysis()); > + > II = ((X86TargetMachine&)TM).getInstrInfo(); > TD = ((X86TargetMachine&)TM).getTargetData(); > Is64BitMode = TM.getSubtarget().is64Bit(); > - > + > do { > MCE.startFunction(MF); > for (MachineFunction::iterator MBB = MF.begin(), E = MF.end(); > @@ -596,13 +605,13 @@ > // Remember the current PC offset, this is the PIC relocation > // base address. > switch (Opcode) { > -#ifndef NDEBUG > default: > assert(0 && "psuedo instructions should be removed before code > emission"); > case TargetInstrInfo::INLINEASM: > assert(0 && "JIT does not support inline asm!\n"); > case TargetInstrInfo::LABEL: > - assert(0 && "JIT does not support meta labels!\n"); > + MCE.emitLabel(MI.getOperand(0).getImm()); > + break; > case X86::IMPLICIT_DEF_GR8: > case X86::IMPLICIT_DEF_GR16: > case X86::IMPLICIT_DEF_GR32: > @@ -613,7 +622,6 @@ > case X86::IMPLICIT_DEF_VR128: > case X86::FP_REG_KILL: > break; > -#endif > case X86::MOVPC32r: { > // This emits the "call" portion of this pseudo instruction. > MCE.emitByte(BaseOpcode); > @@ -627,7 +635,6 @@ > } > CurOp = NumOps; > break; > - > case X86II::RawFrm: > MCE.emitByte(BaseOpcode); > > Index: lib/ExecutionEngine/JIT/JITEmitter.cpp > =================================================================== > --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 46612) > +++ lib/ExecutionEngine/JIT/JITEmitter.cpp (working copy) > @@ -14,6 +14,7 @@ > > #define DEBUG_TYPE "jit" > #include "JIT.h" > +#include "JITDwarfEmitter.h" > #include "llvm/Constant.h" > #include "llvm/Module.h" > #include "llvm/Type.h" > @@ -21,11 +22,13 @@ > #include "llvm/CodeGen/MachineFunction.h" > #include "llvm/CodeGen/MachineConstantPool.h" > #include "llvm/CodeGen/MachineJumpTableInfo.h" > +#include "llvm/CodeGen/MachineModuleInfo.h" > #include "llvm/CodeGen/MachineRelocation.h" > #include "llvm/ExecutionEngine/JITMemoryManager.h" > #include "llvm/Target/TargetData.h" > #include "llvm/Target/TargetJITInfo.h" > #include "llvm/Target/TargetMachine.h" > +#include "llvm/Target/TargetOptions.h" > #include "llvm/Support/Debug.h" > #include "llvm/Support/MutexGuard.h" > #include "llvm/System/Disassembler.h" > @@ -336,6 +339,17 @@ > > /// Resolver - This contains info about the currently resolved > functions. > JITResolver Resolver; > + > + /// DE - The dwarf emitter for the jit. > + JITDwarfEmitter *DE; > + > + /// LabelLocations - This vector is a mapping from Label ID's > to their > + /// address. > + std::vector LabelLocations; > + > + /// MMI - Machine module info for exception informations > + MachineModuleInfo* MMI; > + > public: > JITEmitter(JIT &jit, JITMemoryManager *JMM) : Resolver(jit) { > MemMgr = JMM ? JMM : > JITMemoryManager::CreateDefaultMemManager(); > @@ -343,9 +357,12 @@ > MemMgr->AllocateGOT(); > DOUT << "JIT is managing a GOT\n"; > } > + > + if (ExceptionHandling) DE = new JITDwarfEmitter(jit); > } > ~JITEmitter() { > delete MemMgr; > + if (ExceptionHandling) delete DE; > } > > JITResolver &getJITResolver() { return Resolver; } > @@ -384,6 +401,24 @@ > void deallocateMemForFunction(Function *F) { > MemMgr->deallocateMemForFunction(F); > } > + > + virtual void emitLabel(uint64_t LabelID) { > + if (LabelLocations.size() <= LabelID) > + LabelLocations.resize((LabelID+1)*2); > + LabelLocations[LabelID] = getCurrentPCValue(); > + } > + > + virtual intptr_t getLabelAddress(uint64_t LabelID) const { > + assert(LabelLocations.size() > (unsigned)LabelID && > + LabelLocations[LabelID] && "Label not emitted!"); > + return LabelLocations[LabelID]; > + } > + > + virtual void setModuleInfo(MachineModuleInfo* Info) { > + MMI = Info; > + if (ExceptionHandling) DE->setModuleInfo(Info); > + } > + > private: > void *getPointerToGlobal(GlobalValue *GV, void *Reference, bool > NoNeedStub); > void *getPointerToGVLazyPtr(GlobalValue *V, void *Reference, > @@ -544,7 +579,25 @@ > DOUT << "Disassembled code:\n" > << sys::disassembleBuffer(FnStart, FnEnd-FnStart, > (uintptr_t)FnStart); > #endif > - > + if (ExceptionHandling) { > + uintptr_t ActualSize; > + SavedBufferBegin = BufferBegin; > + SavedBufferEnd = BufferEnd; > + SavedCurBufferPtr = CurBufferPtr; > + > + BufferBegin = CurBufferPtr = MemMgr- > >startExceptionTable(F.getFunction(), > + > ActualSize); > + BufferEnd = BufferBegin+ActualSize; > + unsigned char* FrameRegister = DE->EmitDwarfTable(F, *this, > FnStart, FnEnd); > + MemMgr->endExceptionTable(F.getFunction(), BufferBegin, > CurBufferPtr, FrameRegister); > + BufferBegin = SavedBufferBegin; > + BufferEnd = SavedBufferEnd; > + CurBufferPtr = SavedCurBufferPtr; > + > + TheJIT->RegisterTable(FrameRegister); > + } > + MMI->EndFunction(); > + > return false; > } > > Index: lib/ExecutionEngine/JIT/JITMemoryManager.cpp > =================================================================== > --- lib/ExecutionEngine/JIT/JITMemoryManager.cpp (revision 46612) > +++ lib/ExecutionEngine/JIT/JITMemoryManager.cpp (working copy) > @@ -256,6 +256,7 @@ > sys::MemoryBlock getNewMemoryBlock(unsigned size); > > std::map FunctionBlocks; > + std::map TableBlocks; > public: > DefaultJITMemoryManager(); > ~DefaultJITMemoryManager(); > @@ -290,6 +291,28 @@ > FreeMemoryList =CurBlock->TrimAllocationToSize(FreeMemoryList, > BlockSize); > } > > + /// startExceptionTable - Use startFunctionBody to allocate > memory for the > + /// function's exception table. > + unsigned char* startExceptionTable(const Function* F, uintptr_t > &ActualSize) { > + return startFunctionBody(F, ActualSize); > + } > + > + /// endExceptionTable - The exception table of F is now > allocated, > + /// and takes the memory in the range [TableStart,TableEnd). > + void endExceptionTable(const Function *F, unsigned char > *TableStart, > + unsigned char *TableEnd, > + unsigned char* FrameRegister) { > + assert(TableEnd > TableStart); > + assert(TableStart == (unsigned char *)(CurBlock+1) && > + "Mismatched table start/end!"); > + > + uintptr_t BlockSize = TableEnd - (unsigned char *)CurBlock; > + TableBlocks[F] = CurBlock; > + > + // Release the memory at the end of this block that isn't > needed. > + FreeMemoryList =CurBlock- > >TrimAllocationToSize(FreeMemoryList, BlockSize); > + } > + > unsigned char *getGOTBase() const { > return GOTBase; > } > @@ -315,6 +338,24 @@ > > // Finally, remove this entry from FunctionBlocks. > FunctionBlocks.erase(I); > + > + I = TableBlocks.find(F); > + if (I == TableBlocks.end()) return; > + > + // Find the block that is allocated for this function. > + MemRange = I->second; > + assert(MemRange->ThisAllocated && "Block isn't allocated!"); > + > + // Fill the buffer with garbage! > +#ifndef NDEBUG > + memset(MemRange+1, 0xCD, MemRange->BlockSize- > sizeof(*MemRange)); > +#endif > + > + // Free the memory. > + FreeMemoryList = MemRange->FreeBlock(FreeMemoryList); > + > + // Finally, remove this entry from TableBlocks. > + TableBlocks.erase(I); > } > }; > } > Index: lib/ExecutionEngine/ExecutionEngine.cpp > =================================================================== > --- lib/ExecutionEngine/ExecutionEngine.cpp (revision 46612) > +++ lib/ExecutionEngine/ExecutionEngine.cpp (working copy) > @@ -34,7 +34,9 @@ > > ExecutionEngine::EECtorFn ExecutionEngine::JITCtor = 0; > ExecutionEngine::EECtorFn ExecutionEngine::InterpCtor = 0; > +ExecutionEngine::EERegisterFn > ExecutionEngine::ExceptionTableRegister = 0; > > + > ExecutionEngine::ExecutionEngine(ModuleProvider *P) : > LazyFunctionCreator(0) { > LazyCompilationDisabled = false; > Modules.push_back(P); > Index: lib/ExecutionEngine/JIT/JITDwarfEmitter.h > =================================================================== > --- lib/ExecutionEngine/JIT/JITDwarfEmitter.h (revision 0) > +++ lib/ExecutionEngine/JIT/JITDwarfEmitter.h (revision 0) > @@ -0,0 +1,69 @@ > +//===------ JITDwarfEmitter.h - Write dwarf tables into memory > ------------===// > +// > +// The LLVM Compiler Infrastructure > +// > +// This file is distributed under the University of Illinois Open > Source > +// License. See LICENSE.TXT for details. > +// > +// > = > = > = > ----------------------------------------------------------------------= > ==// > +// > +// This file defines a JITDwarfEmitter object that is used by the > JIT to > +// write dwarf tables to memory. > +// > +// > = > = > = > ----------------------------------------------------------------------= > ==// > + > +#ifndef LLVM_EXECUTION_ENGINE_JIT_DWARFEMITTER_H > +#define LLVM_EXECUTION_ENGINE_JIT_DWARFEMITTER_H > + > +namespace llvm { > + > +class Function; > +class MachineCodeEmitter; > +class MachineFunction; > +class MachineModuleInfo; > +class MachineMove; > +class MRegisterInfo; > +class TargetData; > +class TargetMachine; > + > +class JITDwarfEmitter { > + const TargetData* TD; > + MachineCodeEmitter* MCE; > + const MRegisterInfo* RI; > + MachineModuleInfo* MMI; > + JIT& Jit; > + bool needsIndirectEncoding; > + bool stackGrowthDirection; > + > +public: > + JITDwarfEmitter(JIT& jit); > + > + unsigned char* EmitExceptionTable(MachineFunction* MF, > + unsigned char* StartFunction, > + unsigned char* EndFunction); > + > + void EmitFrameMoves(intptr_t BaseLabelPtr, > + const std::vector &Moves); > + > + unsigned char* EmitCommonEHFrame(const Function* Personality); > + > + unsigned char* EmitEHFrame(const Function* Personality, > + unsigned char* StartBufferPtr, > + unsigned char* StartFunction, > + unsigned char* EndFunction, > + unsigned char* ExceptionTable); > + > + > + unsigned char* EmitDwarfTable(MachineFunction& F, > + MachineCodeEmitter& MCE, > + unsigned char* StartFunction, > + unsigned char* EndFunction); > + > + void setModuleInfo(MachineModuleInfo* Info) { > + MMI = Info; > + } > +}; > + > +} // end namespace llvm > + > +#endif // LLVM_EXECUTION_ENGINE_JIT_DWARFEMITTER_H > Index: lib/ExecutionEngine/JIT/JITDwarfEmitter.cpp > =================================================================== > --- lib/ExecutionEngine/JIT/JITDwarfEmitter.cpp (revision 0) > +++ lib/ExecutionEngine/JIT/JITDwarfEmitter.cpp (revision 0) > @@ -0,0 +1,636 @@ > +//===----- JITDwarfEmitter.cpp - Write dwarf tables into memory > -----------===// > +// > +// The LLVM Compiler Infrastructure > +// > +// This file is distributed under the University of Illinois Open > Source > +// License. See LICENSE.TXT for details. > +// > +// > = > = > = > ----------------------------------------------------------------------= > ==// > +// > +// This file defines a JITDwarfEmitter object that is used by the > JIT to > +// write dwarf tables to memory. > +// > +// > = > = > = > ----------------------------------------------------------------------= > ==// > + > +#include "JIT.h" > +#include "JITDwarfEmitter.h" > +#include "llvm/Function.h" > +#include "llvm/ADT/DenseMap.h" > +#include "llvm/CodeGen/AsmPrinter.h" > +#include "llvm/CodeGen/MachineCodeEmitter.h" > +#include "llvm/CodeGen/MachineFunction.h" > +#include "llvm/CodeGen/MachineLocation.h" > +#include "llvm/CodeGen/MachineModuleInfo.h" > +#include "llvm/ExecutionEngine/JITMemoryManager.h" > +#include "llvm/Target/MRegisterInfo.h" > +#include "llvm/Target/TargetAsmInfo.h" > +#include "llvm/Target/TargetData.h" > +#include "llvm/Target/TargetInstrInfo.h" > +#include "llvm/Target/TargetFrameInfo.h" > +#include "llvm/Target/TargetMachine.h" > + > +using namespace llvm; > + > +JITDwarfEmitter::JITDwarfEmitter(JIT& theJit) : Jit(theJit) {} > + > + > +unsigned char* JITDwarfEmitter::EmitDwarfTable(MachineFunction& F, > + MachineCodeEmitter& > mce, > + unsigned char* > StartFunction, > + unsigned char* > EndFunction) { > + const TargetMachine& TM = F.getTarget(); > + TD = TM.getTargetData(); > + needsIndirectEncoding = TM.getTargetAsmInfo()- > >getNeedsIndirectEncoding(); > + stackGrowthDirection = TM.getFrameInfo()- > >getStackGrowthDirection(); > + RI = TM.getRegisterInfo(); > + MCE = &mce; > + > + unsigned char* ExceptionTable = EmitExceptionTable(&F, > StartFunction, > + EndFunction); > + > + unsigned char* Result = 0; > + unsigned char* EHFramePtr = 0; > + > + const std::vector Personalities = MMI- > >getPersonalities(); > + EHFramePtr = EmitCommonEHFrame(Personalities[MMI- > >getPersonalityIndex()]); > + > + Result = EmitEHFrame(Personalities[MMI->getPersonalityIndex()], > EHFramePtr, > + StartFunction, EndFunction, ExceptionTable); > + > + return Result; > +} > + > + > +void JITDwarfEmitter::EmitFrameMoves(intptr_t BaseLabelPtr, > + const std::vector > &Moves) { > + unsigned PointerSize = TD->getPointerSize(); > + int stackGrowth = stackGrowthDirection == > TargetFrameInfo::StackGrowsUp ? > + PointerSize : -PointerSize; > + bool IsLocal = BaseLabelPtr; > + > + for (unsigned i = 0, N = Moves.size(); i < N; ++i) { > + const MachineMove &Move = Moves[i]; > + unsigned LabelID = Move.getLabelID(); > + > + if (LabelID) { > + LabelID = MMI->MappedLabel(LabelID); > + > + // Throw out move if the label is invalid. > + if (!LabelID) continue; > + } > + > + intptr_t LabelPtr = 0; > + if (LabelID) LabelPtr = MCE->getLabelAddress(LabelID); > + > + const MachineLocation &Dst = Move.getDestination(); > + const MachineLocation &Src = Move.getSource(); > + > + // Advance row if new location. > + if (BaseLabelPtr && LabelID && (BaseLabelPtr != LabelPtr || ! > IsLocal)) { > + MCE->emitByte(dwarf::DW_CFA_advance_loc4); > + if (PointerSize == 8) { > + MCE->emitInt64(LabelPtr - BaseLabelPtr); > + } else { > + MCE->emitInt32(LabelPtr - BaseLabelPtr); > + } > + > + BaseLabelPtr = LabelPtr; > + IsLocal = true; > + } > + > + // If advancing cfa. > + if (Dst.isRegister() && Dst.getRegister() == > MachineLocation::VirtualFP) { > + if (!Src.isRegister()) { > + if (Src.getRegister() == MachineLocation::VirtualFP) { > + MCE->emitByte(dwarf::DW_CFA_def_cfa_offset); > + } else { > + MCE->emitByte(dwarf::DW_CFA_def_cfa); > + MCE->emitULEB128Bytes(RI- > >getDwarfRegNum(Src.getRegister(), true)); > + } > + > + int Offset = -Src.getOffset(); > + > + MCE->emitULEB128Bytes(Offset); > + } else { > + assert(0 && "Machine move no supported yet."); > + } > + } else if (Src.isRegister() && > + Src.getRegister() == MachineLocation::VirtualFP) { > + if (Dst.isRegister()) { > + MCE->emitByte(dwarf::DW_CFA_def_cfa_register); > + MCE->emitULEB128Bytes(RI->getDwarfRegNum(Dst.getRegister(), > true)); > + } else { > + assert(0 && "Machine move no supported yet."); > + } > + } else { > + unsigned Reg = RI->getDwarfRegNum(Src.getRegister(), true); > + int Offset = Dst.getOffset() / stackGrowth; > + > + if (Offset < 0) { > + MCE->emitByte(dwarf::DW_CFA_offset_extended_sf); > + MCE->emitULEB128Bytes(Reg); > + MCE->emitSLEB128Bytes(Offset); > + } else if (Reg < 64) { > + MCE->emitByte(dwarf::DW_CFA_offset + Reg); > + MCE->emitULEB128Bytes(Offset); > + } else { > + MCE->emitByte(dwarf::DW_CFA_offset_extended); > + MCE->emitULEB128Bytes(Reg); > + MCE->emitULEB128Bytes(Offset); > + } > + } > + } > +} > + > +/// SharedTypeIds - How many leading type ids two landing pads have > in common. > +static unsigned SharedTypeIds(const LandingPadInfo *L, > + const LandingPadInfo *R) { > + const std::vector &LIds = L->TypeIds, &RIds = R->TypeIds; > + unsigned LSize = LIds.size(), RSize = RIds.size(); > + unsigned MinSize = LSize < RSize ? LSize : RSize; > + unsigned Count = 0; > + > + for (; Count != MinSize; ++Count) > + if (LIds[Count] != RIds[Count]) > + return Count; > + > + return Count; > +} > + > + > +/// PadLT - Order landing pads lexicographically by type id. > +static bool PadLT(const LandingPadInfo *L, const LandingPadInfo *R) { > + const std::vector &LIds = L->TypeIds, &RIds = R->TypeIds; > + unsigned LSize = LIds.size(), RSize = RIds.size(); > + unsigned MinSize = LSize < RSize ? LSize : RSize; > + > + for (unsigned i = 0; i != MinSize; ++i) > + if (LIds[i] != RIds[i]) > + return LIds[i] < RIds[i]; > + > + return LSize < RSize; > +} > + > +struct KeyInfo { > + static inline unsigned getEmptyKey() { return -1U; } > + static inline unsigned getTombstoneKey() { return -2U; } > + static unsigned getHashValue(const unsigned &Key) { return Key; } > + static bool isEqual(unsigned LHS, unsigned RHS) { return LHS == > RHS; } > + static bool isPod() { return true; } > +}; > + > +/// ActionEntry - Structure describing an entry in the actions table. > +struct ActionEntry { > + int ValueForTypeID; // The value to write - may not be equal to > the type id. > + int NextAction; > + struct ActionEntry *Previous; > +}; > + > +/// PadRange - Structure holding a try-range and the associated > landing pad. > +struct PadRange { > + // The index of the landing pad. > + unsigned PadIndex; > + // The index of the begin and end labels in the landing pad's > label lists. > + unsigned RangeIndex; > +}; > + > +typedef DenseMap RangeMapType; > + > +/// CallSiteEntry - Structure describing an entry in the call-site > table. > +struct CallSiteEntry { > + unsigned BeginLabel; // zero indicates the start of the function. > + unsigned EndLabel; // zero indicates the end of the function. > + unsigned PadLabel; // zero indicates that there is no landing > pad. > + unsigned Action; > +}; > + > +unsigned char* JITDwarfEmitter::EmitExceptionTable(MachineFunction* > MF, > + unsigned char* > StartFunction, > + unsigned char* > EndFunction) { > + // Map all labels and get rid of any dead landing pads. > + MMI->TidyLandingPads(); > + > + const std::vector &TypeInfos = MMI- > >getTypeInfos(); > + const std::vector &FilterIds = MMI->getFilterIds(); > + const std::vector &PadInfos = MMI- > >getLandingPads(); > + if (PadInfos.empty()) return 0; > + > + // Sort the landing pads in order of their type ids. This is > used to fold > + // duplicate actions. > + SmallVector LandingPads; > + LandingPads.reserve(PadInfos.size()); > + for (unsigned i = 0, N = PadInfos.size(); i != N; ++i) > + LandingPads.push_back(&PadInfos[i]); > + std::sort(LandingPads.begin(), LandingPads.end(), PadLT); > + > + // Negative type ids index into FilterIds, positive type ids > index into > + // TypeInfos. The value written for a positive type id is just > the type > + // id itself. For a negative type id, however, the value written > is the > + // (negative) byte offset of the corresponding FilterIds entry. > The byte > + // offset is usually equal to the type id, because the FilterIds > entries > + // are written using a variable width encoding which outputs one > byte per > + // entry as long as the value written is not too large, but can > differ. > + // This kind of complication does not occur for positive type ids > because > + // type infos are output using a fixed width encoding. > + // FilterOffsets[i] holds the byte offset corresponding to > FilterIds[i]. > + SmallVector FilterOffsets; > + FilterOffsets.reserve(FilterIds.size()); > + int Offset = -1; > + for(std::vector::const_iterator I = FilterIds.begin(), > + E = FilterIds.end(); I != E; ++I) { > + FilterOffsets.push_back(Offset); > + Offset -= AsmPrinter::SizeULEB128(*I); > + } > + > + // Compute the actions table and gather the first action index > for each > + // landing pad site. > + SmallVector Actions; > + SmallVector FirstActions; > + FirstActions.reserve(LandingPads.size()); > + > + int FirstAction = 0; > + unsigned SizeActions = 0; > + for (unsigned i = 0, N = LandingPads.size(); i != N; ++i) { > + const LandingPadInfo *LP = LandingPads[i]; > + const std::vector &TypeIds = LP->TypeIds; > + const unsigned NumShared = i ? SharedTypeIds(LP, > LandingPads[i-1]) : 0; > + unsigned SizeSiteActions = 0; > + > + if (NumShared < TypeIds.size()) { > + unsigned SizeAction = 0; > + ActionEntry *PrevAction = 0; > + > + if (NumShared) { > + const unsigned SizePrevIds = LandingPads[i-1]- > >TypeIds.size(); > + assert(Actions.size()); > + PrevAction = &Actions.back(); > + SizeAction = AsmPrinter::SizeSLEB128(PrevAction- > >NextAction) + > + AsmPrinter::SizeSLEB128(PrevAction->ValueForTypeID); > + for (unsigned j = NumShared; j != SizePrevIds; ++j) { > + SizeAction -= AsmPrinter::SizeSLEB128(PrevAction- > >ValueForTypeID); > + SizeAction += -PrevAction->NextAction; > + PrevAction = PrevAction->Previous; > + } > + } > + > + // Compute the actions. > + for (unsigned I = NumShared, M = TypeIds.size(); I != M; ++I) { > + int TypeID = TypeIds[I]; > + assert(-1-TypeID < (int)FilterOffsets.size() && "Unknown > filter id!"); > + int ValueForTypeID = TypeID < 0 ? FilterOffsets[-1 - > TypeID] : TypeID; > + unsigned SizeTypeID = > AsmPrinter::SizeSLEB128(ValueForTypeID); > + > + int NextAction = SizeAction ? -(SizeAction + SizeTypeID) : 0; > + SizeAction = SizeTypeID + > AsmPrinter::SizeSLEB128(NextAction); > + SizeSiteActions += SizeAction; > + > + ActionEntry Action = {ValueForTypeID, NextAction, > PrevAction}; > + Actions.push_back(Action); > + > + PrevAction = &Actions.back(); > + } > + > + // Record the first action of the landing pad site. > + FirstAction = SizeActions + SizeSiteActions - SizeAction + 1; > + } // else identical - re-use previous FirstAction > + > + FirstActions.push_back(FirstAction); > + > + // Compute this sites contribution to size. > + SizeActions += SizeSiteActions; > + } > + > + // Compute the call-site table. Entries must be ordered by > address. > + SmallVector CallSites; > + > + RangeMapType PadMap; > + for (unsigned i = 0, N = LandingPads.size(); i != N; ++i) { > + const LandingPadInfo *LandingPad = LandingPads[i]; > + for (unsigned j=0, E = LandingPad->BeginLabels.size(); j != E; + > +j) { > + unsigned BeginLabel = LandingPad->BeginLabels[j]; > + assert(!PadMap.count(BeginLabel) && "Duplicate landing pad > labels!"); > + PadRange P = { i, j }; > + PadMap[BeginLabel] = P; > + } > + } > + > + bool MayThrow = false; > + unsigned LastLabel = 0; > + for (MachineFunction::const_iterator I = MF->begin(), E = MF- > >end(); > + I != E; ++I) { > + for (MachineBasicBlock::const_iterator MI = I->begin(), E = I- > >end(); > + MI != E; ++MI) { > + if (MI->getOpcode() != TargetInstrInfo::LABEL) { > + MayThrow |= MI->getDesc().isCall(); > + continue; > + } > + > + unsigned BeginLabel = MI->getOperand(0).getImm(); > + assert(BeginLabel && "Invalid label!"); > + > + if (BeginLabel == LastLabel) > + MayThrow = false; > + > + RangeMapType::iterator L = PadMap.find(BeginLabel); > + > + if (L == PadMap.end()) > + continue; > + > + PadRange P = L->second; > + const LandingPadInfo *LandingPad = LandingPads[P.PadIndex]; > + > + assert(BeginLabel == LandingPad->BeginLabels[P.RangeIndex] && > + "Inconsistent landing pad map!"); > + > + // If some instruction between the previous try-range and > this one may > + // throw, create a call-site entry with no landing pad for > the region > + // between the try-ranges. > + if (MayThrow) { > + CallSiteEntry Site = {LastLabel, BeginLabel, 0, 0}; > + CallSites.push_back(Site); > + } > + > + LastLabel = LandingPad->EndLabels[P.RangeIndex]; > + CallSiteEntry Site = {BeginLabel, LastLabel, > + LandingPad->LandingPadLabel, FirstActions[P.PadIndex]}; > + > + assert(Site.BeginLabel && Site.EndLabel && Site.PadLabel && > + "Invalid landing pad!"); > + > + // Try to merge with the previous call-site. > + if (CallSites.size()) { > + CallSiteEntry &Prev = CallSites[CallSites.size()-1]; > + if (Site.PadLabel == Prev.PadLabel && Site.Action == > Prev.Action) { > + // Extend the range of the previous entry. > + Prev.EndLabel = Site.EndLabel; > + continue; > + } > + } > + > + // Otherwise, create a new call-site. > + CallSites.push_back(Site); > + } > + } > + // If some instruction between the previous try-range and the end > of the > + // function may throw, create a call-site entry with no landing > pad for the > + // region following the try-range. > + if (MayThrow) { > + CallSiteEntry Site = {LastLabel, 0, 0, 0}; > + CallSites.push_back(Site); > + } > + > + // Final tallies. > + unsigned SizeSites = CallSites.size() * (sizeof(int32_t) + // > Site start. > + sizeof(int32_t) + // > Site length. > + sizeof(int32_t)); // > Landing pad. > + for (unsigned i = 0, e = CallSites.size(); i < e; ++i) > + SizeSites += AsmPrinter::SizeULEB128(CallSites[i].Action); > + > + unsigned SizeTypes = TypeInfos.size() * TD->getPointerSize(); > + > + unsigned TypeOffset = sizeof(int8_t) + // Call site format > + // Call-site table length > + AsmPrinter::SizeULEB128(SizeSites) + > + SizeSites + SizeActions + SizeTypes; > + > + unsigned TotalSize = sizeof(int8_t) + // LPStart format > + sizeof(int8_t) + // TType format > + AsmPrinter::SizeULEB128(TypeOffset) + // > TType base offset > + TypeOffset; > + > + unsigned SizeAlign = (4 - TotalSize) & 3; > + > + // Begin the exception table. > + MCE->emitAlignment(4); > + for (unsigned i = 0; i != SizeAlign; ++i) { > + MCE->emitByte(0); > + // Asm->EOL("Padding"); > + } > + > + unsigned char* DwarfExceptionTable = (unsigned char*)MCE- > >getCurrentPCValue(); > + > + // Emit the header. > + MCE->emitByte(dwarf::DW_EH_PE_omit); > + // Asm->EOL("LPStart format (DW_EH_PE_omit)"); > + MCE->emitByte(dwarf::DW_EH_PE_absptr); > + // Asm->EOL("TType format (DW_EH_PE_absptr)"); > + MCE->emitULEB128Bytes(TypeOffset); > + // Asm->EOL("TType base offset"); > + MCE->emitByte(dwarf::DW_EH_PE_udata4); > + // Asm->EOL("Call site format (DW_EH_PE_udata4)"); > + MCE->emitULEB128Bytes(SizeSites); > + // Asm->EOL("Call-site table length"); > + > + // Emit the landing pad site information. > + for (unsigned i = 0; i < CallSites.size(); ++i) { > + CallSiteEntry &S = CallSites[i]; > + intptr_t BeginLabelPtr = 0; > + intptr_t EndLabelPtr = 0; > + > + if (!S.BeginLabel) { > + BeginLabelPtr = (intptr_t)StartFunction; > + if (TD->getPointerSize() == sizeof(int32_t)) > + MCE->emitInt32(0); > + else > + MCE->emitInt64(0); > + } else { > + BeginLabelPtr = MCE->getLabelAddress(S.BeginLabel); > + if (TD->getPointerSize() == sizeof(int32_t)) > + MCE->emitInt32(BeginLabelPtr - (intptr_t)StartFunction); > + else > + MCE->emitInt64(BeginLabelPtr - (intptr_t)StartFunction); > + } > + > + // Asm->EOL("Region start"); > + > + if (!S.EndLabel) { > + EndLabelPtr = (intptr_t)EndFunction; > + if (TD->getPointerSize() == sizeof(int32_t)) > + MCE->emitInt32((intptr_t)EndFunction - BeginLabelPtr); > + else > + MCE->emitInt64((intptr_t)EndFunction - BeginLabelPtr); > + } else { > + EndLabelPtr = MCE->getLabelAddress(S.EndLabel); > + if (TD->getPointerSize() == sizeof(int32_t)) > + MCE->emitInt32(EndLabelPtr - BeginLabelPtr); > + else > + MCE->emitInt64(EndLabelPtr - BeginLabelPtr); > + } > + //Asm->EOL("Region length"); > + > + if (!S.PadLabel) { > + if (TD->getPointerSize() == sizeof(int32_t)) > + MCE->emitInt32(0); > + else > + MCE->emitInt64(0); > + } else { > + unsigned PadLabelPtr = MCE->getLabelAddress(S.PadLabel); > + if (TD->getPointerSize() == sizeof(int32_t)) > + MCE->emitInt32(PadLabelPtr - (intptr_t)StartFunction); > + else > + MCE->emitInt64(PadLabelPtr - (intptr_t)StartFunction); > + } > + // Asm->EOL("Landing pad"); > + > + MCE->emitULEB128Bytes(S.Action); > + // Asm->EOL("Action"); > + } > + > + // Emit the actions. > + for (unsigned I = 0, N = Actions.size(); I != N; ++I) { > + ActionEntry &Action = Actions[I]; > + > + MCE->emitSLEB128Bytes(Action.ValueForTypeID); > + //Asm->EOL("TypeInfo index"); > + MCE->emitSLEB128Bytes(Action.NextAction); > + //Asm->EOL("Next action"); > + } > + > + // Emit the type ids. > + for (unsigned M = TypeInfos.size(); M; --M) { > + GlobalVariable *GV = TypeInfos[M - 1]; > + > + if (GV) { > + if (TD->getPointerSize() == sizeof(int32_t)) { > + MCE->emitInt32((intptr_t)Jit.getOrEmitGlobalVariable(GV)); > + } else { > + MCE->emitInt64((intptr_t)Jit.getOrEmitGlobalVariable(GV)); > + } > + } else { > + if (TD->getPointerSize() == sizeof(int32_t)) > + MCE->emitInt32(0); > + else > + MCE->emitInt64(0); > + } > + // Asm->EOL("TypeInfo"); > + } > + > + // Emit the filter typeids. > + for (unsigned j = 0, M = FilterIds.size(); j < M; ++j) { > + unsigned TypeID = FilterIds[j]; > + MCE->emitULEB128Bytes(TypeID); > + //Asm->EOL("Filter TypeInfo index"); > + } > + > + MCE->emitAlignment(4); > + > + return DwarfExceptionTable; > +} > + > +unsigned char* JITDwarfEmitter::EmitCommonEHFrame(const Function* > Personality) { > + unsigned PointerSize = TD->getPointerSize(); > + int stackGrowth = stackGrowthDirection == > TargetFrameInfo::StackGrowsUp ? > + PointerSize : -PointerSize; > + > + unsigned char* StartCommonPtr = (unsigned char*)MCE- > >getCurrentPCValue(); > + // EH Common Frame header > + MCE->allocateSpace(PointerSize, 0); > + unsigned char* FrameCommonBeginPtr = (unsigned char*)MCE- > >getCurrentPCValue(); > + MCE->emitInt32((int)0); > + MCE->emitByte(dwarf::DW_CIE_VERSION); > + MCE->emitString(Personality ? "zPLR" : "zR"); > + MCE->emitULEB128Bytes(1); > + MCE->emitSLEB128Bytes(stackGrowth); > + MCE->emitByte(RI->getDwarfRegNum(RI->getRARegister(), true)); > + > + if (Personality) { > + MCE->emitULEB128Bytes(7); > + > + if (needsIndirectEncoding) > + MCE->emitByte(dwarf::DW_EH_PE_pcrel | dwarf::DW_EH_PE_sdata4 | > + dwarf::DW_EH_PE_indirect); > + else > + MCE->emitByte(dwarf::DW_EH_PE_pcrel | dwarf::DW_EH_PE_sdata4); > + > + if (PointerSize == 8) > + MCE->emitInt64((intptr_t)Jit.getPointerToGlobal(Personality) - > + MCE->getCurrentPCValue()); > + else > + MCE->emitInt32((intptr_t)Jit.getPointerToGlobal(Personality) - > + MCE->getCurrentPCValue()); > + > + MCE->emitULEB128Bytes(dwarf::DW_EH_PE_pcrel); > + MCE->emitULEB128Bytes(dwarf::DW_EH_PE_pcrel); > + > + } else { > + MCE->emitULEB128Bytes(1); > + MCE->emitULEB128Bytes(dwarf::DW_EH_PE_pcrel); > + } > + > + std::vector Moves; > + RI->getInitialFrameState(Moves); > + EmitFrameMoves(0, Moves); > + MCE->emitAlignment(4); > + > + MCE->emitAt((uintptr_t*)StartCommonPtr, > + (uintptr_t)((unsigned char*)MCE->getCurrentPCValue() - > + FrameCommonBeginPtr)); > + > + return StartCommonPtr; > +} > + > + > +unsigned char* JITDwarfEmitter::EmitEHFrame(const Function* > Personality, > + unsigned char* > StartCommonPtr, > + unsigned char* > StartFunction, > + unsigned char* > EndFunction, > + unsigned char* > ExceptionTable) { > + unsigned PointerSize = TD->getPointerSize(); > + > + // EH frame header. > + unsigned char* StartEHPtr = (unsigned char*)MCE- > >getCurrentPCValue(); > + MCE->allocateSpace(PointerSize, 0); > + unsigned char* FrameBeginPtr = (unsigned char*)MCE- > >getCurrentPCValue(); > + // FDE CIE Offset > + if (PointerSize == 8) { > + MCE->emitInt64(FrameBeginPtr - StartCommonPtr); > + MCE->emitInt64(StartFunction - (unsigned char*)MCE- > >getCurrentPCValue()); > + MCE->emitInt64(EndFunction - StartFunction); > + } else { > + MCE->emitInt32(FrameBeginPtr - StartCommonPtr); > + MCE->emitInt32(StartFunction - (unsigned char*)MCE- > >getCurrentPCValue()); > + MCE->emitInt32(EndFunction - StartFunction); > + } > + > + // If there is a personality and landing pads then point to the > language > + // specific data area in the exception table. > + if (MMI->getPersonalityIndex()) { > + MCE->emitULEB128Bytes(4); > + > + if (!MMI->getLandingPads().empty()) { > + if (PointerSize == 8) > + MCE->emitInt64(ExceptionTable - (unsigned char*)MCE- > >getCurrentPCValue()); > + else > + MCE->emitInt32(ExceptionTable - (unsigned char*)MCE- > >getCurrentPCValue()); > + } else if (PointerSize == 8) { > + MCE->emitInt64((int)0); > + } else { > + MCE->emitInt32((int)0); > + } > + } else { > + MCE->emitULEB128Bytes(0); > + } > + > + // Indicate locations of function specific callee saved > registers in > + // frame. > + EmitFrameMoves((intptr_t)StartFunction, MMI->getFrameMoves()); > + > + MCE->emitAlignment(4); > + > + // Indicate the size of the table > + MCE->emitAt((uintptr_t*)StartEHPtr, > + (uintptr_t)((unsigned char*)MCE->getCurrentPCValue() - > + StartEHPtr)); > + > + // Double zeroes for the unwind runtime > + if (PointerSize == 8) { > + MCE->emitInt64(0); > + MCE->emitInt64(0); > + } else { > + MCE->emitInt32(0); > + MCE->emitInt32(0); > + } > + > + > + return StartEHPtr; > +} > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From lee225 at uiuc.edu Mon Feb 4 16:42:03 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Mon, 4 Feb 2008 16:42:03 -0600 (CST) Subject: [LLVMdev] Question to Chris Message-ID: <20080204164203.BBE77636@expms2.cites.uiuc.edu> Thank you for this comment, Mike. So... your suggestion is to make a valid transform for each loop like: >for (;C;) { > S >} > >is to transform: > >top: >if (!C) goto end; > S >goto top; >end: For now, my code is incomplete so not ready to present for audit yet but I hope it asap. In fact, I couldn't understand what you said: >The cost of the .pdf file outweighed the benefit for me. I can see >the pretty graphs in the straight text code. If you want to help me >see them further, just indent. Forgive my poor English. What did you mean by that? Thanks, Seung ---- Original message ---- >Date: Sat, 2 Feb 2008 11:31:46 -0800 >From: Mike Stump >Subject: Re: [LLVMdev] Question to Chris >To: LLVM Developers Mailing List > >On Feb 1, 2008, at 11:51 PM, Seung Jae Lee wrote: >> As Prof.Adve mentioned, I need to explain exactly what my problem >> is, but I have no good ability that I can explain it in this plain >> text space. > >Let me rephrase your question for you. You can then see the right >question, and the answer for it. > >The question is, why is, why can't I change: > > bb8: > sum_1 = i_0_pn + sum_0_pn; > br bool %exitcond, label %bb10, label %bb3 > >into > > bb8: > br bool %exitcond, label %bb10, label %bb3 > sum_1 = i_0_pn + sum_0_pn; > >? > >The answer is, because that is an invalid transform. > > A: > B; > C; > >has to be transformed into: > > B; > A: > C; > >(where the motion of B is copy it to the other side of all control >flows into A) > >When you do this, you'll notice you get: > >$ cat t.c >int foo() { > unsigned indvar_next27, indvar_next; > int sum_1, sum_0_pn, i_0_pn; > //entry: > unsigned indvar26 = 0; > int sum_0_pn_ph = 0; > //brlabel %bb8_outer > //bb8_outer: > for (indvar_next27=0; indvar_next27 != 10; ){ > int i_0_0_ph = (int) indvar26; > unsigned indvar= 0; > int sum_0_pn = sum_0_pn_ph; > int i_0_pn = i_0_0_ph; > //brlabel %bb8 > //bb8: > sum_1 = i_0_pn + sum_0_pn; /* LOOK HERE >*/ > for (;indvar!=3;){ > //%exitcond= setequint%indvar, 3 > //brbool %exitcond, label %bb10, label %bb3 > //bb3: > indvar_next= indvar+ 1; > indvar= indvar_next; > sum_0_pn = sum_1; > i_0_pn = 2; > sum_1 = i_0_pn + sum_0_pn; /* LOOK HERE >*/ > //brlabel %bb8 > } > //bb10: > indvar_next27 = indvar26 + 1; > //%exitcond28 = setequint%indvar_next27, 10 > indvar26 = indvar_next27; > sum_0_pn_ph = sum_1; > //brbool %exitcond28, label %bb16, label %bb8_outer > } > //bb16: > return sum_1; >} > >int main() { > printf("%d\n", foo()); >} >$ gcc t.c >t.c: In function ?main?: >t.c:40: warning: incompatible implicit declaration of built-in >function ?printf? >$ ./a.out >105 > >The cost of the .pdf file outweighed the benefit for me. I can see >the pretty graphs in the straight text code. If you want to help me >see them further, just indent. > >The short answer is you can't guess at valid transforms. You have to >know they are valid, or prove the are valid. > >The only way to get: > >for (;C;) { > S >} > >is to transform: > >top: >if (!C) goto end; > S >goto top; >end: > >into it. If you have any other form, it is wrong to transform into >it. You _must_transform into the form just above first, and then that >form goes into the for statement. > >At the end of the day, you have a set of valid transforms, each one of >which you can talk about and audit separately. If you have any bugs, >they are never in the valid transforms, and the invalid ones stand out >to people skilled in the art. > >So, if you had written down the transform you were using, we could >have identified it. You didn't, so, we could not. > >I didn't check your other loop for correctness, or any of the other >implied transforms that you used for correctness. If you want to >ensure it is correct, you can run large amount of code through it and >check the results (I'd call that the industrial approach) and hope it >is approximately right, or, you have to reason about each and every >transform you're using and hopefully even prove each one. The latter >approach I'd call the academic approach. :-) > >You're splitting and moving phi nodes seems reasonable. > >The transform of: > > top: > S; > goto top; > >into > > for (;;) { > S; > } > >is valid. What isn't valid is putting the induction variable into the >condition slot and calling it done. You must first transform it into >the form given above. To do that, you have to use other transforms, >each one of which you should write down and list and prove is valid. > >If you want us to audit each transform for you, write them all down, >one by one. >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From lee225 at uiuc.edu Mon Feb 4 17:04:17 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Mon, 4 Feb 2008 17:04:17 -0600 (CST) Subject: [LLVMdev] Question to Chris Message-ID: <20080204170417.BBE81027@expms2.cites.uiuc.edu> Hello, Wojtek. I owe much to you. Thank you. My HL code should be simple without any 'goto','break' and so on. Simple as just loops with 'for' and 'if's inside it, so your comment looks helpful. I'll try. Just one thing which concerning me is demotePHI() I couldn't find it in 1.9 so seems to me another installation of the newest version of LLVM. Anyway, Thank you. Truly yours, Seung ---- Original message ---- >Date: Sun, 03 Feb 2008 20:54:24 +0100 >From: Wojciech Matyjewicz >Subject: Re: [LLVMdev] Question to Chris >To: LLVM Developers Mailing List > >Seung, > >> Would you please explain to me how I can access to this problem in a better way if you can figure out? > >Here are my thoughts on your first question: "how to make it count >correctly for the reconstruction of loops?". I believe it can't be done >for an arbitrary loop. However, IIRC from previous posts your loops are >simple - for example: they don't contain any breaks, gotos. I think, >your reconstruction could be done for two forms of loops that are very >common: > >1) rotated canonical loop (bb8.outer in your example): >The loop has only one backedge, and an induction variable counting from >0 with step 1. The only basic block that branches out of the loop (so >called, exiting block) is the backedge. > >header: > %i = phi [ 0, %preheader ], [ %i.next, %body ] > ... > br label %body ;%header and %body may be the same block > >body: > ... > %i.next = add %i, 1 > %c = seteq %i.next, %n > br %c, label %exit, label %header > >exit: > ... > >The loop iteration count is %n. In this case, it means that _every_ >basic block is executed %n times. Your current version of reconstruction >seems to be okay for loops in this form. > >2) unrotated canonical loop (bb8 in your example): >The loop has only one backedge and an induction variable counting from 0 >with step 1. The only basic block that branches out of the loop is the >loop header. > >header: > %i = phi [ 0, %preheader ], [ %i.next, %body ] > ... > %c = seteq %i, %n > br %c, label %exit, label %body > >body: > ... > %i.next = add %i, 1 > br label %header > >exit: > ... > >The loop iteration count is also %n. However, this time it means that >the loop header is executed %n times, while the rest of blocks - %n-1 >times. The reconstruction should take it into account. For example, it >could make a "for" loop from all loop basic blocks setting the iteration >count to %n-1, and then insert a copy of the loop header with %i==%n >after the "for". > >I also suggest taking look at the LoopInfo pass. It has many useful >methods to analyze loops. To determine the loop iteration count you may >use the ScalarEvolution pass as well. > >-Wojtek >_______________________________________________ >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 Mon Feb 4 18:01:09 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Mon, 4 Feb 2008 16:01:09 -0800 (PST) Subject: [LLVMdev] Question to Chris In-Reply-To: <20080204152913.BBE62677@expms2.cites.uiuc.edu> References: <20080204152913.BBE62677@expms2.cites.uiuc.edu> Message-ID: >> 1) LLVM has the capabilities to do everything that you are trying to >> re-implement. >> 2) Have you looked at the C backend? It recreates loops. It may not >> create "for" loops but you can hack on it to do that. > > I wonder if you mean "goto elimination technique" by Ana Maria Erosa ( > http://citeseer.ist.psu.edu/317208.html ) for this? I mean exactly this: look at the C backend in LLVM. It goes from LLVM IR in SSA form to C code. LLVM has everything you are trying to reimplement. You should spend some time looking through doxygen or the source code for examples. >> 3) The way you are converting out of SSA is wrong. You will suffer >> from lost copies. You should look at using demotePHI(). see include/ >> llvm/Transforms/Utils/Local.h > > I use LLVM 1.9 where I can't find demotePHI(). Is it a function available at later versions? It is not in 1.9. You should really consider upgrading to 2.1 or 2.2 (its out in a week). 1.9 is almost 1.5 years old! demotePHI is in 2.1. > >> 4) LLVM will compute your trip counts for you, use LoopInfo. You >> need to be in SSA form to do this. > Do you mean -loops pass, right? > I mean this: http://llvm.org/doxygen/LoopInfo_8h-source.html Require the analysis in your pass and use it. -Tanya From dalej at apple.com Mon Feb 4 18:19:36 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 4 Feb 2008 16:19:36 -0800 Subject: [LLVMdev] llvm 46728 won't build Message-ID: <617C4FE6-CF0A-4C29-B2C6-82562E3FD319@apple.com> Somebody forget a header? llvm[2]: Compiling AsmPrinter.cpp for Debug build AsmPrinter.cpp: In member function ?virtual bool llvm::AsmPrinter::doInitialization(llvm::Module&)?: AsmPrinter.cpp:121: error: ?MMI? was not declared in this scope AsmPrinter.cpp: In member function ?void llvm::AsmPrinter::printDeclare(const llvm::MachineInstr*) const?: AsmPrinter.cpp:1298: error: ?MMI? was not declared in this scope From bhurt at spnz.org Mon Feb 4 20:45:38 2008 From: bhurt at spnz.org (Brian Hurt) Date: Mon, 4 Feb 2008 21:45:38 -0500 (EST) Subject: [LLVMdev] Advice on implementing fast per-thread data Message-ID: Hello- I'm looking to implement a new programming language using LLVM as a back-end. Generally it's looking very good, I only have one question. The language is going to be an ML-style language, similiar to Haskell or Ocaml, except explicitly multithreaded and (like Haskell but unlike Ocaml) purely functional. But this means that speed of allocation is essential- purely functional languages have been measured to allocate an average of 1 word every 6 instructions. Generally they allocate larger blocks (often 10-20 words at a shot) less often, but we're still talking about an insane (to imperitive programming language standards) allocation rate. What I'd like is something similiar to the Ocaml garbage collector, but with a unique young heap for each thread (so I don't have to acquire a lock to allocate). But this requires me to have two words of thread-local storage for every thread (young_heap_pointer and young_heap_limit). So this is the question I have: what is the best way to implement this, given exceedingly tight constraints on performance? I'd like something that could be implemented on both Unix/Mac and Windows, just to make it more of a problem. By far the best way I can think of is to play games with the virtual memory- have the two pointers (and maybe a little bit of other per-thread information) on a global page all by themselves, and remap that virtual page for every thread. Then I could simply dereference the globals. On Unix I think I can do this playing games with mmap(), but I'm not sure how to do this on Windows. I played around a little with the VirtualAlloc function, but it doesn't look like it does what I need. Almost as good would be to add a level of indirection, have a global pointer to where the page is to be mapped, and just map it in the same place in every thread. Another possibility, and I'm not sure how to do this in LLVM, would be to sacrifice a register to hold the pointer to the unique per-thread structure. This would be worthwhile to me even on the register-starved x86-32. I suppose I could also just add a "hidden" (compiler-added and -maintained) argument to every function which is the pointer to the per-thread data. Using the normal thread-local storage scares me, because I don't know the performance implications. Obviously calling a syscall every allocation would be unacceptable, nor would I like an O(log N) tree-walking hit. Ocaml's allocation is like 3-5 clock cycles for the common case (no minor GC needed), so adding another 5 clock cycles to get the thread-local data doubles the cost of allocation. Adding 50 or 1000 clock cycles is right out. Basically, I'd like allocation to remain single-digit clock cycle cost for the common case. If someone can convince me that thread-local storage is that fast, then we're good. Otherwise, I need to look elsewhere. Opinions, advice, and/or alternative ideas about this problem would all be greatly welcomed. Which of the above alternatives do you think would work best? Or some other approach entirely? Thanks. Brian From scottm at rushg.aero.org Mon Feb 4 21:39:43 2008 From: scottm at rushg.aero.org (Scott Michel) Date: Mon, 04 Feb 2008 19:39:43 -0800 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: References: Message-ID: <47A7DA7F.7010506@rush.aero.org> thomas weidner wrote: > Hello, > > i want to implement a common lisp subset using llvm for fun. Out of curiousity, for which CL implementation is this targeted? sbcl? Or something you're rolling? The reason why I ask is that I expressed an outrageous opinion at Supercomputing back in November, to wit, that CL is probably the best language suited for today's multicore problems... but I don't have the time to hack one of the current implementations to proove the point. Although, you'll notice that LLVM amply prooves "Greenbaum's hypothesis" (IIRC): inside every sufficiently complex program there is an implmentation of a Lisp interpreter. ;-) -scooter From tonic at nondot.org Mon Feb 4 23:17:14 2008 From: tonic at nondot.org (Tanya Lattner) Date: Mon, 4 Feb 2008 21:17:14 -0800 Subject: [LLVMdev] 2.2 Prerelease available for testing In-Reply-To: <973330f0801301958w6b26971hab805f739b85a827@mail.gmail.com> References: <973330f0801260643u31d8c86bsf5ba52756efa8085@mail.gmail.com> <1EEFE3A8-5163-4F1C-A989-3FCB3DDFFBEF@nondot.org> <973330f0801301958w6b26971hab805f739b85a827@mail.gmail.com> Message-ID: <76D28E69-9B48-4FF9-95E9-BB266DA74AD6@nondot.org> On Jan 30, 2008, at 7:58 PM, Takanori Ishikawa wrote: > Dear Tanya: > >> You also have a few CBE failures that I am not seeing. What version >> of xcode do you have installed? > > Xcode 2.4.1 > Same as mine. >> Can you send me the following files? >> SingleSource/Regression/C/Output/2008-01-07-LongDouble.* >> SingleSource/Regression/C/Output/PR1386.* > > OK, I attached those files (llvm-2.2-test-output.tar.gz) > Thanks. After reviewing these, it looks like there was something wrong with your native compiler. For example, your output for 2008-01-07-LongDouble/2008-01-07-LongDouble.out-nat is wrong. I'm not sure what happened here, but its not in llvm because your llc output is correct. It reports a failure because it compares your llc output to your native output (which is wrong). Thanks, Tanya > Best regards, > > 2008/1/30, Tanya Lattner : >> Thanks for testing the release. Overall the test results look decent >> with a couple exceptions. >> >> You also have a few CBE failures that I am not seeing. What version >> of xcode do you have installed? >> >> Can you send me the following files? >> SingleSource/Regression/C/Output/2008-01-07-LongDouble.* >> SingleSource/Regression/C/Output/PR1386.* >> >> Thanks, >> Tanya >> >> On Jan 26, 2008, at 6:43 AM, Takanori Ishikawa wrote: >> >>> My test results for the LLVM 2.2 prerelease. >>> >>> === Q. Target === >>> >>> * Mac OS X 10.4.11 >>> * 2 GHz Intel Core 2 Duo >>> * MacBook >>> >>> % uname -a >>> Darwin macbook.local 8.11.1 Darwin Kernel Version 8.11.1: >>> Wed Oct 10 18:23:28 PDT 2007; >>> root:xnu-792.25.20~1/RELEASE_I386 i386 i386 >>> >>> === Q. How you built the release === >>> >>> * objDir != srcDir >>> * Release build >>> * llvm-gcc-4.2 from source (llvm-gcc4.2-2.2.source.tar.gz) >>> >>> === Q. Which llvm-gcc you used. === >>> >>> * llvm-gcc-4.2 from source (llvm-gcc4.2-2.2.source.tar.gz) >>> >>> === Q. make check results (either final totals or log file) === >>> >>> * Attachment (testrun.log) >>> >>> === Q. lvm-test results (report.nightly.txt) === >>> >>> * Attachment (llvm-test-2.2.txt) >>> >>> >>> I also put a detailed build instructions here. >>> >>> http://metareal.jottit.com/llvm-2.2-prerelease >>> >>> Hope this help. >>> >>> >>> 2008/1/25, Tanya M. Lattner : >>>> >>>> LLVMers, >>>> >>>> The 2.2 prerelease is now available for testing: >>>> http://llvm.org/prereleases/2.2/ >>>> >>>> If anyone can help test this release, I ask that you do the >>>> following: >>>> >>>> 1) Build llvm and llvm-gcc (or use a binary). You may build release >>>> (default) or debug. You may pick llvm-gcc-4.0, llvm-gcc-4.2, >>>> or both. >>>> 2) Run 'make check'. >>>> 3) In llvm-test, run 'make TEST=nightly report'. >>>> 4) When submitting your testing results to the list, please >>>> include: >>>> - Target >>>> - How you built the release (objDir = srcDir? Release? >>>> Debug? >>>> llvm-gcc binary?) >>>> - Which llvm-gcc you used. >>>> - make check results (either final totals or log file) >>>> - llvm-test results (report.nightly.txt) >>>> >>>> All prerelease testing must be completed by Feb 1, 2008. >>>> >>>> The release has been delayed by one week, and I have updated the >>>> schedule >>>> on the main page. Here is the new schedule: >>>> * Jan 24, 2008: First round of pre-release testing begins. >>>> * Feb 1, 2008: Pre-release testing ends. >>>> * Feb 3, 2008: Second round of pre-release testing begins. >>>> * Feb 10, 2008: Pre-release testing ends. >>>> * Feb 11, 2008: 2.2 released. >>>> >>>> Thanks, >>>> Tanya Lattner >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tonic at nondot.org Mon Feb 4 23:23:40 2008 From: tonic at nondot.org (Tanya Lattner) Date: Mon, 4 Feb 2008 21:23:40 -0800 Subject: [LLVMdev] 2.2 Prerelease (version 2) available for testing Message-ID: LLVMers, The next version of the 2.2 prerelease is available for testing: http://llvm.org/prereleases/2.2/ Please see my last email for testing directions: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-January/012249.html Please complete all testing by February 10th at 5PM PST. Thanks! -Tanya From prabhat.saraswat at gmail.com Tue Feb 5 04:09:57 2008 From: prabhat.saraswat at gmail.com (Prabhat Kumar Saraswat) Date: Tue, 5 Feb 2008 11:09:57 +0100 Subject: [LLVMdev] Induction Variables vs Loop Control Variable Message-ID: Hi all, I was wondering if its possible to identify loop control variables from the induction variables in a Loop using LLVM. Also, How does one can use the LoopInfo class to identify the natural loops from the IR. In other words how to use the class in the pass? Thanks, Regards Prabhat From 3.14159 at gmx.net Tue Feb 5 06:40:20 2008 From: 3.14159 at gmx.net (thomas weidner) Date: Tue, 5 Feb 2008 12:40:20 +0000 (UTC) Subject: [LLVMdev] 2.2 garbage collector questions References: <47A7DA7F.7010506@rush.aero.org> Message-ID: Scott Michel rushg.aero.org> writes: > Out of curiousity, for which CL implementation is this targeted? sbcl? > Or something you're rolling? I wanted to roll out my own lisp, and maybe use some library code from existing lisps (think of loop or format). Adding an LLVM backend to an existing lisp implementation is a nice idea, but currently not planned. > > The reason why I ask is that I expressed an outrageous opinion at > Supercomputing back in November, to wit, that CL is probably the best > language suited for today's multicore problems... but I don't have the > time to hack one of the current implementations to proove the point. interesting, what makes lisp superior in this area over languages with explicit support for parallell computing (like erlang? or Ada) or languages which may be easier auto parallelized (like haskell because of its functional nature). > Although, you'll notice that LLVM amply prooves "Greenbaum's hypothesis" > (IIRC): inside every sufficiently complex program there is an > implmentation of a Lisp interpreter. Nice statement :) From llvmdev at gmail.com Tue Feb 5 07:54:34 2008 From: llvmdev at gmail.com (Sanjiv Gupta) Date: Tue, 5 Feb 2008 19:24:34 +0530 Subject: [LLVMdev] Handling "adde" nodes !! Message-ID: <56aaf0ef0802050554h237a186du41bf27408bb24a63@mail.gmail.com> Any idea how to handle "adde" nodes for processors that do not have an "add with carry" instruction? In our case, we rely on "carry test" and "increment" instrunctions. Any reference to a similiar existing LLVM target will be helpful.. TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080205/b844df54/attachment.html From raulherbster at gmail.com Tue Feb 5 08:10:51 2008 From: raulherbster at gmail.com (Raul Fernandes Herbster) Date: Tue, 5 Feb 2008 11:10:51 -0300 Subject: [LLVMdev] Counting instructions Message-ID: <6fbb4ff20802050610l509e7d43m567a418e383b42e4@mail.gmail.com> Hi, I need to instrument the code in order to generate an event (call a certain function) whenever X instructions have been executed. I'm using MachineFunctionPass to get machine-dependent representation of each LLVM function in the program. However, such pass doesn't allow to modify such functions. Is there any other class so I can modify MachineFunctions? Thanks in advance, Raul. -- Raul Fernandes Herbster Embedded and Pervasive Computing Laboratory - embedded.ufcg.edu.br Electrical Engineering and Informatics Center - CEEI Federal University of Campina Grande - UFCG - www.ufcg.edu.br Caixa Postal 10105 58109-970 Campina Grande - PB - Brasil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080205/5d8c705b/attachment.html From jon at ffconsultancy.com Tue Feb 5 10:14:23 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Tue, 5 Feb 2008 16:14:23 +0000 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: References: <47A7DA7F.7010506@rush.aero.org> Message-ID: <200802051614.23694.jon@ffconsultancy.com> On Tuesday 05 February 2008 12:40:20 thomas weidner wrote: > I wanted to roll out my own lisp, and maybe use some library code from > existing lisps (think of loop or format). Adding an LLVM backend to an > existing lisp implementation is a nice idea, but currently not planned. I am also interested in implementing functional programming languages using LLVM. Although I'm only interested in statically typed ones, there is a lot of work that can be shared. LLVM currently lacks working examples demonstrating the use of garbage collection and exceptions, so that would be a good first port of call. Then we can worry about an intermediate representation that supports closures. If you are familiar with functional programming and, in particular, its benefits in the context of compiler work then you might like to use Gordon's OCaml bindings to LLVM that are bundled with LLVM. They are very easy to use and will make subsequent work vastly easier than trying to write everything in C++. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From bos at serpentine.com Tue Feb 5 11:18:28 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 05 Feb 2008 09:18:28 -0800 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: <200802051614.23694.jon@ffconsultancy.com> References: <47A7DA7F.7010506@rush.aero.org> <200802051614.23694.jon@ffconsultancy.com> Message-ID: <47A89A64.9020602@serpentine.com> Jon Harrop wrote: > If you are familiar with functional programming and, in particular, its > benefits in the context of compiler work then you might like to use Gordon's > OCaml bindings to LLVM that are bundled with LLVM. They are very easy to use > and will make subsequent work vastly easier than trying to write everything > in C++. Or, indeed, the Haskell bindings I've been working on with Lennart Augustsson. They're both safer and easier to use than the OCaml bindings :-) References: <47A7DA7F.7010506@rush.aero.org> <200802051614.23694.jon@ffconsultancy.com> Message-ID: <1202232156.47a89b5cba42c@webmail.telus.net> > LLVM currently lacks working examples demonstrating the use of garbage > collection... Hello, if anybody has time, I would recommend putting a big disclaimer at the top of the garbage collection page that explains that, for the most part, garbage collection falls outside of LLVM's domain. Right now LLVM advertises itself as "supporting garbage collecting", which although true, somewhat misses the point. LLVM just happens to not get in the way. The only real garbage collection feature that LLVM provides is accurate stack walking, and even that can be implemented separately through a shadow stack. That the documentation contains llvm.gc intrinsics is a bit of a red herring. You end up doing most of the work yourself. To illustrate, for our own LLVM work we implemented garbage collecting completely without using any LLVM primitives. Granted, we're a conservative collector right now, and once we go accurate we'll investigate the stack-walking. Just a head's up from an beginner/intermediate LLVM programmer. The current state of the GC documentation makes it seem as if: "you just connect the GC and it works". I'm sure that isn't the intention, but judging from some of the posts on this mailing lists over the past months, this seems to be a common expectation. Two cents... Jaap Suter From jon at ffconsultancy.com Tue Feb 5 11:38:34 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Tue, 5 Feb 2008 17:38:34 +0000 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: <1202232156.47a89b5cba42c@webmail.telus.net> References: <200802051614.23694.jon@ffconsultancy.com> <1202232156.47a89b5cba42c@webmail.telus.net> Message-ID: <200802051738.34544.jon@ffconsultancy.com> On Tuesday 05 February 2008 17:22:36 Jaap Suter wrote: > if anybody has time, I would recommend putting a big disclaimer at the top > of the garbage collection page that explains that, for the most part, > garbage collection falls outside of LLVM's domain. Yes. However, I think it would also be extremely productive to have working examples showcasing what LLVM does provide, e.g. with trivial GC and exception mechanisms. If nothing else, this would at least prove that they really do work. :-) > Just a head's up from an beginner/intermediate LLVM programmer. The current > state of the GC documentation makes it seem as if: "you just connect the GC > and it works". I'm sure that isn't the intention, but judging from some of > the posts on this mailing lists over the past months, this seems to be a > common expectation. I think that is the goal though. New users are certainly expecting it to work because that's the way its phrased. It isn't there yet but it continues to improve at a tremendous rate (IMHO). I'm just sorry that I haven't been able to devote more of my own time to this... There is also the question of when the LLVM maintainers should start kicking stuff out of the LLVM repository. As soon as we get working examples I'm sure they will be deluged with mini Lisp/Haskell/CAML etc. implementations, most of which will snowball beyond minimal working examples and no longer belong in LLVM itself. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From sabre at nondot.org Tue Feb 5 12:01:03 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 5 Feb 2008 10:01:03 -0800 (PST) Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: <200802051738.34544.jon@ffconsultancy.com> References: <200802051614.23694.jon@ffconsultancy.com> <1202232156.47a89b5cba42c@webmail.telus.net> <200802051738.34544.jon@ffconsultancy.com> Message-ID: On Tue, 5 Feb 2008, Jon Harrop wrote: > There is also the question of when the LLVM maintainers should start kicking > stuff out of the LLVM repository. As soon as we get working examples I'm sure > they will be deluged with mini Lisp/Haskell/CAML etc. implementations, most > of which will snowball beyond minimal working examples and no longer belong > in LLVM itself. IMO, there are two classes of projects here. The easy class are little samples or demos or examples which are (at most) a couple hundred lines of code. These can live in the main llvm repo, f.e. under llvm/examples. Projects that are bigger than this can be part of the llvm project umbrella if desired, but should live in a separate module. For example, llvm-gcc, clang, stacker, java, poolalloc etc all exist this way. The bar for creating a separate module is very low, so this isn't a big issue. One real issue though is that these projects will get out of synch with mainline if noone is active to maintain it (e.g. java). In my mind, this is actually a good thing: putting these into mainline would cause increased maintenance burden in the case when noone is interested in the project. When someone later becomes reinterested in a project, it usually isn't too hard to synch the project up to mainline again. Anyway, in short, bring on the deluge! -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Tue Feb 5 12:08:33 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 5 Feb 2008 10:08:33 -0800 (PST) Subject: [LLVMdev] Counting instructions In-Reply-To: <6fbb4ff20802050610l509e7d43m567a418e383b42e4@mail.gmail.com> References: <6fbb4ff20802050610l509e7d43m567a418e383b42e4@mail.gmail.com> Message-ID: On Tue, 5 Feb 2008, Raul Fernandes Herbster wrote: > I need to instrument the code in order to generate an event (call a certain > function) whenever X instructions have been executed. I'm using > MachineFunctionPass to get machine-dependent representation of each LLVM > function in the program. However, such pass doesn't allow to modify such > functions. Is there any other class so I can modify MachineFunctions? I'm not sure I follow here: you want to insert your instrumentation at the machine code level, but you want to change the llvm ir? Once the instruction selection phase converts from llvm ir to machine code, the LLVM IR is mostly ignored. Changing it won't cause a change in the generated code. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Tue Feb 5 12:09:25 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 5 Feb 2008 10:09:25 -0800 (PST) Subject: [LLVMdev] Induction Variables vs Loop Control Variable In-Reply-To: References: Message-ID: On Tue, 5 Feb 2008, Prabhat Kumar Saraswat wrote: > I was wondering if its possible to identify loop control > variables from the induction variables in a Loop using LLVM. > Also, How does one can use the LoopInfo class to identify the natural > loops from the IR. In other words how to use the class in the pass? I'd strongly suggest looking at some existing loop pass like LICM or loop strength reduction or induction variable simplification. Induction Variable Simplification specifically will show you how to rely on it and how to identifier induction variables. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Tue Feb 5 12:12:12 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 5 Feb 2008 10:12:12 -0800 (PST) Subject: [LLVMdev] Advice on implementing fast per-thread data In-Reply-To: References: Message-ID: On Mon, 4 Feb 2008, Brian Hurt wrote: > Another possibility, and I'm not sure how to do this in LLVM, would be to > sacrifice a register to hold the pointer to the unique per-thread > structure. This would be worthwhile to me even on the register-starved > x86-32. I suppose I could also just add a "hidden" (compiler-added and > -maintained) argument to every function which is the pointer to the > per-thread data. Thread local storage (TLS) on Linux is better than this. Instead of sacrificing a GPR, it uses a segment register to reach the TLS area, making it very very cheap. > Using the normal thread-local storage scares me, because I don't know the > performance implications. You should read up about it then. :) Start here: http://people.redhat.com/drepper/tls.pdf -Chris -- http://nondot.org/sabre/ http://llvm.org/ From ssen at apple.com Tue Feb 5 12:10:51 2008 From: ssen at apple.com (Shantonu Sen) Date: Tue, 5 Feb 2008 10:10:51 -0800 Subject: [LLVMdev] Makefile dependencies and configure test fix Message-ID: <8E902AD2-5B8B-49DD-BC57-2961AF287B78@apple.com> Some low-priority fixes to the build system.... These can probably wait after 2.2 1) The current configure script checks for gcc 3.x or later by parsing "gcc --version" output and trying to tokenize it to find the major compiler version. This is pretty fragile and interacts poorly with compilers produced by vendors (like Apple) that modify this string to output target triple (including potentially i686 and darwin9), FSF GCC version, Apple local version. There's lots of numbers there, and the sed expression doesn't find any of the right ones. This patch turns the check into a compile-time check for __GNUC__ version. Since autoconf already does this to determine if you're using GCC or not, it should be pretty safe. Believe it or not, I dusted off a copy of gcc 2.95.2 for Mac OS X for PowerPC and ran it under Rosetta to verify this fix: [ssen at virgon]$ gcc-2.95.2 -v Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs Apple Computer, Inc. version gcc-926, based on gcc version 2.95.2 19991024 (release) [ssen at virgon]$ ./configure CC=gcc-2.95.2 CXX=g++-2.95.2 ... checking for llvm-gcc... no checking for llvm-g++... no checking tool compatibility... configure: error: gcc 3.x required, but you have a lower version 2) Makefile.rules is missing some dependencies for shared library targets, which means if you change core libraries and do a rebuild, things like tools/lto don't get relinked against the new libraries. Test case is to have a pre-built tree and do "touch lib/System/Unix/ Program.inc && make" and make sure you see "Linking Debug Loadable Module LLVMlto.dylib". 3) There appears to be a typo for for llvm_cv_no_link_all_option for Darwin, but this never seems to be used anyway. Probably worth fixing in case a new standalone project uses the LLVM makefiles. I regenerated the configure script with the required versions of autotools on Mac OS X on Intel. Shantonu Sen ssen at apple.com Sent from my Mac Pro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080205/f60f23b5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-makefile-and-configure.patch Type: application/octet-stream Size: 3937 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080205/f60f23b5/attachment.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080205/f60f23b5/attachment-0001.html From brooks at freebsd.org Tue Feb 5 12:33:12 2008 From: brooks at freebsd.org (Brooks Davis) Date: Tue, 5 Feb 2008 12:33:12 -0600 Subject: [LLVMdev] 2.2 Prerelease (version 2) available for testing In-Reply-To: References: Message-ID: <20080205183312.GA86370@lor.one-eyed-alien.net> I've done some minimal testing on FreeBSD 8.x i386. When running make check I get: # of expected passes 2188 # of unexpected failures 1 # of expected failures 6 The error output is: Running /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/LoopUnroll/dg.exp ... FAIL: /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/LoopUnroll/2007-11-05-Crash.ll for PR1770 Failed with signal(SIGSEGV) at line 1 while running: llvm-as < /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/LoopUnroll/2007-11-05-Crash.ll | opt -disable-output -loop-unroll child killed: segmentation violation In this case FreeBSD's malloc debugging option J was enabled and disabling it caused the test to pass. The option does: J Each byte of new memory allocated by malloc(), realloc() or reallocf() will be initialized to 0xa5. All memory returned by free(), realloc() or reallocf() will be initialized to 0x5a. This is intended for debugging and will impact performance nega- tively. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080205/77e36da6/attachment.bin From lattner at apple.com Tue Feb 5 12:34:07 2008 From: lattner at apple.com (Tanya Lattner) Date: Tue, 5 Feb 2008 10:34:07 -0800 Subject: [LLVMdev] Makefile dependencies and configure test fix In-Reply-To: <8E902AD2-5B8B-49DD-BC57-2961AF287B78@apple.com> References: <8E902AD2-5B8B-49DD-BC57-2961AF287B78@apple.com> Message-ID: <3EC7EB82-EA44-407A-A8E5-C058CF95F76D@apple.com> Shantonu, I just wanted to verify that you used the llvm/autoconf/AutoRegen.sh script to regenerate configure. Is that correct? Thanks, Tanya On Feb 5, 2008, at 10:10 AM, Shantonu Sen wrote: > Some low-priority fixes to the build system.... These can probably > wait after 2.2 > > 1) The current configure script checks for gcc 3.x or later by > parsing "gcc --version" output and trying to tokenize it to find > the major compiler version. This is pretty fragile and interacts > poorly with compilers produced by vendors (like Apple) that modify > this string to output target triple (including potentially i686 and > darwin9), FSF GCC version, Apple local version. There's lots of > numbers there, and the sed expression doesn't find any of the right > ones. This patch turns the check into a compile-time check for > __GNUC__ version. Since autoconf already does this to determine if > you're using GCC or not, it should be pretty safe. > > Believe it or not, I dusted off a copy of gcc 2.95.2 for Mac OS X > for PowerPC and ran it under Rosetta to verify this fix: > > [ssen at virgon]$ gcc-2.95.2 -v > Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs > Apple Computer, Inc. version gcc-926, based on gcc version 2.95.2 > 19991024 (release) > [ssen at virgon]$ ./configure CC=gcc-2.95.2 CXX=g++-2.95.2 > ... > checking for llvm-gcc... no > checking for llvm-g++... no > checking tool compatibility... configure: error: gcc 3.x required, > but you have a lower version > > 2) Makefile.rules is missing some dependencies for shared library > targets, which means if you change core libraries and do a rebuild, > things like tools/lto don't get relinked against the new libraries. > Test case is to have a pre-built tree and do "touch lib/System/Unix/ > Program.inc && make" and make sure you see "Linking Debug Loadable > Module LLVMlto.dylib". > > 3) There appears to be a typo for for llvm_cv_no_link_all_option > for Darwin, but this never seems to be used anyway. Probably worth > fixing in case a new standalone project uses the LLVM makefiles. > > I regenerated the configure script with the required versions of > autotools on Mac OS X on Intel. > > > > Shantonu Sen > ssen at apple.com > > Sent from my Mac Pro > > _______________________________________________ > 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/20080205/33601a49/attachment-0001.html From lee225 at uiuc.edu Tue Feb 5 12:44:15 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Tue, 5 Feb 2008 12:44:15 -0600 (CST) Subject: [LLVMdev] signed integer types still in LLVM 2.1 Message-ID: <20080205124415.BBG06211@expms2.cites.uiuc.edu> Hello. I updated my LLVM with version 2.1 from 1.9. But I am curious why I still have signed integer type. I still get LLVM IR as follows: ...... ...... bb8.outer: ; preds = %bb10, %entry %i.0.0.ph = phi uint [ 0, %entry ], [ %indvar.next26, %bb10 ] ; [#uses=2] %sum.0.pn.ph = phi uint [ 0, %entry ], [ %sum.1, %bb10 ] ; [#uses=1] br label %bb8 bb3: ; preds = %bb8 %indvar.next = add uint %j.1, 1 ; [#uses=1] br label %bb8 ..... ..... When I compared this with that from LLVM 1.9, I found all the "cast" instructions eliminated in IR from 2.1, so I seem to be on 2.1 side. But can't see i32 something like this in IR now. (my llvm-gcc is based on gcc 4.0.1) Am I missing something? Thank you, Seung From dpatel at apple.com Tue Feb 5 12:45:49 2008 From: dpatel at apple.com (Devang Patel) Date: Tue, 5 Feb 2008 10:45:49 -0800 Subject: [LLVMdev] 2.2 Prerelease (version 2) available for testing In-Reply-To: <20080205183312.GA86370@lor.one-eyed-alien.net> References: <20080205183312.GA86370@lor.one-eyed-alien.net> Message-ID: <6E79A0E7-8612-47EB-9E07-B0251256293E@apple.com> This was fixed in mainline by Nick http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080121/057623.html On Feb 5, 2008, at 10:33 AM, Brooks Davis wrote: > I've done some minimal testing on FreeBSD 8.x i386. When running make > check I get: > > # of expected passes 2188 > # of unexpected failures 1 > # of expected failures 6 > > The error output is: > > Running > /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/LoopUnroll/ > dg.exp ... > FAIL: /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/ > LoopUnroll/2007-11-05-Crash.ll for PR1770 > Failed with signal(SIGSEGV) at line 1 > while running: llvm-as < /usr/cvsports/devel/llvm/work/llvm-2.2/test/ > Transforms/LoopUnroll/2007-11-05-Crash.ll | opt -disable-output - > loop-unroll > child killed: segmentation violation > > In this case FreeBSD's malloc debugging option J was enabled and > disabling it > caused the test to pass. The option does: > > J Each byte of new memory allocated by malloc(), realloc() > or > reallocf() will be initialized to 0xa5. All memory > returned by > free(), realloc() or reallocf() will be initialized to > 0x5a. > This is intended for debugging and will impact > performance nega- > tively. > > -- Brooks > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev - Devang From ssen at apple.com Tue Feb 5 12:55:33 2008 From: ssen at apple.com (Shantonu Sen) Date: Tue, 5 Feb 2008 10:55:33 -0800 Subject: [LLVMdev] Makefile dependencies and configure test fix In-Reply-To: <3EC7EB82-EA44-407A-A8E5-C058CF95F76D@apple.com> References: <8E902AD2-5B8B-49DD-BC57-2961AF287B78@apple.com> <3EC7EB82-EA44-407A-A8E5-C058CF95F76D@apple.com> Message-ID: <7D5E74DD-11F0-4C26-B132-9FADADFD4D98@apple.com> Yes, I did, the the required versions of autoconf, automake, and libtool in a directory at the front of my PATH. Shantonu Sen ssen at apple.com Sent from my Mac Pro On Feb 5, 2008, at 10:34 AM, Tanya Lattner wrote: > Shantonu, > > I just wanted to verify that you used the llvm/autoconf/AutoRegen.sh > script to regenerate configure. Is that correct? > > Thanks, > Tanya > > On Feb 5, 2008, at 10:10 AM, Shantonu Sen wrote: > >> Some low-priority fixes to the build system.... These can probably >> wait after 2.2 >> >> 1) The current configure script checks for gcc 3.x or later by >> parsing "gcc --version" output and trying to tokenize it to find >> the major compiler version. This is pretty fragile and interacts >> poorly with compilers produced by vendors (like Apple) that modify >> this string to output target triple (including potentially i686 and >> darwin9), FSF GCC version, Apple local version. There's lots of >> numbers there, and the sed expression doesn't find any of the right >> ones. This patch turns the check into a compile-time check for >> __GNUC__ version. Since autoconf already does this to determine if >> you're using GCC or not, it should be pretty safe. >> >> Believe it or not, I dusted off a copy of gcc 2.95.2 for Mac OS X >> for PowerPC and ran it under Rosetta to verify this fix: >> >> [ssen at virgon]$ gcc-2.95.2 -v >> Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs >> Apple Computer, Inc. version gcc-926, based on gcc version 2.95.2 >> 19991024 (release) >> [ssen at virgon]$ ./configure CC=gcc-2.95.2 CXX=g++-2.95.2 >> ... >> checking for llvm-gcc... no >> checking for llvm-g++... no >> checking tool compatibility... configure: error: gcc 3.x required, >> but you have a lower version >> >> 2) Makefile.rules is missing some dependencies for shared library >> targets, which means if you change core libraries and do a rebuild, >> things like tools/lto don't get relinked against the new libraries. >> Test case is to have a pre-built tree and do "touch lib/System/Unix/ >> Program.inc && make" and make sure you see "Linking Debug Loadable >> Module LLVMlto.dylib". >> >> 3) There appears to be a typo for for llvm_cv_no_link_all_option >> for Darwin, but this never seems to be used anyway. Probably worth >> fixing in case a new standalone project uses the LLVM makefiles. >> >> I regenerated the configure script with the required versions of >> autotools on Mac OS X on Intel. >> >> >> >> Shantonu Sen >> ssen at apple.com >> >> Sent from my Mac Pro >> >> _______________________________________________ >> 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/20080205/e578d485/attachment.html From tonic at nondot.org Tue Feb 5 12:58:57 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 5 Feb 2008 10:58:57 -0800 (PST) Subject: [LLVMdev] llvm-gcc4.0 support dropped - please update testers Message-ID: LLVMers, LLVM 2.2 will be the final release that llvm-gcc4.0 is supported. Support has already been dropped in mainline (ie. patches to llvm-gcc4.2 are no longer being back ported). For those running a nightly tester, please upgrade to llvm-gcc4.2. If you have questions, please direct responses to the list. Thanks, Tanya Lattner From sabre at nondot.org Tue Feb 5 13:25:58 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 5 Feb 2008 11:25:58 -0800 (PST) Subject: [LLVMdev] signed integer types still in LLVM 2.1 In-Reply-To: <20080205124415.BBG06211@expms2.cites.uiuc.edu> References: <20080205124415.BBG06211@expms2.cites.uiuc.edu> Message-ID: On Tue, 5 Feb 2008, Seung Jae Lee wrote: > I updated my LLVM with version 2.1 from 1.9. > But I am curious why I still have signed integer type. Did you update your llvm-gcc? -Chris > I still get LLVM IR as follows: > ...... > ...... > bb8.outer: ; preds = %bb10, %entry > %i.0.0.ph = phi uint [ 0, %entry ], [ %indvar.next26, %bb10 ] ; [#uses=2] > %sum.0.pn.ph = phi uint [ 0, %entry ], [ %sum.1, %bb10 ] ; [#uses=1] > br label %bb8 > > bb3: ; preds = %bb8 > %indvar.next = add uint %j.1, 1 ; [#uses=1] > br label %bb8 > ..... > ..... > > When I compared this with that from LLVM 1.9, I found all the "cast" instructions eliminated in IR from 2.1, so I seem to be on 2.1 side. > But can't see i32 something like this in IR now. > (my llvm-gcc is based on gcc 4.0.1) > > Am I missing something? > > Thank you, > Seung > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From evan.cheng at apple.com Tue Feb 5 13:25:34 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 5 Feb 2008 11:25:34 -0800 Subject: [LLVMdev] Code Extractor Issue In-Reply-To: <54D41E91F26CF6488C7088C89D9160F8317DA3@21ctexg01.21technologies.com> References: <54D41E91F26CF6488C7088C89D9160F8317DA3@21ctexg01.21technologies.com> Message-ID: Please file a bug. Thanks. Evan On Feb 1, 2008, at 12:03 PM, Ben Mayne wrote: > I'm having an issue with the CodeExtractor. When I try to extract > the lone basic block from the following function, I get an assertion > error. > > > define i32 @test(i32 %x) { > %tmp = call i32 @test3( i32 %x ) ; > [#uses=1] > ret i32 %tmp > } > > The assertion error is: > > lli: Dominators.cpp:71: void > llvm::DominatorTree::splitBlock(llvm::BasicBlock*): Assertion `NewBB- > >getTerminator()->getNumSuccessors() == 1 && "NewBB should have a > single successor!"' failed. > lli((anonymous namespace)::PrintStackTrace()+0x22)[0x87f7cb8] > lli((anonymous namespace)::SignalHandler(int)+0x110)[0x87f7f7c] > /lib/tls/libc.so.6[0x59fa48] > /lib/tls/libc.so.6(abort+0x129)[0x5a1319] > /lib/tls/libc.so.6(__assert_fail+0x101)[0x598f41] > lli(llvm::DominatorTree::splitBlock(llvm::BasicBlock*)+0xb7) > [0x874edff] > lli[0x86b2672] > lli[0x86b2b15] > lli(llvm::ExtractCodeRegion(llvm::DominatorTree&, > std::vector > > const&, bool)+0x39)[0x86b321d] > > I just updated to llvm-2.1 from llvm-1.9 where I was never having > this problem. I don't understand exactly what it's complaining > about (maybe the fact that the terminator instruction is a 'ret' > instruction?, but I don't see why it couldn't handle this kind of a > block). > > Thanks, > Ben Mayne > > > _______________________________________________ > 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/20080205/25e8af56/attachment-0001.html From evan.cheng at apple.com Tue Feb 5 13:33:33 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 5 Feb 2008 11:33:33 -0800 Subject: [LLVMdev] Handling "adde" nodes !! In-Reply-To: <56aaf0ef0802050554h237a186du41bf27408bb24a63@mail.gmail.com> References: <56aaf0ef0802050554h237a186du41bf27408bb24a63@mail.gmail.com> Message-ID: I don't see any code in legalizer that expands adde nodes. You may have to custom expand them at scheduling time by creating new basic blocks and conditional code. Look for references to usesCustomDAGSchedInserter in td files. I am sure others will have better suggestions. Evan On Feb 5, 2008, at 5:54 AM, Sanjiv Gupta wrote: > Any idea how to handle "adde" nodes for processors that do not have > an "add with carry" instruction? > In our case, we rely on "carry test" and "increment" instrunctions. > Any reference to a similiar existing LLVM target will be helpful.. > > TIA, > Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From lee225 at uiuc.edu Tue Feb 5 13:43:12 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Tue, 5 Feb 2008 13:43:12 -0600 (CST) Subject: [LLVMdev] signed integer types still in LLVM 2.1 Message-ID: <20080205134312.BBG14599@expms2.cites.uiuc.edu> I didn't 'cause my llvm-gcc just seems to be 4.0: ]$ llvm-gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../llvm-gcc4-1.9.source/configure --prefix=/mounts/zion/disks/0/localhome/tbrethou/llvm-gcc4/obj/../install --enable-llvm=/localhome/tbrethou/llvm --enable-languages=c,c++ --disable-threads Thread model: single gcc version 4.0.1 LLVM (Apple Computer, Inc. build 1.9) Do I have to also update llvm-gcc whenever I update llvm? Please forgive my ignorance and thanks for your kind favor in advance. Thanks, Seung ---- Original message ---- >Date: Tue, 5 Feb 2008 11:25:58 -0800 (PST) >From: Chris Lattner >Subject: Re: [LLVMdev] signed integer types still in LLVM 2.1 >To: LLVM Developers Mailing List > >On Tue, 5 Feb 2008, Seung Jae Lee wrote: >> I updated my LLVM with version 2.1 from 1.9. >> But I am curious why I still have signed integer type. > >Did you update your llvm-gcc? > >-Chris > >> I still get LLVM IR as follows: >> ...... >> ...... >> bb8.outer: ; preds = %bb10, %entry >> %i.0.0.ph = phi uint [ 0, %entry ], [ %indvar.next26, %bb10 ] ; [#uses=2] >> %sum.0.pn.ph = phi uint [ 0, %entry ], [ %sum.1, %bb10 ] ; [#uses=1] >> br label %bb8 >> >> bb3: ; preds = %bb8 >> %indvar.next = add uint %j.1, 1 ; [#uses=1] >> br label %bb8 >> ..... >> ..... >> >> When I compared this with that from LLVM 1.9, I found all the "cast" instructions eliminated in IR from 2.1, so I seem to be on 2.1 side. >> But can't see i32 something like this in IR now. >> (my llvm-gcc is based on gcc 4.0.1) >> >> Am I missing something? >> >> Thank you, >> Seung >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >-Chris > >-- >http://nondot.org/sabre/ >http://llvm.org/ >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Tue Feb 5 13:47:08 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 5 Feb 2008 11:47:08 -0800 (PST) Subject: [LLVMdev] Makefile dependencies and configure test fix In-Reply-To: <8E902AD2-5B8B-49DD-BC57-2961AF287B78@apple.com> References: <8E902AD2-5B8B-49DD-BC57-2961AF287B78@apple.com> Message-ID: On Tue, 5 Feb 2008, Shantonu Sen wrote: > Some low-priority fixes to the build system.... These can probably wait after > 2.2 Very nice Shantonu, applied: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080204/057939.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080204/057940.html Thanks! -Chris > 1) The current configure script checks for gcc 3.x or later by parsing "gcc > --version" output and trying to tokenize it to find the major compiler > version. This is pretty fragile and interacts poorly with compilers produced > by vendors (like Apple) that modify this string to output target triple > (including potentially i686 and darwin9), FSF GCC version, Apple local > version. There's lots of numbers there, and the sed expression doesn't find > any of the right ones. This patch turns the check into a compile-time check > for __GNUC__ version. Since autoconf already does this to determine if you're > using GCC or not, it should be pretty safe. > > Believe it or not, I dusted off a copy of gcc 2.95.2 for Mac OS X for PowerPC > and ran it under Rosetta to verify this fix: > > [ssen at virgon]$ gcc-2.95.2 -v > Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs > Apple Computer, Inc. version gcc-926, based on gcc version 2.95.2 19991024 > (release) > [ssen at virgon]$ ./configure CC=gcc-2.95.2 CXX=g++-2.95.2 > ... > checking for llvm-gcc... no > checking for llvm-g++... no > checking tool compatibility... configure: error: gcc 3.x required, but you > have a lower version > > 2) Makefile.rules is missing some dependencies for shared library targets, > which means if you change core libraries and do a rebuild, things like > tools/lto don't get relinked against the new libraries. Test case is to have > a pre-built tree and do "touch lib/System/Unix/Program.inc && make" and make > sure you see "Linking Debug Loadable Module LLVMlto.dylib". > > 3) There appears to be a typo for for llvm_cv_no_link_all_option for Darwin, > but this never seems to be used anyway. Probably worth fixing in case a new > standalone project uses the LLVM makefiles. > > I regenerated the configure script with the required versions of autotools on > Mac OS X on Intel. > > > Shantonu Sen > ssen at apple.com > > Sent from my Mac Pro > > > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From tonic at nondot.org Tue Feb 5 13:50:54 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 5 Feb 2008 11:50:54 -0800 (PST) Subject: [LLVMdev] signed integer types still in LLVM 2.1 In-Reply-To: <20080205134312.BBG14599@expms2.cites.uiuc.edu> References: <20080205134312.BBG14599@expms2.cites.uiuc.edu> Message-ID: > I didn't 'cause my llvm-gcc just seems to be 4.0: > > ]$ llvm-gcc -v > Using built-in specs. > Target: i686-pc-linux-gnu > Configured with: ../llvm-gcc4-1.9.source/configure --prefix=/mounts/zion/disks/0/localhome/tbrethou/llvm-gcc4/obj/../install --enable-llvm=/localhome/tbrethou/llvm --enable-languages=c,c++ --disable-threads > Thread model: single > gcc version 4.0.1 LLVM (Apple Computer, Inc. build 1.9) > > Do I have to also update llvm-gcc whenever I update llvm? > Please forgive my ignorance and thanks for your kind favor in advance. Yes. See the "build 1.9" that means you are using llvm-gcc4.0 release 1.9. llvm-gcc and llvm versions must be the same. -Tanya > > Thanks, > Seung > > ---- Original message ---- >> Date: Tue, 5 Feb 2008 11:25:58 -0800 (PST) >> From: Chris Lattner >> Subject: Re: [LLVMdev] signed integer types still in LLVM 2.1 >> To: LLVM Developers Mailing List >> >> On Tue, 5 Feb 2008, Seung Jae Lee wrote: >>> I updated my LLVM with version 2.1 from 1.9. >>> But I am curious why I still have signed integer type. >> >> Did you update your llvm-gcc? >> >> -Chris >> >>> I still get LLVM IR as follows: >>> ...... >>> ...... >>> bb8.outer: ; preds = %bb10, %entry >>> %i.0.0.ph = phi uint [ 0, %entry ], [ %indvar.next26, %bb10 ] ; [#uses=2] >>> %sum.0.pn.ph = phi uint [ 0, %entry ], [ %sum.1, %bb10 ] ; [#uses=1] >>> br label %bb8 >>> >>> bb3: ; preds = %bb8 >>> %indvar.next = add uint %j.1, 1 ; [#uses=1] >>> br label %bb8 >>> ..... >>> ..... >>> >>> When I compared this with that from LLVM 1.9, I found all the "cast" instructions eliminated in IR from 2.1, so I seem to be on 2.1 side. >>> But can't see i32 something like this in IR now. >>> (my llvm-gcc is based on gcc 4.0.1) >>> >>> Am I missing something? >>> >>> Thank you, >>> Seung >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> -Chris >> >> -- >> http://nondot.org/sabre/ >> http://llvm.org/ >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From zaimoni at zaimoni.com Tue Feb 5 14:36:29 2008 From: zaimoni at zaimoni.com (Kenneth Boyd) Date: Tue, 05 Feb 2008 14:36:29 -0600 Subject: [LLVMdev] Working on getting MingW32/native tools-only source build up Message-ID: <47A8C8CD.5020200@zaimoni.com> Using MingW32/GCC 4.2.1 binary release, mix of Cygwin and MingW32 auxilliary tools, ActivePerl's Perl 5.8.8; operating system Vista. I'm not going to worry about bootstrapping llvm-gcc until I know I can bootstrap gcc. 1) ActivePerl uses the wrong shell (cmd.exe rather than sh.exe) when doing backticks. I had to moderately rewrite llvm-config to use the Cwd module's abs_path function before it worked. Apologies in advance if this is already documented on the site: which files would I need to modify so that llvm-config gets auto-generated correctly? [I haven't done the work to determine what a proper patch would be. I'd think that configure would have to test for the usability of Cwd 'abs_path' before replacing the current $PWD implementation with abs_path calls, which suggests I can't compose the patch (autoconf won't install cleanly).] 2) I'm getting massive link errors on template function instantiations (no tools are being created), and won't have time to properly play with this further "today". It looks like they're being stripped out prematurely; I'll be checking the GCC documentation for how to prevent this when I do have time. Kenneth Boyd From jon at ffconsultancy.com Tue Feb 5 14:44:07 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Tue, 5 Feb 2008 20:44:07 +0000 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: <47A89A64.9020602@serpentine.com> References: <200802051614.23694.jon@ffconsultancy.com> <47A89A64.9020602@serpentine.com> Message-ID: <200802052044.07812.jon@ffconsultancy.com> On Tuesday 05 February 2008 17:18:28 Bryan O'Sullivan wrote: > Jon Harrop wrote: > > If you are familiar with functional programming and, in particular, its > > benefits in the context of compiler work then you might like to use > > Gordon's OCaml bindings to LLVM that are bundled with LLVM. They are very > > easy to use and will make subsequent work vastly easier than trying to > > write everything in C++. > > Or, indeed, the Haskell bindings I've been working on with Lennart > Augustsson. They're both safer and easier to use than the OCaml > bindings :-) Can you elaborate on this? We had a brief discussion here about making safer OCaml bindings by exploiting static type systems but nothing became of it (AFAIK). -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From cfbolz at gmx.de Tue Feb 5 15:15:16 2008 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 05 Feb 2008 22:15:16 +0100 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: <1202232156.47a89b5cba42c@webmail.telus.net> References: <47A7DA7F.7010506@rush.aero.org> <200802051614.23694.jon@ffconsultancy.com> <1202232156.47a89b5cba42c@webmail.telus.net> Message-ID: <47A8D1E4.9020900@gmx.de> Jaap Suter wrote: >> LLVM currently lacks working examples demonstrating the use of garbage >> collection... > > Hello, > > if anybody has time, I would recommend putting a big disclaimer at the top of > the garbage collection page that explains that, for the most part, garbage > collection falls outside of LLVM's domain. > > Right now LLVM advertises itself as "supporting garbage collecting", which > although true, somewhat misses the point. LLVM just happens to not get in the > way. The only real garbage collection feature that LLVM provides is accurate > stack walking, and even that can be implemented separately through a shadow stack. > > That the documentation contains llvm.gc intrinsics is a bit of a red herring. > You end up doing most of the work yourself. To illustrate, for our own LLVM work > we implemented garbage collecting completely without using any LLVM primitives. > Granted, we're a conservative collector right now, and once we go accurate we'll > investigate the stack-walking. In my opinion this is exactly what LLVM _should_ provide. If you try to implement an exact GC one of the most annoying bits is getting information about your stack roots. Using a shadow stack is possible but there are costs attached to it (in PyPy we observed slowdowns of around 5%) as well as implementation complexity. http://morepypy.blogspot.com/2008/01/finding-gc-roots-using-llvm-or-parsing.html > Just a head's up from an beginner/intermediate LLVM programmer. The current > state of the GC documentation makes it seem as if: "you just connect the GC and > it works". I'm sure that isn't the intention, but judging from some of the posts > on this mailing lists over the past months, this seems to be a common expectation. Maybe a disclaimer would make sense indeed. Cheers, Carl Friedrich Bolz From tonic at nondot.org Tue Feb 5 15:57:43 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 5 Feb 2008 13:57:43 -0800 (PST) Subject: [LLVMdev] 2.2 Prerelease (version 2) available for testing In-Reply-To: <20080205183312.GA86370@lor.one-eyed-alien.net> References: <20080205183312.GA86370@lor.one-eyed-alien.net> Message-ID: While this is indeed a bug and has been fixed in mainline, unless we get a major regression in 2.2, I will not merge it into 2.2. Merging this in would require another round of testing and since its technically not a regression from 2.1, I'm not sure the cost outweighs the benefit. Thanks for testing the release! -Tanya On Tue, 5 Feb 2008, Brooks Davis wrote: > I've done some minimal testing on FreeBSD 8.x i386. When running make > check I get: > > # of expected passes 2188 > # of unexpected failures 1 > # of expected failures 6 > > The error output is: > > Running > /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/LoopUnroll/dg.exp ... > FAIL: /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/LoopUnroll/2007-11-05-Crash.ll for PR1770 > Failed with signal(SIGSEGV) at line 1 > while running: llvm-as < /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/LoopUnroll/2007-11-05-Crash.ll | opt -disable-output -loop-unroll > child killed: segmentation violation > > In this case FreeBSD's malloc debugging option J was enabled and disabling it > caused the test to pass. The option does: > > J Each byte of new memory allocated by malloc(), realloc() or > reallocf() will be initialized to 0xa5. All memory returned by > free(), realloc() or reallocf() will be initialized to 0x5a. > This is intended for debugging and will impact performance nega- > tively. > > -- Brooks > From asl at math.spbu.ru Tue Feb 5 16:00:14 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Wed, 06 Feb 2008 01:00:14 +0300 Subject: [LLVMdev] Working on getting MingW32/native tools-only source build up In-Reply-To: <47A8C8CD.5020200.SS1375SS@zaimoni.com> References: <47A8C8CD.5020200.SS1375SS@zaimoni.com> Message-ID: <1202248814.17220.34.camel@asl.dorms.spbu.ru> Hello, Kenneth > Using MingW32/GCC 4.2.1 binary release, mix of Cygwin and MingW32 > auxilliary tools, ActivePerl's Perl 5.8.8; operating system Vista. I'm > not going to worry about bootstrapping llvm-gcc until I know I can > bootstrap gcc. Don't do this. Use either pure cygwin or pure mingw (with msys + msysDTK) installation. This will save bunch of time for you. Seriously. > 1) ActivePerl uses the wrong shell (cmd.exe rather than sh.exe) when > doing backticks. I had to moderately rewrite llvm-config to use the Cwd > module's abs_path function before it worked. See upper. > 2) I'm getting massive link errors on template function instantiations > (no tools are being created), and won't have time to properly play with > this further "today". It looks like they're being stripped out > prematurely; I'll be checking the GCC documentation for how to prevent > this when I do have time. Well. This can be gcc/binutils bug or something like this. I prefer to be conservative and can declare, that everything is ok with gcc 3.4.5 and recent binutils available from mingw website. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From criswell at cs.uiuc.edu Tue Feb 5 16:16:04 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 05 Feb 2008 16:16:04 -0600 Subject: [LLVMdev] Problem Building llvm-gcc 4.2 Message-ID: <47A8E024.3030705@cs.uiuc.edu> Dear All, I'm getting the following error building mainline llvm-gcc 4.2 (LLVM and llvm-gcc are up to date): cc1: /home/vadve/criswell/src/llvm22/lib/VMCore/Instructions.cpp:290: void llvm::CallInst::init(llvm::Value*, llvm::Value*): Assertion `(FTy->getNumParams() == 1 || (FTy->isVarArg() && FTy->getNumParams() == 0)) && "Calling a function with bad signature"' failed. Is anyone else seeing this? I get a similar error when compiling mainline llvm-gcc 4.0. -- John T. From criswell at cs.uiuc.edu Tue Feb 5 16:25:02 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 05 Feb 2008 16:25:02 -0600 Subject: [LLVMdev] Problem Building llvm-gcc 4.2 In-Reply-To: <47A8E024.3030705@cs.uiuc.edu> References: <47A8E024.3030705@cs.uiuc.edu> Message-ID: <47A8E23E.5030704@cs.uiuc.edu> John Criswell wrote: > Dear All, > > I'm getting the following error building mainline llvm-gcc 4.2 (LLVM and > llvm-gcc are up to date): > > cc1: /home/vadve/criswell/src/llvm22/lib/VMCore/Instructions.cpp:290: > void llvm::CallInst::init(llvm::Value*, llvm::Value*): Assertion > `(FTy->getNumParams() == 1 || (FTy->isVarArg() && FTy->getNumParams() == > 0)) && "Calling a function with bad signature"' failed. > On further inspection, I realized I had updated my LLVM tree but hadn't done a new Release build (only new debug builds). I'll retry with a Release build and see if that fixes it. -- John T. > Is anyone else seeing this? I get a similar error when compiling > mainline llvm-gcc 4.0. > > -- 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 jon at ffconsultancy.com Tue Feb 5 16:31:41 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Tue, 5 Feb 2008 22:31:41 +0000 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: <47A8D1E4.9020900@gmx.de> References: <1202232156.47a89b5cba42c@webmail.telus.net> <47A8D1E4.9020900@gmx.de> Message-ID: <200802052231.41134.jon@ffconsultancy.com> On Tuesday 05 February 2008 21:15:16 Carl Friedrich Bolz wrote: > In my opinion this is exactly what LLVM _should_ provide. If you try to > implement an exact GC one of the most annoying bits is getting > information about your stack roots. Using a shadow stack is possible but > there are costs attached to it (in PyPy we observed slowdowns of around > 5%) as well as implementation complexity. > > http://morepypy.blogspot.com/2008/01/finding-gc-roots-using-llvm-or-parsing >.html To put this into perspective, the difference in allocation performance (which is also due to different run-times between OCaml and F#) is up to 500%, so the 5% difference you've observed is tiny and (IMHO) well within the "no significant difference" region. Moreover, I'd be amazed if that 5% were not tremendously architecture and platform specific. How many CPU designs and compilers have you tried this on? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From zaimoni at zaimoni.com Tue Feb 5 17:34:00 2008 From: zaimoni at zaimoni.com (Kenneth Boyd) Date: Tue, 05 Feb 2008 17:34:00 -0600 Subject: [LLVMdev] Working on getting MingW32/native tools-only source build up In-Reply-To: <1202248814.17220.34.camel@asl.dorms.spbu.ru> References: <47A8C8CD.5020200.SS1375SS@zaimoni.com> <1202248814.17220.34.camel@asl.dorms.spbu.ru> Message-ID: <47A8F268.5060205@zaimoni.com> Anton Korobeynikov wrote: > Hello, Kenneth > > >> Using MingW32/GCC 4.2.1 binary release, mix of Cygwin and MingW32 >> auxilliary tools, ActivePerl's Perl 5.8.8; operating system Vista. I'm >> not going to worry about bootstrapping llvm-gcc until I know I can >> bootstrap gcc. >> > Don't do this. Use either pure cygwin or pure mingw (with msys + msysDTK) > installation. This will save bunch of time for you. Seriously. > Actually, the only prebuilt things on this setup that are cygwin are bison 2.3 (recent MingW32 prebuilt bisons don't work, and I can't build-from-source past 1.75 thanks to unbypassable use of fork() ), m4 "just in case", and openssh. Other than that and Perl, I am mostly using the leading-edge prebuilt binaries from the MingW32 website (including binutils). make and grep are locally built, and if I wasn't concerned about bison integration I could build m4 locally. >> 2) I'm getting massive link errors on template function instantiations >> (no tools are being created), and won't have time to properly play with >> this further "today". It looks like they're being stripped out >> prematurely; I'll be checking the GCC documentation for how to prevent >> this when I do have time. >> > Well. This can be gcc/binutils bug or something like this. GCC docs have mentioned that you have to go through specific flags to prevent this. I just need to look up what those flags are, and check whether the *.o/*.a files are being stripped too aggressively. Kenneth From bhurt at spnz.org Tue Feb 5 18:24:26 2008 From: bhurt at spnz.org (Brian Hurt) Date: Tue, 5 Feb 2008 19:24:26 -0500 (EST) Subject: [LLVMdev] Advice on implementing fast per-thread data In-Reply-To: References: Message-ID: On Tue, 5 Feb 2008, Chris Lattner wrote: > On Mon, 4 Feb 2008, Brian Hurt wrote: >> Another possibility, and I'm not sure how to do this in LLVM, would be to >> sacrifice a register to hold the pointer to the unique per-thread >> structure. This would be worthwhile to me even on the register-starved >> x86-32. I suppose I could also just add a "hidden" (compiler-added and >> -maintained) argument to every function which is the pointer to the >> per-thread data. > > Thread local storage (TLS) on Linux is better than this. Instead of > sacrificing a GPR, it uses a segment register to reach the TLS area, > making it very very cheap. > >> Using the normal thread-local storage scares me, because I don't know the >> performance implications. > > You should read up about it then. :) > Start here: http://people.redhat.com/drepper/tls.pdf > Thank you. You've just made my life about 3000% easier. Somehow I've missed __thread- I was thinking of the clunky POSIX threads implementation. Playing around a little bit with this, I find that: static __thread int i; int foo(void) { i += 1; return i; } compiles to: foo: pushl %ebp movl %esp, %ebp movl %gs:i at NTPOFF, %eax addl $1, %eax movl %eax, %gs:i at NTPOFF popl %ebp ret So, other than the segment override, this is no different than accessing a global variable. Which means I don't have to give up a clock cycle on allocation speed for the common case (actually doing a collection is a little bit trickier). Brian From sabre at nondot.org Tue Feb 5 18:09:16 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 5 Feb 2008 16:09:16 -0800 (PST) Subject: [LLVMdev] Advice on implementing fast per-thread data In-Reply-To: References: Message-ID: On Tue, 5 Feb 2008, Brian Hurt wrote: >> You should read up about it then. :) >> Start here: http://people.redhat.com/drepper/tls.pdf >> > > Thank you. You've just made my life about 3000% easier. Somehow I've :) Happy to help, > Playing around a little bit with this, I find that: > static __thread int i; > > int foo(void) { > i += 1; > return i; > } > So, other than the segment override, this is no different than accessing a > global variable. Which means I don't have to give up a clock cycle on > allocation speed for the common case (actually doing a collection is a > little bit trickier). Doing a collection should be relatively straight-forward. You can take the address of these TLS variables, and I believe that the address is visible across threads. Just take the address in the startup for each thread that is created, and store it in some global list that the collector walks. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From scottm at rushg.aero.org Tue Feb 5 19:26:13 2008 From: scottm at rushg.aero.org (Scott Michel) Date: Tue, 05 Feb 2008 17:26:13 -0800 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: References: <47A7DA7F.7010506@rush.aero.org> Message-ID: <47A90CB5.8060709@rush.aero.org> thomas weidner wrote: >>The reason why I ask is that I expressed an outrageous opinion at >>Supercomputing back in November, to wit, that CL is probably the best >>language suited for today's multicore problems... but I don't have the >>time to hack one of the current implementations to proove the point. > > > interesting, what makes lisp superior in this area over languages with explicit > support for parallell computing (like erlang? or Ada) or languages which may be > easier auto parallelized (like haskell because of its functional nature). Lisp macros make it much easier to "rewrite" the program to both analyze the code and take advantage of certain features. Few, if any, other languages have this feature or plan to implement it. For example, assume that the loop macro could be extended in such a way that one could analyze dependencies within the loop -- if there are no dependencies, you get automagic parallelized code. Similarly, the macro could be extended in such a way as to eliminate the dependencies, again, automagic parallelization. -scooter From scottm at rushg.aero.org Tue Feb 5 19:28:37 2008 From: scottm at rushg.aero.org (Scott Michel) Date: Tue, 05 Feb 2008 17:28:37 -0800 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: References: <47A7DA7F.7010506@rush.aero.org> Message-ID: <47A90D45.5080303@rush.aero.org> thomas weidner wrote: > interesting, what makes lisp superior in this area over languages with explicit > support for parallell computing (like erlang? or Ada) or languages which may be > easier auto parallelized (like haskell because of its functional nature). I almost forgot: there was a huge body of work from the 80's on high performance and parallel Lisps. Lisp was the preferred system programming language for the Connection Machine (CM Lisp.) -scooter From scottm at rushg.aero.org Tue Feb 5 19:34:00 2008 From: scottm at rushg.aero.org (Scott Michel) Date: Tue, 05 Feb 2008 17:34:00 -0800 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: <47A90CB5.8060709@rush.aero.org> References: <47A7DA7F.7010506@rush.aero.org> <47A90CB5.8060709@rush.aero.org> Message-ID: <47A90E88.7030901@rush.aero.org> Scott Michel wrote: > thomas weidner wrote: > >>>The reason why I ask is that I expressed an outrageous opinion at >>>Supercomputing back in November, to wit, that CL is probably the best >>>language suited for today's multicore problems... but I don't have the >>>time to hack one of the current implementations to proove the point. >> >> >>interesting, what makes lisp superior in this area over languages with explicit >>support for parallell computing (like erlang? or Ada) or languages which may be >>easier auto parallelized (like haskell because of its functional nature). > > > Lisp macros make it much easier to "rewrite" the program to both analyze > the code and take advantage of certain features. Few, if any, other > languages have this feature or plan to implement it. I realize there might be Lisp macro-like packages for other languages, such as OCaml. Dylan, for all intents and purposes, is A Dead Parrot (as much as it pains me to say so [*]), but was a good example of how to take an Algol-like syntax and incorporate Lisp-like macros in the d-expression paper. For other languages that feature 'eval', such as Python, the AST is relatively complex enough that macros may not ever be viable, i.e., that one could easily perform 'macroexpand-1' before 'eval'. But this is my own personal opinion. Pile on and disgree! -scooter From hs4233 at mail.mn-solutions.de Wed Feb 6 05:10:38 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Wed, 6 Feb 2008 12:10:38 +0100 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 Message-ID: <200802061210.38969.hs4233@mail.mn-solutions.de> I'm on Debian Etch and re-compile llvm/llvm-gcc-4.2 from scratch. I'm on svn revision 46813. I'm using the following commands for the compilation: ---------------------------------- # Get the sources mkdir /s/llvm cd /s/llvm svn co http://llvm.org/svn/llvm-project/llvm/trunk /s/llvm/svn.llvm svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk /s/llvm/svn.gcc42 # Compile llvm mkdir -p /s/llvm/obj.llvm cd /s/llvm/obj.llvm /s/llvm/svn.llvm/configure \ --prefix=/s/llvm/dist \ --with-llvmgccdir=/s/llvm/dist \ --enable-optimized \ --disable-debug \ --disable-doxygen make tools-only # Compile llvm-gcc-4.2 mkdir -p /s/llvm/obj.gcc42 cd /s/llvm/obj.gcc42 /s/llvm/svn.gcc42/configure \ --prefix=/s/llvm/dist \ --enable-llvm=/s/llvm/obj.llvm \ --program-prefix=llvm- \ --enable-languages=c,c++ \ --disable-bootstrap \ --disable-shared make ---------------------------------- This takes some time, and then I get this: ---------------------------------- if /bin/sh ./libtool --mode=compile /s/llvm/obj.gcc42/./gcc/xgcc -B/s/llvm/obj.gcc42/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/s/llvm/svn.gcc42/libgomp -I. -I/s/llvm/svn.gcc42/libgomp/config/linux/x86 -I/s/llvm/svn.gcc42/libgomp/config/linux -I/s/llvm/svn.gcc42/libgomp/config/posix -I/s/llvm/svn.gcc42/libgomp -Wall -Werror -ftls-model=initial-exec -march=i486 -mtune=i686 -Wc,-pthread -O2 -g -O2 -MT lock.lo -MD -MP -MF ".deps/lock.Tpo" -c -o lock.lo /s/llvm/svn.gcc42/libgomp/config/linux/lock.c; \ then mv -f ".deps/lock.Tpo" ".deps/lock.Plo"; else rm -f ".deps/lock.Tpo"; exit 1; fi yes cc1: warnings being treated as errors /s/llvm/svn.gcc42/libgomp/team.c:341: warning: visibility attribute not supported in this configuration; ignored /s/llvm/svn.gcc42/libgomp/team.c:341: warning: visibility attribute not supported in this configuration; ignored checking for tanl... make[5]: *** [team.lo] Error 1 ---------------------------------- Because of the -Werror, this warning is taken as an error and compilation aborts. I wonder why it warns in the first place, is something broken with xgcc? Not knowing details about the gcc build system, I'm wondering also why it builds xgcc, doesn't --disable-bootstrap turn this off? From baldrick at free.fr Wed Feb 6 07:18:58 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 6 Feb 2008 14:18:58 +0100 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <200802061210.38969.hs4233@mail.mn-solutions.de> References: <200802061210.38969.hs4233@mail.mn-solutions.de> Message-ID: <200802061419.04045.baldrick@free.fr> Hi, > if /bin/sh ./libtool --mode=compile /s/llvm/obj.gcc42/./gcc/xgcc -B/s/llvm/obj.gcc42/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/s/llvm/svn.gcc42/libgomp -I. -I/s/llvm/svn.gcc42/libgomp/config/linux/x86 -I/s/llvm/svn.gcc42/libgomp/config/linux -I/s/llvm/svn.gcc42/libgomp/config/posix -I/s/llvm/svn.gcc42/libgomp -Wall -Werror -ftls-model=initial-exec -march=i486 -mtune=i686 -Wc,-pthread -O2 -g -O2 -MT lock.lo -MD -MP -MF ".deps/lock.Tpo" -c -o lock.lo /s/llvm/svn.gcc42/libgomp/config/linux/lock.c; \ > then mv -f ".deps/lock.Tpo" ".deps/lock.Plo"; else rm -f ".deps/lock.Tpo"; exit 1; fi > yes > cc1: warnings being treated as errors > /s/llvm/svn.gcc42/libgomp/team.c:341: warning: visibility attribute not supported in this configuration; ignored > /s/llvm/svn.gcc42/libgomp/team.c:341: warning: visibility attribute not supported in this configuration; ignored > checking for tanl... make[5]: *** [team.lo] Error 1 > ---------------------------------- > > Because of the -Werror, this warning is taken as an error > and compilation aborts. I wonder why it warns in the first > place, is something broken with xgcc? I suspect this is due to the recent change by Bill (revision 46747). Best wishes, Duncan. From zaimoni at zaimoni.com Wed Feb 6 11:19:30 2008 From: zaimoni at zaimoni.com (Kenneth Boyd) Date: Wed, 06 Feb 2008 11:19:30 -0600 Subject: [LLVMdev] Working on getting MingW32/native tools-only source build up In-Reply-To: <47A8C8CD.5020200@zaimoni.com> References: <47A8C8CD.5020200@zaimoni.com> Message-ID: <47A9EC22.4060509@zaimoni.com> Kenneth Boyd wrote: > Using MingW32/GCC 4.2.1 binary release, mix of Cygwin and MingW32 > auxilliary tools, ActivePerl's Perl 5.8.8; operating system Vista. I'm > not going to worry about bootstrapping llvm-gcc until I know I can > bootstrap gcc. > I have the tools-only target building without errors on my end :) > 1) ActivePerl uses the wrong shell (cmd.exe rather than sh.exe) when > doing backticks. I had to moderately rewrite llvm-config to use the Cwd > module's abs_path function before it worked. > > Apologies in advance if this is already documented on the site: which > files would I need to modify so that llvm-config gets auto-generated > correctly? llvm-config.in.in, "of course". Would a patch that tries to use the Cmd module, as well as the current implementation, be reasonable? > 2) I'm getting massive link errors on template function instantiations > (no tools are being created), .... > Libraries weren't being linked in; I worked around this by adjusting the affected makefiles to explicitly mention the required library shorthands. I was doing a static-only build: ../llvm.svn/configure --prefix=/cpp_app/llvm.svn.obj --disable-shared --enable-assertions --enable-expensive-checks Affected tools: bugpoint, llc, lli, llvm2cpp, llvmc, llvm-ar, llvm-as, llvm-bcanalyzer, llvm-db, llvm-dis, llvm-extract, llvm-ld, llvm-link, llvm-nm, llvm-prof, llvm-ranlib, llvm-upgrade, opt . Kenneth Boyd From sabre at nondot.org Wed Feb 6 11:20:24 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 6 Feb 2008 09:20:24 -0800 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <200802061419.04045.baldrick@free.fr> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <200802061419.04045.baldrick@free.fr> Message-ID: <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> On Feb 6, 2008, at 5:18 AM, Duncan Sands wrote: > Hi, > >> if /bin/sh ./libtool --mode=compile /s/llvm/obj.gcc42/./gcc/xgcc -B/ >> s/llvm/obj.gcc42/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/ >> local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/ >> include -isystem /usr/local/i686-pc-linux-gnu/sys-include - >> DHAVE_CONFIG_H -I. -I/s/llvm/svn.gcc42/libgomp -I. -I/s/llvm/ >> svn.gcc42/libgomp/config/linux/x86 -I/s/llvm/svn.gcc42/libgomp/ >> config/linux -I/s/llvm/svn.gcc42/libgomp/config/posix -I/s/llvm/ >> svn.gcc42/libgomp -Wall -Werror -ftls-model=initial-exec - >> march=i486 -mtune=i686 -Wc,-pthread -O2 -g -O2 -MT lock.lo -MD -MP >> -MF ".deps/lock.Tpo" -c -o lock.lo /s/llvm/svn.gcc42/libgomp/config/ >> linux/lock.c; \ >> then mv -f ".deps/lock.Tpo" ".deps/lock.Plo"; else rm -f >> ".deps/lock.Tpo"; exit 1; fi >> yes >> cc1: warnings being treated as errors >> /s/llvm/svn.gcc42/libgomp/team.c:341: warning: visibility attribute >> not supported in this configuration; ignored >> /s/llvm/svn.gcc42/libgomp/team.c:341: warning: visibility attribute >> not supported in this configuration; ignored >> checking for tanl... make[5]: *** [team.lo] Error 1 >> ---------------------------------- >> >> Because of the -Werror, this warning is taken as an error >> and compilation aborts. I wonder why it warns in the first >> place, is something broken with xgcc? > > I suspect this is due to the recent change by Bill (revision 46747). Bill's change only affected darwin IIRC. I don't know that anyone has built GOMP on linux yet, and OpenMP hasn't been widely tested at all. I'd suggest using --enable-languages=c,c++ -Chris From andrewl at lenharth.org Wed Feb 6 11:26:38 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Wed, 6 Feb 2008 11:26:38 -0600 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <200802061419.04045.baldrick@free.fr> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> Message-ID: <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> On 2/6/08, Chris Lattner wrote: > > On Feb 6, 2008, at 5:18 AM, Duncan Sands wrote: > > > Hi, > > > >> if /bin/sh ./libtool --mode=compile /s/llvm/obj.gcc42/./gcc/xgcc -B/ > >> s/llvm/obj.gcc42/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/ > >> local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/ > >> include -isystem /usr/local/i686-pc-linux-gnu/sys-include - > >> DHAVE_CONFIG_H -I. -I/s/llvm/svn.gcc42/libgomp -I. -I/s/llvm/ > >> svn.gcc42/libgomp/config/linux/x86 -I/s/llvm/svn.gcc42/libgomp/ > >> config/linux -I/s/llvm/svn.gcc42/libgomp/config/posix -I/s/llvm/ > >> svn.gcc42/libgomp -Wall -Werror -ftls-model=initial-exec - > >> march=i486 -mtune=i686 -Wc,-pthread -O2 -g -O2 -MT lock.lo -MD -MP > >> -MF ".deps/lock.Tpo" -c -o lock.lo /s/llvm/svn.gcc42/libgomp/config/ > >> linux/lock.c; \ > >> then mv -f ".deps/lock.Tpo" ".deps/lock.Plo"; else rm -f > >> ".deps/lock.Tpo"; exit 1; fi > >> yes > >> cc1: warnings being treated as errors > >> /s/llvm/svn.gcc42/libgomp/team.c:341: warning: visibility attribute > >> not supported in this configuration; ignored > >> /s/llvm/svn.gcc42/libgomp/team.c:341: warning: visibility attribute > >> not supported in this configuration; ignored > >> checking for tanl... make[5]: *** [team.lo] Error 1 > >> ---------------------------------- > >> > >> Because of the -Werror, this warning is taken as an error > >> and compilation aborts. I wonder why it warns in the first > >> place, is something broken with xgcc? > > > > I suspect this is due to the recent change by Bill (revision 46747). > > Bill's change only affected darwin IIRC. I don't know that anyone has > built GOMP on linux yet, and OpenMP hasn't been widely tested at all. > I'd suggest using --enable-languages=c,c++ I am seeing the same errors with just building c,c++. (linux x86, also debian) Andrew From echristo at apple.com Wed Feb 6 11:41:23 2008 From: echristo at apple.com (Eric Christopher) Date: Wed, 6 Feb 2008 09:41:23 -0800 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <200802061419.04045.baldrick@free.fr> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> Message-ID: <0DACC7E6-CF82-4028-8A28-C832D345B680@apple.com> >> >> I suspect this is due to the recent change by Bill (revision 46747). > > Bill's change only affected darwin IIRC. I don't know that anyone has > built GOMP on linux yet, and OpenMP hasn't been widely tested at all. > I'd suggest using --enable-languages=c,c++ This looks like something is broken on the gcc side of things. Does a simple: void __attribute__((visibility ("hidden"))) foo() { } compile with your resultant compiler? -eric From sabre at nondot.org Wed Feb 6 11:44:10 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 6 Feb 2008 09:44:10 -0800 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <200802061419.04045.baldrick@free.fr> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> Message-ID: >>> I suspect this is due to the recent change by Bill (revision 46747). >> >> Bill's change only affected darwin IIRC. I don't know that anyone >> has >> built GOMP on linux yet, and OpenMP hasn't been widely tested at all. >> I'd suggest using --enable-languages=c,c++ > > I am seeing the same errors with just building c,c++. (linux x86, > also debian) Ah, I didn't notice that Bill changed varasm.c. Bill? -Chris From baldrick at free.fr Wed Feb 6 11:54:21 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 6 Feb 2008 18:54:21 +0100 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> Message-ID: <200802061854.26103.baldrick@free.fr> > > > I suspect this is due to the recent change by Bill (revision 46747). > > > > Bill's change only affected darwin IIRC. I don't know that anyone has > > built GOMP on linux yet, and OpenMP hasn't been widely tested at all. > > I'd suggest using --enable-languages=c,c++ > > I am seeing the same errors with just building c,c++. (linux x86, also debian) There was a change to varasm.c that was not conditioned on being on darwin: + /* The "make_assemble_visibility" method may issue a warning if the visibility + attribute isn't supported in a configuration. This is all done through a + call-back. We want to issue this same warning when needed. */ + if (TREE_PUBLIC (decl)) + maybe_assemble_visibility (decl); It seems suspicious. Ciao, Duncan. From andrewl at lenharth.org Wed Feb 6 12:05:21 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Wed, 6 Feb 2008 12:05:21 -0600 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <0DACC7E6-CF82-4028-8A28-C832D345B680@apple.com> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <200802061419.04045.baldrick@free.fr> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> <0DACC7E6-CF82-4028-8A28-C832D345B680@apple.com> Message-ID: <85dfcd7f0802061005v3a5a219bsba9fe57cfdfe025@mail.gmail.com> On 2/6/08, Eric Christopher wrote: > >> > >> I suspect this is due to the recent change by Bill (revision 46747). > > > > Bill's change only affected darwin IIRC. I don't know that anyone has > > built GOMP on linux yet, and OpenMP hasn't been widely tested at all. > > I'd suggest using --enable-languages=c,c++ > > This looks like something is broken on the gcc side of things. Does a > simple: > > void > __attribute__((visibility ("hidden"))) > foo() > { } > > compile with your resultant compiler? ; ModuleID = 'foo.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i686-pc-linux-gnu" define hidden void @foo() { entry: br label %return return: ; preds = %entry ret void } also works when going to native .o or bytecode. llvm-gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../source/configure --prefix=/home/andrewl/Research/cfe-4.2/install --enable-llvm=/home/andrewl/Research/llvm --enable-languages=c,c++ --disable-bootstrap --disable-shared --disable-werror Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5546) (LLVM build) From echristo at apple.com Wed Feb 6 12:05:32 2008 From: echristo at apple.com (Eric Christopher) Date: Wed, 6 Feb 2008 10:05:32 -0800 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <200802061854.26103.baldrick@free.fr> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> <200802061854.26103.baldrick@free.fr> Message-ID: <060B7C42-8EF3-47B7-B832-A6894A85CF28@apple.com> On Feb 6, 2008, at 9:54 AM, Duncan Sands wrote: >>>> I suspect this is due to the recent change by Bill (revision >>>> 46747). >>> >>> Bill's change only affected darwin IIRC. I don't know that anyone >>> has >>> built GOMP on linux yet, and OpenMP hasn't been widely tested at >>> all. >>> I'd suggest using --enable-languages=c,c++ >> >> I am seeing the same errors with just building c,c++. (linux x86, >> also debian) > > There was a change to varasm.c that was not conditioned on being on > darwin: > > + /* The "make_assemble_visibility" method may issue a warning if > the visibility > + attribute isn't supported in a configuration. This is all done > through a > + call-back. We want to issue this same warning when needed. */ > + if (TREE_PUBLIC (decl)) > + maybe_assemble_visibility (decl); > > It seems suspicious. It does seem odd, what was the reason for the change? -eric From echristo at apple.com Wed Feb 6 12:11:44 2008 From: echristo at apple.com (Eric Christopher) Date: Wed, 6 Feb 2008 10:11:44 -0800 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <85dfcd7f0802061005v3a5a219bsba9fe57cfdfe025@mail.gmail.com> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <200802061419.04045.baldrick@free.fr> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> <0DACC7E6-CF82-4028-8A28-C832D345B680@apple.com> <85dfcd7f0802061005v3a5a219bsba9fe57cfdfe025@mail.gmail.com> Message-ID: <67DE0E0A-3A2E-4298-B5DA-D9891FAC1C27@apple.com> >> >> This looks like something is broken on the gcc side of things. Does a >> simple: >> >> void >> __attribute__((visibility ("hidden"))) >> foo() >> { } >> >> compile with your resultant compiler? > > > > also works when going to native .o or bytecode. Well, at least it's not completely broken :) -eric From baldrick at free.fr Wed Feb 6 12:50:16 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 6 Feb 2008 19:50:16 +0100 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> Message-ID: <200802061950.17701.baldrick@free.fr> > > Bill's change only affected darwin IIRC. I don't know that anyone has > > built GOMP on linux yet, and OpenMP hasn't been widely tested at all. > > I'd suggest using --enable-languages=c,c++ > > I am seeing the same errors with just building c,c++. (linux x86, also debian) This bit of Bill's patch did it: -#ifdef HAVE_GAS_HIDDEN + +#if !defined(ENABLE_LLVM) && defined(HAVE_GAS_HIDDEN) fprintf (asm_out_file, "\t.%s\t", type); assemble_name (asm_out_file, name); fprintf (asm_out_file, "\n"); #else warning (OPT_Wattributes, "visibility attribute not supported " "in this configuration; ignored"); #endif From isanbard at gmail.com Wed Feb 6 13:01:12 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 6 Feb 2008 11:01:12 -0800 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <060B7C42-8EF3-47B7-B832-A6894A85CF28@apple.com> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> <200802061854.26103.baldrick@free.fr> <060B7C42-8EF3-47B7-B832-A6894A85CF28@apple.com> Message-ID: <16e5fdf90802061101h5c0fa77q4760ea333738f502@mail.gmail.com> On Feb 6, 2008 10:05 AM, Eric Christopher wrote: > > On Feb 6, 2008, at 9:54 AM, Duncan Sands wrote: > > >>>> I suspect this is due to the recent change by Bill (revision > >>>> 46747). > >>> > >>> Bill's change only affected darwin IIRC. I don't know that anyone > >>> has > >>> built GOMP on linux yet, and OpenMP hasn't been widely tested at > >>> all. > >>> I'd suggest using --enable-languages=c,c++ > >> > >> I am seeing the same errors with just building c,c++. (linux x86, > >> also debian) > > > > There was a change to varasm.c that was not conditioned on being on > > darwin: > > > > + /* The "make_assemble_visibility" method may issue a warning if > > the visibility > > + attribute isn't supported in a configuration. This is all done > > through a > > + call-back. We want to issue this same warning when needed. */ > > + if (TREE_PUBLIC (decl)) > > + maybe_assemble_visibility (decl); > > > > It seems suspicious. > > It does seem odd, what was the reason for the change? > It's not suspicious. Look down about 3 lines after the ENABLE_LLVM if-def block. It's being called unconditionally for all platforms. The problem lies elsewhere. I made a mistake in my if-defs for the default_assemble_visibility function. -bw From echristo at apple.com Wed Feb 6 13:04:35 2008 From: echristo at apple.com (Eric Christopher) Date: Wed, 6 Feb 2008 11:04:35 -0800 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <200802061950.17701.baldrick@free.fr> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> <200802061950.17701.baldrick@free.fr> Message-ID: <356BAEDF-A926-40FB-B29A-AEDC5FD5BBA9@apple.com> On Feb 6, 2008, at 10:50 AM, Duncan Sands wrote: >>> Bill's change only affected darwin IIRC. I don't know that anyone >>> has >>> built GOMP on linux yet, and OpenMP hasn't been widely tested at >>> all. >>> I'd suggest using --enable-languages=c,c++ >> >> I am seeing the same errors with just building c,c++. (linux x86, >> also debian) > > This bit of Bill's patch did it: > > -#ifdef HAVE_GAS_HIDDEN > + > +#if !defined(ENABLE_LLVM) && defined(HAVE_GAS_HIDDEN) > fprintf (asm_out_file, "\t.%s\t", type); > assemble_name (asm_out_file, name); > fprintf (asm_out_file, "\n"); > #else > warning (OPT_Wattributes, "visibility attribute not supported " > "in this configuration; ignored"); > #endif > _______________________________________________ Aaah yes. That'd do it. -eric From isanbard at gmail.com Wed Feb 6 13:07:49 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 6 Feb 2008 11:07:49 -0800 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <200802061950.17701.baldrick@free.fr> References: <200802061210.38969.hs4233@mail.mn-solutions.de> <77FEC920-B67F-4AAE-A9B9-7E683FCC5A34@nondot.org> <85dfcd7f0802060926g77f5cb10i48dfb757eedd41f7@mail.gmail.com> <200802061950.17701.baldrick@free.fr> Message-ID: <16e5fdf90802061107h68a0ebcfv51e107f776ad0f31@mail.gmail.com> On Feb 6, 2008 10:50 AM, Duncan Sands wrote: > > > Bill's change only affected darwin IIRC. I don't know that anyone has > > > built GOMP on linux yet, and OpenMP hasn't been widely tested at all. > > > I'd suggest using --enable-languages=c,c++ > > > > I am seeing the same errors with just building c,c++. (linux x86, also debian) > > This bit of Bill's patch did it: > > -#ifdef HAVE_GAS_HIDDEN > + > +#if !defined(ENABLE_LLVM) && defined(HAVE_GAS_HIDDEN) > fprintf (asm_out_file, "\t.%s\t", type); > assemble_name (asm_out_file, name); > fprintf (asm_out_file, "\n"); > #else > warning (OPT_Wattributes, "visibility attribute not supported " > "in this configuration; ignored"); > #endif > Yes. :-( Sorry about that. I claim that it was late when I made the patch. ;-) Anyway, I corrected my logic. Try it now. -bw From isanbard at gmail.com Wed Feb 6 13:16:06 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 6 Feb 2008 11:16:06 -0800 Subject: [LLVMdev] Patch Causing Failure Message-ID: <16e5fdf90802061116w5b467b54h7a174aae8c4d828e@mail.gmail.com> Hi Owen, I'm seeing this failure on one of my machines -- PPC G5: $ # APPLE LOCAL use -mlongcall for large text support /Volumes/SandBox/Clean/bug/llvm-gcc.obj/./gcc/xgcc -B/Volumes/SandBox/Clean/bug/llvm-gcc.obj/./gcc/ -B/Volumes/SandBox/Clean/bug/llvm-gcc.install/powerpc-apple-darwin9.1.0/bin/ -B/Volumes/SandBox/Clean/bug/llvm-gcc.install/powerpc-apple-darwin9.1.0/lib/ -isystem /Volumes/SandBox/Clean/bug/llvm-gcc.install/powerpc-apple-darwin9.1.0/include -isystem /Volumes/SandBox/Clean/bug/llvm-gcc.install/powerpc-apple-darwin9.1.0/sys-include -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc.src/gcc -I../../llvm-gcc.src/gcc/. -I../../llvm-gcc.src/gcc/../include -I./../intl -I../../llvm-gcc.src/gcc/../libcpp/include -I../../llvm-gcc.src/gcc/../libdecnumber -I../libdecnumber -I/Volumes/SandBox/Clean/bug/llvm.src/include -I/Volumes/SandBox/Clean/bug/llvm.obj/include -mlongcall \ -c ../../llvm-gcc.src/gcc/config/darwin-crt2.c -o crt2.o xgcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See for instructions. make[3]: *** [crt2.o] Error 1 rm gpl.pod fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 xgcc: Internal error: Segmentation fault (program cc1) xgcc: Internal error: Segmentation fault (program cc1) I did a binary search, and it turns out that this patch was the first one that broke things: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080128/057882.html Could you take a look at it? I can give you access to my machine if you need it. Thanks! -bw From kyllercg at kyllercg.net Wed Feb 6 14:17:47 2008 From: kyllercg at kyllercg.net (=?ISO-8859-1?Q?Kyller_Costa_Gorg=F4nio?=) Date: Wed, 6 Feb 2008 17:17:47 -0300 Subject: [LLVMdev] Counting instructions In-Reply-To: References: <6fbb4ff20802050610l509e7d43m567a418e383b42e4@mail.gmail.com> Message-ID: <63ecd9cf0802061217o4b71438ej4fbb89cb40a12ee@mail.gmail.com> I'm not quite sure Chris. But I think Raul only wanna to execute some specific instruction about every X instructions. He probably don't need to modify the instruction generated, but only to count the number of machine instructions and execute something after. Am I right Raul? I believe he is trying to do that at the JIT level. These where my two bits.... :) In time, I don't know the answer for his question. cheers kyller On 2/5/08, Chris Lattner wrote: > On Tue, 5 Feb 2008, Raul Fernandes Herbster wrote: > > I need to instrument the code in order to generate an event (call a certain > > function) whenever X instructions have been executed. I'm using > > MachineFunctionPass to get machine-dependent representation of each LLVM > > function in the program. However, such pass doesn't allow to modify such > > functions. Is there any other class so I can modify MachineFunctions? > > I'm not sure I follow here: you want to insert your instrumentation at the > machine code level, but you want to change the llvm ir? Once the > instruction selection phase converts from llvm ir to machine code, the > LLVM IR is mostly ignored. Changing it won't cause a change in the > generated code. > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- |_|0|_| |_|_|0| |0|0|0| From georgebaah at gmail.com Wed Feb 6 17:22:40 2008 From: georgebaah at gmail.com (George Baah) Date: Wed, 6 Feb 2008 18:22:40 -0500 Subject: [LLVMdev] newbie questions Message-ID: Hi All, I am new to LLVM. I am trying to get the Hello example in "lib/Transform/Hello" to run. But when I do a make in the directory I get this error. I don't understand why it can't find these make files. ../../../Makefile.common:60: ../../../Makefile.config: No such file or directory ../../../Makefile.common:68: /Makefile.rules: No such file or directory Should i make changes to any of variables in "llvm/Make* files? Thanks George -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080206/5e254b7d/attachment.html From isanbard at gmail.com Wed Feb 6 18:37:41 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 6 Feb 2008 16:37:41 -0800 Subject: [LLVMdev] newbie questions In-Reply-To: References: Message-ID: <16e5fdf90802061637p1ff561adsde07b91c2364440@mail.gmail.com> On Feb 6, 2008 3:22 PM, George Baah wrote: > Hi All, > I am new to LLVM. I am trying to get the Hello example in > "lib/Transform/Hello" to run. But when I do a make in the directory > I get this error. I don't understand why it can't find these make files. > > ../../../Makefile.common:60: ../../../Makefile.config: No such file or > directory > ../../../Makefile.common:68: /Makefile.rules: No such file or directory > > > Should i make changes to any of variables in "llvm/Make* files? Thanks > Hi George, Did you run the "configure" script? -bw From georgebaah at gmail.com Wed Feb 6 19:32:28 2008 From: georgebaah at gmail.com (George Baah) Date: Wed, 6 Feb 2008 20:32:28 -0500 Subject: [LLVMdev] newbie questions In-Reply-To: <16e5fdf90802061637p1ff561adsde07b91c2364440@mail.gmail.com> References: <16e5fdf90802061637p1ff561adsde07b91c2364440@mail.gmail.com> Message-ID: Thanks Bill! it worked. On Feb 6, 2008 7:37 PM, Bill Wendling wrote: > On Feb 6, 2008 3:22 PM, George Baah wrote: > > Hi All, > > I am new to LLVM. I am trying to get the Hello example in > > "lib/Transform/Hello" to run. But when I do a make in the directory > > I get this error. I don't understand why it can't find these make files. > > > > ../../../Makefile.common:60: ../../../Makefile.config: No such file or > > directory > > ../../../Makefile.common:68: /Makefile.rules: No such file or directory > > > > > > Should i make changes to any of variables in "llvm/Make* files? Thanks > > > > Hi George, > > Did you run the "configure" script? > > -bw > _______________________________________________ > 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/20080206/cc6f9a54/attachment.html From hs4233 at mail.mn-solutions.de Thu Feb 7 02:04:18 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Thu, 7 Feb 2008 09:04:18 +0100 Subject: [LLVMdev] [PATCH] fix warning: 'NumFolded' defined but not used Message-ID: <200802070904.18335.hs4233@mail.mn-solutions.de> lib/CodeGen/RegAllocLocal.cpp:38: warning: 'NumFolded' defined but not used This has been introduced because of r46821. However, maybe removing just the variable isn't enought, because the comments in the section that got modified by 46821 are not optimal: if (PhysReg) { // Register is available, allocate it! assignVirtToPhysReg(VirtReg, PhysReg); } else { // No registers available. // If we can fold this spill into this instruction, do so now. This comment says that something should be folded. SmallVector Ops; Ops.push_back(OpNum); I don't understand the usage of Ops. Seems not to be used at all. // It looks like we can't fold this virtual register load into this // instruction. Force some poor hapless value out of the register file to // make room for the new register, and reload it. And this comment says that it can't have been folded, so the first comment seems to be superfluous. PhysReg = getReg(MBB, MI, VirtReg); } --- svn.llvm.orig/lib/CodeGen/RegAllocLocal.cpp +++ svn.llvm/lib/CodeGen/RegAllocLocal.cpp @@ -35,7 +35,6 @@ STATISTIC(NumStores, "Number of stores added"); STATISTIC(NumLoads , "Number of loads added"); -STATISTIC(NumFolded, "Number of loads/stores folded into instructions"); namespace { static RegisterRegAlloc @@ -500,12 +499,7 @@ if (PhysReg) { // Register is available, allocate it! assignVirtToPhysReg(VirtReg, PhysReg); } else { // No registers available. - // If we can fold this spill into this instruction, do so now. - SmallVector Ops; - Ops.push_back(OpNum); - - // It looks like we can't fold this virtual register load into this - // instruction. Force some poor hapless value out of the register file to + // Force some poor hapless value out of the register file to // make room for the new register, and reload it. PhysReg = getReg(MBB, MI, VirtReg); } From asl at math.spbu.ru Thu Feb 7 03:31:36 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 7 Feb 2008 12:31:36 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?V29ya2luZyBvbiBnZXR0aW5nIE1pbmdXMzIvbmF0aXZl?= =?koi8-r?b?IHRvb2xzLW9ubHkgc291cmNlIGJ1aWxkCXVw?= Message-ID: <200802070931.m179VaaO069078@star.math.spbu.ru> Hello, Kenneth > Libraries weren't being linked in; This means, that generation of llvm-config for you is broken. I really suggest to use perl from msys-DTK, not ActivePerl. -- WBR, Anton Korobeynikov From asl at math.spbu.ru Thu Feb 7 03:38:40 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 7 Feb 2008 12:38:40 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?c3RyYW5nZSB2aXNpYmlsaXR5IGVycm9yIHdoZW4gY29t?= =?koi8-r?b?cGlsaW5nIGxsdm0tZ2NjLTQuMg==?= Message-ID: <200802070938.m179ceaE070573@star.math.spbu.ru> Chris, > Bill's change only affected darwin IIRC. I don't know that anyone has > built GOMP on linux yet, and OpenMP hasn't been widely tested at all. > I'd suggest using --enable-languages=c,c++ GOMP was ok (w/o any warnings) for me for ages. -- WBR, Anton Korobeynikov From hs4233 at mail.mn-solutions.de Thu Feb 7 05:19:57 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Thu, 7 Feb 2008 12:19:57 +0100 Subject: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2 In-Reply-To: <200802070938.m179ceaE070573@star.math.spbu.ru> References: <200802070938.m179ceaE070573@star.math.spbu.ru> Message-ID: <200802071219.57492.hs4233@mail.mn-solutions.de> >> I'd suggest using --enable-languages=c,c++ > > GOMP was ok (w/o any warnings) for me for ages. Whatever the error was, it's now gone. Just some sidenotes: a) I used --enable-languages=c,c++ b) In llvm-gcc-4.2/Makefile.def you can see this target_modules = { module= libgomp; lib_path=.libs; }; and this // Target libraries installed under gcc need to be installed before gcc dependencies = { module=install-target-libssp; on=install-gcc; }; dependencies = { module=install-target-libgomp; on=install-gcc; }; I read this lines that libgomp always get's compiled. So it has nothing to to do with the --enable-languages thingy at all. From gabor at mac.com Thu Feb 7 11:51:00 2008 From: gabor at mac.com (Gabor Greif) Date: Thu, 07 Feb 2008 18:51:00 +0100 Subject: [LLVMdev] Imprecise description of malloc instruction Message-ID: <47AB4504.8040407@mac.com> Hi all, Quoting : The 'malloc' instruction allocates sizeof()*NumElements bytes of memory from the operating system and returns a pointer of the appropriate type to the program. If "NumElements" is specified, it is the number of elements allocated. Obviously this does not say that the default for NumElements is one. Even obvious assumptions should be *explicit* in a spec :-) May I reword as: The 'malloc' instruction allocates sizeof()*NumElements bytes of memory from the operating system and returns a pointer of the appropriate type to the program. If "NumElements" is specified, it is the number of elements allocated, otherwise "NumElements" is defaulted to be one. ? Cheers Gabor From mrs at apple.com Thu Feb 7 12:14:26 2008 From: mrs at apple.com (Mike Stump) Date: Thu, 7 Feb 2008 10:14:26 -0800 Subject: [LLVMdev] 2.2 garbage collector questions In-Reply-To: <47A90E88.7030901@rush.aero.org> References: <47A7DA7F.7010506@rush.aero.org> <47A90CB5.8060709@rush.aero.org> <47A90E88.7030901@rush.aero.org> Message-ID: <5589155D-4639-4223-B5F3-5C29A39C3F47@apple.com> On Feb 5, 2008, at 5:34 PM, Scott Michel wrote: > I realize there might be Lisp macro-like packages for other languages, I've seen eval and quote and friends added to C: s = `printf ("Hi\n"); eval s; :-) We could extend clang to do this. From evan.cheng at apple.com Thu Feb 7 13:47:02 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 7 Feb 2008 11:47:02 -0800 Subject: [LLVMdev] [PATCH] fix warning: 'NumFolded' defined but not used In-Reply-To: <200802070904.18335.hs4233@mail.mn-solutions.de> References: <200802070904.18335.hs4233@mail.mn-solutions.de> Message-ID: <14FD5811-DF39-4754-9841-6033091B16E6@apple.com> My fault. Patch applied. Thanks. Evan On Feb 7, 2008, at 12:04 AM, Holger Schurig wrote: > lib/CodeGen/RegAllocLocal.cpp:38: warning: 'NumFolded' defined but > not used > > This has been introduced because of r46821. > > However, maybe removing just the variable isn't enought, > because the comments in the section that got modified > by 46821 are not optimal: > > if (PhysReg) { // Register is available, allocate it! > assignVirtToPhysReg(VirtReg, PhysReg); > } else { // No registers available. > // If we can fold this spill into this instruction, do so now. > > This comment says that something should be folded. > > SmallVector Ops; > Ops.push_back(OpNum); > > I don't understand the usage of Ops. Seems not to be > used at all. > > // It looks like we can't fold this virtual register load into this > // instruction. Force some poor hapless value out of the > register file to > // make room for the new register, and reload it. > > And this comment says that it can't have been folded, > so the first comment seems to be superfluous. > > PhysReg = getReg(MBB, MI, VirtReg); > } > > > > --- svn.llvm.orig/lib/CodeGen/RegAllocLocal.cpp > +++ svn.llvm/lib/CodeGen/RegAllocLocal.cpp > @@ -35,7 +35,6 @@ > > STATISTIC(NumStores, "Number of stores added"); > STATISTIC(NumLoads , "Number of loads added"); > -STATISTIC(NumFolded, "Number of loads/stores folded into > instructions"); > > namespace { > static RegisterRegAlloc > @@ -500,12 +499,7 @@ > if (PhysReg) { // Register is available, allocate it! > assignVirtToPhysReg(VirtReg, PhysReg); > } else { // No registers available. > - // If we can fold this spill into this instruction, do so now. > - SmallVector Ops; > - Ops.push_back(OpNum); > - > - // It looks like we can't fold this virtual register load into > this > - // instruction. Force some poor hapless value out of the > register file to > + // Force some poor hapless value out of the register file to > // make room for the new register, and reload it. > PhysReg = getReg(MBB, MI, VirtReg); > } > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From raulherbster at gmail.com Thu Feb 7 14:16:56 2008 From: raulherbster at gmail.com (Raul Fernandes Herbster) Date: Thu, 7 Feb 2008 17:16:56 -0300 Subject: [LLVMdev] Problems with instrumentation Message-ID: <6fbb4ff20802071216n398d90ffwa3761ba14fa4b16@mail.gmail.com> Hi, I'm trying to instrument llvm bytecodes using opt. I performed the following commands: llvm-gcc -g -emit-llvm test.c -c -o test.bc opt -insert-edge-profiling test.bc -o output.bc llc output.bc -o output.s gcc output.s -o test.out However, it can't find symbol llvm_start_edge_profiling. /tmp/ccw7GH4c.o: In function `main': /home/raul/LLVM/tests//test.c:8: undefined reference to `llvm_start_edge_profiling' collect2: ld returned 1 exit status Does anybody know which is the problem? I'm using LLVM 2.1 and LLVM-GCC 4.2 (both were built from SVN source code). Thanks in advance, Raul. -- Raul Fernandes Herbster Embedded and Pervasive Computing Laboratory - embedded.ufcg.edu.br Electrical Engineering and Informatics Center - CEEI Federal University of Campina Grande - UFCG - www.ufcg.edu.br Caixa Postal 10105 58109-970 Campina Grande - PB - Brasil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080207/a7b9efa2/attachment.html From zaimoni at zaimoni.com Thu Feb 7 15:50:55 2008 From: zaimoni at zaimoni.com (Kenneth Boyd) Date: Thu, 07 Feb 2008 15:50:55 -0600 Subject: [LLVMdev] Working on getting MingW32/native tools-only source build up In-Reply-To: <200802070931.m179VaaO069078@star.math.spbu.ru> References: <200802070931.m179VaaO069078@star.math.spbu.ru> Message-ID: <47AB7D3F.2030303@zaimoni.com> Anton Korobeynikov wrote: > Hello, Kenneth > > >> Libraries weren't being linked in; >> > This means, that generation of llvm-config for you is broken. I really > Actually, the minimal change set to get this working is: * tools/llvm-config/llvm-config.in.in (so the system can find the libraries) ** if the $PWD approach fails, fallover to Cwd module's abspath * utils/GenLibDeps.pl (so the system links in the extra libraries beyond what is specified in the makefiles) ** if the extended pipe filtering fails, fallover to doing the sed/sort/uniq work in Perl directly. I can provide patches for either of these if there's interest. > suggest to use perl from msys-DTK, not ActivePerl. > Yes, but ActivePerl's distribution is historically the normal one for Windows (and is by far the easiest one on Windows to install Crypt::SSLeay for; this pretty much dictates which one I normally use.). Best Regards, Kenneth Boyd From wmatyjewicz at fastmail.fm Thu Feb 7 17:04:35 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Fri, 08 Feb 2008 00:04:35 +0100 Subject: [LLVMdev] Problems with instrumentation In-Reply-To: <6fbb4ff20802071216n398d90ffwa3761ba14fa4b16@mail.gmail.com> References: <6fbb4ff20802071216n398d90ffwa3761ba14fa4b16@mail.gmail.com> Message-ID: <47AB8E83.4050409@fastmail.fm> Hi, > llvm-gcc -g -emit-llvm test.c -c -o test.bc > opt -insert-edge-profiling test.bc -o output.bc > llc output.bc -o output.s > gcc output.s -o test.out > > However, it can't find symbol llvm_start_edge_profiling. -insert-edge-profiling inserts call to the llvm_start_edge_profiling function which is a part of a profiling runtime library. This library must be linked into your executable. The runtime library isn't built automatically. To build it, please, run make in the $LLVMOBJDIR/runtime directory. If it complains about LLVMGCCDIR not set, it means you have to reconfigure LLVM with --enable-llvmgccdir option. You may also find some useful information in this thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-January/012315.html -Wojtek From hs4233 at mail.mn-solutions.de Fri Feb 8 02:08:13 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Fri, 8 Feb 2008 09:08:13 +0100 Subject: [LLVMdev] Problems with instrumentation In-Reply-To: <47AB8E83.4050409@fastmail.fm> References: <6fbb4ff20802071216n398d90ffwa3761ba14fa4b16@mail.gmail.com> <47AB8E83.4050409@fastmail.fm> Message-ID: <200802080908.13756.hs4233@mail.mn-solutions.de> Compiling the runtime doesn't work with r46884: llvm[2]: Compiling CommonProfiling.c for Release build (PIC) /usr/src/llvm/obj.llvm/Release/bin/llvm-as: /usr/src/llvm/obj.llvm/runtime/GC/SemiSpace/Release/semispace.ll:3,0: /usr/src/llvm/obj.llvm/runtime/GC/SemiSpace/Release/semispace.ll:3: error: syntax error, unexpected $undefined, expecting GLOBAL or CONSTANT while reading token: '.' From romixlev at yahoo.com Fri Feb 8 10:59:49 2008 From: romixlev at yahoo.com (Roman Levenstein) Date: Fri, 8 Feb 2008 17:59:49 +0100 (CET) Subject: [LLVMdev] Some questions about live intervals In-Reply-To: <39292179-AC6F-4D45-940B-00231DCF40DE@apple.com> Message-ID: <757650.26071.qm@web56312.mail.re3.yahoo.com> Hi Evan, Here is a patch for the LiveIntervalAnalysis that we discussed. --- Evan Cheng schrieb: > > 1) What is the easiest way to understand which MBB a given > instruction index belongs to? All the required information is > available in the > > MBB2IdxMap of the LiveIntervalAnalysis class. Would it be useful > to add a small function getMBBFromIndex() to this class? > > Sure there is a reverse map (actually just a vector) Idx2MBBMap. > Justadd a query. Done. Please find a patch attached to this mail. > > As for (1) and (2), I could implement and provide patches for it, > > if you think this is desirable. > > Yes, thanks. Here you are! -Roman Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go -------------- next part -------------- A non-text attachment was scrubbed... Name: LiveIntervalAnalysis.patch Type: text/x-diff Size: 2377 bytes Desc: 2881029184-LiveIntervalAnalysis.patch Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080208/5cfee60e/attachment.bin From scottm at rushg.aero.org Fri Feb 8 20:43:52 2008 From: scottm at rushg.aero.org (Scott Michel) Date: Fri, 08 Feb 2008 18:43:52 -0800 Subject: [LLVMdev] tblgen and sign-extended constants too large for type Message-ID: <47AD1368.1030005@rush.aero.org> Question: How hard should tblgen try to fit constants into a particular type? My case is an xor with i8 immediate where I'm using 0xff in as the immediate value. 0xff should fit into i8 if treated as unsigned, but CodeGenDAGPatterns.cpp assumes that any and all integers less than 32-bits are signed. Should tblgen try to see if the sign-extended version of the constant could fit into the type, and failing that, try the unsigned version: Index: utils/TableGen/CodeGenDAGPatterns.cpp =================================================================== --- utils/TableGen/CodeGenDAGPatterns.cpp (revision 8028) +++ utils/TableGen/CodeGenDAGPatterns.cpp (working copy) @@ -685,10 +685,17 @@ // Make sure that the value is representable for this type. if (Size < 32) { int Val = (II->getValue() << (32-Size)) >> (32-Size); - if (Val != II->getValue()) - TP.error("Sign-extended integer value '" + itostr(II->getValue())+ - "' is out of range for type '" + - getEnumName(getTypeNum(0)) + "'!"); + if (Val != II->getValue()) { + // If sign-extended doesn't fit, does it fit as unsigned? + unsigned ValueMask = unsigned(MVT::getIntVTBitMask(VT)); + unsigned UnsignedVal = unsigned(II->getValue()); + + if ((ValueMask & UnsignedVal) != UnsignedVal) { + TP.error("Integer value '" + itostr(II->getValue())+ + "' is out of range for type '" + + getEnumName(getTypeNum(0)) + "'!"); + } + } From oscarfv at telefonica.net Sat Feb 9 09:42:36 2008 From: oscarfv at telefonica.net (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Sat, 09 Feb 2008 16:42:36 +0100 Subject: [LLVMdev] Annotate a value. Message-ID: Hello. It would be very useful for my project being able to annotate Value's. An int would do fine. I found an old message with this same subject talking about the Annotation interface and Annotable object, but the doxygen graphs says that only Function is annotable. Could I use the ValueName for the job? It would be enough, although quite clumsy. Seems that Value's of type void can't be named (no problem) but I'll need to name Constants, and this is not allowed. Any suggestion, apart from modifying my LLVM sources? -- Oscar From sabre at nondot.org Sat Feb 9 11:01:45 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 9 Feb 2008 09:01:45 -0800 Subject: [LLVMdev] Annotate a value. In-Reply-To: References: Message-ID: <3A3E62A1-C1A6-4E1E-86BB-A386C7EEE06B@nondot.org> On Feb 9, 2008, at 7:42 AM, ?scar Fuentes wrote: > Hello. > > It would be very useful for my project being able to annotate > Value's. An int would do fine. > > I found an old message with this same subject talking about the > Annotation interface and Annotable object, but the doxygen graphs says > that only Function is annotable. > > Could I use the ValueName for the job? It would be enough, although > quite clumsy. Seems that Value's of type void can't be named (no > problem) but I'll need to name Constants, and this is not allowed. > > Any suggestion, apart from modifying my LLVM sources? I strongly suggest just using a hash table or map like DenseMap. This is generally more efficiently than a separately allocated annotation object. -Chris From tneumann at users.sourceforge.net Sat Feb 9 08:53:47 2008 From: tneumann at users.sourceforge.net (Thomas Neumann) Date: Sat, 9 Feb 2008 15:53:47 +0100 Subject: [LLVMdev] exception handling broken on x86-64? Message-ID: <20080209155347.7a6b3c6c@jaiman> Hi, when building the second release candidate of llvm 2.2 I noticed that exception handling seems to be broken on Linux x86-64. The exception is thrown but never caught. This can be seen by this trivial example: #include using namespace std; class A { }; int main() { cout << "A" << endl; try { cout << "B" << endl; throw A(); cout << "C" << endl; } catch (const A&) { cout << "D" << endl; } cout << "E" << endl; } When compiled with llvm-g++ it aborts after printing "B". The generated assembler code looks reasonable at a first glance, but something must be broken. Any ideas about how to debug this? I build the gcc 4.2 snapshot from the second release candidate with --disable-multilib and --disable-shared to get it to build (as suggested by the readme). llvm itself was build without special options. Thomas From sabre at nondot.org Sat Feb 9 12:14:25 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 9 Feb 2008 10:14:25 -0800 Subject: [LLVMdev] Imprecise description of malloc instruction In-Reply-To: <47AB4504.8040407@mac.com> References: <47AB4504.8040407@mac.com> Message-ID: On Feb 7, 2008, at 9:51 AM, Gabor Greif wrote: > Hi all, > > Quoting : > > The 'malloc' instruction allocates sizeof()*NumElements bytes > of > memory from the operating system and returns a pointer of the > appropriate type > to the program. If "NumElements" is specified, it is the number of > elements allocated. > > > Obviously this does not say that the default for NumElements is one. > Even obvious assumptions should be *explicit* in a spec :-) > > May I reword as: > > The 'malloc' instruction allocates sizeof()*NumElements bytes > of > memory from the operating system and returns a pointer of the > appropriate type > to the program. If "NumElements" is specified, it is the number of > elements allocated, > otherwise "NumElements" is defaulted to be one. Looks great, please do Gabor. The description for alloca also needs update probably. Thanks! -Chris From dalej at apple.com Sat Feb 9 12:39:24 2008 From: dalej at apple.com (Dale Johannesen) Date: Sat, 9 Feb 2008 10:39:24 -0800 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: <20080209155347.7a6b3c6c@jaiman> References: <20080209155347.7a6b3c6c@jaiman> Message-ID: <6CD67941-8905-4AB0-A5E3-4CE659E8F9BB@apple.com> On Feb 9, 2008, at 6:53 AM, Thomas Neumann wrote: > Hi, > > when building the second release candidate of llvm 2.2 I noticed that > exception handling seems to be broken on Linux x86-64. The exception > is > thrown but never caught. > This can be seen by this trivial example: > > #include > using namespace std; > class A { }; > int main() > { > cout << "A" << endl; > try { > cout << "B" << endl; > throw A(); > cout << "C" << endl; > } catch (const A&) { > cout << "D" << endl; > } > cout << "E" << endl; > } Works for me on x86-64 Darwin, fwiw. I made EH work in that environment with 46029, and it's possible I broke Linux when I did that, although I don't think so. Anybody tried this since January 16? If the assembler code looks right there is probably something wrong in the Dwarf metadata. Try comparing with the output of g++; you'll need some understanding of Dwarf. The options -asm-verbose on llvm and -dA on g++ will give you some debugging info. > When compiled with llvm-g++ it aborts after printing "B". The > generated > assembler code looks reasonable at a first glance, but something must > be broken. Any ideas about how to debug this? > > I build the gcc 4.2 snapshot from the second release candidate with > --disable-multilib and --disable-shared to get it to build (as > suggested by the readme). llvm itself was build without special > options. > > Thomas > > > _______________________________________________ > 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 Sat Feb 9 13:11:05 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sat, 9 Feb 2008 22:11:05 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?ZXhjZXB0aW9uIGhhbmRsaW5nIGJyb2tlbiBvbiB4ODYt?= =?koi8-r?b?NjQ/?= Message-ID: <200802091911.m19JB5vA062801@star.math.spbu.ru> Hello, Thomas > when building the second release candidate of llvm 2.2 I noticed that > exception handling seems to be broken on Linux x86-64. The exception EH never worked on x86-64. Mainly due to absence of intrinsics used in unwinding runtime. Also, some other important stuff is missed as well (like stack layout information). > When compiled with llvm-g++ it aborts after printing "B". The generated > assembler code looks reasonable at a first glance, It shouldn't. At least all frame moves information is missing. > but something must be broken. Any ideas about how to debug this? I'd suggest to start with filling necessary bits in the X86RegisterInfo.cpp. This includes frame moves information and description of stack layout. Then you can proceed to x86-64-specific lowering of some important intrinsics. You can link your code with native g++ in order to use gcc-provided (and thus working) runtime. -- WBR, Anton Korobeynikov From asl at math.spbu.ru Sat Feb 9 13:20:03 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sat, 9 Feb 2008 22:20:03 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?ZXhjZXB0aW9uIGhhbmRsaW5nIGJyb2tlbiBvbiB4ODYt?= =?koi8-r?b?NjQ/?= Message-ID: <200802091920.m19JK34G065061@star.math.spbu.ru> Dale, > Works for me on x86-64 Darwin, fwiw. That looks pretty strange. Ok, it can work for small testcases, but will surely fail when you try to use for something more real. Currently it at least lacks information about frame moves. So, every invoke, which needs to restore call-clobbered registers during unwinding will be broken. Does Shootout-C++/except work for you? And stuff from llvm testsuite like omnetpp and xalan ? Also, Darwin is different than Linux, because Darwin's unwinding runtime is native one, not built by llvm-gcc. -- WBR, Anton Korobeynikov From dalej at apple.com Sat Feb 9 13:48:58 2008 From: dalej at apple.com (Dale Johannesen) Date: Sat, 9 Feb 2008 11:48:58 -0800 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: <200802091920.m19JK34G065061@star.math.spbu.ru> References: <200802091920.m19JK34G065061@star.math.spbu.ru> Message-ID: On Feb 9, 2008, at 11:20 AM, Anton Korobeynikov wrote: > Dale, > >> Works for me on x86-64 Darwin, fwiw. > That looks pretty strange. Ok, it can work for small testcases, but > will > surely fail when you try to use for something more real. Currently > it at > least lacks information about frame moves. So, every invoke, which > needs > to restore call-clobbered registers during unwinding will be broken. > > Does Shootout-C++/except work for you? And stuff from llvm testsuite > like omnetpp and xalan ? Everything in the llvm testsuite works. > Also, Darwin is different than Linux, because Darwin's unwinding > runtime > is native one, not built by llvm-gcc. I didn't look too hard, but it looks like the x86-64 info is only slightly modified from the x86-32 info on darwin (in gcc). A few fields were extended to 64 bits but it was not far off. So what was there mostly just worked. You may be right that there are problems that haven't shown up yet. From dalej at apple.com Sat Feb 9 13:50:29 2008 From: dalej at apple.com (Dale Johannesen) Date: Sat, 9 Feb 2008 11:50:29 -0800 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: References: <200802091920.m19JK34G065061@star.math.spbu.ru> Message-ID: <16AE2405-355D-4CA3-A4B8-8E76A6F850A0@apple.com> On Feb 9, 2008, at 11:48 AM, Dale Johannesen wrote: > > On Feb 9, 2008, at 11:20 AM, Anton Korobeynikov wrote: > >> Dale, >> >>> Works for me on x86-64 Darwin, fwiw. >> That looks pretty strange. Ok, it can work for small testcases, but >> will >> surely fail when you try to use for something more real. Currently >> it at >> least lacks information about frame moves. So, every invoke, which >> needs >> to restore call-clobbered registers during unwinding will be broken. >> >> Does Shootout-C++/except work for you? And stuff from llvm testsuite >> like omnetpp and xalan ? > > Everything in the llvm testsuite works. And the gcc testsuite - well, there are a couple of failures, but I looked at them and am convinced they are not problems with the EH mechanism. >> Also, Darwin is different than Linux, because Darwin's unwinding >> runtime >> is native one, not built by llvm-gcc. > > I didn't look too hard, but it looks like the x86-64 info is only > slightly modified from the x86-32 info on darwin (in gcc). A few > fields were extended to 64 bits but it was not far off. So what was > there mostly just worked. You may be right that there are problems > that haven't shown up yet. > From tneumann at users.sourceforge.net Sat Feb 9 15:12:45 2008 From: tneumann at users.sourceforge.net (Thomas Neumann) Date: Sat, 9 Feb 2008 22:12:45 +0100 Subject: [LLVMdev] exception handling broken on x86-64? References: <20080209155347.7a6b3c6c@jaiman> <6CD67941-8905-4AB0-A5E3-4CE659E8F9BB@apple.com> Message-ID: <20080209221245.1010dc87@jaiman> > If the assembler code looks right there is probably something wrong > in the Dwarf metadata. Try comparing with the output of g++; you'll > need some understanding of Dwarf. The options -asm-verbose on llvm > and -dA on g++ will give you some debugging info. llvm-g++ and native g++ seem to produce equivalent assembler code. I only compared the part from start of main to the throw statement, they are functional identical. The problem apparently is the catch part. Comparing the assembler dumps is not the most intuitive task... But I noticed that the native g++ apparently includes much more information than llcm-g++. For example it writes data in section ".eh_frame", which sounds suspiciously like exception handling info, which is not written by llvm. Is this expected or is exception handling completely unimplemented on Linux/x86-64? Thomas From tneumann at users.sourceforge.net Sat Feb 9 15:56:32 2008 From: tneumann at users.sourceforge.net (Thomas Neumann) Date: Sat, 9 Feb 2008 22:56:32 +0100 Subject: [LLVMdev] exception handling broken on x86-64? References: <200802091911.m19JB5vA062801@star.math.spbu.ru> Message-ID: <20080209225632.08176787@jaiman> > I'd suggest to start with filling necessary bits in the > X86RegisterInfo.cpp. This includes frame moves information and > description of stack layout. I looked at X86RegisterInfo.cpp, but I think that it already supports x86-64. At least there were no obvious places were the code would only work for 32bit mode. After comparing the generated assembler code with native gcc code I think the generated code is fine, just the exception handler info in the non-code sections is broken/missing. Thomas From asl at math.spbu.ru Sat Feb 9 16:28:00 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 10 Feb 2008 01:28:00 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?ZXhjZXB0aW9uIGhhbmRsaW5nIGJyb2tlbiBvbiB4ODYt?= =?koi8-r?b?NjQ/?= Message-ID: <200802092228.m19MS0XR018793@star.math.spbu.ru> Hello, Thomas > The problem apparently is the catch part. Catching is done by gcc unwinding runtime. Which is, in your case (--disable-shared), compiled by llvm and thus is definitely broken. What if you link the llvm-generated .S file with native g++ ? > writes data in section ".eh_frame", which sounds suspiciously like > exception handling info, which is not written by llvm. Is this expected > or is exception handling completely unimplemented on Linux/x86-64? Well, it's "expected, because unimplemented" :). The contents of ".eh_frame" section (aka EH common frame information) is among the missed stuff, I talked about. -- WBR, Anton Korobeynikov From asl at math.spbu.ru Sat Feb 9 16:48:05 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 10 Feb 2008 01:48:05 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?ZXhjZXB0aW9uIGhhbmRsaW5nIGJyb2tlbiBvbiB4ODYt?= =?koi8-r?b?NjQ/?= Message-ID: <200802092248.m19Mm5GV066405@star.math.spbu.ru> Hello, Thomas > > I'd suggest to start with filling necessary bits in the > > X86RegisterInfo.cpp. This includes frame moves information and > > description of stack layout. > I looked at X86RegisterInfo.cpp, but I think that it already supports > x86-64. At least there were no obvious places were the code would only > work for 32bit mode. Right. See my last e-mail to Dale. It's really amazing :) > After comparing the generated assembler code with native gcc code I > think the generated code is fine, just the exception handler info in > the non-code sections is broken/missing. It seems, that EH dwarf information emission is disabled in X86TargetAsmInfo.cpp. Remove the is64Bit() condition near "SupportExceptionHandling = true" line in X86Subtarget::isELF section. Also, don't forget to add --enable-eh switch to llc invocation. You will need to link .S with your native unwinding runtime (so, use g++ to link, not llvm-g++) -- WBR, Anton Korobeynikov From tneumann at users.sourceforge.net Sat Feb 9 16:49:52 2008 From: tneumann at users.sourceforge.net (Thomas Neumann) Date: Sat, 9 Feb 2008 23:49:52 +0100 Subject: [LLVMdev] exception handling broken on x86-64? References: <200802092228.m19MS0XR018793@star.math.spbu.ru> Message-ID: <20080209234952.7fe36232@jaiman> > Catching is done by gcc unwinding runtime. Which is, in your case > (--disable-shared), compiled by llvm and thus is definitely broken. > What if you link the llvm-generated .S file with native g++ ? same behavior. The abort message changes (only the string, the meaning is identical), but otherwise the same. The exception is not caught and thus terminate -> abort is called. > Well, it's "expected, because unimplemented" :). The contents of > ".eh_frame" section (aka EH common frame information) is among the > missed stuff, I talked about. I see. Shouldn't there be an open bug about this? I had checked Bugzilla before posting here, but could not find anything. Could you perhaps point me more explicitly to the place where x86-64 support would have to be implemented? I searched around X86RegisterInfo.cpp a bit but I do not see why the 32bit mode should work and the 64bit mode not. Thomas From dalej at apple.com Sat Feb 9 16:57:45 2008 From: dalej at apple.com (Dale Johannesen) Date: Sat, 9 Feb 2008 14:57:45 -0800 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: <200802092248.m19Mm5GV066405@star.math.spbu.ru> References: <200802092248.m19Mm5GV066405@star.math.spbu.ru> Message-ID: <010CA658-2EEB-4A1E-96BA-7EF1EF00F044@apple.com> On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >> After comparing the generated assembler code with native gcc code I >> think the generated code is fine, just the exception handler info in >> the non-code sections is broken/missing. > It seems, that EH dwarf information emission is disabled in > X86TargetAsmInfo.cpp. Remove the is64Bit() condition near > "SupportExceptionHandling = true" line in X86Subtarget::isELF section. > > Also, don't forget to add --enable-eh switch to llc invocation. Just in case it doesn't work the first time:) patch 46029 might be helpful. That made it work on Darwin for me, and it's possible some of the changes there are also applicable to Linux. Compare your .s with g++ output. > You will need to link .S with your native unwinding runtime (so, use > g++ > to link, not llvm-g++) This is not necessary on Darwin, btw, the unwinding stuff Just Worked too. From spectre9 at gmail.com Sat Feb 9 20:23:13 2008 From: spectre9 at gmail.com (Patrick) Date: Sat, 9 Feb 2008 20:23:13 -0600 Subject: [LLVMdev] semicolon breaking builds on llvm-gcc4.2 cygwin build for arm target 2.2prerelease2 Message-ID: Since we are fast approaching the 10th, I thought it appropriate to report this "bug" with the build despite not having worked around it. Build environment is *Summary:* When building llvm-gcc with a arm-apple-darwin target on i686-pc-cygwin, make fails because child calls to configure have an errant semicolon that causes the --srcdir parameter to be ignored by the configure script. This causes the builds in the host-i686-pc-cygwin directory to fail unnecessarily. Removing said semicolon from the configure calls and running 'make' manually succeeds. *Configure Parameters for **llvm-gcc:* (from /cygdrive/e/llvm-gcc4.2-2.2.source/config.status) config.status:# ./configure --enable-llvm=/cygdrive/e/llvm-2.2--target=arm-ap ple-darwin --enable-sjlj-exceptions --with-heavenly=/usr/local/share/iphone-file system --with-gcc=/usr/bin/gcc --program-prefix=arm-apple-darwin --with-as=/usr/ local/bin/llvm-as --with-ld=/usr/local/bin/llvm-ld --enable-languages=c,c++,objc ,obj-c++ *Root Cause?:* I believe this problem is caused by --srcdir appearing after the program_transform_name substitutions. This problem was likely introduced within this change +if test "$program_transform_name" = s,x,x,; then Revision *43990*- ( view) (download) (annotate) - [select for diffs] Modified *Sat Nov 10 22:32:06 2007 CST* (2 months, 4 weeks ago) by *void* Original Path: *llvm-gcc-4.2/trunk/configure* File length: 244731 byte(s) Diff to previous 43921( colored) Update configure scripts to build the Apple Way *Fix:* To maintain computability with the 'Apple way of building', while also enabling compatability for Apple platforms, I suggest moving the } ${ml_srcdiroption} options prior to the ${ac_configure_args} when generating calls to ./configure from 'make' *Closing Comments:* I've yet to complete an entire build, but wanted to report this bug now in case the llvm-gcc team would like to address this problem on Cygwin builds prior to the release. It seems easy enough to fix. I will report back further after I complete the build, and may also install these sources on a clean install of Cygwin to see if I can reproduce the problem. It appears this bug can be corrected rather easily by moving --srcdir as I have suggested. -- Patrick Hennessey -- Dallas, TX *Problem Description* For each host- subdir, the --srcdir parameter follows a semicolon, which to my bash shell means that --srcdir is a second command to execute, rather than a parameter to the configure. I believe this problem would be mitigated by --srcdir appearing before --program-transform-name in the generated invocations of configure. It might to be related these lines in the top level configure which contain said semicolon: - if test "$program_transform_name" = s,x,x,; then - program_transform_name="*s,^,${program_prefix},; * $program_transform_name" - program_transform_name="*s,\$\$,${program_suffix},;*$program_transform_name" Here is an example from *config.log * for* llvm-gcc4.2-2.2.source/** host-i686-pc-cygwin/gcc* (fixincludes, libiberty and intl already were 'fixed' per my 'solution') $ grep configure config.log |head -3 running configure, to aid debugging if configure makes a mistake. It was created by configure, which was $ /cygdrive/e/llvm-gcc4.2-2.2.source/gcc/configure --cache-file=./config.cac --build=i686-pc-cygwin --host=i686-pc-cygwin --target=arm-apple-darwin --enab -llvm=/cygdrive/e/llvm-2.2 --enable-sjlj-exceptions --with-gcc=/usr/bin/gcc --with-as=/usr/local/bin/llvm-as --with-ld=/usr/local/bin/llvm-ld --enable-languages=c,c++,objc,obj-c++ --program-transform-name=s,^,arm-apple-darwin,; --srcdir=../.././gcc Its an easy fix to get these to compile, though: - cd host-i686-pc-cygwin/gcc/ - grep configure config.log|head -3|tail -1 | perl -pe 's/\;//;s/^\s+\$//;' > newonfig.sh - bash newconfig.sh - make $ cat newconfig.sh /cygdrive/e/llvm-gcc4.2-2.2.source/gcc/configure --cache-file=./config.cache -- build=i686-pc-cygwin --host=i686-pc-cygwin --target=arm-apple-darwin --enable-ll vm=/cygdrive/e/llvm-2.2 --enable-sjlj-exceptions --with-gcc=/usr/bin/gcc --with-as=/usr/local/bin/llvm-as --w ith-ld=/usr/local/bin/llvm-ld --enable-languages=c,c++,objc,obj-c++ --program-tr ansform-name=s,^,arm-apple-darwin, --srcdir=../.././gcc Below is the first top-level error generated by 'make' after configure (for fixincludes) This sort of error is generated for each subdirectory target under ./llvm-gcc4.2-2.2.source/host-i686-pc-cygwin. Each time I get the error, I can correct the invocation of configure and build using the Perl rewrite appearing above. $ make make[1]: Entering directory `/cygdrive/e/llvm-gcc4.2-2.2.source' make[2]: Entering directory `/cygdrive/e/llvm-gcc4.2-2.2.source /host-i686-pc-cyg win/libiberty' make[3]: Entering directory `/cygdrive/e/llvm-gcc4.2-2.2.source /host-i686-pc-cyg win/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/e/llvm-gcc4.2-2.2.source /host-i686-pc-cygw in/libiberty/testsuite' make[2]: Leaving directory `/cygdrive/e/llvm-gcc4.2-2.2.source /host-i686-pc-cygw in/libiberty' make[2]: Entering directory `/cygdrive/e/llvm-gcc4.2-2.2.source /host-i686-pc-cyg win/fixincludes' make[2]: *** No rule to make target `/cygdrive/e/llvm-gcc4.2-2.2.source /fixinclu des/Makefile.in', needed by `Makefile'. Stop. make[2]: Leaving directory `/cygdrive/e/llvm-gcc4.2-2.2.source /host-i686-pc-cygw in/fixincludes' make[1]: *** [all-fixincludes] Error 2 make[1]: Leaving directory `/cygdrive/e/llvm-gcc4.2-2.2.source' make: *** [all] Error 2 $ cd /cygdrive/e/llvm-gcc4.2-2.2.source/host-i686-pc-cygwin/fixincldes $ grep configure config.log |head -20 running configure, to aid debugging if configure makes a mistake. It was created by fixincludes configure , which was $ /cygdrive/e/llvm-gcc4.2-2.2.source/fixincludes/configure --cache-file=./con ig.cache --build=i686-pc-cygwin --host=i686-pc-cygwin --target=arm-apple-darwin --enable-llvm=/cygdrive/e/llvm-2.2 --enable-sjlj-exceptions --with-gcc=/usr/bin/gc c --enable-languages=c,c++ objc,obj-c++ --program-transform-name=s,^,arm-apple-darwin, --srcdir=/cygdrive/ /llvm-gcc4.2-2.2.source/fixincludes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080209/c1c1d1c2/attachment-0001.html From clattner at apple.com Sun Feb 10 02:25:57 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 10 Feb 2008 00:25:57 -0800 Subject: [LLVMdev] LLVM 2.2 Release Notes Message-ID: Hi All, The first draft of the llvm 2.2 release notes are now available: http://llvm.org/docs/ReleaseNotes.html The release is scheduled for Monday, so please take a look at them and send me your feedback, or (better yet) just commit fixes directly to the document in llvm/docs/ReleaseNotes.html. In addition to editing improvements I'm particularly interested in adding missing things to the document and getting credit to the right people. Please don't be shy about letting me know if I got something wrong. The release is an amazing release, LLVM 2.2 rocks! -Chris From xf27 at arcor.de Sun Feb 10 02:58:42 2008 From: xf27 at arcor.de (Thomas =?UTF-8?B?SMO8aG4=?=) Date: Sun, 10 Feb 2008 09:58:42 +0100 Subject: [LLVMdev] Better IDEs/code editors because of LLVM? Message-ID: <2824800.uAeYqRHSFb@mid.thomas-huehn.de> Hi I am not sure whether I understand the goals and proposed features of your project, so I'd like to ask. I'll just pick out one little aspect: I think you are developing a compiler that provides "cleaner" and easier access to its internals (AST, semantic annotations etc.). If that is true my personal hope would be that IDEs and code editors would be created (by third parties) that truly understand C++ ("jump to declaration", "which overload is selected?" etc). I don't think there is such a beast yet that really follows C++'s name lookup rules (especially when it comes to templates). Do I get this right? If so, where could I read more about your plans? If not, where am I wrong? Thomas From robert.a.zeh at gmail.com Sun Feb 10 07:33:37 2008 From: robert.a.zeh at gmail.com (Robert Zeh) Date: Sun, 10 Feb 2008 07:33:37 -0600 Subject: [LLVMdev] Instrumenting virtual function calls Message-ID: <7092525B-2271-4C33-A612-226E076331D7@gmail.com> I'm attempting to instrument virtual function calls in my code. After each virtual call I'm calling my own registerMethod function, with an integer marking the location of the call and a pointer to the function that was called. However, and this is where I get confused, the function pointer doesn't match any of the functions in my module. I'd hoped to call ExecutionEngine::getGlobalValueAtAddress to get a Function* for the virtual function, but ExecutionEngine::getGlobalValueAtAddress returns null. If I look up the virtual function that is getting called (with ExeuctionEngine::getPointerToFunction) it doesn't match the arguments being passed to my instrumentation. What's a little strange is that the pointers are somewhat close: getPointerToFunction returns 0x47829a0, but my instrumentation gets 0x477fc10. What am I missing? Lines starting with "!" are the instrumented lines. define double @Return() { entry: %this = load %"struct.Q::BinaryOperation"** @q_constant2 ; < %"struct.Q::BinaryOperation"*> [#uses=2] %tmp9.i = getelementptr %"struct.Q::BinaryOperation"* %this, i32 0, i32 2, i32 0 ; <%"struct.Q::Function"**> [#uses=1] %tmp10.i = load %"struct.Q::Function"** %tmp9.i, align 4 ; < %"struct.Q::Function"*> [#uses=2] %tmp17.i = getelementptr %"struct.Q::BinaryOperation"* %this, i32 0, i32 1, i32 0 ; <%"struct.Q::Function"**> [#uses=1] %tmp18.i = load %"struct.Q::Function"** %tmp17.i, align 4 ; < %"struct.Q::Function"*> [#uses=2] %tmp33.i = getelementptr %"struct.Q::Function"* %tmp18.i, i32 0, i32 0, i32 0, i32 0, i32 0 ; [#uses=1] %tmp34.i = load i32 (...)*** %tmp33.i, align 4 ; [#uses=1] %tmp35.i = getelementptr i32 (...)** %tmp34.i, i32 9 ; [#uses=1] %tmp36.i = load i32 (...)** %tmp35.i, align 4 ; [#uses=1] %tmp3637.i = bitcast i32 (...)* %tmp36.i to double (%"struct.Q::Function"*)* ; [#uses=2] %tmp39.i = call double %tmp3637.i( %"struct.Q::Function"* %tmp18.i ) ; [#uses=1] ! bitcast double (%"struct.Q::Function"*)* %tmp3637.i to i8* ; : 0 [#uses=1] ! call void @registerMethod( i64 73846672, i8* %0 ) %tmp49.i = getelementptr %"struct.Q::Function"* %tmp10.i, i32 0, i32 0, i32 0, i32 0, i32 0 ; [#uses=1] %tmp50.i = load i32 (...)*** %tmp49.i, align 4 ; [#uses=1] %tmp51.i = getelementptr i32 (...)** %tmp50.i, i32 9 ; [#uses=1] %tmp52.i = load i32 (...)** %tmp51.i, align 4 ; [#uses=1] %tmp5253.i = bitcast i32 (...)* %tmp52.i to i32 (%"struct.Q::Function"*)* ; [#uses=2] %tmp55.i = call i32 %tmp5253.i( %"struct.Q::Function"* %tmp10.i ) ; [#uses=1] ! bitcast i32 (%"struct.Q::Function"*)* %tmp5253.i to i8* ; :1 [#uses=1] ! call void @registerMethod( i64 73865808, i8* %1 ) %tmp5859.i = sitofp i32 %tmp55.i to double ; [#uses=1] %tmp61.i = add double %tmp39.i, %tmp5859.i ; [#uses=1] ret double %tmp61.i } Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080210/43e6ba9a/attachment.html From gordonhenriksen at mac.com Sun Feb 10 10:21:32 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Sun, 10 Feb 2008 11:21:32 -0500 Subject: [LLVMdev] Better IDEs/code editors because of LLVM? In-Reply-To: <2824800.uAeYqRHSFb@mid.thomas-huehn.de> References: <2824800.uAeYqRHSFb@mid.thomas-huehn.de> Message-ID: <216DB02E-5DB1-4F24-85B1-BD9B00BC91DB@mac.com> Hi Thomas, On 2008-02-10, at 03:58, Thomas H?hn wrote: > I am not sure whether I understand the goals and proposed features > of your > project, so I'd like to ask. > > I'll just pick out one little aspect: > > I think you are developing a compiler that provides "cleaner" and > easier > access to its internals (AST, semantic annotations etc.). This is not a goal of LLVM, which provides compilers with code generation services: an intermediate representation, low-level program analysis, optimizing transformations, native code generation, just-in- time compiler, and such. However, is a goal of the clang project, which is a C and Objective-C (and eventually C++) compiler built using LLVM as a back-end. Hope that helps, Gordon From xf27 at arcor.de Sun Feb 10 10:45:29 2008 From: xf27 at arcor.de (Thomas =?UTF-8?B?SMO8aG4=?=) Date: Sun, 10 Feb 2008 17:45:29 +0100 Subject: [LLVMdev] Better IDEs/code editors because of LLVM? References: <2824800.uAeYqRHSFb@mid.thomas-huehn.de> <216DB02E-5DB1-4F24-85B1-BD9B00BC91DB@mac.com> Message-ID: <1407041.BtqaYHeWtt@mid.thomas-huehn.de> Gordon Henriksen wrote: > However, is a goal of the clang project, which is a C and Objective-C > (and eventually C++) compiler built using LLVM as a back-end. Thanks for clarifying this. Thomas From sabre at nondot.org Sun Feb 10 11:30:29 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 10 Feb 2008 09:30:29 -0800 Subject: [LLVMdev] Better IDEs/code editors because of LLVM? In-Reply-To: <216DB02E-5DB1-4F24-85B1-BD9B00BC91DB@mac.com> References: <2824800.uAeYqRHSFb@mid.thomas-huehn.de> <216DB02E-5DB1-4F24-85B1-BD9B00BC91DB@mac.com> Message-ID: <95196DA2-A6D0-40EF-AAB1-FD5A9C6B1BB0@nondot.org> On Feb 10, 2008, at 8:21 AM, Gordon Henriksen wrote: > Hi Thomas, > > On 2008-02-10, at 03:58, Thomas H?hn wrote: > >> I am not sure whether I understand the goals and proposed features >> of your >> project, so I'd like to ask. >> >> I'll just pick out one little aspect: >> >> I think you are developing a compiler that provides "cleaner" and >> easier >> access to its internals (AST, semantic annotations etc.). > > However, is a goal of the clang project, which is a C and Objective-C > (and eventually C++) compiler built using LLVM as a back-end. Right. You can read more about clang at http://clang.llvm.org. Specifically, signing up for the cfe-dev list is a good idea if you want to track what is happening. -Chris From romixlev at gmail.com Sun Feb 10 12:56:52 2008 From: romixlev at gmail.com (Roman Levenstein) Date: Sun, 10 Feb 2008 19:56:52 +0100 Subject: [LLVMdev] Some questions about live intervals In-Reply-To: References: <205883.89954.qm@web56304.mail.re3.yahoo.com> Message-ID: <47AF48F4.10605@yahoo.com> Hi Fernando, For some reason, I discovered your mail just today. Fernando Magno Quintao Pereira wrote: > > Hi, Roman, > >> Well, I cannot find anything about in my copy of the paper. The paper >> neither talk about splitting in the interior of basicc blocks, nor >> about handling of pre-colored registers. And Sarkar also does not claim >> the optimality of the algorithm. He claims that it is inherently more >> scalable and efficient, i.e. linear as compared to O(n^2) for Graph >> coloring. >> >> But of course this is required and I'm going to extend the algorithm to >> support it by doing splitting before pre-colored uses. > > I think in the description of the algorithm, in page seven, step 6, > it has to insert register moves to fix the coloring for each program > point P that is part of the program. Well, as far as I understand this algorithm, it does not do any explicit interval splitting. But it tries to color each live range of the live interval separately and may assign different colors to each of those live ranges. After color assignment is done, the algorithm needs to insert some move intsructions, which is done by step 6. In any case, it does not really mean each program point, but only end-points of live range belonging to an live interval. So, it could be seen as some sort of live interval spliiting, but a very limited one, since it only splits at the end of live ranges of live intervals. And for sure, Sarkar's algorithm does not handle pre-colored regs out of the box. >> BTW, there are some other missing features in the Sarkar's algorithm. >> For example, it spills only whole intervals, which is very similar to >> typical GC regallocs, but not very efficient. I think, some of the >> known methods for live-range splitting around high-pressure regions in >> GC world, can be also applied here. This should improve the quality of >> allocation. >> >> Actually, I'm wondering if interval-splitting, handling of pre-colored >> registers, handling of high-pressure regions would slow down the >> algorithm to a very big extent or not? > > One thing that may happen is that, in order to reload spilled variables, > you will need registers available. As far as I understand, it is guaranteed by the algorithm, no special reservation in advance is neccessary. > So, either you spare two registers, > what would be very restrictive in x86, or you do backtracking, as the > current implementation of LLVM's linear scan does. Backtracking may > slowdown the implementation quite a bit. Agree. But it is not neccessary. The way how move instructions are inserted is very similar to Wimmer's linear scan algorithm. There is no need for any reservation of registers in advance or for any backtracking. >I believe that the other factors will not cause too much slowdown. Well, from my experience with the Wimmer's linear scan, book-keeping during the linear scan allocation becomes more complex and time-consuming, once you introduce interval-splitting. Also checks for interception of two live intervals are executed more frequently and consume a significant part of the execution time. Another rather time-consuming operation was the insertion of register moves to glue the splitted parts together. But this is mainly due to the current LLVM design, since such an operation require for each MBB a set of live-in live intervals. And LLVM currently computes live-ins for each MBB just for physical registers, but not for virtual live intervals. Best, Roman From sabre at nondot.org Sun Feb 10 15:41:18 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 10 Feb 2008 13:41:18 -0800 Subject: [LLVMdev] Instrumenting virtual function calls In-Reply-To: <7092525B-2271-4C33-A612-226E076331D7@gmail.com> References: <7092525B-2271-4C33-A612-226E076331D7@gmail.com> Message-ID: On Feb 10, 2008, at 5:33 AM, Robert Zeh wrote: > I'm attempting to instrument virtual function calls in my code. > After each virtual call I'm calling my own registerMethod function, > with an integer marking the location of the call and a pointer to > the function that was called. > > However, and this is where I get confused, the function pointer > doesn't match any of the functions in my module. I'd hoped to call > ExecutionEngine::getGlobalValueAtAddress to get a Function* for the > virtual function, but ExecutionEngine::getGlobalValueAtAddress > returns null. > > If I look up the virtual function that is getting called (with > ExeuctionEngine::getPointerToFunction) it doesn't match the > arguments being passed to my instrumentation. What's a little > strange is that the pointers are somewhat close: > getPointerToFunction returns 0x47829a0, but my instrumentation gets > 0x477fc10. This should basically work. You'll have to walk through the various code that populates the maps. It could be that the start of the function is actually a constant pool or jump table or something, not the first instruction of the function. -Chris From evan.cheng at apple.com Sun Feb 10 21:04:05 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 10 Feb 2008 19:04:05 -0800 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: <010CA658-2EEB-4A1E-96BA-7EF1EF00F044@apple.com> References: <200802092248.m19Mm5GV066405@star.math.spbu.ru> <010CA658-2EEB-4A1E-96BA-7EF1EF00F044@apple.com> Message-ID: <13C0DE39-86A8-479A-92E9-1BB56587A614@apple.com> Where we are on the subject... Are we sure EH is done for x86? These two tests have never worked on Mac OS X / x86: SPEC/CINT2006/471.omnetpp Shootout-C++/except Evan On Feb 9, 2008, at 2:57 PM, Dale Johannesen wrote: > > On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >>> After comparing the generated assembler code with native gcc code I >>> think the generated code is fine, just the exception handler info in >>> the non-code sections is broken/missing. >> It seems, that EH dwarf information emission is disabled in >> X86TargetAsmInfo.cpp. Remove the is64Bit() condition near >> "SupportExceptionHandling = true" line in X86Subtarget::isELF >> section. >> >> Also, don't forget to add --enable-eh switch to llc invocation. > > Just in case it doesn't work the first time:) patch 46029 might be > helpful. That made it work on Darwin for me, and it's possible some > of the changes there are also applicable to Linux. Compare your .s > with g++ output. > >> You will need to link .S with your native unwinding runtime (so, use >> g++ >> to link, not llvm-g++) > > This is not necessary on Darwin, btw, the unwinding stuff Just Worked > too. > > _______________________________________________ > 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 Sun Feb 10 21:09:42 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 10 Feb 2008 19:09:42 -0800 Subject: [LLVMdev] Some questions about live intervals In-Reply-To: <757650.26071.qm@web56312.mail.re3.yahoo.com> References: <757650.26071.qm@web56312.mail.re3.yahoo.com> Message-ID: Thanks. One question though. Should getMBBFromIndex() assert if given an index out of the range or simply returns a NULL pointer? I would think the later makes it a bit more friendly. Evan On Feb 8, 2008, at 8:59 AM, Roman Levenstein wrote: > Hi Evan, > > Here is a patch for the LiveIntervalAnalysis that we discussed. > > --- Evan Cheng schrieb: >>> 1) What is the easiest way to understand which MBB a given >> instruction index belongs to? All the required information is >> available in the >>> MBB2IdxMap of the LiveIntervalAnalysis class. Would it be useful >> to add a small function getMBBFromIndex() to this class? >> >> Sure there is a reverse map (actually just a vector) Idx2MBBMap. >> Justadd a query. > > Done. Please find a patch attached to this mail. > >>> As for (1) and (2), I could implement and provide patches for it, >>> if you think this is desirable. >> >> Yes, thanks. > > Here you are! > > -Roman > > > Lesen Sie Ihre E-Mails auf dem Handy. > www.yahoo.de/goIndex: lib/CodeGen/LiveIntervalAnalysis.cpp > =================================================================== > --- lib/CodeGen/LiveIntervalAnalysis.cpp (revision 46884) > +++ lib/CodeGen/LiveIntervalAnalysis.cpp (working copy) > @@ -79,22 +79,7 @@ > delete ClonedMIs[i]; > } > > -namespace llvm { > - inline bool operator<(unsigned V, const IdxMBBPair &IM) { > - return V < IM.first; > - } > > - inline bool operator<(const IdxMBBPair &IM, unsigned V) { > - return IM.first < V; > - } > - > - struct Idx2MBBCompare { > - bool operator()(const IdxMBBPair &LHS, const IdxMBBPair &RHS) > const { > - return LHS.first < RHS.first; > - } > - }; > -} > - > Index: include/llvm/CodeGen/LiveIntervalAnalysis.h > =================================================================== > --- include/llvm/CodeGen/LiveIntervalAnalysis.h (revision 46884) > +++ include/llvm/CodeGen/LiveIntervalAnalysis.h (working copy) > @@ -40,6 +40,20 @@ > class VirtRegMap; > typedef std::pair IdxMBBPair; > > + inline bool operator<(unsigned V, const IdxMBBPair &IM) { > + return V < IM.first; > + } > + > + inline bool operator<(const IdxMBBPair &IM, unsigned V) { > + return IM.first < V; > + } > + > + struct Idx2MBBCompare { > + bool operator()(const IdxMBBPair &LHS, const IdxMBBPair &RHS) > const { > + return LHS.first < RHS.first; > + } > + }; > + > class LiveIntervals : public MachineFunctionPass { > MachineFunction* mf_; > const TargetMachine* tm_; > @@ -153,6 +167,23 @@ > return MBB2IdxMap[MBBNo].second; > } > > + /// getMBBFromIndex - given an index in any instruction of an > + /// MBB return a pointer the MBB > + MachineBasicBlock* getMBBFromIndex(unsigned index) const { > + std::vector::const_iterator I = > + std::lower_bound(Idx2MBBMap.begin(), Idx2MBBMap.end(), index); > + > + // Take previous pair > + std::vector::const_iterator J = > + ((I != Idx2MBBMap.end() && I->first > index) || > + (I == Idx2MBBMap.end() && Idx2MBBMap.size()>0)) ? (I-1): I; > + > + assert(J != Idx2MBBMap.end() && J->first < index+1 && > + index < getMBBEndIdx(J->second) && > + "index does not correspond to an MBB"); > + return J->second; > + } > + > /// getInstructionIndex - returns the base index of instr > unsigned getInstructionIndex(MachineInstr* instr) const { > Mi2IndexMap::const_iterator it = mi2iMap_.find(instr); > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dalej at apple.com Sun Feb 10 21:52:57 2008 From: dalej at apple.com (Dale Johannesen) Date: Sun, 10 Feb 2008 19:52:57 -0800 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: <13C0DE39-86A8-479A-92E9-1BB56587A614@apple.com> References: <200802092248.m19Mm5GV066405@star.math.spbu.ru> <010CA658-2EEB-4A1E-96BA-7EF1EF00F044@apple.com> <13C0DE39-86A8-479A-92E9-1BB56587A614@apple.com> Message-ID: <696E7857-6428-4E95-B956-524C5D63DB84@apple.com> On Feb 10, 2008, at 7:04 PM, Evan Cheng wrote: > Where we are on the subject... Are we sure EH is done for x86? > > These two tests have never worked on Mac OS X / x86: > SPEC/CINT2006/471.omnetpp > Shootout-C++/except > > Evan Shootout-C++/except works for me. Anton suggests there may be an issue with the unwinding libraries and he may be right, I'll look at it with you tomorrow. > On Feb 9, 2008, at 2:57 PM, Dale Johannesen wrote: > >> >> On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >>>> After comparing the generated assembler code with native gcc code I >>>> think the generated code is fine, just the exception handler info >>>> in >>>> the non-code sections is broken/missing. >>> It seems, that EH dwarf information emission is disabled in >>> X86TargetAsmInfo.cpp. Remove the is64Bit() condition near >>> "SupportExceptionHandling = true" line in X86Subtarget::isELF >>> section. >>> >>> Also, don't forget to add --enable-eh switch to llc invocation. >> >> Just in case it doesn't work the first time:) patch 46029 might be >> helpful. That made it work on Darwin for me, and it's possible some >> of the changes there are also applicable to Linux. Compare your .s >> with g++ output. >> >>> You will need to link .S with your native unwinding runtime (so, use >>> g++ >>> to link, not llvm-g++) >> >> This is not necessary on Darwin, btw, the unwinding stuff Just Worked >> too. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From dalej at apple.com Sun Feb 10 23:01:53 2008 From: dalej at apple.com (Dale Johannesen) Date: Sun, 10 Feb 2008 21:01:53 -0800 Subject: [LLVMdev] LLVM 2.2 Release Notes In-Reply-To: References: Message-ID: <108FAD2C-B6CB-4601-829B-BB2259A43148@apple.com> On Feb 10, 2008, at 12:25 AM, Chris Lattner wrote: > Hi All, > > The first draft of the llvm 2.2 release notes are now available: > http://llvm.org/docs/ReleaseNotes.html > > The release is scheduled for Monday, so please take a look at them and > send me your feedback, or (better yet) just commit fixes directly to > the document in llvm/docs/ReleaseNotes.html. In addition to editing > improvements I'm particularly interested in adding missing things to > the document and getting credit to the right people. Please don't be > shy about letting me know if I got something wrong. This is a matter of presentation, but some of the "GCC extensions" are standard C99 (now, at least). I noticed long long, C++-style comments and designated initializers. I have plenty of complaints about the GCC documentation you're pointing at, but this probably isn't the right forum for that. I do think dropping "as fast as macros" from the "inline" description would be a good idea, that's pure propaganda: sometimes it's true and sometimes it isn't. The miscompilation of code containing both MMX vectors and long double may be worth a mention, but it probably isn't going to bite very many people. (llvm does not insert EMMS everywhere it needs to, or from a different viewpoint, uses MMX when the user didn't tell it to.) Giving me credit for darwin x86-64 EH is an overstatement, I just made minor mods to existing EH code (Anton's I think). Looks good overall. From asl at math.spbu.ru Mon Feb 11 00:06:48 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Mon, 11 Feb 2008 09:06:48 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?ZXhjZXB0aW9uIGhhbmRsaW5nIGJyb2tlbiBvbiB4ODYt?= =?koi8-r?b?NjQ/?= Message-ID: <200802110606.m1B66mk5052431@star.math.spbu.ru> Hello Evan and Dale, > Shootout-C++/except works for me. Anton suggests there may be an > issue with the unwinding libraries and he may be right, I'll look at > it with you tomorrow. Yes. Please be sure, that you're linking with system libgcc.{so,dylib}, not with llvm-compiled one. -- WBR, Anton Korobeynikov From sabre at nondot.org Mon Feb 11 01:26:35 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 10 Feb 2008 23:26:35 -0800 Subject: [LLVMdev] LLVM 2.2 Release Notes In-Reply-To: <108FAD2C-B6CB-4601-829B-BB2259A43148@apple.com> References: <108FAD2C-B6CB-4601-829B-BB2259A43148@apple.com> Message-ID: > This is a matter of presentation, but some of the "GCC extensions" are > standard C99 (now, at least). I noticed long long, C++-style comments > and designated initializers. > > I have plenty of complaints about the GCC documentation you're > pointing at, but this probably isn't the right forum for that. I do > think dropping "as fast as macros" from the "inline" description would > be a good idea, that's pure propaganda: sometimes it's true and > sometimes it isn't. I completely agree with you here. It looks like the GCC docs were written vs C90 not C99. That whole section of the documentation was more useful when there were a lot of GCC features we didn't support. Now it looks like it can be ripped out and we can just keep a list of things that don't work in our own words. Lets do this for the llvm 2.3 release notes though, after Monday. > The miscompilation of code containing both MMX vectors and long double > may be worth a mention, but it probably isn't going to bite very many > people. (llvm does not insert EMMS everywhere it needs to, or from a > different viewpoint, uses MMX when the user didn't tell it to.) AFAIK, many commonly used GCC versions don't do this either. If that's the case, I don't think it's worth mentioning, because most people will be concerned with "llvm regressions vs gcc" or something. I believe that if you explicitly use mmx intrinsics you have to insert emms yourself, and that the only other way to get mmx badness is through use of the gcc generic vector extension. If this is true, I think we should be ok. > Giving me credit for darwin x86-64 EH is an overstatement, I just made > minor mods to existing EH code (Anton's I think). Ok, I'll say 'dale and anton' thanks! -Chris From romixlev at yahoo.com Mon Feb 11 01:44:37 2008 From: romixlev at yahoo.com (Roman Levenstein) Date: Mon, 11 Feb 2008 08:44:37 +0100 (CET) Subject: [LLVMdev] Some questions about live intervals In-Reply-To: Message-ID: <594190.70546.qm@web56304.mail.re3.yahoo.com> Hi Evan, --- Evan Cheng wrote: > Thanks. One question though. Should getMBBFromIndex() assert if given > an index out of the range or simply returns a NULL pointer? I would > think the later makes it a bit more friendly. Yes. It would be more friendly, probably. I can submit such a patch, if you think it suits better. On the other hand I want to mention the following pros: - assert-based approach follows the style of all other getNNN functions in LiveIntervalAnalysis.h. They all assert in out-of-range cases. - What does it mean, if you have a situation where you ask for the MBB of an instruction index, which is out of range for any MBB? How can this happen? If you know the index, then instruction should have been already registered before, it's number is known and it is supposed to belong to an MBB. If not, some internal mapping tables (e.g. start and end of MBBs, index to MBB mappings, etc) in LiveIntervalAnalysis are likely to be broken. In this case, it is better to assert() in those cases, IMHO. Please, let me know, if I should sumbit a patch without any assert() and returning just a NULL pointer. -Roman > On Feb 8, 2008, at 8:59 AM, Roman Levenstein wrote: > > > Hi Evan, > > > > Here is a patch for the LiveIntervalAnalysis that we discussed. > > > > --- Evan Cheng schrieb: > >>> 1) What is the easiest way to understand which MBB a given > >> instruction index belongs to? All the required information is > >> available in the > >>> MBB2IdxMap of the LiveIntervalAnalysis class. Would it be useful > >> to add a small function getMBBFromIndex() to this class? > >> > >> Sure there is a reverse map (actually just a vector) Idx2MBBMap. > >> Justadd a query. > > > > Done. Please find a patch attached to this mail. > > > >>> As for (1) and (2), I could implement and provide patches for it, > >>> if you think this is desirable. > >> > >> Yes, thanks. > > > > Here you are! > > > > -Roman > > > > > > Lesen Sie Ihre E-Mails auf dem Handy. > > www.yahoo.de/goIndex: lib/CodeGen/LiveIntervalAnalysis.cpp > > =================================================================== > > --- lib/CodeGen/LiveIntervalAnalysis.cpp (revision 46884) > > +++ lib/CodeGen/LiveIntervalAnalysis.cpp (working copy) > > @@ -79,22 +79,7 @@ > > delete ClonedMIs[i]; > > } > > > > -namespace llvm { > > - inline bool operator<(unsigned V, const IdxMBBPair &IM) { > > - return V < IM.first; > > - } > > > > - inline bool operator<(const IdxMBBPair &IM, unsigned V) { > > - return IM.first < V; > > - } > > - > > - struct Idx2MBBCompare { > > - bool operator()(const IdxMBBPair &LHS, const IdxMBBPair &RHS) > > > const { > > - return LHS.first < RHS.first; > > - } > > - }; > > -} > > - > > Index: include/llvm/CodeGen/LiveIntervalAnalysis.h > > =================================================================== > > --- include/llvm/CodeGen/LiveIntervalAnalysis.h (revision 46884) > > +++ include/llvm/CodeGen/LiveIntervalAnalysis.h (working copy) > > @@ -40,6 +40,20 @@ > > class VirtRegMap; > > typedef std::pair IdxMBBPair; > > > > + inline bool operator<(unsigned V, const IdxMBBPair &IM) { > > + return V < IM.first; > > + } > > + > > + inline bool operator<(const IdxMBBPair &IM, unsigned V) { > > + return IM.first < V; > > + } > > + > > + struct Idx2MBBCompare { > > + bool operator()(const IdxMBBPair &LHS, const IdxMBBPair &RHS) > > > const { > > + return LHS.first < RHS.first; > > + } > > + }; > > + > > class LiveIntervals : public MachineFunctionPass { > > MachineFunction* mf_; > > const TargetMachine* tm_; > > @@ -153,6 +167,23 @@ > > return MBB2IdxMap[MBBNo].second; > > } > > > > + /// getMBBFromIndex - given an index in any instruction of an > > + /// MBB return a pointer the MBB > > + MachineBasicBlock* getMBBFromIndex(unsigned index) const { > > + std::vector::const_iterator I = > > + std::lower_bound(Idx2MBBMap.begin(), Idx2MBBMap.end(), > index); > > + > > + // Take previous pair > > + std::vector::const_iterator J = > > + ((I != Idx2MBBMap.end() && I->first > index) || > > + (I == Idx2MBBMap.end() && Idx2MBBMap.size()>0)) ? (I-1): I; > > + > > + assert(J != Idx2MBBMap.end() && J->first < index+1 && > > + index < getMBBEndIdx(J->second) && > > + "index does not correspond to an MBB"); > > + return J->second; > > + } > > + > > /// getInstructionIndex - returns the base index of instr > > unsigned getInstructionIndex(MachineInstr* instr) const { > > Mi2IndexMap::const_iterator it = mi2iMap_.find(instr); > > _______________________________________________ > > 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 > __________________________________ Ihre erste Baustelle? Wissenswertes f?r Bastler und Hobby Handwerker. www.yahoo.de/clever From nicolas.geoffray at lip6.fr Mon Feb 11 02:22:49 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 11 Feb 2008 09:22:49 +0100 Subject: [LLVMdev] Exception handling in JIT In-Reply-To: <91B9A606-4221-43A3-9468-FF255CCBEC60@apple.com> References: <475D7CC0.9010605@lip6.fr> <27026429-F8CF-41B0-86CF-A487EA14890C@apple.com> <475FCB4B.4090304@lip6.fr> <393ABC27-9C1A-4B51-84EB-6F842BA37FA1@apple.com> <47A2E553.8020501@lip6.fr> <91B9A606-4221-43A3-9468-FF255CCBEC60@apple.com> Message-ID: <47B005D9.1080001@lip6.fr> Great! I'll apply it in the next couple of days, in case someone else wants to review it. Evan Cheng wrote: > Looks sane. Thanks. > > Evan > > On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > > >> Dear all, >> >> Here's a new patch with Evan's comments (thx Evan!) and some cleanups. >> Now the (duplicated) exception handling code is in a new file: >> lib/ExecutionEngine/JIT/JITDwarfEmitter. >> >> This patch should work on linux/x86 and linux/ppc (tested). >> >> Nicolas >> Index: include/llvm/ExecutionEngine/ExecutionEngine.h >> =================================================================== >> --- include/llvm/ExecutionEngine/ExecutionEngine.h (revision 46612) >> +++ include/llvm/ExecutionEngine/ExecutionEngine.h (working copy) >> @@ -85,6 +85,11 @@ >> /// pointer is invoked to create it. If this returns null, the JIT >> will abort. >> void* (*LazyFunctionCreator)(const std::string &); >> >> + /// ExceptionTableRegister - If Exception Handling is set, the >> JIT will >> + /// register dwarf tables with this function >> + typedef void (*EERegisterFn)(void*); >> + static EERegisterFn ExceptionTableRegister; >> + >> public: >> /// lock - This lock is protects the ExecutionEngine, JIT, >> JITResolver and >> /// JITEmitter classes. It must be held while changing the >> internal state of >> @@ -246,6 +251,18 @@ >> void InstallLazyFunctionCreator(void* (*P)(const std::string &)) { >> LazyFunctionCreator = P; >> } >> + >> + /// InstallExceptionTableRegister - The JIT will use the given >> function >> + /// to register the exception tables it generates. >> + static void InstallExceptionTableRegister(void (*F)(void*)) { >> + ExceptionTableRegister = F; >> + } >> + >> + /// RegisterTable - Registers the given pointer as an exception >> table. It uses >> + /// the ExceptionTableRegister function. >> + static void RegisterTable(void* res) { >> + ExceptionTableRegister(res); >> + } >> >> protected: >> explicit ExecutionEngine(ModuleProvider *P); >> Index: include/llvm/ExecutionEngine/JITMemoryManager.h >> =================================================================== >> --- include/llvm/ExecutionEngine/JITMemoryManager.h (revision 46612) >> +++ include/llvm/ExecutionEngine/JITMemoryManager.h (working copy) >> @@ -89,6 +89,17 @@ >> /// deallocateMemForFunction - Free JIT memory for the specified >> function. >> /// This is never called when the JIT is currently emitting a >> function. >> virtual void deallocateMemForFunction(const Function *F) = 0; >> + >> + /// startExceptionTable - When we finished JITing the function, >> if exception >> + /// handling is set, we emit the exception table. >> + virtual unsigned char* startExceptionTable(const Function* F, >> + uintptr_t &ActualSize) >> = 0; >> + >> + /// endExceptionTable - This method is called when the JIT is >> done emitting >> + /// the exception table. >> + virtual void endExceptionTable(const Function *F, unsigned char >> *TableStart, >> + unsigned char *TableEnd, >> + unsigned char* FrameRegister) = 0; >> }; >> >> } // end namespace llvm. >> Index: include/llvm/CodeGen/MachineCodeEmitter.h >> =================================================================== >> --- include/llvm/CodeGen/MachineCodeEmitter.h (revision 46612) >> +++ include/llvm/CodeGen/MachineCodeEmitter.h (working copy) >> @@ -26,6 +26,7 @@ >> class MachineConstantPool; >> class MachineJumpTableInfo; >> class MachineFunction; >> +class MachineModuleInfo; >> class MachineRelocation; >> class Value; >> class GlobalValue; >> @@ -136,6 +137,72 @@ >> CurBufferPtr = BufferEnd; >> } >> >> + >> + /// emitULEB128Bytes - This callback is invoked when a ULEB128 >> needs to be >> + /// written to the output stream. >> + void emitULEB128Bytes(unsigned Value) { >> + do { >> + unsigned char Byte = Value & 0x7f; >> + Value >>= 7; >> + if (Value) Byte |= 0x80; >> + emitByte(Byte); >> + } while (Value); >> + } >> + >> + /// emitSLEB128Bytes - This callback is invoked when a SLEB128 >> needs to be >> + /// written to the output stream. >> + void emitSLEB128Bytes(int Value) { >> + int Sign = Value >> (8 * sizeof(Value) - 1); >> + bool IsMore; >> + >> + do { >> + unsigned char Byte = Value & 0x7f; >> + Value >>= 7; >> + IsMore = Value != Sign || ((Byte ^ Sign) & 0x40) != 0; >> + if (IsMore) Byte |= 0x80; >> + emitByte(Byte); >> + } while (IsMore); >> + } >> + >> + /// emitString - This callback is invoked when a String needs to be >> + /// written to the output stream. >> + void emitString(const std::string &String) { >> + for (unsigned i = 0, N = String.size(); i < N; ++i) { >> + unsigned char C = String[i]; >> + emitByte(C); >> + } >> + emitByte(0); >> + } >> + >> + /// emitInt32 - Emit a int32 directive. >> + void emitInt32(int Value) { >> + if (CurBufferPtr+4 <= BufferEnd) { >> + *((uint32_t*)CurBufferPtr) = Value; >> + CurBufferPtr += 4; >> + } else { >> + CurBufferPtr = BufferEnd; >> + } >> + } >> + >> + /// emitInt64 - Emit a int64 directive. >> + void emitInt64(uint64_t Value) { >> + if (CurBufferPtr+8 <= BufferEnd) { >> + *((uint64_t*)CurBufferPtr) = Value; >> + CurBufferPtr += 8; >> + } else { >> + CurBufferPtr = BufferEnd; >> + } >> + } >> + >> + /// emitAt - Emit Value in Addr >> + void emitAt(uintptr_t *Addr, uintptr_t Value) { >> + if (Addr >= (uintptr_t*)BufferBegin && Addr < >> (uintptr_t*)BufferEnd) >> + (*Addr) = Value; >> + } >> + >> + /// emitLabel - Emits a label >> + virtual void emitLabel(uint64_t LabelID) = 0; >> + >> /// allocateSpace - Allocate a block of space in the current >> output buffer, >> /// returning null (and setting conditions to indicate buffer >> overflow) on >> /// failure. Alignment is the alignment in bytes of the buffer >> desired. >> @@ -194,6 +261,15 @@ >> /// emitted. >> /// >> virtual intptr_t getMachineBasicBlockAddress(MachineBasicBlock >> *MBB) const= 0; >> + >> + /// getLabelAddress - Return the address of the specified >> LabelID, only usable >> + /// after the LabelID has been emitted. >> + /// >> + virtual intptr_t getLabelAddress(uint64_t LabelID) const = 0; >> + >> + /// Specifies the MachineModuleInfo object. This is used for >> exception handling >> + /// purposes. >> + virtual void setModuleInfo(MachineModuleInfo* Info) = 0; >> }; >> >> } // End llvm namespace >> Index: lib/CodeGen/LLVMTargetMachine.cpp >> =================================================================== >> --- lib/CodeGen/LLVMTargetMachine.cpp (revision 46612) >> +++ lib/CodeGen/LLVMTargetMachine.cpp (working copy) >> @@ -186,8 +186,8 @@ >> >> PM.add(createGCLoweringPass()); >> >> - // FIXME: Implement the invoke/unwind instructions! >> - PM.add(createLowerInvokePass(getTargetLowering())); >> + if (!ExceptionHandling) >> + PM.add(createLowerInvokePass(getTargetLowering())); >> >> // Make sure that no unreachable blocks are instruction selected. >> PM.add(createUnreachableBlockEliminationPass()); >> Index: lib/CodeGen/ELFWriter.cpp >> =================================================================== >> --- lib/CodeGen/ELFWriter.cpp (revision 46612) >> +++ lib/CodeGen/ELFWriter.cpp (working copy) >> @@ -98,6 +98,21 @@ >> return 0; >> } >> >> + virtual intptr_t getLabelAddress(uint64_t Label) const { >> + assert(0 && "Label address not implementated yet!"); >> + abort(); >> + return 0; >> + } >> + >> + virtual void emitLabel(uint64_t LabelID) { >> + assert(0 && "emit Label not implementated yet!"); >> + abort(); >> + } >> + >> + >> + virtual void setModuleInfo(llvm::MachineModuleInfo* MMI) { } >> + >> + >> /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! >> void startFunctionStub(unsigned StubSize, unsigned Alignment = >> 1) { >> assert(0 && "JIT specific function called!"); >> Index: lib/CodeGen/MachOWriter.cpp >> =================================================================== >> --- lib/CodeGen/MachOWriter.cpp (revision 46612) >> +++ lib/CodeGen/MachOWriter.cpp (working copy) >> @@ -125,6 +125,20 @@ >> return MBBLocations[MBB->getNumber()]; >> } >> >> + virtual intptr_t getLabelAddress(uint64_t Label) const { >> + assert(0 && "get Label not implemented"); >> + abort(); >> + return 0; >> + } >> + >> + virtual void emitLabel(uint64_t LabelID) { >> + assert(0 && "emit Label not implemented"); >> + abort(); >> + } >> + >> + >> + virtual void setModuleInfo(llvm::MachineModuleInfo* MMI) { } >> + >> /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! >> virtual void startFunctionStub(unsigned StubSize, unsigned >> Alignment = 1) { >> assert(0 && "JIT specific function called!"); >> Index: lib/Target/PowerPC/PPCCodeEmitter.cpp >> =================================================================== >> --- lib/Target/PowerPC/PPCCodeEmitter.cpp (revision 46612) >> +++ lib/Target/PowerPC/PPCCodeEmitter.cpp (working copy) >> @@ -20,6 +20,7 @@ >> #include "llvm/CodeGen/MachineCodeEmitter.h" >> #include "llvm/CodeGen/MachineFunctionPass.h" >> #include "llvm/CodeGen/MachineInstrBuilder.h" >> +#include "llvm/CodeGen/MachineModuleInfo.h" >> #include "llvm/CodeGen/Passes.h" >> #include "llvm/Support/Debug.h" >> #include "llvm/Support/Compiler.h" >> @@ -38,6 +39,11 @@ >> /// getMachineOpValue - evaluates the MachineOperand of a given >> MachineInstr >> /// >> int getMachineOpValue(MachineInstr &MI, MachineOperand &MO); >> + >> + void getAnalysisUsage(AnalysisUsage &AU) const { >> + AU.addRequired(); >> + MachineFunctionPass::getAnalysisUsage(AU); >> + } >> >> public: >> static char ID; >> @@ -82,6 +88,8 @@ >> assert((MF.getTarget().getRelocationModel() != Reloc::Default || >> MF.getTarget().getRelocationModel() != Reloc::Static) && >> "JIT relocation model must be set to static or default!"); >> + >> + MCE.setModuleInfo(&getAnalysis()); >> do { >> MovePCtoLROffset = 0; >> MCE.startFunction(MF); >> @@ -101,6 +109,9 @@ >> default: >> MCE.emitWordBE(getBinaryCodeForInstr(*I)); >> break; >> + case TargetInstrInfo::LABEL: >> + MCE.emitLabel(MI.getOperand(0).getImm()); >> + break; >> case PPC::IMPLICIT_DEF_GPRC: >> case PPC::IMPLICIT_DEF_G8RC: >> case PPC::IMPLICIT_DEF_F8: >> Index: lib/Target/X86/X86CodeEmitter.cpp >> =================================================================== >> --- lib/Target/X86/X86CodeEmitter.cpp (revision 46612) >> +++ lib/Target/X86/X86CodeEmitter.cpp (working copy) >> @@ -23,6 +23,7 @@ >> #include "llvm/CodeGen/MachineCodeEmitter.h" >> #include "llvm/CodeGen/MachineFunctionPass.h" >> #include "llvm/CodeGen/MachineInstr.h" >> +#include "llvm/CodeGen/MachineModuleInfo.h" >> #include "llvm/CodeGen/Passes.h" >> #include "llvm/Function.h" >> #include "llvm/ADT/Statistic.h" >> @@ -61,6 +62,11 @@ >> >> void emitInstruction(const MachineInstr &MI, >> const TargetInstrDesc *Desc); >> + >> + void getAnalysisUsage(AnalysisUsage &AU) const { >> + AU.addRequired(); >> + MachineFunctionPass::getAnalysisUsage(AU); >> + } >> >> private: >> void emitPCRelativeBlockAddress(MachineBasicBlock *MBB); >> @@ -104,10 +110,13 @@ >> assert((MF.getTarget().getRelocationModel() != Reloc::Default || >> MF.getTarget().getRelocationModel() != Reloc::Static) && >> "JIT relocation model must be set to static or default!"); >> + >> + MCE.setModuleInfo(&getAnalysis()); >> + >> II = ((X86TargetMachine&)TM).getInstrInfo(); >> TD = ((X86TargetMachine&)TM).getTargetData(); >> Is64BitMode = TM.getSubtarget().is64Bit(); >> - >> + >> do { >> MCE.startFunction(MF); >> for (MachineFunction::iterator MBB = MF.begin(), E = MF.end(); >> @@ -596,13 +605,13 @@ >> // Remember the current PC offset, this is the PIC relocation >> // base address. >> switch (Opcode) { >> -#ifndef NDEBUG >> default: >> assert(0 && "psuedo instructions should be removed before code >> emission"); >> case TargetInstrInfo::INLINEASM: >> assert(0 && "JIT does not support inline asm!\n"); >> case TargetInstrInfo::LABEL: >> - assert(0 && "JIT does not support meta labels!\n"); >> + MCE.emitLabel(MI.getOperand(0).getImm()); >> + break; >> case X86::IMPLICIT_DEF_GR8: >> case X86::IMPLICIT_DEF_GR16: >> case X86::IMPLICIT_DEF_GR32: >> @@ -613,7 +622,6 @@ >> case X86::IMPLICIT_DEF_VR128: >> case X86::FP_REG_KILL: >> break; >> -#endif >> case X86::MOVPC32r: { >> // This emits the "call" portion of this pseudo instruction. >> MCE.emitByte(BaseOpcode); >> @@ -627,7 +635,6 @@ >> } >> CurOp = NumOps; >> break; >> - >> case X86II::RawFrm: >> MCE.emitByte(BaseOpcode); >> >> Index: lib/ExecutionEngine/JIT/JITEmitter.cpp >> =================================================================== >> --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 46612) >> +++ lib/ExecutionEngine/JIT/JITEmitter.cpp (working copy) >> @@ -14,6 +14,7 @@ >> >> #define DEBUG_TYPE "jit" >> #include "JIT.h" >> +#include "JITDwarfEmitter.h" >> #include "llvm/Constant.h" >> #include "llvm/Module.h" >> #include "llvm/Type.h" >> @@ -21,11 +22,13 @@ >> #include "llvm/CodeGen/MachineFunction.h" >> #include "llvm/CodeGen/MachineConstantPool.h" >> #include "llvm/CodeGen/MachineJumpTableInfo.h" >> +#include "llvm/CodeGen/MachineModuleInfo.h" >> #include "llvm/CodeGen/MachineRelocation.h" >> #include "llvm/ExecutionEngine/JITMemoryManager.h" >> #include "llvm/Target/TargetData.h" >> #include "llvm/Target/TargetJITInfo.h" >> #include "llvm/Target/TargetMachine.h" >> +#include "llvm/Target/TargetOptions.h" >> #include "llvm/Support/Debug.h" >> #include "llvm/Support/MutexGuard.h" >> #include "llvm/System/Disassembler.h" >> @@ -336,6 +339,17 @@ >> >> /// Resolver - This contains info about the currently resolved >> functions. >> JITResolver Resolver; >> + >> + /// DE - The dwarf emitter for the jit. >> + JITDwarfEmitter *DE; >> + >> + /// LabelLocations - This vector is a mapping from Label ID's >> to their >> + /// address. >> + std::vector LabelLocations; >> + >> + /// MMI - Machine module info for exception informations >> + MachineModuleInfo* MMI; >> + >> public: >> JITEmitter(JIT &jit, JITMemoryManager *JMM) : Resolver(jit) { >> MemMgr = JMM ? JMM : >> JITMemoryManager::CreateDefaultMemManager(); >> @@ -343,9 +357,12 @@ >> MemMgr->AllocateGOT(); >> DOUT << "JIT is managing a GOT\n"; >> } >> + >> + if (ExceptionHandling) DE = new JITDwarfEmitter(jit); >> } >> ~JITEmitter() { >> delete MemMgr; >> + if (ExceptionHandling) delete DE; >> } >> >> JITResolver &getJITResolver() { return Resolver; } >> @@ -384,6 +401,24 @@ >> void deallocateMemForFunction(Function *F) { >> MemMgr->deallocateMemForFunction(F); >> } >> + >> + virtual void emitLabel(uint64_t LabelID) { >> + if (LabelLocations.size() <= LabelID) >> + LabelLocations.resize((LabelID+1)*2); >> + LabelLocations[LabelID] = getCurrentPCValue(); >> + } >> + >> + virtual intptr_t getLabelAddress(uint64_t LabelID) const { >> + assert(LabelLocations.size() > (unsigned)LabelID && >> + LabelLocations[LabelID] && "Label not emitted!"); >> + return LabelLocations[LabelID]; >> + } >> + >> + virtual void setModuleInfo(MachineModuleInfo* Info) { >> + MMI = Info; >> + if (ExceptionHandling) DE->setModuleInfo(Info); >> + } >> + >> private: >> void *getPointerToGlobal(GlobalValue *GV, void *Reference, bool >> NoNeedStub); >> void *getPointerToGVLazyPtr(GlobalValue *V, void *Reference, >> @@ -544,7 +579,25 @@ >> DOUT << "Disassembled code:\n" >> << sys::disassembleBuffer(FnStart, FnEnd-FnStart, >> (uintptr_t)FnStart); >> #endif >> - >> + if (ExceptionHandling) { >> + uintptr_t ActualSize; >> + SavedBufferBegin = BufferBegin; >> + SavedBufferEnd = BufferEnd; >> + SavedCurBufferPtr = CurBufferPtr; >> + >> + BufferBegin = CurBufferPtr = MemMgr- >> >>> startExceptionTable(F.getFunction(), >>> >> + >> ActualSize); >> + BufferEnd = BufferBegin+ActualSize; >> + unsigned char* FrameRegister = DE->EmitDwarfTable(F, *this, >> FnStart, FnEnd); >> + MemMgr->endExceptionTable(F.getFunction(), BufferBegin, >> CurBufferPtr, FrameRegister); >> + BufferBegin = SavedBufferBegin; >> + BufferEnd = SavedBufferEnd; >> + CurBufferPtr = SavedCurBufferPtr; >> + >> + TheJIT->RegisterTable(FrameRegister); >> + } >> + MMI->EndFunction(); >> + >> return false; >> } >> >> Index: lib/ExecutionEngine/JIT/JITMemoryManager.cpp >> =================================================================== >> --- lib/ExecutionEngine/JIT/JITMemoryManager.cpp (revision 46612) >> +++ lib/ExecutionEngine/JIT/JITMemoryManager.cpp (working copy) >> @@ -256,6 +256,7 @@ >> sys::MemoryBlock getNewMemoryBlock(unsigned size); >> >> std::map FunctionBlocks; >> + std::map TableBlocks; >> public: >> DefaultJITMemoryManager(); >> ~DefaultJITMemoryManager(); >> @@ -290,6 +291,28 @@ >> FreeMemoryList =CurBlock->TrimAllocationToSize(FreeMemoryList, >> BlockSize); >> } >> >> + /// startExceptionTable - Use startFunctionBody to allocate >> memory for the >> + /// function's exception table. >> + unsigned char* startExceptionTable(const Function* F, uintptr_t >> &ActualSize) { >> + return startFunctionBody(F, ActualSize); >> + } >> + >> + /// endExceptionTable - The exception table of F is now >> allocated, >> + /// and takes the memory in the range [TableStart,TableEnd). >> + void endExceptionTable(const Function *F, unsigned char >> *TableStart, >> + unsigned char *TableEnd, >> + unsigned char* FrameRegister) { >> + assert(TableEnd > TableStart); >> + assert(TableStart == (unsigned char *)(CurBlock+1) && >> + "Mismatched table start/end!"); >> + >> + uintptr_t BlockSize = TableEnd - (unsigned char *)CurBlock; >> + TableBlocks[F] = CurBlock; >> + >> + // Release the memory at the end of this block that isn't >> needed. >> + FreeMemoryList =CurBlock- >> >>> TrimAllocationToSize(FreeMemoryList, BlockSize); >>> >> + } >> + >> unsigned char *getGOTBase() const { >> return GOTBase; >> } >> @@ -315,6 +338,24 @@ >> >> // Finally, remove this entry from FunctionBlocks. >> FunctionBlocks.erase(I); >> + >> + I = TableBlocks.find(F); >> + if (I == TableBlocks.end()) return; >> + >> + // Find the block that is allocated for this function. >> + MemRange = I->second; >> + assert(MemRange->ThisAllocated && "Block isn't allocated!"); >> + >> + // Fill the buffer with garbage! >> +#ifndef NDEBUG >> + memset(MemRange+1, 0xCD, MemRange->BlockSize- >> sizeof(*MemRange)); >> +#endif >> + >> + // Free the memory. >> + FreeMemoryList = MemRange->FreeBlock(FreeMemoryList); >> + >> + // Finally, remove this entry from TableBlocks. >> + TableBlocks.erase(I); >> } >> }; >> } >> Index: lib/ExecutionEngine/ExecutionEngine.cpp >> =================================================================== >> --- lib/ExecutionEngine/ExecutionEngine.cpp (revision 46612) >> +++ lib/ExecutionEngine/ExecutionEngine.cpp (working copy) >> @@ -34,7 +34,9 @@ >> >> ExecutionEngine::EECtorFn ExecutionEngine::JITCtor = 0; >> ExecutionEngine::EECtorFn ExecutionEngine::InterpCtor = 0; >> +ExecutionEngine::EERegisterFn >> ExecutionEngine::ExceptionTableRegister = 0; >> >> + >> ExecutionEngine::ExecutionEngine(ModuleProvider *P) : >> LazyFunctionCreator(0) { >> LazyCompilationDisabled = false; >> Modules.push_back(P); >> Index: lib/ExecutionEngine/JIT/JITDwarfEmitter.h >> =================================================================== >> --- lib/ExecutionEngine/JIT/JITDwarfEmitter.h (revision 0) >> +++ lib/ExecutionEngine/JIT/JITDwarfEmitter.h (revision 0) >> @@ -0,0 +1,69 @@ >> +//===------ JITDwarfEmitter.h - Write dwarf tables into memory >> ------------===// >> +// >> +// The LLVM Compiler Infrastructure >> +// >> +// This file is distributed under the University of Illinois Open >> Source >> +// License. See LICENSE.TXT for details. >> +// >> +// >> = >> = >> = >> ----------------------------------------------------------------------= >> ==// >> +// >> +// This file defines a JITDwarfEmitter object that is used by the >> JIT to >> +// write dwarf tables to memory. >> +// >> +// >> = >> = >> = >> ----------------------------------------------------------------------= >> ==// >> + >> +#ifndef LLVM_EXECUTION_ENGINE_JIT_DWARFEMITTER_H >> +#define LLVM_EXECUTION_ENGINE_JIT_DWARFEMITTER_H >> + >> +namespace llvm { >> + >> +class Function; >> +class MachineCodeEmitter; >> +class MachineFunction; >> +class MachineModuleInfo; >> +class MachineMove; >> +class MRegisterInfo; >> +class TargetData; >> +class TargetMachine; >> + >> +class JITDwarfEmitter { >> + const TargetData* TD; >> + MachineCodeEmitter* MCE; >> + const MRegisterInfo* RI; >> + MachineModuleInfo* MMI; >> + JIT& Jit; >> + bool needsIndirectEncoding; >> + bool stackGrowthDirection; >> + >> +public: >> + JITDwarfEmitter(JIT& jit); >> + >> + unsigned char* EmitExceptionTable(MachineFunction* MF, >> + unsigned char* StartFunction, >> + unsigned char* EndFunction); >> + >> + void EmitFrameMoves(intptr_t BaseLabelPtr, >> + const std::vector &Moves); >> + >> + unsigned char* EmitCommonEHFrame(const Function* Personality); >> + >> + unsigned char* EmitEHFrame(const Function* Personality, >> + unsigned char* StartBufferPtr, >> + unsigned char* StartFunction, >> + unsigned char* EndFunction, >> + unsigned char* ExceptionTable); >> + >> + >> + unsigned char* EmitDwarfTable(MachineFunction& F, >> + MachineCodeEmitter& MCE, >> + unsigned char* StartFunction, >> + unsigned char* EndFunction); >> + >> + void setModuleInfo(MachineModuleInfo* Info) { >> + MMI = Info; >> + } >> +}; >> + >> +} // end namespace llvm >> + >> +#endif // LLVM_EXECUTION_ENGINE_JIT_DWARFEMITTER_H >> Index: lib/ExecutionEngine/JIT/JITDwarfEmitter.cpp >> =================================================================== >> --- lib/ExecutionEngine/JIT/JITDwarfEmitter.cpp (revision 0) >> +++ lib/ExecutionEngine/JIT/JITDwarfEmitter.cpp (revision 0) >> @@ -0,0 +1,636 @@ >> +//===----- JITDwarfEmitter.cpp - Write dwarf tables into memory >> -----------===// >> +// >> +// The LLVM Compiler Infrastructure >> +// >> +// This file is distributed under the University of Illinois Open >> Source >> +// License. See LICENSE.TXT for details. >> +// >> +// >> = >> = >> = >> ----------------------------------------------------------------------= >> ==// >> +// >> +// This file defines a JITDwarfEmitter object that is used by the >> JIT to >> +// write dwarf tables to memory. >> +// >> +// >> = >> = >> = >> ----------------------------------------------------------------------= >> ==// >> + >> +#include "JIT.h" >> +#include "JITDwarfEmitter.h" >> +#include "llvm/Function.h" >> +#include "llvm/ADT/DenseMap.h" >> +#include "llvm/CodeGen/AsmPrinter.h" >> +#include "llvm/CodeGen/MachineCodeEmitter.h" >> +#include "llvm/CodeGen/MachineFunction.h" >> +#include "llvm/CodeGen/MachineLocation.h" >> +#include "llvm/CodeGen/MachineModuleInfo.h" >> +#include "llvm/ExecutionEngine/JITMemoryManager.h" >> +#include "llvm/Target/MRegisterInfo.h" >> +#include "llvm/Target/TargetAsmInfo.h" >> +#include "llvm/Target/TargetData.h" >> +#include "llvm/Target/TargetInstrInfo.h" >> +#include "llvm/Target/TargetFrameInfo.h" >> +#include "llvm/Target/TargetMachine.h" >> + >> +using namespace llvm; >> + >> +JITDwarfEmitter::JITDwarfEmitter(JIT& theJit) : Jit(theJit) {} >> + >> + >> +unsigned char* JITDwarfEmitter::EmitDwarfTable(MachineFunction& F, >> + MachineCodeEmitter& >> mce, >> + unsigned char* >> StartFunction, >> + unsigned char* >> EndFunction) { >> + const TargetMachine& TM = F.getTarget(); >> + TD = TM.getTargetData(); >> + needsIndirectEncoding = TM.getTargetAsmInfo()- >> >>> getNeedsIndirectEncoding(); >>> >> + stackGrowthDirection = TM.getFrameInfo()- >> >>> getStackGrowthDirection(); >>> >> + RI = TM.getRegisterInfo(); >> + MCE = &mce; >> + >> + unsigned char* ExceptionTable = EmitExceptionTable(&F, >> StartFunction, >> + EndFunction); >> + >> + unsigned char* Result = 0; >> + unsigned char* EHFramePtr = 0; >> + >> + const std::vector Personalities = MMI- >> >>> getPersonalities(); >>> >> + EHFramePtr = EmitCommonEHFrame(Personalities[MMI- >> >>> getPersonalityIndex()]); >>> >> + >> + Result = EmitEHFrame(Personalities[MMI->getPersonalityIndex()], >> EHFramePtr, >> + StartFunction, EndFunction, ExceptionTable); >> + >> + return Result; >> +} >> + >> + >> +void JITDwarfEmitter::EmitFrameMoves(intptr_t BaseLabelPtr, >> + const std::vector >> &Moves) { >> + unsigned PointerSize = TD->getPointerSize(); >> + int stackGrowth = stackGrowthDirection == >> TargetFrameInfo::StackGrowsUp ? >> + PointerSize : -PointerSize; >> + bool IsLocal = BaseLabelPtr; >> + >> + for (unsigned i = 0, N = Moves.size(); i < N; ++i) { >> + const MachineMove &Move = Moves[i]; >> + unsigned LabelID = Move.getLabelID(); >> + >> + if (LabelID) { >> + LabelID = MMI->MappedLabel(LabelID); >> + >> + // Throw out move if the label is invalid. >> + if (!LabelID) continue; >> + } >> + >> + intptr_t LabelPtr = 0; >> + if (LabelID) LabelPtr = MCE->getLabelAddress(LabelID); >> + >> + const MachineLocation &Dst = Move.getDestination(); >> + const MachineLocation &Src = Move.getSource(); >> + >> + // Advance row if new location. >> + if (BaseLabelPtr && LabelID && (BaseLabelPtr != LabelPtr || ! >> IsLocal)) { >> + MCE->emitByte(dwarf::DW_CFA_advance_loc4); >> + if (PointerSize == 8) { >> + MCE->emitInt64(LabelPtr - BaseLabelPtr); >> + } else { >> + MCE->emitInt32(LabelPtr - BaseLabelPtr); >> + } >> + >> + BaseLabelPtr = LabelPtr; >> + IsLocal = true; >> + } >> + >> + // If advancing cfa. >> + if (Dst.isRegister() && Dst.getRegister() == >> MachineLocation::VirtualFP) { >> + if (!Src.isRegister()) { >> + if (Src.getRegister() == MachineLocation::VirtualFP) { >> + MCE->emitByte(dwarf::DW_CFA_def_cfa_offset); >> + } else { >> + MCE->emitByte(dwarf::DW_CFA_def_cfa); >> + MCE->emitULEB128Bytes(RI- >> >>> getDwarfRegNum(Src.getRegister(), true)); >>> >> + } >> + >> + int Offset = -Src.getOffset(); >> + >> + MCE->emitULEB128Bytes(Offset); >> + } else { >> + assert(0 && "Machine move no supported yet."); >> + } >> + } else if (Src.isRegister() && >> + Src.getRegister() == MachineLocation::VirtualFP) { >> + if (Dst.isRegister()) { >> + MCE->emitByte(dwarf::DW_CFA_def_cfa_register); >> + MCE->emitULEB128Bytes(RI->getDwarfRegNum(Dst.getRegister(), >> true)); >> + } else { >> + assert(0 && "Machine move no supported yet."); >> + } >> + } else { >> + unsigned Reg = RI->getDwarfRegNum(Src.getRegister(), true); >> + int Offset = Dst.getOffset() / stackGrowth; >> + >> + if (Offset < 0) { >> + MCE->emitByte(dwarf::DW_CFA_offset_extended_sf); >> + MCE->emitULEB128Bytes(Reg); >> + MCE->emitSLEB128Bytes(Offset); >> + } else if (Reg < 64) { >> + MCE->emitByte(dwarf::DW_CFA_offset + Reg); >> + MCE->emitULEB128Bytes(Offset); >> + } else { >> + MCE->emitByte(dwarf::DW_CFA_offset_extended); >> + MCE->emitULEB128Bytes(Reg); >> + MCE->emitULEB128Bytes(Offset); >> + } >> + } >> + } >> +} >> + >> +/// SharedTypeIds - How many leading type ids two landing pads have >> in common. >> +static unsigned SharedTypeIds(const LandingPadInfo *L, >> + const LandingPadInfo *R) { >> + const std::vector &LIds = L->TypeIds, &RIds = R->TypeIds; >> + unsigned LSize = LIds.size(), RSize = RIds.size(); >> + unsigned MinSize = LSize < RSize ? LSize : RSize; >> + unsigned Count = 0; >> + >> + for (; Count != MinSize; ++Count) >> + if (LIds[Count] != RIds[Count]) >> + return Count; >> + >> + return Count; >> +} >> + >> + >> +/// PadLT - Order landing pads lexicographically by type id. >> +static bool PadLT(const LandingPadInfo *L, const LandingPadInfo *R) { >> + const std::vector &LIds = L->TypeIds, &RIds = R->TypeIds; >> + unsigned LSize = LIds.size(), RSize = RIds.size(); >> + unsigned MinSize = LSize < RSize ? LSize : RSize; >> + >> + for (unsigned i = 0; i != MinSize; ++i) >> + if (LIds[i] != RIds[i]) >> + return LIds[i] < RIds[i]; >> + >> + return LSize < RSize; >> +} >> + >> +struct KeyInfo { >> + static inline unsigned getEmptyKey() { return -1U; } >> + static inline unsigned getTombstoneKey() { return -2U; } >> + static unsigned getHashValue(const unsigned &Key) { return Key; } >> + static bool isEqual(unsigned LHS, unsigned RHS) { return LHS == >> RHS; } >> + static bool isPod() { return true; } >> +}; >> + >> +/// ActionEntry - Structure describing an entry in the actions table. >> +struct ActionEntry { >> + int ValueForTypeID; // The value to write - may not be equal to >> the type id. >> + int NextAction; >> + struct ActionEntry *Previous; >> +}; >> + >> +/// PadRange - Structure holding a try-range and the associated >> landing pad. >> +struct PadRange { >> + // The index of the landing pad. >> + unsigned PadIndex; >> + // The index of the begin and end labels in the landing pad's >> label lists. >> + unsigned RangeIndex; >> +}; >> + >> +typedef DenseMap RangeMapType; >> + >> +/// CallSiteEntry - Structure describing an entry in the call-site >> table. >> +struct CallSiteEntry { >> + unsigned BeginLabel; // zero indicates the start of the function. >> + unsigned EndLabel; // zero indicates the end of the function. >> + unsigned PadLabel; // zero indicates that there is no landing >> pad. >> + unsigned Action; >> +}; >> + >> +unsigned char* JITDwarfEmitter::EmitExceptionTable(MachineFunction* >> MF, >> + unsigned char* >> StartFunction, >> + unsigned char* >> EndFunction) { >> + // Map all labels and get rid of any dead landing pads. >> + MMI->TidyLandingPads(); >> + >> + const std::vector &TypeInfos = MMI- >> >>> getTypeInfos(); >>> >> + const std::vector &FilterIds = MMI->getFilterIds(); >> + const std::vector &PadInfos = MMI- >> >>> getLandingPads(); >>> >> + if (PadInfos.empty()) return 0; >> + >> + // Sort the landing pads in order of their type ids. This is >> used to fold >> + // duplicate actions. >> + SmallVector LandingPads; >> + LandingPads.reserve(PadInfos.size()); >> + for (unsigned i = 0, N = PadInfos.size(); i != N; ++i) >> + LandingPads.push_back(&PadInfos[i]); >> + std::sort(LandingPads.begin(), LandingPads.end(), PadLT); >> + >> + // Negative type ids index into FilterIds, positive type ids >> index into >> + // TypeInfos. The value written for a positive type id is just >> the type >> + // id itself. For a negative type id, however, the value written >> is the >> + // (negative) byte offset of the corresponding FilterIds entry. >> The byte >> + // offset is usually equal to the type id, because the FilterIds >> entries >> + // are written using a variable width encoding which outputs one >> byte per >> + // entry as long as the value written is not too large, but can >> differ. >> + // This kind of complication does not occur for positive type ids >> because >> + // type infos are output using a fixed width encoding. >> + // FilterOffsets[i] holds the byte offset corresponding to >> FilterIds[i]. >> + SmallVector FilterOffsets; >> + FilterOffsets.reserve(FilterIds.size()); >> + int Offset = -1; >> + for(std::vector::const_iterator I = FilterIds.begin(), >> + E = FilterIds.end(); I != E; ++I) { >> + FilterOffsets.push_back(Offset); >> + Offset -= AsmPrinter::SizeULEB128(*I); >> + } >> + >> + // Compute the actions table and gather the first action index >> for each >> + // landing pad site. >> + SmallVector Actions; >> + SmallVector FirstActions; >> + FirstActions.reserve(LandingPads.size()); >> + >> + int FirstAction = 0; >> + unsigned SizeActions = 0; >> + for (unsigned i = 0, N = LandingPads.size(); i != N; ++i) { >> + const LandingPadInfo *LP = LandingPads[i]; >> + const std::vector &TypeIds = LP->TypeIds; >> + const unsigned NumShared = i ? SharedTypeIds(LP, >> LandingPads[i-1]) : 0; >> + unsigned SizeSiteActions = 0; >> + >> + if (NumShared < TypeIds.size()) { >> + unsigned SizeAction = 0; >> + ActionEntry *PrevAction = 0; >> + >> + if (NumShared) { >> + const unsigned SizePrevIds = LandingPads[i-1]- >> >>> TypeIds.size(); >>> >> + assert(Actions.size()); >> + PrevAction = &Actions.back(); >> + SizeAction = AsmPrinter::SizeSLEB128(PrevAction- >> >>> NextAction) + >>> >> + AsmPrinter::SizeSLEB128(PrevAction->ValueForTypeID); >> + for (unsigned j = NumShared; j != SizePrevIds; ++j) { >> + SizeAction -= AsmPrinter::SizeSLEB128(PrevAction- >> >>> ValueForTypeID); >>> >> + SizeAction += -PrevAction->NextAction; >> + PrevAction = PrevAction->Previous; >> + } >> + } >> + >> + // Compute the actions. >> + for (unsigned I = NumShared, M = TypeIds.size(); I != M; ++I) { >> + int TypeID = TypeIds[I]; >> + assert(-1-TypeID < (int)FilterOffsets.size() && "Unknown >> filter id!"); >> + int ValueForTypeID = TypeID < 0 ? FilterOffsets[-1 - >> TypeID] : TypeID; >> + unsigned SizeTypeID = >> AsmPrinter::SizeSLEB128(ValueForTypeID); >> + >> + int NextAction = SizeAction ? -(SizeAction + SizeTypeID) : 0; >> + SizeAction = SizeTypeID + >> AsmPrinter::SizeSLEB128(NextAction); >> + SizeSiteActions += SizeAction; >> + >> + ActionEntry Action = {ValueForTypeID, NextAction, >> PrevAction}; >> + Actions.push_back(Action); >> + >> + PrevAction = &Actions.back(); >> + } >> + >> + // Record the first action of the landing pad site. >> + FirstAction = SizeActions + SizeSiteActions - SizeAction + 1; >> + } // else identical - re-use previous FirstAction >> + >> + FirstActions.push_back(FirstAction); >> + >> + // Compute this sites contribution to size. >> + SizeActions += SizeSiteActions; >> + } >> + >> + // Compute the call-site table. Entries must be ordered by >> address. >> + SmallVector CallSites; >> + >> + RangeMapType PadMap; >> + for (unsigned i = 0, N = LandingPads.size(); i != N; ++i) { >> + const LandingPadInfo *LandingPad = LandingPads[i]; >> + for (unsigned j=0, E = LandingPad->BeginLabels.size(); j != E; + >> +j) { >> + unsigned BeginLabel = LandingPad->BeginLabels[j]; >> + assert(!PadMap.count(BeginLabel) && "Duplicate landing pad >> labels!"); >> + PadRange P = { i, j }; >> + PadMap[BeginLabel] = P; >> + } >> + } >> + >> + bool MayThrow = false; >> + unsigned LastLabel = 0; >> + for (MachineFunction::const_iterator I = MF->begin(), E = MF- >> >>> end(); >>> >> + I != E; ++I) { >> + for (MachineBasicBlock::const_iterator MI = I->begin(), E = I- >> >>> end(); >>> >> + MI != E; ++MI) { >> + if (MI->getOpcode() != TargetInstrInfo::LABEL) { >> + MayThrow |= MI->getDesc().isCall(); >> + continue; >> + } >> + >> + unsigned BeginLabel = MI->getOperand(0).getImm(); >> + assert(BeginLabel && "Invalid label!"); >> + >> + if (BeginLabel == LastLabel) >> + MayThrow = false; >> + >> + RangeMapType::iterator L = PadMap.find(BeginLabel); >> + >> + if (L == PadMap.end()) >> + continue; >> + >> + PadRange P = L->second; >> + const LandingPadInfo *LandingPad = LandingPads[P.PadIndex]; >> + >> + assert(BeginLabel == LandingPad->BeginLabels[P.RangeIndex] && >> + "Inconsistent landing pad map!"); >> + >> + // If some instruction between the previous try-range and >> this one may >> + // throw, create a call-site entry with no landing pad for >> the region >> + // between the try-ranges. >> + if (MayThrow) { >> + CallSiteEntry Site = {LastLabel, BeginLabel, 0, 0}; >> + CallSites.push_back(Site); >> + } >> + >> + LastLabel = LandingPad->EndLabels[P.RangeIndex]; >> + CallSiteEntry Site = {BeginLabel, LastLabel, >> + LandingPad->LandingPadLabel, FirstActions[P.PadIndex]}; >> + >> + assert(Site.BeginLabel && Site.EndLabel && Site.PadLabel && >> + "Invalid landing pad!"); >> + >> + // Try to merge with the previous call-site. >> + if (CallSites.size()) { >> + CallSiteEntry &Prev = CallSites[CallSites.size()-1]; >> + if (Site.PadLabel == Prev.PadLabel && Site.Action == >> Prev.Action) { >> + // Extend the range of the previous entry. >> + Prev.EndLabel = Site.EndLabel; >> + continue; >> + } >> + } >> + >> + // Otherwise, create a new call-site. >> + CallSites.push_back(Site); >> + } >> + } >> + // If some instruction between the previous try-range and the end >> of the >> + // function may throw, create a call-site entry with no landing >> pad for the >> + // region following the try-range. >> + if (MayThrow) { >> + CallSiteEntry Site = {LastLabel, 0, 0, 0}; >> + CallSites.push_back(Site); >> + } >> + >> + // Final tallies. >> + unsigned SizeSites = CallSites.size() * (sizeof(int32_t) + // >> Site start. >> + sizeof(int32_t) + // >> Site length. >> + sizeof(int32_t)); // >> Landing pad. >> + for (unsigned i = 0, e = CallSites.size(); i < e; ++i) >> + SizeSites += AsmPrinter::SizeULEB128(CallSites[i].Action); >> + >> + unsigned SizeTypes = TypeInfos.size() * TD->getPointerSize(); >> + >> + unsigned TypeOffset = sizeof(int8_t) + // Call site format >> + // Call-site table length >> + AsmPrinter::SizeULEB128(SizeSites) + >> + SizeSites + SizeActions + SizeTypes; >> + >> + unsigned TotalSize = sizeof(int8_t) + // LPStart format >> + sizeof(int8_t) + // TType format >> + AsmPrinter::SizeULEB128(TypeOffset) + // >> TType base offset >> + TypeOffset; >> + >> + unsigned SizeAlign = (4 - TotalSize) & 3; >> + >> + // Begin the exception table. >> + MCE->emitAlignment(4); >> + for (unsigned i = 0; i != SizeAlign; ++i) { >> + MCE->emitByte(0); >> + // Asm->EOL("Padding"); >> + } >> + >> + unsigned char* DwarfExceptionTable = (unsigned char*)MCE- >> >>> getCurrentPCValue(); >>> >> + >> + // Emit the header. >> + MCE->emitByte(dwarf::DW_EH_PE_omit); >> + // Asm->EOL("LPStart format (DW_EH_PE_omit)"); >> + MCE->emitByte(dwarf::DW_EH_PE_absptr); >> + // Asm->EOL("TType format (DW_EH_PE_absptr)"); >> + MCE->emitULEB128Bytes(TypeOffset); >> + // Asm->EOL("TType base offset"); >> + MCE->emitByte(dwarf::DW_EH_PE_udata4); >> + // Asm->EOL("Call site format (DW_EH_PE_udata4)"); >> + MCE->emitULEB128Bytes(SizeSites); >> + // Asm->EOL("Call-site table length"); >> + >> + // Emit the landing pad site information. >> + for (unsigned i = 0; i < CallSites.size(); ++i) { >> + CallSiteEntry &S = CallSites[i]; >> + intptr_t BeginLabelPtr = 0; >> + intptr_t EndLabelPtr = 0; >> + >> + if (!S.BeginLabel) { >> + BeginLabelPtr = (intptr_t)StartFunction; >> + if (TD->getPointerSize() == sizeof(int32_t)) >> + MCE->emitInt32(0); >> + else >> + MCE->emitInt64(0); >> + } else { >> + BeginLabelPtr = MCE->getLabelAddress(S.BeginLabel); >> + if (TD->getPointerSize() == sizeof(int32_t)) >> + MCE->emitInt32(BeginLabelPtr - (intptr_t)StartFunction); >> + else >> + MCE->emitInt64(BeginLabelPtr - (intptr_t)StartFunction); >> + } >> + >> + // Asm->EOL("Region start"); >> + >> + if (!S.EndLabel) { >> + EndLabelPtr = (intptr_t)EndFunction; >> + if (TD->getPointerSize() == sizeof(int32_t)) >> + MCE->emitInt32((intptr_t)EndFunction - BeginLabelPtr); >> + else >> + MCE->emitInt64((intptr_t)EndFunction - BeginLabelPtr); >> + } else { >> + EndLabelPtr = MCE->getLabelAddress(S.EndLabel); >> + if (TD->getPointerSize() == sizeof(int32_t)) >> + MCE->emitInt32(EndLabelPtr - BeginLabelPtr); >> + else >> + MCE->emitInt64(EndLabelPtr - BeginLabelPtr); >> + } >> + //Asm->EOL("Region length"); >> + >> + if (!S.PadLabel) { >> + if (TD->getPointerSize() == sizeof(int32_t)) >> + MCE->emitInt32(0); >> + else >> + MCE->emitInt64(0); >> + } else { >> + unsigned PadLabelPtr = MCE->getLabelAddress(S.PadLabel); >> + if (TD->getPointerSize() == sizeof(int32_t)) >> + MCE->emitInt32(PadLabelPtr - (intptr_t)StartFunction); >> + else >> + MCE->emitInt64(PadLabelPtr - (intptr_t)StartFunction); >> + } >> + // Asm->EOL("Landing pad"); >> + >> + MCE->emitULEB128Bytes(S.Action); >> + // Asm->EOL("Action"); >> + } >> + >> + // Emit the actions. >> + for (unsigned I = 0, N = Actions.size(); I != N; ++I) { >> + ActionEntry &Action = Actions[I]; >> + >> + MCE->emitSLEB128Bytes(Action.ValueForTypeID); >> + //Asm->EOL("TypeInfo index"); >> + MCE->emitSLEB128Bytes(Action.NextAction); >> + //Asm->EOL("Next action"); >> + } >> + >> + // Emit the type ids. >> + for (unsigned M = TypeInfos.size(); M; --M) { >> + GlobalVariable *GV = TypeInfos[M - 1]; >> + >> + if (GV) { >> + if (TD->getPointerSize() == sizeof(int32_t)) { >> + MCE->emitInt32((intptr_t)Jit.getOrEmitGlobalVariable(GV)); >> + } else { >> + MCE->emitInt64((intptr_t)Jit.getOrEmitGlobalVariable(GV)); >> + } >> + } else { >> + if (TD->getPointerSize() == sizeof(int32_t)) >> + MCE->emitInt32(0); >> + else >> + MCE->emitInt64(0); >> + } >> + // Asm->EOL("TypeInfo"); >> + } >> + >> + // Emit the filter typeids. >> + for (unsigned j = 0, M = FilterIds.size(); j < M; ++j) { >> + unsigned TypeID = FilterIds[j]; >> + MCE->emitULEB128Bytes(TypeID); >> + //Asm->EOL("Filter TypeInfo index"); >> + } >> + >> + MCE->emitAlignment(4); >> + >> + return DwarfExceptionTable; >> +} >> + >> +unsigned char* JITDwarfEmitter::EmitCommonEHFrame(const Function* >> Personality) { >> + unsigned PointerSize = TD->getPointerSize(); >> + int stackGrowth = stackGrowthDirection == >> TargetFrameInfo::StackGrowsUp ? >> + PointerSize : -PointerSize; >> + >> + unsigned char* StartCommonPtr = (unsigned char*)MCE- >> >>> getCurrentPCValue(); >>> >> + // EH Common Frame header >> + MCE->allocateSpace(PointerSize, 0); >> + unsigned char* FrameCommonBeginPtr = (unsigned char*)MCE- >> >>> getCurrentPCValue(); >>> >> + MCE->emitInt32((int)0); >> + MCE->emitByte(dwarf::DW_CIE_VERSION); >> + MCE->emitString(Personality ? "zPLR" : "zR"); >> + MCE->emitULEB128Bytes(1); >> + MCE->emitSLEB128Bytes(stackGrowth); >> + MCE->emitByte(RI->getDwarfRegNum(RI->getRARegister(), true)); >> + >> + if (Personality) { >> + MCE->emitULEB128Bytes(7); >> + >> + if (needsIndirectEncoding) >> + MCE->emitByte(dwarf::DW_EH_PE_pcrel | dwarf::DW_EH_PE_sdata4 | >> + dwarf::DW_EH_PE_indirect); >> + else >> + MCE->emitByte(dwarf::DW_EH_PE_pcrel | dwarf::DW_EH_PE_sdata4); >> + >> + if (PointerSize == 8) >> + MCE->emitInt64((intptr_t)Jit.getPointerToGlobal(Personality) - >> + MCE->getCurrentPCValue()); >> + else >> + MCE->emitInt32((intptr_t)Jit.getPointerToGlobal(Personality) - >> + MCE->getCurrentPCValue()); >> + >> + MCE->emitULEB128Bytes(dwarf::DW_EH_PE_pcrel); >> + MCE->emitULEB128Bytes(dwarf::DW_EH_PE_pcrel); >> + >> + } else { >> + MCE->emitULEB128Bytes(1); >> + MCE->emitULEB128Bytes(dwarf::DW_EH_PE_pcrel); >> + } >> + >> + std::vector Moves; >> + RI->getInitialFrameState(Moves); >> + EmitFrameMoves(0, Moves); >> + MCE->emitAlignment(4); >> + >> + MCE->emitAt((uintptr_t*)StartCommonPtr, >> + (uintptr_t)((unsigned char*)MCE->getCurrentPCValue() - >> + FrameCommonBeginPtr)); >> + >> + return StartCommonPtr; >> +} >> + >> + >> +unsigned char* JITDwarfEmitter::EmitEHFrame(const Function* >> Personality, >> + unsigned char* >> StartCommonPtr, >> + unsigned char* >> StartFunction, >> + unsigned char* >> EndFunction, >> + unsigned char* >> ExceptionTable) { >> + unsigned PointerSize = TD->getPointerSize(); >> + >> + // EH frame header. >> + unsigned char* StartEHPtr = (unsigned char*)MCE- >> >>> getCurrentPCValue(); >>> >> + MCE->allocateSpace(PointerSize, 0); >> + unsigned char* FrameBeginPtr = (unsigned char*)MCE- >> >>> getCurrentPCValue(); >>> >> + // FDE CIE Offset >> + if (PointerSize == 8) { >> + MCE->emitInt64(FrameBeginPtr - StartCommonPtr); >> + MCE->emitInt64(StartFunction - (unsigned char*)MCE- >> >>> getCurrentPCValue()); >>> >> + MCE->emitInt64(EndFunction - StartFunction); >> + } else { >> + MCE->emitInt32(FrameBeginPtr - StartCommonPtr); >> + MCE->emitInt32(StartFunction - (unsigned char*)MCE- >> >>> getCurrentPCValue()); >>> >> + MCE->emitInt32(EndFunction - StartFunction); >> + } >> + >> + // If there is a personality and landing pads then point to the >> language >> + // specific data area in the exception table. >> + if (MMI->getPersonalityIndex()) { >> + MCE->emitULEB128Bytes(4); >> + >> + if (!MMI->getLandingPads().empty()) { >> + if (PointerSize == 8) >> + MCE->emitInt64(ExceptionTable - (unsigned char*)MCE- >> >>> getCurrentPCValue()); >>> >> + else >> + MCE->emitInt32(ExceptionTable - (unsigned char*)MCE- >> >>> getCurrentPCValue()); >>> >> + } else if (PointerSize == 8) { >> + MCE->emitInt64((int)0); >> + } else { >> + MCE->emitInt32((int)0); >> + } >> + } else { >> + MCE->emitULEB128Bytes(0); >> + } >> + >> + // Indicate locations of function specific callee saved >> registers in >> + // frame. >> + EmitFrameMoves((intptr_t)StartFunction, MMI->getFrameMoves()); >> + >> + MCE->emitAlignment(4); >> + >> + // Indicate the size of the table >> + MCE->emitAt((uintptr_t*)StartEHPtr, >> + (uintptr_t)((unsigned char*)MCE->getCurrentPCValue() - >> + StartEHPtr)); >> + >> + // Double zeroes for the unwind runtime >> + if (PointerSize == 8) { >> + MCE->emitInt64(0); >> + MCE->emitInt64(0); >> + } else { >> + MCE->emitInt32(0); >> + MCE->emitInt32(0); >> + } >> + >> + >> + return StartEHPtr; >> +} >> _______________________________________________ >> 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 Feb 11 04:35:33 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 11 Feb 2008 11:35:33 +0100 Subject: [LLVMdev] "make check" failures: leaq in fold-mul-lohi.ll, stride-nine-with-base-reg.ll, stride-reuse.ll Message-ID: <200802111135.34863.baldrick@free.fr> I'm seeing the following failures with "make check" (x86-32 linux): FAIL: test/CodeGen/X86/fold-mul-lohi.ll Failed with exit(1) at line 2 while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc -march=x86-64 | not grep lea leaq B, %rsi leaq A, %r8 leaq P, %rsi child process exited abnormally FAIL: test/CodeGen/X86/stride-nine-with-base-reg.ll Failed with exit(1) at line 2 while running: llvm-as < test/CodeGen/X86/stride-nine-with-base-reg.ll | llc -march=x86-64 | not grep lea leaq B, %rdx leaq A, %r8 leaq P, %rdx child process exited abnormally FAIL: test/CodeGen/X86/stride-reuse.ll Failed with exit(1) at line 2 while running: llvm-as < test/CodeGen/X86/stride-reuse.ll | llc -march=x86-64 | not grep lea leaq B, %rsi leaq A, %rsi leaq P, %rsi child process exited abnormally From dalej at apple.com Mon Feb 11 12:26:41 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 11 Feb 2008 10:26:41 -0800 Subject: [LLVMdev] LLVM 2.2 Release Notes In-Reply-To: References: <108FAD2C-B6CB-4601-829B-BB2259A43148@apple.com> Message-ID: <5AF2B953-A124-406A-8FF4-AD8BCC96498F@apple.com> On Feb 10, 2008, at 11:26 PM, Chris Lattner wrote: >> This is a matter of presentation, but some of the "GCC extensions" >> are >> standard C99 (now, at least). I noticed long long, C++-style >> comments >> and designated initializers. >> >> I have plenty of complaints about the GCC documentation you're >> pointing at, but this probably isn't the right forum for that. I do >> think dropping "as fast as macros" from the "inline" description >> would >> be a good idea, that's pure propaganda: sometimes it's true and >> sometimes it isn't. > > I completely agree with you here. It looks like the GCC docs were > written vs C90 not C99. That whole section of the documentation was > more useful when there were a lot of GCC features we didn't support. > Now it looks like it can be ripped out and we can just keep a list of > things that don't work in our own words. Lets do this for the llvm > 2.3 release notes though, after Monday. ok. >> The miscompilation of code containing both MMX vectors and long >> double >> may be worth a mention, but it probably isn't going to bite very many >> people. (llvm does not insert EMMS everywhere it needs to, or from a >> different viewpoint, uses MMX when the user didn't tell it to.) > > AFAIK, many commonly used GCC versions don't do this either. If > that's the case, I don't think it's worth mentioning, because most > people will be concerned with "llvm regressions vs gcc" or something. > I believe that if you explicitly use mmx intrinsics you have to insert > emms yourself, and that the only other way to get mmx badness is > through use of the gcc generic vector extension. If this is true, I > think we should be ok. I think that is true, but, the situtation with llvm is rather worse than with gcc: llvm uses MMX registers for mem-to-mem copies of 64- bit vectors, while gcc does not. gcc attempts to restrict its use of MMX to the MMX builtins, and the loads and stores connected to them; we think it is possible for RA spilling to use MMX registers erroneously, but this is not common. From gohman at apple.com Mon Feb 11 17:47:24 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 11 Feb 2008 15:47:24 -0800 Subject: [LLVMdev] APInt::getBitsSet Message-ID: APInt::getBitsSet's loBit and hiBit arguments describe a range that's inclusive on both ends. Would anyone mind if we change it to be a "half-open" range, meaning exclusive on the high end? Currently every caller (including several new ones in some code I'm writing right now) does a subtract by one to adjust for the current behavior. And the implementation does an add by one for its part. It would be simpler on both sides to just define the hiBit as being one past the last bit set. Dan From scottm at aero.org Mon Feb 11 20:15:08 2008 From: scottm at aero.org (Scott Michel) Date: Mon, 11 Feb 2008 18:15:08 -0800 Subject: [LLVMdev] tblgen and sign-extended constants too large for type In-Reply-To: <47AD1368.1030005@rush.aero.org> References: <47AD1368.1030005@rush.aero.org> Message-ID: <6CF212CA-775C-41E3-8343-60A4169F71D0@aero.org> Allow me to rephrase my question: How much agony and gnashing of teeth will I cause if I commit this patch to tblgen (fully tested and changes to DAGISelEmitter.cpp also committed)? -scooter On Feb 8, 2008, at 6:43 PM, Scott Michel wrote: > Question: How hard should tblgen try to fit constants into a > particular > type? > > My case is an xor with i8 immediate where I'm using 0xff in as the > immediate value. 0xff should fit into i8 if treated as unsigned, but > CodeGenDAGPatterns.cpp assumes that any and all integers less than > 32-bits are signed. > > Should tblgen try to see if the sign-extended version of the constant > could fit into the type, and failing that, try the unsigned version: > > Index: utils/TableGen/CodeGenDAGPatterns.cpp > =================================================================== > --- utils/TableGen/CodeGenDAGPatterns.cpp (revision 8028) > +++ utils/TableGen/CodeGenDAGPatterns.cpp (working copy) > @@ -685,10 +685,17 @@ > // Make sure that the value is representable for this type. > if (Size < 32) { > int Val = (II->getValue() << (32-Size)) >> (32-Size); > - if (Val != II->getValue()) > - TP.error("Sign-extended integer value '" + > itostr(II->getValue())+ > - "' is out of range for type '" + > - getEnumName(getTypeNum(0)) + "'!"); > + if (Val != II->getValue()) { > + // If sign-extended doesn't fit, does it fit as unsigned? > + unsigned ValueMask = unsigned(MVT::getIntVTBitMask(VT)); > + unsigned UnsignedVal = unsigned(II->getValue()); > + > + if ((ValueMask & UnsignedVal) != UnsignedVal) { > + TP.error("Integer value '" + itostr(II->getValue())+ > + "' is out of range for type '" + > + getEnumName(getTypeNum(0)) + "'!"); > + } > + } > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From scottm at rushg.aero.org Mon Feb 11 21:16:17 2008 From: scottm at rushg.aero.org (Scott Michel) Date: Mon, 11 Feb 2008 19:16:17 -0800 Subject: [LLVMdev] tblgen and sign-extended constants too large for type In-Reply-To: <6CF212CA-775C-41E3-8343-60A4169F71D0@aero.org> References: <47AD1368.1030005@rush.aero.org> <6CF212CA-775C-41E3-8343-60A4169F71D0@aero.org> Message-ID: <47B10F81.3000401@rush.aero.org> Scott Michel wrote: > Allow me to rephrase my question: How much agony and gnashing of > teeth will I cause if I commit this patch to tblgen (fully tested and > changes to DAGISelEmitter.cpp also committed)? I tested the aforementioned patch in the test subdirectory and the tests all passed. The basic implication from this patch is that all constants emitted by tblgen will be uint64_t hex constants and tblgen won't complain when a sign-extended value won't fit i16 or i8 or i(i<32-bit) type even though it would if it were treated as unsigned. -scooter (who's not going to beg forgiveness if the patch isn't Lattnerized(tm)) From evan.cheng at apple.com Mon Feb 11 23:21:57 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 11 Feb 2008 21:21:57 -0800 Subject: [LLVMdev] Some questions about live intervals In-Reply-To: <594190.70546.qm@web56304.mail.re3.yahoo.com> References: <594190.70546.qm@web56304.mail.re3.yahoo.com> Message-ID: On Feb 10, 2008, at 11:44 PM, Roman Levenstein wrote: > Hi Evan, > > --- Evan Cheng wrote: > >> Thanks. One question though. Should getMBBFromIndex() assert if given >> an index out of the range or simply returns a NULL pointer? I would >> think the later makes it a bit more friendly. > > Yes. It would be more friendly, probably. I can submit such a patch, > if > you think it suits better. > > On the other hand I want to mention the following pros: > - assert-based approach follows the style of all other getNNN > functions in LiveIntervalAnalysis.h. They all assert in out-of-range > cases. > - What does it mean, if you have a situation where you ask for the MBB > of an instruction index, which is out of range for any MBB? How can > this happen? If you know the index, then instruction should have been > already registered before, it's number is known and it is supposed to > belong to an MBB. If not, some internal mapping tables (e.g. start and > end of MBBs, index to MBB mappings, etc) in LiveIntervalAnalysis are > likely to be broken. In this case, it is better to assert() in those > cases, IMHO. > > Please, let me know, if I should sumbit a patch without any assert() > and returning just a NULL pointer. Now I think either approach is fine. Please commit. Thanks! Evan > > > -Roman > > >> On Feb 8, 2008, at 8:59 AM, Roman Levenstein wrote: >> >>> Hi Evan, >>> >>> Here is a patch for the LiveIntervalAnalysis that we discussed. >>> >>> --- Evan Cheng schrieb: >>>>> 1) What is the easiest way to understand which MBB a given >>>> instruction index belongs to? All the required information is >>>> available in the >>>>> MBB2IdxMap of the LiveIntervalAnalysis class. Would it be useful >>>> to add a small function getMBBFromIndex() to this class? >>>> >>>> Sure there is a reverse map (actually just a vector) Idx2MBBMap. >>>> Justadd a query. >>> >>> Done. Please find a patch attached to this mail. >>> >>>>> As for (1) and (2), I could implement and provide patches for it, >>>>> if you think this is desirable. >>>> >>>> Yes, thanks. >>> >>> Here you are! >>> >>> -Roman >>> >>> >>> Lesen Sie Ihre E-Mails auf dem Handy. >>> www.yahoo.de/goIndex: lib/CodeGen/LiveIntervalAnalysis.cpp >>> =================================================================== >>> --- lib/CodeGen/LiveIntervalAnalysis.cpp (revision 46884) >>> +++ lib/CodeGen/LiveIntervalAnalysis.cpp (working copy) >>> @@ -79,22 +79,7 @@ >>> delete ClonedMIs[i]; >>> } >>> >>> -namespace llvm { >>> - inline bool operator<(unsigned V, const IdxMBBPair &IM) { >>> - return V < IM.first; >>> - } >>> >>> - inline bool operator<(const IdxMBBPair &IM, unsigned V) { >>> - return IM.first < V; >>> - } >>> - >>> - struct Idx2MBBCompare { >>> - bool operator()(const IdxMBBPair &LHS, const IdxMBBPair &RHS) >> >>> const { >>> - return LHS.first < RHS.first; >>> - } >>> - }; >>> -} >>> - >>> Index: include/llvm/CodeGen/LiveIntervalAnalysis.h >>> =================================================================== >>> --- include/llvm/CodeGen/LiveIntervalAnalysis.h (revision 46884) >>> +++ include/llvm/CodeGen/LiveIntervalAnalysis.h (working copy) >>> @@ -40,6 +40,20 @@ >>> class VirtRegMap; >>> typedef std::pair IdxMBBPair; >>> >>> + inline bool operator<(unsigned V, const IdxMBBPair &IM) { >>> + return V < IM.first; >>> + } >>> + >>> + inline bool operator<(const IdxMBBPair &IM, unsigned V) { >>> + return IM.first < V; >>> + } >>> + >>> + struct Idx2MBBCompare { >>> + bool operator()(const IdxMBBPair &LHS, const IdxMBBPair &RHS) >> >>> const { >>> + return LHS.first < RHS.first; >>> + } >>> + }; >>> + >>> class LiveIntervals : public MachineFunctionPass { >>> MachineFunction* mf_; >>> const TargetMachine* tm_; >>> @@ -153,6 +167,23 @@ >>> return MBB2IdxMap[MBBNo].second; >>> } >>> >>> + /// getMBBFromIndex - given an index in any instruction of an >>> + /// MBB return a pointer the MBB >>> + MachineBasicBlock* getMBBFromIndex(unsigned index) const { >>> + std::vector::const_iterator I = >>> + std::lower_bound(Idx2MBBMap.begin(), Idx2MBBMap.end(), >> index); >>> + >>> + // Take previous pair >>> + std::vector::const_iterator J = >>> + ((I != Idx2MBBMap.end() && I->first > index) || >>> + (I == Idx2MBBMap.end() && Idx2MBBMap.size()>0)) ? (I-1): I; >>> + >>> + assert(J != Idx2MBBMap.end() && J->first < index+1 && >>> + index < getMBBEndIdx(J->second) && >>> + "index does not correspond to an MBB"); >>> + return J->second; >>> + } >>> + >>> /// getInstructionIndex - returns the base index of instr >>> unsigned getInstructionIndex(MachineInstr* instr) const { >>> Mi2IndexMap::const_iterator it = mi2iMap_.find(instr); >>> _______________________________________________ >>> 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 >> > > > > __________________________________ Ihre erste Baustelle? > Wissenswertes f?r Bastler und Hobby Handwerker. www.yahoo.de/clever > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Mon Feb 11 23:51:49 2008 From: sabre at nondot.org (Chris Lattner) Date: Mon, 11 Feb 2008 21:51:49 -0800 Subject: [LLVMdev] APInt::getBitsSet In-Reply-To: References: Message-ID: <98543103-38A0-4271-A7BA-FB8B91FADB9F@nondot.org> On Feb 11, 2008, at 3:47 PM, Dan Gohman wrote: > APInt::getBitsSet's loBit and hiBit arguments describe a range that's > inclusive > on both ends. Would anyone mind if we change it to be a "half-open" > range, > meaning exclusive on the high end? I think that is much more consistent with the way the STL works, and is thus less surprising, go for it! -Chris From lee225 at uiuc.edu Tue Feb 12 00:04:36 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Tue, 12 Feb 2008 00:04:36 -0600 (CST) Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? Message-ID: <20080212000436.BBO10317@expms2.cites.uiuc.edu> Hello all, Is there anyone has tried LLVM 2.1 on Visual Studio 2005? I did but not succeed due to some build errors. I seem to remember I read somewhere on this list it's compiled on VS2005 so I wonder... Have a good night. Thx, Seung From sabre at nondot.org Tue Feb 12 00:48:42 2008 From: sabre at nondot.org (Chris Lattner) Date: Mon, 11 Feb 2008 22:48:42 -0800 Subject: [LLVMdev] LLVM 2.2 Release Notes In-Reply-To: <5AF2B953-A124-406A-8FF4-AD8BCC96498F@apple.com> References: <108FAD2C-B6CB-4601-829B-BB2259A43148@apple.com> <5AF2B953-A124-406A-8FF4-AD8BCC96498F@apple.com> Message-ID: On Feb 11, 2008, at 10:26 AM, Dale Johannesen wrote: >>> I have plenty of complaints about the GCC documentation you're >>> pointing at, but this probably isn't the right forum for that. I >>> do >>> think dropping "as fast as macros" from the "inline" description >>> would >>> be a good idea, that's pure propaganda: sometimes it's true and >>> sometimes it isn't. >> >> I completely agree with you here. It looks like the GCC docs were >> written vs C90 not C99. That whole section of the documentation was >> more useful when there were a lot of GCC features we didn't support. >> Now it looks like it can be ripped out and we can just keep a list of >> things that don't work in our own words. Lets do this for the llvm >> 2.3 release notes though, after Monday. > > ok. I ripped this out from mainline ("llvm 2.3") release notes. >>> The miscompilation of code containing both MMX vectors and long >>> double >>> may be worth a mention, but it probably isn't going to bite very >>> many >>> people. (llvm does not insert EMMS everywhere it needs to, or >>> from a >>> different viewpoint, uses MMX when the user didn't tell it to.) >> >> AFAIK, many commonly used GCC versions don't do this either. If >> that's the case, I don't think it's worth mentioning, because most >> people will be concerned with "llvm regressions vs gcc" or something. >> I believe that if you explicitly use mmx intrinsics you have to >> insert >> emms yourself, and that the only other way to get mmx badness is >> through use of the gcc generic vector extension. If this is true, I >> think we should be ok. > > I think that is true, but, the situtation with llvm is rather worse > than with gcc: llvm uses MMX registers for mem-to-mem copies of 64- > bit vectors, while gcc does not. gcc attempts to restrict its use of > MMX to the MMX builtins, and the loads and stores connected to them; > we think it is possible for RA spilling to use MMX registers > erroneously, but this is not common. Ok. I don't think the release notes are a great place to go into this though. Is this an issue we can fix on mainline? -Chris From viridia at gmail.com Tue Feb 12 00:51:47 2008 From: viridia at gmail.com (Talin) Date: Mon, 11 Feb 2008 22:51:47 -0800 Subject: [LLVMdev] GC heap implementation Message-ID: <47B14203.6030108@gmail.com> I'd like to share some code with anyone who is interested. A while back I started working on the problem of implementing a garbage collector using the LLVM primitives. While I managed to accomplish a fair bit in this direction, I eventually realized that it was distracting me from my main goal, which is implementing a compiler for a strongly-typed language of my own design. In other words, I was writing a GC implementation because I needed one, not necessarily because I wanted to write one. I decided to push the GC project to the back burner and focus on my main goal, on the theory that while that was happening the GC problem might be worked on by someone else. Although my GC code was initially intended to support my runtime, I've lately been using it in the compiler. I realized that in my case, I couldn't keep on using llvm::BumpPtrAllocator because I couldn't make guarantees about the lifetime of AST nodes in my compiler, and if I used a malloc-based allocator I would have to do something like reference counting. Instead, I took one component of my GC - the general heap implementation - and built a trivial mark & sweep collector on top of it, which seems to be working very well for my purpose. This GC heap was to be the foundation for my collector. It's loosely inspired by the popular dlmalloc implementation (although it doesn't directly take any code from it), but it also supports a number of features useful for implementing a collector, such as the ability to efficiently walk the heap and free blocks based on a predicate callback. It also reserves space in the 8-byte allocation header for an opaque type tag pointer (or debug string if you don't need tags) as well as room for 2 mark bits. It supports aligned allocations, which is useful for doing work with SIMD instructions. It supports compile-time configurable guard bytes, small block bins, and other things you would expect in a modern allocator. The heap is thread-safe, and uses only pthread primitives for locking. It allows the heap to be non-contiguous, so if you have other libraries that are calling regular libc malloc you can still coexist with them. The code is written in fairly-well commented ANSI C and includes a number of unit tests. In any case, this code is currently lying fallow, so if anyone is interested in working with it I will be glad to donate it. -- Talin From evan.cheng at apple.com Tue Feb 12 01:08:36 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 11 Feb 2008 23:08:36 -0800 Subject: [LLVMdev] tblgen and sign-extended constants too large for type In-Reply-To: <47AD1368.1030005@rush.aero.org> References: <47AD1368.1030005@rush.aero.org> Message-ID: My feeling is tblgen shouldn't make assumptions about whether the backend will treat the value as signed or unsigned (after all MVT::ValueType does not convey sign information). Perhaps it's cleaner to just check if it fits as unsigned? Chris? Evan On Feb 8, 2008, at 6:43 PM, Scott Michel wrote: > Question: How hard should tblgen try to fit constants into a > particular > type? > > My case is an xor with i8 immediate where I'm using 0xff in as the > immediate value. 0xff should fit into i8 if treated as unsigned, but > CodeGenDAGPatterns.cpp assumes that any and all integers less than > 32-bits are signed. > > Should tblgen try to see if the sign-extended version of the constant > could fit into the type, and failing that, try the unsigned version: > > Index: utils/TableGen/CodeGenDAGPatterns.cpp > =================================================================== > --- utils/TableGen/CodeGenDAGPatterns.cpp (revision 8028) > +++ utils/TableGen/CodeGenDAGPatterns.cpp (working copy) > @@ -685,10 +685,17 @@ > // Make sure that the value is representable for this type. > if (Size < 32) { > int Val = (II->getValue() << (32-Size)) >> (32-Size); > - if (Val != II->getValue()) > - TP.error("Sign-extended integer value '" + > itostr(II->getValue())+ > - "' is out of range for type '" + > - getEnumName(getTypeNum(0)) + "'!"); > + if (Val != II->getValue()) { > + // If sign-extended doesn't fit, does it fit as unsigned? > + unsigned ValueMask = unsigned(MVT::getIntVTBitMask(VT)); > + unsigned UnsignedVal = unsigned(II->getValue()); > + > + if ((ValueMask & UnsignedVal) != UnsignedVal) { > + TP.error("Integer value '" + itostr(II->getValue())+ > + "' is out of range for type '" + > + getEnumName(getTypeNum(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 Tue Feb 12 01:22:45 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 11 Feb 2008 23:22:45 -0800 Subject: [LLVMdev] "make check" failures: leaq in fold-mul-lohi.ll, stride-nine-with-base-reg.ll, stride-reuse.ll In-Reply-To: <200802111135.34863.baldrick@free.fr> References: <200802111135.34863.baldrick@free.fr> Message-ID: <4CD9AB0F-B255-4CF9-851A-60073C4C0154@apple.com> Fixed. Thanks. Evan On Feb 11, 2008, at 2:35 AM, Duncan Sands wrote: > I'm seeing the following failures with "make check" (x86-32 linux): > > FAIL: test/CodeGen/X86/fold-mul-lohi.ll > Failed with exit(1) at line 2 > while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc - > march=x86-64 | not grep lea > leaq B, %rsi > leaq A, %r8 > leaq P, %rsi > child process exited abnormally > FAIL: test/CodeGen/X86/stride-nine-with-base-reg.ll > Failed with exit(1) at line 2 > while running: llvm-as < test/CodeGen/X86/stride-nine-with-base- > reg.ll | llc -march=x86-64 | not grep lea > leaq B, %rdx > leaq A, %r8 > leaq P, %rdx > child process exited abnormally > FAIL: test/CodeGen/X86/stride-reuse.ll > Failed with exit(1) at line 2 > while running: llvm-as < test/CodeGen/X86/stride-reuse.ll | llc - > march=x86-64 | not grep lea > leaq B, %rsi > leaq A, %rsi > leaq P, %rsi > child process exited abnormally > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From llvmdev at gmail.com Tue Feb 12 06:00:33 2008 From: llvmdev at gmail.com (Sanjiv Gupta) Date: Tue, 12 Feb 2008 17:30:33 +0530 Subject: [LLVMdev] 2.2 build failure Message-ID: <56aaf0ef0802120400g3c10fd58lcaf1fff1e29a0474@mail.gmail.com> I am using gcc 3.2.3 on RHEL 3 to build llvm 2.2. Below are the build errors: /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:147: no type named `NodeType' in `class llvm::BasicBlock' /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:150: ` VInfo' undeclared (first use this function) /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:152: no matching function for call to `Compress( llvm::DominatorTreeBase&, llvm::BasicBlock*&)' TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080212/02347f4c/attachment.html From aditya at iss.tu-darmstadt.de Tue Feb 12 06:13:22 2008 From: aditya at iss.tu-darmstadt.de (Aditya Vishnubhotla Vijay) Date: Tue, 12 Feb 2008 13:13:22 +0100 Subject: [LLVMdev] Inrinsic Creation Problem Message-ID: <200802121313.22198.aditya@iss.tu-darmstadt.de> Hi, I tried creating intrinsics which are to be placeholders for some instructions which should not be executed by the backend. Kindly help me with the errors in my "migrate_begin" intrinsic creation The following are the additions made to the Intrinsics.td file def llvm_migrate_begin : LLVMType; def int_migrate_begin : Intrinsic<[llvm_migrate_begin,llvm_vararg_ty], [IntrWriteMem],"llvm.migrate_begin">; A section of the code which deals with the "migrate_begin" intrinsic creation is as follows const Type **Tys=(const Type**)calloc(extTys.size(),sizeof(Type*)); /* extTys vector contains data types(pointers) of formal parameters of the function "f" */ int i=0; for(vector::iterator it=extTys.begin(),e=extTys.end();it!=e;it++) {Tys[i++]=*it;} extTys.clear(); Module *M = bbp->getParent()->getParent(); Function *f = Intrinsic::getDeclaration(M,Intrinsic::migrate_begin,Tys,i); /* migrate_begin intrinsic creation */ CallInst* CI = new CallInst(f,bbp); /*bbp is pointer to basic block where intrinsic is to be inserted*/ Errors: /work/aditya/llvm-2.1/Debug/bin/opt(llvm::FunctionType::FunctionType(llvm::Type const*, std::vector > const&, bool, llvm::ParamAttrsList const*)+0x6a)[0x85ea1d0] /work/aditya/llvm-2.1/Debug/bin/opt(llvm::FunctionType::get(llvm::Type const*, std::vector > const&, bool, llvm::ParamAttrsList const*)+0xc5)[0x85ecd01] /work/aditya/llvm-2.1/Debug/bin/opt(llvm::Intrinsic::getType(llvm::Intrinsic::ID, llvm::Type const**, unsigned int)+0x3f8e)[0x85ad73e] /work/aditya/llvm-2.1/Debug/bin/opt(llvm::Intrinsic::getDeclaration(llvm::Module*,llvm::Intrinsic::ID,llvm::Type const**, unsigned int)+0x20)[0x85ad8ea] From nunoplopes at sapo.pt Tue Feb 12 11:14:09 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Tue, 12 Feb 2008 17:14:09 -0000 Subject: [LLVMdev] slashdoted! Message-ID: <2E3130CDCFAD40A2AC525ECF9D0EA1F5@pc07654> Hi, The LLVM 2.2 release got slashdoted: http://developers.slashdot.org/article.pl?sid=08/02/12/1431222 Congratulations everybody :) Nuno From sabre at nondot.org Tue Feb 12 12:22:30 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 12 Feb 2008 10:22:30 -0800 (PST) Subject: [LLVMdev] 2.2 build failure In-Reply-To: <56aaf0ef0802120400g3c10fd58lcaf1fff1e29a0474@mail.gmail.com> References: <56aaf0ef0802120400g3c10fd58lcaf1fff1e29a0474@mail.gmail.com> Message-ID: On Tue, 12 Feb 2008, Sanjiv Gupta wrote: > I am using gcc 3.2.3 on RHEL 3 to build llvm 2.2. > Below are the build errors: > > /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:147: > no > type named `NodeType' in `class llvm::BasicBlock' > /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:150: > ` > VInfo' undeclared (first use this function) > /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:152: > no > matching function for call to `Compress( > llvm::DominatorTreeBase&, llvm::BasicBlock*&)' That is a very strange error: I think the code is fine, but your GCC is confused. I notice that GCC 3.2.2 is listed as a "known bad" version of GCC. It could be that 3.2.3 is also broken as well. Is there any local source change you can make to that file that gets it working? If not, I'd suggest upgrading to a newer GCC. Sorry :( -Chris -- http://nondot.org/sabre/ http://llvm.org/ From gohman at apple.com Tue Feb 12 12:10:02 2008 From: gohman at apple.com (Dan Gohman) Date: Tue, 12 Feb 2008 10:10:02 -0800 Subject: [LLVMdev] "make check" failures: leaq in fold-mul-lohi.ll, stride-nine-with-base-reg.ll, stride-reuse.ll In-Reply-To: <4CD9AB0F-B255-4CF9-851A-60073C4C0154@apple.com> References: <200802111135.34863.baldrick@free.fr> <4CD9AB0F-B255-4CF9-851A-60073C4C0154@apple.com> Message-ID: <440C3BDB-3FA2-4CED-9D69-170FBA47F988@apple.com> Hi Evan, In -relocation-model=static mode, those tests are now getting code like this leaq A, %rsi movss %xmm0, (%rsi,%rdx,4) instead of this: movss %xmm0, A(,%rdx,4) This is specifically what these tests were written to catch :-). Running them with -relocation-model=pic is hiding the real bug. Dan On Feb 11, 2008, at 11:22 PM, Evan Cheng wrote: > Fixed. Thanks. > > Evan > > On Feb 11, 2008, at 2:35 AM, Duncan Sands wrote: > >> I'm seeing the following failures with "make check" (x86-32 linux): >> >> FAIL: test/CodeGen/X86/fold-mul-lohi.ll >> Failed with exit(1) at line 2 >> while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc - >> march=x86-64 | not grep lea >> leaq B, %rsi >> leaq A, %r8 >> leaq P, %rsi >> child process exited abnormally >> FAIL: test/CodeGen/X86/stride-nine-with-base-reg.ll >> Failed with exit(1) at line 2 >> while running: llvm-as < test/CodeGen/X86/stride-nine-with-base- >> reg.ll | llc -march=x86-64 | not grep lea >> leaq B, %rdx >> leaq A, %r8 >> leaq P, %rdx >> child process exited abnormally >> FAIL: test/CodeGen/X86/stride-reuse.ll >> Failed with exit(1) at line 2 >> while running: llvm-as < test/CodeGen/X86/stride-reuse.ll | llc - >> march=x86-64 | not grep lea >> leaq B, %rsi >> leaq A, %rsi >> leaq P, %rsi >> child process exited abnormally >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From isanbard at gmail.com Tue Feb 12 12:51:15 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 12 Feb 2008 10:51:15 -0800 Subject: [LLVMdev] LLVM DevMeet 2008 In-Reply-To: <86fc46910802120151r2ad6aa4ah214abc4881fd7310@mail.gmail.com> References: <86fc46910802120151r2ad6aa4ah214abc4881fd7310@mail.gmail.com> Message-ID: <16e5fdf90802121051m78a9a709lfc4820868ec26555@mail.gmail.com> [CCing the list] On Feb 12, 2008 1:51 AM, Dan Moniz wrote: > Hi there, > > Kenneth Hoste suggested I get in touch with you as lead wrangler on > scheduling the 2008 LLVM DevMeet. I can't speak for others, but I know > I'm pretty packed with travel in August already, only some of which is > going to be directly sponsored or endorsed by work. Everything else > will have to be out of my personal time budget. I'd actually prefer > something *later*, like September, but that's probably not agreeable > to others. Maybe early-ish July instead? > Hi Dan, As far as I know, a date hasn't been set yet. I personally don't have a preference, but then again I don't travel much. :-) -bw From tonic at nondot.org Tue Feb 12 13:46:52 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 12 Feb 2008 11:46:52 -0800 (PST) Subject: [LLVMdev] LLVM DevMeet 2008 In-Reply-To: <16e5fdf90802121051m78a9a709lfc4820868ec26555@mail.gmail.com> References: <86fc46910802120151r2ad6aa4ah214abc4881fd7310@mail.gmail.com> <16e5fdf90802121051m78a9a709lfc4820868ec26555@mail.gmail.com> Message-ID: >> Kenneth Hoste suggested I get in touch with you as lead wrangler on >> scheduling the 2008 LLVM DevMeet. I can't speak for others, but I know >> I'm pretty packed with travel in August already, only some of which is >> going to be directly sponsored or endorsed by work. Everything else >> will have to be out of my personal time budget. I'd actually prefer >> something *later*, like September, but that's probably not agreeable >> to others. Maybe early-ish July instead? >> > Hi Dan, > > As far as I know, a date hasn't been set yet. I personally don't have > a preference, but then again I don't travel much. :-) Just an FYI, here is the website on the upcoming LLVM developers meeting: http://llvm.org/devmtg/current/ Please note that anyone interested in attending/presenting should email Jonathan Johnson (email on that page). He has volunteered to help gather information about presenters/attendees and keep that web page up to date. I'll be handling the logistics of the meeting (hotel, location, meals, etc). The date has not been set at this time, but Chris did want to give people an idea of when it could happen. The main thing to draw is that we will not be having it in May as we did last year. We'd like to narrow it down to a couple of dates instead of a broad range. So once we get that figured out we will do a poll and see which is most popular. We'd love to pick a date where everyone can come, but thats just not possible :) Thanks, Tanya Lattner From evan.cheng at apple.com Tue Feb 12 13:22:36 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 12 Feb 2008 11:22:36 -0800 Subject: [LLVMdev] "make check" failures: leaq in fold-mul-lohi.ll, stride-nine-with-base-reg.ll, stride-reuse.ll In-Reply-To: <440C3BDB-3FA2-4CED-9D69-170FBA47F988@apple.com> References: <200802111135.34863.baldrick@free.fr> <4CD9AB0F-B255-4CF9-851A-60073C4C0154@apple.com> <440C3BDB-3FA2-4CED-9D69-170FBA47F988@apple.com> Message-ID: Fixed. However, I wonder if we are doing the right / smart codegen for static codegen. AMD64 ABI document seems to indicate rip relative addressing should be used even in this case (see page 38). You know about about Linux addressing mode than I do. Please check. Thanks, Evan On Feb 12, 2008, at 10:10 AM, Dan Gohman wrote: > Hi Evan, > > In -relocation-model=static mode, those tests are now getting > code like this > > leaq A, %rsi > movss %xmm0, (%rsi,%rdx,4) > > instead of this: > > movss %xmm0, A(,%rdx,4) > > This is specifically what these tests were written to catch :-). > Running them with -relocation-model=pic is hiding the real bug. > > Dan > > On Feb 11, 2008, at 11:22 PM, Evan Cheng wrote: > >> Fixed. Thanks. >> >> Evan >> >> On Feb 11, 2008, at 2:35 AM, Duncan Sands wrote: >> >>> I'm seeing the following failures with "make check" (x86-32 linux): >>> >>> FAIL: test/CodeGen/X86/fold-mul-lohi.ll >>> Failed with exit(1) at line 2 >>> while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc - >>> march=x86-64 | not grep lea >>> leaq B, %rsi >>> leaq A, %r8 >>> leaq P, %rsi >>> child process exited abnormally >>> FAIL: test/CodeGen/X86/stride-nine-with-base-reg.ll >>> Failed with exit(1) at line 2 >>> while running: llvm-as < test/CodeGen/X86/stride-nine-with-base- >>> reg.ll | llc -march=x86-64 | not grep lea >>> leaq B, %rdx >>> leaq A, %r8 >>> leaq P, %rdx >>> child process exited abnormally >>> FAIL: test/CodeGen/X86/stride-reuse.ll >>> Failed with exit(1) at line 2 >>> while running: llvm-as < test/CodeGen/X86/stride-reuse.ll | llc - >>> march=x86-64 | not grep lea >>> leaq B, %rsi >>> leaq A, %rsi >>> leaq P, %rsi >>> child process exited abnormally >>> _______________________________________________ >>> 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 Feb 12 13:48:44 2008 From: gohman at apple.com (Dan Gohman) Date: Tue, 12 Feb 2008 11:48:44 -0800 Subject: [LLVMdev] "make check" failures: leaq in fold-mul-lohi.ll, stride-nine-with-base-reg.ll, stride-reuse.ll In-Reply-To: References: <200802111135.34863.baldrick@free.fr> <4CD9AB0F-B255-4CF9-851A-60073C4C0154@apple.com> <440C3BDB-3FA2-4CED-9D69-170FBA47F988@apple.com> Message-ID: <0C0AF196-5A76-4C3E-B341-C247598EEF96@apple.com> Rip-relative addressing can't be used with an index register, so in cases where an index register is being used, the benefit of using rip-relative addressing in non-PIC modes is outweighed by the additional instructions and registers needed to do the index computations. The examples on page 38 don't have any cases with indicies :-). Dan On Feb 12, 2008, at 11:22 AM, Evan Cheng wrote: > Fixed. However, I wonder if we are doing the right / smart codegen for > static codegen. AMD64 ABI document seems to indicate rip relative > addressing should be used even in this case (see page 38). You know > about about Linux addressing mode than I do. Please check. > > Thanks, > > Evan > > On Feb 12, 2008, at 10:10 AM, Dan Gohman wrote: > >> Hi Evan, >> >> In -relocation-model=static mode, those tests are now getting >> code like this >> >> leaq A, %rsi >> movss %xmm0, (%rsi,%rdx,4) >> >> instead of this: >> >> movss %xmm0, A(,%rdx,4) >> >> This is specifically what these tests were written to catch :-). >> Running them with -relocation-model=pic is hiding the real bug. >> >> Dan >> >> On Feb 11, 2008, at 11:22 PM, Evan Cheng wrote: >> >>> Fixed. Thanks. >>> >>> Evan >>> >>> On Feb 11, 2008, at 2:35 AM, Duncan Sands wrote: >>> >>>> I'm seeing the following failures with "make check" (x86-32 linux): >>>> >>>> FAIL: test/CodeGen/X86/fold-mul-lohi.ll >>>> Failed with exit(1) at line 2 >>>> while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc - >>>> march=x86-64 | not grep lea >>>> leaq B, %rsi >>>> leaq A, %r8 >>>> leaq P, %rsi >>>> child process exited abnormally >>>> FAIL: test/CodeGen/X86/stride-nine-with-base-reg.ll >>>> Failed with exit(1) at line 2 >>>> while running: llvm-as < test/CodeGen/X86/stride-nine-with-base- >>>> reg.ll | llc -march=x86-64 | not grep lea >>>> leaq B, %rdx >>>> leaq A, %r8 >>>> leaq P, %rdx >>>> child process exited abnormally >>>> FAIL: test/CodeGen/X86/stride-reuse.ll >>>> Failed with exit(1) at line 2 >>>> while running: llvm-as < test/CodeGen/X86/stride-reuse.ll | llc - >>>> march=x86-64 | not grep lea >>>> leaq B, %rsi >>>> leaq A, %rsi >>>> leaq P, %rsi >>>> child process exited abnormally >>>> _______________________________________________ >>>> 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 clattner at apple.com Tue Feb 12 16:32:35 2008 From: clattner at apple.com (Chris Lattner) Date: Tue, 12 Feb 2008 14:32:35 -0800 Subject: [LLVMdev] tblgen and sign-extended constants too large for type In-Reply-To: References: <47AD1368.1030005@rush.aero.org> Message-ID: <6AEEEF98-E000-4E2E-B02B-674C3414C4CD@apple.com> On Feb 11, 2008, at 11:08 PM, Evan Cheng wrote: > My feeling is tblgen shouldn't make assumptions about whether the > backend will treat the value as signed or unsigned (after all > MVT::ValueType does not convey sign information). Perhaps it's > cleaner to just check if it fits as unsigned? Chris? I don't see why there is an issue. Can't you just write i8 -1 ? -Chris From dalej at apple.com Tue Feb 12 16:35:55 2008 From: dalej at apple.com (Dale Johannesen) Date: Tue, 12 Feb 2008 14:35:55 -0800 Subject: [LLVMdev] an llvm-gcc bug Message-ID: Here's a cute bug in llvm-gcc's struct translation: struct S242 { char * a;int b[1]; } ; struct S93 { __attribute__((aligned (8))) void * a; } ; The second example is padded out to 8 bytes, so both of these look like { i8 *, [1 x i32] } This leads the "struct type factory" StructType::get to think they are the same. But, the second field is marked as Padding in the second case but not the first, and CopyAggregate does not copy Padding. When the second type goes through ConvertType, it is converted to the same llvm Type as the first type, and the StructTypeConversionInfo info is replaced; later copies of the first type then think they don't have to copy the padding, producing wrong code. I'm inclined to remove skipping the Padding in CopyAggregate; that's at best an unimportant optimization, and could result in code that's slower than doing a straightforward rep;movsl or equivalent. Alternatively I can take the Padding bit into account in the StructType::get code somehow. Anyone have a strong opinion? From robert.a.zeh at gmail.com Tue Feb 12 19:08:27 2008 From: robert.a.zeh at gmail.com (Robert Zeh) Date: Tue, 12 Feb 2008 19:08:27 -0600 Subject: [LLVMdev] Instrumenting virtual function calls In-Reply-To: References: <7092525B-2271-4C33-A612-226E076331D7@gmail.com> Message-ID: After hacking away at it for a bit, it looks like the mystery function is actually a stub function. The function pointer is coming from a vtable, which gets filled in with pointers to stub functions. Is there any way to do the round trip for a stub function? Two possible solutions come to mind: 1) Modify getGlobalValueAtAddress to work for pointers to stub functions 2) Add a getStubAtAddress Any other suggestions? Robert On Feb 10, 2008, at 3:41 PM, Chris Lattner wrote: > > On Feb 10, 2008, at 5:33 AM, Robert Zeh wrote: > >> I'm attempting to instrument virtual function calls in my code. >> After each virtual call I'm calling my own registerMethod function, >> with an integer marking the location of the call and a pointer to >> the function that was called. >> >> However, and this is where I get confused, the function pointer >> doesn't match any of the functions in my module. I'd hoped to call >> ExecutionEngine::getGlobalValueAtAddress to get a Function* for the >> virtual function, but ExecutionEngine::getGlobalValueAtAddress >> returns null. >> >> If I look up the virtual function that is getting called (with >> ExeuctionEngine::getPointerToFunction) it doesn't match the >> arguments being passed to my instrumentation. What's a little >> strange is that the pointers are somewhat close: >> getPointerToFunction returns 0x47829a0, but my instrumentation gets >> 0x477fc10. > > This should basically work. You'll have to walk through the various > code that populates the maps. It could be that the start of the > function is actually a constant pool or jump table or something, not > the first instruction of the function. > > -Chris > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From cfr at adobe.com Tue Feb 12 19:26:16 2008 From: cfr at adobe.com (Chuck Rose III) Date: Tue, 12 Feb 2008 17:26:16 -0800 Subject: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build Message-ID: <680422C0AA225644931C2F6DD07200DD01897697@namail5.corp.adobe.com> Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going to call into bar. This has been working for me for a long time on win32 and also under xcode of course. I've included the code that generates the situation at the bottom. Some questions (which may be really brain dead) are: 1. Why isn't the stack getting set up in foo prior to the call down into bar? 2. Why is the call to bar a pointer to a jump. I.e. why didn't it resolve the address in foo? 3. What are some good places for me to be looking to try and drill down further on what's happening? I've tried switching calling conventions and have watched it create machine instructions for adjusting the stack up and down, but they seem to be removed by the time it actually gets down to execution time. Any suggestions would be appreciated. Thanks, Chuck. Call into function (foo) 0000000000980030 mov rax,140001591h 000000000098003A call rax ? this is calling to bar via a jump table 000000000098003C ret Leads to 0000000140001591 jmp bar (1400064E0h) Leads to void bar(int i) { 00000001400064E0 mov dword ptr [rsp+8],ecx 00000001400064E4 push rdi 00000001400064E5 sub rsp,20h 00000001400064E9 mov rdi,rsp 00000001400064EC mov rcx,8 00000001400064F6 mov eax,0CCCCCCCCh 00000001400064FB rep stos dword ptr [rdi] 00000001400064FD mov ecx,dword ptr [rsp+30h] printf("the int is %i\n",i); 0000000140006501 mov edx,dword ptr [i] 0000000140006505 lea rcx,[string "the int is %i\n" (140C1A240h)] 000000014000650C call qword ptr [__imp_printf (141145920h)] } 0000000140006512 add rsp,20h 0000000140006516 pop rdi 0000000140006517 ret At this point, we seem to be jumping back up but the stack is no longer in order, so 000000000098003C ret Takes us into wonderland 0000000100000003 ??? But unfortunately not through the looking glass. Here's the modification of the Fibonacci program which got me the above: #include "llvm/Module.h" #include "llvm/DerivedTypes.h" #include "llvm/Constants.h" #include "llvm/Instructions.h" #include "llvm/ModuleProvider.h" #include "llvm/Analysis/Verifier.h" #include "llvm/ExecutionEngine/JIT.h" #include "llvm/ExecutionEngine/Interpreter.h" #include "llvm/ExecutionEngine/GenericValue.h" #include "llvm/System/DynamicLibrary.h" #include "llvm/CallingConv.h" #include #include using namespace llvm; void bar(int i) { printf("the int is %i\n",i); } Function* createBarFunction(Module* M) { Function* pBarF = cast(M->getOrInsertFunction("bar", Type::VoidTy, Type::Int32Ty, NULL)); return pBarF; } Function* createFooFunction(Module* M) { Function* pBarF = createBarFunction(M), * pFooF; pFooF = cast(M->getOrInsertFunction("foo", Type::VoidTy, Type::Int32Ty, NULL)); BasicBlock* pBody = new BasicBlock("body",pFooF); Argument* pArg = pFooF->arg_begin(); pArg->setName("i"); std::vector barArgs; barArgs.push_back(pArg); new CallInst(pBarF, barArgs.begin(), barArgs.end(), "", pBody); new ReturnInst(NULL, pBody); return pFooF; } int main(int argc, char **argv) { // Create some module to put our function into it. Module *M = new Module("test"); M->setDataLayout("e-p:64:64:64-i1:8:8:8-i8:8:8:8-i32:32:32:32-f32:32:32:32"); Function* pFooF = createFooFunction(M); M->print(std::cout); // Now we going to create JIT ExistingModuleProvider *MP = new ExistingModuleProvider(M); ExecutionEngine *EE = ExecutionEngine::create(MP, false); sys::DynamicLibrary::AddSymbol("bar", (void*) bar); llvm::Module::FunctionListType& funcList = MP->getModule()->getFunctionList(); for (llvm::Module::FunctionListType::iterator i = funcList.begin() ; i != funcList.end() ; ++i) { EE->getPointerToFunction(i); } EE->recompileAndRelinkFunction(pFooF); std::vector Args(1); Args[0].IntVal = APInt(32, 3); GenericValue GV = EE->runFunction(pFooF, Args); return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080212/d247b926/attachment-0001.html From cfr at adobe.com Tue Feb 12 20:20:59 2008 From: cfr at adobe.com (Chuck Rose III) Date: Tue, 12 Feb 2008 18:20:59 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <20080212000436.BBO10317@expms2.cites.uiuc.edu> References: <20080212000436.BBO10317@expms2.cites.uiuc.edu> Message-ID: <680422C0AA225644931C2F6DD07200DD018976BC@namail5.corp.adobe.com> Hola Seung, I don't know if 2.1 in particular worked. I updated the 2.2 win32 vstudio 2k5 files right before lockdown, so they should be building. You will need appropriate versions of flex and bison installed. I used the ones from getgnuwin32 on my machine. Good luck. Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Seung Jae Lee Sent: Monday, February 11, 2008 10:05 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? Hello all, Is there anyone has tried LLVM 2.1 on Visual Studio 2005? I did but not succeed due to some build errors. I seem to remember I read somewhere on this list it's compiled on VS2005 so I wonder... Have a good night. Thx, Seung _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From mrs at apple.com Tue Feb 12 21:11:02 2008 From: mrs at apple.com (Mike Stump) Date: Tue, 12 Feb 2008 19:11:02 -0800 Subject: [LLVMdev] Instrumenting virtual function calls In-Reply-To: References: <7092525B-2271-4C33-A612-226E076331D7@gmail.com> Message-ID: <35667D52-18C2-45BC-81A3-C07C24DDF067@apple.com> On Feb 12, 2008, at 5:08 PM, Robert Zeh wrote: > After hacking away at it for a bit, it looks like the mystery > function is actually a stub function. You know, I had this lengthy email written to cover all the details and I decided not to send it as I wasn't sure if that was what you were hitting a stub and I didn't want to confuse the issue if it wasn't due to stubs... :-( Oh well... > Is there any way to do the round trip for a stub function? Not that I know of. I think you're down to template checking (check the whole thing for strict equality please). > Two possible solutions come to mind: > 1) Modify getGlobalValueAtAddress to work for pointers to stub > functions I think I like this better. I think others might want to, need to do this same thing and I suspect they don't want to learn and they'll appreciate it just working. > 2) Add a getStubAtAddress From scottm at rushg.aero.org Tue Feb 12 21:21:13 2008 From: scottm at rushg.aero.org (Scott Michel) Date: Tue, 12 Feb 2008 19:21:13 -0800 Subject: [LLVMdev] OT: Organizing a Supercomputing '08 workshop Message-ID: <47B26229.9090102@rush.aero.org> All: Sorry if this is a bit off-topic, but... having two successful workshops at Supercomputing, I'm contemplating a third (I'm a glutton for punishment.) This year, the focus will be on many/multicore's programmability gap -- the gap between today's languages and the multicore/manycore architectures that we're trying to program. A stellar example is software development on the IBM Cell BE and its SPUs in C/C++. The workshop will focus on languages, compilers and runtimes that are targeted for many/multicore architecutes and platforms. If you know of any good speakers with topics in the workshop's area, please feel free to contact me. -scooter From sabre at nondot.org Tue Feb 12 22:45:13 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 12 Feb 2008 20:45:13 -0800 Subject: [LLVMdev] Instrumenting virtual function calls In-Reply-To: References: <7092525B-2271-4C33-A612-226E076331D7@gmail.com> Message-ID: <2EFD1412-81B9-42A7-B44F-F9F72A0157D4@nondot.org> On Feb 12, 2008, at 5:08 PM, Robert Zeh wrote: > After hacking away at it for a bit, it looks like the mystery function > is actually a stub function. The function pointer is coming from a > vtable, which gets filled in with pointers to stub functions. > > Is there any way to do the round trip for a stub function? Two > possible solutions come to mind: > 1) Modify getGlobalValueAtAddress to work for pointers to stub > functions > 2) Add a getStubAtAddress > > Any other suggestions? Do you care about JIT laziness? You could just call getPointerToFunction on every function in the module before your code starts up. -Chris From ted at tedneward.com Tue Feb 12 23:11:04 2008 From: ted at tedneward.com (Ted Neward) Date: Tue, 12 Feb 2008 21:11:04 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <680422C0AA225644931C2F6DD07200DD018976BC@namail5.corp.adobe.com> References: <20080212000436.BBO10317@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD018976BC@namail5.corp.adobe.com> Message-ID: <02fc01c86dfe$d9accb40$8d0661c0$@com> I'm sorry, what is getgnuwin32? Is this just a cygwin shortcut tool? If I have most of the cygwin dev packages downloaded already, do I still need getgnuwin32? Where do I find getgnuwin32, in any event? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Chuck Rose III > Sent: Tuesday, February 12, 2008 6:21 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > Hola Seung, > > I don't know if 2.1 in particular worked. I updated the 2.2 win32 > vstudio 2k5 files right before lockdown, so they should be building. > You will need appropriate versions of flex and bison installed. I used > the ones from getgnuwin32 on my machine. > > Good luck. > > Chuck. > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Seung Jae Lee > Sent: Monday, February 11, 2008 10:05 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > Hello all, > > Is there anyone has tried LLVM 2.1 on Visual Studio 2005? > I did but not succeed due to some build errors. > I seem to remember I read somewhere on this list it's compiled on > VS2005 > so I wonder... > Have a good night. > > Thx, > Seung > _______________________________________________ > 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 > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: > 2/11/2008 8:16 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 8:16 AM From lee225 at uiuc.edu Tue Feb 12 23:19:42 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Tue, 12 Feb 2008 23:19:42 -0600 (CST) Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? Message-ID: <20080212231942.BBP55342@expms2.cites.uiuc.edu> I simply found it at: http://getgnuwin32.sourceforge.net/ Seung ---- Original message ---- >Date: Tue, 12 Feb 2008 21:11:04 -0800 >From: "Ted Neward" >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? >To: "'LLVM Developers Mailing List'" > >I'm sorry, what is getgnuwin32? Is this just a cygwin shortcut tool? > >If I have most of the cygwin dev packages downloaded already, do I still >need getgnuwin32? > >Where do I find getgnuwin32, in any event? > >Ted Neward >Java, .NET, XML Services >Consulting, Teaching, Speaking, Writing >http://www.tedneward.com > > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Chuck Rose III >> Sent: Tuesday, February 12, 2008 6:21 PM >> To: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> 2005? >> >> Hola Seung, >> >> I don't know if 2.1 in particular worked. I updated the 2.2 win32 >> vstudio 2k5 files right before lockdown, so they should be building. >> You will need appropriate versions of flex and bison installed. I used >> the ones from getgnuwin32 on my machine. >> >> Good luck. >> >> Chuck. >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Seung Jae Lee >> Sent: Monday, February 11, 2008 10:05 PM >> To: llvmdev at cs.uiuc.edu >> Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> 2005? >> >> Hello all, >> >> Is there anyone has tried LLVM 2.1 on Visual Studio 2005? >> I did but not succeed due to some build errors. >> I seem to remember I read somewhere on this list it's compiled on >> VS2005 >> so I wonder... >> Have a good night. >> >> Thx, >> Seung >> _______________________________________________ >> 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 >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: >> 2/11/2008 8:16 AM >> > >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 >8:16 AM > > >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From lee225 at uiuc.edu Tue Feb 12 23:52:00 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Tue, 12 Feb 2008 23:52:00 -0600 (CST) Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? Message-ID: <20080212235200.BBP58517@expms2.cites.uiuc.edu> Thanks for your comment. I also tried for LLVM 2.2 but got the same compilation errors on VS2005. (I didn't modify anything before the compilation) I just wonder if I need bison and flex even just in the case of compiling them on VS2005 without changing anything because the LLVM doc says "If you plan to modify any .y or .l files, you will need to have bison and/or flex installed where Visual Studio can find them. Otherwise, you do not need them and the pre-generated files that come with the source tree will be used." One of errors of mine is as follows: ------------------------------------------------------- ... 7>llvmAsmParser.cpp 7>c1xx : fatal error C1083: Cannot open source file: '.\llvmAsmParser.cpp': No such file or directory ... ------------------------------------------------------- where llvmAsmParser.cpp is related to Bison so I am compelled to feel to try installing flex/bison on my machine, anyway. Forgive my ignorance, could you briefly tell me about that? Thank you in advance. Seung ---- Original message ---- >Date: Tue, 12 Feb 2008 18:20:59 -0800 >From: "Chuck Rose III" >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? >To: "LLVM Developers Mailing List" > >Hola Seung, > >I don't know if 2.1 in particular worked. I updated the 2.2 win32 >vstudio 2k5 files right before lockdown, so they should be building. >You will need appropriate versions of flex and bison installed. I used >the ones from getgnuwin32 on my machine. > >Good luck. > >Chuck. > >-----Original Message----- >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >On Behalf Of Seung Jae Lee >Sent: Monday, February 11, 2008 10:05 PM >To: llvmdev at cs.uiuc.edu >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >2005? > >Hello all, > >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? >I did but not succeed due to some build errors. >I seem to remember I read somewhere on this list it's compiled on VS2005 >so I wonder... >Have a good night. > >Thx, >Seung >_______________________________________________ >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 Wed Feb 13 01:35:19 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 13 Feb 2008 08:35:19 +0100 Subject: [LLVMdev] an llvm-gcc bug In-Reply-To: References: Message-ID: <200802130835.20332.baldrick@free.fr> Hi Dale, > Here's a cute bug in llvm-gcc's struct translation: > > struct S242 { char * a;int b[1]; } ; > struct S93 { __attribute__((aligned (8))) void * a; } ; > > The second example is padded out to 8 bytes, so both of these look like > { i8 *, [1 x i32] } > This leads the "struct type factory" StructType::get to think they are > the same. > But, the second field is marked as Padding in the second case but not > the first, > and CopyAggregate does not copy Padding. When the second type > goes through ConvertType, it is converted to the same llvm Type as the > first type, > and the StructTypeConversionInfo info is replaced; later copies of the > first type > then think they don't have to copy the padding, producing wrong code. there's some mucking around with padding in ConvertUNION presumably because someone noticed a problem of this kind there. > I'm inclined to remove skipping the Padding in CopyAggregate; that's > at best an unimportant optimization, and could result in code that's > slower than doing a straightforward rep;movsl or equivalent. The padding info is used when doing an element by element copy instead of a memcpy (done for small objects in the hope of being faster). > Alternatively I can take the Padding bit into account in the > StructType::get code somehow. Anyone have a strong opinion? Shouldn't it be a map from the gcc type to the padding info? That said, you can get rid of the padding info as far as I'm concerned. However Chris might have a different opinion - I think he introduced it. Ciao, Duncan. From hehaifeng2nd at gmail.com Wed Feb 13 03:10:16 2008 From: hehaifeng2nd at gmail.com (Haifeng He) Date: Wed, 13 Feb 2008 02:10:16 -0700 Subject: [LLVMdev] Problem of ELF section attribute Message-ID: Hi, I am having problem of using LLVM on a program which contains customized code section. In addition to ".text" section for keeping code, the program has another code section, called ".init.text". The functions in this section are defined as "int foo (int, int) __attribute__ ((section (".init.text")));" If I compile the program with gcc, this section(".init.text") will have attributes of "AX" (means allocate space and executable). However, if I first compile the program into llvm IR, then convert IR to native assembly code using llc, this section will not have "AX" attribute. This causes the native executable fails when it tries to call a function in .init.text section. Any suggestion? (btw, my platform is Linux running on x86 machine.) Thank you Haifeng From ted at tedneward.com Wed Feb 13 05:16:31 2008 From: ted at tedneward.com (Ted Neward) Date: Wed, 13 Feb 2008 03:16:31 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <20080212231942.BBP55342@expms2.cites.uiuc.edu> References: <20080212231942.BBP55342@expms2.cites.uiuc.edu> Message-ID: <004b01c86e31$e51942f0$af4bc8d0$@com> Thanks--I was offline when I wrote it, couldn't Google. Found it in about 5 seconds once I was back online. Second question: I'm getting various build errors relating (it seems) to configuration: can't find windows.h and so forth. Where (or to whom) is the best place to report these and iterate until we fix them? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Seung Jae Lee > Sent: Tuesday, February 12, 2008 9:20 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > I simply found it at: > > http://getgnuwin32.sourceforge.net/ > > Seung > > ---- Original message ---- > >Date: Tue, 12 Feb 2008 21:11:04 -0800 > >From: "Ted Neward" > >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio 2005? > >To: "'LLVM Developers Mailing List'" > > > >I'm sorry, what is getgnuwin32? Is this just a cygwin shortcut tool? > > > >If I have most of the cygwin dev packages downloaded already, do I > still > >need getgnuwin32? > > > >Where do I find getgnuwin32, in any event? > > > >Ted Neward > >Java, .NET, XML Services > >Consulting, Teaching, Speaking, Writing > >http://www.tedneward.com > > > > > >> -----Original Message----- > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > >> On Behalf Of Chuck Rose III > >> Sent: Tuesday, February 12, 2008 6:21 PM > >> To: LLVM Developers Mailing List > >> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > >> 2005? > >> > >> Hola Seung, > >> > >> I don't know if 2.1 in particular worked. I updated the 2.2 win32 > >> vstudio 2k5 files right before lockdown, so they should be building. > >> You will need appropriate versions of flex and bison installed. I > used > >> the ones from getgnuwin32 on my machine. > >> > >> Good luck. > >> > >> Chuck. > >> > >> -----Original Message----- > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > >> On Behalf Of Seung Jae Lee > >> Sent: Monday, February 11, 2008 10:05 PM > >> To: llvmdev at cs.uiuc.edu > >> Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > >> 2005? > >> > >> Hello all, > >> > >> Is there anyone has tried LLVM 2.1 on Visual Studio 2005? > >> I did but not succeed due to some build errors. > >> I seem to remember I read somewhere on this list it's compiled on > >> VS2005 > >> so I wonder... > >> Have a good night. > >> > >> Thx, > >> Seung > >> _______________________________________________ > >> 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 > >> > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: > >> 2/11/2008 8:16 AM > >> > > > >No virus found in this outgoing message. > >Checked by AVG Free Edition. > >Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: > 2/11/2008 > >8:16 AM > > > > > >_______________________________________________ > >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 > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: > 2/11/2008 8:16 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 8:16 AM From llvmdev at gmail.com Wed Feb 13 06:19:26 2008 From: llvmdev at gmail.com (Sanjiv Gupta) Date: Wed, 13 Feb 2008 17:49:26 +0530 Subject: [LLVMdev] 2.2 build failure In-Reply-To: References: <56aaf0ef0802120400g3c10fd58lcaf1fff1e29a0474@mail.gmail.com> Message-ID: <56aaf0ef0802130419g53789537h17043610f5046d98@mail.gmail.com> On 2/12/08, Chris Lattner wrote: > > On Tue, 12 Feb 2008, Sanjiv Gupta wrote: > > I am using gcc 3.2.3 on RHEL 3 to build llvm 2.2. > > Below are the build errors: > > > > /home/i00171/Work/llvm-work/src/llvm-2.2 > /include/llvm/Analysis/DominatorInternals.h:147: > > no > > type named `NodeType' in `class llvm::BasicBlock' > > /home/i00171/Work/llvm-work/src/llvm-2.2 > /include/llvm/Analysis/DominatorInternals.h:150: > > ` > > VInfo' undeclared (first use this function) > > /home/i00171/Work/llvm-work/src/llvm-2.2 > /include/llvm/Analysis/DominatorInternals.h:152: > > no > > matching function for call to `Compress( > > llvm::DominatorTreeBase&, llvm::BasicBlock*&)' > > That is a very strange error: I think the code is fine, but your GCC is > confused. I notice that GCC 3.2.2 is listed as a "known bad" version of > GCC. It could be that 3.2.3 is also broken as well. Is there any local > source change you can make to that file that gets it working? If not, I'd > suggest upgrading to a newer GCC. Sorry :( > > -Chris I did build GCC 4.2 and used that to build LLVM 2.2. It builds fine now. Thanks, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080213/d99f7db0/attachment.html From tewk at cs.utah.edu Wed Feb 13 07:52:07 2008 From: tewk at cs.utah.edu (Kevin Tew) Date: Wed, 13 Feb 2008 06:52:07 -0700 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <004b01c86e31$e51942f0$af4bc8d0$@com> References: <20080212231942.BBP55342@expms2.cites.uiuc.edu> <004b01c86e31$e51942f0$af4bc8d0$@com> Message-ID: <47B2F607.8010506@cs.utah.edu> If you are using the Express versions of Visual Studio, the Platform SDK(windows.h) is a seperate install that you have to download. Kevin Tew Ted Neward wrote: > Thanks--I was offline when I wrote it, couldn't Google. Found it in about 5 > seconds once I was back online. > > Second question: I'm getting various build errors relating (it seems) to > configuration: can't find windows.h and so forth. Where (or to whom) is the > best place to report these and iterate until we fix them? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Seung Jae Lee >> Sent: Tuesday, February 12, 2008 9:20 PM >> To: llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> 2005? >> >> I simply found it at: >> >> http://getgnuwin32.sourceforge.net/ >> >> Seung >> >> ---- Original message ---- >> >>> Date: Tue, 12 Feb 2008 21:11:04 -0800 >>> From: "Ted Neward" >>> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual >>> >> Studio 2005? >> >>> To: "'LLVM Developers Mailing List'" >>> >>> I'm sorry, what is getgnuwin32? Is this just a cygwin shortcut tool? >>> >>> If I have most of the cygwin dev packages downloaded already, do I >>> >> still >> >>> need getgnuwin32? >>> >>> Where do I find getgnuwin32, in any event? >>> >>> Ted Neward >>> Java, .NET, XML Services >>> Consulting, Teaching, Speaking, Writing >>> http://www.tedneward.com >>> >>> >>> >>>> -----Original Message----- >>>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >>>> >> bounces at cs.uiuc.edu] >> >>>> On Behalf Of Chuck Rose III >>>> Sent: Tuesday, February 12, 2008 6:21 PM >>>> To: LLVM Developers Mailing List >>>> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual >>>> >> Studio >> >>>> 2005? >>>> >>>> Hola Seung, >>>> >>>> I don't know if 2.1 in particular worked. I updated the 2.2 win32 >>>> vstudio 2k5 files right before lockdown, so they should be building. >>>> You will need appropriate versions of flex and bison installed. I >>>> >> used >> >>>> the ones from getgnuwin32 on my machine. >>>> >>>> Good luck. >>>> >>>> Chuck. >>>> >>>> -----Original Message----- >>>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >>>> >> bounces at cs.uiuc.edu] >> >>>> On Behalf Of Seung Jae Lee >>>> Sent: Monday, February 11, 2008 10:05 PM >>>> To: llvmdev at cs.uiuc.edu >>>> Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >>>> 2005? >>>> >>>> Hello all, >>>> >>>> Is there anyone has tried LLVM 2.1 on Visual Studio 2005? >>>> I did but not succeed due to some build errors. >>>> I seem to remember I read somewhere on this list it's compiled on >>>> VS2005 >>>> so I wonder... >>>> Have a good night. >>>> >>>> Thx, >>>> Seung >>>> _______________________________________________ >>>> 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 >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: >>>> 2/11/2008 8:16 AM >>>> >>>> >>> No virus found in this outgoing message. >>> Checked by AVG Free Edition. >>> Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: >>> >> 2/11/2008 >> >>> 8:16 AM >>> >>> >>> _______________________________________________ >>> 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 >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: >> 2/11/2008 8:16 AM >> >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 > 8:16 AM > > > _______________________________________________ > 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/20080213/5031f3b6/attachment-0001.html From cfr at adobe.com Wed Feb 13 10:52:12 2008 From: cfr at adobe.com (Chuck Rose III) Date: Wed, 13 Feb 2008 08:52:12 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <20080212235200.BBP58517@expms2.cites.uiuc.edu> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> Message-ID: <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com> I have always built it with flex and bison installed, though I believe Chris removed our last dependence on flex a little while back, so you may not need that. I'm using bison 2.1 which I got from the getgnuwin32 folks. I imagine that if you have cygwin or the like, you probably already have everything. You will need to have the executables in your path. I build with VisualStudio 2k5 Professional with VStudio SP1 installed. I typically work on Vista32 or Vista64, but have compiled on XP as well. I don't know how up to date the LLVM docs related to Visual Studio compilation are. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Seung Jae Lee Sent: Tuesday, February 12, 2008 9:52 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? Thanks for your comment. I also tried for LLVM 2.2 but got the same compilation errors on VS2005. (I didn't modify anything before the compilation) I just wonder if I need bison and flex even just in the case of compiling them on VS2005 without changing anything because the LLVM doc says "If you plan to modify any .y or .l files, you will need to have bison and/or flex installed where Visual Studio can find them. Otherwise, you do not need them and the pre-generated files that come with the source tree will be used." One of errors of mine is as follows: ------------------------------------------------------- ... 7>llvmAsmParser.cpp 7>c1xx : fatal error C1083: Cannot open source file: '.\llvmAsmParser.cpp': No such file or directory ... ------------------------------------------------------- where llvmAsmParser.cpp is related to Bison so I am compelled to feel to try installing flex/bison on my machine, anyway. Forgive my ignorance, could you briefly tell me about that? Thank you in advance. Seung ---- Original message ---- >Date: Tue, 12 Feb 2008 18:20:59 -0800 >From: "Chuck Rose III" >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? >To: "LLVM Developers Mailing List" > >Hola Seung, > >I don't know if 2.1 in particular worked. I updated the 2.2 win32 >vstudio 2k5 files right before lockdown, so they should be building. >You will need appropriate versions of flex and bison installed. I used >the ones from getgnuwin32 on my machine. > >Good luck. > >Chuck. > >-----Original Message----- >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >On Behalf Of Seung Jae Lee >Sent: Monday, February 11, 2008 10:05 PM >To: llvmdev at cs.uiuc.edu >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >2005? > >Hello all, > >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? >I did but not succeed due to some build errors. >I seem to remember I read somewhere on this list it's compiled on VS2005 >so I wonder... >Have a good night. > >Thx, >Seung >_______________________________________________ >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 sabre at nondot.org Wed Feb 13 11:44:47 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 13 Feb 2008 09:44:47 -0800 (PST) Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com> Message-ID: On Wed, 13 Feb 2008, Chuck Rose III wrote: > I have always built it with flex and bison installed, though I believe > Chris removed our last dependence on flex a little while back, so you > may not need that. I'm using bison 2.1 which I got from the getgnuwin32 I think that llvmc and llvm-upgrade still use flex. Neither of those are really interesting on windows and both are slated to be removed for 2.3. It would be nice to get help upgrading all the .ll files in llvm/test. Once that happens, we can nuke llvm-upgrade from mainline. -Chris > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Seung Jae Lee > Sent: Tuesday, February 12, 2008 9:52 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > Thanks for your comment. > I also tried for LLVM 2.2 but got the same compilation errors on VS2005. > (I didn't modify anything before the compilation) > > I just wonder if I need bison and flex even just in the case of > compiling them on VS2005 without changing anything because the LLVM doc > says "If you plan to modify any .y or .l files, you will need to have > bison and/or flex installed where Visual Studio can find them. > Otherwise, you do not need them and the pre-generated files that come > with the source tree will be used." > > One of errors of mine is as follows: > ------------------------------------------------------- > ... > 7>llvmAsmParser.cpp > 7>c1xx : fatal error C1083: Cannot open source file: > '.\llvmAsmParser.cpp': No such file or directory > ... > ------------------------------------------------------- > where llvmAsmParser.cpp is related to Bison so I am compelled to feel to > try installing flex/bison on my machine, anyway. > > Forgive my ignorance, could you briefly tell me about that? > Thank you in advance. > > Seung > > ---- Original message ---- >> Date: Tue, 12 Feb 2008 18:20:59 -0800 >> From: "Chuck Rose III" >> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? >> To: "LLVM Developers Mailing List" >> >> Hola Seung, >> >> I don't know if 2.1 in particular worked. I updated the 2.2 win32 >> vstudio 2k5 files right before lockdown, so they should be building. >> You will need appropriate versions of flex and bison installed. I used >> the ones from getgnuwin32 on my machine. >> >> Good luck. >> >> Chuck. >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Seung Jae Lee >> Sent: Monday, February 11, 2008 10:05 PM >> To: llvmdev at cs.uiuc.edu >> Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> 2005? >> >> Hello all, >> >> Is there anyone has tried LLVM 2.1 on Visual Studio 2005? >> I did but not succeed due to some build errors. >> I seem to remember I read somewhere on this list it's compiled on > VS2005 >> so I wonder... >> Have a good night. >> >> Thx, >> Seung >> _______________________________________________ >> 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 > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Wed Feb 13 11:52:38 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 13 Feb 2008 09:52:38 -0800 (PST) Subject: [LLVMdev] 2.2 build failure In-Reply-To: <56aaf0ef0802130419g53789537h17043610f5046d98@mail.gmail.com> References: <56aaf0ef0802120400g3c10fd58lcaf1fff1e29a0474@mail.gmail.com> <56aaf0ef0802130419g53789537h17043610f5046d98@mail.gmail.com> Message-ID: On Wed, 13 Feb 2008, Sanjiv Gupta wrote: > I did build GCC 4.2 and used that to build LLVM 2.2. It builds fine now. Sounds good, I added 3.2.3 to the list of broken gcc's. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From evan.cheng at apple.com Wed Feb 13 12:50:52 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 13 Feb 2008 10:50:52 -0800 Subject: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build In-Reply-To: <680422C0AA225644931C2F6DD07200DD01897697@namail5.corp.adobe.com> References: <680422C0AA225644931C2F6DD07200DD01897697@namail5.corp.adobe.com> Message-ID: <30BDCC2B-91CC-406E-9CD2-3FFFCA6B66B2@apple.com> Hi Chuck, It's hard to tell what's wrong without having a way to reproduce it since it's on Windows. Can you dump out IR's at various places to help debugging this? You can start by dumping out machine instructions and then go back backwards if necessary. Evan On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I?m debugging through some strangeness that I?m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I?ve otherwise > left LLVM 2.2 alone. The basic idea is that I?ve got a function bar > which is compiled by VStudio and I?m creating another function foo > via LLVM JIT which is going to call into bar. This has been working > for me for a long time on win32 and also under xcode of course. > I?ve included the code that generates the situation at the bottom. > Some questions (which may be really brain dead) are: > > 1. Why isn?t the stack getting set up in foo prior to the call > down into bar? > 2. Why is the call to bar a pointer to a jump. I.e. why > didn?t it resolve the address in foo? > 3. What are some good places for me to be looking to try and > drill down further on what?s happening? I?ve tried switching > calling conventions and have watched it create machine instructions > for adjusting the stack up and down, but they seem to be removed by > the time it actually gets down to execution time. > > Any suggestions would be appreciated. > > Thanks, > Chuck. > > Call into function (foo) > 0000000000980030 mov rax,140001591h > 000000000098003A call rax ? this is > calling to bar via a jump table > 000000000098003C ret > > Leads to > 0000000140001591 jmp bar (1400064E0h) > > Leads to > void bar(int i) > { > 00000001400064E0 mov dword ptr [rsp+8],ecx > 00000001400064E4 push rdi > 00000001400064E5 sub rsp,20h > 00000001400064E9 mov rdi,rsp > 00000001400064EC mov rcx,8 > 00000001400064F6 mov eax,0CCCCCCCCh > 00000001400064FB rep stos dword ptr [rdi] > 00000001400064FD mov ecx,dword ptr [rsp+30h] > printf("the int is %i\n",i); > 0000000140006501 mov edx,dword ptr [i] > 0000000140006505 lea rcx,[string "the int is %i > \n" (140C1A240h)] > 000000014000650C call qword ptr [__imp_printf (141145920h)] > } > 0000000140006512 add rsp,20h > 0000000140006516 pop rdi > 0000000140006517 ret > > At this point, we seem to be jumping back up but the stack is no > longer in order, so > 000000000098003C ret > > Takes us into wonderland > 0000000100000003 ??? > > But unfortunately not through the looking glass. > > Here?s the modification of the Fibonacci program which got me the > above: > #include "llvm/Module.h" > #include "llvm/DerivedTypes.h" > #include "llvm/Constants.h" > #include "llvm/Instructions.h" > #include "llvm/ModuleProvider.h" > #include "llvm/Analysis/Verifier.h" > #include "llvm/ExecutionEngine/JIT.h" > #include "llvm/ExecutionEngine/Interpreter.h" > #include "llvm/ExecutionEngine/GenericValue.h" > #include "llvm/System/DynamicLibrary.h" > #include "llvm/CallingConv.h" > #include > #include > using namespace llvm; > > void bar(int i) > { > printf("the int is %i\n",i); > } > > Function* createBarFunction(Module* M) > { > Function* pBarF = cast(M->getOrInsertFunction("bar", > Type::VoidTy, Type::Int32Ty, NULL)); > return pBarF; > } > > Function* createFooFunction(Module* M) > { > Function* pBarF = createBarFunction(M), > * pFooF; > > pFooF = cast(M->getOrInsertFunction("foo", > Type::VoidTy, Type::Int32Ty, NULL)); > BasicBlock* pBody = new BasicBlock("body",pFooF); > Argument* pArg = pFooF->arg_begin(); > pArg->setName("i"); > std::vector barArgs; > barArgs.push_back(pArg); > new CallInst(pBarF, barArgs.begin(), barArgs.end(), "", pBody); > new ReturnInst(NULL, pBody); > return pFooF; > } > > int main(int argc, char **argv) { > // Create some module to put our function into it. > Module *M = new Module("test"); > > M->setDataLayout("e-p:64:64:64-i1:8:8:8-i8:8:8:8-i32:32:32:32- > f32:32:32:32"); > Function* pFooF = createFooFunction(M); > M->print(std::cout); > > // Now we going to create JIT > ExistingModuleProvider *MP = new ExistingModuleProvider(M); > ExecutionEngine *EE = ExecutionEngine::create(MP, false); > > sys::DynamicLibrary::AddSymbol("bar", (void*) bar); > llvm::Module::FunctionListType& funcList = MP->getModule()- > >getFunctionList(); > > for (llvm::Module::FunctionListType::iterator i = > funcList.begin() ; i != funcList.end() ; ++i) > { > EE->getPointerToFunction(i); > } > > EE->recompileAndRelinkFunction(pFooF); > > std::vector Args(1); > Args[0].IntVal = APInt(32, 3); > GenericValue GV = EE->runFunction(pFooF, Args); > > return 0; > } > > _______________________________________________ > 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/20080213/cc3d9752/attachment-0001.html From evan.cheng at apple.com Wed Feb 13 13:08:03 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 13 Feb 2008 11:08:03 -0800 Subject: [LLVMdev] Problem of ELF section attribute In-Reply-To: References: Message-ID: Please file a bug. We'll move the discussion there. Thanks, Evan On Feb 13, 2008, at 1:10 AM, Haifeng He wrote: > Hi, > > I am having problem of using LLVM on a program which contains > customized code section. > In addition to ".text" section for keeping code, the program has > another code section, called ".init.text". > The functions in this section are defined as > "int foo (int, int) __attribute__ ((section (".init.text")));" > > If I compile the program with gcc, this section(".init.text") will > have attributes of "AX" (means allocate space and > executable). However, if I first compile the program into llvm IR, > then convert IR to native assembly code using > llc, this section will not have "AX" attribute. This causes the native > executable fails when it tries to call a function > in .init.text section. Any suggestion? (btw, my platform is Linux > running on x86 machine.) > > Thank you > > Haifeng > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ted at tedneward.com Wed Feb 13 13:37:16 2008 From: ted at tedneward.com (Ted Neward) Date: Wed, 13 Feb 2008 11:37:16 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <47B2F607.8010506@cs.utah.edu> References: <20080212231942.BBP55342@expms2.cites.uiuc.edu> <004b01c86e31$e51942f0$af4bc8d0$@com> <47B2F607.8010506@cs.utah.edu> Message-ID: <012801c86e77$dc877e90$95967bb0$@com> True, though I have VS 2005 Pro installed, and the Platform SDK is installed as part of it?I can compile the Platform SDK examples and Petzold code just fine. Good thought, though. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com From: Kevin Tew [mailto:tewk at cs.utah.edu] Sent: Wednesday, February 13, 2008 5:52 AM To: LLVM Developers Mailing List Cc: ted at tedneward.com Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? If you are using the Express versions of Visual Studio, the Platform SDK(windows.h) is a seperate install that you have to download. Kevin Tew Ted Neward wrote: Thanks--I was offline when I wrote it, couldn't Google. Found it in about 5 seconds once I was back online. Second question: I'm getting various build errors relating (it seems) to configuration: can't find windows.h and so forth. Where (or to whom) is the best place to report these and iterate until we fix them? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com -----Original Message----- From: HYPERLINK "mailto:llvmdev-bounces at cs.uiuc.edu"llvmdev-bounces at cs.uiuc.edu [HYPERLINK "mailto:llvmdev-bounces at cs.uiuc.edu"mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Seung Jae Lee Sent: Tuesday, February 12, 2008 9:20 PM To: HYPERLINK "mailto:llvmdev at cs.uiuc.edu"llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? I simply found it at: HYPERLINK "http://getgnuwin32.sourceforge.net/"http://getgnuwin32.sourceforge.net/ Seung ---- Original message ---- Date: Tue, 12 Feb 2008 21:11:04 -0800 From: "Ted Neward" HYPERLINK "mailto:ted at tedneward.com" Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? To: "'LLVM Developers Mailing List'" HYPERLINK "mailto:llvmdev at cs.uiuc.edu" I'm sorry, what is getgnuwin32? Is this just a cygwin shortcut tool? If I have most of the cygwin dev packages downloaded already, do I still need getgnuwin32? Where do I find getgnuwin32, in any event? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com -----Original Message----- From: HYPERLINK "mailto:llvmdev-bounces at cs.uiuc.edu"llvmdev-bounces at cs.uiuc.edu [HYPERLINK "mailto:llvmdev"mailto:llvmdev- HYPERLINK "mailto:bounces at cs.uiuc.edu"bounces at cs.uiuc.edu] On Behalf Of Chuck Rose III Sent: Tuesday, February 12, 2008 6:21 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? Hola Seung, I don't know if 2.1 in particular worked. I updated the 2.2 win32 vstudio 2k5 files right before lockdown, so they should be building. You will need appropriate versions of flex and bison installed. I used the ones from getgnuwin32 on my machine. Good luck. Chuck. -----Original Message----- From: HYPERLINK "mailto:llvmdev-bounces at cs.uiuc.edu"llvmdev-bounces at cs.uiuc.edu [HYPERLINK "mailto:llvmdev"mailto:llvmdev- HYPERLINK "mailto:bounces at cs.uiuc.edu"bounces at cs.uiuc.edu] On Behalf Of Seung Jae Lee Sent: Monday, February 11, 2008 10:05 PM To: HYPERLINK "mailto:llvmdev at cs.uiuc.edu"llvmdev at cs.uiuc.edu Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? Hello all, Is there anyone has tried LLVM 2.1 on Visual Studio 2005? I did but not succeed due to some build errors. I seem to remember I read somewhere on this list it's compiled on VS2005 so I wonder... Have a good night. Thx, Seung _______________________________________________ LLVM Developers mailing list HYPERLINK "mailto:LLVMdev at cs.uiuc.edu"LLVMdev at cs.uiuc.edu HYPERLINK "http://llvm.cs.uiuc.edu"http://llvm.cs.uiuc.edu HYPERLINK "http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"http://lists.cs.uiuc.edu/ mailman/listinfo/llvmdev _______________________________________________ LLVM Developers mailing list HYPERLINK "mailto:LLVMdev at cs.uiuc.edu"LLVMdev at cs.uiuc.edu HYPERLINK "http://llvm.cs.uiuc.edu"http://llvm.cs.uiuc.edu HYPERLINK "http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"http://lists.cs.uiuc.edu/ mailman/listinfo/llvmdev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 8:16 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 8:16 AM _______________________________________________ LLVM Developers mailing list HYPERLINK "mailto:LLVMdev at cs.uiuc.edu"LLVMdev at cs.uiuc.edu HYPERLINK "http://llvm.cs.uiuc.edu"http://llvm.cs.uiuc.edu HYPERLINK "http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"http://lists.cs.uiuc.edu/ mailman/listinfo/llvmdev _______________________________________________ LLVM Developers mailing list HYPERLINK "mailto:LLVMdev at cs.uiuc.edu"LLVMdev at cs.uiuc.edu HYPERLINK "http://llvm.cs.uiuc.edu"http://llvm.cs.uiuc.edu HYPERLINK "http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"http://lists.cs.uiuc.edu/ mailman/listinfo/llvmdev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 8:16 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 8:16 AM _______________________________________________ LLVM Developers mailing list HYPERLINK "mailto:LLVMdev at cs.uiuc.edu"LLVMdev at cs.uiuc.edu HYPERLINK "http://llvm.cs.uiuc.edu"http://llvm.cs.uiuc.edu HYPERLINK "http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"http://lists.cs.uiuc.edu/ mailman/listinfo/llvmdev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 8:16 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: 2/13/2008 9:41 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080213/6f10cae2/attachment.html From ted at tedneward.com Wed Feb 13 15:45:45 2008 From: ted at tedneward.com (Ted Neward) Date: Wed, 13 Feb 2008 13:45:45 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com> Message-ID: <017f01c86e89$cbe88f90$63b9aeb0$@com> I have flex and bison from Cygwin installed: $ flex --version flex version 2.5.4 $ bison --version bison (GNU Bison) 2.3 Written by Robert Corbett and Richard Stallman. Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Should that work, assuming they're on the PATH? When I ran the build from inside VS, I get some build failures, but nothing that implies that it was looking for flex/bison to execute directly--are you supposed to run these prior to launching the build? The docs on "Getting Started with Visual Studio" seem a tad bit out of date, but I'm certainly not enough beyond n00b status to know for sure. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Chuck Rose III > Sent: Wednesday, February 13, 2008 8:52 AM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > I have always built it with flex and bison installed, though I believe > Chris removed our last dependence on flex a little while back, so you > may not need that. I'm using bison 2.1 which I got from the > getgnuwin32 > folks. I imagine that if you have cygwin or the like, you probably > already have everything. > > You will need to have the executables in your path. > > I build with VisualStudio 2k5 Professional with VStudio SP1 installed. > I typically work on Vista32 or Vista64, but have compiled on XP as > well. > > > I don't know how up to date the LLVM docs related to Visual Studio > compilation are. > > Thanks, > Chuck. > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Seung Jae Lee > Sent: Tuesday, February 12, 2008 9:52 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > Thanks for your comment. > I also tried for LLVM 2.2 but got the same compilation errors on > VS2005. > (I didn't modify anything before the compilation) > > I just wonder if I need bison and flex even just in the case of > compiling them on VS2005 without changing anything because the LLVM doc > says "If you plan to modify any .y or .l files, you will need to have > bison and/or flex installed where Visual Studio can find them. > Otherwise, you do not need them and the pre-generated files that come > with the source tree will be used." > > One of errors of mine is as follows: > ------------------------------------------------------- > ... > 7>llvmAsmParser.cpp > 7>c1xx : fatal error C1083: Cannot open source file: > '.\llvmAsmParser.cpp': No such file or directory > ... > ------------------------------------------------------- > where llvmAsmParser.cpp is related to Bison so I am compelled to feel > to > try installing flex/bison on my machine, anyway. > > Forgive my ignorance, could you briefly tell me about that? > Thank you in advance. > > Seung > > ---- Original message ---- > >Date: Tue, 12 Feb 2008 18:20:59 -0800 > >From: "Chuck Rose III" > >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > 2005? > >To: "LLVM Developers Mailing List" > > > >Hola Seung, > > > >I don't know if 2.1 in particular worked. I updated the 2.2 win32 > >vstudio 2k5 files right before lockdown, so they should be building. > >You will need appropriate versions of flex and bison installed. I > used > >the ones from getgnuwin32 on my machine. > > > >Good luck. > > > >Chuck. > > > >-----Original Message----- > >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > >On Behalf Of Seung Jae Lee > >Sent: Monday, February 11, 2008 10:05 PM > >To: llvmdev at cs.uiuc.edu > >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > >2005? > > > >Hello all, > > > >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? > >I did but not succeed due to some build errors. > >I seem to remember I read somewhere on this list it's compiled on > VS2005 > >so I wonder... > >Have a good night. > > > >Thx, > >Seung > >_______________________________________________ > >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 > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: > 2/13/2008 9:41 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: 2/13/2008 9:41 AM From robert.a.zeh at gmail.com Wed Feb 13 19:32:56 2008 From: robert.a.zeh at gmail.com (Robert Zeh) Date: Wed, 13 Feb 2008 19:32:56 -0600 Subject: [LLVMdev] Instrumenting virtual function calls In-Reply-To: <2EFD1412-81B9-42A7-B44F-F9F72A0157D4@nondot.org> References: <7092525B-2271-4C33-A612-226E076331D7@gmail.com> <2EFD1412-81B9-42A7-B44F-F9F72A0157D4@nondot.org> Message-ID: <4710F91A-D654-4A70-9F44-D63842104EA7@gmail.com> I thought about it --- that's actually how I figured out that I was getting the stub functions --- but the laziness is nice for my application. The bitcode module I'm working with is about 3.8 megabytes. I've been assuming it would take a while to compile each function, a chunk of which I probably won't need (but won't be able to tell until I get my input.) Robert On Feb 12, 2008, at 10:45 PM, Chris Lattner wrote: > > On Feb 12, 2008, at 5:08 PM, Robert Zeh wrote: > >> After hacking away at it for a bit, it looks like the mystery >> function >> is actually a stub function. The function pointer is coming from a >> vtable, which gets filled in with pointers to stub functions. >> >> Is there any way to do the round trip for a stub function? Two >> possible solutions come to mind: >> 1) Modify getGlobalValueAtAddress to work for pointers to stub >> functions >> 2) Add a getStubAtAddress >> >> Any other suggestions? > > Do you care about JIT laziness? You could just call > getPointerToFunction on every function in the module before your code > starts up. > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From geunsik.lim at samsung.com Wed Feb 13 19:15:55 2008 From: geunsik.lim at samsung.com (=?euc-kr?B?wNOx2b3E?=) Date: Thu, 14 Feb 2008 01:15:55 +0000 (GMT) Subject: [LLVMdev] Bug Report - Broken versions of FC6-GCC.4.1.1 when complie llvm-2.2 source Message-ID: <0JW700GMYFIJ9G@ms12.samsung.com> An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080214/7536fc8b/attachment.html From sabre at nondot.org Wed Feb 13 23:35:12 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 13 Feb 2008 21:35:12 -0800 Subject: [LLVMdev] Bug Report - Broken versions of FC6-GCC.4.1.1 when complie llvm-2.2 source In-Reply-To: <0JW700GMYFIJ9G@ms12.samsung.com> References: <0JW700GMYFIJ9G@ms12.samsung.com> Message-ID: <151F22A7-AAF3-4AFE-983A-672ADAD7D580@nondot.org> On Feb 13, 2008, at 5:15 PM, ??? wrote: > Hello. My name is Lim,GeunSik. I currently tre to compile llvm-2.2 > source. > at first, I download http://llvm.org/releases/2.2/llvm-gcc4.2-2.2-x86-linux-RHEL4.tar.gz > at http://llvm.org website. > I run into a problem with a version of My GCC on fedora/redhat > series. Belows are about error info. > Hi, please be aware that you're using some known-broken compilers. Please don't use any compilers on this list: http://llvm.org/docs/GettingStarted.html#brokengcc -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080213/7978ad57/attachment.html From jon at ffconsultancy.com Thu Feb 14 09:43:17 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Thu, 14 Feb 2008 15:43:17 +0000 Subject: [LLVMdev] Higher-level OCaml bindings Message-ID: <200802141543.18562.jon@ffconsultancy.com> I'm still meddling with different ways to exploit LLVM's awesome JIT compilation capabilities from OCaml. Although I've managed to get minimal compilers up and running with relatively little effort, I can't help but think that I'm spending a significant amount of time reinventing the C front-end. Would it make sense to have higher-level OCaml bindings to the current CLang front-end to make code generation even easier? Does CLang use a suitable intermediate representation for this to be possible? Just an idea... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From sabre at nondot.org Thu Feb 14 10:33:25 2008 From: sabre at nondot.org (Chris Lattner) Date: Thu, 14 Feb 2008 08:33:25 -0800 (PST) Subject: [LLVMdev] Higher-level OCaml bindings In-Reply-To: <200802141543.18562.jon@ffconsultancy.com> References: <200802141543.18562.jon@ffconsultancy.com> Message-ID: On Thu, 14 Feb 2008, Jon Harrop wrote: > Would it make sense to have higher-level OCaml bindings to the current CLang > front-end to make code generation even easier? > > Does CLang use a suitable intermediate representation for this to be possible? The higher level IR that clang uses is basically a C AST. This interface is under constant flux though. If you wanted to do this, it would be very reasonable to just cons up some C code and send it through the clang parser. Clang works great in a JIT environment. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From jon at ffconsultancy.com Thu Feb 14 11:10:24 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Thu, 14 Feb 2008 17:10:24 +0000 Subject: [LLVMdev] Higher-level OCaml bindings In-Reply-To: References: <200802141543.18562.jon@ffconsultancy.com> Message-ID: <200802141710.24674.jon@ffconsultancy.com> On Thursday 14 February 2008 16:33:25 Chris Lattner wrote: > On Thu, 14 Feb 2008, Jon Harrop wrote: > > Does CLang use a suitable intermediate representation for this to be > > possible? > > The higher level IR that clang uses is basically a C AST. This interface > is under constant flux though. If you wanted to do this, it would be > very reasonable to just cons up some C code and send it through the clang > parser. Clang works great in a JIT environment. Great! Sounds like CIL should do the trick: http://manju.cs.berkeley.edu/cil/ :-) -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From sabre at nondot.org Thu Feb 14 11:24:04 2008 From: sabre at nondot.org (Chris Lattner) Date: Thu, 14 Feb 2008 09:24:04 -0800 (PST) Subject: [LLVMdev] Higher-level OCaml bindings In-Reply-To: <200802141710.24674.jon@ffconsultancy.com> References: <200802141543.18562.jon@ffconsultancy.com> <200802141710.24674.jon@ffconsultancy.com> Message-ID: On Thu, 14 Feb 2008, Jon Harrop wrote: >> is under constant flux though. If you wanted to do this, it would be >> very reasonable to just cons up some C code and send it through the clang >> parser. Clang works great in a JIT environment. > > Great! Sounds like CIL should do the trick: > > http://manju.cs.berkeley.edu/cil/ Huh? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From jon at ffconsultancy.com Thu Feb 14 11:26:22 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Thu, 14 Feb 2008 17:26:22 +0000 Subject: [LLVMdev] Higher-level OCaml bindings In-Reply-To: References: <200802141543.18562.jon@ffconsultancy.com> <200802141710.24674.jon@ffconsultancy.com> Message-ID: <200802141726.22519.jon@ffconsultancy.com> On Thursday 14 February 2008 17:24:04 Chris Lattner wrote: > On Thu, 14 Feb 2008, Jon Harrop wrote: > >> is under constant flux though. If you wanted to do this, it would be > >> very reasonable to just cons up some C code and send it through the > >> clang parser. Clang works great in a JIT environment. > > > > Great! Sounds like CIL should do the trick: > > > > http://manju.cs.berkeley.edu/cil/ > > Huh? CIL should provide the AST type already in OCaml with a pretty printer to generate C code as a string that can be fed straight into CLang for JIT compilation. Then all I need is bindings to actually invoke CLang from OCaml with a string containing the source code. I'm particularly interested in making FFI to existing C libraries as easy as possible using code compiled by my compiler. I can't think of a better way than explicitly using C as an intermediate language. :-) Thanks, -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From angray at beeb.net Thu Feb 14 15:34:57 2008 From: angray at beeb.net (Aaron Gray) Date: Thu, 14 Feb 2008 21:34:57 -0000 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? References: <20080212235200.BBP58517@expms2.cites.uiuc.edu><680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com> <017f01c86e89$cbe88f90$63b9aeb0$@com> Message-ID: <00ae01c86f51$7236b080$0300a8c0@ze4427wm> >I have flex and bison from Cygwin installed: WinGNU32 Flex and Bison are the ones to use with LLVM and Visual Studio. http://gnuwin32.sourceforge.net/ The LLVM Visual Studio .sln file is for Visual Studio 2003 so will require conversion and some minor modification. Aaron > Should that work, assuming they're on the PATH? When I ran the build from > inside VS, I get some build failures, but nothing that implies that it was > looking for flex/bison to execute directly--are you supposed to run these > prior to launching the build? > > The docs on "Getting Started with Visual Studio" seem a tad bit out of > date, > but I'm certainly not enough beyond n00b status to know for sure. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Chuck Rose III >> Sent: Wednesday, February 13, 2008 8:52 AM >> To: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> 2005? >> >> I have always built it with flex and bison installed, though I believe >> Chris removed our last dependence on flex a little while back, so you >> may not need that. I'm using bison 2.1 which I got from the >> getgnuwin32 >> folks. I imagine that if you have cygwin or the like, you probably >> already have everything. >> >> You will need to have the executables in your path. >> >> I build with VisualStudio 2k5 Professional with VStudio SP1 installed. >> I typically work on Vista32 or Vista64, but have compiled on XP as >> well. >> >> >> I don't know how up to date the LLVM docs related to Visual Studio >> compilation are. >> >> Thanks, >> Chuck. >> >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Seung Jae Lee >> Sent: Tuesday, February 12, 2008 9:52 PM >> To: llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> 2005? >> >> Thanks for your comment. >> I also tried for LLVM 2.2 but got the same compilation errors on >> VS2005. >> (I didn't modify anything before the compilation) >> >> I just wonder if I need bison and flex even just in the case of >> compiling them on VS2005 without changing anything because the LLVM doc >> says "If you plan to modify any .y or .l files, you will need to have >> bison and/or flex installed where Visual Studio can find them. >> Otherwise, you do not need them and the pre-generated files that come >> with the source tree will be used." >> >> One of errors of mine is as follows: >> ------------------------------------------------------- >> ... >> 7>llvmAsmParser.cpp >> 7>c1xx : fatal error C1083: Cannot open source file: >> '.\llvmAsmParser.cpp': No such file or directory >> ... >> ------------------------------------------------------- >> where llvmAsmParser.cpp is related to Bison so I am compelled to feel >> to >> try installing flex/bison on my machine, anyway. >> >> Forgive my ignorance, could you briefly tell me about that? >> Thank you in advance. >> >> Seung >> >> ---- Original message ---- >> >Date: Tue, 12 Feb 2008 18:20:59 -0800 >> >From: "Chuck Rose III" >> >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual >> Studio >> 2005? >> >To: "LLVM Developers Mailing List" >> > >> >Hola Seung, >> > >> >I don't know if 2.1 in particular worked. I updated the 2.2 win32 >> >vstudio 2k5 files right before lockdown, so they should be building. >> >You will need appropriate versions of flex and bison installed. I >> used >> >the ones from getgnuwin32 on my machine. >> > >> >Good luck. >> > >> >Chuck. >> > >> >-----Original Message----- >> >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> >On Behalf Of Seung Jae Lee >> >Sent: Monday, February 11, 2008 10:05 PM >> >To: llvmdev at cs.uiuc.edu >> >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> >2005? >> > >> >Hello all, >> > >> >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? >> >I did but not succeed due to some build errors. >> >I seem to remember I read somewhere on this list it's compiled on >> VS2005 >> >so I wonder... >> >Have a good night. >> > >> >Thx, >> >Seung >> >_______________________________________________ >> >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 >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: >> 2/13/2008 9:41 AM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: 2/13/2008 > 9:41 AM > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From angray at beeb.net Thu Feb 14 15:40:44 2008 From: angray at beeb.net (Aaron Gray) Date: Thu, 14 Feb 2008 21:40:44 -0000 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? References: <20080212235200.BBP58517@expms2.cites.uiuc.edu><680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com><017f01c86e89$cbe88f90$63b9aeb0$@com> <00ae01c86f51$7236b080$0300a8c0@ze4427wm> Message-ID: <00b701c86f52$41410240$0300a8c0@ze4427wm> > >I have flex and bison from Cygwin installed: > > WinGNU32 Flex and Bison are the ones to use with LLVM and Visual Studio. > > http://gnuwin32.sourceforge.net/ Oh, you will have to install WinGNU32 M4 too. Aaron From cfr at adobe.com Thu Feb 14 17:07:03 2008 From: cfr at adobe.com (Chuck Rose III) Date: Thu, 14 Feb 2008 15:07:03 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <00ae01c86f51$7236b080$0300a8c0@ze4427wm> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu><680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com><017f01c86e89$cbe88f90$63b9aeb0$@com> <00ae01c86f51$7236b080$0300a8c0@ze4427wm> Message-ID: <680422C0AA225644931C2F6DD07200DD018DCBA3@namail5.corp.adobe.com> I converted it over to 2k5 a while back. Don't know about the 2.1 drop, but definitely for the 2.2 drop and most of the trunk time in between. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Aaron Gray Sent: Thursday, February 14, 2008 1:35 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? >I have flex and bison from Cygwin installed: WinGNU32 Flex and Bison are the ones to use with LLVM and Visual Studio. http://gnuwin32.sourceforge.net/ The LLVM Visual Studio .sln file is for Visual Studio 2003 so will require conversion and some minor modification. Aaron > Should that work, assuming they're on the PATH? When I ran the build from > inside VS, I get some build failures, but nothing that implies that it was > looking for flex/bison to execute directly--are you supposed to run these > prior to launching the build? > > The docs on "Getting Started with Visual Studio" seem a tad bit out of > date, > but I'm certainly not enough beyond n00b status to know for sure. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Chuck Rose III >> Sent: Wednesday, February 13, 2008 8:52 AM >> To: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> 2005? >> >> I have always built it with flex and bison installed, though I believe >> Chris removed our last dependence on flex a little while back, so you >> may not need that. I'm using bison 2.1 which I got from the >> getgnuwin32 >> folks. I imagine that if you have cygwin or the like, you probably >> already have everything. >> >> You will need to have the executables in your path. >> >> I build with VisualStudio 2k5 Professional with VStudio SP1 installed. >> I typically work on Vista32 or Vista64, but have compiled on XP as >> well. >> >> >> I don't know how up to date the LLVM docs related to Visual Studio >> compilation are. >> >> Thanks, >> Chuck. >> >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Seung Jae Lee >> Sent: Tuesday, February 12, 2008 9:52 PM >> To: llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> 2005? >> >> Thanks for your comment. >> I also tried for LLVM 2.2 but got the same compilation errors on >> VS2005. >> (I didn't modify anything before the compilation) >> >> I just wonder if I need bison and flex even just in the case of >> compiling them on VS2005 without changing anything because the LLVM doc >> says "If you plan to modify any .y or .l files, you will need to have >> bison and/or flex installed where Visual Studio can find them. >> Otherwise, you do not need them and the pre-generated files that come >> with the source tree will be used." >> >> One of errors of mine is as follows: >> ------------------------------------------------------- >> ... >> 7>llvmAsmParser.cpp >> 7>c1xx : fatal error C1083: Cannot open source file: >> '.\llvmAsmParser.cpp': No such file or directory >> ... >> ------------------------------------------------------- >> where llvmAsmParser.cpp is related to Bison so I am compelled to feel >> to >> try installing flex/bison on my machine, anyway. >> >> Forgive my ignorance, could you briefly tell me about that? >> Thank you in advance. >> >> Seung >> >> ---- Original message ---- >> >Date: Tue, 12 Feb 2008 18:20:59 -0800 >> >From: "Chuck Rose III" >> >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual >> Studio >> 2005? >> >To: "LLVM Developers Mailing List" >> > >> >Hola Seung, >> > >> >I don't know if 2.1 in particular worked. I updated the 2.2 win32 >> >vstudio 2k5 files right before lockdown, so they should be building. >> >You will need appropriate versions of flex and bison installed. I >> used >> >the ones from getgnuwin32 on my machine. >> > >> >Good luck. >> > >> >Chuck. >> > >> >-----Original Message----- >> >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> >On Behalf Of Seung Jae Lee >> >Sent: Monday, February 11, 2008 10:05 PM >> >To: llvmdev at cs.uiuc.edu >> >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio >> >2005? >> > >> >Hello all, >> > >> >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? >> >I did but not succeed due to some build errors. >> >I seem to remember I read somewhere on this list it's compiled on >> VS2005 >> >so I wonder... >> >Have a good night. >> > >> >Thx, >> >Seung >> >_______________________________________________ >> >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 >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: >> 2/13/2008 9:41 AM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: 2/13/2008 > 9:41 AM > > > _______________________________________________ > 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 angray at beeb.net Thu Feb 14 18:36:12 2008 From: angray at beeb.net (Aaron Gray) Date: Fri, 15 Feb 2008 00:36:12 -0000 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? References: <20080212235200.BBP58517@expms2.cites.uiuc.edu><680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com><017f01c86e89$cbe88f90$63b9aeb0$@com> <00ae01c86f51$7236b080$0300a8c0@ze4427wm> Message-ID: <00d801c86f6a$c45fd350$0300a8c0@ze4427wm> > >I have flex and bison from Cygwin installed: > > WinGNU32 Flex and Bison are the ones to use with LLVM and Visual Studio. > > http://gnuwin32.sourceforge.net/ Oh, you will have to install WinGNU32 M4 too. Aaron From ttmrichter at gmail.com Thu Feb 14 20:16:58 2008 From: ttmrichter at gmail.com (Michael T. Richter) Date: Fri, 15 Feb 2008 10:16:58 +0800 Subject: [LLVMdev] Some blogged LLVM experience. Message-ID: <1203041819.2703.12.camel@isolde> http://snakeratpig.blogspot.com/2008/02/alternative-compiler-suites.html Executive summary: LLVM-GCC was consistently faster and its output consistently faster than plain old GCC when compiling and using Ruby 1.9. Both compilers failed spectacularly on the full regression suite, but GCC lasted longer and did more tests before exploding. If I could find a comprehensive Erlang testing suite, I'd blog those results as well. I have been using LLVMed Erlang for two months now, however, with no ill effects noted and a "feel" that it is snappier. Good work. LLVM rocks. -- Michael T. Richter (GoogleTalk: ttmrichter at gmail.com) We should sell bloat credits, the way the government sells pollution credits. Everybody's assigned a certain amount of bloat, and if they go over, they have to purchase bloat credits from some other group that's been more careful. (Bent Hagemark) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/eb9998cd/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/eb9998cd/attachment.bin From ted at tedneward.com Thu Feb 14 20:54:39 2008 From: ted at tedneward.com (Ted Neward) Date: Thu, 14 Feb 2008 18:54:39 -0800 Subject: [LLVMdev] Question on link error Message-ID: <049301c86f7e$27d7ddc0$77879940$@com> So I?ve built llvm-2.2 using Cygwin, and I think I?ve got all the right bits in the right places, but I?m getting a strange error when running through the hello.c examples from the Web site: Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ gcc hello.s -o hello.native Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ ls hello.bc hello.c* hello.exe* hello.native* hello.s Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ ./hello.native hello world Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ lli hello.bc ERROR: Program used external function '__main' which could not be resolved! Aborted Is there something Really Really Simple (TM) that I?m missing here? AFAIK, __main is supposed to be inside hello.bc, so why can?t lli find it? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: 2/14/2008 10:28 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080214/4c2053e6/attachment-0001.html From sabre at nondot.org Thu Feb 14 21:11:36 2008 From: sabre at nondot.org (Chris Lattner) Date: Thu, 14 Feb 2008 19:11:36 -0800 Subject: [LLVMdev] Question on link error In-Reply-To: <049301c86f7e$27d7ddc0$77879940$@com> References: <049301c86f7e$27d7ddc0$77879940$@com> Message-ID: <68CB0C5F-FFD8-4A4A-A120-BA8D08A2D58F@nondot.org> On Feb 14, 2008, at 6:54 PM, Ted Neward wrote: > So I?ve built llvm-2.2 using Cygwin, and I think I?ve got all the > right bits in the right places, but I?m getting a strange error when > running through the hello.c examples from the Web site: How did you create hello.s? What version of llvm-gcc are you using? 4.2? Have you tried compiling hello.s to hello.native with llvm-gcc instead of gcc? -Chris > > Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm > $ gcc hello.s -o hello.native > > Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm > $ ls > hello.bc hello.c* hello.exe* hello.native* hello.s > > Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm > $ ./hello.native > hello world > > Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm > $ lli hello.bc > ERROR: Program used external function '__main' which could not be > resolved! > Aborted > > > Is there something Really Really Simple (TM) that I?m missing here? > AFAIK, __main is supposed to be inside hello.bc, so why can?t lli > find it? > > > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: > 2/14/2008 10:28 AM > > _______________________________________________ > 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/20080214/0d25d6ee/attachment.html From ted at tedneward.com Fri Feb 15 01:58:56 2008 From: ted at tedneward.com (Ted Neward) Date: Thu, 14 Feb 2008 23:58:56 -0800 Subject: [LLVMdev] Question on link error In-Reply-To: <68CB0C5F-FFD8-4A4A-A120-BA8D08A2D58F@nondot.org> References: <049301c86f7e$27d7ddc0$77879940$@com> <68CB0C5F-FFD8-4A4A-A120-BA8D08A2D58F@nondot.org> Message-ID: <004901c86fa8$a98147b0$fc83d710$@com> (*) hello.s was created as per what?s on the LLVM page: Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ llc hello.bc -o hello.s (*) gcc is llvm-gcc, compiled from the llvm-gcc-4.2 source tree: Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ gcc --version gcc (GCC) 4.2.1 (Based on Apple Inc. build 5546) (LLVM build) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (*) Yes, I compiled hello.s -> hello.native using llvm-gcc, since that?s what?s on the PATH ahead of the original Cygwin gcc. Hello.native also runs just fine. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Thursday, February 14, 2008 7:12 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Question on link error On Feb 14, 2008, at 6:54 PM, Ted Neward wrote: So I?ve built llvm-2.2 using Cygwin, and I think I?ve got all the right bits in the right places, but I?m getting a strange error when running through the hello.c examples from the Web site: How did you create hello.s? What version of llvm-gcc are you using? 4.2? Have you tried compiling hello.s to hello.native with llvm-gcc instead of gcc? -Chris Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ gcc hello.s -o hello.native Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ ls hello.bc hello.c* hello.exe* hello.native* hello.s Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ ./hello.native hello world Ted at XPLanguages /cygdrive/c/Projects/Exploration/llvm $ lli hello.bc ERROR: Program used external function '__main' which could not be resolved! Aborted Is there something Really Really Simple (TM) that I?m missing here? AFAIK, __main is supposed to be inside hello.bc, so why can?t lli find it? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: 2/14/2008 10:28 AM _______________________________________________ LLVM Developers mailing list HYPERLINK "mailto:LLVMdev at cs.uiuc.edu"LLVMdev at cs.uiuc.edu HYPERLINK "http://llvm.cs.uiuc.edu"http://llvm.cs.uiuc.edu HYPERLINK "http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"http://lists.cs.uiuc.edu/ mailman/listinfo/llvmdev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: 2/14/2008 10:28 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: 2/14/2008 10:28 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080214/8472af7f/attachment-0001.html From baldrick at free.fr Fri Feb 15 02:06:58 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 15 Feb 2008 09:06:58 +0100 Subject: [LLVMdev] Some blogged LLVM experience. In-Reply-To: <1203041819.2703.12.camel@isolde> References: <1203041819.2703.12.camel@isolde> Message-ID: <200802150907.02654.baldrick@free.fr> Hi Michael, thanks for trying out LLVM! "The bad news comes with the make test-all results. Less than two minutes into the comprehensive test suite the LLVM-GCC version of Ruby 1.9 dies with the following message: "Illegal instruction (core dumped)". Later it tells me the test failed with "error 132". This is, as you can see, not a very useful message since it's not really helping me locate where the error is." The illegal instruction message is not coming from ruby or LLVM, it is coming from the OS: the program fed the processor some garbage to execute rather than proper instruction codes, and was promptly killed with this message. As for "error 132", it is also not coming from LLVM which does not produce messages of this kind. Does ruby compile ruby code to native instructions and execute them? If so and it made a mistake that would explain the illegal instruction error. Otherwise it probably means that llvm-gcc miscompiled something. If you can extract a testcase please don't hesitate to post it to LLVM bugzilla (http://llvm.org/bugs). Bugs generally get fixed fast, but someone needs to report them! Best wishes, Duncan. From asl at math.spbu.ru Fri Feb 15 05:52:02 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 15 Feb 2008 14:52:02 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?UXVlc3Rpb24gb24gbGluayBlcnJvcg==?= Message-ID: <200802151152.m1FBq1LB072913@star.math.spbu.ru> Hello, Ted > __main is supposed to be inside hello.bc, so why can?t lli find it? No, it shouldn't be there. On targets, which lacks init sections (for example, all win-based, like mingw & cygwin) __main is used to call static constructors and relevant stuff. The call to __main is assembled early in the main routine before the actual code will be executed. I'll try to look into this problem today. -- WBR, Anton Korobeynikov From ralph at inputplus.co.uk Fri Feb 15 06:49:15 2008 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 15 Feb 2008 12:49:15 +0000 Subject: [LLVMdev] Some blogged LLVM experience. In-Reply-To: <200802150907.02654.baldrick@free.fr> References: <1203041819.2703.12.camel@isolde> <200802150907.02654.baldrick@free.fr> Message-ID: <20080215124915.478DB14822C@blake.inputplus.co.uk> Hi Duncan, > "The bad news comes with the make test-all results. Less than two > minutes into the comprehensive test suite the LLVM-GCC version of Ruby > 1.9 dies with the following message: "Illegal instruction (core > dumped)". Later it tells me the test failed with "error 132". This is, > as you can see, not a very useful message since it's not really > helping me locate where the error is." > > The illegal instruction message is not coming from ruby or LLVM, it is > coming from the OS: the program fed the processor some garbage to > execute rather than proper instruction codes, and was promptly killed > with this message. As for "error 132", it is also not coming from > LLVM which does not produce messages of this kind. 132 is 0x84 and looks like an exit value for the process, i.e. it was killed by signal 4 which is normally SIGILL, i.e. illegal instruction. The test harness is probably printing the `error 132'. Cheers, Ralph. From ttmrichter at gmail.com Fri Feb 15 08:24:51 2008 From: ttmrichter at gmail.com (Michael T. Richter) Date: Fri, 15 Feb 2008 22:24:51 +0800 Subject: [LLVMdev] Some blogged LLVM experience. In-Reply-To: <200802150907.02654.baldrick@free.fr> References: <1203041819.2703.12.camel@isolde> <200802150907.02654.baldrick@free.fr> Message-ID: <1203085492.2703.18.camel@isolde> On Fri, 2008-02-15 at 09:06 +0100, Duncan Sands wrote: > Does ruby compile ruby code to native instructions and execute them? No. Ruby is an interpreted language. The latest version has a VM that it targets -- YARV -- but it still does not compile to native like, say, a JIT would. > Otherwise it probably means that llvm-gcc miscompiled something. This is what I'm guessing at this stage. It is, however, only a guess. And given that GCC raw -- the "native" compilation platform for Ruby -- also fails (albeit in a different, highly-entertaining way -- I'm also guessing that part of this is because Ruby is doing some weird stuff behind the scenes. > If you can extract a testcase please don't hesitate to post it to LLVM bugzilla > (http://llvm.org/bugs). Bugs generally get fixed fast, but someone needs > to report them! I have already reported the bug with a "test case" that consists of "here is how to build Ruby with llvm-gcc". :) I have also slotted some hacking time to figure out where in the test harness the thing is exploding. Unfortunately, unlike the explosion that GCC's failure gives, the LLVM-GCC version explodes so thoroughly that it doesn't print out any kind of error message. All I get is a bunch of pacifier dots on the screen as one test after another is run (there are thousands) and then that message. It will take me a while to figure out where the error is happening. (Binary search for the win!) Once I have it narrowed down to one specific test, I will update the bug report with the steps required to replicate the error. -- Michael T. Richter (GoogleTalk: ttmrichter at gmail.com) Experts in advanced countries underestimate by a factor of two to four the ability of people in underdeveloped countries to do anything technical. (Charles P Issawi) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/dbfc35d6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/dbfc35d6/attachment.bin From ralph at inputplus.co.uk Fri Feb 15 09:06:26 2008 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 15 Feb 2008 15:06:26 +0000 Subject: [LLVMdev] Some blogged LLVM experience. In-Reply-To: <1203085492.2703.18.camel@isolde> References: <1203041819.2703.12.camel@isolde> <200802150907.02654.baldrick@free.fr> <1203085492.2703.18.camel@isolde> Message-ID: <20080215150626.94C90148F35@blake.inputplus.co.uk> Hi Michael, > All I get is a bunch of pacifier dots on the screen as one test after > another is run (there are thousands) and then that message. It will > take me a while to figure out where the error is happening. (Binary > search for the win!) Once I have it narrowed down to one specific > test, I will update the bug report with the steps required to > replicate the error. Take a look at the test harness source. Most likely, where it's printing those dots, there's a conditional "if verbose, print the test name". You can then look to see how to turn on verbose, etc. Cheers, Ralph. From evan.cheng at apple.com Fri Feb 15 11:35:27 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 15 Feb 2008 09:35:27 -0800 Subject: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build In-Reply-To: <680422C0AA225644931C2F6DD07200DD01897697@namail5.corp.adobe.com> References: <680422C0AA225644931C2F6DD07200DD01897697@namail5.corp.adobe.com> Message-ID: On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I?m debugging through some strangeness that I?m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I?ve otherwise > left LLVM 2.2 alone. The basic idea is that I?ve got a function bar > which is compiled by VStudio and I?m creating another function foo > via LLVM JIT which is going to call into bar. This has been working > for me for a long time on win32 and also under xcode of course. > I?ve included the code that generates the situation at the bottom. > Some questions (which may be really brain dead) are: > > 1. Why isn?t the stack getting set up in foo prior to the call > down into bar? What is the triplet of the target? x86_64-win32? > 2. Why is the call to bar a pointer to a jump. I.e. why > didn?t it resolve the address in foo? Not sure. I can't reproduce this. Can you step through the code in X86ISelLowering.cpp::LowerCALL()? Around // If the callee is a GlobalAddress node (quite common, every direct call is) // turn it into a TargetGlobalAddress node so that legalize doesn't hack it. Evan > 3. What are some good places for me to be looking to try and > drill down further on what?s happening? I?ve tried switching > calling conventions and have watched it create machine instructions > for adjusting the stack up and down, but they seem to be removed by > the time it actually gets down to execution time. > > Any suggestions would be appreciated. > > Thanks, > Chuck. > > Call into function (foo) > 0000000000980030 mov rax,140001591h > 000000000098003A call rax ? this is > calling to bar via a jump table > 000000000098003C ret > > Leads to > 0000000140001591 jmp bar (1400064E0h) > > Leads to > void bar(int i) > { > 00000001400064E0 mov dword ptr [rsp+8],ecx > 00000001400064E4 push rdi > 00000001400064E5 sub rsp,20h > 00000001400064E9 mov rdi,rsp > 00000001400064EC mov rcx,8 > 00000001400064F6 mov eax,0CCCCCCCCh > 00000001400064FB rep stos dword ptr [rdi] > 00000001400064FD mov ecx,dword ptr [rsp+30h] > printf("the int is %i\n",i); > 0000000140006501 mov edx,dword ptr [i] > 0000000140006505 lea rcx,[string "the int is %i > \n" (140C1A240h)] > 000000014000650C call qword ptr [__imp_printf (141145920h)] > } > 0000000140006512 add rsp,20h > 0000000140006516 pop rdi > 0000000140006517 ret > > At this point, we seem to be jumping back up but the stack is no > longer in order, so > 000000000098003C ret > > Takes us into wonderland > 0000000100000003 ??? > > But unfortunately not through the looking glass. > > Here?s the modification of the Fibonacci program which got me the > above: > #include "llvm/Module.h" > #include "llvm/DerivedTypes.h" > #include "llvm/Constants.h" > #include "llvm/Instructions.h" > #include "llvm/ModuleProvider.h" > #include "llvm/Analysis/Verifier.h" > #include "llvm/ExecutionEngine/JIT.h" > #include "llvm/ExecutionEngine/Interpreter.h" > #include "llvm/ExecutionEngine/GenericValue.h" > #include "llvm/System/DynamicLibrary.h" > #include "llvm/CallingConv.h" > #include > #include > using namespace llvm; > > void bar(int i) > { > printf("the int is %i\n",i); > } > > Function* createBarFunction(Module* M) > { > Function* pBarF = cast(M->getOrInsertFunction("bar", > Type::VoidTy, Type::Int32Ty, NULL)); > return pBarF; > } > > Function* createFooFunction(Module* M) > { > Function* pBarF = createBarFunction(M), > * pFooF; > > pFooF = cast(M->getOrInsertFunction("foo", > Type::VoidTy, Type::Int32Ty, NULL)); > BasicBlock* pBody = new BasicBlock("body",pFooF); > Argument* pArg = pFooF->arg_begin(); > pArg->setName("i"); > std::vector barArgs; > barArgs.push_back(pArg); > new CallInst(pBarF, barArgs.begin(), barArgs.end(), "", pBody); > new ReturnInst(NULL, pBody); > return pFooF; > } > > int main(int argc, char **argv) { > // Create some module to put our function into it. > Module *M = new Module("test"); > > M->setDataLayout("e-p:64:64:64-i1:8:8:8-i8:8:8:8-i32:32:32:32- > f32:32:32:32"); > Function* pFooF = createFooFunction(M); > M->print(std::cout); > > // Now we going to create JIT > ExistingModuleProvider *MP = new ExistingModuleProvider(M); > ExecutionEngine *EE = ExecutionEngine::create(MP, false); > > sys::DynamicLibrary::AddSymbol("bar", (void*) bar); > llvm::Module::FunctionListType& funcList = MP->getModule()- > >getFunctionList(); > > for (llvm::Module::FunctionListType::iterator i = > funcList.begin() ; i != funcList.end() ; ++i) > { > EE->getPointerToFunction(i); > } > > EE->recompileAndRelinkFunction(pFooF); > > std::vector Args(1); > Args[0].IntVal = APInt(32, 3); > GenericValue GV = EE->runFunction(pFooF, Args); > > return 0; > } > > _______________________________________________ > 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/20080215/798d5012/attachment-0001.html From sabre at nondot.org Fri Feb 15 12:08:57 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 10:08:57 -0800 Subject: [LLVMdev] an llvm-gcc bug In-Reply-To: <200802130835.20332.baldrick@free.fr> References: <200802130835.20332.baldrick@free.fr> Message-ID: <06E61F18-FB44-419D-9D85-C33168D9762C@nondot.org> >> Alternatively I can take the Padding bit into account in the >> StructType::get code somehow. Anyone have a strong opinion? > > Shouldn't it be a map from the gcc type to the padding info? > That said, you can get rid of the padding info as far as I'm > concerned. However Chris might have a different opinion - I > think he introduced it. I don't think I introduced it (was it Devang?). However, I agree with duncan: the right fix is to make the StructTypeInfoMap be indexed by a GCC type, not an llvm type. I am not fully familiar with how StructTypeInfoMap works, but I wouldn't be surprised if this caused other subtle miscompilations. -Chris From dpatel at apple.com Fri Feb 15 12:23:47 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 15 Feb 2008 10:23:47 -0800 Subject: [LLVMdev] an llvm-gcc bug In-Reply-To: <06E61F18-FB44-419D-9D85-C33168D9762C@nondot.org> References: <200802130835.20332.baldrick@free.fr> <06E61F18-FB44-419D-9D85-C33168D9762C@nondot.org> Message-ID: <76A6A427-6C09-49C6-B949-9CCE59AD364F@apple.com> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>> Alternatively I can take the Padding bit into account in the >>> StructType::get code somehow. Anyone have a strong opinion? >> >> Shouldn't it be a map from the gcc type to the padding info? >> That said, you can get rid of the padding info as far as I'm >> concerned. However Chris might have a different opinion - I >> think he introduced it. > > I don't think I introduced it (was it Devang?). Yup. PR 1278 > However, I agree with > duncan: the right fix is to make the StructTypeInfoMap be indexed by a > GCC type, not an llvm type. I am not fully familiar with how > StructTypeInfoMap works, but I wouldn't be surprised if this caused > other subtle miscompilations. > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev - Devang From sabre at nondot.org Fri Feb 15 12:27:32 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 10:27:32 -0800 Subject: [LLVMdev] an llvm-gcc bug In-Reply-To: <76A6A427-6C09-49C6-B949-9CCE59AD364F@apple.com> References: <200802130835.20332.baldrick@free.fr> <06E61F18-FB44-419D-9D85-C33168D9762C@nondot.org> <76A6A427-6C09-49C6-B949-9CCE59AD364F@apple.com> Message-ID: <392A5148-74C2-4F1C-98BC-4583DB8FE85A@nondot.org> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > > On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > >>>> Alternatively I can take the Padding bit into account in the >>>> StructType::get code somehow. Anyone have a strong opinion? >>> >>> Shouldn't it be a map from the gcc type to the padding info? >>> That said, you can get rid of the padding info as far as I'm >>> concerned. However Chris might have a different opinion - I >>> think he introduced it. >> >> I don't think I introduced it (was it Devang?). > > Yup. PR 1278 Ok! Can you please fix it to index by GCC type? There is a many to one mapping between gcc types and llvm types. -Chris From romixlev at yahoo.com Fri Feb 15 12:27:35 2008 From: romixlev at yahoo.com (Roman Levenstein) Date: Fri, 15 Feb 2008 19:27:35 +0100 (CET) Subject: [LLVMdev] Some questions about live intervals In-Reply-To: Message-ID: <445724.64646.qm@web56310.mail.re3.yahoo.com> Hi Evan, [skipped] ... > > Please, let me know, if I should sumbit a patch without any > > assert() and returning just a NULL pointer. > > Now I think either approach is fine. Please commit. Thanks! > > Evan I don't have a commit access to the SVN repository. Therefore I cannot commit it myself. Should I better apply for getting a commiter access or should I simply send you the final version of the patch? -Roman Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail From baldrick at free.fr Fri Feb 15 12:34:36 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 15 Feb 2008 19:34:36 +0100 Subject: [LLVMdev] Some blogged LLVM experience. In-Reply-To: <1203085492.2703.18.camel@isolde> References: <1203041819.2703.12.camel@isolde> <200802150907.02654.baldrick@free.fr> <1203085492.2703.18.camel@isolde> Message-ID: <200802151934.37494.baldrick@free.fr> Hi Michael, > ... Unfortunately, unlike the explosion that GCC's failure > gives, the LLVM-GCC version explodes so thoroughly that it doesn't print > out any kind of error message. All I get is a bunch of pacifier dots on > the screen as one test after another is run (there are thousands) and > then that message. I tried it here and it's not clear to me whether it failed the same way as for you. I noted what I saw in the bugzilla entry http://llvm.org/bugs/show_bug.cgi?id=2038 Let's continue the discussion there. Best wishes, Duncan. From cfr at adobe.com Fri Feb 15 13:00:34 2008 From: cfr at adobe.com (Chuck Rose III) Date: Fri, 15 Feb 2008 11:00:34 -0800 Subject: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build In-Reply-To: References: <680422C0AA225644931C2F6DD07200DD01897697@namail5.corp.adobe.com> Message-ID: <680422C0AA225644931C2F6DD07200DD018DCEC4@namail5.corp.adobe.com> Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0 IsLittleEndian=true ...} llvm::TargetLowering VarArgsFrameIndex -842150451 int RegSaveFrameIndex -842150451 int VarArgsGPOffset 3452816845 unsigned int VarArgsFPOffset 3452816845 unsigned int BytesToPopOnReturn 0 int BytesCallerReserves 0 int - Subtarget 0x00000000008eda90 {AsmFlavor=Intel PICStyle=None X86SSELevel=SSE2 ...} const llvm::X86Subtarget * + llvm::TargetSubtarget {...} llvm::TargetSubtarget AsmFlavor Intel llvm::X86Subtarget::AsmWriterFlavorTy PICStyle None llvm::PICStyle::Style X86SSELevel SSE2 llvm::X86Subtarget::X86SSEEnum X863DNowLevel -842150451 llvm::X86Subtarget::X863DNowEnum HasX86_64 true bool DarwinVers 0 unsigned char stackAlignment 8 unsigned int MaxInlineSizeThreshold 128 unsigned int Is64Bit true bool HasLow4GUserAddress true bool TargetType isWindows llvm::X86Subtarget:: if (GlobalAddressSDNode *G = dyn_cast(Callee)) { // We should use extra load for direct calls to dllimported functions in // non-JIT mode. // it get's into here if ((IsTailCall || !Is64Bit || // both these are false getTargetMachine().getCodeModel() != CodeModel::Large) // this is false && !Subtarget->GVRequiresExtraLoad(G->getGlobal(), // this is short circuited away getTargetMachine(), true)) Callee = DAG.getTargetGlobalAddress(G->getGlobal(), getPointerTy()); // this is passed over because the test is false // since it made it through the if (Global...., it skips down to // Returns a chain & a flag for retval copy to use. SDVTList NodeTys = DAG.getVTList(MVT::Other, MVT::Flag); Thanks! Chuck. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Friday, February 15, 2008 9:35 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going to call into bar. This has been working for me for a long time on win32 and also under xcode of course. I've included the code that generates the situation at the bottom. Some questions (which may be really brain dead) are: 1. Why isn't the stack getting set up in foo prior to the call down into bar? What is the triplet of the target? x86_64-win32? 2. Why is the call to bar a pointer to a jump. I.e. why didn't it resolve the address in foo? Not sure. I can't reproduce this. Can you step through the code in X86ISelLowering.cpp::LowerCALL()? Around // If the callee is a GlobalAddress node (quite common, every direct call is) // turn it into a TargetGlobalAddress node so that legalize doesn't hack it. Evan 3. What are some good places for me to be looking to try and drill down further on what's happening? I've tried switching calling conventions and have watched it create machine instructions for adjusting the stack up and down, but they seem to be removed by the time it actually gets down to execution time. Any suggestions would be appreciated. Thanks, Chuck. Call into function (foo) 0000000000980030 mov rax,140001591h 000000000098003A call rax ? this is calling to bar via a jump table 000000000098003C ret Leads to 0000000140001591 jmp bar (1400064E0h) Leads to void bar(int i) { 00000001400064E0 mov dword ptr [rsp+8],ecx 00000001400064E4 push rdi 00000001400064E5 sub rsp,20h 00000001400064E9 mov rdi,rsp 00000001400064EC mov rcx,8 00000001400064F6 mov eax,0CCCCCCCCh 00000001400064FB rep stos dword ptr [rdi] 00000001400064FD mov ecx,dword ptr [rsp+30h] printf("the int is %i\n",i); 0000000140006501 mov edx,dword ptr [i] 0000000140006505 lea rcx,[string "the int is %i\n" (140C1A240h)] 000000014000650C call qword ptr [__imp_printf (141145920h)] } 0000000140006512 add rsp,20h 0000000140006516 pop rdi 0000000140006517 ret At this point, we seem to be jumping back up but the stack is no longer in order, so 000000000098003C ret Takes us into wonderland 0000000100000003 ??? But unfortunately not through the looking glass. Here's the modification of the Fibonacci program which got me the above: #include "llvm/Module.h" #include "llvm/DerivedTypes.h" #include "llvm/Constants.h" #include "llvm/Instructions.h" #include "llvm/ModuleProvider.h" #include "llvm/Analysis/Verifier.h" #include "llvm/ExecutionEngine/JIT.h" #include "llvm/ExecutionEngine/Interpreter.h" #include "llvm/ExecutionEngine/GenericValue.h" #include "llvm/System/DynamicLibrary.h" #include "llvm/CallingConv.h" #include #include using namespace llvm; void bar(int i) { printf("the int is %i\n",i); } Function* createBarFunction(Module* M) { Function* pBarF = cast(M->getOrInsertFunction("bar", Type::VoidTy, Type::Int32Ty, NULL)); return pBarF; } Function* createFooFunction(Module* M) { Function* pBarF = createBarFunction(M), * pFooF; pFooF = cast(M->getOrInsertFunction("foo", Type::VoidTy, Type::Int32Ty, NULL)); BasicBlock* pBody = new BasicBlock("body",pFooF); Argument* pArg = pFooF->arg_begin(); pArg->setName("i"); std::vector barArgs; barArgs.push_back(pArg); new CallInst(pBarF, barArgs.begin(), barArgs.end(), "", pBody); new ReturnInst(NULL, pBody); return pFooF; } int main(int argc, char **argv) { // Create some module to put our function into it. Module *M = new Module("test"); M->setDataLayout("e-p:64:64:64-i1:8:8:8-i8:8:8:8-i32:32:32:32-f32:32:32:32"); Function* pFooF = createFooFunction(M); M->print(std::cout); // Now we going to create JIT ExistingModuleProvider *MP = new ExistingModuleProvider(M); ExecutionEngine *EE = ExecutionEngine::create(MP, false); sys::DynamicLibrary::AddSymbol("bar", (void*) bar); llvm::Module::FunctionListType& funcList = MP->getModule()->getFunctionList(); for (llvm::Module::FunctionListType::iterator i = funcList.begin() ; i != funcList.end() ; ++i) { EE->getPointerToFunction(i); } EE->recompileAndRelinkFunction(pFooF); std::vector Args(1); Args[0].IntVal = APInt(32, 3); GenericValue GV = EE->runFunction(pFooF, Args); return 0; } _______________________________________________ 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/20080215/0ff5161b/attachment-0001.html From dpatel at apple.com Fri Feb 15 13:17:33 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 15 Feb 2008 11:17:33 -0800 Subject: [LLVMdev] an llvm-gcc bug In-Reply-To: <392A5148-74C2-4F1C-98BC-4583DB8FE85A@nondot.org> References: <200802130835.20332.baldrick@free.fr> <06E61F18-FB44-419D-9D85-C33168D9762C@nondot.org> <76A6A427-6C09-49C6-B949-9CCE59AD364F@apple.com> <392A5148-74C2-4F1C-98BC-4583DB8FE85A@nondot.org> Message-ID: <0C222846-383D-41DD-8229-4858BD1FD3A2@apple.com> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > >> >> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >> >>>>> Alternatively I can take the Padding bit into account in the >>>>> StructType::get code somehow. Anyone have a strong opinion? >>>> >>>> Shouldn't it be a map from the gcc type to the padding info? >>>> That said, you can get rid of the padding info as far as I'm >>>> concerned. However Chris might have a different opinion - I >>>> think he introduced it. >>> >>> I don't think I introduced it (was it Devang?). >> >> Yup. PR 1278 > > Ok! Can you please fix it to index by GCC type? There is a many to > one mapping between gcc types and llvm types. This is tricky and probably won't work. Padding info is in llvm struct type and CopyAggregate() is operating on llvm type. There is not any way to map llvm type back to gcc type. Am I missing something ? - Devang From sabre at nondot.org Fri Feb 15 13:21:41 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 11:21:41 -0800 Subject: [LLVMdev] an llvm-gcc bug In-Reply-To: <0C222846-383D-41DD-8229-4858BD1FD3A2@apple.com> References: <200802130835.20332.baldrick@free.fr> <06E61F18-FB44-419D-9D85-C33168D9762C@nondot.org> <76A6A427-6C09-49C6-B949-9CCE59AD364F@apple.com> <392A5148-74C2-4F1C-98BC-4583DB8FE85A@nondot.org> <0C222846-383D-41DD-8229-4858BD1FD3A2@apple.com> Message-ID: <8A9142EB-F978-4CCE-8550-5F805BDFAA07@nondot.org> On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: >> Ok! Can you please fix it to index by GCC type? There is a many to >> one mapping between gcc types and llvm types. > > This is tricky and probably won't work. Padding info is in llvm struct > type and CopyAggregate() is operating on llvm type. There is not any > way to map llvm type back to gcc type. Am I missing something ? EmitAggregateCopy has the gcc type. It would be reasonable to have CopyAggregate walk the GCC type in parallel with the llvm type, at least in simple cases. In more complex cases, it could give up. -Chris From dalej at apple.com Fri Feb 15 13:22:47 2008 From: dalej at apple.com (Dale Johannesen) Date: Fri, 15 Feb 2008 11:22:47 -0800 Subject: [LLVMdev] an llvm-gcc bug In-Reply-To: <0C222846-383D-41DD-8229-4858BD1FD3A2@apple.com> References: <200802130835.20332.baldrick@free.fr> <06E61F18-FB44-419D-9D85-C33168D9762C@nondot.org> <76A6A427-6C09-49C6-B949-9CCE59AD364F@apple.com> <392A5148-74C2-4F1C-98BC-4583DB8FE85A@nondot.org> <0C222846-383D-41DD-8229-4858BD1FD3A2@apple.com> Message-ID: <04308F30-2980-4F02-8FF7-E09DD4D0D9C1@apple.com> On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > > On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > >> >> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >> >>> >>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>> >>>>>> Alternatively I can take the Padding bit into account in the >>>>>> StructType::get code somehow. Anyone have a strong opinion? >>>>> >>>>> Shouldn't it be a map from the gcc type to the padding info? >>>>> That said, you can get rid of the padding info as far as I'm >>>>> concerned. However Chris might have a different opinion - I >>>>> think he introduced it. >>>> >>>> I don't think I introduced it (was it Devang?). >>> >>> Yup. PR 1278 >> >> Ok! Can you please fix it to index by GCC type? There is a many to >> one mapping between gcc types and llvm types. > > This is tricky and probably won't work. Padding info is in llvm struct > type and CopyAggregate() is operating on llvm type. There is not any > way to map llvm type back to gcc type. Am I missing something ? I don't think so, I have reached the same conclusion. You can pass the gcc type into CopyAggregate, but it's recursive, and there's no way to get the gcc type for the fields. You would have to walk the gcc type in parallel with the llvm type, which at best involves duplicating a lot of code and is quite error prone. From dalej at apple.com Fri Feb 15 13:27:42 2008 From: dalej at apple.com (Dale Johannesen) Date: Fri, 15 Feb 2008 11:27:42 -0800 Subject: [LLVMdev] an llvm-gcc bug In-Reply-To: <04308F30-2980-4F02-8FF7-E09DD4D0D9C1@apple.com> References: <200802130835.20332.baldrick@free.fr> <06E61F18-FB44-419D-9D85-C33168D9762C@nondot.org> <76A6A427-6C09-49C6-B949-9CCE59AD364F@apple.com> <392A5148-74C2-4F1C-98BC-4583DB8FE85A@nondot.org> <0C222846-383D-41DD-8229-4858BD1FD3A2@apple.com> <04308F30-2980-4F02-8FF7-E09DD4D0D9C1@apple.com> Message-ID: <86CE380D-44AB-4035-9E7C-2DCD85308BDA@apple.com> On Feb 15, 2008, at 11:22 AM, Dale Johannesen wrote: > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > >> >> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: >> >>> >>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >>> >>>> >>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>>> >>>>>>> Alternatively I can take the Padding bit into account in the >>>>>>> StructType::get code somehow. Anyone have a strong opinion? >>>>>> >>>>>> Shouldn't it be a map from the gcc type to the padding info? >>>>>> That said, you can get rid of the padding info as far as I'm >>>>>> concerned. However Chris might have a different opinion - I >>>>>> think he introduced it. >>>>> >>>>> I don't think I introduced it (was it Devang?). >>>> >>>> Yup. PR 1278 >>> >>> Ok! Can you please fix it to index by GCC type? There is a many to >>> one mapping between gcc types and llvm types. >> >> This is tricky and probably won't work. Padding info is in llvm >> struct >> type and CopyAggregate() is operating on llvm type. There is not any >> way to map llvm type back to gcc type. Am I missing something ? > > > I don't think so, I have reached the same conclusion. You can pass > the gcc type into CopyAggregate, but it's recursive, and there's no > way to get the gcc type for the fields. You would have to walk the > gcc type in parallel with the llvm type, which at best involves > duplicating a lot of code and is quite error prone. ...but giving up in this case is easy enough, ok, I can do that. From sabre at nondot.org Fri Feb 15 13:39:06 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 11:39:06 -0800 Subject: [LLVMdev] an llvm-gcc bug In-Reply-To: <86CE380D-44AB-4035-9E7C-2DCD85308BDA@apple.com> References: <200802130835.20332.baldrick@free.fr> <06E61F18-FB44-419D-9D85-C33168D9762C@nondot.org> <76A6A427-6C09-49C6-B949-9CCE59AD364F@apple.com> <392A5148-74C2-4F1C-98BC-4583DB8FE85A@nondot.org> <0C222846-383D-41DD-8229-4858BD1FD3A2@apple.com> <04308F30-2980-4F02-8FF7-E09DD4D0D9C1@apple.com> <86CE380D-44AB-4035-9E7C-2DCD85308BDA@apple.com> Message-ID: <9345E8E7-503D-483F-90DD-1DA6FD64B6F3@nondot.org> On Feb 15, 2008, at 11:27 AM, Dale Johannesen wrote: >> I don't think so, I have reached the same conclusion. You can pass >> the gcc type into CopyAggregate, but it's recursive, and there's no >> way to get the gcc type for the fields. You would have to walk the >> gcc type in parallel with the llvm type, which at best involves >> duplicating a lot of code and is quite error prone. > > ...but giving up in this case is easy enough, ok, I can do that. Cool, thanks Dale! I think it would be reasonable to give up in nested struct cases, etc. We can always improve it later, and that will get us the obvious case in PR1278. -Chris From ted at tedneward.com Fri Feb 15 13:47:47 2008 From: ted at tedneward.com (Ted Neward) Date: Fri, 15 Feb 2008 11:47:47 -0800 Subject: [LLVMdev] Question on link error In-Reply-To: <200802151152.m1FBq1LB072913@star.math.spbu.ru> References: <200802151152.m1FBq1LB072913@star.math.spbu.ru> Message-ID: <017001c8700b$a8172760$f8457620$@com> I am *more* than willing to believe it's an environment/configuration error, so if you can't repro it, let's assume the problem is somewhere on my end. FWIW, I took the 2.2 release from the website, the GCC 4.2 release from the website, and tried to follow the README.LLVM directions (build LLVM 2.2, configure gcc in the obj directory, make and make install), then ran through the hello steps. Only the lli step fails. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Anton Korobeynikov > Sent: Friday, February 15, 2008 3:52 AM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Question on link error > > Hello, Ted > > > __main is supposed to be inside hello.bc, so why cant lli find it? > No, it shouldn't be there. On targets, which lacks init sections (for > example, all win-based, like mingw & cygwin) __main is used to call > static constructors and relevant stuff. > > The call to __main is assembled early in the main routine before the > actual code will be executed. I'll try to look into this problem today. > > -- > WBR, Anton Korobeynikov > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: > 2/14/2008 10:28 AM > > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.6/1280 - Release Date: 2/15/2008 9:00 AM From romixlev at yahoo.com Fri Feb 15 14:01:33 2008 From: romixlev at yahoo.com (Roman Levenstein) Date: Fri, 15 Feb 2008 21:01:33 +0100 (CET) Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting & SubRegisters) In-Reply-To: <8FEC4195-547A-4844-B5C1-4E7E2FB5F2BF@apple.com> Message-ID: <572290.31048.qm@web56312.mail.re3.yahoo.com> Hi Evan, I have a few questions about current implementation of live intervals spilling, which is required for the implementation of Extended Linear Scan algorithm. --- Evan Cheng wrote: > > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: > >>> Evan, > >>> > >>> Can you explain the basic mechanics of the live interval > splitting code? > >>> Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills > >>> and child routines? What is it trying to do? > >> > >> It's splitting live intervals that span multiple basic blocks. > That is, when an interval is spilled, it introduce a single reload per >>> basic block and retarget all the uses to use the result of the > single reload. It does not (yet) split intra-bb intervals. When I look at the code, it seems that when linear scan regalloc decides to spill a given live interval, it calls addIntervalsForSpills. This function would split the original live interval into several intervals according to the principle described by you above. Each of this intervals (split children) then gets a stack slot allocated (and all these split intervals get the same stack slot?) and then those new splitted intervals are added to unhandled set. Thus they get a chance to get physical registers assigned to them, independently. So, actually, they are not quite "spilled" intervals (since they are not really spilled and located in memory) and may get a physical register. Is my understanding of the algorithm correct so far? What I don't quite understand is the following: Why do live intervals with an allocated stack slot should also always have a physical register assigned to them? How should a register allocator decide, which physical register should be used for that? For example, in my version of Sarkar's Extended Linear Scan I sometimes spill the whole live interval. So, I assign a stack slot to it. But LLVM requires also a physical register to be assigned to each such live interval as well. How do I decide which physical register should be taken? Why can't the local spiller or the former rewriteFunction() part of the RegAllocLinearScan find out on their own which of the currently available for allocation physical registers should be taken at a given point for a reload or for a spilling operation for a given spilled live interval? Wouldn't it be more convenient? You just say that the interval is spilled and the rest is done "by magic"? Or may be I'm missing something about how spilling currently works in LLVM? Thanks in advance for any clarification of this issue. -Roman Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go From fernando at CS.UCLA.EDU Fri Feb 15 14:21:08 2008 From: fernando at CS.UCLA.EDU (Fernando Magno Quintao Pereira) Date: Fri, 15 Feb 2008 12:21:08 -0800 (PST) Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting & SubRegisters) In-Reply-To: <572290.31048.qm@web56312.mail.re3.yahoo.com> References: <572290.31048.qm@web56312.mail.re3.yahoo.com> Message-ID: Hi, Roman, maybe I can try to answer this. I think that all boils down to having register to reload spilled values. Once a register is spilled, its live range is split into smaller pieces. These pieces most be contained into registers, and it is the task of the allocator to find these registers. Imagine that you have something like: Before After allocation: allocation: a := 1 a(R1) := 1 // a is assigned to R1 | // store R1 into M1 | | // 'a' is spilled into stack slot M1 | | // assign 'a' to R2, and load M1 into R2 b := a b(Rx) := a(R2) | | | | | // assign 'a' to R3, and load M1 into R3 c := a c(Ry) := a(R3) So, the register is necessary for doing the reloading. Sometimes it is possible to avoid the reloading with instruction folding, but this is not always the case. Also, in the new allocator used in LLVM, I believe that some live ranges may be split into bigger pieces, and this would save some reloads. best, Fernando > When I look at the code, it seems that when linear scan regalloc > decides to spill a given live interval, it calls addIntervalsForSpills. > This function would split the original live interval into several > intervals according to the principle described by you above. Each of > this intervals (split children) then gets a stack slot allocated (and > all these split intervals get the same stack slot?) and then those new > splitted intervals are added to unhandled set. Thus they get a chance > to get physical registers assigned to them, independently. So, > actually, they are not quite "spilled" intervals (since they are not > really spilled and located in memory) and may get a physical register. > Is my understanding of the algorithm correct so far? > > What I don't quite understand is the following: > Why do live intervals with an allocated stack slot should also always > have a physical register assigned to them? How should a register > allocator decide, which physical register should be used for that? > > For example, in my version of Sarkar's Extended Linear Scan I sometimes > spill the whole live interval. So, I assign a stack slot to it. But > LLVM requires also a physical register to be assigned to each such live > interval as well. How do I decide which physical register should be > taken? Why can't the local spiller or the former rewriteFunction() part > of the RegAllocLinearScan find out on their own which of the currently > available for allocation physical registers should be taken at a given > point for a reload or for a spilling operation for a given spilled live > interval? Wouldn't it be more convenient? You just say that the > interval is spilled and the rest is done "by magic"? Or may be I'm > missing something about how spilling currently works in LLVM? > > Thanks in advance for any clarification of this issue. > > -Roman > > > Lesen Sie Ihre E-Mails auf dem Handy. > www.yahoo.de/go > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From loisel at temple.edu Fri Feb 15 14:28:46 2008 From: loisel at temple.edu (Sebastien Loisel) Date: Fri, 15 Feb 2008 15:28:46 -0500 Subject: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47 In-Reply-To: References: Message-ID: Dear LLVMers OK, when I signed up for this mailing list, I asked for a once-daily digest. This is the fourth digest I receive today, and there are about that many each day. The only reason I subscribe to the mailing list is so I can post to it. But I don't need to receive the emails, because I can fully well read them in the archive online, and I certainly don't want to get spammed multiple times daily with the digest. Today, I received issue 44 at 3:01am, issue 45 at 12:37pm, issue 46 at 2:02pm and issue 47 at 3:21pm. Is there a way that I can turn off all delivery of emails from the llvmdev list without unsubscribing? If that's not possible, I'll unsubscribe and then resubscribe when I have something to say, but I just think it would be better if I could turn off the email delivery or something. Sincerely, S?bastien Loisel On Fri, Feb 15, 2008 at 3:21 PM, wrote: > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > or, via email, send a message with subject or body 'help' to > llvmdev-request at cs.uiuc.edu > > You can reach the person managing the list at > llvmdev-owner at cs.uiuc.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of LLVMdev digest..." > > > Today's Topics: > > 1. Re: an llvm-gcc bug (Devang Patel) > 2. Re: an llvm-gcc bug (Chris Lattner) > 3. Re: an llvm-gcc bug (Dale Johannesen) > 4. Re: an llvm-gcc bug (Dale Johannesen) > 5. Re: an llvm-gcc bug (Chris Lattner) > 6. Re: Question on link error (Ted Neward) > 7. LiveInterval spilling (was LiveInterval Splitting & > SubRegisters) (Roman Levenstein) > 8. Re: LiveInterval spilling (was LiveInterval Splitting & > SubRegisters) (Fernando Magno Quintao Pereira) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Feb 2008 11:17:33 -0800 > From: Devang Patel > Subject: Re: [LLVMdev] an llvm-gcc bug > To: LLVM Developers Mailing List > Message-ID: <0C222846-383D-41DD-8229-4858BD1FD3A2 at apple.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > > > > On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > > > >> > >> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > >> > >>>>> Alternatively I can take the Padding bit into account in the > >>>>> StructType::get code somehow. Anyone have a strong opinion? > >>>> > >>>> Shouldn't it be a map from the gcc type to the padding info? > >>>> That said, you can get rid of the padding info as far as I'm > >>>> concerned. However Chris might have a different opinion - I > >>>> think he introduced it. > >>> > >>> I don't think I introduced it (was it Devang?). > >> > >> Yup. PR 1278 > > > > Ok! Can you please fix it to index by GCC type? There is a many to > > one mapping between gcc types and llvm types. > > This is tricky and probably won't work. Padding info is in llvm struct > type and CopyAggregate() is operating on llvm type. There is not any > way to map llvm type back to gcc type. Am I missing something ? > > - > Devang > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 15 Feb 2008 11:21:41 -0800 > From: Chris Lattner > Subject: Re: [LLVMdev] an llvm-gcc bug > To: LLVM Developers Mailing List > Message-ID: <8A9142EB-F978-4CCE-8550-5F805BDFAA07 at nondot.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > >> Ok! Can you please fix it to index by GCC type? There is a many to > >> one mapping between gcc types and llvm types. > > > > This is tricky and probably won't work. Padding info is in llvm struct > > type and CopyAggregate() is operating on llvm type. There is not any > > way to map llvm type back to gcc type. Am I missing something ? > > EmitAggregateCopy has the gcc type. It would be reasonable to have > CopyAggregate walk the GCC type in parallel with the llvm type, at > least in simple cases. In more complex cases, it could give up. > > -Chris > > > ------------------------------ > > Message: 3 > Date: Fri, 15 Feb 2008 11:22:47 -0800 > From: Dale Johannesen > Subject: Re: [LLVMdev] an llvm-gcc bug > To: LLVM Developers Mailing List > Message-ID: <04308F30-2980-4F02-8FF7-E09DD4D0D9C1 at apple.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > > > > > On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > > >> > >> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > >> > >>> > >>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > >>> > >>>>>> Alternatively I can take the Padding bit into account in the > >>>>>> StructType::get code somehow. Anyone have a strong opinion? > >>>>> > >>>>> Shouldn't it be a map from the gcc type to the padding info? > >>>>> That said, you can get rid of the padding info as far as I'm > >>>>> concerned. However Chris might have a different opinion - I > >>>>> think he introduced it. > >>>> > >>>> I don't think I introduced it (was it Devang?). > >>> > >>> Yup. PR 1278 > >> > >> Ok! Can you please fix it to index by GCC type? There is a many to > >> one mapping between gcc types and llvm types. > > > > This is tricky and probably won't work. Padding info is in llvm struct > > type and CopyAggregate() is operating on llvm type. There is not any > > way to map llvm type back to gcc type. Am I missing something ? > > > I don't think so, I have reached the same conclusion. You can pass > the gcc type into CopyAggregate, but it's recursive, and there's no > way to get the gcc type for the fields. You would have to walk the > gcc type in parallel with the llvm type, which at best involves > duplicating a lot of code and is quite error prone. > > > > ------------------------------ > > Message: 4 > Date: Fri, 15 Feb 2008 11:27:42 -0800 > From: Dale Johannesen > Subject: Re: [LLVMdev] an llvm-gcc bug > To: Dale Johannesen > Cc: LLVM Developers Mailing List > Message-ID: <86CE380D-44AB-4035-9E7C-2DCD85308BDA at apple.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 15, 2008, at 11:22 AM, Dale Johannesen wrote: > > > > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > > > >> > >> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > >> > >>> > >>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > >>> > >>>> > >>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > >>>> > >>>>>>> Alternatively I can take the Padding bit into account in the > >>>>>>> StructType::get code somehow. Anyone have a strong opinion? > >>>>>> > >>>>>> Shouldn't it be a map from the gcc type to the padding info? > >>>>>> That said, you can get rid of the padding info as far as I'm > >>>>>> concerned. However Chris might have a different opinion - I > >>>>>> think he introduced it. > >>>>> > >>>>> I don't think I introduced it (was it Devang?). > >>>> > >>>> Yup. PR 1278 > >>> > >>> Ok! Can you please fix it to index by GCC type? There is a many to > >>> one mapping between gcc types and llvm types. > >> > >> This is tricky and probably won't work. Padding info is in llvm > >> struct > >> type and CopyAggregate() is operating on llvm type. There is not any > >> way to map llvm type back to gcc type. Am I missing something ? > > > > > > I don't think so, I have reached the same conclusion. You can pass > > the gcc type into CopyAggregate, but it's recursive, and there's no > > way to get the gcc type for the fields. You would have to walk the > > gcc type in parallel with the llvm type, which at best involves > > duplicating a lot of code and is quite error prone. > > ...but giving up in this case is easy enough, ok, I can do that. > > > > ------------------------------ > > Message: 5 > Date: Fri, 15 Feb 2008 11:39:06 -0800 > From: Chris Lattner > Subject: Re: [LLVMdev] an llvm-gcc bug > To: LLVM Developers Mailing List > Message-ID: <9345E8E7-503D-483F-90DD-1DA6FD64B6F3 at nondot.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 15, 2008, at 11:27 AM, Dale Johannesen wrote: > > >> I don't think so, I have reached the same conclusion. You can pass > >> the gcc type into CopyAggregate, but it's recursive, and there's no > >> way to get the gcc type for the fields. You would have to walk the > >> gcc type in parallel with the llvm type, which at best involves > >> duplicating a lot of code and is quite error prone. > > > > ...but giving up in this case is easy enough, ok, I can do that. > > Cool, thanks Dale! I think it would be reasonable to give up in > nested struct cases, etc. We can always improve it later, and that > will get us the obvious case in PR1278. > > -Chris > > > ------------------------------ > > Message: 6 > Date: Fri, 15 Feb 2008 11:47:47 -0800 > From: "Ted Neward" > Subject: Re: [LLVMdev] Question on link error > To: "'Anton Korobeynikov'" , "'LLVM Developers > Mailing List'" > Message-ID: <017001c8700b$a8172760$f8457620$@com> > Content-Type: text/plain; charset="windows-1250" > > I am *more* than willing to believe it's an environment/configuration > error, > so if you can't repro it, let's assume the problem is somewhere on my end. > > FWIW, I took the 2.2 release from the website, the GCC 4.2 release from > the > website, and tried to follow the README.LLVM directions (build LLVM 2.2, > configure gcc in the obj directory, make and make install), then ran > through > the hello steps. Only the lli step fails. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > > On Behalf Of Anton Korobeynikov > > Sent: Friday, February 15, 2008 3:52 AM > > To: LLVM Developers Mailing List > > Subject: Re: [LLVMdev] Question on link error > > > > Hello, Ted > > > > > __main is supposed to be inside hello.bc, so why can t lli find it? > > No, it shouldn't be there. On targets, which lacks init sections (for > > example, all win-based, like mingw & cygwin) __main is used to call > > static constructors and relevant stuff. > > > > The call to __main is assembled early in the main routine before the > > actual code will be executed. I'll try to look into this problem today. > > > > -- > > WBR, Anton Korobeynikov > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: > > 2/14/2008 10:28 AM > > > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.6/1280 - Release Date: 2/15/2008 > 9:00 AM > > > > > > ------------------------------ > > Message: 7 > Date: Fri, 15 Feb 2008 21:01:33 +0100 (CET) > From: Roman Levenstein > Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting & > SubRegisters) > To: LLVM Developers Mailing List > Message-ID: <572290.31048.qm at web56312.mail.re3.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > Hi Evan, > > I have a few questions about current implementation of live intervals > spilling, which is required for the implementation of Extended Linear > Scan algorithm. > > --- Evan Cheng wrote: > > > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > > >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: > > >>> Evan, > > >>> > > >>> Can you explain the basic mechanics of the live interval > > splitting code? > > >>> Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills > > >>> and child routines? What is it trying to do? > > >> > > >> It's splitting live intervals that span multiple basic blocks. > > That is, when an interval is spilled, it introduce a single reload > per > >>> basic block and retarget all the uses to use the result of the > > single reload. It does not (yet) split intra-bb intervals. > > When I look at the code, it seems that when linear scan regalloc > decides to spill a given live interval, it calls addIntervalsForSpills. > This function would split the original live interval into several > intervals according to the principle described by you above. Each of > this intervals (split children) then gets a stack slot allocated (and > all these split intervals get the same stack slot?) and then those new > splitted intervals are added to unhandled set. Thus they get a chance > to get physical registers assigned to them, independently. So, > actually, they are not quite "spilled" intervals (since they are not > really spilled and located in memory) and may get a physical register. > Is my understanding of the algorithm correct so far? > > What I don't quite understand is the following: > Why do live intervals with an allocated stack slot should also always > have a physical register assigned to them? How should a register > allocator decide, which physical register should be used for that? > > For example, in my version of Sarkar's Extended Linear Scan I sometimes > spill the whole live interval. So, I assign a stack slot to it. But > LLVM requires also a physical register to be assigned to each such live > interval as well. How do I decide which physical register should be > taken? Why can't the local spiller or the former rewriteFunction() part > of the RegAllocLinearScan find out on their own which of the currently > available for allocation physical registers should be taken at a given > point for a reload or for a spilling operation for a given spilled live > interval? Wouldn't it be more convenient? You just say that the > interval is spilled and the rest is done "by magic"? Or may be I'm > missing something about how spilling currently works in LLVM? > > Thanks in advance for any clarification of this issue. > > -Roman > > > Lesen Sie Ihre E-Mails auf dem Handy. > www.yahoo.de/go > > > ------------------------------ > > Message: 8 > Date: Fri, 15 Feb 2008 12:21:08 -0800 (PST) > From: Fernando Magno Quintao Pereira > Subject: Re: [LLVMdev] LiveInterval spilling (was LiveInterval > Splitting & SubRegisters) > To: LLVM Developers Mailing List > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi, Roman, > > maybe I can try to answer this. I think that all boils down to having > register to reload spilled values. Once a register is spilled, its live > range is split into smaller pieces. These pieces most be contained into > registers, and it is the task of the allocator to find these registers. > Imagine that you have something like: > > Before After > allocation: allocation: > a := 1 a(R1) := 1 // a is assigned to R1 > | // store R1 into M1 > | > | // 'a' is spilled into stack slot M1 > | > | // assign 'a' to R2, and load M1 into R2 > b := a b(Rx) := a(R2) > | > | > | > | > | // assign 'a' to R3, and load M1 into R3 > c := a c(Ry) := a(R3) > > So, the register is necessary for doing the reloading. Sometimes it is > possible to avoid the reloading with instruction folding, but this is not > always the case. Also, in the new allocator used in LLVM, I believe that > some live ranges may be split into bigger pieces, and this would save some > reloads. > > best, > > Fernando > > > When I look at the code, it seems that when linear scan > regalloc > > decides to spill a given live interval, it calls addIntervalsForSpills. > > This function would split the original live interval into several > > intervals according to the principle described by you above. Each of > > this intervals (split children) then gets a stack slot allocated (and > > all these split intervals get the same stack slot?) and then those new > > splitted intervals are added to unhandled set. Thus they get a chance > > to get physical registers assigned to them, independently. So, > > actually, they are not quite "spilled" intervals (since they are not > > really spilled and located in memory) and may get a physical register. > > Is my understanding of the algorithm correct so far? > > > > What I don't quite understand is the following: > > Why do live intervals with an allocated stack slot should also always > > have a physical register assigned to them? How should a register > > allocator decide, which physical register should be used for that? > > > > For example, in my version of Sarkar's Extended Linear Scan I sometimes > > spill the whole live interval. So, I assign a stack slot to it. But > > LLVM requires also a physical register to be assigned to each such live > > interval as well. How do I decide which physical register should be > > taken? Why can't the local spiller or the former rewriteFunction() part > > of the RegAllocLinearScan find out on their own which of the currently > > available for allocation physical registers should be taken at a given > > point for a reload or for a spilling operation for a given spilled live > > interval? Wouldn't it be more convenient? You just say that the > > interval is spilled and the rest is done "by magic"? Or may be I'm > > missing something about how spilling currently works in LLVM? > > > > Thanks in advance for any clarification of this issue. > > > > -Roman > > > > > > Lesen Sie Ihre E-Mails auf dem Handy. > > www.yahoo.de/go > > _______________________________________________ > > 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 44, Issue 47 > *************************************** > -- S?bastien Loisel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/a88fb674/attachment-0001.html From loisel at temple.edu Fri Feb 15 14:31:34 2008 From: loisel at temple.edu (Sebastien Loisel) Date: Fri, 15 Feb 2008 15:31:34 -0500 Subject: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47 Message-ID: Here's issue 48. I'm guessing I'm going to get issue 49 as soon as I hit send... On Fri, Feb 15, 2008 at 3:28 PM, wrote: > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > or, via email, send a message with subject or body 'help' to > llvmdev-request at cs.uiuc.edu > > You can reach the person managing the list at > llvmdev-owner at cs.uiuc.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of LLVMdev digest..." > > > Today's Topics: > > 1. Re: LLVMdev Digest, Vol 44, Issue 47 (Sebastien Loisel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Feb 2008 15:28:46 -0500 > From: "Sebastien Loisel" > Subject: Re: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47 > To: llvmdev at cs.uiuc.edu > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Dear LLVMers > > OK, when I signed up for this mailing list, I asked for a once-daily > digest. > > This is the fourth digest I receive today, and there are about that many > each day. > > The only reason I subscribe to the mailing list is so I can post to it. > But > I don't need to receive the emails, because I can fully well read them in > the archive online, and I certainly don't want to get spammed multiple > times > daily with the digest. Today, I received issue 44 at 3:01am, issue 45 at > 12:37pm, issue 46 at 2:02pm and issue 47 at 3:21pm. > > Is there a way that I can turn off all delivery of emails from the llvmdev > list without unsubscribing? If that's not possible, I'll unsubscribe and > then resubscribe when I have something to say, but I just think it would > be > better if I could turn off the email delivery or something. > > Sincerely, > > S?bastien Loisel > > On Fri, Feb 15, 2008 at 3:21 PM, wrote: > > > Send LLVMdev mailing list submissions to > > llvmdev at cs.uiuc.edu > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > or, via email, send a message with subject or body 'help' to > > llvmdev-request at cs.uiuc.edu > > > > You can reach the person managing the list at > > llvmdev-owner at cs.uiuc.edu > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of LLVMdev digest..." > > > > > > Today's Topics: > > > > 1. Re: an llvm-gcc bug (Devang Patel) > > 2. Re: an llvm-gcc bug (Chris Lattner) > > 3. Re: an llvm-gcc bug (Dale Johannesen) > > 4. Re: an llvm-gcc bug (Dale Johannesen) > > 5. Re: an llvm-gcc bug (Chris Lattner) > > 6. Re: Question on link error (Ted Neward) > > 7. LiveInterval spilling (was LiveInterval Splitting & > > SubRegisters) (Roman Levenstein) > > 8. Re: LiveInterval spilling (was LiveInterval Splitting & > > SubRegisters) (Fernando Magno Quintao Pereira) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Fri, 15 Feb 2008 11:17:33 -0800 > > From: Devang Patel > > Subject: Re: [LLVMdev] an llvm-gcc bug > > To: LLVM Developers Mailing List > > Message-ID: <0C222846-383D-41DD-8229-4858BD1FD3A2 at apple.com> > > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > > > > On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > > > > > > > On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > > > > > >> > > >> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > > >> > > >>>>> Alternatively I can take the Padding bit into account in the > > >>>>> StructType::get code somehow. Anyone have a strong opinion? > > >>>> > > >>>> Shouldn't it be a map from the gcc type to the padding info? > > >>>> That said, you can get rid of the padding info as far as I'm > > >>>> concerned. However Chris might have a different opinion - I > > >>>> think he introduced it. > > >>> > > >>> I don't think I introduced it (was it Devang?). > > >> > > >> Yup. PR 1278 > > > > > > Ok! Can you please fix it to index by GCC type? There is a many to > > > one mapping between gcc types and llvm types. > > > > This is tricky and probably won't work. Padding info is in llvm struct > > type and CopyAggregate() is operating on llvm type. There is not any > > way to map llvm type back to gcc type. Am I missing something ? > > > > - > > Devang > > > > > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Fri, 15 Feb 2008 11:21:41 -0800 > > From: Chris Lattner > > Subject: Re: [LLVMdev] an llvm-gcc bug > > To: LLVM Developers Mailing List > > Message-ID: <8A9142EB-F978-4CCE-8550-5F805BDFAA07 at nondot.org> > > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > > >> Ok! Can you please fix it to index by GCC type? There is a many to > > >> one mapping between gcc types and llvm types. > > > > > > This is tricky and probably won't work. Padding info is in llvm struct > > > type and CopyAggregate() is operating on llvm type. There is not any > > > way to map llvm type back to gcc type. Am I missing something ? > > > > EmitAggregateCopy has the gcc type. It would be reasonable to have > > CopyAggregate walk the GCC type in parallel with the llvm type, at > > least in simple cases. In more complex cases, it could give up. > > > > -Chris > > > > > > ------------------------------ > > > > Message: 3 > > Date: Fri, 15 Feb 2008 11:22:47 -0800 > > From: Dale Johannesen > > Subject: Re: [LLVMdev] an llvm-gcc bug > > To: LLVM Developers Mailing List > > Message-ID: <04308F30-2980-4F02-8FF7-E09DD4D0D9C1 at apple.com> > > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > > > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > > > > > > > > On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > > > > >> > > >> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > > >> > > >>> > > >>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > > >>> > > >>>>>> Alternatively I can take the Padding bit into account in the > > >>>>>> StructType::get code somehow. Anyone have a strong opinion? > > >>>>> > > >>>>> Shouldn't it be a map from the gcc type to the padding info? > > >>>>> That said, you can get rid of the padding info as far as I'm > > >>>>> concerned. However Chris might have a different opinion - I > > >>>>> think he introduced it. > > >>>> > > >>>> I don't think I introduced it (was it Devang?). > > >>> > > >>> Yup. PR 1278 > > >> > > >> Ok! Can you please fix it to index by GCC type? There is a many to > > >> one mapping between gcc types and llvm types. > > > > > > This is tricky and probably won't work. Padding info is in llvm struct > > > type and CopyAggregate() is operating on llvm type. There is not any > > > way to map llvm type back to gcc type. Am I missing something ? > > > > > > I don't think so, I have reached the same conclusion. You can pass > > the gcc type into CopyAggregate, but it's recursive, and there's no > > way to get the gcc type for the fields. You would have to walk the > > gcc type in parallel with the llvm type, which at best involves > > duplicating a lot of code and is quite error prone. > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Fri, 15 Feb 2008 11:27:42 -0800 > > From: Dale Johannesen > > Subject: Re: [LLVMdev] an llvm-gcc bug > > To: Dale Johannesen > > Cc: LLVM Developers Mailing List > > Message-ID: <86CE380D-44AB-4035-9E7C-2DCD85308BDA at apple.com> > > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > > > > On Feb 15, 2008, at 11:22 AM, Dale Johannesen wrote: > > > > > > > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > > > > > >> > > >> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > >> > > >>> > > >>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > > >>> > > >>>> > > >>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > > >>>> > > >>>>>>> Alternatively I can take the Padding bit into account in the > > >>>>>>> StructType::get code somehow. Anyone have a strong opinion? > > >>>>>> > > >>>>>> Shouldn't it be a map from the gcc type to the padding info? > > >>>>>> That said, you can get rid of the padding info as far as I'm > > >>>>>> concerned. However Chris might have a different opinion - I > > >>>>>> think he introduced it. > > >>>>> > > >>>>> I don't think I introduced it (was it Devang?). > > >>>> > > >>>> Yup. PR 1278 > > >>> > > >>> Ok! Can you please fix it to index by GCC type? There is a many to > > >>> one mapping between gcc types and llvm types. > > >> > > >> This is tricky and probably won't work. Padding info is in llvm > > >> struct > > >> type and CopyAggregate() is operating on llvm type. There is not any > > >> way to map llvm type back to gcc type. Am I missing something ? > > > > > > > > > I don't think so, I have reached the same conclusion. You can pass > > > the gcc type into CopyAggregate, but it's recursive, and there's no > > > way to get the gcc type for the fields. You would have to walk the > > > gcc type in parallel with the llvm type, which at best involves > > > duplicating a lot of code and is quite error prone. > > > > ...but giving up in this case is easy enough, ok, I can do that. > > > > > > > > ------------------------------ > > > > Message: 5 > > Date: Fri, 15 Feb 2008 11:39:06 -0800 > > From: Chris Lattner > > Subject: Re: [LLVMdev] an llvm-gcc bug > > To: LLVM Developers Mailing List > > Message-ID: <9345E8E7-503D-483F-90DD-1DA6FD64B6F3 at nondot.org> > > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > > > > On Feb 15, 2008, at 11:27 AM, Dale Johannesen wrote: > > > > >> I don't think so, I have reached the same conclusion. You can pass > > >> the gcc type into CopyAggregate, but it's recursive, and there's no > > >> way to get the gcc type for the fields. You would have to walk the > > >> gcc type in parallel with the llvm type, which at best involves > > >> duplicating a lot of code and is quite error prone. > > > > > > ...but giving up in this case is easy enough, ok, I can do that. > > > > Cool, thanks Dale! I think it would be reasonable to give up in > > nested struct cases, etc. We can always improve it later, and that > > will get us the obvious case in PR1278. > > > > -Chris > > > > > > ------------------------------ > > > > Message: 6 > > Date: Fri, 15 Feb 2008 11:47:47 -0800 > > From: "Ted Neward" > > Subject: Re: [LLVMdev] Question on link error > > To: "'Anton Korobeynikov'" , "'LLVM Developers > > Mailing List'" > > Message-ID: <017001c8700b$a8172760$f8457620$@com> > > Content-Type: text/plain; charset="windows-1250" > > > > I am *more* than willing to believe it's an environment/configuration > > error, > > so if you can't repro it, let's assume the problem is somewhere on my > end. > > > > FWIW, I took the 2.2 release from the website, the GCC 4.2 release from > > the > > website, and tried to follow the README.LLVM directions (build LLVM 2.2, > > configure gcc in the obj directory, make and make install), then ran > > through > > the hello steps. Only the lli step fails. > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > > > -----Original Message----- > > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > > > On Behalf Of Anton Korobeynikov > > > Sent: Friday, February 15, 2008 3:52 AM > > > To: LLVM Developers Mailing List > > > Subject: Re: [LLVMdev] Question on link error > > > > > > Hello, Ted > > > > > > > __main is supposed to be inside hello.bc, so why can t lli find it? > > > No, it shouldn't be there. On targets, which lacks init sections (for > > > example, all win-based, like mingw & cygwin) __main is used to call > > > static constructors and relevant stuff. > > > > > > The call to __main is assembled early in the main routine before the > > > actual code will be executed. I'll try to look into this problem > today. > > > > > > -- > > > WBR, Anton Korobeynikov > > > > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: > > > 2/14/2008 10:28 AM > > > > > > > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.6/1280 - Release Date: > 2/15/2008 > > 9:00 AM > > > > > > > > > > > > ------------------------------ > > > > Message: 7 > > Date: Fri, 15 Feb 2008 21:01:33 +0100 (CET) > > From: Roman Levenstein > > Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting & > > SubRegisters) > > To: LLVM Developers Mailing List > > Message-ID: <572290.31048.qm at web56312.mail.re3.yahoo.com> > > Content-Type: text/plain; charset=iso-8859-1 > > > > Hi Evan, > > > > I have a few questions about current implementation of live intervals > > spilling, which is required for the implementation of Extended Linear > > Scan algorithm. > > > > --- Evan Cheng wrote: > > > > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > > > >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: > > > >>> Evan, > > > >>> > > > >>> Can you explain the basic mechanics of the live interval > > > splitting code? > > > >>> Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills > > > >>> and child routines? What is it trying to do? > > > >> > > > >> It's splitting live intervals that span multiple basic blocks. > > > That is, when an interval is spilled, it introduce a single reload > > per > > >>> basic block and retarget all the uses to use the result of the > > > single reload. It does not (yet) split intra-bb intervals. > > > > When I look at the code, it seems that when linear scan regalloc > > decides to spill a given live interval, it calls addIntervalsForSpills. > > This function would split the original live interval into several > > intervals according to the principle described by you above. Each of > > this intervals (split children) then gets a stack slot allocated (and > > all these split intervals get the same stack slot?) and then those new > > splitted intervals are added to unhandled set. Thus they get a chance > > to get physical registers assigned to them, independently. So, > > actually, they are not quite "spilled" intervals (since they are not > > really spilled and located in memory) and may get a physical register. > > Is my understanding of the algorithm correct so far? > > > > What I don't quite understand is the following: > > Why do live intervals with an allocated stack slot should also always > > have a physical register assigned to them? How should a register > > allocator decide, which physical register should be used for that? > > > > For example, in my version of Sarkar's Extended Linear Scan I sometimes > > spill the whole live interval. So, I assign a stack slot to it. But > > LLVM requires also a physical register to be assigned to each such live > > interval as well. How do I decide which physical register should be > > taken? Why can't the local spiller or the former rewriteFunction() part > > of the RegAllocLinearScan find out on their own which of the currently > > available for allocation physical registers should be taken at a given > > point for a reload or for a spilling operation for a given spilled live > > interval? Wouldn't it be more convenient? You just say that the > > interval is spilled and the rest is done "by magic"? Or may be I'm > > missing something about how spilling currently works in LLVM? > > > > Thanks in advance for any clarification of this issue. > > > > -Roman > > > > > > Lesen Sie Ihre E-Mails auf dem Handy. > > www.yahoo.de/go > > > > > > ------------------------------ > > > > Message: 8 > > Date: Fri, 15 Feb 2008 12:21:08 -0800 (PST) > > From: Fernando Magno Quintao Pereira > > Subject: Re: [LLVMdev] LiveInterval spilling (was LiveInterval > > Splitting & SubRegisters) > > To: LLVM Developers Mailing List > > Message-ID: > > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > > > > Hi, Roman, > > > > maybe I can try to answer this. I think that all boils down to > having > > register to reload spilled values. Once a register is spilled, its live > > range is split into smaller pieces. These pieces most be contained into > > registers, and it is the task of the allocator to find these registers. > > Imagine that you have something like: > > > > Before After > > allocation: allocation: > > a := 1 a(R1) := 1 // a is assigned to R1 > > | // store R1 into M1 > > | > > | // 'a' is spilled into stack slot M1 > > | > > | // assign 'a' to R2, and load M1 into R2 > > b := a b(Rx) := a(R2) > > | > > | > > | > > | > > | // assign 'a' to R3, and load M1 into R3 > > c := a c(Ry) := a(R3) > > > > So, the register is necessary for doing the reloading. Sometimes it is > > possible to avoid the reloading with instruction folding, but this is > not > > always the case. Also, in the new allocator used in LLVM, I believe that > > some live ranges may be split into bigger pieces, and this would save > some > > reloads. > > > > best, > > > > Fernando > > > > > When I look at the code, it seems that when linear scan > > regalloc > > > decides to spill a given live interval, it calls > addIntervalsForSpills. > > > This function would split the original live interval into several > > > intervals according to the principle described by you above. Each of > > > this intervals (split children) then gets a stack slot allocated (and > > > all these split intervals get the same stack slot?) and then those new > > > splitted intervals are added to unhandled set. Thus they get a chance > > > to get physical registers assigned to them, independently. So, > > > actually, they are not quite "spilled" intervals (since they are not > > > really spilled and located in memory) and may get a physical register. > > > Is my understanding of the algorithm correct so far? > > > > > > What I don't quite understand is the following: > > > Why do live intervals with an allocated stack slot should also always > > > have a physical register assigned to them? How should a register > > > allocator decide, which physical register should be used for that? > > > > > > For example, in my version of Sarkar's Extended Linear Scan I > sometimes > > > spill the whole live interval. So, I assign a stack slot to it. But > > > LLVM requires also a physical register to be assigned to each such > live > > > interval as well. How do I decide which physical register should be > > > taken? Why can't the local spiller or the former rewriteFunction() > part > > > of the RegAllocLinearScan find out on their own which of the currently > > > available for allocation physical registers should be taken at a given > > > point for a reload or for a spilling operation for a given spilled > live > > > interval? Wouldn't it be more convenient? You just say that the > > > interval is spilled and the rest is done "by magic"? Or may be I'm > > > missing something about how spilling currently works in LLVM? > > > > > > Thanks in advance for any clarification of this issue. > > > > > > -Roman > > > > > > > > > Lesen Sie Ihre E-Mails auf dem Handy. > > > www.yahoo.de/go > > > _______________________________________________ > > > 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 44, Issue 47 > > *************************************** > > > > > > -- > S?bastien Loisel > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/a88fb674/attachment.html > > ------------------------------ > > _______________________________________________ > LLVMdev mailing list > LLVMdev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > End of LLVMdev Digest, Vol 44, Issue 48 > *************************************** > -- S?bastien Loisel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/05ce4791/attachment-0001.html From tonic at nondot.org Fri Feb 15 14:48:35 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Fri, 15 Feb 2008 12:48:35 -0800 (PST) Subject: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47 In-Reply-To: References: Message-ID: > Is there a way that I can turn off all delivery of emails from the llvmdev > list without unsubscribing? If that's not possible, I'll unsubscribe and > then resubscribe when I have something to say, but I just think it would be > better if I could turn off the email delivery or something. Yes, edit your mailman subscription options. http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -Tanya > > Sincerely, > > S?bastien Loisel > > On Fri, Feb 15, 2008 at 3:21 PM, wrote: > >> Send LLVMdev mailing list submissions to >> llvmdev at cs.uiuc.edu >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> or, via email, send a message with subject or body 'help' to >> llvmdev-request at cs.uiuc.edu >> >> You can reach the person managing the list at >> llvmdev-owner at cs.uiuc.edu >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of LLVMdev digest..." >> >> >> Today's Topics: >> >> 1. Re: an llvm-gcc bug (Devang Patel) >> 2. Re: an llvm-gcc bug (Chris Lattner) >> 3. Re: an llvm-gcc bug (Dale Johannesen) >> 4. Re: an llvm-gcc bug (Dale Johannesen) >> 5. Re: an llvm-gcc bug (Chris Lattner) >> 6. Re: Question on link error (Ted Neward) >> 7. LiveInterval spilling (was LiveInterval Splitting & >> SubRegisters) (Roman Levenstein) >> 8. Re: LiveInterval spilling (was LiveInterval Splitting & >> SubRegisters) (Fernando Magno Quintao Pereira) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 15 Feb 2008 11:17:33 -0800 >> From: Devang Patel >> Subject: Re: [LLVMdev] an llvm-gcc bug >> To: LLVM Developers Mailing List >> Message-ID: <0C222846-383D-41DD-8229-4858BD1FD3A2 at apple.com> >> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >> >> >> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: >> >>> >>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >>> >>>> >>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>>> >>>>>>> Alternatively I can take the Padding bit into account in the >>>>>>> StructType::get code somehow. Anyone have a strong opinion? >>>>>> >>>>>> Shouldn't it be a map from the gcc type to the padding info? >>>>>> That said, you can get rid of the padding info as far as I'm >>>>>> concerned. However Chris might have a different opinion - I >>>>>> think he introduced it. >>>>> >>>>> I don't think I introduced it (was it Devang?). >>>> >>>> Yup. PR 1278 >>> >>> Ok! Can you please fix it to index by GCC type? There is a many to >>> one mapping between gcc types and llvm types. >> >> This is tricky and probably won't work. Padding info is in llvm struct >> type and CopyAggregate() is operating on llvm type. There is not any >> way to map llvm type back to gcc type. Am I missing something ? >> >> - >> Devang >> >> >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 15 Feb 2008 11:21:41 -0800 >> From: Chris Lattner >> Subject: Re: [LLVMdev] an llvm-gcc bug >> To: LLVM Developers Mailing List >> Message-ID: <8A9142EB-F978-4CCE-8550-5F805BDFAA07 at nondot.org> >> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >> >> On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: >>>> Ok! Can you please fix it to index by GCC type? There is a many to >>>> one mapping between gcc types and llvm types. >>> >>> This is tricky and probably won't work. Padding info is in llvm struct >>> type and CopyAggregate() is operating on llvm type. There is not any >>> way to map llvm type back to gcc type. Am I missing something ? >> >> EmitAggregateCopy has the gcc type. It would be reasonable to have >> CopyAggregate walk the GCC type in parallel with the llvm type, at >> least in simple cases. In more complex cases, it could give up. >> >> -Chris >> >> >> ------------------------------ >> >> Message: 3 >> Date: Fri, 15 Feb 2008 11:22:47 -0800 >> From: Dale Johannesen >> Subject: Re: [LLVMdev] an llvm-gcc bug >> To: LLVM Developers Mailing List >> Message-ID: <04308F30-2980-4F02-8FF7-E09DD4D0D9C1 at apple.com> >> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >> >> >> On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: >> >>> >>> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: >>> >>>> >>>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >>>> >>>>> >>>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>>>> >>>>>>>> Alternatively I can take the Padding bit into account in the >>>>>>>> StructType::get code somehow. Anyone have a strong opinion? >>>>>>> >>>>>>> Shouldn't it be a map from the gcc type to the padding info? >>>>>>> That said, you can get rid of the padding info as far as I'm >>>>>>> concerned. However Chris might have a different opinion - I >>>>>>> think he introduced it. >>>>>> >>>>>> I don't think I introduced it (was it Devang?). >>>>> >>>>> Yup. PR 1278 >>>> >>>> Ok! Can you please fix it to index by GCC type? There is a many to >>>> one mapping between gcc types and llvm types. >>> >>> This is tricky and probably won't work. Padding info is in llvm struct >>> type and CopyAggregate() is operating on llvm type. There is not any >>> way to map llvm type back to gcc type. Am I missing something ? >> >> >> I don't think so, I have reached the same conclusion. You can pass >> the gcc type into CopyAggregate, but it's recursive, and there's no >> way to get the gcc type for the fields. You would have to walk the >> gcc type in parallel with the llvm type, which at best involves >> duplicating a lot of code and is quite error prone. >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 15 Feb 2008 11:27:42 -0800 >> From: Dale Johannesen >> Subject: Re: [LLVMdev] an llvm-gcc bug >> To: Dale Johannesen >> Cc: LLVM Developers Mailing List >> Message-ID: <86CE380D-44AB-4035-9E7C-2DCD85308BDA at apple.com> >> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >> >> >> On Feb 15, 2008, at 11:22 AM, Dale Johannesen wrote: >> >>> >>> On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: >>> >>>> >>>> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: >>>> >>>>> >>>>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >>>>> >>>>>> >>>>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>>>>> >>>>>>>>> Alternatively I can take the Padding bit into account in the >>>>>>>>> StructType::get code somehow. Anyone have a strong opinion? >>>>>>>> >>>>>>>> Shouldn't it be a map from the gcc type to the padding info? >>>>>>>> That said, you can get rid of the padding info as far as I'm >>>>>>>> concerned. However Chris might have a different opinion - I >>>>>>>> think he introduced it. >>>>>>> >>>>>>> I don't think I introduced it (was it Devang?). >>>>>> >>>>>> Yup. PR 1278 >>>>> >>>>> Ok! Can you please fix it to index by GCC type? There is a many to >>>>> one mapping between gcc types and llvm types. >>>> >>>> This is tricky and probably won't work. Padding info is in llvm >>>> struct >>>> type and CopyAggregate() is operating on llvm type. There is not any >>>> way to map llvm type back to gcc type. Am I missing something ? >>> >>> >>> I don't think so, I have reached the same conclusion. You can pass >>> the gcc type into CopyAggregate, but it's recursive, and there's no >>> way to get the gcc type for the fields. You would have to walk the >>> gcc type in parallel with the llvm type, which at best involves >>> duplicating a lot of code and is quite error prone. >> >> ...but giving up in this case is easy enough, ok, I can do that. >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Fri, 15 Feb 2008 11:39:06 -0800 >> From: Chris Lattner >> Subject: Re: [LLVMdev] an llvm-gcc bug >> To: LLVM Developers Mailing List >> Message-ID: <9345E8E7-503D-483F-90DD-1DA6FD64B6F3 at nondot.org> >> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >> >> >> On Feb 15, 2008, at 11:27 AM, Dale Johannesen wrote: >> >>>> I don't think so, I have reached the same conclusion. You can pass >>>> the gcc type into CopyAggregate, but it's recursive, and there's no >>>> way to get the gcc type for the fields. You would have to walk the >>>> gcc type in parallel with the llvm type, which at best involves >>>> duplicating a lot of code and is quite error prone. >>> >>> ...but giving up in this case is easy enough, ok, I can do that. >> >> Cool, thanks Dale! I think it would be reasonable to give up in >> nested struct cases, etc. We can always improve it later, and that >> will get us the obvious case in PR1278. >> >> -Chris >> >> >> ------------------------------ >> >> Message: 6 >> Date: Fri, 15 Feb 2008 11:47:47 -0800 >> From: "Ted Neward" >> Subject: Re: [LLVMdev] Question on link error >> To: "'Anton Korobeynikov'" , "'LLVM Developers >> Mailing List'" >> Message-ID: <017001c8700b$a8172760$f8457620$@com> >> Content-Type: text/plain; charset="windows-1250" >> >> I am *more* than willing to believe it's an environment/configuration >> error, >> so if you can't repro it, let's assume the problem is somewhere on my end. >> >> FWIW, I took the 2.2 release from the website, the GCC 4.2 release from >> the >> website, and tried to follow the README.LLVM directions (build LLVM 2.2, >> configure gcc in the obj directory, make and make install), then ran >> through >> the hello steps. Only the lli step fails. >> >> Ted Neward >> Java, .NET, XML Services >> Consulting, Teaching, Speaking, Writing >> http://www.tedneward.com >> >> >>> -----Original Message----- >>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >>> On Behalf Of Anton Korobeynikov >>> Sent: Friday, February 15, 2008 3:52 AM >>> To: LLVM Developers Mailing List >>> Subject: Re: [LLVMdev] Question on link error >>> >>> Hello, Ted >>> >>>> __main is supposed to be inside hello.bc, so why can t lli find it? >>> No, it shouldn't be there. On targets, which lacks init sections (for >>> example, all win-based, like mingw & cygwin) __main is used to call >>> static constructors and relevant stuff. >>> >>> The call to __main is assembled early in the main routine before the >>> actual code will be executed. I'll try to look into this problem today. >>> >>> -- >>> WBR, Anton Korobeynikov >>> >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: >>> 2/14/2008 10:28 AM >>> >>> >> >> No virus found in this outgoing message. >> Checked by AVG Free Edition. >> Version: 7.5.516 / Virus Database: 269.20.6/1280 - Release Date: 2/15/2008 >> 9:00 AM >> >> >> >> >> >> ------------------------------ >> >> Message: 7 >> Date: Fri, 15 Feb 2008 21:01:33 +0100 (CET) >> From: Roman Levenstein >> Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting & >> SubRegisters) >> To: LLVM Developers Mailing List >> Message-ID: <572290.31048.qm at web56312.mail.re3.yahoo.com> >> Content-Type: text/plain; charset=iso-8859-1 >> >> Hi Evan, >> >> I have a few questions about current implementation of live intervals >> spilling, which is required for the implementation of Extended Linear >> Scan algorithm. >> >> --- Evan Cheng wrote: >>>> On Wednesday 23 January 2008 02:01, Evan Cheng wrote: >>>>> On Jan 22, 2008, at 12:23 PM, David Greene wrote: >>>>>> Evan, >>>>>> >>>>>> Can you explain the basic mechanics of the live interval >>> splitting code? >>>>>> Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills >>>>>> and child routines? What is it trying to do? >>>>> >>>>> It's splitting live intervals that span multiple basic blocks. >>> That is, when an interval is spilled, it introduce a single reload >> per >>>>> basic block and retarget all the uses to use the result of the >>> single reload. It does not (yet) split intra-bb intervals. >> >> When I look at the code, it seems that when linear scan regalloc >> decides to spill a given live interval, it calls addIntervalsForSpills. >> This function would split the original live interval into several >> intervals according to the principle described by you above. Each of >> this intervals (split children) then gets a stack slot allocated (and >> all these split intervals get the same stack slot?) and then those new >> splitted intervals are added to unhandled set. Thus they get a chance >> to get physical registers assigned to them, independently. So, >> actually, they are not quite "spilled" intervals (since they are not >> really spilled and located in memory) and may get a physical register. >> Is my understanding of the algorithm correct so far? >> >> What I don't quite understand is the following: >> Why do live intervals with an allocated stack slot should also always >> have a physical register assigned to them? How should a register >> allocator decide, which physical register should be used for that? >> >> For example, in my version of Sarkar's Extended Linear Scan I sometimes >> spill the whole live interval. So, I assign a stack slot to it. But >> LLVM requires also a physical register to be assigned to each such live >> interval as well. How do I decide which physical register should be >> taken? Why can't the local spiller or the former rewriteFunction() part >> of the RegAllocLinearScan find out on their own which of the currently >> available for allocation physical registers should be taken at a given >> point for a reload or for a spilling operation for a given spilled live >> interval? Wouldn't it be more convenient? You just say that the >> interval is spilled and the rest is done "by magic"? Or may be I'm >> missing something about how spilling currently works in LLVM? >> >> Thanks in advance for any clarification of this issue. >> >> -Roman >> >> >> Lesen Sie Ihre E-Mails auf dem Handy. >> www.yahoo.de/go >> >> >> ------------------------------ >> >> Message: 8 >> Date: Fri, 15 Feb 2008 12:21:08 -0800 (PST) >> From: Fernando Magno Quintao Pereira >> Subject: Re: [LLVMdev] LiveInterval spilling (was LiveInterval >> Splitting & SubRegisters) >> To: LLVM Developers Mailing List >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> >> Hi, Roman, >> >> maybe I can try to answer this. I think that all boils down to having >> register to reload spilled values. Once a register is spilled, its live >> range is split into smaller pieces. These pieces most be contained into >> registers, and it is the task of the allocator to find these registers. >> Imagine that you have something like: >> >> Before After >> allocation: allocation: >> a := 1 a(R1) := 1 // a is assigned to R1 >> | // store R1 into M1 >> | >> | // 'a' is spilled into stack slot M1 >> | >> | // assign 'a' to R2, and load M1 into R2 >> b := a b(Rx) := a(R2) >> | >> | >> | >> | >> | // assign 'a' to R3, and load M1 into R3 >> c := a c(Ry) := a(R3) >> >> So, the register is necessary for doing the reloading. Sometimes it is >> possible to avoid the reloading with instruction folding, but this is not >> always the case. Also, in the new allocator used in LLVM, I believe that >> some live ranges may be split into bigger pieces, and this would save some >> reloads. >> >> best, >> >> Fernando >> >>> When I look at the code, it seems that when linear scan >> regalloc >>> decides to spill a given live interval, it calls addIntervalsForSpills. >>> This function would split the original live interval into several >>> intervals according to the principle described by you above. Each of >>> this intervals (split children) then gets a stack slot allocated (and >>> all these split intervals get the same stack slot?) and then those new >>> splitted intervals are added to unhandled set. Thus they get a chance >>> to get physical registers assigned to them, independently. So, >>> actually, they are not quite "spilled" intervals (since they are not >>> really spilled and located in memory) and may get a physical register. >>> Is my understanding of the algorithm correct so far? >>> >>> What I don't quite understand is the following: >>> Why do live intervals with an allocated stack slot should also always >>> have a physical register assigned to them? How should a register >>> allocator decide, which physical register should be used for that? >>> >>> For example, in my version of Sarkar's Extended Linear Scan I sometimes >>> spill the whole live interval. So, I assign a stack slot to it. But >>> LLVM requires also a physical register to be assigned to each such live >>> interval as well. How do I decide which physical register should be >>> taken? Why can't the local spiller or the former rewriteFunction() part >>> of the RegAllocLinearScan find out on their own which of the currently >>> available for allocation physical registers should be taken at a given >>> point for a reload or for a spilling operation for a given spilled live >>> interval? Wouldn't it be more convenient? You just say that the >>> interval is spilled and the rest is done "by magic"? Or may be I'm >>> missing something about how spilling currently works in LLVM? >>> >>> Thanks in advance for any clarification of this issue. >>> >>> -Roman >>> >>> >>> Lesen Sie Ihre E-Mails auf dem Handy. >>> www.yahoo.de/go >>> _______________________________________________ >>> 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 44, Issue 47 >> *************************************** >> > > > > From sabre at nondot.org Fri Feb 15 14:35:56 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 12:35:56 -0800 Subject: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47 In-Reply-To: References: Message-ID: <571FEF8A-87B2-4A6F-ADC9-D91A9498A3EE@nondot.org> On Feb 15, 2008, at 12:28 PM, Sebastien Loisel wrote: > Dear LLVMers > > OK, when I signed up for this mailing list, I asked for a once-daily > digest. > > This is the fourth digest I receive today, and there are about that > many each day. > > The only reason I subscribe to the mailing list is so I can post to > it. But I don't need to receive the emails, because I can fully well > read them in the archive online, and I certainly don't want to get > spammed multiple times daily with the digest. Today, I received > issue 44 at 3:01am, issue 45 at 12:37pm, issue 46 at 2:02pm and > issue 47 at 3:21pm. > > Is there a way that I can turn off all delivery of emails from the > llvmdev list without unsubscribing? If that's not possible, I'll > unsubscribe and then resubscribe when I have something to say, but I > just think it would be better if I could turn off the email delivery > or something. You don't need to be subscribed to post. The first post to the list is moderated, that is all. -Chris From brooks at freebsd.org Fri Feb 15 14:40:38 2008 From: brooks at freebsd.org (Brooks Davis) Date: Fri, 15 Feb 2008 14:40:38 -0600 Subject: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47 In-Reply-To: References: Message-ID: <20080215204038.GA35852@lor.one-eyed-alien.net> On Fri, Feb 15, 2008 at 03:28:46PM -0500, Sebastien Loisel wrote: > Dear LLVMers > > OK, when I signed up for this mailing list, I asked for a once-daily digest. > > This is the fourth digest I receive today, and there are about that many > each day. > > The only reason I subscribe to the mailing list is so I can post to it. But > I don't need to receive the emails, because I can fully well read them in > the archive online, and I certainly don't want to get spammed multiple times > daily with the digest. Today, I received issue 44 at 3:01am, issue 45 at > 12:37pm, issue 46 at 2:02pm and issue 47 at 3:21pm. > > Is there a way that I can turn off all delivery of emails from the llvmdev > list without unsubscribing? If that's not possible, I'll unsubscribe and > then resubscribe when I have something to say, but I just think it would be > better if I could turn off the email delivery or something. Unless it's been disabled on this list server, you should be able to go to the subscription page for your account and disable delivery. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/703d4feb/attachment.bin From criswell at cs.uiuc.edu Fri Feb 15 14:37:22 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri, 15 Feb 2008 14:37:22 -0600 Subject: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47 In-Reply-To: References: Message-ID: <47B5F802.2070407@cs.uiuc.edu> Sebastien Loisel wrote: > Dear LLVMers > > OK, when I signed up for this mailing list, I asked for a once-daily digest. > > This is the fourth digest I receive today, and there are about that many each day. > > The only reason I subscribe to the mailing list is so I can post to it. But I don't need to receive the emails, because I can fully well read them in the archive online, and I certainly don't want to get spammed multiple times daily with the digest. Today, I received issue 44 at 3:01am, issue 45 at 12:37pm, issue 46 at 2:02pm and issue 47 at 3:21pm. > Briefly looking over the admin interface, it seems that the mailer sends email when the digest reaches a certain size. I am guessing, then, that llvm-dev has been busy as of late. I believe I've changed your subscription so that you will receive no mails from the list, but you should still be able to send email to the list. If you could send a test message to the list to make sure this is the case, I'd greatly appreciate it. For those on digest, the digest size is currently 30 KB. Is this reasonable for everyone, or should it be higher? -- John T. > Is there a way that I can turn off all delivery of emails from the llvmdev list without unsubscribing? If that's not possible, I'll unsubscribe and then resubscribe when I have something to say, but I just think it would be better if I could turn off the email delivery or something. > > Sincerely, > > S?bastien Loisel > > On Fri, Feb 15, 2008 at 3:21 PM, > wrote: > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > or, via email, send a message with subject or body 'help' to > llvmdev-request at cs.uiuc.edu > > You can reach the person managing the list at > llvmdev-owner at cs.uiuc.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of LLVMdev digest..." > > > Today's Topics: > > 1. Re: an llvm-gcc bug (Devang Patel) > 2. Re: an llvm-gcc bug (Chris Lattner) > 3. Re: an llvm-gcc bug (Dale Johannesen) > 4. Re: an llvm-gcc bug (Dale Johannesen) > 5. Re: an llvm-gcc bug (Chris Lattner) > 6. Re: Question on link error (Ted Neward) > 7. LiveInterval spilling (was LiveInterval Splitting & > SubRegisters) (Roman Levenstein) > 8. Re: LiveInterval spilling (was LiveInterval Splitting & > SubRegisters) (Fernando Magno Quintao Pereira) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Feb 2008 11:17:33 -0800 > From: Devang Patel > > Subject: Re: [LLVMdev] an llvm-gcc bug > To: LLVM Developers Mailing List > > Message-ID: <0C222846-383D-41DD-8229-4858BD1FD3A2 at apple.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > >> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >> >> >>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>> >>> >>>>>> Alternatively I can take the Padding bit into account in the >>>>>> StructType::get code somehow. Anyone have a strong opinion? >>>>>> >>>>> Shouldn't it be a map from the gcc type to the padding info? >>>>> That said, you can get rid of the padding info as far as I'm >>>>> concerned. However Chris might have a different opinion - I >>>>> think he introduced it. >>>>> >>>> I don't think I introduced it (was it Devang?). >>>> >>> Yup. PR 1278 >>> >> Ok! Can you please fix it to index by GCC type? There is a many to >> one mapping between gcc types and llvm types. >> > > This is tricky and probably won't work. Padding info is in llvm struct > type and CopyAggregate() is operating on llvm type. There is not any > way to map llvm type back to gcc type. Am I missing something ? > > - > Devang > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 15 Feb 2008 11:21:41 -0800 > From: Chris Lattner > > Subject: Re: [LLVMdev] an llvm-gcc bug > To: LLVM Developers Mailing List > > Message-ID: <8A9142EB-F978-4CCE-8550-5F805BDFAA07 at nondot.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > >>> Ok! Can you please fix it to index by GCC type? There is a many to >>> one mapping between gcc types and llvm types. >>> >> This is tricky and probably won't work. Padding info is in llvm struct >> type and CopyAggregate() is operating on llvm type. There is not any >> way to map llvm type back to gcc type. Am I missing something ? >> > > EmitAggregateCopy has the gcc type. It would be reasonable to have > CopyAggregate walk the GCC type in parallel with the llvm type, at > least in simple cases. In more complex cases, it could give up. > > -Chris > > > ------------------------------ > > Message: 3 > Date: Fri, 15 Feb 2008 11:22:47 -0800 > From: Dale Johannesen > > Subject: Re: [LLVMdev] an llvm-gcc bug > To: LLVM Developers Mailing List > > Message-ID: <04308F30-2980-4F02-8FF7-E09DD4D0D9C1 at apple.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > > >> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: >> >> >>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >>> >>> >>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>>> >>>> >>>>>>> Alternatively I can take the Padding bit into account in the >>>>>>> StructType::get code somehow. Anyone have a strong opinion? >>>>>>> >>>>>> Shouldn't it be a map from the gcc type to the padding info? >>>>>> That said, you can get rid of the padding info as far as I'm >>>>>> concerned. However Chris might have a different opinion - I >>>>>> think he introduced it. >>>>>> >>>>> I don't think I introduced it (was it Devang?). >>>>> >>>> Yup. PR 1278 >>>> >>> Ok! Can you please fix it to index by GCC type? There is a many to >>> one mapping between gcc types and llvm types. >>> >> This is tricky and probably won't work. Padding info is in llvm struct >> type and CopyAggregate() is operating on llvm type. There is not any >> way to map llvm type back to gcc type. Am I missing something ? >> > > > I don't think so, I have reached the same conclusion. You can pass > the gcc type into CopyAggregate, but it's recursive, and there's no > way to get the gcc type for the fields. You would have to walk the > gcc type in parallel with the llvm type, which at best involves > duplicating a lot of code and is quite error prone. > > > > ------------------------------ > > Message: 4 > Date: Fri, 15 Feb 2008 11:27:42 -0800 > From: Dale Johannesen > > Subject: Re: [LLVMdev] an llvm-gcc bug > To: Dale Johannesen > > Cc: LLVM Developers Mailing List > > Message-ID: <86CE380D-44AB-4035-9E7C-2DCD85308BDA at apple.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 15, 2008, at 11:22 AM, Dale Johannesen wrote: > > >> On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: >> >> >>> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: >>> >>> >>>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >>>> >>>> >>>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>>>> >>>>> >>>>>>>> Alternatively I can take the Padding bit into account in the >>>>>>>> StructType::get code somehow. Anyone have a strong opinion? >>>>>>>> >>>>>>> Shouldn't it be a map from the gcc type to the padding info? >>>>>>> That said, you can get rid of the padding info as far as I'm >>>>>>> concerned. However Chris might have a different opinion - I >>>>>>> think he introduced it. >>>>>>> >>>>>> I don't think I introduced it (was it Devang?). >>>>>> >>>>> Yup. PR 1278 >>>>> >>>> Ok! Can you please fix it to index by GCC type? There is a many to >>>> one mapping between gcc types and llvm types. >>>> >>> This is tricky and probably won't work. Padding info is in llvm >>> struct >>> type and CopyAggregate() is operating on llvm type. There is not any >>> way to map llvm type back to gcc type. Am I missing something ? >>> >> I don't think so, I have reached the same conclusion. You can pass >> the gcc type into CopyAggregate, but it's recursive, and there's no >> way to get the gcc type for the fields. You would have to walk the >> gcc type in parallel with the llvm type, which at best involves >> duplicating a lot of code and is quite error prone. >> > > ...but giving up in this case is easy enough, ok, I can do that. > > > > ------------------------------ > > Message: 5 > Date: Fri, 15 Feb 2008 11:39:06 -0800 > From: Chris Lattner > > Subject: Re: [LLVMdev] an llvm-gcc bug > To: LLVM Developers Mailing List > > Message-ID: <9345E8E7-503D-483F-90DD-1DA6FD64B6F3 at nondot.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 15, 2008, at 11:27 AM, Dale Johannesen wrote: > > >>> I don't think so, I have reached the same conclusion. You can pass >>> the gcc type into CopyAggregate, but it's recursive, and there's no >>> way to get the gcc type for the fields. You would have to walk the >>> gcc type in parallel with the llvm type, which at best involves >>> duplicating a lot of code and is quite error prone. >>> >> ...but giving up in this case is easy enough, ok, I can do that. >> > > Cool, thanks Dale! I think it would be reasonable to give up in > nested struct cases, etc. We can always improve it later, and that > will get us the obvious case in PR1278. > > -Chris > > > ------------------------------ > > Message: 6 > Date: Fri, 15 Feb 2008 11:47:47 -0800 > From: "Ted Neward" > > Subject: Re: [LLVMdev] Question on link error > To: "'Anton Korobeynikov'" >, "'LLVM Developers > Mailing List'" > > Message-ID: <017001c8700b$a8172760$f8457620$@com> > Content-Type: text/plain; charset="windows-1250" > > I am *more* than willing to believe it's an environment/configuration error, > so if you can't repro it, let's assume the problem is somewhere on my end. > > FWIW, I took the 2.2 release from the website, the GCC 4.2 release from the > website, and tried to follow the README.LLVM directions (build LLVM 2.2, > configure gcc in the obj directory, make and make install), then ran through > the hello steps. Only the lli step fails. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Anton Korobeynikov >> Sent: Friday, February 15, 2008 3:52 AM >> To: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Question on link error >> >> Hello, Ted >> >> >>> __main is supposed to be inside hello.bc, so why can t lli find it? >>> >> No, it shouldn't be there. On targets, which lacks init sections (for >> example, all win-based, like mingw & cygwin) __main is used to call >> static constructors and relevant stuff. >> >> The call to __main is assembled early in the main routine before the >> actual code will be executed. I'll try to look into this problem today. >> >> -- >> WBR, Anton Korobeynikov >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date: >> 2/14/2008 10:28 AM >> >> >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.6/1280 - Release Date: 2/15/2008 > 9:00 AM > > > > > > ------------------------------ > > Message: 7 > Date: Fri, 15 Feb 2008 21:01:33 +0100 (CET) > From: Roman Levenstein > > Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting & > SubRegisters) > To: LLVM Developers Mailing List > > Message-ID: <572290.31048.qm at web56312.mail.re3.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > Hi Evan, > > I have a few questions about current implementation of live intervals > spilling, which is required for the implementation of Extended Linear > Scan algorithm. > > --- Evan Cheng > wrote: > >>> On Wednesday 23 January 2008 02:01, Evan Cheng wrote: >>> >>>> On Jan 22, 2008, at 12:23 PM, David Greene wrote: >>>> >>>>> Evan, >>>>> >>>>> Can you explain the basic mechanics of the live interval >>>>> >> splitting code? >> >>>>> Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills >>>>> and child routines? What is it trying to do? >>>>> >>>> It's splitting live intervals that span multiple basic blocks. >>>> >> That is, when an interval is spilled, it introduce a single reload >> > per > >>>> basic block and retarget all the uses to use the result of the >>>> >> single reload. It does not (yet) split intra-bb intervals. >> > > When I look at the code, it seems that when linear scan regalloc > decides to spill a given live interval, it calls addIntervalsForSpills. > This function would split the original live interval into several > intervals according to the principle described by you above. Each of > this intervals (split children) then gets a stack slot allocated (and > all these split intervals get the same stack slot?) and then those new > splitted intervals are added to unhandled set. Thus they get a chance > to get physical registers assigned to them, independently. So, > actually, they are not quite "spilled" intervals (since they are not > really spilled and located in memory) and may get a physical register. > Is my understanding of the algorithm correct so far? > > What I don't quite understand is the following: > Why do live intervals with an allocated stack slot should also always > have a physical register assigned to them? How should a register > allocator decide, which physical register should be used for that? > > For example, in my version of Sarkar's Extended Linear Scan I sometimes > spill the whole live interval. So, I assign a stack slot to it. But > LLVM requires also a physical register to be assigned to each such live > interval as well. How do I decide which physical register should be > taken? Why can't the local spiller or the former rewriteFunction() part > of the RegAllocLinearScan find out on their own which of the currently > available for allocation physical registers should be taken at a given > point for a reload or for a spilling operation for a given spilled live > interval? Wouldn't it be more convenient? You just say that the > interval is spilled and the rest is done "by magic"? Or may be I'm > missing something about how spilling currently works in LLVM? > > Thanks in advance for any clarification of this issue. > > -Roman > > > Lesen Sie Ihre E-Mails auf dem Handy. > www.yahoo.de/go > > > ------------------------------ > > Message: 8 > Date: Fri, 15 Feb 2008 12:21:08 -0800 (PST) > From: Fernando Magno Quintao Pereira > > Subject: Re: [LLVMdev] LiveInterval spilling (was LiveInterval > Splitting & SubRegisters) > To: LLVM Developers Mailing List > > Message-ID: > > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi, Roman, > > maybe I can try to answer this. I think that all boils down to having > register to reload spilled values. Once a register is spilled, its live > range is split into smaller pieces. These pieces most be contained into > registers, and it is the task of the allocator to find these registers. > Imagine that you have something like: > > Before After > allocation: allocation: > a := 1 a(R1) := 1 // a is assigned to R1 > | // store R1 into M1 > | > | // 'a' is spilled into stack slot M1 > | > | // assign 'a' to R2, and load M1 into R2 > b := a b(Rx) := a(R2) > | > | > | > | > | // assign 'a' to R3, and load M1 into R3 > c := a c(Ry) := a(R3) > > So, the register is necessary for doing the reloading. Sometimes it is > possible to avoid the reloading with instruction folding, but this is not > always the case. Also, in the new allocator used in LLVM, I believe that > some live ranges may be split into bigger pieces, and this would save some > reloads. > > best, > > Fernando > > >> When I look at the code, it seems that when linear scan >> > regalloc > >> decides to spill a given live interval, it calls addIntervalsForSpills. >> This function would split the original live interval into several >> intervals according to the principle described by you above. Each of >> this intervals (split children) then gets a stack slot allocated (and >> all these split intervals get the same stack slot?) and then those new >> splitted intervals are added to unhandled set. Thus they get a chance >> to get physical registers assigned to them, independently. So, >> actually, they are not quite "spilled" intervals (since they are not >> really spilled and located in memory) and may get a physical register. >> Is my understanding of the algorithm correct so far? >> >> What I don't quite understand is the following: >> Why do live intervals with an allocated stack slot should also always >> have a physical register assigned to them? How should a register >> allocator decide, which physical register should be used for that? >> >> For example, in my version of Sarkar's Extended Linear Scan I sometimes >> spill the whole live interval. So, I assign a stack slot to it. But >> LLVM requires also a physical register to be assigned to each such live >> interval as well. How do I decide which physical register should be >> taken? Why can't the local spiller or the former rewriteFunction() part >> of the RegAllocLinearScan find out on their own which of the currently >> available for allocation physical registers should be taken at a given >> point for a reload or for a spilling operation for a given spilled live >> interval? Wouldn't it be more convenient? You just say that the >> interval is spilled and the rest is done "by magic"? Or may be I'm >> missing something about how spilling currently works in LLVM? >> >> Thanks in advance for any clarification of this issue. >> >> -Roman >> >> >> Lesen Sie Ihre E-Mails auf dem Handy. >> www.yahoo.de/go >> _______________________________________________ >> 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 44, Issue 47 > *************************************** > > > > -- > S?bastien Loisel > > From evan.cheng at apple.com Fri Feb 15 14:55:55 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 15 Feb 2008 12:55:55 -0800 Subject: [LLVMdev] Some questions about live intervals In-Reply-To: <445724.64646.qm@web56310.mail.re3.yahoo.com> References: <445724.64646.qm@web56310.mail.re3.yahoo.com> Message-ID: I'd be happy to commit it for you. But check with Chris about commit access. Evan On Feb 15, 2008, at 10:27 AM, Roman Levenstein wrote: > Hi Evan, > > [skipped] ... > >>> Please, let me know, if I should sumbit a patch without any >>> assert() and returning just a NULL pointer. >> >> Now I think either approach is fine. Please commit. Thanks! >> >> Evan > > I don't have a commit access to the SVN repository. Therefore I cannot > commit it myself. Should I better apply for getting a commiter access > or should I simply send you the final version of the patch? > > -Roman > > > > Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From loisel at temple.edu Fri Feb 15 15:20:05 2008 From: loisel at temple.edu (Sebastien Loisel) Date: Fri, 15 Feb 2008 16:20:05 -0500 Subject: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47 In-Reply-To: <47B5FA41.2060708@cs.uiuc.edu> References: <47B5FA41.2060708@cs.uiuc.edu> Message-ID: Dear John, Thank you for your quick intervention. I guess we will see if this email gets through. For those on digest, the digest size is currently 30 KB. Is this > reasonable for everyone, or should it be higher? > I think if you send a single email with enough quotes in it, it busts the limit. -- S?bastien Loisel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/9cb1b8fb/attachment.html From sabre at nondot.org Fri Feb 15 15:29:47 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 13:29:47 -0800 Subject: [LLVMdev] Some questions about live intervals In-Reply-To: References: <445724.64646.qm@web56310.mail.re3.yahoo.com> Message-ID: <71B06659-BFA6-41D6-B726-5C2EB8A66C59@nondot.org> On Feb 15, 2008, at 12:55 PM, Evan Cheng wrote: > I'd be happy to commit it for you. But check with Chris about commit > access. My typical heuristic is to give out commit access on the second or third significant patch, -Chris From andrewl at lenharth.org Fri Feb 15 15:34:12 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Fri, 15 Feb 2008 15:34:12 -0600 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> Message-ID: <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> Attached is the target independent llvm.atomic.barrier support, as well as alpha and x86 (sse2) support. This matches Chandler's definitions, and the LangRef patch will just restore that. Non-sse2 barrier will be needed, I think it is "lock; mov %esp, %esp", but I'm not sure. Any objections? I'll take a hack at the front end support for __sync_synchronize after this goes in. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: barrier.patch Type: text/x-diff Size: 6625 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/fdd767c0/attachment.bin From deplinenoise at gmail.com Fri Feb 15 15:47:20 2008 From: deplinenoise at gmail.com (Andreas Fredriksson) Date: Fri, 15 Feb 2008 22:47:20 +0100 Subject: [LLVMdev] More address registers Message-ID: <3212b1a80802151347j5435f2eeqcae8b8424375ea9d@mail.gmail.com> Hi again, I'm finally getting some time to work on my m68k backend again. :) I was trying to solve the problem that loads from arbitrary addresses need to go through address registers. 68k allows flexible addressing similar to what the x86 can do, only that the adressing base has to reside in an address register: move.size[b/w/l] (Ax, Dx * Scale[1/2/4/8]), -- Dest = *(Ax + Displacement + Dx * Scale) This is very powerful and suits a variant of the X86 backend SelectAddr() pretty well, so I've adapter pieces of that code for my own little backend. The issue I'm pondering is how to ensure that addresses end up in address registers just before the load. We discussed different alternatives on the list a while back such as pseudo registers and fixup passes; but then today I sat down again and tried something really stupid. In my SelectAddr() hook, which I know is going to be attempted for all loads, I can simply augment the source of the load to include a register copy so I know it's guaranteed to be loading from the correct register class in the end. I tried mocking this up using the following. (Base is what's returned as the Ax in the move expression above when the DAG is constructed due to SelectAddr().) SDOperand chain = CurDAG->getCopyToReg(Base, M68K::A3, Base); Base = CurDAG->getCopyFromReg(chain, M68K::A3, MVT::i32); This actually generates valid, but horrible code: int deref(int *p) { return *p; } gives move.l a0, a3 -- a0 is a live in (first pointer arg) move.l (a3), d0 -- d0 is a live out (first integer return value) rts int deref(int **p) { return **p; } gives move.l a0, a3 move.l (a3), d0 move.l d0, a3 move.l (a3), d0 rts Could this work (given there's a way to correctly get a hold of a virtual register of address type rather than hard coding A3) or am I missing something? // Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/b76bf453/attachment.html From criswell at cs.uiuc.edu Fri Feb 15 15:57:17 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri, 15 Feb 2008 15:57:17 -0600 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp Message-ID: <47B60ABD.5030107@cs.uiuc.edu> Dear All, I'm getting the following assertion from a program I've written: /home/vadve/criswell/src/llvm22/lib/VMCore/Value.cpp:57: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed. This occurs when I free a Module (the program uses an auto_ptr() to the Module, and the auto_ptr() moves out of scope). It looks like the code that frees a BasicBlock frees all of its instructions in order without regards to the def-use chains. However, the Value class's destructor has the assertion that the Value has no uses. Is the assertion an error, or should BasicBlock's deallocate instructions so that there are no dangling def-use chains? -- John T. From andrewl at lenharth.org Fri Feb 15 16:29:01 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Fri, 15 Feb 2008 16:29:01 -0600 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> Message-ID: <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> On 2/15/08, Andrew Lenharth wrote: > I'll take a hack at the front end support for > __sync_synchronize after this goes in. This is the gcc side of the patch. Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 46956) +++ gcc/llvm-convert.cpp (working copy) @@ -4260,6 +4260,15 @@ EmitBlock(new BasicBlock("")); return true; + case BUILT_IN_SYNCHRONIZE: { + Value* C[4]; + C[0] = C[1] = C[2] = C[3] = ConstantInt::get(Type::Int1Ty, 1); + + Builder.CreateCall(Intrinsic::getDeclaration(TheModule, Intrinsic::atomic_membarrier), + C, C + 4); + return true; + } + #if 1 // FIXME: Should handle these GCC extensions eventually. case BUILT_IN_APPLY_ARGS: case BUILT_IN_APPLY: From sabre at nondot.org Fri Feb 15 16:36:47 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 14:36:47 -0800 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp In-Reply-To: <47B60ABD.5030107@cs.uiuc.edu> References: <47B60ABD.5030107@cs.uiuc.edu> Message-ID: <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> On Feb 15, 2008, at 1:57 PM, John Criswell wrote: > Dear All, > > I'm getting the following assertion from a program I've written: > > /home/vadve/criswell/src/llvm22/lib/VMCore/Value.cpp:57: virtual > llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a > value is destroyed!"' failed. > > This occurs when I free a Module (the program uses an auto_ptr() to > the > Module, and the auto_ptr() moves out of scope). > > It looks like the code that frees a BasicBlock frees all of its > instructions in order without regards to the def-use chains. However, > the Value class's destructor has the assertion that the Value has no > uses. > > Is the assertion an error, or should BasicBlock's deallocate > instructions so that there are no dangling def-use chains? You probably have an instruction that you removed from the module but didn't delete. The module dtor works fine: it uses 'dropAllReferences' to clear the operands of instructions before deleting the instructions themselves. -Chris From chandlerc at gmail.com Fri Feb 15 16:38:00 2008 From: chandlerc at gmail.com (Chandler Carruth) Date: Fri, 15 Feb 2008 14:38:00 -0800 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> Message-ID: <47B61448.1070703@gmail.com> This looks good to me after a cursory scan, and seems to match what I had worked up with some very welcome better form on the codegen/backend side. =D I'm glad you've had some time to start hacking on this, it may be several more weeks before I get any time to work on these and other LLVM projects. Hopefully someone can chime in on appropriateness of the DAG and target implementations. One question: is "wmb" not actually useful on Alpha? My reading of docs had indicated it provided store-store memory barrier functionality, but I'm far from an expert on the architecture. Again, glad to see some work on this, and glad you had some time! -Chandler Andrew Lenharth wrote: > Attached is the target independent llvm.atomic.barrier support, as > well as alpha and x86 (sse2) support. This matches Chandler's > definitions, and the LangRef patch will just restore that. Non-sse2 > barrier will be needed, I think it is "lock; mov %esp, %esp", but I'm > not sure. > > Any objections? I'll take a hack at the front end support for > __sync_synchronize after this goes in. > > > Andrew > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Fri Feb 15 16:43:06 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri, 15 Feb 2008 16:43:06 -0600 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp In-Reply-To: <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> References: <47B60ABD.5030107@cs.uiuc.edu> <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> Message-ID: <47B6157A.10600@cs.uiuc.edu> Chris Lattner wrote: > On Feb 15, 2008, at 1:57 PM, John Criswell wrote: > > >> Dear All, >> >> I'm getting the following assertion from a program I've written: >> >> /home/vadve/criswell/src/llvm22/lib/VMCore/Value.cpp:57: virtual >> llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a >> value is destroyed!"' failed. >> >> This occurs when I free a Module (the program uses an auto_ptr() to >> the >> Module, and the auto_ptr() moves out of scope). >> >> It looks like the code that frees a BasicBlock frees all of its >> instructions in order without regards to the def-use chains. However, >> the Value class's destructor has the assertion that the Value has no >> uses. >> >> Is the assertion an error, or should BasicBlock's deallocate >> instructions so that there are no dangling def-use chains? >> > > You probably have an instruction that you removed from the module but > didn't delete. The module dtor works fine: it uses > 'dropAllReferences' to clear the operands of instructions before > deleting the instructions themselves. > Okay. I wasn't aware I had to delete unneeded values as well as remove them. I'll try that. Thanks. -- John T. > -Chris > _______________________________________________ > 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 Fri Feb 15 16:44:45 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Fri, 15 Feb 2008 16:44:45 -0600 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <47B61448.1070703@gmail.com> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> <47B61448.1070703@gmail.com> Message-ID: <85dfcd7f0802151444n7b40291ew3c21bc14bda049f7@mail.gmail.com> On 2/15/08, Chandler Carruth wrote: > Hopefully someone can chime in on appropriateness of the DAG and target > implementations. One question: is "wmb" not actually useful on Alpha? My > reading of docs had indicated it provided store-store memory barrier > functionality, but I'm far from an expert on the architecture. wmb is probably useful and can be added should someone really want it fairly easily, but since alpha isn't much used, I don't mind being overly conservative there. The bigger problem is the pre-SSE2 x86 version. > Again, glad to see some work on this, and glad you had some time! We have similar extensions sitting around for some research projects and I wanted to reduce our code base :) Andrew From sabre at nondot.org Fri Feb 15 16:58:12 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 14:58:12 -0800 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp In-Reply-To: <47B6157A.10600@cs.uiuc.edu> References: <47B60ABD.5030107@cs.uiuc.edu> <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> <47B6157A.10600@cs.uiuc.edu> Message-ID: <661E56FF-BE62-438A-949A-60AFF8B3EE15@nondot.org> >> You probably have an instruction that you removed from the module but >> didn't delete. The module dtor works fine: it uses >> 'dropAllReferences' to clear the operands of instructions before >> deleting the instructions themselves. >> > Okay. I wasn't aware I had to delete unneeded values as well as > remove > them. I'll try that. The convention is that 'remove' unlinks the object from the IR, and 'erase' does remove and deletes the result. If someone wants to clarify this behavior in http://llvm.org/docs/ProgrammersManual.html#common , it would be nice :) -Chris From criswell at cs.uiuc.edu Fri Feb 15 17:01:17 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri, 15 Feb 2008 17:01:17 -0600 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp In-Reply-To: <661E56FF-BE62-438A-949A-60AFF8B3EE15@nondot.org> References: <47B60ABD.5030107@cs.uiuc.edu> <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> <47B6157A.10600@cs.uiuc.edu> <661E56FF-BE62-438A-949A-60AFF8B3EE15@nondot.org> Message-ID: <47B619BD.1030905@cs.uiuc.edu> Chris Lattner wrote: >>> You probably have an instruction that you removed from the module but >>> didn't delete. The module dtor works fine: it uses >>> 'dropAllReferences' to clear the operands of instructions before >>> deleting the instructions themselves. >>> >>> >> Okay. I wasn't aware I had to delete unneeded values as well as >> remove >> them. I'll try that. >> > > The convention is that 'remove' unlinks the object from the IR, and > 'erase' does remove and deletes the result. > > If someone wants to clarify this behavior in http://llvm.org/docs/ProgrammersManual.html#common > , it would be nice :) > No, I understood that part (granted, I read DoxyGen). The part I didn't understand is that I'm required to erase an instruction that should have no more uses before deleting the Module. If I get time, I can try to add some text about it. -- John T. > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From sabre at nondot.org Fri Feb 15 17:02:33 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 15:02:33 -0800 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> Message-ID: <9136C12A-F831-4081-BC68-0BE744E5E466@nondot.org> On Feb 15, 2008, at 2:29 PM, Andrew Lenharth wrote: > On 2/15/08, Andrew Lenharth wrote: >> I'll take a hack at the front end support for >> __sync_synchronize after this goes in. > > This is the gcc side of the patch. GCC 4.2 compiles this to a no-op on x86: void foo() { __sync_synchronize(); } Are you seeing different behavior? What am I missing here? -Chris > > > Index: gcc/llvm-convert.cpp > =================================================================== > --- gcc/llvm-convert.cpp (revision 46956) > +++ gcc/llvm-convert.cpp (working copy) > @@ -4260,6 +4260,15 @@ > EmitBlock(new BasicBlock("")); > return true; > > + case BUILT_IN_SYNCHRONIZE: { > + Value* C[4]; > + C[0] = C[1] = C[2] = C[3] = ConstantInt::get(Type::Int1Ty, 1); > + > + Builder.CreateCall(Intrinsic::getDeclaration(TheModule, > Intrinsic::atomic_membarrier), > + C, C + 4); > + return true; > + } > + > #if 1 // FIXME: Should handle these GCC extensions eventually. > case BUILT_IN_APPLY_ARGS: > case BUILT_IN_APPLY: > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Fri Feb 15 17:05:07 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 15:05:07 -0800 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> Message-ID: <956478A2-6109-4479-92E6-65634C2AA134@nondot.org> On Feb 15, 2008, at 2:29 PM, Andrew Lenharth wrote: > On 2/15/08, Andrew Lenharth wrote: >> I'll take a hack at the front end support for >> __sync_synchronize after this goes in. > > This is the gcc side of the patch. Thanks for tackling this Andrew. Please prepare a patch for LangRef.html that explains what this thing does :). What are all those bools? Once that is available I'll review the rest of the llvm patch. In the call below, you don't have to pass in 4 i1's. Just passing in the intrinsic ID should be fine. The type list is for intrinsics that take 'any' as an argument. Finally, don't forget the 80 column rule. -Chris > > > Index: gcc/llvm-convert.cpp > =================================================================== > --- gcc/llvm-convert.cpp (revision 46956) > +++ gcc/llvm-convert.cpp (working copy) > @@ -4260,6 +4260,15 @@ > EmitBlock(new BasicBlock("")); > return true; > > + case BUILT_IN_SYNCHRONIZE: { > + Value* C[4]; > + C[0] = C[1] = C[2] = C[3] = ConstantInt::get(Type::Int1Ty, 1); > + > + Builder.CreateCall(Intrinsic::getDeclaration(TheModule, > Intrinsic::atomic_membarrier), > + C, C + 4); > + return true; > + } > + > #if 1 // FIXME: Should handle these GCC extensions eventually. > case BUILT_IN_APPLY_ARGS: > case BUILT_IN_APPLY: > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Fri Feb 15 17:06:53 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 15:06:53 -0800 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp In-Reply-To: <47B619BD.1030905@cs.uiuc.edu> References: <47B60ABD.5030107@cs.uiuc.edu> <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> <47B6157A.10600@cs.uiuc.edu> <661E56FF-BE62-438A-949A-60AFF8B3EE15@nondot.org> <47B619BD.1030905@cs.uiuc.edu> Message-ID: On Feb 15, 2008, at 3:01 PM, John Criswell wrote: >> The convention is that 'remove' unlinks the object from the IR, and >> 'erase' does remove and deletes the result. >> >> If someone wants to clarify this behavior in http://llvm.org/docs/ProgrammersManual.html#common >> , it would be nice :) >> > No, I understood that part (granted, I read DoxyGen). The part I > didn't > understand is that I'm required to erase an instruction that should > have > no more uses before deleting the Module. That's what the assertion is telling you (poorly) :). It is saying that there is something that uses a value that is attempting to be deleted. It doesn't know the context, so it can't tell you that the user is something that was unlinked but not deleted. If you write your code as an llvm pass, you should automatically get notified of this stuff in a debug build. If you can't do that, manually interfacing to the LeakDetector can help. -Chris From Ashwin.Kashyap at thomson.net Fri Feb 15 17:05:14 2008 From: Ashwin.Kashyap at thomson.net (Kashyap Ashwin) Date: Fri, 15 Feb 2008 18:05:14 -0500 Subject: [LLVMdev] llvm-gcc is generating native code Message-ID: <68DF70B3485CC648835655773E92314F08D542@prinsmail02.am.thmulti.com> Hello, I downloaded llvm-gcc4.2-2.2.source.tar.gz and followed instructions in README.LLVM, I used this to configure it: ../configure --prefix=/opt/llvm --enable-threads --disable-nls --enable-languages=c,c++ --enable-sjlj-exceptions --enable-llvm=/home/kashyapa/llvm-2.2 --program-prefix=llvm- --disable-bootstrap I have already installed llvm-2.2 in /opt/llvm. The compilation goes thru fine. /opt/llvm/bin/llvm-gcc -v, prints this: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/opt/llvm --enable-threads --disable-nls --disable-shared --enable-languages=c,c++ --enable-sjlj-exceptions --enable-llvm=/opt/llvm/ --program-prefix=llvm- --disable-multilib --disable-bootstrap : (reconfigured) ../configure --prefix=/opt/llvm --enable-threads --disable-nls --disable-shared --enable-languages=c,c++ --enable-sjlj-exceptions --enable-llvm=/home/kashyapa/llvm-2.2 --program-prefix=llvm- --disable-multilib --disable-bootstrap Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5546) (LLVM build) When I compile using this compiler, I do not get a *.bc file. Instead the binary generated seems to be a i386 binary. I also made sure /opt/llvm/bin is in path and LD_LIBRARY_PATH=/opt/llvm/lib I am using Ubuntu and have also uninstalled the stock (old v1.8, but generates *.bc correctly) llvm that is shipped. Is there anything I missed? Thanks, Ashwin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/19497ab6/attachment.html From criswell at cs.uiuc.edu Fri Feb 15 17:11:07 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri, 15 Feb 2008 17:11:07 -0600 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp In-Reply-To: References: <47B60ABD.5030107@cs.uiuc.edu> <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> <47B6157A.10600@cs.uiuc.edu> <661E56FF-BE62-438A-949A-60AFF8B3EE15@nondot.org> <47B619BD.1030905@cs.uiuc.edu> Message-ID: <47B61C0B.3000904@cs.uiuc.edu> Chris Lattner wrote: > On Feb 15, 2008, at 3:01 PM, John Criswell wrote: > > >>> The convention is that 'remove' unlinks the object from the IR, and >>> 'erase' does remove and deletes the result. >>> >>> If someone wants to clarify this behavior in http://llvm.org/docs/ProgrammersManual.html#common >>> , it would be nice :) >>> >>> >> No, I understood that part (granted, I read DoxyGen). The part I >> didn't >> understand is that I'm required to erase an instruction that should >> have >> no more uses before deleting the Module. >> > > That's what the assertion is telling you (poorly) :). It is saying > that there is something that uses a value that is attempting to be > deleted. It doesn't know the context, so it can't tell you that the > user is something that was unlinked but not deleted. > > If you write your code as an llvm pass, you should automatically get > notified of this stuff in a debug build. If you can't do that, > manually interfacing to the LeakDetector can help. > It is an LLVM pass, it's a debug build, and the only assertion I got was the one in ~Value(). Should there have been an earlier assertion? -- John T. > -Chris > _______________________________________________ > 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 Fri Feb 15 17:12:17 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Fri, 15 Feb 2008 17:12:17 -0600 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <956478A2-6109-4479-92E6-65634C2AA134@nondot.org> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> <956478A2-6109-4479-92E6-65634C2AA134@nondot.org> Message-ID: <85dfcd7f0802151512h2aae3b2ej652ac61046fedfee@mail.gmail.com> > Please prepare a patch for LangRef.html that explains what this thing > does :). What are all those bools? Once that is available I'll > review the rest of the llvm patch. http://llvm.org/releases/2.1/docs/LangRef.html#int_memory_barrier > In the call below, you don't have to pass in 4 i1's. Just passing in > the intrinsic ID should be fine. The type list is for intrinsics that > take 'any' as an argument. The intrinsic takes 4 bools. > Finally, don't forget the 80 column rule. Yea, already noticed that. From romixlev at yahoo.com Fri Feb 15 17:13:43 2008 From: romixlev at yahoo.com (Roman Levenstein) Date: Sat, 16 Feb 2008 00:13:43 +0100 (CET) Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting & SubRegisters) In-Reply-To: Message-ID: <359503.95298.qm@web56307.mail.re3.yahoo.com> Hi Fernando, --- Fernando Magno Quintao Pereira wrote: > > Hi, Roman, > > maybe I can try to answer this. I think that all boils down to > having register to reload spilled values. Ok. That I can follow. > Once a register is spilled, its live range is split into smaller > pieces. These pieces most be contained into registers, and it is the > task of the allocator to find these registers. I'm not quite sure about the last statement. See below. > Imagine that you have something like: > > Before After > allocation: allocation: > a := 1 a(R1) := 1 // a is assigned to R1 > | // store R1 into M1 > | > | // 'a' is spilled into stack slot M1 > | > | // assign 'a' to R2, and load M1 into R2 > b := a b(Rx) := a(R2) > | > | > | > | > | // assign 'a' to R3, and load M1 into R3 > c := a c(Ry) := a(R3) > > So, the register is necessary for doing the reloading. Yes. But as you show above, it may happen that the same spilled virtual interval is reloaded into _multiple different_ physical registers during its lifetime. So, what is the reason to assign only one (!) physical register to the virtual interval by means of VRM.assignVirt2Phys() and to do it actually in advance? What is the semantics of it? I'd really like to understand it better. How does this solve the problem described above? Wouldn't it be better if the spiller or code rewriter (that replaces virtual regs with the corresponding allocated physical regs) would decide dynamically (after regalloc finished doing its decisions about non-spilled intervals) based on case-by-case approach and taking into account current set of free physical registers which of them could be used for reloading the spilled register at a given point of execution? So, every time there is a use of a spilled register, such a spiller/rewriter would try to find a free physical register, where it could load the spilled value from memory. Once the operation with this reloaded value is over, it could eventually free this physical register for other purposes. Of course, it can happen that in some high register pressure situations you cannot dynamically find a free physical register to reload a spilled value, because all of them are occupied. But then you could temporarily evict one of them into memory or other location, use the freed physical register for the reload of spilled value and operations on it, and once it is done, restore the evicted register back into the physical one. Does it make some sense? Or do I still miss something very obvious? > Sometimes it > is possible to avoid the reloading with instruction folding, but this > is not always the case. Yes. Sometimes you really need it to be in a physical register. > Also, in the new allocator used in LLVM, I > believe that some live ranges may be split into bigger pieces, and > this would save some reloads. Seems so. Best, Roman > > When I look at the code, it seems that when linear scan > regalloc > > decides to spill a given live interval, it calls > addIntervalsForSpills. > > This function would split the original live interval into several > > intervals according to the principle described by you above. Each > of > > this intervals (split children) then gets a stack slot allocated > (and > > all these split intervals get the same stack slot?) and then those > new > > splitted intervals are added to unhandled set. Thus they get a > chance > > to get physical registers assigned to them, independently. So, > > actually, they are not quite "spilled" intervals (since they are > not > > really spilled and located in memory) and may get a physical > register. > > Is my understanding of the algorithm correct so far? > > > > What I don't quite understand is the following: > > Why do live intervals with an allocated stack slot should also > always > > have a physical register assigned to them? How should a register > > allocator decide, which physical register should be used for that? > > > > For example, in my version of Sarkar's Extended Linear Scan I > sometimes > > spill the whole live interval. So, I assign a stack slot to it. But > > LLVM requires also a physical register to be assigned to each such > live > > interval as well. How do I decide which physical register should be > > taken? Why can't the local spiller or the former rewriteFunction() > part > > of the RegAllocLinearScan find out on their own which of the > currently > > available for allocation physical registers should be taken at a > given > > point for a reload or for a spilling operation for a given spilled > live > > interval? Wouldn't it be more convenient? You just say that the > > interval is spilled and the rest is done "by magic"? Or may be I'm > > missing something about how spilling currently works in LLVM? > > > > Thanks in advance for any clarification of this issue. > > > > -Roman > > Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set From fernando at CS.UCLA.EDU Fri Feb 15 17:15:33 2008 From: fernando at CS.UCLA.EDU (Fernando Magno Quintao Pereira) Date: Fri, 15 Feb 2008 15:15:33 -0800 (PST) Subject: [LLVMdev] llvm-gcc is generating native code In-Reply-To: <68DF70B3485CC648835655773E92314F08D542@prinsmail02.am.thmulti.com> References: <68DF70B3485CC648835655773E92314F08D542@prinsmail02.am.thmulti.com> Message-ID: Hi, Ashwin, I think what you want is to add -emit-llvm after llvm-gcc, like: $> llvm-gcc foo.c -o foo.bc -c -emit-llvm Fernando > Hello, > > I downloaded llvm-gcc4.2-2.2.source.tar.gz and followed instructions in > README.LLVM, I used this to configure it: > > ../configure --prefix=/opt/llvm --enable-threads --disable-nls > --enable-languages=c,c++ --enable-sjlj-exceptions > --enable-llvm=/home/kashyapa/llvm-2.2 --program-prefix=llvm- > --disable-bootstrap > > > > I have already installed llvm-2.2 in /opt/llvm. > > The compilation goes thru fine. /opt/llvm/bin/llvm-gcc -v, prints this: > > > > Using built-in specs. > > Target: i686-pc-linux-gnu > > Configured with: ../configure --prefix=/opt/llvm --enable-threads > --disable-nls --disable-shared --enable-languages=c,c++ > --enable-sjlj-exceptions --enable-llvm=/opt/llvm/ --program-prefix=llvm- > --disable-multilib --disable-bootstrap : (reconfigured) ../configure > --prefix=/opt/llvm --enable-threads --disable-nls --disable-shared > --enable-languages=c,c++ --enable-sjlj-exceptions > --enable-llvm=/home/kashyapa/llvm-2.2 --program-prefix=llvm- > --disable-multilib --disable-bootstrap > > Thread model: posix > > gcc version 4.2.1 (Based on Apple Inc. build 5546) (LLVM build) > > > > When I compile using this compiler, I do not get a *.bc file. Instead > the binary generated seems to be a i386 binary. I also made sure > /opt/llvm/bin is in path and LD_LIBRARY_PATH=/opt/llvm/lib > > > > I am using Ubuntu and have also uninstalled the stock (old v1.8, but > generates *.bc correctly) llvm that is shipped. > > > > Is there anything I missed? > > > > Thanks, > > Ashwin > > From sabre at nondot.org Fri Feb 15 17:15:56 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 15:15:56 -0800 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp In-Reply-To: <47B61C0B.3000904@cs.uiuc.edu> References: <47B60ABD.5030107@cs.uiuc.edu> <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> <47B6157A.10600@cs.uiuc.edu> <661E56FF-BE62-438A-949A-60AFF8B3EE15@nondot.org> <47B619BD.1030905@cs.uiuc.edu> <47B61C0B.3000904@cs.uiuc.edu> Message-ID: <901B4EFE-6137-4B7C-A03F-240BB766CAF7@nondot.org> >> If you write your code as an llvm pass, you should automatically get >> notified of this stuff in a debug build. If you can't do that, >> manually interfacing to the LeakDetector can help. >> > It is an LLVM pass, it's a debug build, and the only assertion I got > was > the one in ~Value(). > > Should there have been an earlier assertion? You load a module, run your pass (which leaks an instruction) from the passmgr, then delete the module? -Chris From andrewl at lenharth.org Fri Feb 15 17:23:18 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Fri, 15 Feb 2008 17:23:18 -0600 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <9136C12A-F831-4081-BC68-0BE744E5E466@nondot.org> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> <9136C12A-F831-4081-BC68-0BE744E5E466@nondot.org> Message-ID: <85dfcd7f0802151523y6e7a6ae8tbbae9b311c1e9848@mail.gmail.com> On 2/15/08, Chris Lattner wrote: > GCC 4.2 compiles this to a no-op on x86: > > void foo() { > __sync_synchronize(); > } > > Are you seeing different behavior? What am I missing here? I see the same. I don't know why, __sync_synchronize() is suppose to be a full memory barrier. I don't know why gcc doesn't generate a barrier on x86. It does on alpha. X86 will do load-load reordering, so I would expect a "full memory barrier" primitive in gcc to actually generate a barrier (and at least the linux kernel implements barriers on x86 for hardware io). In any event, generating the intrinsic all the time should keep the optimizations from reordering when the programmer doesn't want them too, and the codegen for x86 can always remove unnecessary barriers. Andrew From fernando at CS.UCLA.EDU Fri Feb 15 17:29:51 2008 From: fernando at CS.UCLA.EDU (Fernando Magno Quintao Pereira) Date: Fri, 15 Feb 2008 15:29:51 -0800 (PST) Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting & SubRegisters) In-Reply-To: <359503.95298.qm@web56307.mail.re3.yahoo.com> References: <359503.95298.qm@web56307.mail.re3.yahoo.com> Message-ID: I see your issues. (I will be talking about LLVM 2.1, before Evan added the live range splitting thing). Once a register is spilled, LLVM replaces each use of it with a new, fresh virtual, so, my code before was, indeed, an abuse of notation. The new code would be like: a := 1 a := 1 a(R1) := 1 // a is assigned to R1 | M1 := store a M1 := store R1 | | | | | // 'a' is spilled into stack slot M1. | | // new registers a1 and a2, also | | // sharing M1 are created. | | | | | | | a1 := load M1 R2 := load from M1 b := a b := a1 b(Rx) := a1(R2) | | | | | | | a2 := load M1 R3 := load from M1 c := a c := a2 c(Ry) := a2(R3) So, after the spill is detected, the source code will change a little bit, to reflect this. Once the allocator finds, say, a1, it treats is as an ordinary virtual. Notice that those load instructions are, indeed, inserted by the Spiller, after register allocation is over. So, each of these registers a, a1 and a2 can be assigned to different registers. best, Fernando >> Before After >> allocation: allocation: >> a := 1 a(R1) := 1 // a is assigned to R1 >> | // store R1 into M1 >> | >> | // 'a' is spilled into stack slot M1 >> | >> | // assign 'a' to R2, and load M1 into R2 >> b := a b(Rx) := a(R2) >> | >> | >> | >> | >> | // assign 'a' to R3, and load M1 into R3 >> c := a c(Ry) := a(R3) >> >> So, the register is necessary for doing the reloading. > > Yes. But as you show above, it may happen that the same spilled virtual > interval is reloaded into _multiple different_ physical registers > during its lifetime. So, what is the reason to assign only one (!) > physical register to the virtual interval by means of > VRM.assignVirt2Phys() and to do it actually in advance? What is the > semantics of it? I'd really like to understand it better. How does this > solve the problem described above? Wouldn't it be better if the spiller > or code rewriter (that replaces virtual regs with the corresponding > allocated physical regs) would decide dynamically (after regalloc > finished doing its decisions about non-spilled intervals) based on > case-by-case approach and taking into account current set of free > physical registers which of them could be used for reloading the > spilled register at a given point of execution? So, every time there is > a use of a spilled register, such a spiller/rewriter would try to find > a free physical register, where it could load the spilled value from > memory. Once the operation with this reloaded value is over, it could > eventually free this physical register for other purposes. > > Of course, it can happen that in some high register pressure situations > you cannot dynamically find a free physical register to reload a > spilled value, because all of them are occupied. But then you could > temporarily evict one of them into memory or other location, use the > freed physical register for the reload of spilled value and operations > on it, and once it is done, restore the evicted register back into the > physical one. From sabre at nondot.org Fri Feb 15 17:35:31 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 15:35:31 -0800 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <85dfcd7f0802151512h2aae3b2ej652ac61046fedfee@mail.gmail.com> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> <956478A2-6109-4479-92E6-65634C2AA134@nondot.org> <85dfcd7f0802151512h2aae3b2ej652ac61046fedfee@mail.gmail.com> Message-ID: On Feb 15, 2008, at 3:12 PM, Andrew Lenharth wrote: >> Please prepare a patch for LangRef.html that explains what this thing >> does :). What are all those bools? Once that is available I'll >> review the rest of the llvm patch. > > http://llvm.org/releases/2.1/docs/LangRef.html#int_memory_barrier > >> In the call below, you don't have to pass in 4 i1's. Just passing in >> the intrinsic ID should be fine. The type list is for intrinsics >> that >> take 'any' as an argument. > > The intrinsic takes 4 bools. I know, but you don't have to pass them into intrinsic::getdeclaration -Chris From sabre at nondot.org Fri Feb 15 17:39:13 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 15:39:13 -0800 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151334r73b6e271pe6f8fae8665f7155@mail.gmail.com> Message-ID: <2742F557-9C33-4EA5-BFD2-F3ED1DFCC235@nondot.org> On Feb 15, 2008, at 1:34 PM, Andrew Lenharth wrote: > Attached is the target independent llvm.atomic.barrier support, as > well as alpha and x86 (sse2) support. This matches Chandler's > definitions, and the LangRef patch will just restore that. Non-sse2 > barrier will be needed, I think it is "lock; mov %esp, %esp", but I'm > not sure. > > Any objections? I'll take a hack at the front end support for > __sync_synchronize after this goes in. + // MEMBARRIER - This corresponds to the atomic.barrier intrinsic. + // it takes 4 operands to specify the type of barrier: + // ll, ls, sl, ss + MEMBARRIER, This should specify the input and output values, like EH_RETURN does. +def : Pat<(membarrier (i8 1), (i8 0), (i8 0), (i8 0)), (LFENCE)>; +def : Pat<(membarrier (i8 imm:$ll), (i8 imm:$ls), (i8 imm:$sl), (i8 imm:$ss)), + (MFENCE)>; Very nice. I'll trust Chandler that these are right. :) Looks great Andrew, please commit. Thanks! -Chris From sabre at nondot.org Fri Feb 15 17:32:04 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 15:32:04 -0800 Subject: [LLVMdev] llvm-gcc is generating native code In-Reply-To: References: <68DF70B3485CC648835655773E92314F08D542@prinsmail02.am.thmulti.com> Message-ID: On Feb 15, 2008, at 3:15 PM, Fernando Magno Quintao Pereira wrote: > > Hi, Ashwin, > > I think what you want is to add -emit-llvm after llvm-gcc, like: > > $> llvm-gcc foo.c -o foo.bc -c -emit-llvm Or you can pass -O4, which is -O3 + -emit-llvm. -Chris From evan.cheng at apple.com Fri Feb 15 17:56:32 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 15 Feb 2008 15:56:32 -0800 Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting & SubRegisters) In-Reply-To: <359503.95298.qm@web56307.mail.re3.yahoo.com> References: <359503.95298.qm@web56307.mail.re3.yahoo.com> Message-ID: <6E5C64EF-01F5-4DFB-906F-A1B3AFE4D0E0@apple.com> This is how the allocator was originally designed. Basically spilling a live interval is simply to split it many smaller pieces, one per define and use. Therefore, the allocator must guarantee every little piece is assigned a register right away to prevent further spilling (this is ensured by assigning them infinite spill weight). It is not designed with iterative spilling in mind. Obviously this approach can sometimes cause performance issue. That's why we are starting to introduce live interval splitting after 2.1 and you can expect more changes along the line in the not too distant future. Evan On Feb 15, 2008, at 3:13 PM, Roman Levenstein wrote: > Hi Fernando, > > --- Fernando Magno Quintao Pereira wrote: >> >> Hi, Roman, >> >> maybe I can try to answer this. I think that all boils down to >> having register to reload spilled values. > > Ok. That I can follow. > >> Once a register is spilled, its live range is split into smaller >> pieces. These pieces most be contained into registers, and it is the >> task of the allocator to find these registers. > > I'm not quite sure about the last statement. See below. > >> Imagine that you have something like: >> >> Before After >> allocation: allocation: >> a := 1 a(R1) := 1 // a is assigned to R1 >> | // store R1 into M1 >> | >> | // 'a' is spilled into stack slot M1 >> | >> | // assign 'a' to R2, and load M1 into R2 >> b := a b(Rx) := a(R2) >> | >> | >> | >> | >> | // assign 'a' to R3, and load M1 into R3 >> c := a c(Ry) := a(R3) >> >> So, the register is necessary for doing the reloading. > > Yes. But as you show above, it may happen that the same spilled > virtual > interval is reloaded into _multiple different_ physical registers > during its lifetime. So, what is the reason to assign only one (!) > physical register to the virtual interval by means of > VRM.assignVirt2Phys() and to do it actually in advance? What is the > semantics of it? I'd really like to understand it better. How does > this > solve the problem described above? Wouldn't it be better if the > spiller > or code rewriter (that replaces virtual regs with the corresponding > allocated physical regs) would decide dynamically (after regalloc > finished doing its decisions about non-spilled intervals) based on > case-by-case approach and taking into account current set of free > physical registers which of them could be used for reloading the > spilled register at a given point of execution? So, every time there > is > a use of a spilled register, such a spiller/rewriter would try to find > a free physical register, where it could load the spilled value from > memory. Once the operation with this reloaded value is over, it could > eventually free this physical register for other purposes. > > Of course, it can happen that in some high register pressure > situations > you cannot dynamically find a free physical register to reload a > spilled value, because all of them are occupied. But then you could > temporarily evict one of them into memory or other location, use the > freed physical register for the reload of spilled value and operations > on it, and once it is done, restore the evicted register back into the > physical one. > > Does it make some sense? Or do I still miss something very obvious? > >> Sometimes it >> is possible to avoid the reloading with instruction folding, but this > >> is not always the case. > > Yes. Sometimes you really need it to be in a physical register. > >> Also, in the new allocator used in LLVM, I >> believe that some live ranges may be split into bigger pieces, and >> this would save some reloads. > > Seems so. > > Best, > Roman > >>> When I look at the code, it seems that when linear scan >> regalloc >>> decides to spill a given live interval, it calls >> addIntervalsForSpills. >>> This function would split the original live interval into several >>> intervals according to the principle described by you above. Each >> of >>> this intervals (split children) then gets a stack slot allocated >> (and >>> all these split intervals get the same stack slot?) and then those >> new >>> splitted intervals are added to unhandled set. Thus they get a >> chance >>> to get physical registers assigned to them, independently. So, >>> actually, they are not quite "spilled" intervals (since they are >> not >>> really spilled and located in memory) and may get a physical >> register. >>> Is my understanding of the algorithm correct so far? >>> >>> What I don't quite understand is the following: >>> Why do live intervals with an allocated stack slot should also >> always >>> have a physical register assigned to them? How should a register >>> allocator decide, which physical register should be used for that? >>> >>> For example, in my version of Sarkar's Extended Linear Scan I >> sometimes >>> spill the whole live interval. So, I assign a stack slot to it. But >>> LLVM requires also a physical register to be assigned to each such >> live >>> interval as well. How do I decide which physical register should be >>> taken? Why can't the local spiller or the former rewriteFunction() >> part >>> of the RegAllocLinearScan find out on their own which of the >> currently >>> available for allocation physical registers should be taken at a >> given >>> point for a reload or for a spilling operation for a given spilled >> live >>> interval? Wouldn't it be more convenient? You just say that the >>> interval is spilled and the rest is done "by magic"? Or may be I'm >>> missing something about how spilling currently works in LLVM? >>> >>> Thanks in advance for any clarification of this issue. >>> >>> -Roman >>> > > > > Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: > http://de.yahoo.com/set > _______________________________________________ > 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 Fri Feb 15 18:38:59 2008 From: criswell at uiuc.edu (John Criswell) Date: Fri, 15 Feb 2008 18:38:59 -0600 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp In-Reply-To: <901B4EFE-6137-4B7C-A03F-240BB766CAF7@nondot.org> References: <47B60ABD.5030107@cs.uiuc.edu> <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> <47B6157A.10600@cs.uiuc.edu> <661E56FF-BE62-438A-949A-60AFF8B3EE15@nondot.org> <47B619BD.1030905@cs.uiuc.edu> <47B61C0B.3000904@cs.uiuc.edu> <901B4EFE-6137-4B7C-A03F-240BB766CAF7@nondot.org> Message-ID: <47B630A3.3070502@uiuc.edu> Chris Lattner wrote: >>> If you write your code as an llvm pass, you should automatically get >>> notified of this stuff in a debug build. If you can't do that, >>> manually interfacing to the LeakDetector can help. >>> >>> >> It is an LLVM pass, it's a debug build, and the only assertion I got >> was >> the one in ~Value(). >> >> Should there have been an earlier assertion? >> > > You load a module, run your pass (which leaks an instruction) from the > passmgr, then delete the module? > Yes, that's what the code was doing. -- John T. > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From sabre at nondot.org Fri Feb 15 18:45:17 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 15 Feb 2008 16:45:17 -0800 Subject: [LLVMdev] Possible Bad Assertion in Value.cpp In-Reply-To: <47B630A3.3070502@uiuc.edu> References: <47B60ABD.5030107@cs.uiuc.edu> <0DFB1ADA-EBE5-4B76-BCC1-54AD34923FCF@nondot.org> <47B6157A.10600@cs.uiuc.edu> <661E56FF-BE62-438A-949A-60AFF8B3EE15@nondot.org> <47B619BD.1030905@cs.uiuc.edu> <47B61C0B.3000904@cs.uiuc.edu> <901B4EFE-6137-4B7C-A03F-240BB766CAF7@nondot.org> <47B630A3.3070502@uiuc.edu> Message-ID: <566D008F-951C-4395-8AA9-BF91D5E04B63@nondot.org> On Feb 15, 2008, at 4:38 PM, John Criswell wrote: > Chris Lattner wrote: >>>> If you write your code as an llvm pass, you should automatically >>>> get >>>> notified of this stuff in a debug build. If you can't do that, >>>> manually interfacing to the LeakDetector can help. >>>> >>>> >>> It is an LLVM pass, it's a debug build, and the only assertion I got >>> was >>> the one in ~Value(). >>> >>> Should there have been an earlier assertion? >>> >> >> You load a module, run your pass (which leaks an instruction) from >> the >> passmgr, then delete the module? >> > Yes, that's what the code was doing. If you're sure that you're leaking in instruction and it isn't getting caught, please try to figure out why leak detector isn't seeing it. LeakDetector is a really trivial class: if you add a breakpoint to addGarbage/removeGarbage, you should be able to see what isn't happening. -Chris From dalej at apple.com Fri Feb 15 18:49:50 2008 From: dalej at apple.com (Dale Johannesen) Date: Fri, 15 Feb 2008 16:49:50 -0800 Subject: [LLVMdev] llvm-gcc is generating native code In-Reply-To: <68DF70B3485CC648835655773E92314F08D542@prinsmail02.am.thmulti.com> References: <68DF70B3485CC648835655773E92314F08D542@prinsmail02.am.thmulti.com> Message-ID: <67FE9C19-F0EF-4467-B957-264E21487A5A@apple.com> On Feb 15, 2008, at 3:05 PM, Kashyap Ashwin wrote: > Hello, > I downloaded llvm-gcc4.2-2.2.source.tar.gz and followed instructions > in README.LLVM, I used this to configure it: > ../configure --prefix=/opt/llvm --enable-threads --disable-nls -- > enable-languages=c,c++ --enable-sjlj-exceptions --enable-llvm=/home/ > kashyapa/llvm-2.2 --program-prefix=llvm- --disable-bootstrap > > I have already installed llvm-2.2 in /opt/llvm. > The compilation goes thru fine. /opt/llvm/bin/llvm-gcc ?v, prints > this: > > Using built-in specs. > Target: i686-pc-linux-gnu > Configured with: ../configure --prefix=/opt/llvm --enable-threads -- > disable-nls --disable-shared --enable-languages=c,c++ --enable-sjlj- > exceptions --enable-llvm=/opt/llvm/ --program-prefix=llvm- --disable- > multilib --disable-bootstrap : (reconfigured) ../configure --prefix=/ > opt/llvm --enable-threads --disable-nls --disable-shared --enable- > languages=c,c++ --enable-sjlj-exceptions --enable-llvm=/home/ > kashyapa/llvm-2.2 --program-prefix=llvm- --disable-multilib -- > disable-bootstrap > Thread model: posix > gcc version 4.2.1 (Based on Apple Inc. build 5546) (LLVM build) > > When I compile using this compiler, I do not get a *.bc file. > Instead the binary generated seems to be a i386 binary. I also made > sure /opt/llvm/bin is in path and LD_LIBRARY_PATH=/opt/llvm/lib The interface of llvm-gcc is like gcc: by default it compiles as far as a.out, and stops earlier with -c or -S. You need -emit-llvm -c to get an llvm binary file; -emit-llvm -S produces the ASCII form. The name defaults to *.s or *.o as usual for -c and -S, and is changed with -o as usual. > I am using Ubuntu and have also uninstalled the stock (old v1.8, but > generates *.bc correctly) llvm that is shipped. > > Is there anything I missed? > > Thanks, > Ashwin > _______________________________________________ > 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/20080215/cb2e9a67/attachment.html From cokane at cokane.org Fri Feb 15 21:17:33 2008 From: cokane at cokane.org (Coleman Kane) Date: Fri, 15 Feb 2008 22:17:33 -0500 Subject: [LLVMdev] amd64, FreeBSD and shared libraries Message-ID: <47B655CD.6080909@cokane.org> Hello, I am trying to build llvm-gcc 4.2 w/ llvm 2.2 on FreeBSD/amd64 and have found that it doesn't seem to want to build shared libraries. I've found numerous notes that I should try --disable-shared, because the linker ends up erroring out with a linker error when building libgcc_s.so. Subsequently, the same error is produced when it attempts to build libstdc++.so. If you do happen to build and install it, any attempt to link a shared library results in this very same behavior. The crtbeginS.o object seems to contain the offending relocation data which ld doesn't like. The following error is what I get: /usr/home/cokane/src/llvm-gcc4.2-2.2.source/host-amd64-undermydesk-freebsd8/gcc/xgcc -B/usr/home/cokane/src/llvm-gcc4.2-2.2.source/host-amd64-undermydesk-freebsd8/gcc/ -B/home/cokane/llvm-root/amd64-undermydesk-freebsd8/bin/ -B/home/cokane/llvm-root/amd64-undermydesk-freebsd8/lib/ -isystem /home/cokane/llvm-root/amd64-undermydesk-freebsd8/include -isystem /home/cokane/llvm-root/amd64-undermydesk-freebsd8/sys-include -O2 -O2 -fPIC -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_bswapsi2_s.o libgcc/./_bswapdi2_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so /usr/bin/ld: /usr/home/cokane/src/llvm-gcc4.2-2.2.source/host-amd64-undermydesk-freebsd8/gcc/crtbeginS.o: relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/home/cokane/src/llvm-gcc4.2-2.2.source/host-amd64-undermydesk-freebsd8/gcc/crtbeginS.o: could not read symbols: Bad value collect2: ld returned 1 exit status gmake[3]: *** [libgcc_s.so] Error 1 gmake[3]: Leaving directory `/usr/home/cokane/src/llvm-gcc4.2-2.2.source/host-amd64-undermydesk-freebsd8/gcc' gmake[2]: *** [libgcc.a] Error 2 gmake[2]: Leaving directory `/usr/home/cokane/src/llvm-gcc4.2-2.2.source/host-amd64-undermydesk-freebsd8/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/usr/home/cokane/src/llvm-gcc4.2-2.2.source' gmake: *** [all] Error 2 I am really eager to get this working on my system so that I can play around. Any help would be appreciated. -- Coleman Kane From baldrick at free.fr Sat Feb 16 02:16:44 2008 From: baldrick at free.fr (Duncan Sands) Date: Sat, 16 Feb 2008 09:16:44 +0100 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <9136C12A-F831-4081-BC68-0BE744E5E466@nondot.org> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> <9136C12A-F831-4081-BC68-0BE744E5E466@nondot.org> Message-ID: <200802160916.44769.baldrick@free.fr> > GCC 4.2 compiles this to a no-op on x86: > > void foo() { > __sync_synchronize(); > } > > Are you seeing different behavior? What am I missing here? Maybe the processor does a memory barrier when it executes a call instruction. Ciao, Duncan. From baldrick at free.fr Sat Feb 16 02:20:40 2008 From: baldrick at free.fr (Duncan Sands) Date: Sat, 16 Feb 2008 09:20:40 +0100 Subject: [LLVMdev] llvm-gcc is generating native code In-Reply-To: References: <68DF70B3485CC648835655773E92314F08D542@prinsmail02.am.thmulti.com> Message-ID: <200802160920.40844.baldrick@free.fr> > > $> llvm-gcc foo.c -o foo.bc -c -emit-llvm > > Or you can pass -O4, which is -O3 + -emit-llvm. This seems to have stopped working recently (4.2 from svn). D. From baldrick at free.fr Sat Feb 16 02:30:07 2008 From: baldrick at free.fr (Duncan Sands) Date: Sat, 16 Feb 2008 09:30:07 +0100 Subject: [LLVMdev] amd64, FreeBSD and shared libraries In-Reply-To: <47B655CD.6080909@cokane.org> References: <47B655CD.6080909@cokane.org> Message-ID: <200802160930.08156.baldrick@free.fr> Try --disable-multilib Ciao, Duncan. From andrewl at lenharth.org Sat Feb 16 07:24:04 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sat, 16 Feb 2008 07:24:04 -0600 Subject: [LLVMdev] llvm.atomic.barrier implementation In-Reply-To: <200802160916.44769.baldrick@free.fr> References: <85dfcd7f0802151331s103e7041w514d855baad8e127@mail.gmail.com> <85dfcd7f0802151429u729bb27cr157efd07d96310e4@mail.gmail.com> <9136C12A-F831-4081-BC68-0BE744E5E466@nondot.org> <200802160916.44769.baldrick@free.fr> Message-ID: <85dfcd7f0802160524y17a48c83x407bd8e88c58c28a@mail.gmail.com> On 2/16/08, Duncan Sands wrote: > > GCC 4.2 compiles this to a no-op on x86: > > > > void foo() { > > __sync_synchronize(); > > } > > > > Are you seeing different behavior? What am I missing here? > > Maybe the processor does a memory barrier when it executes > a call instruction. I had tried several variants of that with loads and stores around the barrier. GCC never generated a barrier, but it's not needed if you are accessing cached memory (on x86, at least post-ppro, from what I've read), only other stuff, so I am assuming gcc is making that assumption about loads and stores. Andrew From dalej at apple.com Sat Feb 16 13:24:29 2008 From: dalej at apple.com (Dale Johannesen) Date: Sat, 16 Feb 2008 11:24:29 -0800 Subject: [LLVMdev] [llvm-testresults] Grawp-PIC i386 nightly tester results In-Reply-To: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> References: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> Message-ID: <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> On Feb 16, 2008, at 7:06 AM, Apache wrote: > New Test Failures: > test/C++Frontend/2008-02-13-sret.cpp [DEJAGNU] This test doesn't work with gcc-4.0, which caused it to fail on a number of testers overnight. I can fix that in 4.0, but as I understand it we're going to drop support for it next release, so how about now? From evan.cheng at apple.com Sat Feb 16 13:32:13 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sat, 16 Feb 2008 11:32:13 -0800 Subject: [LLVMdev] [llvm-testresults] Grawp-PIC i386 nightly tester results In-Reply-To: <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> References: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> Message-ID: <887ED4AD-8F74-49DA-8D9C-A052C8EF21F1@apple.com> But I am using llvm-gcc-4.2. Any idea why it's failing? Evan On Feb 16, 2008, at 11:24 AM, Dale Johannesen wrote: > On Feb 16, 2008, at 7:06 AM, Apache wrote: >> New Test Failures: >> test/C++Frontend/2008-02-13-sret.cpp [DEJAGNU] > > This test doesn't work with gcc-4.0, which caused it to fail on a > number of testers overnight. I can fix that in 4.0, but as I > understand it we're going to drop support for it next release, so how > about now? > > _______________________________________________ > 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 Feb 16 13:38:07 2008 From: dalej at apple.com (Dale Johannesen) Date: Sat, 16 Feb 2008 11:38:07 -0800 Subject: [LLVMdev] [llvm-testresults] Grawp-PIC i386 nightly tester results In-Reply-To: <887ED4AD-8F74-49DA-8D9C-A052C8EF21F1@apple.com> References: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> <887ED4AD-8F74-49DA-8D9C-A052C8EF21F1@apple.com> Message-ID: <4A95844A-AA6A-4BE9-819D-A2DBDA96A09D@apple.com> On Feb 16, 2008, at 11:32 AM, Evan Cheng wrote: > But I am using llvm-gcc-4.2. Any idea why it's failing? > > Evan All the failing testers are using gcc-4.0 according to the web pages they point at. > On Feb 16, 2008, at 11:24 AM, Dale Johannesen wrote: > >> On Feb 16, 2008, at 7:06 AM, Apache wrote: >>> New Test Failures: >>> test/C++Frontend/2008-02-13-sret.cpp [DEJAGNU] >> >> This test doesn't work with gcc-4.0, which caused it to fail on a >> number of testers overnight. I can fix that in 4.0, but as I >> understand it we're going to drop support for it next release, so how >> about now? >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > llvm-testresults mailing list > llvm-testresults at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-testresults From evan.cheng at apple.com Sat Feb 16 13:42:20 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sat, 16 Feb 2008 11:42:20 -0800 Subject: [LLVMdev] [llvm-testresults] Grawp-PIC i386 nightly tester results In-Reply-To: <4A95844A-AA6A-4BE9-819D-A2DBDA96A09D@apple.com> References: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> <887ED4AD-8F74-49DA-8D9C-A052C8EF21F1@apple.com> <4A95844A-AA6A-4BE9-819D-A2DBDA96A09D@apple.com> Message-ID: llvm itself is built with gcc-4.0, but the run line is: // RUN: %llvmgxx -S -O0 -emit-llvm %s -o - | grep retval | grep S242 | grep {i32 1} | count 2 According the log: FAIL: /Volumes/Muggles/LLVM/nightlytest-pic/build/llvm/test/C+ +Frontend/2008-02-13-sret.cpp Failed with exit(1) at line 1 while running: /usr/local/bin/llvm-gcc -emit-llvm -S -O0 -emit-llvm / Volumes/Muggles/LLVM/nightlytest-pic/build/llvm/test/C++Frontend/ 2008-02-13-sret.cpp -o - | grep {retva\ l\|memtmp} | grep S242 | grep {i32 1} | count 1 count: expected 1 lines and got 0. child process exited abnormally /usr/local/bin/llvm-gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /tmp/llvmgcc42.r46865.roots/llvmgcc42.r46865~obj/src/ configure --disable-checking --enable-werror --prefix=/Developer/usr/ llvm-gcc-4.2 --mandir=/Developer/usr/llvm-gcc-4.2/share/man --enable- languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program- transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-gxx-include-dir=/usr/ include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 -- enable-llvm=/usr/local --host=i686-apple-darwin9 --target=i686-apple- darwin9 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5546) (LLVM build 9999) It's 4.2 based llvm-gcc. Evan On Feb 16, 2008, at 11:38 AM, Dale Johannesen wrote: > > On Feb 16, 2008, at 11:32 AM, Evan Cheng wrote: > >> But I am using llvm-gcc-4.2. Any idea why it's failing? >> >> Evan > > All the failing testers are using gcc-4.0 according to the web pages > they point at. > >> On Feb 16, 2008, at 11:24 AM, Dale Johannesen wrote: >> >>> On Feb 16, 2008, at 7:06 AM, Apache wrote: >>>> New Test Failures: >>>> test/C++Frontend/2008-02-13-sret.cpp [DEJAGNU] >>> >>> This test doesn't work with gcc-4.0, which caused it to fail on a >>> number of testers overnight. I can fix that in 4.0, but as I >>> understand it we're going to drop support for it next release, so >>> how >>> about now? >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> llvm-testresults mailing list >> llvm-testresults at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-testresults > From clattner at apple.com Sat Feb 16 14:11:35 2008 From: clattner at apple.com (Chris Lattner) Date: Sat, 16 Feb 2008 12:11:35 -0800 Subject: [LLVMdev] [llvm-testresults] Grawp-PIC i386 nightly tester results In-Reply-To: <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> References: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> Message-ID: <79777734-94DB-40C1-9969-4487CDA7C3C0@apple.com> On Feb 16, 2008, at 11:24 AM, Dale Johannesen wrote: > On Feb 16, 2008, at 7:06 AM, Apache wrote: >> New Test Failures: >> test/C++Frontend/2008-02-13-sret.cpp [DEJAGNU] > > This test doesn't work with gcc-4.0, which caused it to fail on a > number of testers overnight. I can fix that in 4.0, but as I > understand it we're going to drop support for it next release, so how > about now? 4.0 is dead, please don't worry about it. -Chris From johnhull2008 at gmail.com Sat Feb 16 14:14:28 2008 From: johnhull2008 at gmail.com (john hull) Date: Sat, 16 Feb 2008 12:14:28 -0800 Subject: [LLVMdev] speeding up compilation and link time Message-ID: <16f40f0802161214r2bbe0d90o859434cccab5de15@mail.gmail.com> Does anyone have any ideas or tips on how to shorten the time to build? I am building a new tool (in the llvm/projects directory) and it takes minutes to fully build the project, possibly because it uses lots of templates and boost & stl libraries and I am using a slow machine. Specifically, I am looking for ways to change the Makefile and use precompiled headers and incremental linking, but still can't figure out how the Makefile is structured. compiler: gcc 4.2.0. build options: ENABLE_OPTIMIZED=0 REQUIRES_EH=1 Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080216/2430d98c/attachment.html From sabre at nondot.org Sat Feb 16 14:32:19 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 16 Feb 2008 12:32:19 -0800 Subject: [LLVMdev] linux/x86-64 codegen support Message-ID: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> PR1711 is an x86 codegen problem that is blocking adoption of llvm-gcc by people using linux on x86-64 boxes. Could someone with access to one of these boxes take a look? I'll help try to debug this, but I don't have access to a machine. I bet it's a small tweak required in the x86 backend. Thanks! -Chris From dalej at apple.com Sat Feb 16 14:55:13 2008 From: dalej at apple.com (Dale Johannesen) Date: Sat, 16 Feb 2008 12:55:13 -0800 Subject: [LLVMdev] [llvm-testresults] Grawp-PIC i386 nightly tester results In-Reply-To: References: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> <887ED4AD-8F74-49DA-8D9C-A052C8EF21F1@apple.com> <4A95844A-AA6A-4BE9-819D-A2DBDA96A09D@apple.com> Message-ID: <7A2F8C3F-37D7-4EAE-8B23-5470F0578CF5@apple.com> > > Using built-in specs. > Target: i686-apple-darwin9 > Configured with: /tmp/llvmgcc42.r46865.roots/llvmgcc42.r46865~obj/ > src/configure --disable-checking --enable-werror --prefix=/Developer/ > usr/llvm-gcc-4.2 --mandir=/Developer/usr/llvm-gcc-4.2/share/man -- > enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program- > transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-gxx-include-dir=/usr/ > include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 > --enable-llvm=/usr/local --host=i686-apple-darwin9 --target=i686- > apple-darwin9 > Thread model: posix > gcc version 4.2.1 (Based on Apple Inc. build 5546) (LLVM build 9999) > > It's 4.2 based llvm-gcc. Ok, so the gcc line on the tester web pages is worse than useless. Works for me. Make sure your llvm-gcc-4.2 is up to date, you need r47180. The r46865 above suggests you might not have it. From andrewl at lenharth.org Sat Feb 16 15:16:32 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sat, 16 Feb 2008 15:16:32 -0600 Subject: [LLVMdev] linux/x86-64 codegen support In-Reply-To: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> References: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> Message-ID: <85dfcd7f0802161316o7e8d387bp7edb94dc61d6e214@mail.gmail.com> libcpp/charset.c:631 turns into: %tmp16 = tail call i64 @strlen( i8* %to ) nounwind readonly ; [#uses=1] %tmp18 = tail call i64 @strlen( i8* %from ) nounwind readonly ; [#uses=1] %tmp19 = add i64 %tmp16, 2 ; [#uses=1] %tmp20 = add i64 %tmp19, %tmp18 ; [#uses=1] %tmp21 = tail call i8* @alloca( i64 %tmp20 ) nounwind ; [#uses=5] other allocas in that file become instructions. Andrew On 2/16/08, Chris Lattner wrote: > PR1711 is an x86 codegen problem that is blocking adoption of llvm-gcc > by people using linux on x86-64 boxes. Could someone with access to > one of these boxes take a look? I'll help try to debug this, but I > don't have access to a machine. I bet it's a small tweak required in > the x86 backend. > > Thanks! > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From andrewl at lenharth.org Sat Feb 16 15:44:08 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sat, 16 Feb 2008 15:44:08 -0600 Subject: [LLVMdev] linux/x86-64 codegen support In-Reply-To: <85dfcd7f0802161316o7e8d387bp7edb94dc61d6e214@mail.gmail.com> References: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> <85dfcd7f0802161316o7e8d387bp7edb94dc61d6e214@mail.gmail.com> Message-ID: <85dfcd7f0802161344i535378a1pb9110be7328b671@mail.gmail.com> Interestingly, in the .i file there are 2 __builtin_alloca, and EmitBuiltinAlloca is only being called once. Andrew On 2/16/08, Andrew Lenharth wrote: > libcpp/charset.c:631 turns into: > > %tmp16 = tail call i64 @strlen( i8* %to ) nounwind readonly > ; [#uses=1] > %tmp18 = tail call i64 @strlen( i8* %from ) nounwind readonly > ; [#uses=1] > %tmp19 = add i64 %tmp16, 2 ; [#uses=1] > %tmp20 = add i64 %tmp19, %tmp18 ; [#uses=1] > %tmp21 = tail call i8* @alloca( i64 %tmp20 ) nounwind > ; [#uses=5] > > other allocas in that file become instructions. > > Andrew > > On 2/16/08, Chris Lattner wrote: > > PR1711 is an x86 codegen problem that is blocking adoption of llvm-gcc > > by people using linux on x86-64 boxes. Could someone with access to > > one of these boxes take a look? I'll help try to debug this, but I > > don't have access to a machine. I bet it's a small tweak required in > > the x86 backend. > > > > Thanks! > > > > -Chris > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > From edwintorok at gmail.com Sat Feb 16 16:17:25 2008 From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=) Date: Sun, 17 Feb 2008 00:17:25 +0200 Subject: [LLVMdev] linux/x86-64 codegen support In-Reply-To: <85dfcd7f0802161344i535378a1pb9110be7328b671@mail.gmail.com> References: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> <85dfcd7f0802161316o7e8d387bp7edb94dc61d6e214@mail.gmail.com> <85dfcd7f0802161344i535378a1pb9110be7328b671@mail.gmail.com> Message-ID: <47B760F5.9020902@gmail.com> Andrew Lenharth wrote: > Interestingly, in the .i file there are 2 __builtin_alloca, and > EmitBuiltinAlloca is only being called once. > > Hmm, here EmitBuiltinAlloca gets called twice, but it looks like validate_arglist is rejecting the args both times. I have 2 calls to alloca generated: $ grep alloca x.bc|grep call %tmp21 = call i8* @alloca( i64 %tmp20 ) nounwind ; [#uses=1] %tmp3 = call i8* @alloca( i64 %tmp2 ) nounwind ; [#uses=1] I added some printfs around that code, running cc1 shows it never reaches the 2nd printf: 4762? printf("HERE!!\n"); 4763? tree arglist = TREE_OPERAND(exp, 1); 4764?> if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) 4765? return false; 4766? printf("THERE!!\n") Is there a way to nicely dump arglist? gdb's print *arglist shows too much information.... $ /home/edwin/llvm-svn/obj42/./prev-gcc/cc1 charset.i vprintf getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar fputc_unlocked putc_unlocked putchar_unlocked feof_unlocked ferror_unlocked gnu_dev_major gnu_dev_minor gnu_dev_makedev atof atoi atol atoll stat lstat fstat mknod cpp_in_system_header ustrcmp ustrncmp ustrcspn ustrlen uxstrdup ustrchr ufputs one_utf8_to_cppchar one_cppchar_to_utf8 one_utf8_to_utf32 one_utf32_to_utf8 one_utf8_to_utf16 one_utf16_to_utf8 conversion_loop convert_utf8_utf16 convert_utf8_utf32 convert_utf16_utf8 convert_utf32_utf8 convert_no_conversion convert_using_iconv init_iconv_descHERE!! cpp_init_iconv _cpp_destroy_iconv cpp_host_to_exec_charset width_to_mask ucn_valid_in_identifier _cpp_valid_ucn convert_ucn emit_numeric_escape convert_hex convert_oct convert_escape cpp_interpret_string cpp_interpret_string_notranslate narrow_str_to_charconst wide_str_to_charconst cpp_interpret_charconst _cpp_interpret_identifierHERE!! _cpp_convert_input _cpp_default_encoding cpp_utf8_utf16 Execution times (seconds) preprocessing : 0.02 ( 6%) usr 0.01 ( 6%) sys 0.04 ( 8%) wall 285 kB ( 6%) ggc lexical analysis : 0.01 ( 3%) usr 0.10 (59%) sys 0.08 (16%) wall 0 kB ( 0%) ggc parser : 0.06 (19%) usr 0.04 (24%) sys 0.13 (26%) wall 2756 kB (56%) ggc tree gimplify : 0.01 ( 3%) usr 0.00 ( 0%) sys 0.02 ( 4%) wall 424 kB ( 9%) ggc llvm backend functions: 0.03 ( 9%) usr 0.00 ( 0%) sys 0.03 ( 6%) wall 1 kB ( 0%) ggc llvm backend globals : 0.01 ( 3%) usr 0.00 ( 0%) sys 0.01 ( 2%) wall 0 kB ( 0%) ggc llvm backend per file : 0.17 (53%) usr 0.01 ( 6%) sys 0.18 (36%) wall 0 kB ( 0%) ggc TOTAL : 0.32 0.17 0.50 4953 kB Best regards, --Edwin From andrewl at lenharth.org Sat Feb 16 16:27:38 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sat, 16 Feb 2008 16:27:38 -0600 Subject: [LLVMdev] linux/x86-64 codegen support In-Reply-To: <47B760F5.9020902@gmail.com> References: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> <85dfcd7f0802161316o7e8d387bp7edb94dc61d6e214@mail.gmail.com> <85dfcd7f0802161344i535378a1pb9110be7328b671@mail.gmail.com> <47B760F5.9020902@gmail.com> Message-ID: <85dfcd7f0802161427n3b0f95cdn6c41fd604d47b319@mail.gmail.com> See the bug for a reduction and the gimple trees. validate_arglist definately is rejecting the arglist in EmitBuiltinAlloca. (try: bool TreeToLLVM::EmitBuiltinAlloca(tree exp, Value *&Result) { tree arglist = TREE_OPERAND(exp, 1); if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) { debug_tree(arglist); return false; } Value *Amt = Emit(TREE_VALUE(arglist), 0); Amt = CastToSIntType(Amt, Type::Int32Ty); Result = Builder.CreateAlloca(Type::Int8Ty, Amt, "tmp"); return true; } for a pretty (?) print of the tree at that point) Andrew On 2/16/08, T?r?k Edwin wrote: > Andrew Lenharth wrote: > > Interestingly, in the .i file there are 2 __builtin_alloca, and > > EmitBuiltinAlloca is only being called once. > > > > > > Hmm, here EmitBuiltinAlloca gets called twice, but it looks like > validate_arglist is rejecting the args both times. > > I have 2 calls to alloca generated: > $ grep alloca x.bc|grep call > %tmp21 = call i8* @alloca( i64 %tmp20 ) nounwind > ; [#uses=1] > %tmp3 = call i8* @alloca( i64 %tmp2 ) nounwind ; > [#uses=1] > > I added some printfs around that code, running cc1 shows it never > reaches the 2nd printf: > 4762? printf("HERE!!\n"); > 4763? tree arglist = TREE_OPERAND(exp, 1); > 4764?> if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) > 4765? return false; > 4766? printf("THERE!!\n") > > Is there a way to nicely dump arglist? > gdb's print *arglist shows too much information.... > > $ /home/edwin/llvm-svn/obj42/./prev-gcc/cc1 charset.i > vprintf getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar > fputc_unlocked putc_unlocked putchar_unlocked feof_unlocked > ferror_unlocked gnu_dev_major gnu_dev_minor gnu_dev_makedev atof atoi > atol atoll stat lstat fstat mknod cpp_in_system_header ustrcmp ustrncmp > ustrcspn ustrlen uxstrdup ustrchr ufputs one_utf8_to_cppchar > one_cppchar_to_utf8 one_utf8_to_utf32 one_utf32_to_utf8 > one_utf8_to_utf16 one_utf16_to_utf8 conversion_loop convert_utf8_utf16 > convert_utf8_utf32 convert_utf16_utf8 convert_utf32_utf8 > convert_no_conversion convert_using_iconv init_iconv_descHERE!! > cpp_init_iconv _cpp_destroy_iconv cpp_host_to_exec_charset > width_to_mask ucn_valid_in_identifier _cpp_valid_ucn convert_ucn > emit_numeric_escape convert_hex convert_oct convert_escape > cpp_interpret_string cpp_interpret_string_notranslate > narrow_str_to_charconst wide_str_to_charconst cpp_interpret_charconst > _cpp_interpret_identifierHERE!! > _cpp_convert_input _cpp_default_encoding cpp_utf8_utf16 > Execution times (seconds) > preprocessing : 0.02 ( 6%) usr 0.01 ( 6%) sys 0.04 ( 8%) > wall 285 kB ( 6%) ggc > lexical analysis : 0.01 ( 3%) usr 0.10 (59%) sys 0.08 (16%) > wall 0 kB ( 0%) ggc > parser : 0.06 (19%) usr 0.04 (24%) sys 0.13 (26%) > wall 2756 kB (56%) ggc > tree gimplify : 0.01 ( 3%) usr 0.00 ( 0%) sys 0.02 ( 4%) > wall 424 kB ( 9%) ggc > llvm backend functions: 0.03 ( 9%) usr 0.00 ( 0%) sys 0.03 ( 6%) > wall 1 kB ( 0%) ggc > llvm backend globals : 0.01 ( 3%) usr 0.00 ( 0%) sys 0.01 ( 2%) > wall 0 kB ( 0%) ggc > llvm backend per file : 0.17 (53%) usr 0.01 ( 6%) sys 0.18 (36%) > wall 0 kB ( 0%) ggc > TOTAL : 0.32 0.17 0.50 4953 kB > > > 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 tonic at nondot.org Sat Feb 16 16:35:19 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sat, 16 Feb 2008 14:35:19 -0800 Subject: [LLVMdev] [llvm-testresults] Grawp-PIC i386 nightly tester results In-Reply-To: <7A2F8C3F-37D7-4EAE-8B23-5470F0578CF5@apple.com> References: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> <887ED4AD-8F74-49DA-8D9C-A052C8EF21F1@apple.com> <4A95844A-AA6A-4BE9-819D-A2DBDA96A09D@apple.com> <7A2F8C3F-37D7-4EAE-8B23-5470F0578CF5@apple.com> Message-ID: On Feb 16, 2008, at 12:55 PM, Dale Johannesen wrote: >> >> Using built-in specs. >> Target: i686-apple-darwin9 >> Configured with: /tmp/llvmgcc42.r46865.roots/llvmgcc42.r46865~obj/ >> src/configure --disable-checking --enable-werror --prefix=/Developer/ >> usr/llvm-gcc-4.2 --mandir=/Developer/usr/llvm-gcc-4.2/share/man -- >> enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program- >> transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-gxx-include-dir=/usr/ >> include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 >> --enable-llvm=/usr/local --host=i686-apple-darwin9 --target=i686- >> apple-darwin9 >> Thread model: posix >> gcc version 4.2.1 (Based on Apple Inc. build 5546) (LLVM build 9999) >> >> It's 4.2 based llvm-gcc. > > > Ok, so the gcc line on the tester web pages is worse than useless. > The gcc line is not useless. Its helpful if you want to figure out build errors, cbe errors, or when looking at performance numbers (compared to gcc). -Tanya > Works for me. Make sure your llvm-gcc-4.2 is up to date, you need > r47180. The r46865 above suggests you might not have it. > > > _______________________________________________ > 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 Feb 16 16:47:41 2008 From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=) Date: Sun, 17 Feb 2008 00:47:41 +0200 Subject: [LLVMdev] linux/x86-64 codegen support In-Reply-To: <85dfcd7f0802161427n3b0f95cdn6c41fd604d47b319@mail.gmail.com> References: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> <85dfcd7f0802161316o7e8d387bp7edb94dc61d6e214@mail.gmail.com> <85dfcd7f0802161344i535378a1pb9110be7328b671@mail.gmail.com> <47B760F5.9020902@gmail.com> <85dfcd7f0802161427n3b0f95cdn6c41fd604d47b319@mail.gmail.com> Message-ID: <47B7680D.5060402@gmail.com> Andrew Lenharth wrote: > See the bug for a reduction and the gimple trees. validate_arglist > definately is rejecting the arglist in EmitBuiltinAlloca. > > (try: > bool TreeToLLVM::EmitBuiltinAlloca(tree exp, Value *&Result) { > tree arglist = TREE_OPERAND(exp, 1); > if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) { > debug_tree(arglist); > return false; > } > Value *Amt = Emit(TREE_VALUE(arglist), 0); > Amt = CastToSIntType(Amt, Type::Int32Ty); > Result = Builder.CreateAlloca(Type::Int8Ty, Amt, "tmp"); > return true; > } > for a pretty (?) print of the tree at that point) > > Thanks, I am seeing a similar tree too. (with an extra pointertype instead of void). Best regards, --Edwin From sabre at nondot.org Sat Feb 16 17:22:04 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 16 Feb 2008 15:22:04 -0800 Subject: [LLVMdev] linux/x86-64 codegen support In-Reply-To: <85dfcd7f0802161427n3b0f95cdn6c41fd604d47b319@mail.gmail.com> References: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> <85dfcd7f0802161316o7e8d387bp7edb94dc61d6e214@mail.gmail.com> <85dfcd7f0802161344i535378a1pb9110be7328b671@mail.gmail.com> <47B760F5.9020902@gmail.com> <85dfcd7f0802161427n3b0f95cdn6c41fd604d47b319@mail.gmail.com> Message-ID: On Feb 16, 2008, at 2:27 PM, Andrew Lenharth wrote: > See the bug for a reduction and the gimple trees. validate_arglist > definately is rejecting the arglist in EmitBuiltinAlloca. > > (try: > bool TreeToLLVM::EmitBuiltinAlloca(tree exp, Value *&Result) { > tree arglist = TREE_OPERAND(exp, 1); > if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) { > debug_tree(arglist); > return false; > } > Value *Amt = Emit(TREE_VALUE(arglist), 0); > Amt = CastToSIntType(Amt, Type::Int32Ty); > Result = Builder.CreateAlloca(Type::Int8Ty, Amt, "tmp"); > return true; > } > for a pretty (?) print of the tree at that point) This is very strange. I built a cross compiler to x86_64-unknown- linux-gnu and it seems to work for me: ./cc1 /Users/sabre/pr1711.c -emit-llvm -quiet -O2 -o - target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64- f80:128:128" target triple = "x86_64-unknown-linux-gnu" %struct.cpp_reader = type opaque define i32 @_cpp_interpret_identifier(%struct.cpp_reader* %pfile, i8* %id, i64 %len) nounwind { entry: ret i32 undef } -Chris From andrewl at lenharth.org Sat Feb 16 17:31:21 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sat, 16 Feb 2008 17:31:21 -0600 Subject: [LLVMdev] linux/x86-64 codegen support In-Reply-To: References: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> <85dfcd7f0802161316o7e8d387bp7edb94dc61d6e214@mail.gmail.com> <85dfcd7f0802161344i535378a1pb9110be7328b671@mail.gmail.com> <47B760F5.9020902@gmail.com> <85dfcd7f0802161427n3b0f95cdn6c41fd604d47b319@mail.gmail.com> Message-ID: <85dfcd7f0802161531u2eb0c772mdbbc662b6b864ddd@mail.gmail.com> On 2/16/08, Chris Lattner wrote: > > This is very strange. I built a cross compiler to x86_64-unknown- > linux-gnu and it seems to work for me: > > ./cc1 /Users/sabre/pr1711.c -emit-llvm -quiet -O2 -o - > > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- > i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64- > f80:128:128" > target triple = "x86_64-unknown-linux-gnu" > %struct.cpp_reader = type opaque > > define i32 @_cpp_interpret_identifier(%struct.cpp_reader* %pfile, i8* > %id, i64 %len) nounwind { > entry: > ret i32 undef > } This is what I get with the non-bootstrap version. Andrew From sabre at nondot.org Sat Feb 16 18:03:22 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 16 Feb 2008 16:03:22 -0800 Subject: [LLVMdev] linux/x86-64 codegen support In-Reply-To: <85dfcd7f0802161531u2eb0c772mdbbc662b6b864ddd@mail.gmail.com> References: <13165B09-3F7F-4A52-BE70-0B0684204FA2@nondot.org> <85dfcd7f0802161316o7e8d387bp7edb94dc61d6e214@mail.gmail.com> <85dfcd7f0802161344i535378a1pb9110be7328b671@mail.gmail.com> <47B760F5.9020902@gmail.com> <85dfcd7f0802161427n3b0f95cdn6c41fd604d47b319@mail.gmail.com> <85dfcd7f0802161531u2eb0c772mdbbc662b6b864ddd@mail.gmail.com> Message-ID: On Feb 16, 2008, at 3:31 PM, Andrew Lenharth wrote: > On 2/16/08, Chris Lattner wrote: >> >> This is very strange. I built a cross compiler to x86_64-unknown- >> linux-gnu and it seems to work for me: >> >> ./cc1 /Users/sabre/pr1711.c -emit-llvm -quiet -O2 -o - >> >> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- >> i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- >> s0:64:64- >> f80:128:128" >> target triple = "x86_64-unknown-linux-gnu" >> %struct.cpp_reader = type opaque >> >> define i32 @_cpp_interpret_identifier(%struct.cpp_reader* %pfile, i8* >> %id, i64 %len) nounwind { >> entry: >> ret i32 undef >> } > > This is what I get with the non-bootstrap version. Ahh, ok. Somehow I didn't understand that this only happens when bootstrapping. It appears that the front-end builds file with -- disable-bootstrap. In this case, I can guess what is going on. This is probably due to the fact that llvm does not currently obey the X86-64 abi in some cases, particularly with respect to struct return. When bootstrapping, the C++ parts of the front-end are built with the native gcc compiler and the c parts are built with the bootstrapped C+ + compiler. We're planning to fix the x86-64 abi issues (or make them much closer) for llvm 2.3, so I guess we'll have to wait for this (it's a big project). Until then, using --disable-bootstrap is a reasonable workaround. Thanks for the help everyone! -Chris From sabre at nondot.org Sat Feb 16 18:46:28 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 16 Feb 2008 16:46:28 -0800 Subject: [LLVMdev] amd64, FreeBSD and shared libraries In-Reply-To: <47B655CD.6080909@cokane.org> References: <47B655CD.6080909@cokane.org> Message-ID: <8AB70FDD-9A67-413C-97A1-0C3BFC533E5D@nondot.org> On Feb 15, 2008, at 7:17 PM, Coleman Kane wrote: > Hello, > > I am trying to build llvm-gcc 4.2 w/ llvm 2.2 on FreeBSD/amd64 and > have > found that it doesn't seem to want to build shared libraries. I've > found > numerous notes that I should try --disable-shared, because the linker > ends up erroring out with a linker error when building libgcc_s.so. > Subsequently, the same error is produced when it attempts to build > libstdc++.so. If you do happen to build and install it, any attempt to > link a shared library results in this very same behavior. The > crtbeginS.o object seems to contain the offending relocation data > which > ld doesn't like. This is due to http://llvm.org/PR1711. Please try configuring with -- disable-shared and --disable-bootstrap. -Chris From cokane at cokane.org Sat Feb 16 19:11:45 2008 From: cokane at cokane.org (Coleman Kane) Date: Sat, 16 Feb 2008 20:11:45 -0500 Subject: [LLVMdev] amd64, FreeBSD and shared libraries In-Reply-To: <200802160930.08156.baldrick@free.fr> References: <47B655CD.6080909@cokane.org> <200802160930.08156.baldrick@free.fr> Message-ID: <47B789D1.7000006@cokane.org> Duncan Sands wrote: > Try --disable-multilib > > Ciao, > > Duncan. > The configure line for this build was: env CPPFLAGS=-fPIC CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure --enable-llvm=/home/cokane/src/llvm-2.2/Release --prefix=/home/cokane/llvm-root --enable-languages=c,c++ --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --enable-shared --enable-pic --with-pic --disable-bootstrap --disable-multilib I am aware that I *can* get the compiler to build if I also --disable-shared. This, however, just hides the fact that the linker won't link crtbeginS.o to a shared library (as the GCC build doesn't end up building any). When I later go to build shared libraries, it fails linking with the same error message. So it seems that the compiler can only be used for statically linked projects, in my case. -- Coleman From christian.plessl at uni-paderborn.de Sun Feb 17 06:42:08 2008 From: christian.plessl at uni-paderborn.de (Christian Plessl) Date: Sun, 17 Feb 2008 13:42:08 +0100 Subject: [LLVMdev] speeding up compilation and link time In-Reply-To: <16f40f0802161214r2bbe0d90o859434cccab5de15@mail.gmail.com> References: <16f40f0802161214r2bbe0d90o859434cccab5de15@mail.gmail.com> Message-ID: <2D6B0E98-9BAE-4DF5-8063-0216168F7CAA@uni-paderborn.de> > Does anyone have any ideas or tips on how to shorten the time to > build? I am building a new tool (in the llvm/projects directory) and > it takes minutes to fully build the project, possibly because it > uses lots of templates and boost & stl libraries and I am using a > slow machine. Specifically, I am looking for ways to change the > Makefile and use precompiled headers and incremental linking, but > still can't figure out how the Makefile is structured. You may try to use a compiler cache, such as ccache (http://ccache.samba.org ). While compiler caches can significantly reduce compilation time I guess that linking time will not be affected much. Cheers, Christian From asl at math.spbu.ru Sun Feb 17 07:13:08 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 17 Feb 2008 16:13:08 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?c3BlZWRpbmcgdXAgY29tcGlsYXRpb24gYW5kIGxpbmsg?= =?koi8-r?b?dGltZQ==?= Message-ID: <200802171313.m1HDD8e7060367@star.math.spbu.ru> > You may try to use a compiler cache, such as ccache (http://ccache.samba.org > ). While compiler caches can significantly reduce compilation time I > guess that linking time will not be affected much. I used ccache on one of my windows boxes and it greatly reduced compilation time for small incremental changes. -- WBR, Anton Korobeynikov From idadesub at users.sourceforge.net Sun Feb 17 16:06:42 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sun, 17 Feb 2008 14:06:42 -0800 Subject: [LLVMdev] llvm 2.2 build problems Message-ID: <1ef034530802171406w687f307bpd470382e0c9fb9bf@mail.gmail.com> I'm getting an error when trying to build llvm 2.2's tblgen: llvm[2]: Linking Release executable tblgen (without symbols) /usr/bin/ld: Undefined symbols: llvm::MemoryBuffer::getFileOrSTDIN(char const*, unsigned int, std::basic_string, std::allocator >*, long long) llvm::cl::ParseCommandLineOptions(int, char**, char const*) It's being run with this to configure: "./configure --prefix=/opt/local --enable-optimized --enable-jit" and this to build: "make tools-only" What am I doing wrong? I'm on an intel macbook pro running 10.4.11. Finally, here's the full build log: llvm[1]: Compiling Alarm.cpp for Release build llvm[1]: Compiling Disassembler.cpp for Release build llvm[1]: Compiling DynamicLibrary.cpp for Release build llvm[1]: Compiling IncludeFile.cpp for Release build llvm[1]: Compiling MappedFile.cpp for Release build llvm[1]: Compiling Memory.cpp for Release build llvm[1]: Compiling Mutex.cpp for Release build llvm[1]: Compiling Path.cpp for Release build llvm[1]: Compiling Process.cpp for Release build llvm[1]: Compiling Program.cpp for Release build llvm[1]: Compiling Signals.cpp for Release build llvm[1]: Compiling TimeValue.cpp for Release build llvm[1]: Compiling ltdl.c for Release build llvm[1]: Building Release Archive Library libLLVMSystem.a llvm[1]: Compiling APFloat.cpp for Release build APFloat.cpp: In constructor 'llvm::APFloat::APFloat(const llvm::fltSemantics&, const char*)': APFloat.cpp:680: warning: control may reach end of non-void function 'llvm::APFloat::opStatus llvm::APFloat::convertFromString(const char*, llvm::APFloat::roundingMode)' being inlined llvm[1]: Compiling APInt.cpp for Release build llvm[1]: Compiling Allocator.cpp for Release build llvm[1]: Compiling Annotation.cpp for Release build llvm[1]: Compiling CommandLine.cpp for Release build llvm[1]: Compiling ConstantRange.cpp for Release build llvm[1]: Compiling Debug.cpp for Release build llvm[1]: Compiling Dwarf.cpp for Release build llvm[1]: Compiling FileUtilities.cpp for Release build llvm[1]: Compiling FoldingSet.cpp for Release build llvm[1]: Compiling GraphWriter.cpp for Release build llvm[1]: Compiling IsInf.cpp for Release build llvm[1]: Compiling IsNAN.cpp for Release build llvm[1]: Compiling ManagedStatic.cpp for Release build llvm[1]: Compiling MemoryBuffer.cpp for Release build llvm[1]: Compiling PluginLoader.cpp for Release build llvm[1]: Compiling SlowOperationInformer.cpp for Release build llvm[1]: Compiling SmallPtrSet.cpp for Release build llvm[1]: Compiling Statistic.cpp for Release build llvm[1]: Compiling Streams.cpp for Release build llvm[1]: Compiling StringExtras.cpp for Release build llvm[1]: Compiling StringMap.cpp for Release build llvm[1]: Compiling StringPool.cpp for Release build llvm[1]: Compiling SystemUtils.cpp for Release build llvm[1]: Compiling Timer.cpp for Release build llvm[1]: Building Release Archive Library libLLVMSupport.a llvm[2]: Compiling AsmWriterEmitter.cpp for Release build llvm[2]: Compiling CallingConvEmitter.cpp for Release build llvm[2]: Compiling CodeEmitterGen.cpp for Release build llvm[2]: Compiling CodeGenDAGPatterns.cpp for Release build llvm[2]: Compiling CodeGenInstruction.cpp for Release build llvm[2]: Compiling CodeGenTarget.cpp for Release build llvm[2]: Compiling DAGISelEmitter.cpp for Release build llvm[2]: Compiling InstrEnumEmitter.cpp for Release build llvm[2]: Compiling InstrInfoEmitter.cpp for Release build llvm[2]: Compiling IntrinsicEmitter.cpp for Release build llvm[2]: Compiling Record.cpp for Release build llvm[2]: Compiling RegisterInfoEmitter.cpp for Release build llvm[2]: Compiling SubtargetEmitter.cpp for Release build llvm[2]: Compiling TGLexer.cpp for Release build llvm[2]: Compiling TGParser.cpp for Release build llvm[2]: Compiling TableGen.cpp for Release build llvm[2]: Compiling TableGenBackend.cpp for Release build llvm[2]: Linking Release executable tblgen (without symbols) /usr/bin/ld: Undefined symbols: llvm::MemoryBuffer::getFileOrSTDIN(char const*, unsigned int, std::basic_string, std::allocator >*, long long) llvm::cl::ParseCommandLineOptions(int, char**, char const*) collect2: ld returned 1 exit status Thanks! From idadesub at users.sourceforge.net Sun Feb 17 19:00:48 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sun, 17 Feb 2008 17:00:48 -0800 Subject: [LLVMdev] llvm 2.2 build problems In-Reply-To: <1ef034530802171406w687f307bpd470382e0c9fb9bf@mail.gmail.com> References: <1ef034530802171406w687f307bpd470382e0c9fb9bf@mail.gmail.com> Message-ID: <1ef034530802171700l78fb8cd0x384e571ee4b04c47@mail.gmail.com> It turns out my problem was that I still had llvm-2.0 installed, and I'm guessing the build script was finding 2.0's libLLVMSupport.a instead of the one that was just built. I think this happened because macports (which I'm making the llvm build script for) specifies these environment variables: CFLAGS='-O2' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-O2' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-O2' LDFLAGS='-L/opt/local/lib' FCFLAGS='-O2' OBJC='/usr/bin/gcc-4.0' INSTALL='/usr/bin/install' OBJCFLAGS='-O2' FFLAGS='-O2' CC='/usr/bin/gcc-4.0' If I run the build without CPPFLAGS='-I/opt/local/include' and LDFLAGS='-L/opt/local/lib' specified it builds fine. Is there anything that could be changed so that this conflict doesn't happen again? From ted at tedneward.com Mon Feb 18 01:40:30 2008 From: ted at tedneward.com (Ted Neward) Date: Sun, 17 Feb 2008 23:40:30 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com> Message-ID: <001101c87201$8bd624a0$a3826de0$@com> By the way, somebody (I think it was Chuck, but I don't remember for certain) was asking for the BuildLog.htm from building the llvm.sln file under VS 2005 SP1 for diagnostic purposes; right now the SLN is configured to produce a new BuildLog for each and every one of the projects inside the solution. I don't know who's responsible for this guy, but that's probably not the best way to do this. Chuck (assuming it was you), would it not be easier for me to capture the full results of an "msbuild llvm.sln" from the console for you? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Chuck Rose III > Sent: Wednesday, February 13, 2008 8:52 AM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > I have always built it with flex and bison installed, though I believe > Chris removed our last dependence on flex a little while back, so you > may not need that. I'm using bison 2.1 which I got from the > getgnuwin32 > folks. I imagine that if you have cygwin or the like, you probably > already have everything. > > You will need to have the executables in your path. > > I build with VisualStudio 2k5 Professional with VStudio SP1 installed. > I typically work on Vista32 or Vista64, but have compiled on XP as > well. > > > I don't know how up to date the LLVM docs related to Visual Studio > compilation are. > > Thanks, > Chuck. > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Seung Jae Lee > Sent: Tuesday, February 12, 2008 9:52 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > Thanks for your comment. > I also tried for LLVM 2.2 but got the same compilation errors on > VS2005. > (I didn't modify anything before the compilation) > > I just wonder if I need bison and flex even just in the case of > compiling them on VS2005 without changing anything because the LLVM doc > says "If you plan to modify any .y or .l files, you will need to have > bison and/or flex installed where Visual Studio can find them. > Otherwise, you do not need them and the pre-generated files that come > with the source tree will be used." > > One of errors of mine is as follows: > ------------------------------------------------------- > ... > 7>llvmAsmParser.cpp > 7>c1xx : fatal error C1083: Cannot open source file: > '.\llvmAsmParser.cpp': No such file or directory > ... > ------------------------------------------------------- > where llvmAsmParser.cpp is related to Bison so I am compelled to feel > to > try installing flex/bison on my machine, anyway. > > Forgive my ignorance, could you briefly tell me about that? > Thank you in advance. > > Seung > > ---- Original message ---- > >Date: Tue, 12 Feb 2008 18:20:59 -0800 > >From: "Chuck Rose III" > >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > 2005? > >To: "LLVM Developers Mailing List" > > > >Hola Seung, > > > >I don't know if 2.1 in particular worked. I updated the 2.2 win32 > >vstudio 2k5 files right before lockdown, so they should be building. > >You will need appropriate versions of flex and bison installed. I > used > >the ones from getgnuwin32 on my machine. > > > >Good luck. > > > >Chuck. > > > >-----Original Message----- > >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > >On Behalf Of Seung Jae Lee > >Sent: Monday, February 11, 2008 10:05 PM > >To: llvmdev at cs.uiuc.edu > >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > >2005? > > > >Hello all, > > > >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? > >I did but not succeed due to some build errors. > >I seem to remember I read somewhere on this list it's compiled on > VS2005 > >so I wonder... > >Have a good night. > > > >Thx, > >Seung > >_______________________________________________ > >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 > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: > 2/13/2008 9:41 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: 2/17/2008 2:39 PM From ted at tedneward.com Mon Feb 18 02:11:34 2008 From: ted at tedneward.com (Ted Neward) Date: Mon, 18 Feb 2008 00:11:34 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <001101c87201$8bd624a0$a3826de0$@com> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com> <001101c87201$8bd624a0$a3826de0$@com> Message-ID: <002001c87205$e31b28b0$a9517a10$@com> More on this: Walking through the projects slowly: (*) "Configure" builds with no problem. (*) "support" fails: C:\Prg\llvm-2.2\llvm-2.2\win32>msbuild llvm.sln /t:Build Microsoft (R) Build Engine Version 2.0.50727.1433 [Microsoft .NET Framework, Version 2.0.50727.1433] Copyright (C) Microsoft Corporation 2005. All rights reserved. Build started 2/18/2008 12:07:45 AM. __________________________________________________ Project "C:\Prg\llvm-2.2\llvm-2.2\win32\llvm.sln" (Build target(s)): Target ValidateSolutionConfiguration: Building solution configuration "Debug|Win32". Target Build: Target Configure: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\..\..\vc\vcpackag es\vcbuild.exe C:\Prg\llvm-2.2\llvm-2.2\win32\Configure\Configure.vcproj "Config ure|Win32" Target support: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\..\..\vc\vcpackag es\vcbuild.exe C:\Prg\llvm-2.2\llvm-2.2\win32\Support\Support.tmp_Debug_Win32.vc proj "Debug|Win32" ..\..\lib\Support\IsInf.cpp(46): error C3861: 'isinf': identifier not fo und ..\..\lib\Support\IsInf.cpp(47): error C3861: 'isinf': identifier not fo und ..\..\lib\Support\IsNAN.cpp(31): error C3861: 'isnan': identifier not fo und ..\..\lib\Support\IsNAN.cpp(32): error C3861: 'isnan': identifier not fo und Done building target "support" in project "llvm.sln" -- FAILED. It looks like there's some kind of configuration that's failing here, because for some reason IsInf.cpp thinks that my machine has isinf() defined, when in fact there isn't any. It seems that some #defines in config.h in include/llvm/Config are controlling this: /* Set to 1 if the isinf function is found in */ #define HAVE_ISINF_IN_MATH_H 1 /* Set to 1 if the isnan function is found in */ /* #undef HAVE_ISNAN_IN_CMATH */ /* Set to 1 if the isnan function is found in */ #define HAVE_ISNAN_IN_MATH_H 1 But I'm guessing that somehow this is supposed to be manipulated by the build process, not by hand. Am I wrong in this? There's a config.h file in the win32 subdirectory that implies that it's supposed to be concatenated as part of the build process, but it doesn't seem like that's happening from within the .sln script--am I missing a pre-build step someplace? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Ted Neward > Sent: Sunday, February 17, 2008 11:41 PM > To: 'LLVM Developers Mailing List' > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > By the way, somebody (I think it was Chuck, but I don't remember for > certain) was asking for the BuildLog.htm from building the llvm.sln > file > under VS 2005 SP1 for diagnostic purposes; right now the SLN is > configured > to produce a new BuildLog for each and every one of the projects inside > the > solution. I don't know who's responsible for this guy, but that's > probably > not the best way to do this. > > Chuck (assuming it was you), would it not be easier for me to capture > the > full results of an "msbuild llvm.sln" from the console for you? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > > On Behalf Of Chuck Rose III > > Sent: Wednesday, February 13, 2008 8:52 AM > > To: LLVM Developers Mailing List > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > > 2005? > > > > I have always built it with flex and bison installed, though I > believe > > Chris removed our last dependence on flex a little while back, so you > > may not need that. I'm using bison 2.1 which I got from the > > getgnuwin32 > > folks. I imagine that if you have cygwin or the like, you probably > > already have everything. > > > > You will need to have the executables in your path. > > > > I build with VisualStudio 2k5 Professional with VStudio SP1 > installed. > > I typically work on Vista32 or Vista64, but have compiled on XP as > > well. > > > > > > I don't know how up to date the LLVM docs related to Visual Studio > > compilation are. > > > > Thanks, > > Chuck. > > > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > > On Behalf Of Seung Jae Lee > > Sent: Tuesday, February 12, 2008 9:52 PM > > To: llvmdev at cs.uiuc.edu > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > > 2005? > > > > Thanks for your comment. > > I also tried for LLVM 2.2 but got the same compilation errors on > > VS2005. > > (I didn't modify anything before the compilation) > > > > I just wonder if I need bison and flex even just in the case of > > compiling them on VS2005 without changing anything because the LLVM > doc > > says "If you plan to modify any .y or .l files, you will need to have > > bison and/or flex installed where Visual Studio can find them. > > Otherwise, you do not need them and the pre-generated files that come > > with the source tree will be used." > > > > One of errors of mine is as follows: > > ------------------------------------------------------- > > ... > > 7>llvmAsmParser.cpp > > 7>c1xx : fatal error C1083: Cannot open source file: > > '.\llvmAsmParser.cpp': No such file or directory > > ... > > ------------------------------------------------------- > > where llvmAsmParser.cpp is related to Bison so I am compelled to feel > > to > > try installing flex/bison on my machine, anyway. > > > > Forgive my ignorance, could you briefly tell me about that? > > Thank you in advance. > > > > Seung > > > > ---- Original message ---- > > >Date: Tue, 12 Feb 2008 18:20:59 -0800 > > >From: "Chuck Rose III" > > >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > > Studio > > 2005? > > >To: "LLVM Developers Mailing List" > > > > > >Hola Seung, > > > > > >I don't know if 2.1 in particular worked. I updated the 2.2 win32 > > >vstudio 2k5 files right before lockdown, so they should be building. > > >You will need appropriate versions of flex and bison installed. I > > used > > >the ones from getgnuwin32 on my machine. > > > > > >Good luck. > > > > > >Chuck. > > > > > >-----Original Message----- > > >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > > >On Behalf Of Seung Jae Lee > > >Sent: Monday, February 11, 2008 10:05 PM > > >To: llvmdev at cs.uiuc.edu > > >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > > >2005? > > > > > >Hello all, > > > > > >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? > > >I did but not succeed due to some build errors. > > >I seem to remember I read somewhere on this list it's compiled on > > VS2005 > > >so I wonder... > > >Have a good night. > > > > > >Thx, > > >Seung > > >_______________________________________________ > > >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 > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: > > 2/13/2008 9:41 AM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > 2/17/2008 > 2:39 PM > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > 2/17/2008 2:39 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: 2/17/2008 2:39 PM From evan.cheng at apple.com Mon Feb 18 02:15:22 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 18 Feb 2008 00:15:22 -0800 Subject: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build In-Reply-To: <680422C0AA225644931C2F6DD07200DD018DCEC4@namail5.corp.adobe.com> References: <680422C0AA225644931C2F6DD07200DD01897697@namail5.corp.adobe.com> <680422C0AA225644931C2F6DD07200DD018DCEC4@namail5.corp.adobe.com> Message-ID: Ah, ok. x86-64 JIT assumes large code size model, i.e. it cannot assume the GV displacement would fit in the 32-bit direct call field. So it's using an indirect call. But I think that's fine. I think the problem you are running into has to do with JIT function stub. In lazy compilation mode (which is the default), functions are compiled on demand when they are called. So a function call is actually emitted as a call to a target specific function stub. See X86CompilationCallback() in X86JITInfo.cpp. These are the functions that save registers and then call JIT to lazily compile the call destination. I am not sure if it has been tested on x86-64 Windows. Anton, do you know? Meanwhile, can you try to disable lazy compilation? See ExecutionEngine.h::DisableLazyCompilation(). Evan On Feb 15, 2008, at 11:00 AM, Chuck Rose III wrote: > Hey Evan, > > At the point of the instructions you suggested I step through, > X86ISelLowering has this state: > > - this 0x00000000005fe728 > {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 > VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * > const > + llvm::TargetLowering {TM={...} > TD=0x00000000008edac0 IsLittleEndian=true ...} > llvm::TargetLowering > VarArgsFrameIndex > -842150451 int > RegSaveFrameIndex > -842150451 int > VarArgsGPOffset > 3452816845 unsigned int > VarArgsFPOffset > 3452816845 unsigned int > BytesToPopOnReturn 0 > int > BytesCallerReserves > 0 int > - Subtarget > 0x00000000008eda90 {AsmFlavor=Intel PICStyle=None > X86SSELevel=SSE2 ...} const llvm::X86Subtarget * > + llvm::TargetSubtarget {...} > llvm::TargetSubtarget > AsmFlavor Intel > llvm::X86Subtarget::AsmWriterFlavorTy > PICStyle None > llvm::PICStyle::Style > X86SSELevel SSE2 > llvm::X86Subtarget::X86SSEEnum > X863DNowLevel > -842150451 llvm::X86Subtarget::X863DNowEnum > HasX86_64 true bool > DarwinVers 0 > unsigned char > stackAlignment 8 > unsigned int > MaxInlineSizeThreshold > 128 unsigned int > Is64Bit true bool > HasLow4GUserAddress > true bool > TargetType > isWindows llvm::X86Subtarget:: > > > if (GlobalAddressSDNode *G = > dyn_cast(Callee)) { > // We should use extra load for direct calls to dllimported > functions in > // non-JIT mode. > // it get?s into here > if ((IsTailCall || !Is64Bit || // both these are false > getTargetMachine().getCodeModel() != CodeModel::Large) // > this is false > && !Subtarget->GVRequiresExtraLoad(G->getGlobal(), // this > is short circuited away > getTargetMachine(), true)) > Callee = DAG.getTargetGlobalAddress(G->getGlobal(), > getPointerTy()); // this is passed over because the test is false > > // since it made it through the if (Global?., it skips down to > > // Returns a chain & a flag for retval copy to use. > SDVTList NodeTys = DAG.getVTList(MVT::Other, MVT::Flag); > > > Thanks! > > Chuck. > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of Evan Cheng > Sent: Friday, February 15, 2008 9:35 AM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build > > > On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > > > Hola LLVMers, > > I?m debugging through some strangeness that I?m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I?ve otherwise > left LLVM 2.2 alone. The basic idea is that I?ve got a function bar > which is compiled by VStudio and I?m creating another function foo > via LLVM JIT which is going to call into bar. This has been working > for me for a long time on win32 and also under xcode of course. > I?ve included the code that generates the situation at the bottom. > Some questions (which may be really brain dead) are: > > 1. Why isn?t the stack getting set up in foo prior to the call > down into bar? > > What is the triplet of the target? x86_64-win32? > > > 2. Why is the call to bar a pointer to a jump. I.e. why > didn?t it resolve the address in foo? > > Not sure. I can't reproduce this. Can you step through the code in > X86ISelLowering.cpp::LowerCALL()? Around > // If the callee is a GlobalAddress node (quite common, every > direct call is) > // turn it into a TargetGlobalAddress node so that legalize > doesn't hack it. > > Evan > > > 3. What are some good places for me to be looking to try and > drill down further on what?s happening? I?ve tried switching > calling conventions and have watched it create machine instructions > for adjusting the stack up and down, but they seem to be removed by > the time it actually gets down to execution time. > > Any suggestions would be appreciated. > > Thanks, > Chuck. > > Call into function (foo) > 0000000000980030 mov rax,140001591h > 000000000098003A call rax ? this is > calling to bar via a jump table > 000000000098003C ret > > Leads to > 0000000140001591 jmp bar (1400064E0h) > > Leads to > void bar(int i) > { > 00000001400064E0 mov dword ptr [rsp+8],ecx > 00000001400064E4 push rdi > 00000001400064E5 sub rsp,20h > 00000001400064E9 mov rdi,rsp > 00000001400064EC mov rcx,8 > 00000001400064F6 mov eax,0CCCCCCCCh > 00000001400064FB rep stos dword ptr [rdi] > 00000001400064FD mov ecx,dword ptr [rsp+30h] > printf("the int is %i\n",i); > 0000000140006501 mov edx,dword ptr [i] > 0000000140006505 lea rcx,[string "the int is %i > \n" (140C1A240h)] > 000000014000650C call qword ptr [__imp_printf (141145920h)] > } > 0000000140006512 add rsp,20h > 0000000140006516 pop rdi > 0000000140006517 ret > > At this point, we seem to be jumping back up but the stack is no > longer in order, so > 000000000098003C ret > > Takes us into wonderland > 0000000100000003 ??? > > But unfortunately not through the looking glass. > > Here?s the modification of the Fibonacci program which got me the > above: > #include "llvm/Module.h" > #include "llvm/DerivedTypes.h" > #include "llvm/Constants.h" > #include "llvm/Instructions.h" > #include "llvm/ModuleProvider.h" > #include "llvm/Analysis/Verifier.h" > #include "llvm/ExecutionEngine/JIT.h" > #include "llvm/ExecutionEngine/Interpreter.h" > #include "llvm/ExecutionEngine/GenericValue.h" > #include "llvm/System/DynamicLibrary.h" > #include "llvm/CallingConv.h" > #include > #include > using namespace llvm; > > void bar(int i) > { > printf("the int is %i\n",i); > } > > Function* createBarFunction(Module* M) > { > Function* pBarF = cast(M->getOrInsertFunction("bar", > Type::VoidTy, Type::Int32Ty, NULL)); > return pBarF; > } > > Function* createFooFunction(Module* M) > { > Function* pBarF = createBarFunction(M), > * pFooF; > > pFooF = cast(M->getOrInsertFunction("foo", > Type::VoidTy, Type::Int32Ty, NULL)); > BasicBlock* pBody = new BasicBlock("body",pFooF); > Argument* pArg = pFooF->arg_begin(); > pArg->setName("i"); > std::vector barArgs; > barArgs.push_back(pArg); > new CallInst(pBarF, barArgs.begin(), barArgs.end(), "", pBody); > new ReturnInst(NULL, pBody); > return pFooF; > } > > int main(int argc, char **argv) { > // Create some module to put our function into it. > Module *M = new Module("test"); > > M->setDataLayout("e-p:64:64:64-i1:8:8:8-i8:8:8:8-i32:32:32:32- > f32:32:32:32"); > Function* pFooF = createFooFunction(M); > M->print(std::cout); > > // Now we going to create JIT > ExistingModuleProvider *MP = new ExistingModuleProvider(M); > ExecutionEngine *EE = ExecutionEngine::create(MP, false); > > sys::DynamicLibrary::AddSymbol("bar", (void*) bar); > llvm::Module::FunctionListType& funcList = MP->getModule()- > >getFunctionList(); > > for (llvm::Module::FunctionListType::iterator i = > funcList.begin() ; i != funcList.end() ; ++i) > { > EE->getPointerToFunction(i); > } > > EE->recompileAndRelinkFunction(pFooF); > > std::vector Args(1); > Args[0].IntVal = APInt(32, 3); > GenericValue GV = EE->runFunction(pFooF, Args); > > return 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080218/6b758141/attachment-0001.html From asl at math.spbu.ru Mon Feb 18 02:23:37 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Mon, 18 Feb 2008 11:23:37 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?TExWTTIuMiB4NjQgSklUIHRyb3VibGUgb24gVlN0dWRp?= =?koi8-r?b?byBidWlsZA==?= Message-ID: <200802180823.m1I8NbJQ016535@star.math.spbu.ru> Hello, Evan > I am not sure if it has been tested on x86-64 Windows. > Anton, do you know? I don't think it was ever written (for vcpp). There is 32-bit stub only. -- WBR, Anton Korobeynikov From evan.cheng at apple.com Mon Feb 18 02:45:18 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 18 Feb 2008 00:45:18 -0800 Subject: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build In-Reply-To: <200802180823.m1I8NbJQ016535@star.math.spbu.ru> References: <200802180823.m1I8NbJQ016535@star.math.spbu.ru> Message-ID: <735159AD-61AC-4AB6-9E9B-C1CF73FD4DBD@apple.com> The x86-64 one probably doesn't work for Winodws. That's likely the issue. Evan On Feb 18, 2008, at 12:23 AM, Anton Korobeynikov wrote: > Hello, Evan >> I am not sure if it has been tested on x86-64 Windows. >> Anton, do you know? > I don't think it was ever written (for vcpp). There is 32-bit stub > only. > > -- > WBR, Anton Korobeynikov From asl at math.spbu.ru Mon Feb 18 02:51:09 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Mon, 18 Feb 2008 11:51:09 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?TExWTTIuMiB4NjQgSklUIHRyb3VibGUgb24gVlN0dWRp?= =?koi8-r?b?byBidWlsZA==?= Message-ID: <200802180851.m1I8p9mV092277@star.math.spbu.ru> > The x86-64 one probably doesn't work for Winodws. That's likely the > issue. Well, x86-64 stub was never ported to intel assembler, I expect to see 32-bit one used on windows64. In general, the whole windows64 support is missed mainly due to crazy calling convetion invented by Microsoft. So, all calls from code being JITed to external functions will be clearly broken (if they will use 'normal' CC and pass args in the registers). -- WBR, Anton Korobeynikov From kevin.andre at student.ua.ac.be Mon Feb 18 10:09:36 2008 From: kevin.andre at student.ua.ac.be (=?UTF-8?Q?Kevin_Andr=C3=A9?=) Date: Mon, 18 Feb 2008 17:09:36 +0100 Subject: [LLVMdev] cross compiling with the C backend Message-ID: <20d882600802180809q4d8c88fen7822c12c486bd5ae@mail.gmail.com> For my master's thesis, I am trying to cross compile programs for the PSP (PlayStation Portable) with LLVM and llvm-gcc. This is what I do: (1) compile a program and the libraries it uses (libpng etc.) with llvm-gcc (2) link the bitcode files with llvm-ld into one file (3) run "llc -march=c" on the result (4) compile the resulting C source with the PSP toolchain It seems to work with a very simple program (Pi_Calc, calculates Pi and prints it), but it fails when I try it with another program that is a bit more advanced: the PSP hangs when I run the program. Am I using the right approach here? I have compiled llvmgcc-4.2-2.2 on my machine as a native compiler (i686-pc-linux-gnu). Does llvm-gcc have an impact on the portability of the resulting LLVM bitcode? And is the C code generated by the C backend really portable? I use the "-nostdinc" option for llvm-gcc and specify the include paths of the PSP SDK instead. But I still get warnings with llvm-gcc that do not appear with psp-gcc ("passing argument 2 of 'xyz' discards qualifiers from pointer target type"). And the output of the C back end generates lots of warnings as well, or is that expected? What could solve this problem? Do I have to configure llvm-gcc as a cross compiler? MIPS might be a better candidate than the 'i686' from the native configuration. Or could it be simply a bug in llvm-gcc or LLVM? Another option could be to add real support for the PSP to LLVM, though I'm not sure if I'll be able to accomplish that. Regards, -Kevin Andr? From dalej at apple.com Mon Feb 18 11:09:15 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 18 Feb 2008 09:09:15 -0800 Subject: [LLVMdev] [llvm-testresults] Grawp-PIC i386 nightly tester results In-Reply-To: References: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> <887ED4AD-8F74-49DA-8D9C-A052C8EF21F1@apple.com> <4A95844A-AA6A-4BE9-819D-A2DBDA96A09D@apple.com> <7A2F8C3F-37D7-4EAE-8B23-5470F0578CF5@apple.com> Message-ID: On Feb 16, 2008, at 2:35 PM, Tanya Lattner wrote: > On Feb 16, 2008, at 12:55 PM, Dale Johannesen wrote: >>> Using built-in specs. >>> Target: i686-apple-darwin9 >>> Configured with: /tmp/llvmgcc42.r46865.roots/llvmgcc42.r46865~obj/ >>> src/configure --disable-checking --enable-werror --prefix=/ >>> Developer/ >>> usr/llvm-gcc-4.2 --mandir=/Developer/usr/llvm-gcc-4.2/share/man -- >>> enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- -- >>> program- >>> transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-gxx-include-dir=/usr/ >>> include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 >>> --enable-llvm=/usr/local --host=i686-apple-darwin9 --target=i686- >>> apple-darwin9 >>> Thread model: posix >>> gcc version 4.2.1 (Based on Apple Inc. build 5546) (LLVM build 9999) >>> >>> It's 4.2 based llvm-gcc. >> >> >> Ok, so the gcc line on the tester web pages is worse than useless. >> > > The gcc line is not useless. Its helpful if you want to figure out > build errors, cbe errors, or when looking at performance numbers > (compared to gcc). > > -Tanya OK, I am corrected. I do believe the version of %llvmgcc in use would also be useful (for me, more useful). >> Works for me. Make sure your llvm-gcc-4.2 is up to date, you need >> r47180. The r46865 above suggests you might not have it. >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > llvm-testresults mailing list > llvm-testresults at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-testresults From tonic at nondot.org Mon Feb 18 11:49:28 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Mon, 18 Feb 2008 09:49:28 -0800 (PST) Subject: [LLVMdev] [llvm-testresults] Grawp-PIC i386 nightly tester results In-Reply-To: References: <200802161506.m1GF6SLv018372@zion.cs.uiuc.edu> <06637DF6-4737-4D41-AECF-9D593C0D033F@apple.com> <887ED4AD-8F74-49DA-8D9C-A052C8EF21F1@apple.com> <4A95844A-AA6A-4BE9-819D-A2DBDA96A09D@apple.com> <7A2F8C3F-37D7-4EAE-8B23-5470F0578CF5@apple.com> Message-ID: >> > >> > Ok, so the gcc line on the tester web pages is worse than useless. >> > >> >> The gcc line is not useless. Its helpful if you want to figure out >> build errors, cbe errors, or when looking at performance numbers >> (compared to gcc). >> >> -Tanya > > OK, I am corrected. I do believe the version of %llvmgcc in use would also > be useful (for me, more useful). I totally agree that it would be useful. I'll add it to the new nightly tester database and make sure its displayed. I'm not going to update the old one though. -Tanya > >> > Works for me. Make sure your llvm-gcc-4.2 is up to date, you need >> > r47180. The r46865 above suggests you might not have it. >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> llvm-testresults mailing list >> llvm-testresults at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-testresults > From cfr at adobe.com Mon Feb 18 13:57:51 2008 From: cfr at adobe.com (Chuck Rose III) Date: Mon, 18 Feb 2008 11:57:51 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <002001c87205$e31b28b0$a9517a10$@com> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com><001101c87201$8bd624a0$a3826de0$@com> <002001c87205$e31b28b0$a9517a10$@com> Message-ID: <680422C0AA225644931C2F6DD07200DD018DD3FC@namail5.corp.adobe.com> >There's a config.h file in the win32 subdirectory that implies that it's >supposed to be concatenated as part of the build process, but it doesn't >seem like that's happening from within the .sln script--am I missing a >pre-build step someplace? When config.h.in is hit in the build of configure the configure project, the configure.h file from the win32 directory is copied to main llvm\Config\Config.h. The script in the sln file is: copy "$(InputPath)"+"$(SolutionDir)config.h" "$(ProjectDir)..\llvm\Config\config.h" configured as a custom build step in the solution file. Is that not firing from the command line compilation of the sln? The file in the win32 directory is the config.h file that's ultimately used when compiling everything under VStudio. That it implies that it concatenates is outdated information. Ditto for the other .in files in configure. We should probably be doing something more clever here. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ted Neward Sent: Monday, February 18, 2008 12:12 AM To: 'LLVM Developers Mailing List' Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? More on this: Walking through the projects slowly: (*) "Configure" builds with no problem. (*) "support" fails: C:\Prg\llvm-2.2\llvm-2.2\win32>msbuild llvm.sln /t:Build Microsoft (R) Build Engine Version 2.0.50727.1433 [Microsoft .NET Framework, Version 2.0.50727.1433] Copyright (C) Microsoft Corporation 2005. All rights reserved. Build started 2/18/2008 12:07:45 AM. __________________________________________________ Project "C:\Prg\llvm-2.2\llvm-2.2\win32\llvm.sln" (Build target(s)): Target ValidateSolutionConfiguration: Building solution configuration "Debug|Win32". Target Build: Target Configure: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\..\..\vc\vcpackag es\vcbuild.exe C:\Prg\llvm-2.2\llvm-2.2\win32\Configure\Configure.vcproj "Config ure|Win32" Target support: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\..\..\vc\vcpackag es\vcbuild.exe C:\Prg\llvm-2.2\llvm-2.2\win32\Support\Support.tmp_Debug_Win32.vc proj "Debug|Win32" ..\..\lib\Support\IsInf.cpp(46): error C3861: 'isinf': identifier not fo und ..\..\lib\Support\IsInf.cpp(47): error C3861: 'isinf': identifier not fo und ..\..\lib\Support\IsNAN.cpp(31): error C3861: 'isnan': identifier not fo und ..\..\lib\Support\IsNAN.cpp(32): error C3861: 'isnan': identifier not fo und Done building target "support" in project "llvm.sln" -- FAILED. It looks like there's some kind of configuration that's failing here, because for some reason IsInf.cpp thinks that my machine has isinf() defined, when in fact there isn't any. It seems that some #defines in config.h in include/llvm/Config are controlling this: /* Set to 1 if the isinf function is found in */ #define HAVE_ISINF_IN_MATH_H 1 /* Set to 1 if the isnan function is found in */ /* #undef HAVE_ISNAN_IN_CMATH */ /* Set to 1 if the isnan function is found in */ #define HAVE_ISNAN_IN_MATH_H 1 But I'm guessing that somehow this is supposed to be manipulated by the build process, not by hand. Am I wrong in this? There's a config.h file in the win32 subdirectory that implies that it's supposed to be concatenated as part of the build process, but it doesn't seem like that's happening from within the .sln script--am I missing a pre-build step someplace? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Ted Neward > Sent: Sunday, February 17, 2008 11:41 PM > To: 'LLVM Developers Mailing List' > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > By the way, somebody (I think it was Chuck, but I don't remember for > certain) was asking for the BuildLog.htm from building the llvm.sln > file > under VS 2005 SP1 for diagnostic purposes; right now the SLN is > configured > to produce a new BuildLog for each and every one of the projects inside > the > solution. I don't know who's responsible for this guy, but that's > probably > not the best way to do this. > > Chuck (assuming it was you), would it not be easier for me to capture > the > full results of an "msbuild llvm.sln" from the console for you? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > > On Behalf Of Chuck Rose III > > Sent: Wednesday, February 13, 2008 8:52 AM > > To: LLVM Developers Mailing List > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > > 2005? > > > > I have always built it with flex and bison installed, though I > believe > > Chris removed our last dependence on flex a little while back, so you > > may not need that. I'm using bison 2.1 which I got from the > > getgnuwin32 > > folks. I imagine that if you have cygwin or the like, you probably > > already have everything. > > > > You will need to have the executables in your path. > > > > I build with VisualStudio 2k5 Professional with VStudio SP1 > installed. > > I typically work on Vista32 or Vista64, but have compiled on XP as > > well. > > > > > > I don't know how up to date the LLVM docs related to Visual Studio > > compilation are. > > > > Thanks, > > Chuck. > > > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > > On Behalf Of Seung Jae Lee > > Sent: Tuesday, February 12, 2008 9:52 PM > > To: llvmdev at cs.uiuc.edu > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > > 2005? > > > > Thanks for your comment. > > I also tried for LLVM 2.2 but got the same compilation errors on > > VS2005. > > (I didn't modify anything before the compilation) > > > > I just wonder if I need bison and flex even just in the case of > > compiling them on VS2005 without changing anything because the LLVM > doc > > says "If you plan to modify any .y or .l files, you will need to have > > bison and/or flex installed where Visual Studio can find them. > > Otherwise, you do not need them and the pre-generated files that come > > with the source tree will be used." > > > > One of errors of mine is as follows: > > ------------------------------------------------------- > > ... > > 7>llvmAsmParser.cpp > > 7>c1xx : fatal error C1083: Cannot open source file: > > '.\llvmAsmParser.cpp': No such file or directory > > ... > > ------------------------------------------------------- > > where llvmAsmParser.cpp is related to Bison so I am compelled to feel > > to > > try installing flex/bison on my machine, anyway. > > > > Forgive my ignorance, could you briefly tell me about that? > > Thank you in advance. > > > > Seung > > > > ---- Original message ---- > > >Date: Tue, 12 Feb 2008 18:20:59 -0800 > > >From: "Chuck Rose III" > > >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > > Studio > > 2005? > > >To: "LLVM Developers Mailing List" > > > > > >Hola Seung, > > > > > >I don't know if 2.1 in particular worked. I updated the 2.2 win32 > > >vstudio 2k5 files right before lockdown, so they should be building. > > >You will need appropriate versions of flex and bison installed. I > > used > > >the ones from getgnuwin32 on my machine. > > > > > >Good luck. > > > > > >Chuck. > > > > > >-----Original Message----- > > >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > > >On Behalf Of Seung Jae Lee > > >Sent: Monday, February 11, 2008 10:05 PM > > >To: llvmdev at cs.uiuc.edu > > >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > > >2005? > > > > > >Hello all, > > > > > >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? > > >I did but not succeed due to some build errors. > > >I seem to remember I read somewhere on this list it's compiled on > > VS2005 > > >so I wonder... > > >Have a good night. > > > > > >Thx, > > >Seung > > >_______________________________________________ > > >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 > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: > > 2/13/2008 9:41 AM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > 2/17/2008 > 2:39 PM > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > 2/17/2008 2:39 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: 2/17/2008 2:39 PM _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From bruno.cardoso at gmail.com Mon Feb 18 15:08:13 2008 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Mon, 18 Feb 2008 18:08:13 -0300 Subject: [LLVMdev] cross compiling with the C backend In-Reply-To: <20d882600802180809q4d8c88fen7822c12c486bd5ae@mail.gmail.com> References: <20d882600802180809q4d8c88fen7822c12c486bd5ae@mail.gmail.com> Message-ID: <275e64e40802181308h77560725w9ea3fdeb55095191@mail.gmail.com> > What could solve this problem? Do I have to configure llvm-gcc as a > cross compiler? MIPS might be a better candidate than the 'i686' from > the native configuration. Or could it be simply a bug in llvm-gcc or > LLVM? Btw, cross-compiling llvm-gcc for Mips wont work since the support in llvm-gcc isnt ready yet! > Another option could be to add real support for the PSP to LLVM, > though I'm not sure if I'll be able to accomplish that. That would be nice, any improvements to the Mips backend are welcome! =) -- Bruno Cardoso Lopes http://www.brunocardoso.org From deplinenoise at gmail.com Mon Feb 18 15:24:51 2008 From: deplinenoise at gmail.com (Andreas Fredriksson) Date: Mon, 18 Feb 2008 22:24:51 +0100 Subject: [LLVMdev] More address registers In-Reply-To: <3212b1a80802151347j5435f2eeqcae8b8424375ea9d@mail.gmail.com> References: <3212b1a80802151347j5435f2eeqcae8b8424375ea9d@mail.gmail.com> Message-ID: <3212b1a80802181324x476482fas69ecf5d6b131f5a5@mail.gmail.com> 2008/2/15, Andreas Fredriksson : > > I tried mocking this up using the following. (Base is what's returned as > the Ax in the move expression above when the DAG is constructed due to > SelectAddr().) > > SDOperand chain = CurDAG->getCopyToReg(Base, M68K::A3, Base); > Base = CurDAG->getCopyFromReg(chain, M68K::A3, MVT::i32); > Replying to myself here. This worked a bit better :) const unsigned addressReg = RegMap->createVirtualRegister(&M68K::AR32RegClass); SDOperand chain = CurDAG->getCopyToReg(Base, addressReg, Base); Base = CurDAG->getCopyFromReg(chain, addressReg, MVT::i32); // Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080218/abc02ccc/attachment.html From cfr at adobe.com Mon Feb 18 15:25:04 2008 From: cfr at adobe.com (Chuck Rose III) Date: Mon, 18 Feb 2008 13:25:04 -0800 Subject: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build In-Reply-To: <200802180851.m1I8p9mV092277@star.math.spbu.ru> References: <200802180851.m1I8p9mV092277@star.math.spbu.ru> Message-ID: <680422C0AA225644931C2F6DD07200DD018DD492@namail5.corp.adobe.com> I guess my next question would be how would you suggest I go about tackling thing? I've had a look at the stubs before and I think I'm circumventing them in the example program since I populate the table and compile the functions in the order so that things never need to be done lazily, but I'll look further. If the answer is to add support for x64 windows calling conventions, which parts of LLVM should I be looking at to understand what needs to be done? Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Anton Korobeynikov Sent: Monday, February 18, 2008 12:51 AM To: Evan Cheng Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev]LLVM2.2 x64 JIT trouble on VStudio build > The x86-64 one probably doesn't work for Winodws. That's likely the > issue. Well, x86-64 stub was never ported to intel assembler, I expect to see 32-bit one used on windows64. In general, the whole windows64 support is missed mainly due to crazy calling convetion invented by Microsoft. So, all calls from code being JITed to external functions will be clearly broken (if they will use 'normal' CC and pass args in the registers). -- 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 mrs at apple.com Mon Feb 18 16:25:36 2008 From: mrs at apple.com (Mike Stump) Date: Mon, 18 Feb 2008 14:25:36 -0800 Subject: [LLVMdev] speeding up compilation and link time In-Reply-To: <16f40f0802161214r2bbe0d90o859434cccab5de15@mail.gmail.com> References: <16f40f0802161214r2bbe0d90o859434cccab5de15@mail.gmail.com> Message-ID: On Feb 16, 2008, at 12:14 PM, john hull wrote: > Does anyone have any ideas or tips on how to shorten the time to > build? You can precompile headers... The only change needed for makefiles is generally to add: g++ -c foo.h -o foo.h.gch and then to use -include foo.h on the compiles. From nicholas at mxc.ca Mon Feb 18 17:48:03 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Mon, 18 Feb 2008 15:48:03 -0800 Subject: [LLVMdev] cross compiling with the C backend In-Reply-To: <20d882600802180809q4d8c88fen7822c12c486bd5ae@mail.gmail.com> References: <20d882600802180809q4d8c88fen7822c12c486bd5ae@mail.gmail.com> Message-ID: <47BA1933.1070805@mxc.ca> Kevin Andr? wrote: > For my master's thesis, I am trying to cross compile programs for the > PSP (PlayStation Portable) with LLVM and llvm-gcc. > > This is what I do: > > (1) compile a program and the libraries it uses (libpng etc.) with llvm-gcc > (2) link the bitcode files with llvm-ld into one file > (3) run "llc -march=c" on the result > (4) compile the resulting C source with the PSP toolchain > > It seems to work with a very simple program (Pi_Calc, calculates Pi > and prints it), but it fails when I try it with another program that > is a bit more advanced: the PSP hangs when I run the program. > > Am I using the right approach here? I have compiled llvmgcc-4.2-2.2 on > my machine as a native compiler (i686-pc-linux-gnu). Does llvm-gcc > have an impact on the portability of the resulting LLVM bitcode? And > is the C code generated by the C backend really portable? I use the > "-nostdinc" option for llvm-gcc and specify the include paths of the > PSP SDK instead. But I still get warnings with llvm-gcc that do not > appear with psp-gcc ("passing argument 2 of 'xyz' discards qualifiers > from pointer target type"). And the output of the C back end generates > lots of warnings as well, or is that expected? No, it's not portable like that. Here's what goes on. C is portable in the sense that it gives you enough tools to inspect your environment. So an 'int' might be any number of chars (which themselves may be any number of bits >= 8), but that's okay because C provides 'sizeof(int)'. If you have code like "char *x = malloc(sizeof(int));" you're going to get different LLVM bytecode depending on what platform your llvm-gcc is set to. LLVM is portable in the sense that the bytecode will behave the same way on every platform. So if the above code becomes "%x_addr = malloc i32" then you get a 32-bit integer regardless of the abilities of the underlying system. Finally, the C backend's output isn't portable in the sense that it uses GCC extensions to get the correct output. Which is fine so long as you're compiling its output with GCC. Building llvm-gcc as a cross-compiler would help, if there's a platform you can select that matches the PSP more closely. Besides that, the warning you gave as an example is probably because llvm-gcc 4.2 is a newer version of gcc than psp-gcc. Nick From asl at math.spbu.ru Mon Feb 18 18:19:41 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Tue, 19 Feb 2008 03:19:41 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?TExWTTIuMiB4NjQgSklUIHRyb3VibGUgb24gVlN0dWRp?= =?koi8-r?b?byBidWlsZA==?= Message-ID: <200802190019.m1J0JfEY078124@star.math.spbu.ru> Hello, Chuck > I've had a look at the stubs before and I think I'm circumventing them > in the example program since I populate the table and compile the > functions in the order so that things never need to be done lazily, but > I'll look further. Well, anyway stubs are definitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to time. > If the answer is to add support for x64 windows calling conventions, > which parts of LLVM should I be looking at to understand what needs to > be done? The CC is described in the X86CallingConv.td file and also some other bits are expanded in the X86ISelLowering.cpp The changes needed for windows64 CC are pretty straightforward modification of the current x86-64 CC (I even can try to find my preliminary patch made this summer). However, there is one pretty ugly thing currently totally unimplemented: register shadowing: consider, e.g. void foo(int, double). First argument is passed into RCX, and second in both XMM1 and RDX. Also not, that it gos to XMM1, because it's second argument and XMM0 is shadowed by already-used RCX. I think I can try to heal my early patch and then stuff should be extended to handle these specific construction. -- WBR, Anton Korobeynikov From cfr at adobe.com Mon Feb 18 19:14:45 2008 From: cfr at adobe.com (Chuck Rose III) Date: Mon, 18 Feb 2008 17:14:45 -0800 Subject: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build In-Reply-To: <200802190019.m1J0JfEY078124@star.math.spbu.ru> References: <200802190019.m1J0JfEY078124@star.math.spbu.ru> Message-ID: <680422C0AA225644931C2F6DD07200DD018DD628@namail5.corp.adobe.com> Hola Anton, I live in a pretty closed world, so all of the functions I might want to call back to are pretty simple and are either compiled by me or can be wrapped by a function I can compile. Would my life be made fantastically simpler if I were using a different calling convention for my callback functions on x64 running on Windows? I'll have a look at the areas you pointed me to. Thanks, Chuck. -----Original Message----- From: Anton Korobeynikov [mailto:asl at math.spbu.ru] Sent: Monday, February 18, 2008 4:20 PM To: Chuck Rose III Cc: llvmdev at cs.uiuc.edu; evan.cheng at apple.com Subject: RE: [LLVMdev]LLVM2.2 x64 JIT trouble on VStudio build Hello, Chuck > I've had a look at the stubs before and I think I'm circumventing them > in the example program since I populate the table and compile the > functions in the order so that things never need to be done lazily, but > I'll look further. Well, anyway stubs are definitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to time. > If the answer is to add support for x64 windows calling conventions, > which parts of LLVM should I be looking at to understand what needs to > be done? The CC is described in the X86CallingConv.td file and also some other bits are expanded in the X86ISelLowering.cpp The changes needed for windows64 CC are pretty straightforward modification of the current x86-64 CC (I even can try to find my preliminary patch made this summer). However, there is one pretty ugly thing currently totally unimplemented: register shadowing: consider, e.g. void foo(int, double). First argument is passed into RCX, and second in both XMM1 and RDX. Also not, that it gos to XMM1, because it's second argument and XMM0 is shadowed by already-used RCX. I think I can try to heal my early patch and then stuff should be extended to handle these specific construction. -- WBR, Anton Korobeynikov From asl at math.spbu.ru Mon Feb 18 19:43:07 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Tue, 19 Feb 2008 04:43:07 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?TExWTTIuMiB4NjQgSklUIHRyb3VibGUgb24gVlN0dWRp?= =?koi8-r?b?byBidWlsZA==?= Message-ID: <200802190143.m1J1h711094035@star.math.spbu.ru> Hello, Chuck > Would my life be made fantastically simpler if I were using a different > calling convention for my callback functions on x64 running on Windows? Yes, surely. You can still use 'normal' x86-64 CC if you don't want to call any external functions from code being JITed. Also note a Win64 fixme in the X86CompilationCallback2 function, this can be your case. I think the code there should be carefully inspected to be compatible with windows64. Anyway, win64 version of compilation callback function should be added, otherwise you'll quickly result to messed stack, invalid incoming args, etc (this can be exactly your case now, btw). Also, I think that you should carefully inspect, what to save there, because you will 'mix' two CCs: JITer itself will be compiled with win64 CC and function JITed with normal x86-64 CC and they shouldn't trash the states of each other during crossing of 'CC border'. -- WBR, Anton Korobeynikov From ted at tedneward.com Mon Feb 18 23:46:20 2008 From: ted at tedneward.com (Ted Neward) Date: Mon, 18 Feb 2008 21:46:20 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <680422C0AA225644931C2F6DD07200DD018DD3FC@namail5.corp.adobe.com> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com><001101c87201$8bd624a0$a3826de0$@com> <002001c87205$e31b28b0$a9517a10$@com> <680422C0AA225644931C2F6DD07200DD018DD3FC@namail5.corp.adobe.com> Message-ID: <022901c872ba$cc8f0e30$65ad2a90$@com> OK, a couple of things aren't parsing here. > When config.h.in is hit in the build of configure the configure > project, > the configure.h file from the win32 directory is copied to main > llvm\Config\Config.h. The script in the sln file is: > There is no "configure.h" file from the win32 directory; there is a config.h, and it's 600 bytes long, compared to the 16k or so for the config.h file in $LLVM-ROOT/include/llvm/Config. The contents are obviously different, as well, since the one in $LLVM-ROOT/include/llvm/Config has the LLVM_ON_UNIX #define set. It didn't appear to be doing the copy even when building from within VS. Using "vcbuild /clean" then "vcbuild" on the Configure.vcproj file directly seems to have forced the copy to take place. I can see the "1 file(s) copied" output in the BuildLog. Except it doesn?t. File date/time reveals that nothing's been done to it, and opening it up confirms that the win32\config.h isn't appended. For whatever reason, only by manually deleting the config.h file in the llvm/include/Config directory can I get the project to re-gen that config.h file. I'm not sure if this is a property of running the build from the command-line (but I'm guessing it's not, since MSBuild is used internally inside VS), or if the file-copy is being prevented by something in my environment (files are marked writable, I already checked). I don't know if you need to be "more clever" here, since MSBuild is fully capable of doing what you're trying to get it to do--I have no idea why those file copies appear to be failing. Can you double-check and make sure they're working correctly on your machine? That way we know it's a peculiarity of my setup and not something intrinsic inside the build script. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Chuck Rose III > Sent: Monday, February 18, 2008 11:58 AM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > >There's a config.h file in the win32 subdirectory that implies that > it's > >supposed to be concatenated as part of the build process, but it > doesn't > >seem like that's happening from within the .sln script--am I missing a > >pre-build step someplace? > > When config.h.in is hit in the build of configure the configure > project, > the configure.h file from the win32 directory is copied to main > llvm\Config\Config.h. The script in the sln file is: > > copy "$(InputPath)"+"$(SolutionDir)config.h" > "$(ProjectDir)..\llvm\Config\config.h" > > configured as a custom build step in the solution file. Is that not > firing from the command line compilation of the sln? > > The file in the win32 directory is the config.h file that's ultimately > used when compiling everything under VStudio. That it implies that it > concatenates is outdated information. Ditto for the other .in files in > configure. We should probably be doing something more clever here. > > Thanks, > Chuck. > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Ted Neward > Sent: Monday, February 18, 2008 12:12 AM > To: 'LLVM Developers Mailing List' > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > More on this: > > Walking through the projects slowly: > > (*) "Configure" builds with no problem. > (*) "support" fails: > > > C:\Prg\llvm-2.2\llvm-2.2\win32>msbuild llvm.sln /t:Build > Microsoft (R) Build Engine Version 2.0.50727.1433 > [Microsoft .NET Framework, Version 2.0.50727.1433] > Copyright (C) Microsoft Corporation 2005. All rights reserved. > > Build started 2/18/2008 12:07:45 AM. > __________________________________________________ > Project "C:\Prg\llvm-2.2\llvm-2.2\win32\llvm.sln" (Build target(s)): > > Target ValidateSolutionConfiguration: > Building solution configuration "Debug|Win32". > Target Build: > Target Configure: > C:\Program Files\Microsoft Visual Studio > 8\Common7\IDE\..\..\vc\vcpackag > es\vcbuild.exe C:\Prg\llvm-2.2\llvm- > 2.2\win32\Configure\Configure.vcproj > "Config > ure|Win32" > Target support: > C:\Program Files\Microsoft Visual Studio > 8\Common7\IDE\..\..\vc\vcpackag > es\vcbuild.exe > C:\Prg\llvm-2.2\llvm-2.2\win32\Support\Support.tmp_Debug_Win32.vc > proj "Debug|Win32" > ..\..\lib\Support\IsInf.cpp(46): error C3861: 'isinf': > identifier > not fo > und > ..\..\lib\Support\IsInf.cpp(47): error C3861: 'isinf': > identifier > not fo > und > ..\..\lib\Support\IsNAN.cpp(31): error C3861: 'isnan': > identifier > not fo > und > ..\..\lib\Support\IsNAN.cpp(32): error C3861: 'isnan': > identifier > not fo > und > Done building target "support" in project "llvm.sln" -- FAILED. > > > It looks like there's some kind of configuration that's failing here, > because for some reason IsInf.cpp thinks that my machine has isinf() > defined, when in fact there isn't any. It seems that some #defines in > config.h in include/llvm/Config are controlling this: > > > /* Set to 1 if the isinf function is found in */ > #define HAVE_ISINF_IN_MATH_H 1 > > /* Set to 1 if the isnan function is found in */ > /* #undef HAVE_ISNAN_IN_CMATH */ > > /* Set to 1 if the isnan function is found in */ > #define HAVE_ISNAN_IN_MATH_H 1 > > > But I'm guessing that somehow this is supposed to be manipulated by the > build process, not by hand. Am I wrong in this? > > There's a config.h file in the win32 subdirectory that implies that > it's > supposed to be concatenated as part of the build process, but it > doesn't > seem like that's happening from within the .sln script--am I missing a > pre-build step someplace? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > > On Behalf Of Ted Neward > > Sent: Sunday, February 17, 2008 11:41 PM > > To: 'LLVM Developers Mailing List' > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > > 2005? > > > > By the way, somebody (I think it was Chuck, but I don't remember for > > certain) was asking for the BuildLog.htm from building the llvm.sln > > file > > under VS 2005 SP1 for diagnostic purposes; right now the SLN is > > configured > > to produce a new BuildLog for each and every one of the projects > inside > > the > > solution. I don't know who's responsible for this guy, but that's > > probably > > not the best way to do this. > > > > Chuck (assuming it was you), would it not be easier for me to capture > > the > > full results of an "msbuild llvm.sln" from the console for you? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > -----Original Message----- > > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > > bounces at cs.uiuc.edu] > > > On Behalf Of Chuck Rose III > > > Sent: Wednesday, February 13, 2008 8:52 AM > > > To: LLVM Developers Mailing List > > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > > Studio > > > 2005? > > > > > > I have always built it with flex and bison installed, though I > > believe > > > Chris removed our last dependence on flex a little while back, so > you > > > may not need that. I'm using bison 2.1 which I got from the > > > getgnuwin32 > > > folks. I imagine that if you have cygwin or the like, you probably > > > already have everything. > > > > > > You will need to have the executables in your path. > > > > > > I build with VisualStudio 2k5 Professional with VStudio SP1 > > installed. > > > I typically work on Vista32 or Vista64, but have compiled on XP as > > > well. > > > > > > > > > I don't know how up to date the LLVM docs related to Visual Studio > > > compilation are. > > > > > > Thanks, > > > Chuck. > > > > > > > > > -----Original Message----- > > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > > bounces at cs.uiuc.edu] > > > On Behalf Of Seung Jae Lee > > > Sent: Tuesday, February 12, 2008 9:52 PM > > > To: llvmdev at cs.uiuc.edu > > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > > Studio > > > 2005? > > > > > > Thanks for your comment. > > > I also tried for LLVM 2.2 but got the same compilation errors on > > > VS2005. > > > (I didn't modify anything before the compilation) > > > > > > I just wonder if I need bison and flex even just in the case of > > > compiling them on VS2005 without changing anything because the LLVM > > doc > > > says "If you plan to modify any .y or .l files, you will need to > have > > > bison and/or flex installed where Visual Studio can find them. > > > Otherwise, you do not need them and the pre-generated files that > come > > > with the source tree will be used." > > > > > > One of errors of mine is as follows: > > > ------------------------------------------------------- > > > ... > > > 7>llvmAsmParser.cpp > > > 7>c1xx : fatal error C1083: Cannot open source file: > > > '.\llvmAsmParser.cpp': No such file or directory > > > ... > > > ------------------------------------------------------- > > > where llvmAsmParser.cpp is related to Bison so I am compelled to > feel > > > to > > > try installing flex/bison on my machine, anyway. > > > > > > Forgive my ignorance, could you briefly tell me about that? > > > Thank you in advance. > > > > > > Seung > > > > > > ---- Original message ---- > > > >Date: Tue, 12 Feb 2008 18:20:59 -0800 > > > >From: "Chuck Rose III" > > > >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > > > Studio > > > 2005? > > > >To: "LLVM Developers Mailing List" > > > > > > > >Hola Seung, > > > > > > > >I don't know if 2.1 in particular worked. I updated the 2.2 win32 > > > >vstudio 2k5 files right before lockdown, so they should be > building. > > > >You will need appropriate versions of flex and bison installed. I > > > used > > > >the ones from getgnuwin32 on my machine. > > > > > > > >Good luck. > > > > > > > >Chuck. > > > > > > > >-----Original Message----- > > > >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > > bounces at cs.uiuc.edu] > > > >On Behalf Of Seung Jae Lee > > > >Sent: Monday, February 11, 2008 10:05 PM > > > >To: llvmdev at cs.uiuc.edu > > > >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > > > >2005? > > > > > > > >Hello all, > > > > > > > >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? > > > >I did but not succeed due to some build errors. > > > >I seem to remember I read somewhere on this list it's compiled on > > > VS2005 > > > >so I wonder... > > > >Have a good night. > > > > > > > >Thx, > > > >Seung > > > >_______________________________________________ > > > >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 > > > > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: > > > 2/13/2008 9:41 AM > > > > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > > 2/17/2008 > > 2:39 PM > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > > 2/17/2008 2:39 PM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > 2/17/2008 > 2:39 PM > > > _______________________________________________ > 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 > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1285 - Release Date: > 2/18/2008 5:50 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.7/1285 - Release Date: 2/18/2008 5:50 AM From ted at tedneward.com Mon Feb 18 23:46:20 2008 From: ted at tedneward.com (Ted Neward) Date: Mon, 18 Feb 2008 21:46:20 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <680422C0AA225644931C2F6DD07200DD018DD3FC@namail5.corp.adobe.com> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com><001101c87201$8bd624a0$a3826de0$@com> <002001c87205$e31b28b0$a9517a10$@com> <680422C0AA225644931C2F6DD07200DD018DD3FC@namail5.corp.adobe.com> Message-ID: <020a01c872ba$c3a8c400$4afa4c00$@com> After running a build, I noticed an "llvm" directory inside the "win32" directory--sure enough, tucked away inside this directory are the copied config.h and ADT files that Configure is supposed to be creating--which it did, faithfully. But now I'm not sure of what's going on--why are there two config.h files? It seems that this is what's happening; from the command-line call for Support, which is built right after Configure: /Od /I "..\..\include" /I ".." /D "_CRT_SECURE_NO_DEPRECATE" /D "_CRT_SECURE_NO_WARNINGS" /D "_SCL_SECURE_NO_WARNINGS" /D "_CRT_NONSTDC_NO_WARNINGS" /D "WIN32" /D "_DEBUG" /D "_LIB" /D "__STDC_LIMIT_MACROS" /D "_VC80_UPGRADE=0x0710" /D "_MBCS" /GF /Gm /EHsc /RTC1 /MDd /Fo"Win32\Debug\\" /Fd"\bin\Win32\Debug\support.pdb " /FR"Win32\Debug\\" /W3 /c /Zi /TP /wd4355 /wd4146 /wd4800 "..\..\lib\Support\Allocator.cpp" (bunch more .cpp files) >From within the Support directory, "..\..\include" will pick up "#include ", but so will ".." (..\llvm\config\config.h). This seems highly suspect, to depend on the order of inclusion inside of VS. I also don't quite get what you mean by the following: > The file in the win32 directory is the config.h file that's ultimately > used when compiling everything under VStudio. That it implies that it > concatenates is outdated information. Ditto for the other .in files in > configure. > So they *should* be concatenated, or not? What's the outdated information here? It seems offhand that they should be, but your prose above implies that they shouldn't be. Ultimately, it seems that the build script should be copying this config.h (and other headers) to include/llvm/, rather than an llvm directory inside of win32. Manually copying those files into the main "include" directory seems to work, anyway, and the files that I had there before seemed to be the ones from the Cygwin build I ran earlier using configure. (Perhaps there needs to be a "configure.bat" that does that same kinds of things?) Moving onwards... When trying to build System, then, I get the "Cannot find windows.h" error from DynamicLibrary.cpp. Insofar as I have a stock VS 2005 install, it's right--windows.h isn't part of the standard VC/include directory; it's tucked away in the "VC/PlatformSDK/include" directory, and the .sln doesn't seem to explicitly reference this (though it really shouldn't have to, IIRC). When I add this to the project settings for System, it builds cleanly. I haven't gotten beyond this for the moment just because I want to get this sent off and see what the responses are before I start hacking harder on the project settings. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Chuck Rose III > Sent: Monday, February 18, 2008 11:58 AM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > >There's a config.h file in the win32 subdirectory that implies that > it's > >supposed to be concatenated as part of the build process, but it > doesn't > >seem like that's happening from within the .sln script--am I missing a > >pre-build step someplace? > > When config.h.in is hit in the build of configure the configure > project, > the configure.h file from the win32 directory is copied to main > llvm\Config\Config.h. The script in the sln file is: > > copy "$(InputPath)"+"$(SolutionDir)config.h" > "$(ProjectDir)..\llvm\Config\config.h" > > configured as a custom build step in the solution file. Is that not > firing from the command line compilation of the sln? > > The file in the win32 directory is the config.h file that's ultimately > used when compiling everything under VStudio. That it implies that it > concatenates is outdated information. Ditto for the other .in files in > configure. We should probably be doing something more clever here. > > Thanks, > Chuck. > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Ted Neward > Sent: Monday, February 18, 2008 12:12 AM > To: 'LLVM Developers Mailing List' > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > More on this: > > Walking through the projects slowly: > > (*) "Configure" builds with no problem. > (*) "support" fails: > > > C:\Prg\llvm-2.2\llvm-2.2\win32>msbuild llvm.sln /t:Build > Microsoft (R) Build Engine Version 2.0.50727.1433 > [Microsoft .NET Framework, Version 2.0.50727.1433] > Copyright (C) Microsoft Corporation 2005. All rights reserved. > > Build started 2/18/2008 12:07:45 AM. > __________________________________________________ > Project "C:\Prg\llvm-2.2\llvm-2.2\win32\llvm.sln" (Build target(s)): > > Target ValidateSolutionConfiguration: > Building solution configuration "Debug|Win32". > Target Build: > Target Configure: > C:\Program Files\Microsoft Visual Studio > 8\Common7\IDE\..\..\vc\vcpackag > es\vcbuild.exe C:\Prg\llvm-2.2\llvm- > 2.2\win32\Configure\Configure.vcproj > "Config > ure|Win32" > Target support: > C:\Program Files\Microsoft Visual Studio > 8\Common7\IDE\..\..\vc\vcpackag > es\vcbuild.exe > C:\Prg\llvm-2.2\llvm-2.2\win32\Support\Support.tmp_Debug_Win32.vc > proj "Debug|Win32" > ..\..\lib\Support\IsInf.cpp(46): error C3861: 'isinf': > identifier > not fo > und > ..\..\lib\Support\IsInf.cpp(47): error C3861: 'isinf': > identifier > not fo > und > ..\..\lib\Support\IsNAN.cpp(31): error C3861: 'isnan': > identifier > not fo > und > ..\..\lib\Support\IsNAN.cpp(32): error C3861: 'isnan': > identifier > not fo > und > Done building target "support" in project "llvm.sln" -- FAILED. > > > It looks like there's some kind of configuration that's failing here, > because for some reason IsInf.cpp thinks that my machine has isinf() > defined, when in fact there isn't any. It seems that some #defines in > config.h in include/llvm/Config are controlling this: > > > /* Set to 1 if the isinf function is found in */ > #define HAVE_ISINF_IN_MATH_H 1 > > /* Set to 1 if the isnan function is found in */ > /* #undef HAVE_ISNAN_IN_CMATH */ > > /* Set to 1 if the isnan function is found in */ > #define HAVE_ISNAN_IN_MATH_H 1 > > > But I'm guessing that somehow this is supposed to be manipulated by the > build process, not by hand. Am I wrong in this? > > There's a config.h file in the win32 subdirectory that implies that > it's > supposed to be concatenated as part of the build process, but it > doesn't > seem like that's happening from within the .sln script--am I missing a > pre-build step someplace? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] > > On Behalf Of Ted Neward > > Sent: Sunday, February 17, 2008 11:41 PM > > To: 'LLVM Developers Mailing List' > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > > 2005? > > > > By the way, somebody (I think it was Chuck, but I don't remember for > > certain) was asking for the BuildLog.htm from building the llvm.sln > > file > > under VS 2005 SP1 for diagnostic purposes; right now the SLN is > > configured > > to produce a new BuildLog for each and every one of the projects > inside > > the > > solution. I don't know who's responsible for this guy, but that's > > probably > > not the best way to do this. > > > > Chuck (assuming it was you), would it not be easier for me to capture > > the > > full results of an "msbuild llvm.sln" from the console for you? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > -----Original Message----- > > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > > bounces at cs.uiuc.edu] > > > On Behalf Of Chuck Rose III > > > Sent: Wednesday, February 13, 2008 8:52 AM > > > To: LLVM Developers Mailing List > > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > > Studio > > > 2005? > > > > > > I have always built it with flex and bison installed, though I > > believe > > > Chris removed our last dependence on flex a little while back, so > you > > > may not need that. I'm using bison 2.1 which I got from the > > > getgnuwin32 > > > folks. I imagine that if you have cygwin or the like, you probably > > > already have everything. > > > > > > You will need to have the executables in your path. > > > > > > I build with VisualStudio 2k5 Professional with VStudio SP1 > > installed. > > > I typically work on Vista32 or Vista64, but have compiled on XP as > > > well. > > > > > > > > > I don't know how up to date the LLVM docs related to Visual Studio > > > compilation are. > > > > > > Thanks, > > > Chuck. > > > > > > > > > -----Original Message----- > > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > > bounces at cs.uiuc.edu] > > > On Behalf Of Seung Jae Lee > > > Sent: Tuesday, February 12, 2008 9:52 PM > > > To: llvmdev at cs.uiuc.edu > > > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > > Studio > > > 2005? > > > > > > Thanks for your comment. > > > I also tried for LLVM 2.2 but got the same compilation errors on > > > VS2005. > > > (I didn't modify anything before the compilation) > > > > > > I just wonder if I need bison and flex even just in the case of > > > compiling them on VS2005 without changing anything because the LLVM > > doc > > > says "If you plan to modify any .y or .l files, you will need to > have > > > bison and/or flex installed where Visual Studio can find them. > > > Otherwise, you do not need them and the pre-generated files that > come > > > with the source tree will be used." > > > > > > One of errors of mine is as follows: > > > ------------------------------------------------------- > > > ... > > > 7>llvmAsmParser.cpp > > > 7>c1xx : fatal error C1083: Cannot open source file: > > > '.\llvmAsmParser.cpp': No such file or directory > > > ... > > > ------------------------------------------------------- > > > where llvmAsmParser.cpp is related to Bison so I am compelled to > feel > > > to > > > try installing flex/bison on my machine, anyway. > > > > > > Forgive my ignorance, could you briefly tell me about that? > > > Thank you in advance. > > > > > > Seung > > > > > > ---- Original message ---- > > > >Date: Tue, 12 Feb 2008 18:20:59 -0800 > > > >From: "Chuck Rose III" > > > >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > > > Studio > > > 2005? > > > >To: "LLVM Developers Mailing List" > > > > > > > >Hola Seung, > > > > > > > >I don't know if 2.1 in particular worked. I updated the 2.2 win32 > > > >vstudio 2k5 files right before lockdown, so they should be > building. > > > >You will need appropriate versions of flex and bison installed. I > > > used > > > >the ones from getgnuwin32 on my machine. > > > > > > > >Good luck. > > > > > > > >Chuck. > > > > > > > >-----Original Message----- > > > >From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > > bounces at cs.uiuc.edu] > > > >On Behalf Of Seung Jae Lee > > > >Sent: Monday, February 11, 2008 10:05 PM > > > >To: llvmdev at cs.uiuc.edu > > > >Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual > Studio > > > >2005? > > > > > > > >Hello all, > > > > > > > >Is there anyone has tried LLVM 2.1 on Visual Studio 2005? > > > >I did but not succeed due to some build errors. > > > >I seem to remember I read somewhere on this list it's compiled on > > > VS2005 > > > >so I wonder... > > > >Have a good night. > > > > > > > >Thx, > > > >Seung > > > >_______________________________________________ > > > >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 > > > > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: > > > 2/13/2008 9:41 AM > > > > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > > 2/17/2008 > > 2:39 PM > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > > 2/17/2008 2:39 PM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1284 - Release Date: > 2/17/2008 > 2:39 PM > > > _______________________________________________ > 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 > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1285 - Release Date: > 2/18/2008 5:50 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.7/1285 - Release Date: 2/18/2008 5:50 AM From isanbard at gmail.com Tue Feb 19 02:37:22 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 19 Feb 2008 00:37:22 -0800 Subject: [LLVMdev] 2008-01-25-ByValReadNone.c Failure References: <3293A2C0-ECC0-40A6-B3FB-EEEFA909ED0B@gmail.com> Message-ID: Hi all, I'm seeing this failure on my PPC G4 box running TOT with llvm-gcc 4.2. Is anyone else seeing this? I'm sure it's related to the byval stuff that's recently gone into LLVM. I'm attaching the output of this command: $ llvm-gcc -emit-llvm -O3 -S -o - -emit-llvm /Users/wendling/llvm/ llvm.src/test/CFrontend/2008-01-25-ByValReadNone.c As you can see in it, there are "readonly" attributes on the functions. -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: 2008-01-25-ByValReadNone.ll.gz Type: application/x-gzip Size: 8720 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080219/4ce20476/attachment-0001.gz -------------- next part -------------- FAIL: /Users/wendling/llvm/llvm.src/test/CFrontend/2008-01-25- ByValReadNone.c Failed with exit(1) at line 1 while running: /Users/wendling/llvm/llvm-gcc-4.2.install/bin/llvm-gcc -emit-llvm -O3 -S -o - -emit-llvm /Users/wendling/llvm/llvm.src/test/ CFrontend/2008-01-25-ByValReadNone.c | not grep readonly %tmp1505 = call i32 @g( i64 %x.0.0, i64 %x.0.1, i64 %x.0.2, i64 %x.0.3, i64 %x.0.4, i64 %x.0.5, i64 %x.0.6, i64 %x.0.7, i64 %x. 0.8, i64 %x.0.9, i64 %x.0.10, i64 %x.0.11, i64 %x.0.12, i64 %x.0.13, i64 %x.0.14, i64 %x.0.15, i64 %x.0.16, i64 %x.0.17, i64 %x.0.18, i64 % x.0.19, i64 %x.0.20, i64 %x.0.21, i64 %x.0.22, i64 %x.0.23, i64 %x. 0.24, i64 %x.0.25, i64 %x.0.26, i64 %x.0.27, i64 %x.0.28, i64 %x. 0.29, i64 %x.0.30, i64 %x.0.31, i64 %x.0.32, i64 %x.0.33, i64 %x. 0.34, i64 %x.0.35, i64 %x.0.36, i64 %x.0.37, i64 %x.0.38, i64 %x. 0.39, i64 %x.0.40, i64 %x.0.41, i64 %x.0.42, i64 %x.0.43, i64 %x. 0.44, i64 %x.0.45, i64 %x.0.46, i64 %x.0.47, i64 %x.0.48, i64 %x. 0.49, i64 %x.0.50, i64 %x.0.51, i64 %x.0.52, i64 %x.0.53, i64 %x. 0.54, i64 %x.0.55, i64 %x.0.56, i64 %x.0.57, i64 %x.0.58, i64 %x. 0.59, i64 %x.0.60, i64 %x.0.61, i64 %x.0.62, i64 %x.0.63, i64 %x. 0.64, i64 %x.0.65, i64 %x.0.66, i64 %x.0.67, i64 %x.0.68, i64 %x. 0.69, i64 %x.0.70, i64 %x.0.71, i64 %x.0.72, i64 %x.0.73, i64 %x. 0.74, i64 %x.0.75, i64 %x.0.76, i64 %x.0.77, i64 %x.0.78, i64 %x. 0.79, i64 %x.0.80, i64 %x.0.81, i64 %x.0.82, i64 %x.0.83, i64 %x. 0.84, i64 %x.0.85, i64 %x.0.86, i64 %x.0.87, i64 %x.0.88, i64 %x. 0.89, i64 %x.0.90, i64 %x.0.91, i64 %x.0.92, i64 %x.0.93, i64 %x. 0.94, i64 %x.0.95, i64 %x.0.96, i64 %x.0.97, i64 %x.0.98, i64 %x. 0.99, i64 %x.0.100, i64 %x.0.101, i64 %x.0.102, i64 %x.0.103, i64 %x. 0.104, i64 %x.0.105, i64 %x.0.106, i64 %x.0.107, i64 %x.0.108, i64 %x. 0.109, i64 %x.0.110, i64 %x.0.111, i64 %x.0.112, i64 %x.0.113, i64 %x. 0.114, i64 %x.0.115, i64 %x.0.116, i64 %x.0.117, i64 %x.0.118, i64 %x. 0.119, i64 %x.0.120, i64 %x.0.121, i64 %x.0.122, i64 %x.0.123, i64 %x. 0.124, i64 %x.0.125, i64 %x.0.126, i64 %x.0.127, i64 %x.0.128, i64 %x. 0.129, i64 %x.0.130, i64 %x.0.131, i64 %x.0.132, i64 %x.0.133, i64 %x. 0.134, i64 %x.0.135, i64 %x.0.136, i64 %x.0.137, i64 %x.0.138, i64 %x. 0.139, i64 %x.0.140, i64 %x.0.141, i64 %x.0.142, i64 %x.0.143, i64 %x. 0.144, i64 %x.0.145, i64 %x.0.146, i64 %x.0.147, i64 %x.0.148, i64 %x. 0.149, i64 %x.0.150, i64 %x.0.151, i64 %x.0.152, i64 %x.0.153, i64 %x. 0.154, i64 %x.0.155, i64 %x.0.156, i64 %x.0.157, i64 %x.0.158, i64 %x. 0.159, i64 %x.0.160, i64 %x.0.161, i64 %x.0.162, i64 %x.0.163, i64 %x. 0.164, i64 %x.0.165, i64 %x.0.166, i64 %x.0.167, i64 %x.0.168, i64 %x. 0.169, i64 %x.0.170, i64 %x.0.171, i64 %x.0.172, i64 %x.0.173, i64 %x. 0.174, i64 %x.0.175, i64 %x.0.176, i64 %x.0.177, i64 %x.0.178, i64 %x. 0.179, i64 %x.0.180, i64 %x.0.181, i64 %x.0.182, i64 %x.0.183, i64 %x. 0.184, i64 %x.0.185, i64 %x.0.186, i64 %x.0.187, i64 %x.0.188, i64 %x. 0.189, i64 %x.0.190, i64 %x.0.191, i64 %x.0.192, i64 %x.0.193, i64 %x. 0.194, i64 %x.0.195, i64 %x.0.196, i64 %x.0.197, i64 %x.0.198, i64 %x. 0.199, i64 %x.0.200, i64 %x.0.201, i64 %x.0.202, i64 %x.0.203, i64 %x. 0.204, i64 %x.0.205, i64 %x.0.206, i64 %x.0.207, i64 %x.0.208, i64 %x. 0.209, i64 %x.0.210, i64 %x.0.211, i64 %x.0.212, i64 %x.0.213, i64 %x. 0.214, i64 %x.0.215, i64 %x.0.216, i64 %x.0.217, i64 %x.0.218, i64 %x. 0.219, i64 %x.0.220, i64 %x.0.221, i64 %x.0.222, i64 %x.0.223, i64 %x. 0.224, i64 %x.0.225, i64 %x.0.226, i64 %x.0.227, i64 %x.0.228, i64 %x. 0.229, i64 %x.0.230, i64 %x.0.231, i64 %x.0.232, i64 %x.0.233, i64 %x. 0.234, i64 %x.0.235, i64 %x.0.236, i64 %x.0.237, i64 %x.0.238, i64 %x. 0.239, i64 %x.0.240, i64 %x.0.241, i64 %x.0.242, i64 %x.0.243, i64 %x. 0.244, i64 %x.0.245, i64 %x.0.246, i64 %x.0.247, i64 %x.0.248, i64 %x. 0.249, i64 %x.0.250, i64 %x.0.251, i64 %x.0.252, i64 %x.0.253, i64 %x. 0.254, i64 %x.0.255, i64 %x.0.256, i64 %x.0.257, i64 %x.0.258, i64 %x. 0.259, i64 %x.0.260, i64 %x.0.261, i64 %x.0.262, i64 %x.0.263, i64 %x. 0.264, i64 %x.0.265, i64 %x.0.266, i64 %x.0.267, i64 %x.0.268, i64 %x. 0.269, i64 %x.0.270, i64 %x.0.271, i64 %x.0.272, i64 %x.0.273, i64 %x. 0.274, i64 %x.0.275, i64 %x.0.276,L: /Users/wendling/llvm/llvm.src/ test/CFrontend/2008-01-25-ByValReadNone.c Failed with exit(1) at line 1 while running: /Users/wendling/llvm/llvm-gcc-4.2.install/bin/llvm-gcc -emit-llvm -O3 -S -o - -emit-llvm /Users/wendling/llvm/llvm.src/test/ CFrontend/2008-01-25-ByValReadNone.c | not grep readonly %tmp1505 = call i32 @g( i64 %x.0.0, i64 %x.0.1, i64 %x.0.2, i64 %x.0.3, i64 %x.0.4, i64 %x.0.5, i64 %x.0.6, i64 %x.0.7, i64 %x. 0.8, i64 %x.0.9, i64 %x.0.10, i64 %x.0.11, i64 %x.0.12, i64 %x.0.13, i64 %x.0.14, i64 %x.0.15, i64 %x.0.16, i64 %x.0.17, i64 %x.0.18, i64 % x.0.19, i64 %x.0.20, i64 %x.0.21, i64 %x.0.22, i64 %x.0.23, i64 %x. 0.24, i64 %x.0.25, i64 %x.0.26, i64 %x.0.27, i64 %x.0.28, i64 %x. 0.29, i64 %x.0.30, i64 %x.0.31, i64 %x.0.32, i64 %x.0.33, i64 %x. 0.34, i64 %x.0.35, i64 %x.0.36, i64 %x.0.37, i64 %x.0.38, i64 %x. 0.39, i64 %x.0.40, i64 %x.0.41, i64 %x.0.42, i64 %x.0.43, i64 %x. 0.44, i64 %x.0.45, i64 %x.0.46, i64 %x.0.47, i64 %x.0.48, i64 %x. 0.49, i64 %x.0.50, i64 %x.0.51, i64 %x.0.52, i64 %x.0.53, i64 %x. 0.54, i64 %x.0.55, i64 %x.0.56, i64 %x.0.57, i64 %x.0.58, i64 %x. 0.59, i64 %x.0.60, i64 %x.0.61, i64 %x.0.62, i64 %x.0.63, i64 %x. 0.64, i64 %x.0.65, i64 %x.0.66, i64 %x.0.67, i64 %x.0.68, i64 %x. 0.69, i64 %x.0.70, i64 %x.0.71, i64 %x.0.72, i64 %x.0.73, i64 %x. 0.74, i64 %x.0.75, i64 %x.0.76, i64 %x.0.77, i64 %x.0.78, i64 %x. 0.79, i64 %x.0.80, i64 %x.0.81, i64 %x.0.82, i64 %x.0.83, i64 %x. 0.84, i64 %x.0.85, i64 %x.0.86, i64 %x.0.87, i64 %x.0.88, i64 %x. 0.89, i64 %x.0.90, i64 %x.0.91, i64 %x.0.92, i64 %x.0.93, i64 %x. 0.94, i64 %x.0.95, i64 %x.0.96, i64 %x.0.97, i64 %x.0.98, i64 %x. 0.99, i64 %x.0.100, i64 %x.0.101, i64 %x.0.102, i64 %x.0.103, i64 %x. 0.104, i64 %x.0.105, i64 %x.0.106, i64 %x.0.107, i64 %x.0.108, i64 %x. 0.109, i64 %x.0.110, i64 %x.0.111, i64 %x.0.112, i64 %x.0.113, i64 %x. 0.114, i64 %x.0.115, i64 %x.0.116, i64 %x.0.117, i64 %x.0.118, i64 %x. 0.119, i64 %x.0.120, i64 %x.0.121, i64 %x.0.122, i64 %x.0.123, i64 %x. 0.124, i64 %x.0.125, i64 %x.0.126, i64 %x.0.127, i64 %x.0.128, i64 %x. 0.129, i64 %x.0.130, i64 %x.0.131, i64 %x.0.132, i64 %x.0.133, i64 %x. 0.134, i64 %x.0.135, i64 %x.0.136, i64 %x.0.137, i64 %x.0.138, i64 %x. 0.139, i64 %x.0.140, i64 %x.0.141, i64 %x.0.142, i64 %x.0.143, i64 %x. 0.144, i64 %x.0.145, i64 %x.0.146, i64 %x.0.147, i64 %x.0.148, i64 %x. 0.149, i64 %x.0.150, i64 %x.0.151, i64 %x.0.152, i64 %x.0.153, i64 %x. 0.154, i64 %x.0.155, i64 %x.0.156, i64 %x.0.157, i64 %x.0.158, i64 %x. 0.159, i64 %x.0.160, i64 %x.0.161, i64 %x.0.162, i64 %x.0.163, i64 %x. 0.164, i64 %x.0.165, i64 %x.0.166, i64 %x.0.167, i64 %x.0.168, i64 %x. 0.169, i64 %x.0.170, i64 %x.0.171, i64 %x.0.172, i64 %x.0.173, i64 %x. 0.174, i64 %x.0.175, i64 %x.0.176, i64 %x.0.177, i64 %x.0.178, i64 %x. 0.179, i64 %x.0.180, i64 %x.0.181, i64 %x.0.182, i64 %x.0.183, i64 %x. 0.184, i64 %x.0.185, i64 %x.0.186, i64 %x.0.187, i64 %x.0.188, i64 %x. 0.189, i64 %x.0.190, i64 %x.0.191, i64 %x.0.192, i64 %x.0.193, i64 %x. 0.194, i64 %x.0.195, i64 %x.0.196, i64 %x.0.197, i64 %x.0.198, i64 %x. 0.199, i64 %x.0.200, i64 %x.0.201, i64 %x.0.202, i64 %x.0.203, i64 %x. 0.204, i64 %x.0.205, i64 %x.0.206, i64 %x.0.207, i64 %x.0.208, i64 %x. 0.209, i64 %x.0.210, i64 %x.0.211, i64 %x.0.212, i64 %x.0.213, i64 %x. 0.214, i64 %x.0.215, i64 %x.0.216, i64 %x.0.217, i64 %x.0.218, i64 %x. 0.219, i64 %x.0.220, i64 %x.0.221, i64 %x.0.222, i64 %x.0.223, i64 %x. 0.224, i64 %x.0.225, i64 %x.0.226, i64 %x.0.227, i64 %x.0.228, i64 %x. 0.229, i64 %x.0.230, i64 %x.0.231, i64 %x.0.232, i64 %x.0.233, i64 %x. 0.234, i64 %x.0.235, i64 %x.0.236, i64 %x.0.237, i64 %x.0.238, i64 %x. 0.239, i64 %x.0.240, i64 %x.0.241, i64 %x.0.242, i64 %x.0.243, i64 %x. 0.244, i64 %x.0.245, i64 %x.0.246, i64 %x.0.247, i64 %x.0.248, i64 %x. 0.249, i64 %x.0.250, i64 %x.0.251, i64 %x.0.252, i64 %x.0.253, i64 %x. 0.254, i64 %x.0.255, i64 %x.0.256, i64 %x.0.257, i64 %x.0.258, i64 %x. 0.259, i64 %x.0.260, i64 %x.0.261, i64 %x.0.262, i64 %x.0.263, i64 %x. 0.264, i64 %x.0.265, i64 %x.0.266, i64 %x.0.267, i64 %x.0.268, i64 %x. 0.269, i64 %x.0.270, i64 %x.0.271, i64 %x.0.272, i64 %x.0.273, i64 %x. 0.274, i64 %x.0.275, i64 %x.0.276,.0.54, i64 %x.0.55, i64 %x.0.56, i64 %x.0.57, i64 %x.0.58, i64 %x.0.59, i64 %x.0.60, i64 %x.0.61, i64 % x.0.62, i64 %x.0.63, i64 %x.0.64, i64 %x.0.65, i64 %x.0.66, i64 %x. 0.67, i64 %x.0.68, i64 %x.0.69, i64 %x.0.70, i64 %x.0.71, i64 %x. 0.72, i64 %x.0.73, i64 %x.0.74, i64 %x.0.75, i64 %x.0.76, i64 %x. 0.77, i64 %x.0.78, i64 %x.0.79, i64 %x.0.80, i64 %x.0.81, i64 %x. 0.82, i64 %x.0.83, i64 %x.0.84, i64 %x.0.85, i64 %x.0.86, i64 %x. 0.87, i64 %x.0.88, i64 %x.0.89, i64 %x.0.90, i64 %x.0.91, i64 %x. 0.92, i64 %x.0.93, i64 %x.0.94, i64 %x.0.95, i64 %x.0.96, i64 %x. 0.97, i64 %x.0.98, i64 %x.0.99, i64 %x.0.100, i64 %x.0.101, i64 %x. 0.102, i64 %x.0.103, i64 %x.0.104, i64 %x.0.105, i64 %x.0.106, i64 %x. 0.107, i64 %x.0.108, i64 %x.0.109, i64 %x.0.110, i64 %x.0.111, i64 %x. 0.112, i64 %x.0.113, i64 %x.0.114, i64 %x.0.115, i64 %x.0.116, i64 %x. 0.117, i64 %x.0.118, i64 %x.0.119, i64 %x.0.120, i64 %x.0.121, i64 %x. 0.122, i64 %x.0.123, i64 %x.0.124, i64 %x.0.125, i64 %x.0.126, i64 %x. 0.127, i64 %x.0.128, i64 %x.0.129, i64 %x.0.130, i64 %x.0.131, i64 %x. 0.132, i64 %x.0.133, i64 %x.0.134, i64 %x.0.135, i64 %x.0.136, i64 %x. 0.137, i64 %x.0.138, i64 %x.0.139, i64 %x.0.140, i64 %x.0.141, i64 %x. 0.142, i64 %x.0.143, i64 %x.0.144, i64 %x.0.145, i64 %x.0.146, i64 %x. 0.147, i64 %x.0.148, i64 %x.0.149, i64 %x.0.150, i64 %x.0.151, i64 %x. 0.152, i64 %x.0.153, i64 %x.0.154, i64 %x.0.155, i64 %x.0.156, i64 %x. 0.157, i64 %x.0.158, i64 %x.0.159, i64 %x.0.160, i64 %x.0.161, i64 %x. 0.162, i64 %x.0.163, i64 %x.0.164, i64 %x.0.165, i64 %x.0.166, i64 %x. 0.167, i64 %x.0.168, i64 %x.0.169, i64 %x.0.170, i64 %x.0.171, i64 %x. 0.172, i64 %x.0.173, i64 %x.0.174, i64 %x.0.175, i64 %x.0.176, i64 %x. 0.177, i64 %x.0.178, i64 %x.0.179, i64 %x.0.180, i64 %x.0.181, i64 %x. 0.182, i64 %x.0.183, i64 %x.0.184, i64 %x.0.185, i64 %x.0.186, i64 %x. 0.187, i64 %x.0.188, i64 %x.0.189, i64 %x.0.190, i64 %x.0.191, i64 %x. 0.192, i64 %x.0.193, i64 %x.0.194, i64 %x.0.195, i64 %x.0.196, i64 %x. 0.197, i64 %x.0.198, i64 %x.0.199, i64 %x.0.200, i64 %x.0.201, i64 %x. 0.202, i64 %x.0.203, i64 %x.0.204, i64 %x.0.205, i64 %x.0.206, i64 %x. 0.207, i64 %x.0.208, i64 %x.0.209, i64 %x.0.210, i64 %x.0.211, i64 %x. 0.212, i64 %x.0.213, i64 %x.0.214, i64 %x.0.215, i64 %x.0.216, i64 %x. 0.217, i64 %x.0.218, i64 %x.0.219, i64 %x.0.220, i64 %x.0.221, i64 %x. 0.222, i64 %x.0.223, i64 %x.0.224, i64 %x.0.225, i64 %x.0.226, i64 %x. 0.227, i64 %x.0.228, i64 %x.0.229, i64 %x.0.230, i64 %x.0.231, i64 %x. 0.232, i64 %x.0.233, i64 %x.0.234, i64 %x.0.235, i64 %x.0.236, i64 %x. 0.237, i64 %x.0.238, i64 %x.0.239, i64 %x.0.240, i64 %x.0.241, i64 %x. 0.242, i64 %x.0.243, i64 %x.0.244, i64 %x.0.245, i64 %x.0.246, i64 %x. 0.247, i64 %x.0.248, i64 %x.0.249, i64 %x.0.250, i64 %x.0.251, i64 %x. 0.252, i64 %x.0.253, i64 %x.0.254, i64 %x.0.255, i64 %x.0.256, i64 %x. 0.257, i64 %x.0.258, i64 %x.0.259, i64 %x.0.260, i64 %x.0.261, i64 %x. 0.262, i64 %x.0.263, i64 %x.0.264, i64 %x.0.265, i64 %x.0.266, i64 %x. 0.267, i64 %x.0.268, i64 %x.0.269, i64 %x.0.270, i64 %x.0.271, i64 %x. 0.272, i64 %x.0.273, i64 %x.0.274, i64 %x.0.275, i64 %x.0.276,130, i64 %x.0.131, i64 %x.0.132, i64 %x.0.133, i64 %x.0.134, i64 %x.0.135, i64 %x.0.136, i64 %x.0.137, i64 %x.0.138, i64 %x.0.139, i64 %x.0.140, i64 %x.0.141, i64 %x.0.142, i64 %x.0.143, i64 %x.0.144, i64 %x.0.145, i64 %x.0.146, i64 %x.0.147, i64 %x.0.148, i64 %x.0.149, i64 %x.0.150, i64 %x.0.151, i64 %x.0.152, i64 %x.0.153, i64 %x.0.154, i64 %x.0.155, i64 %x.0.156, i64 %x.0.157, i64 %x.0.158, i64 %x.0.159, i64 %x.0.160, i64 %x.0.161, i64 %x.0.162, i64 %x.0.163, i64 %x.0.164, i64 %x.0.165, i64 %x.0.166, i64 %x.0.167, i64 %x.0.168, i64 %x.0.169, i64 %x.0.170, i64 %x.0.171, i64 %x.0.172, i64 %x.0.173, i64 %x.0.174, i64 %x.0.175, i64 %x.0.176, i64 %x.0.177, i64 %x.0.178, i64 %x.0.179, i64 %x.0.180, i64 %x.0.181, i64 %x.0.182, i64 %x.0.183, i64 %x.0.184, i64 %x.0.185, i64 %x.0.186, i64 %x.0.187, i64 %x.0.188, i64 %x.0.189, i64 %x.0.190, i64 %x.0.191, i64 %x.0.192, i64 %x.0.193, i64 %x.0.194, i64 %x.0.195, i64 %x.0.196, i64 %x.0.197, i64 %x.0.198, i64 %x.0.199, i64 %x.0.200, i64 %x.0.201, i64 %x.0.202, i64 %x.0.203, i64 %x.0.204, i64 %x.0.205, i64 %x.0.206, i64 %x.0.207, i64 %x.0.208, i64 %x.0.209, i64 %x.0.210, i64 %x.0.211, i64 %x.0.212, i64 %x.0.213, i64 %x.0.214, i64 %x.0.215, i64 %x.0.216, i64 %x.0.217, i64 %x.0.218, i64 %x.0.219, i64 %x.0.220, i64 %x.0.221, i64 %x.0.222, i64 %x.0.223, i64 %x.0.224, i64 %x.0.225, i64 %x.0.226, i64 %x.0.227, i64 %x.0.228, i64 %x.0.229, i64 %x.0.230, i64 %x.0.231, i64 %x.0.232, i64 %x.0.233, i64 %x.0.234, i64 %x.0.235, i64 %x.0.236, i64 %x.0.237, i64 %x.0.238, i64 %x.0.239, i64 %x.0.240, i64 %x.0.241, i64 %x.0.242, i64 %x.0.243, i64 %x.0.244, i64 %x.0.245, i64 %x.0.246, i64 %x.0.247, i64 %x.0.248, i64 %x.0.249, i64 %x.0.250, i64 %x.0.251, i64 %x.0.252, i64 %x.0.253, i64 %x.0.254, i64 %x.0.255, i64 %x.0.256, i64 %x.0.257, i64 %x.0.258, i64 %x.0.259, i64 %x.0.260, i64 %x.0.261, i64 %x.0.262, i64 %x.0.263, i64 %x.0.264, i64 %x.0.265, i64 %x.0.266, i64 %x.0.267, i64 %x.0.268, i64 %x.0.269, i64 %x.0.270, i64 %x.0.271, i64 %x.0.272, i64 %x.0.273, i64 %x.0.274, i64 %x.0.275, i64 %x.0.276,3, i64 %x.0.204, i64 %x.0.205, i64 %x.0.206, i64 %x. 0.207, i64 %x.0.208, i64 %x.0.209, i64 %x.0.210, i64 %x.0.211, i64 %x. 0.212, i64 %x.0.213, i64 %x.0.214, i64 %x.0.215, i64 %x.0.216, i64 %x. 0.217, i64 %x.0.218, i64 %x.0.219, i64 %x.0.220, i64 %x.0.221, i64 %x. 0.222, i64 %x.0.223, i64 %x.0.224, i64 %x.0.225, i64 %x.0.226, i64 %x. 0.227, i64 %x.0.228, i64 %x.0.229, i64 %x.0.230, i64 %x.0.231, i64 %x. 0.232, i64 %x.0.233, i64 %x.0.234, i64 %x.0.235, i64 %x.0.236, i64 %x. 0.237, i64 %x.0.238, i64 %x.0.239, i64 %x.0.240, i64 %x.0.241, i64 %x. 0.242, i64 %x.0.243, i64 %x.0.244, i64 %x.0.245, i64 %x.0.246, i64 %x. 0.247, i64 %x.0.248, i64 %x.0.249, i64 %x.0.250, i64 %x.0.251, i64 %x. 0.252, i64 %x.0.253, i64 %x.0.254, i64 %x.0.255, i64 %x.0.256, i64 %x. 0.257, i64 %x.0.258, i64 %x.0.259, i64 %x.0.260, i64 %x.0.261, i64 %x. 0.262, i64 %x.0.263, i64 %x.0.264, i64 %x.0.265, i64 %x.0.266, i64 %x. 0.267, i64 %x.0.268, i64 %x.0.269, i64 %x.0.270, i64 %x.0.271, i64 %x. 0.272, i64 %x.0.273, i64 %x.0.274, i64 %x.0.275, i64 %x.0.276, i64 %x. 0.277, i64 %x.0.278, i64 %x.0.279, i64 %x.0.280, i64 %x.0.281, i64 %x. 0.282, i64 %x.0.283, i64 %x.0.284, i64 %x.0.285, i64 %x.0.286, i64 %x. 0.287, i64 %x.0.288, i64 %x.0.289, i64 %x.0.290, i64 %x.0.291, i64 %x. 0.292, i64 %x.0.293, i64 %x.0.294, i64 %x.0.295, i64 %x.0.296, i64 %x. 0.297, i64 %x.0.298, i64 %x.0.299, i64 %x.0.300, i64 %x.0.301, i64 %x. 0.302, i64 %x.0.303, i64 %x.0.304, i64 %x.0.305, i64 %x.0.306, i64 %x. 0.307, i64 %x.0.308, i64 %x.0.309, i64 %x.0.310, i64 %x.0.311, i64 %x. 0.312, i64 %x.0.313, i64 %x.0.314, i64 %x.0.315, i64 %x.0.316, i64 %x. 0.317, i64 %x.0.318, i64 %x.0.319, i64 %x.0.320, i64 %x.0.321, i64 %x. 0.322, i64 %x.0.323, i64 %x.0.324, i64 %x.0.325, i64 %x.0.326, i64 %x. 0.327, i64 %x.0.328, i64 %x.0.329, i64 %x.0.330, i64 %x.0.331, i64 %x. 0.332, i64 %x.0.333, i64 %x.0.334, i64 %x.0.335, i64 %x.0.336, i64 %x. 0.337, i64 %x.0.338, i64 %x.0.339, i64 %x.0.340, i64 %x.0.341, i64 %x. 0.342, i64 %x.0.343, i64 %x.0.344, i64 %x.0.345, i64 %x.0.346, i64 %x. 0.347, i64 %x.0.348, i64 %x.0.349, i64 %x.0.350, i64 %x.0.351, i64 %x. 0.352, i64 %x.0.353, i64 %x.0.354, i64 %x.0.355, i64 %x.0.356, i64 %x. 0.357, i64 %x.0.358, i64 %x.0.359, i64 %x.0.360, i64 %x.0.361, i64 %x. 0.362, i64 %x.0.363, i64 %x.0.364, i64 %x.0.365, i64 %x.0.366, i64 %x. 0.367, i64 %x.0.368, i64 %x.0.369, i64 %x.0.370, i64 %x.0.371, i64 %x. 0.372, i64 %x.0.373, i64 %x.0.374, i64 %x.0.375, i64 %x.0.376, i64 %x. 0.377, i64 %x.0.378, i64 %x.0.379, i64 %x.0.380, i64 %x.0.381, i64 %x. 0.382, i64 %x.0.383, i64 %x.0.384, i64 %x.0.385, i64 %x.0.386, i64 %x. 0.387, i64 %x.0.388, i64 %x.0.389, i64 %x.0.390, i64 %x.0.391, i64 %x. 0.392, i64 %x.0.393, i64 %x.0.394, i64 %x.0.395, i64 %x.0.396, i64 %x. 0.397, i64 %x.0.398, i64 %x.0.399, i64 %x.0.400, i64 %x.0.401, i64 %x. 0.402, i64 %x.0.403, i64 %x.0.404, i64 %x.0.405, i64 %x.0.406, i64 %x. 0.407, i64 %x.0.408, i64 %x.0.409, i64 %x.0.410, i64 %x.0.411, i64 %x. 0.412, i64 %x.0.413, i64 %x.0.414, i64 %x.0.415, i64 %x.0.416, i64 %x. 0.417, i64 %x.0.418, i64 %x.0.419, i64 %x.0.420, i64 %x.0.421, i64 %x. 0.422, i64 %x.0.423, i64 %x.0.424, i64 %x.0.425, i64 %x.0.426, i64 %x. 0.427, i64 %x.0.428, i64 %x.0.429, i64 %x.0.430, i64 %x.0.431, i64 %x. 0.432, i64 %x.0.433, i64 %x.0.434, i64 %x.0.435, i64 %x.0.436, i64 %x. 0.437, i64 %x.0.438, i64 %x.0.439, i64 %x.0.440, i64 %x.0.441, i64 %x. 0.442, i64 %x.0.443, i64 %x.0.444, i64 %x.0.445, i64 %x.0.446, i64 %x. 0.447, i64 %x.0.448, i64 %x.0.449, i64 %x.0.450, i64 %x.0.451, i64 %x. 0.452, i64 %x.0.453, i64 %x.0.454, i64 %x.0.455, i64 %x.0.456, i64 %x. 0.457, i64 %x.0.458, i64 %x.0.459, i64 %x.0.460, i64 %x.0.461, i64 %x. 0.462, i64 %x.0.463, i64 %x.0.464, i64 %x.0.465, i64 %x.0.466, i64 %x. 0.467, i64 %x.0.468, i64 %x.0.469, i64 %x.0.470, i64 %x.0.471, i64 %x. 0.472, i64 %x.0.473, i64 %x.0.474, i64 %x.0.475, i64 %x.0.476, i64 %x. 0.477, i64 %x.0.478, i64 %x.0.479, i64 %x.0.480, i64 %x.0.481, i64 %x. 0.482, i64 %x.0.483, i64 %x.0.484, i64 %x.0.485, i64 %x.0.486, i64 %x. 0.487, i64 %x.0.488, i64 %x.0.489, i64 %x.0.490, i64 %x.0.491, i64 %x. 0.492, i64 %x.0.493, i64 %x.0.494, i64 %x.0.495, i64 %x.0.496, i64 %x. 0.497, i64 %x.0.498, i64 %x.0.499 ) nounwind readonly ; [#uses=1] declare i32 @g(i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64,i64 %x.0.277, i64 %x.0.278, i64 %x.0.279, i64 %x.0.280, i64 %x.0.281, i64 %x.0.282, i64 %x.0.283, i64 %x.0.284, i64 %x.0.285, i64 %x.0.286, i64 %x.0.287, i64 %x.0.288, i64 %x.0.289, i64 %x.0.290, i64 %x.0.291, i64 %x.0.292, i64 %x.0.293, i64 %x.0.294, i64 %x.0.295, i64 %x.0.296, i64 %x.0.297, i64 %x.0.298, i64 %x.0.299, i64 %x.0.300, i64 %x.0.301, i64 %x.0.302, i64 %x.0.303, i64 %x.0.304, i64 %x.0.305, i64 %x.0.306, i64 %x.0.307, i64 %x.0.308, i64 %x.0.309, i64 %x.0.310, i64 %x.0.311, i64 %x.0.312, i64 %x.0.313, i64 %x.0.314, i64 %x.0.315, i64 %x.0.316, i64 %x.0.317, i64 %x.0.318, i64 %x.0.319, i64 %x.0.320, i64 %x.0.321, i64 %x.0.322, i64 %x.0.323, i64 %x.0.324, i64 %x.0.325, i64 %x.0.326, i64 %x.0.327, i64 %x.0.328, i64 %x.0.329, i64 %x.0.330, i64 %x.0.331, i64 %x.0.332, i64 %x.0.333, i64 %x.0.334, i64 %x.0.335, i64 %x.0.336, i64 %x.0.337, i64 %x.0.338, i64 %x.0.339, i64 %x.0.340, i64 %x.0.341, i64 %x.0.342, i64 %x.0.343, i64 %x.0.344, i64 %x.0.345, i64 %x.0.346, i64 %x.0.347, i64 %x.0.348, i64 %x.0.349, i64 %x.0.350, i64 %x.0.351, i64 %x.0.352, i64 %x.0.353, i64 %x.0.354, i64 %x.0.355, i64 %x.0.356, i64 %x.0.357, i64 %x.0.358, i64 %x.0.359, i64 %x.0.360, i64 %x.0.361, i64 %x.0.362, i64 %x.0.363, i64 %x.0.364, i64 %x.0.365, i64 %x.0.366, i64 %x.0.367, i64 %x.0.368, i64 %x.0.369, i64 %x.0.370, i64 %x.0.371, i64 %x.0.372, i64 %x.0.373, i64 %x.0.374, i64 %x.0.375, i64 %x.0.376, i64 %x.0.377, i64 %x.0.378, i64 %x.0.379, i64 %x.0.380, i64 %x.0.381, i64 %x.0.382, i64 %x.0.383, i64 %x.0.384, i64 %x.0.385, i64 %x.0.386, i64 %x.0.387, i64 %x.0.388, i64 %x.0.389, i64 %x.0.390, i64 %x.0.391, i64 %x.0.392, i64 %x.0.393, i64 %x.0.394, i64 %x.0.395, i64 %x.0.396, i64 %x.0.397, i64 %x.0.398, i64 %x.0.399, i64 %x.0.400, i64 %x.0.401, i64 %x.0.402, i64 %x.0.403, i64 %x.0.404, i64 %x.0.405, i64 %x.0.406, i64 %x.0.407, i64 %x.0.408, i64 %x.0.409, i64 %x.0.410, i64 %x.0.411, i64 %x.0.412, i64 %x.0.413, i64 %x.0.414, i64 %x.0.415, i64 %x.0.416, i64 %x.0.417, i64 %x.0.418, i64 %x.0.419, i64 %x.0.420, i64 %x.0.421, i64 %x.0.422, i64 %x.0.423, i64 %x.0.424, i64 %x.0.425, i64 %x.0.426, i64 %x.0.427, i64 %x.0.428, i64 %x.0.429, i64 %x.0.430, i64 %x.0.431, i64 %x.0.432, i64 %x.0.433, i64 %x.0.434, i64 %x.0.435, i64 %x.0.436, i64 %x.0.437, i64 %x.0.438, i64 %x.0.439, i64 %x.0.440, i64 %x.0.441, i64 %x.0.442, i64 %x.0.443, i64 %x.0.444, i64 %x.0.445, i64 %x.0.446, i64 %x.0.447, i64 %x.0.448, i64 %x.0.449, i64 %x.0.450, i64 %x.0.451, i64 %x.0.452, i64 %x.0.453, i64 %x.0.454, i64 %x.0.455, i64 %x.0.456, i64 %x.0.457, i64 %x.0.458, i64 %x.0.459, i64 %x.0.460, i64 %x.0.461, i64 %x.0.462, i64 %x.0.463, i64 %x.0.464, i64 %x.0.465, i64 %x.0.466, i64 %x.0.467, i64 %x.0.468, i64 %x.0.469, i64 %x.0.470, i64 %x.0.471, i64 %x.0.472, i64 %x.0.473, i64 %x.0.474, i64 %x.0.475, i64 %x.0.476, i64 %x.0.477, i64 %x.0.478, i64 %x.0.479, i64 %x.0.480, i64 %x.0.481, i64 %x.0.482, i64 %x.0.483, i64 %x.0.484, i64 %x.0.485, i64 %x.0.486, i64 %x.0.487, i64 %x.0.488, i64 %x.0.489, i64 %x.0.490, i64 %x.0.491, i64 %x.0.492, i64 %x.0.493, i64 %x.0.494, i64 %x.0.495, i64 %x.0.496, i64 %x.0.497, i64 %x.0.498, i64 %x.0.499 ) nounwind readonly ; [#uses=1] declare i32 @g(i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64,64 %x.0.350, i64 %x.0.351, i64 %x.0.352, i64 % x.0.353, i64 %x.0.354, i64 %x.0.355, i64 %x.0.356, i64 %x.0.357, i64 % x.0.358, i64 %x.0.359, i64 %x.0.360, i64 %x.0.361, i64 %x.0.362, i64 % x.0.363, i64 %x.0.364, i64 %x.0.365, i64 %x.0.366, i64 %x.0.367, i64 % x.0.368, i64 %x.0.369, i64 %x.0.370, i64 %x.0.371, i64 %x.0.372, i64 % x.0.373, i64 %x.0.374, i64 %x.0.375, i64 %x.0.376, i64 %x.0.377, i64 % x.0.378, i64 %x.0.379, i64 %x.0.380, i64 %x.0.381, i64 %x.0.382, i64 % x.0.383, i64 %x.0.384, i64 %x.0.385, i64 %x.0.386, i64 %x.0.387, i64 % x.0.388, i64 %x.0.389, i64 %x.0.390, i64 %x.0.391, i64 %x.0.392, i64 % x.0.393, i64 %x.0.394, i64 %x.0.395, i64 %x.0.396, i64 %x.0.397, i64 % x.0.398, i64 %x.0.399, i64 %x.0.400, i64 %x.0.401, i64 %x.0.402, i64 % x.0.403, i64 %x.0.404, i64 %x.0.405, i64 %x.0.406, i64 %x.0.407, i64 % x.0.408, i64 %x.0.409, i64 %x.0.410, i64 %x.0.411, i64 %x.0.412, i64 % x.0.413, i64 %x.0.414, i64 %x.0.415, i64 %x.0.416, i64 %x.0.417, i64 % x.0.418, i64 %x.0.419, i64 %x.0.420, i64 %x.0.421, i64 %x.0.422, i64 % x.0.423, i64 %x.0.424, i64 %x.0.425, i64 %x.0.426, i64 %x.0.427, i64 % x.0.428, i64 %x.0.429, i64 %x.0.430, i64 %x.0.431, i64 %x.0.432, i64 % x.0.433, i64 %x.0.434, i64 %x.0.435, i64 %x.0.436, i64 %x.0.437, i64 % x.0.438, i64 %x.0.439, i64 %x.0.440, i64 %x.0.441, i64 %x.0.442, i64 % x.0.443, i64 %x.0.444, i64 %x.0.445, i64 %x.0.446, i64 %x.0.447, i64 % x.0.448, i64 %x.0.449, i64 %x.0.450, i64 %x.0.451, i64 %x.0.452, i64 % x.0.453, i64 %x.0.454, i64 %x.0.455, i64 %x.0.456, i64 %x.0.457, i64 % x.0.458, i64 %x.0.459, i64 %x.0.460, i64 %x.0.461, i64 %x.0.462, i64 % x.0.463, i64 %x.0.464, i64 %x.0.465, i64 %x.0.466, i64 %x.0.467, i64 % x.0.468, i64 %x.0.469, i64 %x.0.470, i64 %x.0.471, i64 %x.0.472, i64 % x.0.473, i64 %x.0.474, i64 %x.0.475, i64 %x.0.476, i64 %x.0.477, i64 % x.0.478, i64 %x.0.479, i64 %x.0.480, i64 %x.0.481, i64 %x.0.482, i64 % x.0.483, i64 %x.0.484, i64 %x.0.485, i64 %x.0.486, i64 %x.0.487, i64 % x.0.488, i64 %x.0.489, i64 %x.0.490, i64 %x.0.491, i64 %x.0.492, i64 % x.0.493, i64 %x.0.494, i64 %x.0.495, i64 %x.0.496, i64 %x.0.497, i64 % x.0.498, i64 %x.0.499 ) nounwind readonly ; [#uses=1] declare i32 @g(i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64,4 %x.0.350, i64 %x.0.351, i64 %x.0.352, i64 % x.0.353, i64 %x.0.354, i64 %x.0.355, i64 %x.0.356, i64 %x.0.357, i64 % x.0.358, i64 %x.0.359, i64 %x.0.360, i64 %x.0.361, i64 %x.0.362, i64 % x.0.363, i64 %x.0.364, i64 %x.0.365, i64 %x.0.366, i64 %x.0.367, i64 % x.0.368, i64 %x.0.369, i64 %x.0.370, i64 %x.0.371, i64 %x.0.372, i64 % x.0.373, i64 %x.0.374, i64 %x.0.375, i64 %x.0.376, i64 %x.0.377, i64 % x.0.378, i64 %x.0.379, i64 %x.0.380, i64 %x.0.381, i64 %x.0.382, i64 % x.0.383, i64 %x.0.384, i64 %x.0.385, i64 %x.0.386, i64 %x.0.387, i64 % x.0.388, i64 %x.0.389, i64 %x.0.390, i64 %x.0.391, i64 %x.0.392, i64 % x.0.393, i64 %x.0.394, i64 %x.0.395, i64 %x.0.396, i64 %x.0.397, i64 % x.0.398, i64 %x.0.399, i64 %x.0.400, i64 %x.0.401, i64 %x.0.402, i64 % x.0.403, i64 %x.0.404, i64 %x.0.405, i64 %x.0.406, i64 %x.0.407, i64 % x.0.408, i64 %x.0.409, i64 %x.0.410, i64 %x.0.411, i64 %x.0.412, i64 % x.0.413, i64 %x.0.414, i64 %x.0.415, i64 %x.0.416, i64 %x.0.417, i64 % x.0.418, i64 %x.0.419, i64 %x.0.420, i64 %x.0.421, i64 %x.0.422, i64 % x.0.423, i64 %x.0.424, i64 %x.0.425, i64 %x.0.426, i64 %x.0.427, i64 % x.0.428, i64 %x.0.429, i64 %x.0.430, i64 %x.0.431, i64 %x.0.432, i64 % x.0.433, i64 %x.0.434, i64 %x.0.435, i64 %x.0.436, i64 %x.0.437, i64 % x.0.438, i64 %x.0.439, i64 %x.0.440, i64 %x.0.441, i64 %x.0.442, i64 % x.0.443, i64 %x.0.444, i64 %x.0.445, i64 %x.0.446, i64 %x.0.447, i64 % x.0.448, i64 %x.0.449, i64 %x.0.450, i64 %x.0.451, i64 %x.0.452, i64 % x.0.453, i64 %x.0.454, i64 %x.0.455, i64 %x.0.456, i64 %x.0.457, i64 % x.0.458, i64 %x.0.459, i64 %x.0.460, i64 %x.0.461, i64 %x.0.462, i64 % x.0.463, i64 %x.0.464, i64 %x.0.465, i64 %x.0.466, i64 %x.0.467, i64 % x.0.468, i64 %x.0.469, i64 %x.0.470, i64 %x.0.471, i64 %x.0.472, i64 % x.0.473, i64 %x.0.474, i64 %x.0.475, i64 %x.0.476, i64 %x.0.477, i64 % x.0.478, i64 %x.0.479, i64 %x.0.480, i64 %x.0.481, i64 %x.0.482, i64 % x.0.483, i64 %x.0.484, i64 %x.0.485, i64 %x.0.486, i64 %x.0.487, i64 % x.0.488, i64 %x.0.489, i64 %x.0.490, i64 %x.0.491, i64 %x.0.492, i64 % x.0.493, i64 %x.0.494, i64 %x.0.495, i64 %x.0.496, i64 %x.0.497, i64 % x.0.498, i64 %x.0.499 ) nounwind readonly ; [#uses=1] declare i32 @g(i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, %x.0.423, i64 %x.0.424, i64 %x.0.425, i64 %x. 0.426, i64 %x.0.427, i64 %x.0.428, i64 %x.0.429, i64 %x.0.430, i64 %x. 0.431, i64 %x.0.432, i64 %x.0.433, i64 %x.0.434, i64 %x.0.435, i64 %x. 0.436, i64 %x.0.437, i64 %x.0.438, i64 %x.0.439, i64 %x.0.440, i64 %x. 0.441, i64 %x.0.442, i64 %x.0.443, i64 %x.0.444, i64 %x.0.445, i64 %x. 0.446, i64 %x.0.447, i64 %x.0.448, i64 %x.0.449, i64 %x.0.450, i64 %x. 0.451, i64 %x.0.452, i64 %x.0.453, i64 %x.0.454, i64 %x.0.455, i64 %x. 0.456, i64 %x.0.457, i64 %x.0.458, i64 %x.0.459, i64 %x.0.460, i64 %x. 0.461, i64 %x.0.462, i64 %x.0.463, i64 %x.0.464, i64 %x.0.465, i64 %x. 0.466, i64 %x.0.467, i64 %x.0.468, i64 %x.0.469, i64 %x.0.470, i64 %x. 0.471, i64 %x.0.472, i64 %x.0.473, i64 %x.0.474, i64 %x.0.475, i64 %x. 0.476, i64 %x.0.477, i64 %x.0.478, i64 %x.0.479, i64 %x.0.480, i64 %x. 0.481, i64 %x.0.482, i64 %x.0.483, i64 %x.0.484, i64 %x.0.485, i64 %x. 0.486, i64 %x.0.487, i64 %x.0.488, i64 %x.0.489, i64 %x.0.490, i64 %x. 0.491, i64 %x.0.492, i64 %x.0.493, i64 %x.0.494, i64 %x.0.495, i64 %x. 0.496, i64 %x.0.497, i64 %x.0.498, i64 %x.0.499 ) nounwind readonly ; [#uses=1] declare i32 @g(i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64,%x.0.423, i64 %x.0.424, i64 %x.0.425, i64 %x. 0.426, i64 %x.0.427, i64 %x.0.428, i64 %x.0.429, i64 %x.0.430, i64 %x. 0.431, i64 %x.0.432, i64 %x.0.433, i64 %x.0.434, i64 %x.0.435, i64 %x. 0.436, i64 %x.0.437, i64 %x.0.438, i64 %x.0.439, i64 %x.0.440, i64 %x. 0.441, i64 %x.0.442, i64 %x.0.443, i64 %x.0.444, i64 %x.0.445, i64 %x. 0.446, i64 %x.0.447, i64 %x.0.448, i64 %x.0.449, i64 %x.0.450, i64 %x. 0.451, i64 %x.0.452, i64 %x.0.453, i64 %x.0.454, i64 %x.0.455, i64 %x. 0.456, i64 %x.0.457, i64 %x.0.458, i64 %x.0.459, i64 %x.0.460, i64 %x. 0.461, i64 %x.0.462, i64 %x.0.463, i64 %x.0.464, i64 %x.0.465, i64 %x. 0.466, i64 %x.0.467, i64 %x.0.468, i64 %x.0.469, i64 %x.0.470, i64 %x. 0.471, i64 %x.0.472, i64 %x.0.473, i64 %x.0.474, i64 %x.0.475, i64 %x. 0.476, i64 %x.0.477, i64 %x.0.478, i64 %x.0.479, i64 %x.0.480, i64 %x. 0.481, i64 %x.0.482, i64 %x.0.483, i64 %x.0.484, i64 %x.0.485, i64 %x. 0.486, i64 %x.0.487, i64 %x.0.488, i64 %x.0.489, i64 %x.0.490, i64 %x. 0.491, i64 %x.0.492, i64 %x.0.493, i64 %x.0.494, i64 %x.0.495, i64 %x. 0.496, i64 %x.0.497, i64 %x.0.498, i64 %x.0.499 ) nounwind readonly ; [#uses=1] declare i32 @g(i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64,x.0.496, i64 %x.0.497, i64 %x.0.498, i64 %x. 0.499 ) nounwind readonly ; [#uses=1] declare i32 @g(i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64,.0.496, i64 %x.0.497, i64 %x.0.498, i64 %x. 0.499 ) nounwind readonly ; [#uses=1] declare i32 @g(i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64) readonly child process exited abnormally , i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64) readonly child process exited abnormally i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64) readonly child process exited abnormally i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64, i64) readonly child process exited abnormally From isanbard at gmail.com Tue Feb 19 02:42:45 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 19 Feb 2008 00:42:45 -0800 Subject: [LLVMdev] 2008-02-18-TailMergingBug.ll Failure Message-ID: Hi again, On my PPC G4 box, I'm getting this failure for TOT with llvm-gcc 4.2: Running /Users/wendling/llvm/llvm.src/test/CodeGen/X86/dg.exp ... FAIL: /Users/wendling/llvm/llvm.src/test/CodeGen/X86/2008-02-18- TailMergingBug.ll for PR1909 Failed with exit(1) at line 1 while running: llvm-as < /Users/wendling/llvm/llvm.src/test/CodeGen/ X86/2008-02-18-TailMergingBug.ll | llc -march=x86 -stats |& grep {Number of block tails merged} | grep 6 child process exited abnormally This is what I actually get: $ llvm-as < /Users/wendling/llvm/llvm.src/test/CodeGen/X86/2008-02-18- TailMergingBug.ll |\ llc -march=x86 -stats 2>&1 | grep "Number of block tails merged" 18 branchfolding - Number of block tails merged -bw From vvaditya12 at yahoo.com Tue Feb 19 03:11:22 2008 From: vvaditya12 at yahoo.com (aditya vishnubhotla) Date: Tue, 19 Feb 2008 01:11:22 -0800 (PST) Subject: [LLVMdev] Problem with variable argument intrinsics Message-ID: <281228.68790.qm@web56008.mail.re3.yahoo.com> Hi, I tried creating variable argument intrinsics which are to be placeholders for some instructions which should not be executed by the backend. Kindly help me with the errors in my "migrate_begin" intrinsic creation //Additions made to Intrinsics.td file: def llvm_migrate_begin : LLVMType; def int_migrate_begin : Intrinsic<[llvm_migrate_begin,llvm_vararg_ty],[IntrWriteMem],"llvm.migrate_begin">; //A section of the code which deals with the //"migrate_begin" intrinsic creation is as follows: const Type **Tys=(const Type**)calloc(extTys.size(),sizeof(Type*)); /* extTys vector contains data types(pointers) of formal parameters of the function "f" */ int i=0; for(vector::iterator it=extTys.begin(),e=extTys.end();it!=e;it++) {Tys[i++]=*it;} extTys.clear(); Module *M = bbp->getParent()->getParent(); Function *f = Intrinsic::getDeclaration(M,Intrinsic::migrate_begin,Tys,i); /* migrate_begin intrinsic creation */ CallInst* CI = new CallInst(f,"migrate_begin",bbp); /*bbp is pointer to basic block where intrinsic is to be inserted*/ //Errors: Overloaded intrinsic has incorrect suffix: '.i32.i32'. It should be '.i32' i32 (...)* @llvm.migrate_begin.i32.i32 Overloaded intrinsic has incorrect suffix: '.i32.i32.i32'. It should be '.i32' i32 (...)* @llvm.migrate_begin.i32.i32.i32 Broken module found, compilation aborted! ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From baldrick at free.fr Tue Feb 19 03:15:26 2008 From: baldrick at free.fr (Duncan Sands) Date: Tue, 19 Feb 2008 10:15:26 +0100 Subject: [LLVMdev] 2008-01-25-ByValReadNone.c Failure In-Reply-To: References: <3293A2C0-ECC0-40A6-B3FB-EEEFA909ED0B@gmail.com> Message-ID: <200802191015.26855.baldrick@free.fr> Hi Bill, > As you can see in it, there are "readonly" attributes on the functions. this test uses a huge array in order to be sure that it would be passed 'byval' and not as thousands of individual integer parameters. On your machine it is passed as thousands of individual integer parameters! That is the bug. Ciao, Duncan. From m1.heine at gmx.de Tue Feb 19 07:49:29 2008 From: m1.heine at gmx.de (Matthias Heine) Date: Tue, 19 Feb 2008 14:49:29 +0100 Subject: [LLVMdev] llc: assertion fails in bitreader.cpp Message-ID: <20080219134929.258160@gmx.net> Hi all, I've used the llvmgcc to compile a quite simple bit of c-code: >short addtest(short a, short b) >{ > return a+b; >} When I'm feeding llc (llvm-2.1-version) with the resulting bytecode, it fails with this error: llc: BitcodeReader.cpp:1040: bool llvm::BitcodeReader::ParseModule(const std::string&): Assertion `Func->getFunctionType()->getParamAttrs() == getParamAttrs(Record[4])' failed. Has anyone ever experienced something similar? Thanks in advance! Matthias -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From kevin.andre at student.ua.ac.be Tue Feb 19 08:54:01 2008 From: kevin.andre at student.ua.ac.be (=?UTF-8?Q?Kevin_Andr=C3=A9?=) Date: Tue, 19 Feb 2008 15:54:01 +0100 Subject: [LLVMdev] cross compiling with the C backend In-Reply-To: <47BA1933.1070805@mxc.ca> References: <20d882600802180809q4d8c88fen7822c12c486bd5ae@mail.gmail.com> <47BA1933.1070805@mxc.ca> Message-ID: <20d882600802190654y3745c9f0n5b1759e5c696c5cf@mail.gmail.com> On Feb 19, 2008 12:48 AM, Nick Lewycky wrote: > No, it's not portable like that. Here's what goes on. > > C is portable in the sense that it gives you enough tools to inspect > your environment. So an 'int' might be any number of chars (which > themselves may be any number of bits >= 8), but that's okay because C > provides 'sizeof(int)'. If you have code like "char *x = > malloc(sizeof(int));" you're going to get different LLVM bytecode > depending on what platform your llvm-gcc is set to. > > LLVM is portable in the sense that the bytecode will behave the same way > on every platform. So if the above code becomes "%x_addr = malloc i32" > then you get a 32-bit integer regardless of the abilities of the > underlying system. This is what I thought as well, but I remember reading something that said you could use the C backend for architectures that do not have a 'real' codegenerator for LLVM yet. > Finally, the C backend's output isn't portable in the sense that it uses > GCC extensions to get the correct output. Which is fine so long as > you're compiling its output with GCC. ... which is the case here. > Building llvm-gcc as a cross-compiler would help, if there's a platform > you can select that matches the PSP more closely. I did some testing and it seems that my native gcc already is similar enough. I compiled the following statements: printf(" sizeof(char) = %i\n", sizeof(char)); printf(" sizeof(char*) = %i\n", sizeof(char*)); printf(" sizeof(void*) = %i\n", sizeof(void*)); printf(" sizeof(int) = %i\n", sizeof(int)); printf(" sizeof(unsigned) = %i\n", sizeof(unsigned)); printf(" sizeof(short) = %i\n", sizeof(short)); printf(" sizeof(float) = %i\n", sizeof(float)); printf(" sizeof(double) = %i\n", sizeof(double)); printf(" endianness = %s\n", htonl(123) == 123 ? "big" : "little"); printf(" CHAR_BIT = %i\n", CHAR_BIT); printf(" CHAR_MIN = %i\n", CHAR_MIN); printf(" CHAR_MAX = %i\n", CHAR_MAX); printf(" INT_MIN = %i\n", INT_MIN); printf(" INT_MAX = %i\n", INT_MAX); with both psp-gcc and my gcc and they print exactly the same result: sizeof(char) = 1 sizeof(char*) = 4 sizeof(void*) = 4 sizeof(int) = 4 sizeof(unsigned) = 4 sizeof(short) = 2 sizeof(float) = 4 sizeof(double) = 8 endianness = little CHAR_BIT = 8 CHAR_MIN = -128 CHAR_MAX = 127 INT_MIN = -2147483648 INT_MAX = 2147483647 This explains why the Pi_Calc program does work when compiled with the build process I described in my original message. So the difference is more subtle; maybe a difference in the layout of structs or something. > Besides that, the > warning you gave as an example is probably because llvm-gcc 4.2 is a > newer version of gcc than psp-gcc. Yup, my psp-gcc is still 4.1.0. And I get these kinds of warnings when compiling the output of the C backend with psp-gcc: llvmoutput.c:734: warning: conflicting types for built-in function 'malloc' llvmoutput.c:1332: warning: return type of 'main' is not 'int' llvmoutput.c: In function 'loadImage': llvmoutput.c:2939: warning: pointer targets in passing argument 1 of 'setjmp' differ in signedness (...) llvmoutput.c: In function 'png_default_error': llvmoutput.c:17976: warning: pointer targets in passing argument 1 of 'longjmp' differ in signedness llvmoutput.c: In function 'png_crc_finish': llvmoutput.c:18722: warning: 'llvm_cbe_i9_0_reg2mem_1__PHI_TEMPORARY' may be used uninitialized in this function (...) Maybe I should pass "-nostdlib" to llvm-gcc as well. And I'll try if using "-O1" instead of "-O5" makes a difference. Thanks, Kevin Andr? From baldrick at free.fr Tue Feb 19 09:14:31 2008 From: baldrick at free.fr (Duncan Sands) Date: Tue, 19 Feb 2008 16:14:31 +0100 Subject: [LLVMdev] llc: assertion fails in bitreader.cpp In-Reply-To: <20080219134929.258160@gmx.net> References: <20080219134929.258160@gmx.net> Message-ID: <200802191614.31978.baldrick@free.fr> > When I'm feeding llc (llvm-2.1-version) with the resulting bytecode, it fails with this error: It sounds like the version of llvm-gcc doesn't match the version of llc. What does the llvm assembler look like (i.e. what llvm-dis gives for the bitcode)? D. From m1.heine at gmx.de Tue Feb 19 09:21:24 2008 From: m1.heine at gmx.de (Matthias Heine) Date: Tue, 19 Feb 2008 16:21:24 +0100 Subject: [LLVMdev] llc: assertion fails in bitreader.cpp Message-ID: <47BAF3F4.8080507@gmx.de> Hi there, problem is solved, thanks go out to Duncan Sands. >It sounds like the version of llvm-gcc doesn't match the version of llc. >What does the llvm assembler look like (i.e. what llvm-dis gives for the >bitcode)? > >D. The bitcode was indeed produced with the gcc frontend for llvm-2.2 and used with llc from llvm-2.1. Thanks for helping me out! Matthias Heine From asl at math.spbu.ru Tue Feb 19 09:31:10 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Tue, 19 Feb 2008 18:31:10 +0300 (MSK) Subject: [LLVMdev] =?utf-8?q?cross_compiling_with_the_C_backend?= Message-ID: <200802191531.m1JFVAYO039471@star.math.spbu.ru> Hello, Kevin > build process I described in my original message. So the difference is > more subtle; maybe a difference in the layout of structs or something. Also, there can be another ABI differences. > llvmoutput.c:17976: warning: pointer targets in passing argument 1 of > 'longjmp' differ in signedness Hrm, are you using setjmp/longjmp stuff? They're definitely not portable at all. -- WBR, Anton Korobeynikov From kevin.andre at student.ua.ac.be Tue Feb 19 10:14:23 2008 From: kevin.andre at student.ua.ac.be (=?UTF-8?Q?Kevin_Andr=C3=A9?=) Date: Tue, 19 Feb 2008 17:14:23 +0100 Subject: [LLVMdev] cross compiling with the C backend In-Reply-To: <200802191531.m1JFVAYO039471@star.math.spbu.ru> References: <200802191531.m1JFVAYO039471@star.math.spbu.ru> Message-ID: <20d882600802190814j17b949c5r522257487cc97dc0@mail.gmail.com> On Feb 19, 2008 4:31 PM, Anton Korobeynikov wrote: > Hello, Kevin > > > build process I described in my original message. So the difference is > > more subtle; maybe a difference in the layout of structs or something. > Also, there can be another ABI differences. Could you give an example? > > llvmoutput.c:17976: warning: pointer targets in passing argument 1 of > > 'longjmp' differ in signedness > Hrm, are you using setjmp/longjmp stuff? They're definitely not portable > at all. I didn't wrote the program :) No, I just recompile a program that was already written for (or ported to) the PSP. It seems that "setjmp" is used in libpng. The program and the libraries it uses (libpng and zlib) should be correct because the program works as expected when I compile it with the PSP toolchain. From bkelly.ie at gmail.com Tue Feb 19 10:31:54 2008 From: bkelly.ie at gmail.com (Barry Kelly) Date: Tue, 19 Feb 2008 16:31:54 +0000 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <022901c872ba$cc8f0e30$65ad2a90$@com> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com><001101c87201$8bd624a0$a3826de0$@com> <002001c87205$e31b28b0$a9517a10$@com> <680422C0AA225644931C2F6DD07200DD018DD3FC@namail5.corp.adobe.com> <022901c872ba$cc8f0e30$65ad2a90$@com> Message-ID: <321mr3totf4ndk2d8n2jp2tqndp9cl8iek@4ax.com> > For whatever reason, only by manually deleting the config.h file in the > llvm/include/Config directory can I get the project to re-gen that config.h > file. I'm not sure if this is a property of running the build from the > command-line (but I'm guessing it's not, since MSBuild is used internally > inside VS), or if the file-copy is being prevented by something in my > environment (files are marked writable, I already checked). The MSBuild infrastructure isn't used by VS 2005 for C++ projects; rather, VCBuild does the work. I'm not sure about VS 2008. FWIW, I used ProcMon to diagnose file-handling issues I had in my build: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx -- Barry -- http://barrkel.blogspot.com/ From dalej at apple.com Tue Feb 19 11:24:25 2008 From: dalej at apple.com (Dale Johannesen) Date: Tue, 19 Feb 2008 09:24:25 -0800 Subject: [LLVMdev] 2008-01-25-ByValReadNone.c Failure In-Reply-To: <200802191015.26855.baldrick@free.fr> References: <3293A2C0-ECC0-40A6-B3FB-EEEFA909ED0B@gmail.com> <200802191015.26855.baldrick@free.fr> Message-ID: <428CE5FE-6A20-4DBE-8DCF-FDBC1D793B3F@apple.com> On Feb 19, 2008, at 1:15 AM, Duncan Sands wrote: > Hi Bill, > >> As you can see in it, there are "readonly" attributes on the >> functions. > > this test uses a huge array in order to be sure that it would be > passed > 'byval' and not as thousands of individual integer parameters. On > your > machine it is passed as thousands of individual integer parameters! > That > is the bug. Right now byval is really only implemented on x86. The more interesting question IMO is why this test isn't failing in the nightly PPC32 test runs. It ought to be (it fails for me locally on ppc, and has for a while, probably always). From sabre at nondot.org Tue Feb 19 12:34:23 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 19 Feb 2008 10:34:23 -0800 (PST) Subject: [LLVMdev] 2008-01-25-ByValReadNone.c Failure In-Reply-To: <200802191015.26855.baldrick@free.fr> References: <3293A2C0-ECC0-40A6-B3FB-EEEFA909ED0B@gmail.com> <200802191015.26855.baldrick@free.fr> Message-ID: On Tue, 19 Feb 2008, Duncan Sands wrote: >> As you can see in it, there are "readonly" attributes on the functions. > > this test uses a huge array in order to be sure that it would be passed > 'byval' and not as thousands of individual integer parameters. On your > machine it is passed as thousands of individual integer parameters! That > is the bug. For now, please just mark this test as xfail on ppc, arm, and other non-x86 targets. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Tue Feb 19 12:40:58 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 19 Feb 2008 10:40:58 -0800 (PST) Subject: [LLVMdev] 2008-02-18-TailMergingBug.ll Failure In-Reply-To: References: Message-ID: On Tue, 19 Feb 2008, Bill Wendling wrote: > On my PPC G4 box, I'm getting this failure for TOT with llvm-gcc 4.2: Fixed. -Chris > FAIL: /Users/wendling/llvm/llvm.src/test/CodeGen/X86/2008-02-18- > TailMergingBug.ll for PR1909 > Failed with exit(1) at line 1 > while running: llvm-as < /Users/wendling/llvm/llvm.src/test/CodeGen/ > X86/2008-02-18-TailMergingBug.ll | llc -march=x86 -stats |& grep > {Number of block tails merged} | grep 6 > child process exited abnormally > > This is what I actually get: > > $ llvm-as < /Users/wendling/llvm/llvm.src/test/CodeGen/X86/2008-02-18- > TailMergingBug.ll |\ > llc -march=x86 -stats 2>&1 | grep "Number of block tails merged" > 18 branchfolding - Number of block tails merged > > -bw > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From kevin.andre at student.ua.ac.be Tue Feb 19 12:25:53 2008 From: kevin.andre at student.ua.ac.be (=?UTF-8?Q?Kevin_Andr=C3=A9?=) Date: Tue, 19 Feb 2008 19:25:53 +0100 Subject: [LLVMdev] cross compiling with the C backend In-Reply-To: <200802191624.m1JGOhjN078118@star.math.spbu.ru> References: <200802191624.m1JGOhjN078118@star.math.spbu.ru> Message-ID: <20d882600802191025n60311874hd52c610d4876c5b1@mail.gmail.com> On Feb 19, 2008 5:24 PM, Anton Korobeynikov wrote: > > Could you give an example? > Different alignment issues, for example. LLVM handles alignment > explicitely by inserting dummy padding fields. Surely, the stuff can be > different for build platform and for target one. > > Also, many platform-dependent stuff in POSIX-aware code (see example later). I see. > > I didn't wrote the program :) No, I just recompile a program that was > > already written for (or ported to) the PSP. It seems that "setjmp" is > > used in libpng. The program and the libraries it uses (libpng and > > zlib) should be correct > Unfortunately, this cannot be true in your case :( For example, > longjmp/setjmp accepts struct jmp_buf as an argument, but the contents > of such struct is highly target dependent (since it used to save current > context, etc). > > There are some places in POSIX standards containing wording of form > "struct 'foo' should contain field 'bar'" without specifying the precise > position of this field. > > In general, you will need to configure a crosscompiler, or, at least, > hack llvm-gcc to use correct system headers for your target plaform (not > for the build!). Well, I already use custom includes with these options: "-nostdlib -nostdinc -Ipsptoolchain/psp/include -Ipsptoolchain/lib/gcc/psp/4.1.0/include". But that seems not enough. GCC has some target-specific behaviour compiled in? From evan.cheng at apple.com Tue Feb 19 12:41:33 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 19 Feb 2008 10:41:33 -0800 Subject: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build In-Reply-To: <200802190143.m1J1h711094035@star.math.spbu.ru> References: <200802190143.m1J1h711094035@star.math.spbu.ru> Message-ID: <745748D7-4C8B-425F-9520-3E6BC7AFCD62@apple.com> I think a Win64 version of X86CompilationCallback{2} is still needed. Also, it's not clear to me how to force a non-Windows CC. It may require some FE extension to support it? Evan On Feb 18, 2008, at 5:43 PM, Anton Korobeynikov wrote: > > Hello, Chuck > >> Would my life be made fantastically simpler if I were using a >> different >> calling convention for my callback functions on x64 running on >> Windows? > Yes, surely. You can still use 'normal' x86-64 CC if you don't want to > call any external functions from code being JITed. Also note a Win64 > fixme in the X86CompilationCallback2 function, this can be your > case. I > think the code there should be carefully inspected to be compatible > with > windows64. > > Anyway, win64 version of compilation callback function should be > added, > otherwise you'll quickly result to messed stack, invalid incoming > args, > etc (this can be exactly your case now, btw). > > Also, I think that you should carefully inspect, what to save there, > because you will 'mix' two CCs: JITer itself will be compiled with > win64 > CC and function JITed with normal x86-64 CC and they shouldn't trash > the > states of each other during crossing of 'CC border'. > > -- > WBR, Anton Korobeynikov From evan.cheng at apple.com Tue Feb 19 12:47:05 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 19 Feb 2008 10:47:05 -0800 Subject: [LLVMdev] More address registers In-Reply-To: <3212b1a80802181324x476482fas69ecf5d6b131f5a5@mail.gmail.com> References: <3212b1a80802151347j5435f2eeqcae8b8424375ea9d@mail.gmail.com> <3212b1a80802181324x476482fas69ecf5d6b131f5a5@mail.gmail.com> Message-ID: <99F32C78-8C88-4154-816B-8BB369DB932D@apple.com> On Feb 18, 2008, at 1:24 PM, Andreas Fredriksson wrote: > 2008/2/15, Andreas Fredriksson : > I tried mocking this up using the following. (Base is what's > returned as the Ax in the move expression above when the DAG is > constructed due to SelectAddr().) > > SDOperand chain = CurDAG->getCopyToReg(Base, M68K::A3, Base); > Base = CurDAG->getCopyFromReg(chain, M68K::A3, MVT::i32); > > Replying to myself here. > > This worked a bit better :) > > const unsigned addressReg = RegMap- > >createVirtualRegister(&M68K::AR32RegClass); > SDOperand chain = CurDAG->getCopyToReg(Base, addressReg, Base); > Base = CurDAG->getCopyFromReg(chain, addressReg, MVT::i32); This probably will produce correct code since the copy source and destination registers are of different register classes it's not in danger of being coalesced away. But as you have seen, it'll produce poor code. I think it's a reasonable step in the right direction though. Evan > > > > // Andreas > _______________________________________________ > 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/20080219/bbd826d9/attachment.html From gohman at apple.com Tue Feb 19 12:48:17 2008 From: gohman at apple.com (Dan Gohman) Date: Tue, 19 Feb 2008 10:48:17 -0800 Subject: [LLVMdev] Problem with variable argument intrinsics In-Reply-To: <281228.68790.qm@web56008.mail.re3.yahoo.com> References: <281228.68790.qm@web56008.mail.re3.yahoo.com> Message-ID: <14262CD2-0FAB-404E-9766-17B6F8FCBC56@apple.com> On Feb 19, 2008, at 1:11 AM, aditya vishnubhotla wrote: > Hi, > I tried creating variable argument intrinsics which > are to be placeholders for some instructions which > should not be executed by the backend. > > Kindly help me with the errors in my "migrate_begin" > intrinsic creation > > //Additions made to Intrinsics.td file: > > def llvm_migrate_begin : LLVMType; > def int_migrate_begin : > Intrinsic<[llvm_migrate_begin,llvm_vararg_ty], > [IntrWriteMem],"llvm.migrate_begin">; This says that the return type is overloaded (because it's iAny). But that's the only overloaded part here; using variadic argument lists is different from overloading. > > > Overloaded intrinsic has incorrect suffix: '.i32.i32'. > It should be '.i32' > i32 (...)* @llvm.migrate_begin.i32.i32 > > Overloaded intrinsic has incorrect suffix: > '.i32.i32.i32'. It should be '.i32' > i32 (...)* @llvm.migrate_begin.i32.i32.i32 The suffix has a part for each overloaded type in the function type. Since only the return type is overloaded, the verifier is expecting only one type to be passed into getDeclaration. Dan From daniel at zuster.org Tue Feb 19 12:44:23 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Tue, 19 Feb 2008 10:44:23 -0800 (PST) Subject: [LLVMdev] lli external functions Message-ID: <247618.16348.qm@web54603.mail.re2.yahoo.com> I find the behavior of lli (in --force-interpreter mode) rather strange when calling external functions. Currently if a function has not been defined in the internal "known external" function table it just tries to resolve the symbol and cast it to its generic external function type. Is this really the intended behavior? This is most likely to cause the interpreter to crash without warning when it calls the function. The only use case seems to be if a user wants to explicitly extend the interpreter by providing a loadable module of functions that expect to be called in this fashion, but that doesn't seem very common (and is undocumented?). It seems like it would make more sense for the interpreter to just give up and report an error to the user (or at least give a warning that it is calling into arbitrary binary code). In any case, it seems like lli should know how to call memmove. Patch attached. - Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: lli-memmove-support.patch Type: application/octet-stream Size: 1269 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080219/ee149b78/attachment.obj From isanbard at gmail.com Tue Feb 19 12:56:28 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 19 Feb 2008 10:56:28 -0800 Subject: [LLVMdev] 2008-01-25-ByValReadNone.c Failure In-Reply-To: <200802191015.26855.baldrick@free.fr> References: <3293A2C0-ECC0-40A6-B3FB-EEEFA909ED0B@gmail.com> <200802191015.26855.baldrick@free.fr> Message-ID: <16e5fdf90802191056w29f09618v59c97eb4d254e954@mail.gmail.com> On Feb 19, 2008 1:15 AM, Duncan Sands wrote: > Hi Bill, > > > As you can see in it, there are "readonly" attributes on the functions. > > this test uses a huge array in order to be sure that it would be passed > 'byval' and not as thousands of individual integer parameters. On your > machine it is passed as thousands of individual integer parameters! That > is the bug. > Ah ha! That would explain it. :-) I'll file a PR. -bw From isanbard at gmail.com Tue Feb 19 13:02:50 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 19 Feb 2008 11:02:50 -0800 Subject: [LLVMdev] 2008-01-25-ByValReadNone.c Failure In-Reply-To: <428CE5FE-6A20-4DBE-8DCF-FDBC1D793B3F@apple.com> References: <3293A2C0-ECC0-40A6-B3FB-EEEFA909ED0B@gmail.com> <200802191015.26855.baldrick@free.fr> <428CE5FE-6A20-4DBE-8DCF-FDBC1D793B3F@apple.com> Message-ID: <16e5fdf90802191102ie6200b2ra5b3afc4822a7024@mail.gmail.com> On Feb 19, 2008 9:24 AM, Dale Johannesen wrote: > On Feb 19, 2008, at 1:15 AM, Duncan Sands wrote: > > > Hi Bill, > > > >> As you can see in it, there are "readonly" attributes on the > >> functions. > > > > this test uses a huge array in order to be sure that it would be > > passed > > 'byval' and not as thousands of individual integer parameters. On > > your > > machine it is passed as thousands of individual integer parameters! > > That > > is the bug. > > Right now byval is really only implemented on x86. The more > interesting question IMO is why this test isn't failing in the nightly > PPC32 test runs. It ought to be (it fails for me locally on ppc, and > has for a while, probably always). > Could it be partially implemented on some of the other machines? I filed PR2068 to keep track of this. -bw From isanbard at gmail.com Tue Feb 19 13:04:09 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 19 Feb 2008 11:04:09 -0800 Subject: [LLVMdev] 2008-02-18-TailMergingBug.ll Failure In-Reply-To: References: Message-ID: <16e5fdf90802191104x4bfbf829ta1ae4dfaf89bdfec@mail.gmail.com> On Feb 19, 2008 10:40 AM, Chris Lattner wrote: > On Tue, 19 Feb 2008, Bill Wendling wrote: > > On my PPC G4 box, I'm getting this failure for TOT with llvm-gcc 4.2: > > Fixed. > Thanks! -bw From asl at math.spbu.ru Tue Feb 19 14:07:07 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Tue, 19 Feb 2008 23:07:07 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?Y3Jvc3MgY29tcGlsaW5nIHdpdGggdGhlIEMgYmFja2Vu?= =?koi8-r?b?ZA==?= Message-ID: <200802192007.m1JK770f023784@star.math.spbu.ru> Hello, Kevin. > Well, I already use custom includes with these options: "-nostdlib > -nostdinc -Ipsptoolchain/psp/include > -Ipsptoolchain/lib/gcc/psp/4.1.0/include". But that seems not enough. > GCC has some target-specific behaviour compiled in? Well, in general - yes. However, I'm not sure up to which margin. -- WBR, Anton Korobeynikov From asl at math.spbu.ru Tue Feb 19 14:12:15 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Tue, 19 Feb 2008 23:12:15 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?TExWTTIuMiB4NjQgSklUIHRyb3VibGUgb24gVlN0dWRp?= =?koi8-r?b?byBidWlsZA==?= Message-ID: <200802192012.m1JKCEcl047552@star.math.spbu.ru> Hello, Evan > I think a Win64 version of X86CompilationCallback{2} is still needed. > Also, it's not clear to me how to force a non-Windows CC. It may > require some FE extension to support it? Well, as currently we don't have windows64 support in FE correct (non-windows) CC will be set automatically. -- WBR, Anton Korobeynikov From tobias.oberstein at gmx.de Tue Feb 19 18:19:26 2008 From: tobias.oberstein at gmx.de (Tobias Oberstein) Date: Wed, 20 Feb 2008 01:19:26 +0100 Subject: [LLVMdev] Problems building LLVM 2.2 for ARM Message-ID: <47BB720E.5010005@gmx.de> Hello, I'd like to do some initial experiments with LLVM on embedded ARM (Nokia N800), but ran into a build issue. Could s.o. give me a tip? Thx alot, Tobias P.S.: just as sidenote, LLVM 2.2 builds cleanly on GCC 4.2.3 / Linux. === I'm building on Ubuntu/Scratchbox/ARMEL using GCC 3.4.4 (CodeSourcery ARM 2005q3-2) using ./configure --prefix=$HOME/local/llvm-2.2 --enable-jit --enable-threads --enable-shared --enable-optimized I could reproduce, but overcome the problems described in dox regarding optimized built: """ GCC 3.4.4 (CodeSourcery ARM 2005q3-2): this compiler miscompiles LLVM when building with optimizations enabled. It appears to work with "make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O1" or build a debug build. http://www.llvm.org/docs/GettingStarted.html#brokengcc """ by just going to problematic dirs llvm-2.2/lib/CodeGen/SelectionDAG lib/Target/PowerPC and do make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O1 -- However, much later, the build stops with [sbox-CHINOOK_ARMEL: ~/build/llvm-2.2/tools/llvm-config] > make llvm[0]: Checking for cyclic dependencies between LLVM libraries. find-cycles.pl: Circular dependency between *.a files: find-cycles.pl: libLLVMCodeGen.a libLLVMScalarOpts.a libLLVMSelectionDAG.a llvm[0]: Building llvm-config script. cat: /home/oberstet/build/llvm-2.2/tools/llvm-config/FinalLibDeps.txt: No such file or directory make: *** [/home/oberstet/build/llvm-2.2/Release/bin/llvm-config] Error 1 [sbox-CHINOOK_ARMEL: ~/build/llvm-2.2/tools/llvm-config] > which leaves me pretty lost. Whats the prob? From tobias.oberstein at gmx.de Tue Feb 19 18:26:08 2008 From: tobias.oberstein at gmx.de (Tobias Oberstein) Date: Wed, 20 Feb 2008 01:26:08 +0100 Subject: [LLVMdev] ctpop intrinsic question Message-ID: <47BB73A0.4080008@gmx.de> Hello, is it correct, that the "llvm.ctpop" Hamming weight intrinsic is currently (LLVM 2.2) implemented in Line 254 in lib/CodeGen/IntrinsicLowering.cpp /// LowerCTPOP - Emit the code to lower ctpop of V before the specified /// instruction IP. static Value *LowerCTPOP(Value *V, Instruction *IP) { assert(V->getType()->isInteger() && "Can't ctpop a non-integer type!"); and that the implemented algorithm is essentially the first of the 3 given tree reduction based algorithms given in http://en.wikipedia.org/wiki/Hamming_weight?? How can I emit that intrinsic from LLVMBuilder? What is the correct LLVM textual IR representation? I tried ; ModuleID = 'test' define i64 @popcount(i64 %x) { entry: %tmp = call i64 @llvm.ctpop.i64(i64 %x) ret i64 %tmp } which gives me errors .. I tried several others and read the lang. ref., but I don't get it;( Any hints appreciated, Tobias From evan.cheng at apple.com Tue Feb 19 18:50:47 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 19 Feb 2008 16:50:47 -0800 Subject: [LLVMdev] lli external functions In-Reply-To: <247618.16348.qm@web54603.mail.re2.yahoo.com> References: <247618.16348.qm@web54603.mail.re2.yahoo.com> Message-ID: On Feb 19, 2008, at 10:44 AM, Daniel Dunbar wrote: > I find the behavior of lli (in --force-interpreter mode) rather > strange when calling external > functions. Currently if a function has not been defined in the > internal "known external" > function table it just tries to resolve the symbol and cast it to > its generic external function > type. > > Is this really the intended behavior? This is most likely to cause > the interpreter to crash > without warning when it calls the function. The only use case seems > to be if a user wants > to explicitly extend the interpreter by providing a loadable module > of functions that expect > to be called in this fashion, but that doesn't seem very common (and > is undocumented?). > It seems like it would make more sense for the interpreter to just > give up and report an > error to the user (or at least give a warning that it is calling > into arbitrary binary code). I think this is the acceptable behavior for an interpreter which does not make use of OS facility. Known functions are added on demand. > > > In any case, it seems like lli should know how to call memmove. > Patch attached. Thanks. I'll apply. Evan > > > - Daniel > support.patch>_______________________________________________ > 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 Tue Feb 19 18:51:15 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Tue, 19 Feb 2008 18:51:15 -0600 Subject: [LLVMdev] compare and swap In-Reply-To: <85dfcd7f0802160955r55274fa5yb35883f575e52d66@mail.gmail.com> References: <85dfcd7f0802160955r55274fa5yb35883f575e52d66@mail.gmail.com> Message-ID: <85dfcd7f0802191651w5edcfaa2g45e782e06e5bd7b@mail.gmail.com> I was working on compare and swap and ran into the following problem. Several architectures implement this with a load locked, store conditional sequence. This is good, for those archs I can write generic code to legalize a compare and swap (and most other atomic ops) to load locked store conditional sequences (then the arch only had to give the instr for ldl, stc to support all atomic ops (this applies to mips, arm, ppc, and alpha)). However, I have to split the basic block at the CAS instruction and create two more basic blocks. This isn't currently possible during legalize, nor during the initial SelectionDAG formation (the tricks switch lowering uses only work for terminator instructions). Anyone have an idea? The patch as it stands is attached below. X86 is a pseudo instruction because the necessary ones and prefixes aren't in the code gen yet, but I would imagine they will be (so ignore that ugliness). The true ugliness can be seen in the alpha impl which open codes it, including a couple relative branches. The code sequence for alpha is identical to ppc, mips, and arm, so it would be nice to lower these to the correct sequences before code gen rather than splitting (or hiding as I did here) basic blocks after code gen. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: lcs.patch Type: text/x-diff Size: 15126 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080219/9554a14a/attachment-0001.bin From gohman at apple.com Tue Feb 19 19:14:41 2008 From: gohman at apple.com (Dan Gohman) Date: Tue, 19 Feb 2008 17:14:41 -0800 Subject: [LLVMdev] ctpop intrinsic question In-Reply-To: <47BB73A0.4080008@gmx.de> References: <47BB73A0.4080008@gmx.de> Message-ID: On Feb 19, 2008, at 4:26 PM, Tobias Oberstein wrote: > Hello, > > is it correct, that the "llvm.ctpop" Hamming weight intrinsic is > currently (LLVM 2.2) implemented in > > Line 254 in lib/CodeGen/IntrinsicLowering.cpp > > /// LowerCTPOP - Emit the code to lower ctpop of V before the > specified > /// instruction IP. > static Value *LowerCTPOP(Value *V, Instruction *IP) { > assert(V->getType()->isInteger() && "Can't ctpop a non-integer > type!"); > > > and that the implemented algorithm is essentially the first of the 3 > given tree reduction based algorithms given in > > http://en.wikipedia.org/wiki/Hamming_weight?? Yes. Most targets, unless they have target-specific ways to implement ctpop, actually use the code in SelectionDAGLegalize::ExpandBitCount in lib/CodeGen/SelectionDAG/LegalizeDAG.cpp to do the lowering. It also appears to use the same algorithm as the one you reference. > > > How can I emit that intrinsic from LLVMBuilder? > Use Intrinsic::getDeclaration (see include/llvm/Intrinsics.h) to get a Function* for the intrinsic function, which can then be called like a normal function. ctpop has one overloaded type, so you must pass Intrinsic::getDeclaration a pointer to an array of Type* for the type you want to use (eg. Int64Ty), and a count of 1. > > What is the correct LLVM textual IR representation? I tried > > ; ModuleID = 'test' > > define i64 @popcount(i64 %x) { > entry: > %tmp = call i64 @llvm.ctpop.i64(i64 %x) > ret i64 %tmp > } It's necessary to include a declaration for the intrinsic, which would look like this: declare i64 @llvm.ctpop.i64(i64) Dan From evan.cheng at apple.com Tue Feb 19 19:33:26 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 19 Feb 2008 17:33:26 -0800 Subject: [LLVMdev] compare and swap In-Reply-To: <85dfcd7f0802191651w5edcfaa2g45e782e06e5bd7b@mail.gmail.com> References: <85dfcd7f0802160955r55274fa5yb35883f575e52d66@mail.gmail.com> <85dfcd7f0802191651w5edcfaa2g45e782e06e5bd7b@mail.gmail.com> Message-ID: <6C9C8178-9330-4693-B3FF-58470E1D44C2@apple.com> The current *hack* solution is to mark your pseudo instruction with usesCustomDAGSchedInserter = 1. That allows the targets to expand it at scheduling time by providing a EmitInstrWithCustomInserter() hook. You can create new basic blocks then. Evan On Feb 19, 2008, at 4:51 PM, Andrew Lenharth wrote: > I was working on compare and swap and ran into the following problem. > Several architectures implement this with a load locked, store > conditional sequence. This is good, for those archs I can write > generic code to legalize a compare and swap (and most other atomic > ops) to load locked store conditional sequences (then the arch only > had to give the instr for ldl, stc to support all atomic ops (this > applies to mips, arm, ppc, and alpha)). However, I have to split the > basic block at the CAS instruction and create two more basic blocks. > > This isn't currently possible during legalize, nor during the initial > SelectionDAG formation (the tricks switch lowering uses only work for > terminator instructions). > > Anyone have an idea? The patch as it stands is attached below. X86 > is a pseudo instruction because the necessary ones and prefixes aren't > in the code gen yet, but I would imagine they will be (so ignore that > ugliness). The true ugliness can be seen in the alpha impl which open > codes it, including a couple relative branches. The code sequence for > alpha is identical to ppc, mips, and arm, so it would be nice to lower > these to the correct sequences before code gen rather than splitting > (or hiding as I did here) basic blocks after code gen. > > Andrew > _______________________________________________ > 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 Tue Feb 19 19:41:59 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Tue, 19 Feb 2008 19:41:59 -0600 Subject: [LLVMdev] compare and swap In-Reply-To: <6C9C8178-9330-4693-B3FF-58470E1D44C2@apple.com> References: <85dfcd7f0802160955r55274fa5yb35883f575e52d66@mail.gmail.com> <85dfcd7f0802191651w5edcfaa2g45e782e06e5bd7b@mail.gmail.com> <6C9C8178-9330-4693-B3FF-58470E1D44C2@apple.com> Message-ID: <85dfcd7f0802191741r46d8d299q74dee19e3fd45b76@mail.gmail.com> On 2/19/08, Evan Cheng wrote: > The current *hack* solution is to mark your pseudo instruction with > usesCustomDAGSchedInserter = 1. That allows the targets to expand it > at scheduling time by providing a EmitInstrWithCustomInserter() hook. > You can create new basic blocks then. I guess that can work in the short term. It just seems wasteful for each target that uses ldl/stc sequences to have to all implement it. But if that is what we can do right now, I'll give that a shot. Thanks, Andrew From sabre at nondot.org Tue Feb 19 21:43:17 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 19 Feb 2008 19:43:17 -0800 Subject: [LLVMdev] compare and swap In-Reply-To: <85dfcd7f0802191741r46d8d299q74dee19e3fd45b76@mail.gmail.com> References: <85dfcd7f0802160955r55274fa5yb35883f575e52d66@mail.gmail.com> <85dfcd7f0802191651w5edcfaa2g45e782e06e5bd7b@mail.gmail.com> <6C9C8178-9330-4693-B3FF-58470E1D44C2@apple.com> <85dfcd7f0802191741r46d8d299q74dee19e3fd45b76@mail.gmail.com> Message-ID: <40571E80-57FB-466D-B5B1-EBAF24033A72@nondot.org> On Feb 19, 2008, at 5:41 PM, Andrew Lenharth wrote: > On 2/19/08, Evan Cheng wrote: >> The current *hack* solution is to mark your pseudo instruction with >> usesCustomDAGSchedInserter = 1. That allows the targets to expand it >> at scheduling time by providing a EmitInstrWithCustomInserter() hook. >> You can create new basic blocks then. > > I guess that can work in the short term. It just seems wasteful for > each target that uses ldl/stc sequences to have to all implement it. > But if that is what we can do right now, I'll give that a shot. I agree with Evan. This solution is not wonderful but it is the best we have right now. -chris From xi.wang at gmail.com Tue Feb 19 22:02:29 2008 From: xi.wang at gmail.com (Xi Wang) Date: Wed, 20 Feb 2008 12:02:29 +0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <20080212000436.BBO10317@expms2.cites.uiuc.edu> References: <20080212000436.BBO10317@expms2.cites.uiuc.edu> Message-ID: Hi there, Did anyone try VS2008/Vista? There would a compile error (LLVM 2.1/2.2) at Line 126 in the file DynamicLibrary.inc. // EnumerateLoadedModules(GetCurrentProcess(), ELM_Callback, 0); Maybe MS changed the parameter type in the latest platform SDK. A simple workaround. At line 47 in the same file DynamicLibrary.inc, // static BOOL CALLBACK ELM_Callback(PSTR ModuleName, ... change PSTR to PCSTR, and everything is OK. I don't know if this works for VS2005/XP. Xi From ted at tedneward.com Tue Feb 19 23:21:10 2008 From: ted at tedneward.com (Ted Neward) Date: Tue, 19 Feb 2008 21:21:10 -0800 Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? In-Reply-To: <321mr3totf4ndk2d8n2jp2tqndp9cl8iek@4ax.com> References: <20080212235200.BBP58517@expms2.cites.uiuc.edu> <680422C0AA225644931C2F6DD07200DD01897833@namail5.corp.adobe.com><001101c87201$8bd624a0$a3826de0$@com> <002001c87205$e31b28b0$a9517a10$@com> <680422C0AA225644931C2F6DD07200DD018DD3FC@namail5.corp.adobe.com> <022901c872ba$cc8f0e30$65ad2a90$@com> <321mr3totf4ndk2d8n2jp2tqndp9cl8iek@4ax.com> Message-ID: <011601c87380$6a028fa0$3e07aee0$@com> True, but MSBuild is what's invoked for a Solution, which then defers to VCBuild, as I understand it. (The rumor is that the C++/CLI team was so busy revamping the Managed C++ language for Whidby that they had no time to adapt MSBuild to building C++ apps. *shrug*) Regardless, as I mentioned in the follow-up email, the files *are* being copied, just not where I expected them to end up, which I think is a bug in the .sln/.vcproj files. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Barry Kelly > Sent: Tuesday, February 19, 2008 8:32 AM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio > 2005? > > > For whatever reason, only by manually deleting the config.h file in > the > > llvm/include/Config directory can I get the project to re-gen that > config.h > > file. I'm not sure if this is a property of running the build from > the > > command-line (but I'm guessing it's not, since MSBuild is used > internally > > inside VS), or if the file-copy is being prevented by something in my > > environment (files are marked writable, I already checked). > > The MSBuild infrastructure isn't used by VS 2005 for C++ projects; > rather, VCBuild does the work. I'm not sure about VS 2008. > > FWIW, I used ProcMon to diagnose file-handling issues I had in my > build: > > http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx > > -- Barry > > -- > http://barrkel.blogspot.com/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1285 - Release Date: > 2/18/2008 5:50 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.8/1287 - Release Date: 2/19/2008 10:55 AM From wuxi at fudan.edu.cn Tue Feb 19 23:24:55 2008 From: wuxi at fudan.edu.cn (AndrewWu) Date: Wed, 20 Feb 2008 13:24:55 +0800 Subject: [LLVMdev] llvm-2.2 cannot be successfully built with 'make ENABLE_OPTIMIZED=1' Message-ID: <000801c87380$ed89d360$c89d7a20$@edu.cn> My platform is RedHat Enterprise 5, as shown below: [wuxi at ppidellsc1420 lib]$ uname -a Linux ppidellsc1420 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 i686 i686 i386 GNU/Linux and I install gcc-4.2.3, as shown below: [wuxi at ppidellsc1420 lib]$ g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.3/configure --prefix=/home/wuxi/gcc-4.2-install/ Thread model: posix gcc version 4.2.3 I follow the command: CXX=PATH_TO_MY_G++ ../llvm/configure -prefix=/usr/local To configure llvm And next when I use 'make ENABLE_OPTIMIZED=0', it can successfully build llvm, with the warning that I may get 10 times slower. But when I use 'make ENABLE_OPTMIZED=1', the compilation fails with the message: /home/wuxi/llvm-2.2/llvm-objects-opt/Release/bin/tblgen: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /home/wuxi/llvm-2.2/llvm-objects-opt/Release/bin/tblgen) I have checked by libstdc++, with a higher version: [wuxi at ppidellsc1420 lib]$ rpm -q libstdc++ libstdc++-4.1.1-52.el5 Well. as libstdc++ is published with gcc. I am wondering which version of gcc I should use ? Any suggestion on this problem ? Thanks very much _______________________________________________ Andrew Wu Parallel Processing Institute Fudan University, Shanghai, China E-mail: wuxi at fudan.edu.cn wu.andrew.xi at gmail.com _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080220/8d5fd269/attachment-0001.html From asl at math.spbu.ru Wed Feb 20 00:09:43 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Wed, 20 Feb 2008 09:09:43 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?bGx2bS0yLjIgY2Fubm90IGJlIHN1Y2Nlc3NmdWxseSBi?= =?koi8-r?b?dWlsdCB3aXRoICdtYWtlCUVOQUJMRV9PUFRJTUlaRUQ9MSc=?= Message-ID: <200802200609.m1K69hKR077176@star.math.spbu.ru> Hello, Andrew, > I have checked by libstdc++, with a higher version: > > [wuxi at ppidellsc1420 lib]$ rpm -q libstdc++ > > libstdc++-4.1.1-52.el5 It is lower version. You should use newer version (the one, you've built during gcc 4.2.3 compilation) for the binaries built with new compiler. There are two solutions: 1. Build new gcc with --disable-shared, which will lead to huge binaries, but otherwise will work 2. Replace your system libstdc++ (which is from gcc 4.1.1) to newer version (which is from gcc 4.2.3). There are different ways, including symlinking, LD_LIBRARY_PATH stuff, etc. -- WBR, Anton Korobeynikov From evan.cheng at apple.com Wed Feb 20 01:23:07 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 19 Feb 2008 23:23:07 -0800 Subject: [LLVMdev] Problems building LLVM 2.2 for ARM In-Reply-To: <47BB720E.5010005@gmx.de> References: <47BB720E.5010005@gmx.de> Message-ID: Try make VERBOSE=1 first. Perhaps it'll tell us something. Evan On Feb 19, 2008, at 4:19 PM, Tobias Oberstein wrote: > Hello, > > I'd like to do some initial experiments with LLVM on embedded ARM > (Nokia N800), but ran into a build issue. Could s.o. give me a tip? > > Thx alot, > Tobias > > P.S.: just as sidenote, LLVM 2.2 builds cleanly on GCC 4.2.3 / Linux. > > === > > I'm building on Ubuntu/Scratchbox/ARMEL using GCC 3.4.4 (CodeSourcery > ARM 2005q3-2) using > > ./configure --prefix=$HOME/local/llvm-2.2 --enable-jit --enable- > threads > --enable-shared --enable-optimized > > I could reproduce, but overcome the problems described in dox > regarding optimized built: > > """ > GCC 3.4.4 (CodeSourcery ARM 2005q3-2): this compiler miscompiles LLVM > when building with optimizations enabled. It appears to work with > "make > ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O1" or build a debug build. > > http://www.llvm.org/docs/GettingStarted.html#brokengcc > """ > > by just going to problematic dirs > > llvm-2.2/lib/CodeGen/SelectionDAG > lib/Target/PowerPC > > and do > > make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O1 > > -- > > However, much later, the build stops with > > [sbox-CHINOOK_ARMEL: ~/build/llvm-2.2/tools/llvm-config] > make > llvm[0]: Checking for cyclic dependencies between LLVM libraries. > find-cycles.pl: Circular dependency between *.a files: > find-cycles.pl: libLLVMCodeGen.a libLLVMScalarOpts.a > libLLVMSelectionDAG.a > llvm[0]: Building llvm-config script. > cat: /home/oberstet/build/llvm-2.2/tools/llvm-config/FinalLibDeps.txt: > No such file or directory > make: *** [/home/oberstet/build/llvm-2.2/Release/bin/llvm-config] > Error 1 > [sbox-CHINOOK_ARMEL: ~/build/llvm-2.2/tools/llvm-config] > > > which leaves me pretty lost. Whats the prob? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From baldrick at free.fr Wed Feb 20 01:25:37 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 20 Feb 2008 08:25:37 +0100 Subject: [LLVMdev] llvm-2.2 cannot be successfully built with 'make ENABLE_OPTIMIZED=1' In-Reply-To: <000801c87380$ed89d360$c89d7a20$@edu.cn> References: <000801c87380$ed89d360$c89d7a20$@edu.cn> Message-ID: <200802200825.43866.baldrick@free.fr> Hi, > But when I use 'make ENABLE_OPTMIZED=1', the compilation fails with the spelling mistake: should be ENABLE_OPTIMIZED not ENABLE_OPTMIZED. > message: > > /home/wuxi/llvm-2.2/llvm-objects-opt/Release/bin/tblgen: > /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by > /home/wuxi/llvm-2.2/llvm-objects-opt/Release/bin/tblgen) The directory name shows that this is still an optimized build. As for the error itself, I have no idea. Ciao, Duncan. From wuxi at fudan.edu.cn Wed Feb 20 02:01:43 2008 From: wuxi at fudan.edu.cn (AndrewWu) Date: Wed, 20 Feb 2008 16:01:43 +0800 Subject: [LLVMdev] =?gb2312?B?tPC4tDogW0xMVk1kZXZdIGxsdm0tMi4yIGNhbm5vdCBiZSBzdWNjZQ==?= =?gb2312?B?c3NmdWxseSBidWlsdCB3aXRoICdtYWtlIEVOQUJMRV9PUFRJTUlaRUQ9MSc=?= In-Reply-To: <200802200825.43866.baldrick@free.fr> References: <000801c87380$ed89d360$c89d7a20$@edu.cn> <200802200825.43866.baldrick@free.fr> Message-ID: <001601c87396$d5191aa0$7f4b4fe0$@edu.cn> The full message is shown here, sorry for the spelling mistake, I did not make the mistake when I built the llvm: [wuxi at ppidellsc1420 llvm-objects-opt]$ make ENABLE_OPTIMIZED=1 make[1]: Entering directory `/home/wuxi/llvm-2.2/llvm-objects-opt/lib/System' ... /home/wuxi/llvm-2.2/llvm-objects-opt/Release/bin/tblgen: /usr/lib/libstdc++. so.6: version `GLIBCXX_3.4.9' not found (required by /home/wuxi/llvm-2.2/llvm-objects-opt/Release/bin/tblgen) make[1]: *** [/home/wuxi/llvm-2.2/llvm-objects-opt/lib/VMCore/Release/Intrinsics.gen.tmp] Error 1 make[1]: Leaving directory `/home/wuxi/llvm-2.2/llvm-objects-opt/lib/VMCore' make: *** [all] Error 1 > The directory name shows that this is still an optimized build. > As for the error itself, I have no idea Anyway... the debug build works well and I have written a simple program, use llvm-gcc-4.2 to generate bit code, and run the bit code directly via lli. Thanks _______________________________________________ Andrew Wu Parallel Processing Institute Fudan University, Shanghai, China E-mail: wuxi at fudan.edu.cn wu.andrew.xi at gmail.com _______________________________________________ From tobias.oberstein at gmx.de Wed Feb 20 04:03:04 2008 From: tobias.oberstein at gmx.de (Tobias Oberstein) Date: Wed, 20 Feb 2008 11:03:04 +0100 Subject: [LLVMdev] Problems building LLVM 2.2 for ARM In-Reply-To: References: <47BB720E.5010005@gmx.de> Message-ID: <47BBFAD8.10303@gmx.de> > Try make VERBOSE=1 first. Perhaps it'll tell us something. > > Evan here's the verbose err .. [sbox-CHINOOK_ARMEL: ~] > cd ~/build/llvm-2.2/tools/llvm-config [sbox-CHINOOK_ARMEL: ~/build/llvm-2.2/tools/llvm-config] > make VERBOSE=1 llvm[0]: Checking for cyclic dependencies between LLVM libraries. /scratchbox/tools/bin/perl find-cycles.pl < /home/oberstet/build/llvm-2.2/tools/llvm-config/LibDeps.txt > /home/oberstet/build/llvm-2.2/tools/llvm-config/FinalLibDeps.txt || rm -f /home/oberstet/build/llvm-2.2/tools/llvm-config/FinalLibDeps.txt find-cycles.pl: Circular dependency between *.a files: find-cycles.pl: libLLVMCodeGen.a libLLVMScalarOpts.a libLLVMSelectionDAG.a llvm[0]: Building llvm-config script. echo 's, at LLVM_CPPFLAGS@, -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS,' > temp.sed echo 's, at LLVM_CFLAGS@, -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O3 -fomit-frame-pointer ,' >> temp.sed echo 's, at LLVM_CXXFLAGS@, -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O3 -fomit-frame-pointer -Woverloaded-virtual,' >> temp.sed echo 's, at LLVM_LDFLAGS@,,' >> temp.sed echo 's, at LLVM_BUILDMODE@,Release,' >> temp.sed /scratchbox/tools/bin/sed -f temp.sed < llvm-config.in > /home/oberstet/build/llvm-2.2/Release/bin/llvm-config /scratchbox/tools/bin/rm temp.sed cat /home/oberstet/build/llvm-2.2/tools/llvm-config/FinalLibDeps.txt >> /home/oberstet/build/llvm-2.2/Release/bin/llvm-config cat: /home/oberstet/build/llvm-2.2/tools/llvm-config/FinalLibDeps.txt: No such file or directory make: *** [/home/oberstet/build/llvm-2.2/Release/bin/llvm-config] Error 1 [sbox-CHINOOK_ARMEL: ~/build/llvm-2.2/tools/llvm-config] > perl -V Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=linux, osvers=2.6.16-2-686-smp, archname=i686-linux-thread-multi uname='linux helusbox 2.6.16-2-686-smp #1 smp sun jul 16 01:23:04 utc 2006 i686 gnulinux ' config_args='-des -Dcc=/scratchbox/compilers/host-gcc/bin/gcc -specs=/scratchbox/compilers/host-gcc/host-gcc.specs -Accflags=-DAPPLLIB_EXP=\"/host_usr/perl\" -Dldflags=-Xlinker -dynamic-linker -Xlinker /scratchbox/host_shared/lib/ld.so -Xlinker -rpath -Xlinker /scratchbox/host_shared/lib/ -Xlinker -rpath -Xlinker /scratchbox/tools/lib/ -s -Dusethreads -Duselargefiles -Dprefix=/scratchbox/tools -Dvendorprefix=/scratchbox/tools -Dsiteprefix=/scratchbox/tools -Dotherlibdirs=/etc/perl:/usr/local/lib/perl/5.8.4:/usr/local/share/perl/5.8.4:/usr/lib/perl5:/usr/share/perl5:/usr/lib/perl/5.8.4:/usr/share/perl/5.8.4:/usr/local/lib/site_perl:/scratchbox/devkits/debian/lib/perl/:/scratchbox/devkits/perl/lib/perl/:/scratchbox/devkits/doctools/lib/perl/ -Dlocincpth=/host_usr/perl/include -Dloclibpth=/host_usr/perl/lib -Dman1dir=none -Dman3dir=none' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc ', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DAPPLLIB_EXP="/host_usr/perl" -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DAPPLLIB_EXP="/host_usr/perl" -fno-strict-aliasing' ccversion='', gccversion='3.3.5 (Debian 1:3.3.5-13)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc ', ldflags =' -L/usr/local/lib' libpth=/lib /usr/lib /usr/local/lib libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fpic', lddlflags='-shared' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Aug 1 2007 16:46:35 %ENV: PERL5LIB="/scratchbox/devkits/maemo3-tools/lib/perl5/site_perl/5.8.4/i686-linux-thread-multi" @INC: /scratchbox/devkits/perl/lib/perl /scratchbox/devkits/perl/lib/perl5 /scratchbox/devkits/perl/share/perl /scratchbox/devkits/perl/share/perl5 /scratchbox/devkits/debian-etch/lib/perl /scratchbox/devkits/debian-etch/lib/perl5 /scratchbox/devkits/debian-etch/share/perl /scratchbox/devkits/debian-etch/share/perl5 /scratchbox/devkits/maemo3-tools/lib/perl /scratchbox/devkits/maemo3-tools/lib/perl5 /scratchbox/devkits/maemo3-tools/share/perl /scratchbox/devkits/maemo3-tools/share/perl5 /scratchbox/devkits/cputransp/lib/perl /scratchbox/devkits/cputransp/lib/perl5 /scratchbox/devkits/cputransp/share/perl /scratchbox/devkits/cputransp/share/perl5 /scratchbox/devkits/maemo3-tools/lib/perl5/site_perl/5.8.4/i686-linux-thread-multi /host_usr/perl /scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi /scratchbox/tools/lib/perl5/5.8.4 /scratchbox/tools/lib/perl5/site_perl/5.8.4/i686-linux-thread-multi /scratchbox/tools/lib/perl5/site_perl/5.8.4 /scratchbox/tools/lib/perl5/site_perl /scratchbox/tools/lib/perl5/vendor_perl/5.8.4/i686-linux-thread-multi /scratchbox/tools/lib/perl5/vendor_perl/5.8.4 /scratchbox/tools/lib/perl5/vendor_perl /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8.4 /usr/share/perl/5.8.4 /usr/local/lib/site_perl /scratchbox/devkits/debian/lib/perl/ /scratchbox/devkits/perl/lib/perl/ /scratchbox/devkits/doctools/lib/perl/ . [sbox-CHINOOK_ARMEL: ~/build/llvm-2.2/tools/llvm-config] > From tobias.oberstein at gmx.de Wed Feb 20 04:08:03 2008 From: tobias.oberstein at gmx.de (Tobias Oberstein) Date: Wed, 20 Feb 2008 11:08:03 +0100 Subject: [LLVMdev] llvm-2.2 cannot be successfully built with 'make ENABLE_OPTIMIZED=1' In-Reply-To: <000801c87380$ed89d360$c89d7a20$@edu.cn> References: <000801c87380$ed89d360$c89d7a20$@edu.cn> Message-ID: <47BBFC03.2010305@gmx.de> > I follow the command: > > CXX=PATH_TO_MY_G++ ../llvm/configure ?prefix=/usr/local > > To configure llvm > > > > And next when I use ?make ENABLE_OPTIMIZED=0?, it can successfully build > llvm, with the warning that I may get 10 times slower? > > > > But when I use ?make ENABLE_OPTMIZED=1?, the compilation fails with the > message: > > /home/wuxi/llvm-2.2/llvm-objects-opt/Release/bin/tblgen: > /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by > /home/wuxi/llvm-2.2/llvm-objects-opt/Release/bin/tblgen) try putting your self built newer gcc & libstdc++ in the environment export PATH=/home/wuxi/gcc-4.2-install/bin:${PATH} export LD_LIBRARY_PATH=/home/wuxi/gcc-4.2-install/lib:${LD_LIBRARY_PATH} the systems /usr/lib/libstdc++.so.6 doesn't work with the newer GCC. Tobias From kevin.andre at student.ua.ac.be Wed Feb 20 05:18:59 2008 From: kevin.andre at student.ua.ac.be (=?UTF-8?Q?Kevin_Andr=C3=A9?=) Date: Wed, 20 Feb 2008 12:18:59 +0100 Subject: [LLVMdev] cross compiling with the C backend In-Reply-To: <200802192007.m1JK770f023784@star.math.spbu.ru> References: <200802192007.m1JK770f023784@star.math.spbu.ru> Message-ID: <20d882600802200318k4e153379k79d0765e11d2a354@mail.gmail.com> 2008/2/19 Anton Korobeynikov : > Hello, Kevin. > > > Well, I already use custom includes with these options: "-nostdlib > > -nostdinc -Ipsptoolchain/psp/include > > -Ipsptoolchain/lib/gcc/psp/4.1.0/include". But that seems not enough. > > GCC has some target-specific behaviour compiled in? > Well, in general - yes. However, I'm not sure up to which margin. So I don't really have any other choice than hacking llvm-gcc? From rajamukherji at gmail.com Wed Feb 20 07:53:20 2008 From: rajamukherji at gmail.com (Raja Mukherji) Date: Wed, 20 Feb 2008 13:53:20 +0000 Subject: [LLVMdev] Adding a custom calling convention Message-ID: <2a5a7c080802200553n7d7f8e83n3fde95ca10cc0595@mail.gmail.com> Hi all, I was wondering what the best way of adding a custom calling convention in llvm? In particular, for the x86 platform, I want: on entry esi = size of argument block edi = address of argument block ecx = callee object and on return eax = status code ebx = possible one-shot continuation ecx = returned value edx = returned reference I only want it to work in a JIT fashion so no persistence in bitcode files is necessary. Thanks, Raja Mukherji From vvaditya12 at yahoo.com Wed Feb 20 08:20:45 2008 From: vvaditya12 at yahoo.com (aditya vishnubhotla) Date: Wed, 20 Feb 2008 06:20:45 -0800 (PST) Subject: [LLVMdev] Invalid intrinsic name error In-Reply-To: <14262CD2-0FAB-404E-9766-17B6F8FCBC56@apple.com> Message-ID: <862293.68091.qm@web56015.mail.re3.yahoo.com> Hi, Thank You for the advice and we were able to solve that problem by the following modifications to the Instrinsics.td file. But I now have an "Invalid Intrinsic name" error This error occurs presumably because the created intrinsic is named: llvm.migrate_begin.i32 Intrinsics.gen checks for a string length of 18 (i.e. the length without the .i32). Kindly help me through it. //Additions made to Intrinsics.td file: def int_migrate_begin : Intrinsic<[llvm_i32_ty,llvm_vararg_ty], [IntrWriteMem],"llvm.migrate_begin">; //A section of the code which deals with the //"migrate_begin" intrinsic creation is as follows: const Type **Tys=(const Type**)calloc(extTys.size(),sizeof(Type*)); /*extTys vector contains function type of the function "f" */ int i=0; for(vector::iterator it=extTys.begin(),e=extTys.end();it!=e;it++) {Tys[i++]=*it;} extTys.clear(); Module *M = bbp->getParent()->getParent(); Function *f = Intrinsic::getDeclaration(M,Intrinsic::migrate_begin,Tys,i); /* migrate_begin intrinsic creation */ CallInst* CI = new CallInst(f,"migrate_begin"); //Error: NAME:llvm.migrate_begin.i32 opt: Function.cpp:293: unsigned int llvm::Function::getIntrinsicID(bool) const: Assertion `noAssert && "Invalid LLVM intrinsic name"' failed. P.S: > --- Dan Gohman wrote: > On Feb 19, 2008, at 1:11 AM, aditya vishnubhotla > > wrote: > > Hi, > > I tried creating variable argument intrinsics > > which > > > are to be placeholders for some instructions which > > should not be executed by the backend. > > > > Kindly help me with the errors in my > > "migrate_begin" > > > intrinsic creation > > > > //Additions made to Intrinsics.td file: > > > > def llvm_migrate_begin : LLVMType; > > def int_migrate_begin : > > Intrinsic<[llvm_migrate_begin,llvm_vararg_ty], > > [IntrWriteMem],"llvm.migrate_begin">; > > This says that the return type is overloaded > (because it's iAny). But > that's > the only overloaded part here; using variadic > > argument lists is > different > from overloading. > > > Overloaded intrinsic has incorrect suffix: > > '.i32.i32'. > > > It should be '.i32' > > i32 (...)* @llvm.migrate_begin.i32.i32 > > > > Overloaded intrinsic has incorrect suffix: > > '.i32.i32.i32'. It should be '.i32' > > i32 (...)* @llvm.migrate_begin.i32.i32.i32 > > The suffix has a part for each overloaded type in > the function type. > Since only > the return type is overloaded, the verifier is > expecting only one type > to be passed > into getDeclaration. > > Dan ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From sabre at nondot.org Wed Feb 20 12:20:44 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 20 Feb 2008 10:20:44 -0800 (PST) Subject: [LLVMdev] Adding a custom calling convention In-Reply-To: <2a5a7c080802200553n7d7f8e83n3fde95ca10cc0595@mail.gmail.com> References: <2a5a7c080802200553n7d7f8e83n3fde95ca10cc0595@mail.gmail.com> Message-ID: On Wed, 20 Feb 2008, Raja Mukherji wrote: > Hi all, > I was wondering what the best way of adding a custom calling convention in llvm? It is quite easy to add custom calling conventions. Check out how the various x86 fastcall, stdcall, etc things are handled. > In particular, for the x86 platform, I want: > > on entry > > esi = size of argument block > edi = address of argument block > ecx = callee object This is easy, just map the first three arguments to these registers, and pass these values in as the first three registers. > and on return > > eax = status code > ebx = possible one-shot continuation > ecx = returned value > edx = returned reference This is harder, because LLVM can currently only return one value. Luckily, Devang is currently implementing support for multiple return values, so this should just be a matter of having the function return these four values and having the code generator map them as you want. I'd expect this support to be complete in 2-3 months, hopefully for llvm 2.3. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From gohman at apple.com Wed Feb 20 13:12:15 2008 From: gohman at apple.com (Dan Gohman) Date: Wed, 20 Feb 2008 11:12:15 -0800 Subject: [LLVMdev] Invalid intrinsic name error In-Reply-To: <862293.68091.qm@web56015.mail.re3.yahoo.com> References: <862293.68091.qm@web56015.mail.re3.yahoo.com> Message-ID: <6396BD46-6028-4A35-84E3-CED0A6B30795@apple.com> On Feb 20, 2008, at 6:20 AM, aditya vishnubhotla wrote: > > def int_migrate_begin : > Intrinsic<[llvm_i32_ty,llvm_vararg_ty], > [IntrWriteMem],"llvm.migrate_begin">; This is now an intrinsic with no overloaded types. It will have an empty-string suffix. > > > Intrinsic::getDeclaration(M,Intrinsic::migrate_begin,Tys,i); > /* migrate_begin intrinsic creation */ > CallInst* CI = new CallInst(f,"migrate_begin"); > > //Error: > > NAME:llvm.migrate_begin.i32 > opt: Function.cpp:293: unsigned int > llvm::Function::getIntrinsicID(bool) > const: Assertion `noAssert && "Invalid LLVM intrinsic > name"' failed. Without overloading, there should be no types passed to Intrinsic::getDeclaration. Dan From rajamukherji at gmail.com Wed Feb 20 13:25:29 2008 From: rajamukherji at gmail.com (Raja Mukherji) Date: Wed, 20 Feb 2008 19:25:29 +0000 Subject: [LLVMdev] Adding a custom calling convention In-Reply-To: References: <2a5a7c080802200553n7d7f8e83n3fde95ca10cc0595@mail.gmail.com> Message-ID: <2a5a7c080802201125r6c19ebbdy5ebb63ca87b453a6@mail.gmail.com> On 20/02/2008, Chris Lattner wrote: > On Wed, 20 Feb 2008, Raja Mukherji wrote: > > Hi all, > > I was wondering what the best way of adding a custom calling convention in llvm? > > It is quite easy to add custom calling conventions. Check out how the > various x86 fastcall, stdcall, etc things are handled. Am I correct in thinking that it's the X86CallingConv.td file that needs to changed? I've had a look at it and I think I can figure out how to write the calling convention, but I'm a bit lost trying to integrate it into the rest of the code. In particular, how do I assign an integer for use in the setCallingConv(unsigned CC) method? > > > In particular, for the x86 platform, I want: > > > > on entry > > > > esi = size of argument block > > edi = address of argument block > > ecx = callee object > > This is easy, just map the first three arguments to these registers, and > pass these values in as the first three registers. > > > and on return > > > > eax = status code > > ebx = possible one-shot continuation > > ecx = returned value > > edx = returned reference > > This is harder, because LLVM can currently only return one value. > Luckily, Devang is currently implementing support for multiple return > values, so this should just be a matter of having the function return > these four values and having the code generator map them as you want. I'd > expect this support to be complete in 2-3 months, hopefully for llvm 2.3. > I need the multiple return values so I guess I'll wait until 2.3 before converting to llvm but I'll still try to get the calling convention to work in the mean time. > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > Thanks for the help. From zrakamar at gmail.com Wed Feb 20 14:00:05 2008 From: zrakamar at gmail.com (Zvonimir Rakamaric) Date: Wed, 20 Feb 2008 12:00:05 -0800 Subject: [LLVMdev] finding modified memory locations for each function Message-ID: Hi, I am looking for an analysis which would return a set of memory locations modified by each loop-free function that are visible to its callers (i.e. its frame condition). I've been looking through the list of the implemented llvm analysis and couldn't find anything similar. Please let me know what would be a good place to start or a code/module to look at if I want to implement an analysis like that.... Thanks! -- Zvonimir From dag at cray.com Wed Feb 20 14:14:05 2008 From: dag at cray.com (David Greene) Date: Wed, 20 Feb 2008 14:14:05 -0600 Subject: [LLVMdev] Bug? Coalescing & Updating Subreg Intervals Message-ID: <200802201414.05332.dag@cray.com> I have a question about what is going on at line 754 of SimpleRegisterCoalescing.cpp. The comment says we are updating the live intervals for subregisters. This happens when we coalesce to a physical register. Now, I read that as, "merge in the range information from the eliminated live interval to the subregister live interval," but that appears to not be what happens. In my case, I have the following two intervals which are being coalesced: %reg1026,0 = [458,5168:0 [0])[5180,15248:0 [0]) 0 at 458 %reg15,inf = [0,10:0 [0])[10,458:87 [0])[938,942:1 [0])[942,943:2 [0]) [962,966:3 [0])[966,967:4 [0])[1242,1246:5 [0])[1246,1247:6 [0])[1266,1270:7 [0])[1270,1271:8 [0])[1578,1582:9 [0])[1582,1583:10 [0])[1602,1606:11 [0]) [1606,1607:12 [0])[2314,2318:13 [0])[2318,2319:14 [0])[2338,2342:15 [0]) [2342,2343:16 [0])[3366,3370:17 [0])[3370,3371:18 [0])[3390,3394:19 [0]) [3394,3395:20 [0])[3642,3646:21 [0])[3646,3647:22 [0])[3666,3670:23 [0]) [3670,3671:24 [0])[3942,3946:25 [0])[3946,3947:26 [0])[3966,3970:27 [0]) [3970,3971:28 [0])[6098,6102:29 [0])[6102,6103:30 [0])[6126,6130:31 [0]) [6130,6131:32 [0])[6390,6394:33 [0])[6394,6395:34 [0])[6418,6422:35 [0]) [6422,6423:36 [0])[6714,6718:37 [0])[6718,6719:38 [0])[6742,6746:39 [0]) [6746,6747:40 [0])[7434,7438:41 [0])[7438,7439:42 [0])[7462,7466:43 [0]) [7466,7467:44 [0])[8446,8450:45 [0])[8450,8451:46 [0])[8474,8478:47 [0]) [8478,8479:48 [0])[8710,8714:49 [0])[8714,8715:50 [0])[8738,8742:51 [0]) [8742,8743:52 [0])[8998,9002:53 [0])[9002,9003:54 [0])[9022,9026:55 [0]) [9026,9027:56 [0])[10490,10494:57 [0])[10494,10495:58 [0])[10518,10522:59 [0])[10522,10523:60 [0])[10782,10786:61 [0])[10786,10787:62 [0]) [10810,10814:63 [0])[10814,10815:64 [0])[11106,11110:65 [0])[11110,11111:66 [0])[11134,11138:67 [0])[11138,11139:68 [0])[11826,11830:69 [0]) [11830,11831:70 [0])[11854,11858:71 [0])[11858,11859:72 [0])[12838,12842:73 [0])[12842,12843:74 [0])[12866,12870:75 [0])[12870,12871:76 [0]) [13102,13106:77 [0])[13106,13107:78 [0])[13130,13134:79 [0])[13134,13135:80 [0])[13390,13394:81 [0])[13394,13395:82 [0])[13414,13418:83 [0]) [13418,13419:84 [0])[15350,15374:88 [0])[15374,15382:85 [0])[15382,15383:86 [0]) 0 at 0-(10) 1 at 938-(942) 2 at 942-(943) 3 at 962-(966) 4 at 966-(967) 5 at 1242-(1246) 6 at 1246-(1247) 7 at 1266-(1270) 8 at 1270-(1271) 9 at 1578-(1582) 10 at 1582-(1583) 11 at 1602-(1606) 12 at 1606-(1607) 13 at 2314-(2318) 14 at 2318-(2319) 15 at 2338-(2342) 16 at 2342-(2343) 17 at 3366-(3370) 18 at 3370-(3371) 19 at 3390-(3394) 20 at 3394-(3395) 21 at 3642-(3646) 22 at 3646-(3647) 23 at 3666-(3670) 24 at 3670-(3671) 25 at 3942-(3946) 26 at 3946-(3947) 27 at 3966-(3970) 28 at 3970-(3971) 29 at 6098-(6102) 30 at 6102-(6103) 31 at 6126-(6130) 32 at 6130-(6131) 33 at 6390-(6394) 34 at 6394-(6395) 35 at 6418-(6422) 36 at 6422-(6423) 37 at 6714-(6718) 38 at 6718-(6719) 39 at 6742-(6746) 40 at 6746-(6747) 41 at 7434-(7438) 42 at 7438-(7439) 43 at 7462-(7466) 44 at 7466-(7467) 45 at 8446-(8450) 46 at 8450-(8451) 47 at 8474-(8478) 48 at 8478-(8479) 49 at 8710-(8714) 50 at 8714-(8715) 51 at 8738-(8742) 52 at 8742-(8743) 53 at 8998-(9002) 54 at 9002-(9003) 55 at 9022-(9026) 56 at 9026-(9027) 57 at 10490-(10494) 58 at 10494-(10495) 59 at 10518-(10522) 60 at 10522-(10523) 61 at 10782-(10786) 62 at 10786-(10787) 63 at 10810-(10814) 64 at 10814-(10815) 65 at 11106-(11110) 66 at 11110-(11111) 67 at 11134-(11138) 68 at 11138-(11139) 69 at 11826-(11830) 70 at 11830-(11831) 71 at 11854-(11858) 72 at 11858-(11859) 73 at 12838-(12842) 74 at 12842-(12843) 75 at 12866-(12870) 76 at 12870-(12871) 77 at 13102-(13106) 78 at 13106-(13107) 79 at 13130-(13134) 80 at 13134-(13135) 81 at 13390-(13394) 82 at 13394-(13395) 83 at 13414-(13418) 84 at 13418-(13419) 85 at 15374-(15382) 86 at 15382-(15383) 87@? 88@? MergeInClobberRanges comes along and sees that [458,5168:0 [0]) from %reg1026 overlaps [938,942:1 [0]) from %reg15. It then proceeds to add [458,938:89 [0]) to %reg15. It then moves on to the next LiveRange of %reg1026. Huh? What happened to the rest of [458,5168:0 [0])? Doesn't the subreg live interval need to contain this whole LiveRange? Or am I not understanding what this part of the coalescing code does? I discovered this through an assert I put into some of my own code. I want to know if that assert is bogus or if there's a bug here. Thanks! -Dave From dag at cray.com Wed Feb 20 14:25:19 2008 From: dag at cray.com (David Greene) Date: Wed, 20 Feb 2008 14:25:19 -0600 Subject: [LLVMdev] Bug? Coalescing & Updating Subreg Intervals In-Reply-To: <200802201414.05332.dag@cray.com> References: <200802201414.05332.dag@cray.com> Message-ID: <200802201425.20158.dag@cray.com> On Wednesday 20 February 2008 14:14, David Greene wrote: > I discovered this through an assert I put into some of my own code. I want > to know if that assert is bogus or if there's a bug here. A little more information: the assert checks that after coalescing two nodes, all subregister live intervals for the register coaelsced to now interfere with whatever the eliminated live interval interfered with, since the superregister live interval now contains information from the eliminated live interval and thus it interferes with whatever the eliminated live interval interfered with (and thuis so should the subregister live interval, correct?). In my case, this test _fails_, which I found to be unexpected. In other words, after coalescing, should it be the case that subregister intervals contain at least all of the range information that was contained in any eliminated intervals when those eliminated intervals were coalesced to the subregister's superregister? If not, which is this code supposed to be doing? -Dave From dag at cray.com Wed Feb 20 15:44:51 2008 From: dag at cray.com (David Greene) Date: Wed, 20 Feb 2008 15:44:51 -0600 Subject: [LLVMdev] Bug? Coalescing & Updating Subreg Intervals In-Reply-To: <200802201414.05332.dag@cray.com> References: <200802201414.05332.dag@cray.com> Message-ID: <200802201544.51924.dag@cray.com> On Wednesday 20 February 2008 14:14, David Greene wrote: > In my case, I have the following two intervals which are being > coalesced: > > %reg1026,0 = [458,5168:0 [0])[5180,15248:0 [0]) 0 at 458 > > %reg15,inf = [0,10:0 [0])[10,458:87 [0])[938,942:1 [0])[942,943:2 [0]) Oops, I was inaccruate. We're actually coalescing to %reg80. %reg15 is a subreg of %reg80. -Dave From evan.cheng at apple.com Wed Feb 20 19:00:28 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 20 Feb 2008 17:00:28 -0800 Subject: [LLVMdev] Bug? Coalescing & Updating Subreg Intervals In-Reply-To: <200802201425.20158.dag@cray.com> References: <200802201414.05332.dag@cray.com> <200802201425.20158.dag@cray.com> Message-ID: On Feb 20, 2008, at 12:25 PM, David Greene wrote: > On Wednesday 20 February 2008 14:14, David Greene wrote: > >> I discovered this through an assert I put into some of my own >> code. I want >> to know if that assert is bogus or if there's a bug here. > > A little more information: the assert checks that after coalescing > two nodes, > all subregister live intervals for the register coaelsced to now > interfere > with whatever the eliminated live interval interfered with, since the > superregister live interval now contains information from the > eliminated live > interval and thus it interferes with whatever the eliminated live > interval > interfered with (and thuis so should the subregister live interval, > correct?). > In my case, this test _fails_, which I found to be unexpected. > > In other words, after coalescing, should it be the case that > subregister > intervals contain at least all of the range information that was > contained > in any eliminated intervals when those eliminated intervals were > coalesced > to the subregister's superregister? Right. The code is being conservative. It's saying all of the entirety of the superregister's live inter