From fernando at CS.UCLA.EDU Sat Mar 1 00:52:10 2008 From: fernando at CS.UCLA.EDU (Fernando Magno Quintao Pereira) Date: Fri, 29 Feb 2008 22:52:10 -0800 (PST) Subject: [LLVMdev] Instruction Scheduling Message-ID: Hi, guys, I am comparing the performance of the default scheduler (seems to be the one that minimizes register pressure) with no scheduler (-pre-RA-sched=none), and I got these numbers. The ratio is low_reg_pressure/none, that is, the lower the number, the better the performance with low register pressure: CFP2000/177.mesa/177.mesa 1.00 CFP2000/179.art/179.art 0.98 CFP2000/183.equake/183.equake 1.00 CFP2000/188.ammp/188.ammp 0.98 CINT2000/164.gzip/164.gzip 0.97 CINT2000/175.vpr/175.vpr 0.97 CINT2000/176.gcc/176.gcc n/a // crashed! CINT2000/181.mcf/181.mcf 1.02 CINT2000/186.crafty/186.crafty 1.00 CINT2000/197.parser/197.parser 1.01 CINT2000/252.eon/252.eon n/a // never runs CINT2000/253.perlbmk/253.perlbmk 1.05 CINT2000/254.gap/254.gap 0.97 CINT2000/255.vortex/255.vortex 1.00 CINT2000/256.bzip2/256.bzip2 0.98 CINT2000/300.twolf/300.twolf 0.92 In three cases, I got a ratio above 1 [Must mean: scheduling had a negative impact on performance.] I just run it once, but I was wondering if this could make sense, or if I am setting the tests wrongly. I am running the nightly test Makefile, in a x86 linux 32 bits machine. best, Fernando From sabre at nondot.org Sat Mar 1 03:09:29 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 1 Mar 2008 01:09:29 -0800 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> Message-ID: <759DBC7E-00A8-4B73-BE6A-73D082A25E2E@nondot.org> On Feb 28, 2008, at 10:43 AM, Richard Warburton wrote: > This email is written on the premise that LLVM will be involved in > GSOC again this year. I hope so too! > I would be looking to implement a context-sensitive alias analysis. > Whilst I accept that this isn't the most efficient category of alias > analysis, I think the implementation of such an analysis, that trades > off computational efficiency for a more precise computation of > aliasing would be a beneficial addition to the LLVM project. In terms > of which algorithm to actually implement, I am considering > implementing a BDD based algorithm, possible candidate include: Ok. I think the most important thing to keep in mind, if you want this to be useful for LLVM, is for it to be sound in the presence of incomplete programs. I think it would be very interesting to have a BDD based analysis in LLVM, it would be useful for performance comparisons and many other things, even if it isn't turned on by default. However, it must be sound. Also, LLVM benefits quite a bit from mod/ref info for function. I don't know if you've thought about it at all, but it is an important problem. If you're interested, my thesis describes these issues in detail. > 1. Is this too ambitious for a google summer of code project? It depends on your familiarity with the domain. If you haven't worked in the area of alias analysis (and applications) it probably is. There are lot of smaller subprojects that would be useful for llvm though. > 2. Would implementing any of these algorithms be tricky due to some > peculiarity of LLVM? No, I don't think so. LLVM has hosted a lot of AA work already. > 3. Do existing optimisations and DFAs that depend on aliasing > information interface with the alias analysis in a context sensitive > manner, or do they require rewriting? They can benefit from context sensitive mod/ref info. > 4. Is anyone willing to mentor this project? I don't know :) Maybe someone from Vikram's research group would be willing to mentor you. If you are interested in pursuing this, I'd suggest making a proposal and we can figure out mentorship when the time is closer, -Chris From sabre at nondot.org Sat Mar 1 03:14:43 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 1 Mar 2008 01:14:43 -0800 Subject: [LLVMdev] JITted code in multiple threads In-Reply-To: References: Message-ID: <46F9622E-5FE8-469A-B336-312598E23D83@nondot.org> On Feb 27, 2008, at 1:10 AM, Aaron Dwyer wrote: > I just thought of something that scared me, and I'm hoping there is a > happy ending. I realized recently that the JITter does not > necessarily finish JITting inside of getPointerToFunction. Instead, > it often generates stubs which get a final JIT only upon jumping to > them. Now--I am in the situation where I'd like to do a > getPointerToFunction, and then take the pointer and pass it out to > multiple cores to execute the code I've generated in parallel. This > seems like a problem--if jumping to an address means code will be > munged, then two or more cores trying to jump to that address at the > same time might all try to JIT the stubs, resulting in a barrage of > random code!! > > This seems like a very obvious issue, so I'm guessing there is a > simple answer for this. What are peoples' thoughts? Any and all are > appreciated. The JIT is thread safe: it uses a pthread mutex to prevent multiple threads from clobbering each other, even if lazy compilation is happening. -Chris From jo at durchholz.org Sat Mar 1 03:29:06 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 01 Mar 2008 10:29:06 +0100 Subject: [LLVMdev] llvm/test: suffix or operands invalid for `push' In-Reply-To: <8F94E839-134F-4DD2-AB8C-3F77580EB8EB@apple.com> References: <1204103370.6718.83.camel@kurier> <1204150347.7608.14.camel@kurier> <364EF13F-5437-4990-9C0B-7A86CF0C17F7@apple.com> <1204192520.7319.51.camel@kurier> <00C3AA84-B1B7-462A-AD73-A96BBDEECE12@apple.com> <82FE5EB6-175D-4841-8E4D-4E41D5DEE993@apple.com> <1204328029.7291.37.camel@kurier> <8EC077B6-99D0-43D3-A851-F986DB09B778@apple.com> <1204329930.7291.56.camel@kurier> <8F94E839-134F-4DD2-AB8C-3F77580EB8EB@apple.com> Message-ID: <1204363746.6821.34.camel@kurier> Am Freitag, den 29.02.2008, 18:15 -0800 schrieb Eric Christopher: > Is this configuring llvm or llvm-gcc? This is inside the llvm-2.2 directory. > Seems to work just fine for > configure; make; make check with llvm. Trying "make check" from the llvm directory instead of "make" from llvm/test... doesn't work. Retrying from scratch, here's the transcript: # I had set up $PATH like this: $ which llvm-gcc llvm-g++ /home/jo/bin/llvm-gcc /home/jo/bin/llvm-g++ # ... and $HOME/bin like this: $ ll $HOME/bin llvm-g++ -> /home/jo/Delta/llvm-gcc4.2-2.2-x86-linux-RHEL4/bin/llvm-g++ llvm-gcc -> /home/jo/Delta/llvm-gcc4.2-2.2-x86-linux-RHEL4/bin/llvm-gcc # Reset to initial state: $ rm -rf llvm-2.2 llvm-gcc4.2-2.2-x86-linux-RHEL4 $ tar xzf llvm-2.2.tar.gz $ tar xzf llvm-gcc4.2-2.2-x86-linux-RHEL4.tar.gz # Configure & install $ cd llvm-2.2 # I'm trying the --build option, too. $ ./configure --prefix=$HOME CC=gcc-4.2 CXX=g++-4.2 \ --build=x86_64-pc-linux-gnu \ --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu $ make $ make check # Host is still wrong. # Not sure whether the warnings are a problem. # The used description files might be for x86_64 though. ... Target is i686-pc-linux-gnu Host is x86_64-unknown-linux-gnu ... Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. WARNING: Couldn't find tool config file for unix, using default. WARNING: Assuming target board is the local machine (which is probably wrong). You may need to set your DEJAGNU environment variable. ...FAIL: /home/jo/Delta/llvm-2.2/test/C ++Frontend/2006-11-30-NoCompileUnit.cpp Failed with exit(1) at line 2 while running: as NoCompileUnit.s -o NoCompileUnit.o NoCompileUnit.s: Assembler messages: NoCompileUnit.s:33: Error: suffix or operands invalid for `push' NoCompileUnit.s:52: Error: suffix or operands invalid for `pop' NoCompileUnit.s:64: Error: suffix or operands invalid for `push' NoCompileUnit.s:83: Error: suffix or operands invalid for `pop' NoCompileUnit.s:95: Error: suffix or operands invalid for `push' NoCompileUnit.s:116: Error: suffix or operands invalid for `pop' NoCompileUnit.s:128: Error: suffix or operands invalid for `push' NoCompileUnit.s:225: Error: suffix or operands invalid for `pop' NoCompileUnit.s:237: Error: suffix or operands invalid for `push' NoCompileUnit.s:243: Error: suffix or operands invalid for `push' NoCompileUnit.s:268: Error: suffix or operands invalid for `pop' NoCompileUnit.s:269: Error: suffix or operands invalid for `pop' ... I'm not sure what to make of that "tool config file" warning. Regards, Jo From richard.warburton at gmail.com Sat Mar 1 05:40:53 2008 From: richard.warburton at gmail.com (Richard Warburton) Date: Sat, 1 Mar 2008 11:40:53 +0000 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: <759DBC7E-00A8-4B73-BE6A-73D082A25E2E@nondot.org> References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> <759DBC7E-00A8-4B73-BE6A-73D082A25E2E@nondot.org> Message-ID: <749b5dd60803010340p5c685335v2265deb1cf9b7f44@mail.gmail.com> > Ok. I think the most important thing to keep in mind, if you want > this to be useful for LLVM, is for it to be sound in the presence of > incomplete programs. I think it would be very interesting to have a > BDD based analysis in LLVM, it would be useful for performance > comparisons and many other things, even if it isn't turned on by > default. However, it must be sound. Both of my suggested algorithms have been implemented in Java - which, by virtue of reflection, means one cannot statically determine which class certain object are referring to. In this instance I believe they simply assume the most conservative case (ie mayuse/maydef at that point could be anything). I suspect that this approach could be equally applied to an unknown library. > Also, LLVM benefits quite a bit from mod/ref info for function. I > don't know if you've thought about it at all, but it is an important > problem. If you're interested, my thesis describes these issues in > detail. I'll peruse this, are there any other relevant, LLVM specific texts that are appropriate for this, and not linked from the documentation page[0] ? > > 1. Is this too ambitious for a google summer of code project? > > It depends on your familiarity with the domain. If you haven't worked > in the area of alias analysis (and applications) it probably is. > There are lot of smaller subprojects that would be useful for llvm > though. In order that I may be to gauge what options there are, can you suggest some examples of these subprojects. regards, Richard Warburton [0] http://llvm.cs.uiuc.edu/docs/ From sabre at nondot.org Sat Mar 1 12:57:54 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 1 Mar 2008 10:57:54 -0800 Subject: [LLVMdev] llvm/test: suffix or operands invalid for `push' In-Reply-To: <1204363746.6821.34.camel@kurier> References: <1204103370.6718.83.camel@kurier> <1204150347.7608.14.camel@kurier> <364EF13F-5437-4990-9C0B-7A86CF0C17F7@apple.com> <1204192520.7319.51.camel@kurier> <00C3AA84-B1B7-462A-AD73-A96BBDEECE12@apple.com> <82FE5EB6-175D-4841-8E4D-4E41D5DEE993@apple.com> <1204328029.7291.37.camel@kurier> <8EC077B6-99D0-43D3-A851-F986DB09B778@apple.com> <1204329930.7291.56.camel@kurier> <8F94E839-134F-4DD2-AB8C-3F77580EB8EB@apple.com> <1204363746.6821.34.camel@kurier> Message-ID: > # Configure & install > $ cd llvm-2.2 > # I'm trying the --build option, too. > $ ./configure --prefix=$HOME CC=gcc-4.2 CXX=g++-4.2 \ > --build=x86_64-pc-linux-gnu \ > --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu This is probably the problem. It sounds like you have llvm-gcc building for x86-64 (so the compiler defaults to emitting x86-64 code) but your assembler defaults to x86-32. Thus, your assembler requires - m64 to be passed for it to grok 64-bit code, which isn't being passed by the test. Does it work if you change the top of that test to: ... // RUN: as -m64 NoCompileUnit.s -o NoCompileUnit.o .. ? -Chris > > $ make > $ make check > # Host is still wrong. > # Not sure whether the warnings are a problem. > # The used description files might be for x86_64 though. > ... > Target is i686-pc-linux-gnu > Host is x86_64-unknown-linux-gnu > ... > Using /usr/share/dejagnu/baseboards/unix.exp as board description file > for target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for > target. > WARNING: Couldn't find tool config file for unix, using default. > WARNING: Assuming target board is the local machine (which is probably > wrong). > You may need to set your DEJAGNU environment variable. > ...FAIL: /home/jo/Delta/llvm-2.2/test/C > ++Frontend/2006-11-30-NoCompileUnit.cpp > Failed with exit(1) at line 2 > while running: as NoCompileUnit.s -o NoCompileUnit.o > NoCompileUnit.s: Assembler messages: > NoCompileUnit.s:33: Error: suffix or operands invalid for `push' > NoCompileUnit.s:52: Error: suffix or operands invalid for `pop' > NoCompileUnit.s:64: Error: suffix or operands invalid for `push' > NoCompileUnit.s:83: Error: suffix or operands invalid for `pop' > NoCompileUnit.s:95: Error: suffix or operands invalid for `push' > NoCompileUnit.s:116: Error: suffix or operands invalid for `pop' > NoCompileUnit.s:128: Error: suffix or operands invalid for `push' > NoCompileUnit.s:225: Error: suffix or operands invalid for `pop' > NoCompileUnit.s:237: Error: suffix or operands invalid for `push' > NoCompileUnit.s:243: Error: suffix or operands invalid for `push' > NoCompileUnit.s:268: Error: suffix or operands invalid for `pop' > NoCompileUnit.s:269: Error: suffix or operands invalid for `pop' > ... > > I'm not sure what to make of that "tool config file" warning. > > Regards, > Jo > > > _______________________________________________ > 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 Mar 1 13:24:09 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 1 Mar 2008 11:24:09 -0800 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: <749b5dd60803010340p5c685335v2265deb1cf9b7f44@mail.gmail.com> References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> <759DBC7E-00A8-4B73-BE6A-73D082A25E2E@nondot.org> <749b5dd60803010340p5c685335v2265deb1cf9b7f44@mail.gmail.com> Message-ID: On Mar 1, 2008, at 3:40 AM, Richard Warburton wrote: >> Also, LLVM benefits quite a bit from mod/ref info for function. I >> don't know if you've thought about it at all, but it is an important >> problem. If you're interested, my thesis describes these issues in >> detail. > > I'll peruse this, are there any other relevant, LLVM specific texts > that are appropriate for this, and not linked from the documentation > page[0] ? Not that I know of. >>> 1. Is this too ambitious for a google summer of code project? >> >> It depends on your familiarity with the domain. If you haven't >> worked >> in the area of alias analysis (and applications) it probably is. >> There are lot of smaller subprojects that would be useful for llvm >> though. > > In order that I may be to gauge what options there are, can you > suggest some examples of these subprojects. There are lots of mini projects, revolving around use of better alias analysis: 1. The alias analysis API supports the getModRefBehavior method, which allows the implementation to give details analysis of the functions. For example, we could implement full knowledge of printf/scanf side effects, which would be useful (PR1604). 2. We need some way to reason about errno. Consider a loop like this: for () x += sqrt(loopinvariant); We'd like to transform this into: t = sqrt(loopinvariant); for () x += t; This transformation is safe, because the value of errno isn't otherwise changed in the loop and the exit value of errno from the loop is the same. We currently can't do this, because sqrt clobbers errno, so it isn't "readonly" or "readnone" and we don't have a good way to model this. The hard part of this project is figuring out how to describe errno in the optimizer: each libc #defines errno to something different it seems. Maybe the solution is to have a __builtin_errno_addr() or something and change sys headers to use it. 3. An easy project is to add the 'nocapture' attribute to the LLVM IR (PR2055) and have passes infer and propagate it around. Its presence can significantly improve local alias analysis at very low cost. 4. The globals mod/ref pass basically does really simple and cheap bottom-up context sensitive alias analysis. It being simple and cheap are really important, but there are simple things that we could do to better capture the effects of functions that access pointer arguments. This can be really important for C++ methods, which spend lots of time accessing pointers off 'this'. 5. There are lots of ways to optimize out and improve handling of memcpy/memset (PR452) 6. It would be excellent to replace loops with scalar stores in them into memset/memcpy calls. This dramatically speeds up programs like 'viterbi' in the testsuite. 7. There may still be some ideas in PR1373 left. -Chris From sabre at nondot.org Sat Mar 1 14:18:40 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 1 Mar 2008 12:18:40 -0800 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> <759DBC7E-00A8-4B73-BE6A-73D082A25E2E@nondot.org> <749b5dd60803010340p5c685335v2265deb1cf9b7f44@mail.gmail.com> Message-ID: <2491A06A-486A-4D6E-BA2E-2CA656998308@nondot.org> I just updated the Open Projects page with several new things, including those in the email I just sent out. -Chris From daniel at ruoso.com Sat Mar 1 15:32:22 2008 From: daniel at ruoso.com (Daniel Ruoso) Date: Sat, 01 Mar 2008 21:32:22 +0000 Subject: [LLVMdev] Idea of a tool to help in library versioning In-Reply-To: References: <1204294217.25355.52.camel@pitombeira> Message-ID: <1204407142.4816.0.camel@pitombeira> Sex, 2008-02-29 ?s 13:48 -0800, Mike Stump escreveu: > On Feb 29, 2008, at 6:10 AM, Daniel Ruoso wrote: > > Then I got the idea of generating an API description file from the > > public header files of the library > Sounds neat. In the past I've done this with objdump for the public > symbols in a library. In theory you don't care about types no > findable by the api. A nice tool would allow one to stamp the > interface as release time, and then put that into the source so that > one can get build errors when follow on work don't exactly match it. > At flag days, one can then bump the major number and delete the > interface file and essentially start over. That's even more cool :)... Is there some code of what you've done with objdump? daniel From jo at durchholz.org Sat Mar 1 18:27:30 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 02 Mar 2008 01:27:30 +0100 Subject: [LLVMdev] llvm/test: suffix or operands invalid for `push' In-Reply-To: References: <1204103370.6718.83.camel@kurier> <1204150347.7608.14.camel@kurier> <364EF13F-5437-4990-9C0B-7A86CF0C17F7@apple.com> <1204192520.7319.51.camel@kurier> <00C3AA84-B1B7-462A-AD73-A96BBDEECE12@apple.com> <82FE5EB6-175D-4841-8E4D-4E41D5DEE993@apple.com> <1204328029.7291.37.camel@kurier> <8EC077B6-99D0-43D3-A851-F986DB09B778@apple.com> <1204329930.7291.56.camel@kurier> <8F94E839-134F-4DD2-AB8C-3F77580EB8EB@apple.com> <1204363746.6821.34.camel@kurier> Message-ID: <1204417650.7348.41.camel@kurier> Am Samstag, den 01.03.2008, 10:57 -0800 schrieb Chris Lattner: > > # Configure & install > > $ cd llvm-2.2 > > # I'm trying the --build option, too. > > $ ./configure --prefix=$HOME CC=gcc-4.2 CXX=g++-4.2 \ > > --build=x86_64-pc-linux-gnu \ > > --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu > > This is probably the problem. It sounds like you have llvm-gcc > building for x86-64 (so the compiler defaults to emitting x86-64 code) Hmm... did I misunderstand ./configure --help? It says --build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] --target=TARGET configure for building compilers for TARGET [HOST] which I interpreted to mean: --build - the arch the build process will run on (usually the same as the current machine, though in some cases people might want to run ./configure on one machine and then distribute it to other machines) --host - the arch the compilers will be run on --target - the arch the programs compiled by the compilers will run on In my case, since I'm using an amd64 machine that can run both 32-bit and 64-bit code, this would mean that any combination of x86_64 and i686 for --build, --host, and --target should work. Since llvm cannot generate code for amd64 at this time, this translates to an additional constraint on --target, restricting me to --target=i686 only. If I wish to compile llvm-gcc, and compile llvm itself using llvm-gcc, I'd have to set both --host and --target as i686. Well, at least that's how I interpret these options. If that interpretation is correct, then I suspect there's a bug in the way the configure script processes these options. > but your assembler defaults to x86-32. Thus, your assembler requires - > m64 to be passed for it to grok 64-bit code, which isn't being passed > by the test. Actually it's the other way round: the assembler needs a --32 option. I had set CCFLAGS and CXXFLAGS to -Wa,--32 (the Wa meaning "pass the following options to as", and the --32 tells as it's being fed 32-bit assembly instructions), and with that, the assembly instructions would pass without an error. After that, the linker would complain because it tried to link the default 64-bit libraries with the 32-bit object files generated by the assembler. That's the point at which I started to think that -Wa,--32 is probably a fix that's a bit too low-level; besides, sorting out 32-bit and 64-bit libraries sounded like Very Much Not Fun, and hoped I could avoid the issue by placing the toolchain in 32-bit mode. > Does it work if you change the top of that test to: > ... > // RUN: as -m64 NoCompileUnit.s -o NoCompileUnit.o > .. > ? Lemme see (and checking my own hypotheses, of course...) ... gives me as: unrecognized option `-m64' This is actually gas, the GNU assembler. It expects a --64 or a --32 option (or --arch=, but I'll stick with --64 for now) BTW I see that the RUN lines are using g++. Shouldn't they use $(CXX) so that the same toolchain is used for building and testing llvm? After all, I did ./configure CXX=gcc-4.2 specifically to avoid miscompilation issues with the default gcc on Ubuntu, which is currently 4.1. I have also been toying with the idea of compiling llvm with llvm-gcc, and it would be quite reassuring if I could run the tests using just the llvm infrastructure. Now back to our regularly scheduled programme, and trying --64 now: ... gives me the same old "suffix or operand invalid for pop/push" errors. Trying with --32: FAIL: /home/jo/Delta/llvm-2.2/test/\ C++Frontend/2006-11-30-NoCompileUnit.cpp Failed with exit(1) at line 3 while running: g++ NoCompileUnit.o -o NoCompileUnit.exe /usr/bin/ld: i386 architecture of input file `NoCompileUnit.o' is incompatible with i386:x86-64 output collect2: ld gab 1 als Ende-Status zur?ck So the assembler is doing its thing (no error message from that stage), but after that, ld fails because it wasn't told to use the 32-bit libs. However, if the llvm build/test machinery mishandles --build/host/target somewhere, things *should* work if all three are uniformly set for 32 bits. Trying that approach with $ ./configure --prefix=$HOME CC=gcc-4.2 CXX=g++-4.2 \ --build=i686-pc-linux-gnu \ --host=i686-pc-linux-gnu \ --target=i686-pc-linux-gnu $ make $ make check ... well, what shall I say: it's still saying Host is x86_64-unknown-linux-gnu and giving me NoCompileUnit.s:33: Error: suffix or operands invalid for `push' (plus variations of the latter). My best hypothesis is that the test simply doesn't follow ./configure. Would it make sense to skip the short test entirely and proceed with the full test suite? I had considered running it anyway, so that wouldn't be a serious problem for me. Heck, I'd even compile llvm-gcc using llvm and good riddance to the preinstalled gcc/g++ infrastructure, I wasn't planning on using it for more than doing the initial bootstrap anyway. I'm not sure whether that solves more problems than it creates though, and that's why I didn't try to that yet - but I'm beginning to think it might be the easier route for me. Regards, Jo From zrakamar at gmail.com Sat Mar 1 19:02:26 2008 From: zrakamar at gmail.com (Zvonimir Rakamaric) Date: Sat, 1 Mar 2008 17:02:26 -0800 Subject: [LLVMdev] simple Data Structure Analysis example Message-ID: > On Thursday 28 February 2008, Zvonimir Rakamaric wrote: > > So, the node "array" in function main has flags HME set. Why is flag E > > (This node comes from an external source) set here? I don't see any > > external sources in this simple program. > > Did you run -internalize before DSA? I think this should help. > > Torvald This was easy :).... Thanks, it helped! -- Zvonimir From edwintorok at gmail.com Sun Mar 2 04:21:11 2008 From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=) Date: Sun, 02 Mar 2008 12:21:11 +0200 Subject: [LLVMdev] llvm/test: suffix or operands invalid for `push' In-Reply-To: <1204417650.7348.41.camel@kurier> References: <1204103370.6718.83.camel@kurier> <1204150347.7608.14.camel@kurier> <364EF13F-5437-4990-9C0B-7A86CF0C17F7@apple.com> <1204192520.7319.51.camel@kurier> <00C3AA84-B1B7-462A-AD73-A96BBDEECE12@apple.com> <82FE5EB6-175D-4841-8E4D-4E41D5DEE993@apple.com> <1204328029.7291.37.camel@kurier> <8EC077B6-99D0-43D3-A851-F986DB09B778@apple.com> <1204329930.7291.56.camel@kurier> <8F94E839-134F-4DD2-AB8C-3F77580EB8EB@apple.com> <1204363746.6821.34.camel@kurier> <1204417650.7348.41.camel@kurier> Message-ID: <47CA7F97.9030006@gmail.com> Joachim Durchholz wrote: > Since llvm cannot generate code for amd64 at this time, this translates > to an additional constraint on --target, restricting me to --target=i686 > only. llvm can generate code for amd64, but shared libs don't work, and bootstrapping doesn't work (PR1711). Still, if you want to compile it as 32-bit, does it work if you run configure like this (without any build,host, target): $ linux32 ./configure It should make all tools believe you are on 32-bit: $ linux32 uname -m i686 $ uname -m x86_64 --Edwin From jo at durchholz.org Sun Mar 2 06:50:05 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 02 Mar 2008 13:50:05 +0100 Subject: [LLVMdev] llvm/test: suffix or operands invalid for `push' In-Reply-To: <47CA7F97.9030006@gmail.com> References: <1204103370.6718.83.camel@kurier> <1204150347.7608.14.camel@kurier> <364EF13F-5437-4990-9C0B-7A86CF0C17F7@apple.com> <1204192520.7319.51.camel@kurier> <00C3AA84-B1B7-462A-AD73-A96BBDEECE12@apple.com> <82FE5EB6-175D-4841-8E4D-4E41D5DEE993@apple.com> <1204328029.7291.37.camel@kurier> <8EC077B6-99D0-43D3-A851-F986DB09B778@apple.com> <1204329930.7291.56.camel@kurier> <8F94E839-134F-4DD2-AB8C-3F77580EB8EB@apple.com> <1204363746.6821.34.camel@kurier> <1204417650.7348.41.camel@kurier> <47CA7F97.9030006@gmail.com> Message-ID: <1204462205.7200.23.camel@kurier> Am Sonntag, den 02.03.2008, 12:21 +0200 schrieb T?r?k Edwin: > Joachim Durchholz wrote: > > Since llvm cannot generate code for amd64 at this time, this translates > > to an additional constraint on --target, restricting me to --target=i686 > > only. > > llvm can generate code for amd64, but shared libs don't work, and > bootstrapping doesn't work (PR1711). > > Still, if you want to compile it as 32-bit, does it work if you run > configure like this (without any build,host, target): > $ linux32 ./configure > > It should make all tools believe you are on 32-bit: > $ linux32 uname -m > i686 > $ uname -m > x86_64 Ah, I didn't know this command existed. You never stop learning :-) $ linux32 ./configure --prefix=$HOME $ linux32 make $ linux32 make check gives ... Native configuration is i686-pc-linux-gnu ... FAIL: /home/jo/Delta/llvm-2.2/test/C++Frontend/2006-11-30-NoCompileUnit.cpp Failed with exit(1) at line 2 while running: as NoCompileUnit.s -o NoCompileUnit.o NoCompileUnit.s: Assembler messages: NoCompileUnit.s:33: Error: suffix or operands invalid for `push' ... So 'runtest' is indeed thinking it is running under a 32-bit system, but 'as' tries to assemble for 64 bits anyway. I don't know whether that's a bug in 'as', or in Ubuntu, or just the way 'as' is supposed to work and the caller should determine the correct options to use. Regards, Jo From mrs at apple.com Sun Mar 2 12:46:22 2008 From: mrs at apple.com (Mike Stump) Date: Sun, 2 Mar 2008 10:46:22 -0800 Subject: [LLVMdev] Idea of a tool to help in library versioning In-Reply-To: <1204407142.4816.0.camel@pitombeira> References: <1204294217.25355.52.camel@pitombeira> <1204407142.4816.0.camel@pitombeira> Message-ID: <175676F6-2196-4B4E-89AD-1A56345F15B9@apple.com> On Mar 1, 2008, at 1:32 PM, Daniel Ruoso wrote: > That's even more cool :)... Is there some code of what you've done > with objdump? Not much more sophisticated than objdump -d | diff as I recall. From viridia at gmail.com Sun Mar 2 14:47:59 2008 From: viridia at gmail.com (Talin) Date: Sun, 02 Mar 2008 12:47:59 -0800 Subject: [LLVMdev] Struct layout assumptions Message-ID: <47CB127F.40601@gmail.com> A question about the layout of structs: I decided to make my vtables out of structs rather than arrays. In other words, instead of being a table of opaque pointers, I decided to individually declare each entry with the correct type for that method. I figure that the various optimizers could do a better job if I preserve the type info. OK, so we come to the issue of inheritance: Suppose I have a class A and subclass B, each of which have two methods. One way to layout the vtable for B is to include the vtable for A as a sub-structure, i.e.: A.vtable = { A.method1 *, A.method2 * } B.vtable = { { A.method1 *, A.method2 * }, B.method1 *, B.method2 * } The advantage of this form is that when you upcast B to an A, the pointer to the B vtable can be upcast as well - i.e. its a valid pointer to a B vtable is also a valid pointer to an A vtable. However, when it comes to actually calling methods this form is somewhat cumbersome to work with. It means that each member in B can't simply record a member index of which table entry it corresponds to; Instead it has to record the entire set of GEP indices to get to that table entry. A more convenient form is to simply flatten the structure: A.vtable = { A.method1 *, A.method2 * } B.vtable = { A.method1 *, A.method2 *, B.method1 *, B.method2 * } Now each member can be referred to via a simple integer index. However, the problem here is that I don't know if its legal to bitcast from B.vtable to A.vtable. As far as I know, the optimizer might re-order the member fields, or muck with the padding. What sort of invariants can I rely on in this case? -- Talin From jo at durchholz.org Sun Mar 2 18:02:34 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 03 Mar 2008 01:02:34 +0100 Subject: [LLVMdev] -m32 gives me mixture of 32- and 64-bit code Message-ID: <1204502554.7200.45.camel@kurier> Hi all, after reading and learning much more about GNU's configure and compile machine than I ever wanted ;-), I arrived at configuring llvm-2.2 like this: CFLAGS=-m32 CXXFLAGS=-m32 ./configure --prefix=$HOME The assembler errors are finally gone (phew!, and thanks for all the help!), but I get linker errors now: llvm[3]: Linking Release Object Library LLVMX86.o llvm[3]: Compiling DelaySlotFiller.cpp for Release build /usr/bin/ld: Relocatable linking with relocations from format elf64-x86-64 (/home/jo/Delta/llvm-2.2/lib/Target/X86/Release/X86ATTAsmPrinter.o) to format elf32-i386 (/home/jo/Delta/llvm-2.2/Release/lib/LLVMX86.o) is not supported make[3]: *** [/home/jo/Delta/llvm-2.2/Release/lib/LLVMX86.o] Fehler 1 Seems like was told to link lib/Target/X86/Release/X86ATTAsmPrinter.o (which is 64-bit) and Release/lib/LLVMX86.o (which is 32-bit). The interesting question being: how did it manage to create a 64-bit X86ATTAsmPrinter.o? I tried throwing everything 32-bitty at it using CFLAGS=-m32 CXXFLAGS=-m32 linux32 \ ./configure --prefix=$HOME \ --host=i686-pc-linux-gnu \ --target=i686-pc-linux-gnu \ --build=i686-pc-linux-gnu; \ make and, strangely enough, the above mismatch vanishes but I still get /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib32/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib32/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/../lib32/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/../lib32/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib32/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib32/libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/../lib32/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/../lib32/libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.1.3/32/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: i386 architecture of input file `/usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib32/crti.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `/usr/lib/gcc/x86_64-linux-gnu/4.1.3/32/crtbeginS.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `/usr/lib/gcc/x86_64-linux-gnu/4.1.3/32/crtendS.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `/usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib32/crtn.o' is incompatible with i386:x86-64 output collect2: ld returned 1 exit status make[3]: *** [/home/jo/Delta/llvm-2.2/Release/lib/LLVMHello.la] Fehler 1 meaning it's trying to combine 32-bit standard libs with something 64-bitty. (Does "i386:x86-64 output" mean ld is still trying to generate 64-bit executables? Maybe I need yet another option here...) Anybody got an idea what's going on here? Regards, Jo From gordonhenriksen at mac.com Sun Mar 2 19:22:01 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Sun, 2 Mar 2008 20:22:01 -0500 Subject: [LLVMdev] Struct layout assumptions In-Reply-To: <47CB127F.40601@gmail.com> References: <47CB127F.40601@gmail.com> Message-ID: <2479E6A7-2ED0-4B2F-A6D9-589143EA61DF@mac.com> On Mar 2, 2008, at 15:47, Talin wrote: > OK, so we come to the issue of inheritance: Suppose I have a class A > and subclass B, each of which have two methods. > > A.vtable = { A.method1 *, A.method2 * } > B.vtable = { { A.method1 *, A.method2 * }, B.method1 *, B.method2 > * } > > A.vtable = { A.method1 *, A.method2 * } > B.vtable = { A.method1 *, A.method2 *, B.method1 *, B.method2 * } > > However, the problem here is that I don't know if its legal to > bitcast from B.vtable to A.vtable. As far as I know, the optimizer > might re-order the member fields, or muck with the padding. Hi Talin, Either form is perfectly safe. ? Gordon From dberlin at dberlin.org Sun Mar 2 22:29:06 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Sun, 2 Mar 2008 23:29:06 -0500 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> Message-ID: <4aca3dc20803022029i7034033dl295608bc2e707224@mail.gmail.com> On Thu, Feb 28, 2008 at 1:43 PM, Richard Warburton wrote: > This email is written on the premise that LLVM will be involved in > GSOC again this year. I noted that the wiki's open projects page [0] > has several possible projects, that seem suitable for a summer of code > project. I am writing this email to this list with the hope of > getting some feedback on specifics for a GSOC application, and also > wondering if any potential mentors are interested in these ideas. > > The Idea: > > Were I to use a BDD based approach, I would undoubtedly rely on an > existing implementation, for example buddy[4], rather than > implementing my own. The opinions of any experienced LLVM hackers > would be helpful on algorithm choice. I am reasonably flexible about > choosing a different . At the moment I am personally undecided. I am > interested to hear any feedback on these ideas, specifically, but in > no particular order, with regards the following points: > > 1. Is this too ambitious for a google summer of code project? > 2. Would implementing any of these algorithms be tricky due to some > peculiarity of LLVM? No I've got a BDD based version of andersen's around already (uncommitted). It's slower in time (by a factor of 8 or so), but very slightly (1-2 megabytes of memory) more memory efficient on some cases. Nowadays, the bitmap version is actually more memory efficient than the BDD version, even if you turn off BDD caching, etc. The thing you have to understand is that these context sensitive BDD algorithms work okay on java, but fall down pretty badly on C/C++, because it is a much bigger problem. Whaley's is just brute force, and Zhu's is pretty darn complex. Both are amenable to the same style of offline variable optimizations that Hardekopf, et al (Ben and a friend have been helping out with implementation of andersen's in LLVM), and that may actually make them usable for real world programs. > 3. Do existing optimisations and DFAs that depend on aliasing > information interface with the alias analysis in a context sensitive > manner, or do they require rewriting? It should work okay. > 4. Is anyone willing to mentor this project? I would. I think you will be surprised how badly these algorithms work on even moderate sized C++ programs :( From evan.cheng at apple.com Mon Mar 3 02:15:18 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 3 Mar 2008 00:15:18 -0800 Subject: [LLVMdev] Instruction Scheduling In-Reply-To: References: Message-ID: <4147A687-7E9E-42E3-9D3F-5D66363987C4@apple.com> You must be using an older release of llvm. There are only three variants left: list-tdrr, list-burr, and list-td. These are all fairly basic: list scheduling for minimum latency (top down only, bottom up isn't implemented due to lack of time), list scheduling for minimum register pressure (both top down and bottom up, but in fact only the bu variant has been actively maintained). x86 and arm defaults to list-burr, it does a reasonable job of minimize register pressure. Recently I haven't noticed many cases where it break down. ppc defaults to list-td, it uses a fairly simple hazard recognizer to form good dispatch groups. There hasn't been any real scheduling study done using llvm as far as I am aware. Evan On Feb 29, 2008, at 8:31 PM, Fernando Magno Quintao Pereira wrote: > > Dear LLVM'ers, > > I am browsing the instruction schedulers available in llc, and > there are many: > > -pre-RA-sched = {default, none, simple, simple-noitin, list-burr, > list-tdrr, list-td} > > I looked into the sources in lib/CodeGen/SelectionDAG, and I could > find implementation of Sethi-Ullman numbering, list scheduling, etc. > Now, I wish I could find some comparison between the schedulers. I > guess you guys probably have some tests somewhere. Basically, I wish I > could know when it is better to use a scheduler, and when it is > better to > use another. Even if someone could point me a paper/report discussing > these issues, it would be great. > > best, > > Fernando > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Mon Mar 3 02:30:14 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 3 Mar 2008 00:30:14 -0800 Subject: [LLVMdev] Instruction Scheduling In-Reply-To: References: Message-ID: <0B67DF2E-49B1-41E7-9FB5-7B7233F6D078@apple.com> It's hard to say. I remember -pre-RA-sched=none (when it used to exist) does a depth first traversal on the dag and translates the nodes in that order. It's not particularly good at anything. I assume your target of choice is x86. In that case, yes the default is burr. On modern x86 cpu's, it's far more important to avoid register spills / restores. Scheduling for latency before register allocation hasn't proven to be a win. Benchmarking x86 is very very tricky. On many cases where obviously better code ended up being slower. Hidden hazards like loop alignment, instructions crossing instruction dispatch buffer, etc. are very hard to model. If the scheduler ended up reducing the number of instructions (and loads and stores), then it's doing its job. It's probably more important to those than the actual runtime. Also, all x86 cpu's do not perform the same. Are you seeing these results on current generation of x86 cpu's? Are you using the latest llvm release (when I guess is not since -pre-RA-sched=none is gone)? Evan On Feb 29, 2008, at 10:52 PM, Fernando Magno Quintao Pereira wrote: > > Hi, guys, > > I am comparing the performance of the default scheduler (seems > to be > the one that minimizes register pressure) with no scheduler > (-pre-RA-sched=none), and I got these numbers. The ratio is > low_reg_pressure/none, that is, the lower the number, the better the > performance with low register pressure: > > CFP2000/177.mesa/177.mesa 1.00 > CFP2000/179.art/179.art 0.98 > CFP2000/183.equake/183.equake 1.00 > CFP2000/188.ammp/188.ammp 0.98 > CINT2000/164.gzip/164.gzip 0.97 > CINT2000/175.vpr/175.vpr 0.97 > CINT2000/176.gcc/176.gcc n/a // crashed! > CINT2000/181.mcf/181.mcf 1.02 > CINT2000/186.crafty/186.crafty 1.00 > CINT2000/197.parser/197.parser 1.01 > CINT2000/252.eon/252.eon n/a // never runs > CINT2000/253.perlbmk/253.perlbmk 1.05 > CINT2000/254.gap/254.gap 0.97 > CINT2000/255.vortex/255.vortex 1.00 > CINT2000/256.bzip2/256.bzip2 0.98 > CINT2000/300.twolf/300.twolf 0.92 > > In three cases, I got a ratio above 1 [Must mean: scheduling had a > negative impact on performance.] I just run it once, but I was > wondering > if this could make sense, or if I am setting the tests wrongly. I am > running the nightly test Makefile, in a x86 linux 32 bits machine. > > best, > > Fernando > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From jo at durchholz.org Mon Mar 3 04:49:37 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 03 Mar 2008 11:49:37 +0100 Subject: [LLVMdev] llvm/test: suffix or operands invalid for `push' In-Reply-To: <1204103370.6718.83.camel@kurier> References: <1204103370.6718.83.camel@kurier> Message-ID: <1204541377.7339.36.camel@kurier> Hi all, I found enough to explain the behaviour that I encountered. If I'm correct, the bugs are just in the dejagnu-based test machinery, not in LLVM itself. There seem to be two issues: Issue 1 is that the CC, CFLAGS, CXX, and CXXFLAGS settings are not reflected in the site.exp file. I had CC=gcc-4.2 CFLAGS="-m32 -Wl,-melf_i386" CXX=g++-4.2 CXXFLAGS=$CFLAGS ARCH=i686-pc-linux-gnu ./configure --prefix=$HOME --target=$ARCH --host=$ARCH --build=$ARCH but site.exp still has set gccpath "gcc" set gxxpath "g++" and no mention of -m32 or -Wl,elf_i386 (these options are required to force a 64-bit GNU toolchain into 32-bit mode). I don't know where these options are lost; I did a little looking around in the configure scripts, but didn't find any obvious problems and decided to leave this kind of issue to the autoconf experts :-) Issue 2 is that the RUN: lines in the dejagnu tests ignore $CC, $CXX, $CFLAGS and $CXXFLAGS when calling gcc, g++, or as (and possibly ld). In most cases things will happen to not fail, but the assembler choked on 32-bit opcodes when running in default mode (which is 64 bits on an amd64 machine, of course). If I'm correct, this is a bug in the tests, not in LLVM. Proposed bug fix would then be to replace in all test case files (hopefully I got the dejagnu macro syntax right): gcc -> %gccpath g++ -> %gxxpath as -> %gccpath (don't call 'as' directly, gcc knows how to call it!) ld -> %gccpath (just as with 'as') Can anybody confirm or correct these findings? Regards, Jo From richard.warburton at gmail.com Mon Mar 3 04:55:12 2008 From: richard.warburton at gmail.com (Richard Warburton) Date: Mon, 3 Mar 2008 10:55:12 +0000 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: <4aca3dc20803022029i7034033dl295608bc2e707224@mail.gmail.com> References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> <4aca3dc20803022029i7034033dl295608bc2e707224@mail.gmail.com> Message-ID: <749b5dd60803030255k49411d02lfa927475c0aa0bf8@mail.gmail.com> > No > I've got a BDD based version of andersen's around already (uncommitted). > It's slower in time (by a factor of 8 or so), but very slightly (1-2 > megabytes of memory) more memory efficient on some cases. Nowadays, > the bitmap version is actually more memory efficient than the BDD > version, even if you turn off BDD caching, etc. > > The thing you have to understand is that these context sensitive BDD > algorithms work okay on java, but fall down pretty badly on C/C++, > because it is a much bigger problem. Whaley's is just brute force, > and Zhu's is pretty darn complex. I was interested to see whether Whaley's algorithm really works particularly, given its simplicity and the claims made in the papers. > Both are amenable to the same style of offline variable optimizations > that Hardekopf, et al (Ben and a friend have been helping out with > implementation of andersen's in LLVM), and that may actually make them > usable for real world programs. Are you referring to both the PLDI and the SAS papers? > > 4. Is anyone willing to mentor this project? > I would. Thanks ;) > I think you will be surprised how badly these algorithms work on even > moderate sized C++ programs :( I'm slightly confused here as to whether you mean in terms of precision of analysis, or compute time taken by running the algorithm. Richard From zack at tungstengraphics.com Mon Mar 3 07:21:05 2008 From: zack at tungstengraphics.com (Zack Rusin) Date: Mon, 3 Mar 2008 08:21:05 -0500 Subject: [LLVMdev] Cloning a function Message-ID: <200803030821.05408.zack@tungstengraphics.com> Hi, we have two modules, one that we basically use as a library in which we store a lot of simple function calls, the other is small program generated at run-time. Whenever a function call for to one of the builtin functions is being called we use CloneFunction to clone the instruction from the library module and insert it in the generated module. The problem is for example when we have something like: declare float @powf(float, float) define void @pow(<4 x float>* %res, /*other args*/...) { entry: ... %call = tail call float @powf( float %tmp1, float %tmp3 ) ... } while powf has a similar extern declaration in the generated module, the cloned function after the CloneFunction call obviously refers to the powf from the library module and asserts as an invalid module. To solve that we add a mapping to DenseMap from the powf declaration in the library module to the powf declaration in the generated module, as in: DenseMap val; val[m_builtins->getFunction("powf")] = currentModule()->getFunction("powf"); func = CloneFunction(originalFunc, val); currentModule()->getFunctionList().push_back(func); unfortunately after this we get an assert: vp-tris: /home/zack/projects/general/llvm/lib/Target/X86/X86CodeEmitter.cpp:412: unsigned int sizeOfImm(const llvm::TargetInstrDesc*): Assertion `0 && "Immediate size not set!"' failed. which I'm a little confused about. Any idea what might be causing this and how to fix it? z From andrewl at lenharth.org Mon Mar 3 10:33:29 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 3 Mar 2008 10:33:29 -0600 Subject: [LLVMdev] Struct layout assumptions In-Reply-To: <47CB127F.40601@gmail.com> References: <47CB127F.40601@gmail.com> Message-ID: <85dfcd7f0803030833q5c2bbc41y71db72841d5c5040@mail.gmail.com> On 3/2/08, Talin wrote: > However, the problem here is that I don't know if its legal to bitcast > from B.vtable to A.vtable. As far as I know, the optimizer might > re-order the member fields, or muck with the padding. > > What sort of invariants can I rely on in this case? An optimization could only do that if it could prove it was safe, that is, if it could find all possible uses and fix them up so they still referred to the same field. Basically an optimizer would have to prove that all accesses to those objects were type safe, and that they didn't escape the analysis scope, and didn't alias with other objects. Having written a safe struct reorganizer in llvm before, I can tell you that even if something like that did exist, it is highly unlikely it would be able to prove its invarients for your code, and if it could, then it would be safe and you wouldn't notice :) Andrew From dag at cray.com Mon Mar 3 12:18:22 2008 From: dag at cray.com (David Greene) Date: Mon, 3 Mar 2008 12:18:22 -0600 Subject: [LLVMdev] [PATCH] REPOST: Scheduler Fix In-Reply-To: References: <200802291540.11627.dag@cray.com> Message-ID: <200803031218.23180.dag@cray.com> On Friday 29 February 2008 17:23, Evan Cheng wrote: > It's not building: > Missing a patch? Hrm. I may have missed something. But Roman's patch is better, so we should go with that. It covers the functionality of this patch, I'm testing Roman's patch right now. -Dave From andrewl at lenharth.org Mon Mar 3 13:50:22 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 3 Mar 2008 13:50:22 -0600 Subject: [LLVMdev] Atomic operations: minimal or maximal? Message-ID: <85dfcd7f0803031150i27ba43fbq9805c58f69b357ce@mail.gmail.com> Looking through the various architectures, it seems that the minimal approach to atomic intrinsics isn't necessarily the best. If we assume CAS and atomic add, then we can implement atomic N, where n is some other operation with a loop. however, for the ll/sc architectures, this will lower into a double loop (the outer loop of load-op-CAS and the CAS loop. On such archs, the atomic op can be done as one loop. To generate the best code, we would have to recognize loops that equated to atomic N, and raise them to a more efficient implementation. The alternative is to implement atomic N for all the Ns in gcc's atomic ops, and let all the ll/sc archs generate efficient code easily, and just lower to a loop for x86, sparc, and ia64. Which is a long way to ask, what do people think design wise? Should we have a large set of atomic ops that most platforms support natively and the couple that don't can easily lower, or have a minimal set and try to raise the lowered gcc atomic ops to efficient code on archs that support ll/sc (essentially trying to recognize the ld, op, CAS loops during codegen). Andrew From criswell at cs.uiuc.edu Mon Mar 3 14:07:16 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 03 Mar 2008 14:07:16 -0600 Subject: [LLVMdev] Atomic operations: minimal or maximal? In-Reply-To: <85dfcd7f0803031150i27ba43fbq9805c58f69b357ce@mail.gmail.com> References: <85dfcd7f0803031150i27ba43fbq9805c58f69b357ce@mail.gmail.com> Message-ID: <47CC5A74.5030600@cs.uiuc.edu> Andrew Lenharth wrote: > Looking through the various architectures, it seems that the minimal > approach to atomic intrinsics isn't necessarily the best. > > If we assume CAS and atomic add, then we can implement atomic N, where > n is some other operation with a loop. however, for the ll/sc > architectures, this will lower into a double loop (the outer loop of > load-op-CAS and the CAS loop. On such archs, the atomic op can be > done as one loop. To generate the best code, we would have to > recognize loops that equated to atomic N, and raise them to a more > efficient implementation. The alternative is to implement atomic N > for all the Ns in gcc's atomic ops, and let all the ll/sc archs > generate efficient code easily, and just lower to a loop for x86, > sparc, and ia64. > Most of these atomic operations for the GCC builtins seem to be variations of fetch_and_phi where phi is some integer or bitwise operation (and, or, add, sub, inc, dec, etc). There are relatively few of them, and they'd all be nearly identical to the fetch_and_add implement ion on LL/SC architectures, so development effort is minimal. I'd say implement them all (or exclude only those that get very, very little usage). There aren't that many atomic different kinds of atomic builtins, and the analysis to raise atomic op loops looks like a lot of effort. -- John T. > Which is a long way to ask, what do people think design wise? Should > we have a large set of atomic ops that most platforms support natively > and the couple that don't can easily lower, or have a minimal set and > try to raise the lowered gcc atomic ops to efficient code on archs > that support ll/sc (essentially trying to recognize the ld, op, CAS > loops during codegen). > > Andrew > _______________________________________________ > 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 Mar 3 15:47:50 2008 From: sabre at nondot.org (Chris Lattner) Date: Mon, 3 Mar 2008 13:47:50 -0800 (PST) Subject: [LLVMdev] Atomic operations: minimal or maximal? In-Reply-To: <85dfcd7f0803031150i27ba43fbq9805c58f69b357ce@mail.gmail.com> References: <85dfcd7f0803031150i27ba43fbq9805c58f69b357ce@mail.gmail.com> Message-ID: On Mon, 3 Mar 2008, Andrew Lenharth wrote: > we have a large set of atomic ops that most platforms support natively > and the couple that don't can easily lower, or have a minimal set and > try to raise the lowered gcc atomic ops to efficient code on archs > that support ll/sc (essentially trying to recognize the ld, op, CAS > loops during codegen). I'd suggest starting with a minimal set. It's easier to add things lazily as needed than it is to take things out that end up not being needed. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From andrewl at lenharth.org Mon Mar 3 15:46:28 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 3 Mar 2008 15:46:28 -0600 Subject: [LLVMdev] Atomic operations: minimal or maximal? In-Reply-To: References: <85dfcd7f0803031150i27ba43fbq9805c58f69b357ce@mail.gmail.com> Message-ID: <85dfcd7f0803031346n564062asc9879e073cf10d49@mail.gmail.com> On 3/3/08, Chris Lattner wrote: > On Mon, 3 Mar 2008, Andrew Lenharth wrote: > > we have a large set of atomic ops that most platforms support natively > > and the couple that don't can easily lower, or have a minimal set and > > try to raise the lowered gcc atomic ops to efficient code on archs > > that support ll/sc (essentially trying to recognize the ld, op, CAS > > loops during codegen). > > > I'd suggest starting with a minimal set. It's easier to add things lazily > as needed than it is to take things out that end up not being needed. Right, that is what is done. And they are sufficient, just not easy to make efficient. But I mostly agree and we can wait until the PPC people complain that their locks are too slow. Andrew From gohman at apple.com Mon Mar 3 16:47:02 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 3 Mar 2008 14:47:02 -0800 Subject: [LLVMdev] ABI for i128 on x86-32? In-Reply-To: <46151.76.126.221.87.1204129998.squirrel@webmail.apple.com> References: <46151.76.126.221.87.1204129998.squirrel@webmail.apple.com> Message-ID: Thanks everyone for your input here; I'm actually not going to persue this at this time. x86-64 does support i128 return values, and that's sufficient for my current needs. Dan On Feb 27, 2008, at 8:33 AM, gohman at apple.com wrote: > Hello, > > Does anyone know of any precedent for handling i128 in the > calling convention on x86-32? I'm trying to write a testcase > that returns an i128 value, and LLVM currently has only two > 32-bit GPRs designated for returning integer values on x86-32. > > Dan > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From cradnil at gmail.com Mon Mar 3 23:48:13 2008 From: cradnil at gmail.com (cradnil) Date: Tue, 4 Mar 2008 13:48:13 +0800 Subject: [LLVMdev] Any idea on translate x86 assembly to LLVM IR? Message-ID: <200803041348098282008@gmail.com> I'am now considering converting x86 machine assembly into LLVM IR, does anyone know about any existing project or resource related to this area? Any difficulities or any ideas on this? thanks for your replies in advance. cradnil 2008-03-04 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080304/bf8bda46/attachment.html From idadesub at users.sourceforge.net Tue Mar 4 00:33:57 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Mon, 3 Mar 2008 22:33:57 -0800 Subject: [LLVMdev] [PATCH] Make sure ocamldep runs on all .mli files. Message-ID: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> This is a small bug fix for the ocaml build system that allows for dependencies to be generated for ocaml interface files. --- bindings/ocaml/Makefile.ocaml | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 7c62c2cd93a6402e5f6ebd600e9e3ac7851b4d29.diff Type: text/x-patch Size: 994 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080303/523c9f1a/attachment.bin From hs4233 at mail.mn-solutions.de Tue Mar 4 00:44:56 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Tue, 4 Mar 2008 07:44:56 +0100 Subject: [LLVMdev] Any idea on translate x86 assembly to LLVM IR? In-Reply-To: <200803041348098282008@gmail.com> References: <200803041348098282008@gmail.com> Message-ID: <200803040744.56777.hs4233@mail.mn-solutions.de> > I'am now considering converting x86 machine assembly into LLVM > IR, does anyone know about any existing project or resource > related to this area? Any difficulities or any ideas on this? There is a idea floating around that LLVM and QEMU could be married. QEMU has sort-of-a-disassembler, where they generate little pieces of code and later let that code execute (it's actually a bit different, but hey, use the source). The idea was to replace that part with an LLVM IR generation. Then you can use standard LLVM optimization passes on this and/or run this code via JIT. Anyway, the disassembler-part of QEMU is easy to rip out, for me it was easier than, say, the libbfd based disassemblers, which are highly optimized to produce human readable strings. From evan.cheng at apple.com Tue Mar 4 01:57:35 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 3 Mar 2008 23:57:35 -0800 Subject: [LLVMdev] Any idea on translate x86 assembly to LLVM IR? In-Reply-To: <200803041348098282008@gmail.com> References: <200803041348098282008@gmail.com> Message-ID: This is a hard problem. Machine assembly is (mostly) untyped. You also have to reconstruct CFG, translate it back to SSA form. Not to mention how do you translate instructions where there is no equivalent llvm instruction. Evan On Mar 3, 2008, at 9:48 PM, cradnil wrote: > I'am now considering converting x86 machine assembly into LLVM IR, > does anyone know about any existing project or resource related to > this area? > Any difficulities or any ideas on this? > > thanks for your replies in advance. > > cradnil > 2008-03-04 > _______________________________________________ > 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/20080303/b0dd02b0/attachment.html From prabhat.saraswat at gmail.com Tue Mar 4 02:24:05 2008 From: prabhat.saraswat at gmail.com (Prabhat Kumar Saraswat) Date: Tue, 4 Mar 2008 09:24:05 +0100 Subject: [LLVMdev] Register Allocation by Graph Coloring Message-ID: Dear all, I was looking for to compile some benchmarks and generate code using different register allocation algorithms. As i can see, the built in options for register allocation in llvm are 1. Simple 2. Local 3. Linear Scan I want to compare the generating code also with a graph coloring based register allocation approach. Is this also built in by default by llvm. Are there some other projects, whose code i can borrow for this task. To summarize: I want to compare the generated code of various benchmarks (generated using linear scan based reg allocation vs graph based register allocation). Any suggestions would be helpful. Regards Prabhat From idadesub at users.sourceforge.net Tue Mar 4 02:19:37 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Tue, 4 Mar 2008 00:19:37 -0800 Subject: [LLVMdev] [PATCH] Cleanup the c and ocaml binding documentation. In-Reply-To: <1204618777-26977-1-git-send-email-idadesub@users.sourceforge.net> References: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> <1204618777-26977-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: <1204618777-26977-2-git-send-email-idadesub@users.sourceforge.net> --- bindings/ocaml/llvm/llvm.ml | 2 +- bindings/ocaml/llvm/llvm.mli | 2 +- bindings/ocaml/llvm/llvm_ocaml.c | 2 +- include/llvm-c/Core.h | 32 +++++++++++++++++++------------- 4 files changed, 22 insertions(+), 16 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 316a84e85ed2363551149e65a227c8e7c8192624.diff Type: text/x-patch Size: 5061 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080304/ea3f0621/attachment.bin From idadesub at users.sourceforge.net Tue Mar 4 02:19:36 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Tue, 4 Mar 2008 00:19:36 -0800 Subject: [LLVMdev] [PATCH] Prefer to use *.opt ocaml executables as they are more efficient. In-Reply-To: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> References: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: <1204618777-26977-1-git-send-email-idadesub@users.sourceforge.net> I noticed that the ocaml compilation isn't using the .opt executables if they're available. We might gain a slight optimization in ocaml compile time by optionally using them with this patch. --- autoconf/configure.ac | 18 +++++ configure | 195 ++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 188 insertions(+), 25 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 97c6db7b03016306d34ee2e3ca41d0e423cf2c0c.diff Type: text/x-patch Size: 14342 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080304/05b4dd48/attachment-0001.bin From zhousheng00 at gmail.com Tue Mar 4 03:24:24 2008 From: zhousheng00 at gmail.com (Zhou Sheng) Date: Tue, 4 Mar 2008 17:24:24 +0800 Subject: [LLVMdev] llvm-gcc 4.2 building failed on x86-64 Message-ID: <8abe0dc60803040124y5d0308eft5b60bc1c06f68823@mail.gmail.com> Current llvm-gcc 4.2 building failed on X86-64, here is the dump information: xgcc -B/home/zsth/projects/llvm.org/build/cfe4.2obj/./prev-gcc/ -B/home/zsth/projects/llvm.org/install/x86_64-unknown-linux-gnu/bin/ -I../../../cfe4.2/libcpp -I. -I../../../cfe4.2/libcpp/../include -I../../../cfe4.2/libcpp/include -DENABLE_LLVM -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -I../../../cfe4.2/libcpp -I. -I../../../cfe4.2/libcpp/../include -I../../../cfe4.2/libcpp/include -DENABLE_LLVM -c -o directives.o -MT directives.o -MMD -MP -MF .deps/directives.Po ../../../cfe4.2/libcpp/directives.c ../../../cfe4.2/libcpp/directives.c: In function 'do_pragma': ../../../cfe4.2/libcpp/directives.c:1376: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions Any ideas? My gcc version: gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../gcc-4.0.4/configure --prefix=/home/toolman/gcc4.0.4-x86_64 --enable-languages=c,c++ --host=x86_64-redhat-linux Thread model: posix gcc version 4.0.4 Thanks, Sheng. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080304/1f44c81e/attachment.html From st at iss.tu-darmstadt.de Tue Mar 4 04:39:12 2008 From: st at iss.tu-darmstadt.de (ST) Date: Tue, 4 Mar 2008 11:39:12 +0100 Subject: [LLVMdev] llvm-gcc 4.2 building failed on x86-64 In-Reply-To: <8abe0dc60803040124y5d0308eft5b60bc1c06f68823@mail.gmail.com> References: <8abe0dc60803040124y5d0308eft5b60bc1c06f68823@mail.gmail.com> Message-ID: <200803041139.12304.st@iss.tu-darmstadt.de> Hi Sheng Am Dienstag, 4. M?rz 2008 schrieb Zhou Sheng: > Current llvm-gcc 4.2 building failed on X86-64, here is the dump I am not followng head closely but may it be that the current head still doesn't support amd64 proper: gcc README.LLVM: "When targeting non-darwin X86-64/AMD-64/EM64-T, configure with --disable-shared. The LLVM X86-64 backend doesn't support PIC codegen on non-darwin systems yet. If you get a build error, try configuring with --disable-multilib." Best regards ST From aditya at iss.tu-darmstadt.de Tue Mar 4 07:31:29 2008 From: aditya at iss.tu-darmstadt.de (Aditya Vishnubhotla Vijay) Date: Tue, 4 Mar 2008 14:31:29 +0100 Subject: [LLVMdev] Deleting Instructions after Intrinsic Creation Message-ID: <200803041431.29742.aditya@iss.tu-darmstadt.de> Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I want to retain only intrinsic,phi and terminator instructions in a basic block. I have taken care of the external dependencies of basic block. How do I delete the rest of the instructions? Thank You Aditya P.S: ---------------------------------------------------------------------------------------------- Below is the section of LLVM IR after intrinsic creation (Instructions to be deleted have only internal uses): define i32 @main() nounwind { entry: %year.i = alloca i32 ; [#uses=2] %tmp2.i = call i32 (i8*, ...)* @printf( i8* noalias getelementptr ([15 x i8]* @.str2, i32 0, i32 0) ) nounwind ; [#uses=0] %tmp4.i = call i32 (i8*, ...)* @scanf( i8* noalias getelementptr ([3 x i8]* @.str3, i32 0, i32 0), i32* %year.i ) nounwind ; [#uses=0] %tmp5.i = load i32* %year.i, align 4 ; [#uses=3] %tmp12.i = sitofp i32 %tmp5.i to double ; [#uses=1] %tmp3.i = sub double %tmp12.i, 1.000000e+00 ; [#uses=3] %tmp4.i1 = fdiv double %tmp3.i, 4.000000e+00 ; [#uses=1] %tmp45.i = fptosi double %tmp4.i1 to i32 ; [#uses=1] %tmp9.i = fdiv double %tmp3.i, 1.000000e+02 ; [#uses=1] %tmp910.i = fptosi double %tmp9.i to i32 ; [#uses=1] %tmp14.i = fdiv double %tmp3.i, 4.000000e+02 ; [#uses=1] %tmp1415.i = fptosi double %tmp14.i to i32 ; [#uses=1] %tmp18.i = add i32 %tmp45.i, %tmp5.i ; [#uses=1] %tmp20.i = sub i32 %tmp18.i, %tmp910.i ; [#uses=1] %tmp22.i = add i32 %tmp20.i, %tmp1415.i ; [#uses=1] %tmp23.i = srem i32 %tmp22.i, 7 ; [#uses=0] %tmp2.i2 = and i32 %tmp5.i, 3 ; [#uses=1] %tmp3.i3 = icmp eq i32 %tmp2.i2, 0 ; [#uses=0] %migrate_begin = call i32 (...)* @llvm.migrate_begin( ) ; [#uses=2] %migrate_end = call i32 @llvm.migrate_end_1.i32( i32 %migrate_begin ) ; [#uses=5] %migrate_end1 = call i1 @llvm.migrate_end_1.i1( i32 %migrate_begin ) ; [#uses=1] br i1 %migrate_end1, label %bb.i, label %bb10.i ------------------------------------------------------------------------------------------------------------- Section of code used to delete instructions: for(BasicBlock::iterator i= bbp->getFirstNonPHI(),ie=bbp->end();i!=ie;++i){ if(!((i->isTerminator()) || (isa(i)))) {i->dropAllReferences(); } } for(BasicBlock::iterator bi= bbp->getFirstNonPHI(),ie=bbp->end();bi!=ie;++bi){ if((*bi).getNumOperands()==0) {(*bi).eraseFromParent();} } -------------------------------------------------------------------------------------------------------------- Error: (gdb) bt #0 llvm::AssemblyWriter::printInstruction (this=0xbfa1a75c, I=@0x877b488) at AsmWriter.cpp:1378 #1 0x085b2ece in llvm::AssemblyWriter::write (this=0xbfa1a75c, I=0x877b488) at AsmWriter.cpp:741 #2 0x085adb0f in llvm::Instruction::print (this=0x877b488, o=@0x8794f48, AAW=0x0) at AsmWriter.cpp:1482 #3 0x085b5bf2 in llvm::Instruction::print (this=0x877b488, OS=@0x8794f48) at /work/aditya/llvm-2.2/include/llvm/Instruction.h:172 #4 0x08357c13 in llvm::operator<< (OS=@0x8794f48, V=@0x877b488) at /work/aditya/llvm-2.2/include/llvm/Value.h:221 #5 0x0863ceb5 in (anonymous namespace)::Verifier::WriteValue (this=0x8794f18, V=0x877b488) at Verifier.cpp:272 #6 0x0863d139 in (anonymous namespace)::Verifier::CheckFailed (this=0x8794f18, Message=@0xbfa1a878, V1=0x877b488, V2=0x0, V3=0x0, V4=0x0) at Verifier.cpp:292 #7 0x08636ba2 in (anonymous namespace)::Verifier::visitInstruction (this=0x8794f18, I=@0x877b488) at Verifier.cpp:1077 #8 0x08637807 in (anonymous namespace)::Verifier::visitAllocationInst (this=0x8794f18, AI=@0x877b488) at Verifier.cpp:1037 #9 0x0863d75e in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visitAllocaInst (this=0x8794f18, I=@0x877b488) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:173 #10 0x0863d778 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visitAlloca (this=0x8794f18, I=@0x877b488) at /work/aditya/llvm-2.2/include/llvm/Instruction.def:130 #11 0x0863df45 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, I=@0x877b488) at /work/aditya/llvm-2.2/include/llvm/Instruction.def:130 #12 0x0863e1d1 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit > (this=0x8794f18, Start= {> = {<> = {}, }, NodePtr = 0x877b4f8}, End= {> = {<> = {}, }, NodePtr = 0x877b4c8}) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:92 #13 0x0863e248 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, BB=@0x8776e80) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:107 #14 0x0863e293 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit > (this=0x8794f18, Start= {> = {<> = {}, }, NodePtr = 0x8776ee8}, End= {> = {<> = {}, }, NodePtr = 0x8776ea8}) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:92 #15 0x0863e4b0 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, F=@0x8777638) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:103 #16 0x0863e4ff in (anonymous namespace)::Verifier::runOnFunction (this=0x8794f18, F=@0x8777638) at Verifier.cpp:155 #17 0x0860e692 in llvm::FPPassManager::runOnFunction (this=0x8793ca8, F=@0x8777638) at PassManager.cpp:1171 #18 0x0860e83e in llvm::FPPassManager::runOnModule (this=0x8793ca8, M=@0x8773d10) at PassManager.cpp:1191 #19 0x0860e362 in llvm::MPPassManager::runOnModule (this=0x87731d8, M=@0x8773d10) at PassManager.cpp:1240 #20 0x0860e518 in llvm::PassManagerImpl::run (this=0x87766b8, M=@0x8773d10) at PassManager.cpp:1313 #21 0x0860e56a in llvm::PassManager::run (this=0xbfa1ac28, M=@0x8773d10) at PassManager.cpp:1345 #22 0x0836680d in main (argc=13, argv=0xbfa1ae14) at opt.cpp:426 From vvaditya12 at yahoo.com Tue Mar 4 07:37:06 2008 From: vvaditya12 at yahoo.com (aditya vishnubhotla) Date: Tue, 4 Mar 2008 05:37:06 -0800 (PST) Subject: [LLVMdev] Deleting Instructions after Intrinsic Creation Message-ID: <619441.44188.qm@web56004.mail.re3.yahoo.com> Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I want to retain only intrinsic,phi and terminator instructions in a basic block. I have taken care of the external dependencies of basic block. How do I delete the rest of the instructions? Thank You Aditya P.S: ---------------------------------------------------------------------------------------------- Below is the section of LLVM IR after intrinsic creation (Instructions to be deleted have only internal uses): define i32 @main() nounwind { entry: %year.i = alloca i32 ; [#uses=2] %tmp2.i = call i32 (i8*, ...)* @printf( i8* noalias getelementptr ([15 x i8]* @.str2, i32 0, i32 0) ) nounwind ; [#uses=0] %tmp4.i = call i32 (i8*, ...)* @scanf( i8* noalias getelementptr ([3 x i8]* @.str3, i32 0, i32 0), i32* %year.i ) nounwind ; [#uses=0] %tmp5.i = load i32* %year.i, align 4 ; [#uses=3] %tmp12.i = sitofp i32 %tmp5.i to double ; [#uses=1] %tmp3.i = sub double %tmp12.i, 1.000000e+00 ; [#uses=3] %tmp4.i1 = fdiv double %tmp3.i, 4.000000e+00 ; [#uses=1] %tmp45.i = fptosi double %tmp4.i1 to i32 ; [#uses=1] %tmp9.i = fdiv double %tmp3.i, 1.000000e+02 ; [#uses=1] %tmp910.i = fptosi double %tmp9.i to i32 ; [#uses=1] %tmp14.i = fdiv double %tmp3.i, 4.000000e+02 ; [#uses=1] %tmp1415.i = fptosi double %tmp14.i to i32 ; [#uses=1] %tmp18.i = add i32 %tmp45.i, %tmp5.i ; [#uses=1] %tmp20.i = sub i32 %tmp18.i, %tmp910.i ; [#uses=1] %tmp22.i = add i32 %tmp20.i, %tmp1415.i ; [#uses=1] %tmp23.i = srem i32 %tmp22.i, 7 ; [#uses=0] %tmp2.i2 = and i32 %tmp5.i, 3 ; [#uses=1] %tmp3.i3 = icmp eq i32 %tmp2.i2, 0 ; [#uses=0] %migrate_begin = call i32 (...)* @llvm.migrate_begin( ) ; [#uses=2] %migrate_end = call i32 @llvm.migrate_end_1.i32( i32 %migrate_begin ) ; [#uses=5] %migrate_end1 = call i1 @llvm.migrate_end_1.i1( i32 %migrate_begin ) ; [#uses=1] br i1 %migrate_end1, label %bb.i, label %bb10.i ------------------------------------------------------------------------------------------------------------- Section of code used to delete instructions: for(BasicBlock::iterator i= bbp->getFirstNonPHI(),ie=bbp->end();i!=ie;++i){ if(!((i->isTerminator()) || (isa(i)))) {i->dropAllReferences();} } for(BasicBlock::iterator bi= bbp->getFirstNonPHI(),ie=bbp->end();bi!=ie;++bi){ if((*bi).getNumOperands()==0) {(*bi).eraseFromParent();} } -------------------------------------------------------------------------------------------------------------- Error: (gdb) bt #0 llvm::AssemblyWriter::printInstruction (this=0xbfa1a75c, I=@0x877b488) at AsmWriter.cpp:1378 #1 0x085b2ece in llvm::AssemblyWriter::write (this=0xbfa1a75c, I=0x877b488) at AsmWriter.cpp:741 #2 0x085adb0f in llvm::Instruction::print (this=0x877b488, o=@0x8794f48, AAW=0x0) at AsmWriter.cpp:1482 #3 0x085b5bf2 in llvm::Instruction::print (this=0x877b488, OS=@0x8794f48) at /work/aditya/llvm-2.2/include/llvm/Instruction.h:172 #4 0x08357c13 in llvm::operator<< (OS=@0x8794f48, V=@0x877b488) at /work/aditya/llvm-2.2/include/llvm/Value.h:221 #5 0x0863ceb5 in (anonymous namespace)::Verifier::WriteValue (this=0x8794f18, V=0x877b488) at Verifier.cpp:272 #6 0x0863d139 in (anonymous namespace)::Verifier::CheckFailed (this=0x8794f18, Message=@0xbfa1a878, V1=0x877b488, V2=0x0, V3=0x0, V4=0x0) at Verifier.cpp:292 #7 0x08636ba2 in (anonymous namespace)::Verifier::visitInstruction (this=0x8794f18, I=@0x877b488) at Verifier.cpp:1077 #8 0x08637807 in (anonymous namespace)::Verifier::visitAllocationInst (this=0x8794f18, AI=@0x877b488) at Verifier.cpp:1037 #9 0x0863d75e in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visitAllocaInst (this=0x8794f18, I=@0x877b488) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:173 #10 0x0863d778 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visitAlloca (this=0x8794f18, I=@0x877b488) at /work/aditya/llvm-2.2/include/llvm/Instruction.def:130 #11 0x0863df45 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, I=@0x877b488) at /work/aditya/llvm-2.2/include/llvm/Instruction.def:130 #12 0x0863e1d1 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit > (this=0x8794f18, Start= {> = {<> = {}, }, NodePtr = 0x877b4f8}, End= {> = {<> = {}, }, NodePtr = 0x877b4c8}) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:92 #13 0x0863e248 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, BB=@0x8776e80) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:107 #14 0x0863e293 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit > (this=0x8794f18, Start= {> = {<> = {}, }, NodePtr = 0x8776ee8}, End= {> = {<> = {}, }, NodePtr = 0x8776ea8}) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:92 #15 0x0863e4b0 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, F=@0x8777638) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:103 #16 0x0863e4ff in (anonymous namespace)::Verifier::runOnFunction (this=0x8794f18, F=@0x8777638) at Verifier.cpp:155 #17 0x0860e692 in llvm::FPPassManager::runOnFunction (this=0x8793ca8, F=@0x8777638) at PassManager.cpp:1171 #18 0x0860e83e in llvm::FPPassManager::runOnModule (this=0x8793ca8, M=@0x8773d10) at PassManager.cpp:1191 #19 0x0860e362 in llvm::MPPassManager::runOnModule (this=0x87731d8, M=@0x8773d10) at PassManager.cpp:1240 #20 0x0860e518 in llvm::PassManagerImpl::run (this=0x87766b8, M=@0x8773d10) at PassManager.cpp:1313 #21 0x0860e56a in llvm::PassManager::run (this=0xbfa1ac28, M=@0x8773d10) at PassManager.cpp:1345 #22 0x0836680d in main (argc=13, argv=0xbfa1ae14) at opt.cpp:426 ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From gordonhenriksen at mac.com Tue Mar 4 08:11:11 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Tue, 4 Mar 2008 09:11:11 -0500 Subject: [LLVMdev] [PATCH] Prefer to use *.opt ocaml executables as they are more efficient. In-Reply-To: <1204618777-26977-1-git-send-email-idadesub@users.sourceforge.net> References: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> <1204618777-26977-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: <7B98597D-8772-4D07-9A6A-BF39E23BB78D@mac.com> Hi Erick, On Mar 4, 2008, at 03:19, Erick Tryzelaar wrote: > I noticed that the ocaml compilation isn't using the .opt > executables if they're available. We might gain a slight > optimization in ocaml compile time by optionally using them > with this patch. This looks like a good improvement. > --- > autoconf/configure.ac | 18 +++++ > configure | 195 ++++++++++++++++++++++++++++++++++++++++ > ++------ > 2 files changed, 188 insertions(+), 25 deletions(-)diff --git > autoconf/configure.ac autoconf/configure.ac > index 97e0305..56a25ca 100644 > --- autoconf/configure.ac > +++ autoconf/configure.ac > @@ -592,6 +592,9 @@ AC_PATH_PROG(ZIP,[zip],[echo "Skipped: zip not > found"]) > AC_PATH_PROG(OCAMLC,[ocamlc],[echo "Skipped: ocamlc not found"]) > AC_PATH_PROG(OCAMLOPT,[ocamlopt],[echo "Skipped: ocamlopt not found"]) > AC_PATH_PROG(OCAMLDEP,[ocamldep],[echo "Skipped: ocamldep not found"]) > +AC_PATH_PROG(OCAMLC_OPT,[ocamlc.opt],[echo "Skipped: ocamlc.opt not > found"]) > +AC_PATH_PROG(OCAMLOPT_OPT,[ocamlopt.opt],[echo "Skipped: > ocamlopt.opt not found"]) > +AC_PATH_PROG(OCAMLDEP_OPT,[ocamldep.opt],[echo "Skipped: > ocamldep.opt not found"]) > > dnl Determine if the linker supports the -R option. > AC_LINK_USE_R > @@ -911,6 +914,21 @@ AC_DEFINE_UNQUOTED(LLVM_CONFIGTIME, > "$LLVM_CONFIGTIME", > AC_DEFINE_UNQUOTED(LLVM_HOSTTRIPLE, "$host", > [Host triple we were built on]) > > +# prefer ocamlc.opt to ocamlc > +if test "x$OCAMLC" != x -a "x$OCAMLC_OPT" != x ; then > + OCAMLC=$OCAMLC_OPT > +fi > + > +# prefer ocamlopt.opt to ocamlopt > +if test "x$OCAMLOPT" != x -a "x$OCAMLOPT_OPT" != x ; then > + OCAMLOPT=$OCAMLOPT_OPT > +fi > + > +# prefer ocamldep.opt to ocamldep > +if test "x$OCAMLDEP" != x -a "x$OCAMLDEP_OPT" != x ; then > + OCAMLDEP=$OCAMLDEP_OPT > +fi > + > # Determine which bindings to build. > if test "$BINDINGS_TO_BUILD" = auto ; then > BINDINGS_TO_BUILD="" I think it would be simpler to use AC_PATH_PROGS instead. See how $GV is set up for instance. Can you please see whether that approach is workable? ? Gordon From gordonhenriksen at mac.com Tue Mar 4 08:18:26 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Tue, 4 Mar 2008 09:18:26 -0500 Subject: [LLVMdev] [PATCH] Cleanup the c and ocaml binding documentation. In-Reply-To: <1204618777-26977-2-git-send-email-idadesub@users.sourceforge.net> References: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> <1204618777-26977-1-git-send-email-idadesub@users.sourceforge.net> <1204618777-26977-2-git-send-email-idadesub@users.sourceforge.net> Message-ID: <0C3835AC-4B7B-45F3-BF09-542EDD95974C@mac.com> Hi Erick, Thanks, this looks good. Can you please resubmit this patch, and the others, as an attachment? On Mar 4, 2008, at 03:19, Erick Tryzelaar wrote: > --- > bindings/ocaml/llvm/llvm.ml | 2 +- > bindings/ocaml/llvm/llvm.mli | 2 +- > bindings/ocaml/llvm/llvm_ocaml.c | 2 +- > include/llvm-c/Core.h | 32 ++++++++++++++++++ > +------------- > 4 files changed, 22 insertions(+), 16 deletions(-)diff --git > bindings/ocaml/llvm/llvm.ml bindings/ocaml/llvm/llvm.ml > index 6657af5..ea6ef71 100644 > --- bindings/ocaml/llvm/llvm.ml > +++ bindings/ocaml/llvm/llvm.ml > @@ -1,4 +1,4 @@ > -(*===-- tools/ml/llvm.ml - LLVM Ocaml Interface > ---------------------------===* > +(*===-- llvm/llvm.ml - LLVM Ocaml Implementation > ---------------------------===* > * > * The LLVM Compiler Infrastructure > * > diff --git bindings/ocaml/llvm/llvm.mli bindings/ocaml/llvm/llvm.mli > index c6d50c9..3ed9d27 100644 > --- bindings/ocaml/llvm/llvm.mli > +++ bindings/ocaml/llvm/llvm.mli > @@ -1,4 +1,4 @@ > -(*===-- tools/ml/llvm.ml - LLVM Ocaml Interface > ---------------------------===* > +(*===-- llvm/llvm.mli - LLVM Ocaml Interface > -------------------------------===* > * > * The LLVM Compiler Infrastructure > * > diff --git bindings/ocaml/llvm/llvm_ocaml.c bindings/ocaml/llvm/ > llvm_ocaml.c > index 3f48887..f4e958d 100644 > --- bindings/ocaml/llvm/llvm_ocaml.c > +++ bindings/ocaml/llvm/llvm_ocaml.c > @@ -1,4 +1,4 @@ > -/*===-- llvm_ocaml.h - LLVM Ocaml Glue --------------------------*- > C++ -*-===*\ > +/*===-- llvm_ocaml.c - LLVM Ocaml Glue --------------------------*- > C++ -*-===*\ > | > * *| > |* The LLVM Compiler > Infrastructure *| > | > * *| > diff --git include/llvm-c/Core.h include/llvm-c/Core.h > index 9b11df5..3676377 100644 > --- include/llvm-c/Core.h > +++ include/llvm-c/Core.h > @@ -48,20 +48,20 @@ extern "C" { > > /** > * The top-level container for all other LLVM Intermediate > Representation (IR) > - * objects. See the llvm::Module class. > + * objects. See the [llvm::Module] class. > */ > typedef struct LLVMOpaqueModule *LLVMModuleRef; > > /** > - * Each value in the LLVM IR has a type, an instance of [lltype]. > See the > - * llvm::Type class. > + * Each value in the LLVM IR has a type, an instance of > [LLVMTypeRef]. See the > + * [llvm::Type] class. > */ > typedef struct LLVMOpaqueType *LLVMTypeRef; > > /** > - * When building recursive types using [refine_type], [lltype] > values may become > - * invalid; use [lltypehandle] to resolve this problem. See the > - * llvm::AbstractTypeHolder] class. > + * When building recursive types using [LLVMRefineType], > [LLVMTypeRef] values may become > + * invalid; use [LLVMTypeHandleRef] to resolve this problem. See the > + * [llvm::AbstractTypeHolder] class. > */ > typedef struct LLVMOpaqueTypeHandle *LLVMTypeHandleRef; > > @@ -70,12 +70,12 @@ typedef struct LLVMOpaqueBasicBlock > *LLVMBasicBlockRef; > typedef struct LLVMOpaqueBuilder *LLVMBuilderRef; > > /* Used to provide a module to JIT or interpreter. > - * See the llvm::ModuleProvider class. > + * See the [llvm::ModuleProvider] class. > */ > typedef struct LLVMOpaqueModuleProvider *LLVMModuleProviderRef; > > /* Used to provide a module to JIT or interpreter. > - * See the llvm::MemoryBuffer class. > + * See the [llvm::MemoryBuffer] class. > */ > typedef struct LLVMOpaqueMemoryBuffer *LLVMMemoryBufferRef; > > @@ -165,18 +165,21 @@ void LLVMDisposeMessage(char *Message); > /*===-- Modules > -----------------------------------------------------------===*/ > > /* Create and destroy modules. */ > +/** See [llvm::Module::Module]. */ > LLVMModuleRef LLVMModuleCreateWithName(const char *ModuleID); > + > +/** See [llvm::Module::~Module]. */ > void LLVMDisposeModule(LLVMModuleRef M); > > -/* Data layout */ > +/** Data layout. See [Module::getDataLayout]. */ > const char *LLVMGetDataLayout(LLVMModuleRef M); > void LLVMSetDataLayout(LLVMModuleRef M, const char *Triple); > > -/* Target triple */ > +/** Target triple. See [Module::getTargetTriple]. */ > const char *LLVMGetTarget(LLVMModuleRef M); > void LLVMSetTarget(LLVMModuleRef M, const char *Triple); > > -/* Same as Module::addTypeName. */ > +/** See [Module::addTypeName]. */ > int LLVMAddTypeName(LLVMModuleRef M, const char *Name, LLVMTypeRef > Ty); > void LLVMDeleteTypeName(LLVMModuleRef M, const char *Name); > > @@ -198,7 +201,10 @@ void LLVMDeleteTypeName(LLVMModuleRef M, const > char *Name); > * opaque type > */ > > +/** See [llvm::LLVMTypeKind::getTypeID]. */ > LLVMTypeKind LLVMGetTypeKind(LLVMTypeRef Ty); > + > +/** See [llvm::DerivedType::refineAbstractTypeTo]. */ > void LLVMRefineAbstractType(LLVMTypeRef AbstractType, LLVMTypeRef > ConcreteType); > > /* Operations on integer types */ > @@ -546,13 +552,13 @@ LLVMValueRef > LLVMBuildShuffleVector(LLVMBuilderRef, LLVMValueRef V1, > > /* Encapsulates the module M in a module provider, taking ownership > of the > * module. > - * See the constructor > llvm::ExistingModuleProvider::ExistingModuleProvider. > + * See the constructor > [llvm::ExistingModuleProvider::ExistingModuleProvider]. > */ > LLVMModuleProviderRef > LLVMCreateModuleProviderForExistingModule(LLVMModuleRef M); > > /* Destroys the module provider MP as well as the contained module. > - * See the destructor llvm::ModuleProvider::~ModuleProvider. > + * See the destructor [llvm::ModuleProvider::~ModuleProvider]. > */ > void LLVMDisposeModuleProvider(LLVMModuleProviderRef MP); > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev ? Gordon From gordonhenriksen at mac.com Tue Mar 4 08:44:47 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Tue, 4 Mar 2008 09:44:47 -0500 Subject: [LLVMdev] [PATCH] Cleanup the c and ocaml binding documentation. In-Reply-To: <0C3835AC-4B7B-45F3-BF09-542EDD95974C@mac.com> References: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> <1204618777-26977-1-git-send-email-idadesub@users.sourceforge.net> <1204618777-26977-2-git-send-email-idadesub@users.sourceforge.net> <0C3835AC-4B7B-45F3-BF09-542EDD95974C@mac.com> Message-ID: <872FECF0-E057-4E98-9C48-89EA8EF33EA7@mac.com> On Mar 4, 2008, at 09:18, Gordon Henriksen wrote: > Hi Erick, > > Thanks, this looks good. Can you please resubmit this patch, and the > others, as an attachment? > > On Mar 4, 2008, at 03:19, Erick Tryzelaar wrote: > >> diff --git include/llvm-c/Core.h include/llvm-c/Core.h >> index 9b11df5..3676377 100644 >> --- include/llvm-c/Core.h >> +++ include/llvm-c/Core.h >> @@ -48,20 +48,20 @@ extern "C" { >> >> /** >> * The top-level container for all other LLVM Intermediate >> Representation (IR) >> - * objects. See the llvm::Module class. >> + * objects. See the [llvm::Module] class. >> */ >> typedef struct LLVMOpaqueModule *LLVMModuleRef; Actually, I spoke too soon. ocamldoc's [] syntax is not recognized by doxygen, so it will just be noise. Please leave it out in C. Thanks, Gordon From gordonhenriksen at mac.com Tue Mar 4 08:54:54 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Tue, 4 Mar 2008 09:54:54 -0500 Subject: [LLVMdev] [PATCH] Make sure ocamldep runs on all .mli files. In-Reply-To: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> References: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: <8F62301B-FC47-4A1A-91C1-214901A40BA6@mac.com> Hi Erick, Thanks for your patches! On Mar 4, 2008, at 01:33, Erick Tryzelaar wrote: > This is a small bug fix for the ocaml build system that allows > for dependencies to be generated for ocaml interface files. I've committed the second half of this. > --- > bindings/ocaml/Makefile.ocaml | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-)diff --git bindings/ > ocaml/Makefile.ocaml bindings/ocaml/Makefile.ocaml > index 6fc9a9a..d505ad8 100644 > --- bindings/ocaml/Makefile.ocaml > +++ bindings/ocaml/Makefile.ocaml > @@ -58,7 +58,7 @@ Archive.CMXA := $(strip $(OCAMLOPT) -a $ > (OCAMLAFLAGS) $(OCAMLDEBUGFLAG) -o) > > # Source files > OcamlSources1 := $(sort $(wildcard $(PROJ_SRC_DIR)/*.ml)) > -OcamlHeaders1 := $(OcamlSources1:.ml=.mli) > +OcamlHeaders1 := $(sort $(wildcard $(PROJ_SRC_DIR)/*.mli)) Not sure how an .mli without a corresponding .ml would be useful, so I left this bit. Thanks! Gordon From dag at cray.com Tue Mar 4 11:19:56 2008 From: dag at cray.com (David Greene) Date: Tue, 4 Mar 2008 11:19:56 -0600 Subject: [LLVMdev] Getting the Stack Pointer Message-ID: <200803041119.56466.dag@cray.com> What's the "right" way to find out which machine register acts as the stack pointer? I'm working on enhancing Fernando's register allocator debugger and would like to add support for stack pointer semantics. TargetRegisterInfo has a getFrameRegister method but that returns (on x86) either ESP/RSP or EBP/RBP depending on whether frame pointer elimination has been done. Would it be ok to add a getStackPointerRegister method to TargetRegisterInfo? -Dave From dag at cray.com Tue Mar 4 11:24:48 2008 From: dag at cray.com (David Greene) Date: Tue, 4 Mar 2008 11:24:48 -0600 Subject: [LLVMdev] Register Allocation by Graph Coloring In-Reply-To: References: Message-ID: <200803041124.48884.dag@cray.com> On Tuesday 04 March 2008 02:24, Prabhat Kumar Saraswat wrote: > Dear all, > I was looking for to compile some benchmarks and generate code using > different register allocation algorithms. As i can see, the built in > options for register allocation in llvm are > 1. Simple > 2. Local > 3. Linear Scan > > I want to compare the generating code also with a graph coloring based > register allocation approach. Is this also built in by default by > llvm. Are there some other projects, whose code i can borrow for this > task. There have been several people working on projects like this, including me. Unfortunately, I am not able to contribute my code. But Bill Wendling posted an (incomplete) implementation of priority-based graph coloring some time ago. You can check the list archives (Google is your friend here). If you are doing this as part of a research project leading to publication, be very careful about how you specify things. Every single register allocation paper I've ever read is woefully incomplete when it comes to specifying exactly what the allocator does. Even the papers by Briggs and Chaiten contradict themselves when you examine the text of the paper vs. the pseudocode provided. There are lots of variables and heuristics. Be very skeptical about any performance data you come across. I have seen swings of 20% or more in performance based on assumptions about heuristics and various enhancements to the algorithms. -Dave From fernando at CS.UCLA.EDU Tue Mar 4 11:26:22 2008 From: fernando at CS.UCLA.EDU (Fernando Magno Quintao Pereira) Date: Tue, 4 Mar 2008 09:26:22 -0800 (PST) Subject: [LLVMdev] Register Allocation by Graph Coloring In-Reply-To: References: Message-ID: Hi, Prabhat, I have the implementation of a register allocator at http://compilers.cs.ucla.edu/fernando/projects/puzzles It is not graph-based, but if you want to use it, I would be happy to help you to install. It is working for LLVM 2.1. best, Fernando > Dear all, > I was looking for to compile some benchmarks and generate code using > different register allocation algorithms. As i can see, the built in > options for register allocation in llvm are > 1. Simple > 2. Local > 3. Linear Scan > > I want to compare the generating code also with a graph coloring based > register allocation approach. Is this also built in by default by > llvm. Are there some other projects, whose code i can borrow for this > task. > > To summarize: I want to compare the generated code of various > benchmarks (generated using linear scan based reg allocation vs graph > based register allocation). > > Any suggestions would be helpful. > > Regards > Prabhat > _______________________________________________ > 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 Mar 4 12:16:38 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 4 Mar 2008 10:16:38 -0800 (PST) Subject: [LLVMdev] Getting the Stack Pointer In-Reply-To: <200803041119.56466.dag@cray.com> References: <200803041119.56466.dag@cray.com> Message-ID: On Tue, 4 Mar 2008, David Greene wrote: > What's the "right" way to find out which machine register acts as the > stack pointer? I'm working on enhancing Fernando's register allocator > debugger and would like to add support for stack pointer semantics. > > TargetRegisterInfo has a getFrameRegister method but that returns > (on x86) either ESP/RSP or EBP/RBP depending on whether frame > pointer elimination has been done. > > Would it be ok to add a getStackPointerRegister method to TargetRegisterInfo? Why do you need to do this in a register allocator? Typically you want to refer to abstract frame indices. Wouldn't fernando's debugger use a similar representation? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From dag at cray.com Tue Mar 4 11:44:42 2008 From: dag at cray.com (David Greene) Date: Tue, 4 Mar 2008 11:44:42 -0600 Subject: [LLVMdev] Getting the Stack Pointer In-Reply-To: References: <200803041119.56466.dag@cray.com> Message-ID: <200803041144.42978.dag@cray.com> On Tuesday 04 March 2008 12:16, Chris Lattner wrote: > > Would it be ok to add a getStackPointerRegister method to > > TargetRegisterInfo? > > Why do you need to do this in a register allocator? Typically you want to > refer to abstract frame indices. Wouldn't fernando's debugger use a > similar representation? I don't need it in the allocator. I need it in Fernando's spiller that prints the IR used by the debugger. The IR includes references to the stack pointer. I need to add some sMira IR instructions at the top of the function to define the stack pointer (and other things) so it isn't flagged as undefined by the debugger. I suppose we could change Fernando's IR so it works with abstract stack indices but there are other times I've wanted to know the stack pointer as well, especially when dumping debug info. -Dave From idadesub at users.sourceforge.net Tue Mar 4 11:19:58 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Tue, 4 Mar 2008 09:19:58 -0800 Subject: [LLVMdev] [PATCH] Make sure ocamldep runs on all .mli files. In-Reply-To: <8F62301B-FC47-4A1A-91C1-214901A40BA6@mac.com> References: <1204612437-12156-1-git-send-email-idadesub@users.sourceforge.net> <8F62301B-FC47-4A1A-91C1-214901A40BA6@mac.com> Message-ID: <1ef034530803040919s1ae84bd0n233900b5440cb781@mail.gmail.com> On Tue, Mar 4, 2008 at 6:54 AM, Gordon Henriksen wrote: > Not sure how an .mli without a corresponding .ml would be useful, so I > left this bit. If you've got a module that only defines a type with no function definitions, you don't need the .ml file: foo.ml: let foo = Bar.A bar.mli: type t = A | B > ocamlc bar.mli > ocamlc foo.ml > In my eventual patch to switch over to using packed modules, I was thinking about making a TypeKind.mli that has just the type interface. However, I think I'd prefer to actually have this in the Type.ml{,i} files, but that would break source compatibility. From sabre at nondot.org Tue Mar 4 12:35:19 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 4 Mar 2008 10:35:19 -0800 (PST) Subject: [LLVMdev] Getting the Stack Pointer In-Reply-To: <200803041144.42978.dag@cray.com> References: <200803041119.56466.dag@cray.com> <200803041144.42978.dag@cray.com> Message-ID: On Tue, 4 Mar 2008, David Greene wrote: >> similar representation? > > I don't need it in the allocator. I need it in Fernando's spiller that prints > the IR used by the debugger. The IR includes references to the stack > pointer. I need to add some sMira IR instructions at the top of the function > to define the stack pointer (and other things) so it isn't flagged as > undefined by the debugger. It sounds like the debugger is operating at the wrong abstraction level here. If it's just the RA debugger, using frame indices makes the most sense. > I suppose we could change Fernando's IR so it works with abstract stack > indices but there are other times I've wanted to know the stack pointer as > well, especially when dumping debug info. I'm not sure what you mean here. If this is for debug dumps in the register allocator, dumping the stack pointer would be the *wrong* thing, because the frame indexes may end up being relative to the SP or the BP. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Tue Mar 4 13:17:11 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 4 Mar 2008 11:17:11 -0800 (PST) Subject: [LLVMdev] Tree Stability + Testing Message-ID: Hi Everyone, This is just a reminder to test patches before they go in. As the pace of development on LLVM is increasing, making sure your patch is solid is increasingly important. This is because every change has some inherent risk of breakage, and the more patches that go in, the higher the chance that the tree will be broken when the nightly testers run. Some guidelines: 0. Always build the tree before committing. 1. Always run make check at a minimum before checking in nontrivial patches (e.g. comment changes). 2. Almost all patches should run a subset of llvm-test to verify that they didn't break anything obvious. My personal favorite is MultiSource/Benchmarks, but any other reasonable subset is ok. 3. For major changes, please run a large subset of the test suite, such as all of MultiSource. 4. For particularly invasive or risky patches, please run the full llvm-test suite and verify no regressions before checking stuff in. There are exceptions to these rules of course: if your code is not run by default, or is only enabled in 'llc-beta' mode, you basically just need to make sure that the code builds and does not cause regressions in 'make check', regardless of how risky it is. The goal of the nightly tester is to find subtle/rare problems (the sort that cause 3-4 programs to fail in a nightly tester), or problems that you can't be reasonably expected to test (e.g. a problem that only manifests on darwin/ppc, but you're testing on itanium/linux). Think green, the tree appreciates it! :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From dberlin at dberlin.org Tue Mar 4 15:28:44 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Tue, 4 Mar 2008 16:28:44 -0500 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: <749b5dd60803030255k49411d02lfa927475c0aa0bf8@mail.gmail.com> References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> <4aca3dc20803022029i7034033dl295608bc2e707224@mail.gmail.com> <749b5dd60803030255k49411d02lfa927475c0aa0bf8@mail.gmail.com> Message-ID: <4aca3dc20803041328w718076b1hf7407505f95176c7@mail.gmail.com> On Mon, Mar 3, 2008 at 5:55 AM, Richard Warburton wrote: > > No > > I've got a BDD based version of andersen's around already (uncommitted). > > It's slower in time (by a factor of 8 or so), but very slightly (1-2 > > megabytes of memory) more memory efficient on some cases. Nowadays, > > the bitmap version is actually more memory efficient than the BDD > > version, even if you turn off BDD caching, etc. > > > > The thing you have to understand is that these context sensitive BDD > > algorithms work okay on java, but fall down pretty badly on C/C++, > > because it is a much bigger problem. Whaley's is just brute force, > > and Zhu's is pretty darn complex. > > I was interested to see whether Whaley's algorithm really works > particularly, given its simplicity and the claims made in the papers. Certainly, it works, and is not hard to implement. All you need to do is to add a context number to each constraint, and then you can clone them at every call and increment context number fairly easily. Storing constraint graphs in BDD's is also trivial (ben's source has a few solvers that do this, IIRC). > > > > Both are amenable to the same style of offline variable optimizations > > that Hardekopf, et al (Ben and a friend have been helping out with > > implementation of andersen's in LLVM), and that may actually make them > > usable for real world programs. > > Are you referring to both the PLDI and the SAS papers? Yes, as well as some other optimizations that have not been presented. > > > > > 4. Is anyone willing to mentor this project? > > I would. > > Thanks ;) > > > > I think you will be surprised how badly these algorithms work on even > > moderate sized C++ programs :( > > I'm slightly confused here as to whether you mean in terms of > precision of analysis, or compute time taken by running the algorithm. > Compute time. None of these algorithms are useful at all in the real world if it takes 3 years to compute the answer. Precision of them, is of course, great, assuming you use a sane heap model. --Dan From johnhull2008 at gmail.com Tue Mar 4 20:51:15 2008 From: johnhull2008 at gmail.com (john hull) Date: Tue, 4 Mar 2008 18:51:15 -0800 Subject: [LLVMdev] getAnalysis*() called on an analysis that was not " "'required' by pass! Message-ID: <16f40f0803041851r528c9c6bj8df19bd19fe41001@mail.gmail.com> Hello, I'd appreciate it if anyone can tell me what the error message means and point out what I am doing wrong. Thank you. I am trying to use the result of the DominatorTree analysis in my ModulePass class as explained in the section "Writing an LLVM Pass". http://llvm.org/docs/WritingAnLLVMPass.html#interaction I called the method "addRequired()" in the method "getAnalysisUsage(AnalysisUsage&)", but I get the following error message. opt: /usr/local/llvm/llvm/include/llvm/PassAnalysisSupport.h:193: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = llvm::DominatorTree]: Assertion `ResultPass && "getAnalysis*() called on an analysis that was not " "'required' by pass!"' failed. The following is the command I typed in: opt -load /usr/local/llvm/install/lib/mymodulepass.so -mymodulepass /dev/null Here are the header and implementation files of my class with just the bare minimum that produces the error messages. (MyModulePass.h) #ifndef MYMODULEPASS_H #define MYMODULEPASS_H #include "llvm/Pass.h" namespace llvm { class MyModulePass : public ModulePass { public: static char ID; // Pass identification, replacement for typeid MyModulePass(); virtual bool runOnModule(Module &M); virtual void getAnalysisUsage(AnalysisUsage &Info) const; }; extern RegisterPass X_MyModulePass; } #endif (MyModulePass.cpp) #include #include "MyModulePass.h" #include "llvm/Module.h" #include "llvm/Function.h" #include "llvm/BasicBlock.h" #include "llvm/Analysis/Dominators.h" #include "llvm/Analysis/AliasAnalysis.h" using namespace llvm; // ID, register char llvm::MyModulePass::ID = 0; RegisterPass llvm::X_MyModulePass("mymodulepass", "My Module Pass"); MyModulePass::MyModulePass() : ModulePass((intptr_t)&MyModulePass::ID) { } bool MyModulePass::runOnModule(Module &m) { for (Module::const_iterator f = m.begin(); f != m.end(); ++f) DominatorTree &dt = getAnalysis(); return false; } void MyModulePass::getAnalysisUsage(AnalysisUsage &info) const { info.addRequired(); } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080304/e9aab97a/attachment.html From idadesub at users.sourceforge.net Tue Mar 4 21:52:57 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Tue, 4 Mar 2008 19:52:57 -0800 Subject: [LLVMdev] new patch without brackets In-Reply-To: <872FECF0-E057-4E98-9C48-89EA8EF33EA7@mac.com> References: <872FECF0-E057-4E98-9C48-89EA8EF33EA7@mac.com> Message-ID: <1204689178-13481-1-git-send-email-idadesub@users.sourceforge.net> Thanks Gordon. This patch should make the changes you requested. From idadesub at users.sourceforge.net Tue Mar 4 21:52:58 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Tue, 4 Mar 2008 19:52:58 -0800 Subject: [LLVMdev] [PATCH] Cleanup the c and ocaml binding documentation. In-Reply-To: <1204689178-13481-1-git-send-email-idadesub@users.sourceforge.net> References: <872FECF0-E057-4E98-9C48-89EA8EF33EA7@mac.com> <1204689178-13481-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: <1204689178-13481-2-git-send-email-idadesub@users.sourceforge.net> --- bindings/ocaml/llvm/llvm.ml | 2 +- bindings/ocaml/llvm/llvm.mli | 2 +- bindings/ocaml/llvm/llvm_ocaml.c | 2 +- include/llvm-c/Core.h | 20 +++++++++++++------- 4 files changed, 16 insertions(+), 10 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 2a33a0870af02af3d1b3bd767b36637f434615a2.diff Type: text/x-patch Size: 3613 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080304/f4105ddd/attachment.bin From gordonhenriksen at mac.com Wed Mar 5 00:11:30 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Wed, 5 Mar 2008 01:11:30 -0500 Subject: [LLVMdev] new patch without brackets In-Reply-To: <1204689178-13481-1-git-send-email-idadesub@users.sourceforge.net> References: <872FECF0-E057-4E98-9C48-89EA8EF33EA7@mac.com> <1204689178-13481-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: <8E3EA324-8263-4AE3-9D2C-C5E2E260E409@mac.com> On Mar 4, 2008, at 22:52, Erick Tryzelaar wrote: > Thanks Gordon. This patch should make the changes you requested. Please submit your patches as attachments; these fail to apply. ? Gordon From idadesub at users.sourceforge.net Wed Mar 5 00:49:03 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Tue, 4 Mar 2008 22:49:03 -0800 Subject: [LLVMdev] new patch without brackets In-Reply-To: <8E3EA324-8263-4AE3-9D2C-C5E2E260E409@mac.com> References: <872FECF0-E057-4E98-9C48-89EA8EF33EA7@mac.com> <1204689178-13481-1-git-send-email-idadesub@users.sourceforge.net> <8E3EA324-8263-4AE3-9D2C-C5E2E260E409@mac.com> Message-ID: <1ef034530803042249t52513846o66ecc17b48e09934@mail.gmail.com> On Tue, Mar 4, 2008 at 10:11 PM, Gordon Henriksen wrote: > Please submit your patches as attachments; these fail to apply. How odd. I was able to apply the patch I sent you using just "patch -p0 < 2a33a0870af02af3d1b3bd767b36637f434615a2.diff" after downloading the patch I sent from the list. I did attach it using the "inline" Content-Disposition option though, which lets some browsers display the patch. I can in the future use "attach" (which I did with this mail). Or if you'd prefer me to just apply the patch against subversion and send the subversion patch, I can do that too (which I also did with this patch). I'm sorry for causing problems. -e -------------- next part -------------- A non-text attachment was scrubbed... Name: 2a33a0870af02af3d1b3bd767b36637f434615a2.diff Type: application/octet-stream Size: 3612 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080304/87e7742d/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-from-svn.diff Type: application/octet-stream Size: 3651 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080304/87e7742d/attachment-0003.obj From idadesub at users.sourceforge.net Wed Mar 5 01:05:41 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Tue, 4 Mar 2008 23:05:41 -0800 Subject: [LLVMdev] [PATCH] Prefer to use *.opt ocaml executables as they are more efficient. In-Reply-To: <7B98597D-8772-4D07-9A6A-BF39E23BB78D@mac.co> References: <7B98597D-8772-4D07-9A6A-BF39E23BB78D@mac.co> Message-ID: <1204700741-13946-1-git-send-email-idadesub@users.sourceforge.net> Hello Gordon, This is another attempt to use the .opt ocaml executables. I've attached these instead of inlining them, so hopefully they won't give you problems applying them. Please let me know if it's still not working, then I'll just do this the old fashioned way. - Erick --- autoconf/configure.ac | 6 ++-- configure | 81 +++++++++++++++++++++++++++++-------------------- 2 files changed, 51 insertions(+), 36 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 9b5616832645f511a81ba69d0c7225e0f4ddbaae.diff Type: text/x-patch Size: 10794 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080304/1de55fda/attachment.bin From wmatyjewicz at fastmail.fm Wed Mar 5 01:34:21 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Wed, 05 Mar 2008 08:34:21 +0100 Subject: [LLVMdev] getAnalysis*() called on an analysis that was not " "'required' by pass! In-Reply-To: <16f40f0803041851r528c9c6bj8df19bd19fe41001@mail.gmail.com> References: <16f40f0803041851r528c9c6bj8df19bd19fe41001@mail.gmail.com> Message-ID: <47CE4CFD.7000509@fastmail.fm> Hi, > bool MyModulePass::runOnModule(Module &m) { > for (Module::const_iterator f = m.begin(); f != m.end(); ++f) > DominatorTree &dt = getAnalysis(); > > return false; > } DominatorTree is a function-level analysis, while your pass is a module-level one. It means you have to point the function you want the analysis result for. Try using: getAnalysis(*f); (It would probably require changing const_iterator to iterator) Getting analysis result is valid only for function definitions, not declarations. Hence, it is necessary to check f->isDeclaration() before calling getAnalysis(). Wojtek From xi.wang at gmail.com Wed Mar 5 02:44:06 2008 From: xi.wang at gmail.com (Xi Wang) Date: Wed, 5 Mar 2008 16:44:06 +0800 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: <749b5dd60803030255k49411d02lfa927475c0aa0bf8@mail.gmail.com> References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> <4aca3dc20803022029i7034033dl295608bc2e707224@mail.gmail.com> <749b5dd60803030255k49411d02lfa927475c0aa0bf8@mail.gmail.com> Message-ID: On Mon, Mar 3, 2008 at 6:55 PM, Richard Warburton wrote: > > No > > I've got a BDD based version of andersen's around already (uncommitted). > > It's slower in time (by a factor of 8 or so), but very slightly (1-2 > > megabytes of memory) more memory efficient on some cases. Nowadays, > > the bitmap version is actually more memory efficient than the BDD > > version, even if you turn off BDD caching, etc. > > > > The thing you have to understand is that these context sensitive BDD > > algorithms work okay on java, but fall down pretty badly on C/C++, > > because it is a much bigger problem. Whaley's is just brute force, > > and Zhu's is pretty darn complex. > > I was interested to see whether Whaley's algorithm really works > particularly, given its simplicity and the claims made in the papers. I have implemented a tool based on the Phoenix compiler framework at MSR, which can dump relations as BDD from C/C++ code and feed them into John Whaley's bddbddb for further analysis. As Dan said, currently the performance is not good enough for C/C++ code (due to more complex relations, BDD variable orders, etc.). I am still trying several optimizations. John also told that it took quite a lot of effort to get the Java version to scale. I am interested to see an implementation based on LLVM. Xi From vvaditya12 at yahoo.com Wed Mar 5 09:17:02 2008 From: vvaditya12 at yahoo.com (aditya vishnubhotla) Date: Wed, 5 Mar 2008 07:17:02 -0800 (PST) Subject: [LLVMdev] Deleting Instructions after Intrinsic Creation In-Reply-To: <619441.44188.qm@web56004.mail.re3.yahoo.com> Message-ID: <568280.15874.qm@web56014.mail.re3.yahoo.com> Hi, The problem is solved. Thank You Aditya ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From scottm at aero.org Wed Mar 5 11:21:20 2008 From: scottm at aero.org (Scott Michel) Date: Wed, 5 Mar 2008 09:21:20 -0800 Subject: [LLVMdev] llvm-gcc 4.2 building failed on x86-64 In-Reply-To: <200803041139.12304.st@iss.tu-darmstadt.de> References: <8abe0dc60803040124y5d0308eft5b60bc1c06f68823@mail.gmail.com> <200803041139.12304.st@iss.tu-darmstadt.de> Message-ID: <83D248DC-1DB3-4121-8E3B-4073D3DD8E37@aero.org> On Mar 4, 2008, at 2:39 AM, ST wrote: > Hi Sheng > Am Dienstag, 4. M?rz 2008 schrieb Zhou Sheng: >> Current llvm-gcc 4.2 building failed on X86-64, here is the dump > I am not followng head closely but may it be that the current head > still > doesn't support amd64 proper: > > gcc README.LLVM: > "When targeting non-darwin X86-64/AMD-64/EM64-T, configure with > --disable-shared. The LLVM X86-64 backend doesn't support PIC > codegen on > non-darwin systems yet. If you get a build error, try configuring > with > --disable-multilib." I encountered this bug intermittently using llvm Release, but cannot reproduce it when using llvm Debug. But the failure occurs inside of llvm. Consequently, your suggestion won't work. Also, the build is broken on x86_64 because somehow references to alloca() turned into an unresolved extern. -scooter From tilmann.scheller at googlemail.com Wed Mar 5 12:03:43 2008 From: tilmann.scheller at googlemail.com (Tilmann Scheller) Date: Wed, 5 Mar 2008 19:03:43 +0100 Subject: [LLVMdev] Any idea on translate x86 assembly to LLVM IR? Message-ID: >* I'am now considering converting x86 machine assembly into LLVM *>* IR, does anyone know about any existing project or resource *>* related to this area? Any difficulities or any ideas on this? * During Google Summer of Code 2007 I was working on llvm-qemu, which translates from ARM machine code to LLVM IR (at basic block level) and via the LLVM JIT to x86 machine code. All source architectures supported by qemu (x86, x86-64, ARM, SPARC, PowerPC, MIPS, m68k) can be translated to LLVM IR this way (e.g. adding support for x86 to llvm-qemu should be almost trivial). You can find llvm-qemu at http://code.google.com/p/llvm-qemu/ Greetings, Tilmann Scheller -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080305/13d1a0f7/attachment.html From dberlin at dberlin.org Wed Mar 5 13:27:37 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 5 Mar 2008 14:27:37 -0500 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> <4aca3dc20803022029i7034033dl295608bc2e707224@mail.gmail.com> <749b5dd60803030255k49411d02lfa927475c0aa0bf8@mail.gmail.com> Message-ID: <4aca3dc20803051127h7b260a96g443d6d34507f6e2c@mail.gmail.com> On Wed, Mar 5, 2008 at 3:44 AM, Xi Wang wrote: > On Mon, Mar 3, 2008 at 6:55 PM, Richard Warburton > > wrote: > > > > No > > > I've got a BDD based version of andersen's around already (uncommitted). > > > It's slower in time (by a factor of 8 or so), but very slightly (1-2 > > > megabytes of memory) more memory efficient on some cases. Nowadays, > > > the bitmap version is actually more memory efficient than the BDD > > > version, even if you turn off BDD caching, etc. > > > > > > The thing you have to understand is that these context sensitive BDD > > > algorithms work okay on java, but fall down pretty badly on C/C++, > > > because it is a much bigger problem. Whaley's is just brute force, > > > and Zhu's is pretty darn complex. > > > > I was interested to see whether Whaley's algorithm really works > > particularly, given its simplicity and the claims made in the papers. > > I have implemented a tool based on the Phoenix compiler framework at > MSR, which can dump relations as BDD from C/C++ code and feed them > into John Whaley's bddbddb for further analysis. As Dan said, > currently the performance is not good enough for C/C++ code (due to > more complex relations, BDD variable orders, etc.). I am still trying > several optimizations. John also told that it took quite a lot of > effort to get the Java version to scale. My guess is that if you try doing variable substitution style optimizations, you will get very very serious speedups. Usually, out of 80-100k constraint variables, you can unify 60k of them. In my testing, it reduces the number of constraint variables by 80+% in non-context sensitive analysis. bddbddb is already going to be rather good at solving the query relations, so to get faster, you have to start reducing the size of the problem itself. From jo at durchholz.org Wed Mar 5 13:33:38 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 05 Mar 2008 20:33:38 +0100 Subject: [LLVMdev] Error messages in llvm-test Message-ID: <1204745618.7307.152.camel@kurier> Hi all, llvm-test fails on me in the first test (and many subsequent tests, but I hope that fixing the first test will allow me to continue). I see syntax errors from the C compiler and core dumps from llc. Is any of this supposed to happen? This is still on my amd64 machine. However, the build process is using the right incantation to compile (gcc-4.2 -m32 -Wl,-melf_i386). The llvm-gcc toolchain installed is the precompiled 2.2 Red Hat package for Linux. See below for the error messages, and further below for the source lines mentioned in the messages. Should I worry about these messages? I haven't tested actually using LLVM yet, and I may be barking up the wrong tree. (Having a clean test suite *would* make me feel more confident, of course.) Regards, Jo --- snip --- Transcript for $ cd llvm/projects/llvm-test $ export LANG=C $ make I'm giving a little bit more context than announced above. make[1]: Entering directory `/home/jo/Delta/llvm/projects/llvm-test/SingleSource' make[2]: Entering directory `/home/jo/Delta/llvm/projects/llvm-test/SingleSource/UnitTests' make[3]: Entering directory `/home/jo/Delta/llvm/projects/llvm-test/SingleSource/UnitTests/Vector' /home/jo/Delta/llvm/Release/bin/llc -march=c Output/build.llvm.bc -o Output/build.cbe.c -f C Writer does not know about %tmp12 = insertelement <4 x float> % tmp11, float %X.0, i32 1 ; <<4 x float>> [#uses=2] /home/jo/Delta/llvm/Release/bin/llc[0x878d8dc] [0x6] /lib32/libc.so.6(abort+0x101)[0x556f24b1] /home/jo/Delta/llvm/Release/bin/llc[0x812a0f8] make[3]: *** [Output/build.cbe.c] Aborted (core dumped) gcc-4.2 -m32 Output/build.cbe.c -o Output/build.cbe -Wl,-melf_i386 -Wl,-melf_i386 -O3 -fno-strict-aliasing -fno-inline gcc-4.2: Output/build.cbe.c: No such file or directory make[3]: [Output/build.cbe] Error 1 (ignored) gcc-4.2 -m32 Output/build2.cbe.c -o Output/build2.cbe -Wl,-melf_i386 -Wl,-melf_i386 -O3 -fno-strict-aliasing -fno-inline Output/build2.cbe.c:113: warning: conflicting types for built-in function 'malloc' Output/build2.cbe.c: In function 'main': Output/build2.cbe.c:181: error: expected expression before '{' token Output/build2.cbe.c:182: error: expected expression before '{' token Output/build2.cbe.c:183: error: expected expression before '{' token Output/build2.cbe.c:191: error: expected expression before '{' token Output/build2.cbe.c:192: error: expected expression before '{' token Output/build2.cbe.c:193: error: expected expression before '{' token Output/build2.cbe.c:208: error: incompatible types in assignment Output/build2.cbe.c:209: error: incompatible types in assignment Output/build2.cbe.c:210: error: incompatible types in assignment Output/build2.cbe.c:211: error: expected expression before '{' token Output/build2.cbe.c:211: error: expected expression before '{' token Output/build2.cbe.c:211: error: expected expression before '{' token Output/build2.cbe.c:211: error: expected expression before '{' token Output/build2.cbe.c:212: error: expected expression before '{' token Output/build2.cbe.c:212: error: expected expression before '{' token Output/build2.cbe.c:212: error: expected expression before '{' token Output/build2.cbe.c:212: error: expected expression before '{' token Output/build2.cbe.c:212: error: expected expression before '{' token Output/build2.cbe.c:212: error: expected expression before '{' token Output/build2.cbe.c:213: error: expected expression before '{' token Output/build2.cbe.c:213: error: expected expression before '{' token Output/build2.cbe.c:213: error: expected expression before '{' token Output/build2.cbe.c:213: error: expected expression before '{' token Output/build2.cbe.c:219: error: incompatible types in assignment Output/build2.cbe.c:220: error: incompatible types in assignment Output/build2.cbe.c:221: error: incompatible types in assignment Output/build2.cbe.c:228: error: incompatible types in assignment Output/build2.cbe.c:229: error: incompatible types in assignment Output/build2.cbe.c:230: error: incompatible types in assignment Output/build2.cbe.c:142: warning: return type of 'main' is not 'int' make[3]: [Output/build2.cbe] Error 1 (ignored) /home/jo/Delta/llvm/Release/bin/llc -march=c Output/divides.llvm.bc -o Output/divides.cbe.c -f llc: CBackend.cpp:400: std::ostream&::CWriter::printSimpleType(std::ostream&, const llvm::Type*, bool, const std::string&): Assertion `(Ty->isPrimitiveType() || Ty->isInteger()) && "Invalid t ype for printSimpleType"' failed. /home/jo/Delta/llvm/Release/bin/llc[0x878d8dc] [0x6] /lib32/libc.so.6(abort+0x101)[0x556f24b1] /lib32/libc.so.6(__assert_fail+0xee)[0x556e9bbe] /home/jo/Delta/llvm/Release/bin/llc[0x811c697] make[3]: *** [Output/divides.cbe.c] Aborted (core dumped) gcc-4.2 -m32 Output/divides.cbe.c -o Output/divides.cbe -Wl,-melf_i386 -Wl,-melf_i386 -O3 -fno-strict-aliasing -fno-inline gcc-4.2: Output/divides.cbe.c: No such file or directory make[3]: [Output/divides.cbe] Error 1 (ignored) gcc-4.2 -m32 Output/multiplies.cbe.c -o Output/multiplies.cbe -Wl,-melf_i386 -Wl,-melf_i386 -O3 -fno-strict-aliasing -fno-inline Output/multiplies.cbe.c:124: warning: conflicting types for built-in function 'malloc' Output/multiplies.cbe.c: In function 'main': Output/multiplies.cbe.c:247: error: expected expression before '{' token Output/multiplies.cbe.c:258: error: incompatible types in assignment Output/multiplies.cbe.c:260: error: incompatible types in assignment Output/multiplies.cbe.c:269: error: incompatible types in assignment Output/multiplies.cbe.c:276: error: incompatible types in assignment Output/multiplies.cbe.c:277: error: incompatible types in assignment Output/multiplies.cbe.c:278: error: invalid operands to binary * Output/multiplies.cbe.c:284: error: incompatible types in assignment Output/multiplies.cbe.c:291: error: cast specifies array type Output/multiplies.cbe.c:299: error: expected expression before '{' token Output/multiplies.cbe.c:305: error: incompatible types in assignment Output/multiplies.cbe.c:307: error: incompatible types in assignment Output/multiplies.cbe.c:316: error: incompatible types in assignment Output/multiplies.cbe.c:323: error: incompatible types in assignment Output/multiplies.cbe.c:324: error: incompatible types in assignment Output/multiplies.cbe.c:325: error: invalid operands to binary * Output/multiplies.cbe.c:331: error: incompatible types in assignment Output/multiplies.cbe.c:338: error: cast specifies array type Output/multiplies.cbe.c:346: error: expected expression before '{' token Output/multiplies.cbe.c:352: error: incompatible types in assignment Output/multiplies.cbe.c:354: error: incompatible types in assignment Output/multiplies.cbe.c:363: error: incompatible types in assignment Output/multiplies.cbe.c:370: error: incompatible types in assignment Output/multiplies.cbe.c:371: error: incompatible types in assignment Output/multiplies.cbe.c:372: error: invalid operands to binary * Output/multiplies.cbe.c:378: error: incompatible types in assignment Output/multiplies.cbe.c:385: error: incompatible types in assignment Output/multiplies.cbe.c:393: error: expected expression before '{' token Output/multiplies.cbe.c:399: error: incompatible types in assignment Output/multiplies.cbe.c:401: error: incompatible types in assignment Output/multiplies.cbe.c:410: error: incompatible types in assignment Output/multiplies.cbe.c:417: error: incompatible types in assignment Output/multiplies.cbe.c:418: error: incompatible types in assignment Output/multiplies.cbe.c:419: error: invalid operands to binary * Output/multiplies.cbe.c:425: error: incompatible types in assignment Output/multiplies.cbe.c:432: error: incompatible types in assignment Output/multiplies.cbe.c:155: warning: return type of 'main' is not 'int' make[3]: [Output/multiplies.cbe] Error 1 (ignored) /home/jo/Delta/llvm/Release/bin/llc -march=c Output/simple.llvm.bc -o Output/simple.cbe.c -f C Writer does not know about %tmp35 = insertelement <4 x float> % tmp34, float %X.0, i32 1 ; <<4 x float>> [#uses=3] /home/jo/Delta/llvm/Release/bin/llc[0x878d8dc] [0x6] /lib32/libc.so.6(abort+0x101)[0x556f24b1] /home/jo/Delta/llvm/Release/bin/llc[0x812a0f8] make[3]: *** [Output/simple.cbe.c] Aborted (core dumped) gcc-4.2 -m32 Output/simple.cbe.c -o Output/simple.cbe -Wl,-melf_i386 -Wl,-melf_i386 -O3 -fno-strict-aliasing -fno-inline gcc-4.2: Output/simple.cbe.c: No such file or directory make[3]: [Output/simple.cbe] Error 1 (ignored) gcc-4.2 -m32 Output/sumarray-dbl.cbe.c -o Output/sumarray-dbl.cbe -Wl,-melf_i386 -Wl,-melf_i386 -O3 -fno-strict-aliasing -fno-inline Output/sumarray-dbl.cbe.c:130: warning: conflicting types for built-in function 'malloc' Output/sumarray-dbl.cbe.c: In function 'main': Output/sumarray-dbl.cbe.c:195: error: expected expression before '{' token Output/sumarray-dbl.cbe.c:206: error: incompatible types in assignment Output/sumarray-dbl.cbe.c:207: error: incompatible types in assignment Output/sumarray-dbl.cbe.c:208: error: invalid operands to binary + Output/sumarray-dbl.cbe.c:214: error: incompatible types in assignment Output/sumarray-dbl.cbe.c:220: error: incompatible types in assignment Output/sumarray-dbl.cbe.c:161: warning: return type of 'main' is not 'int' make[3]: [Output/sumarray-dbl.cbe] Error 1 (ignored) gcc-4.2 -m32 Output/sumarray.cbe.c -o Output/sumarray.cbe -Wl,-melf_i386 -Wl,-melf_i386 -O3 -fno-strict-aliasing -fno-inline Output/sumarray.cbe.c:130: warning: conflicting types for built-in function 'malloc' Output/sumarray.cbe.c: In function 'main': Output/sumarray.cbe.c:191: error: expected expression before '{' token Output/sumarray.cbe.c:202: error: incompatible types in assignment Output/sumarray.cbe.c:203: error: incompatible types in assignment Output/sumarray.cbe.c:204: error: invalid operands to binary + Output/sumarray.cbe.c:210: error: incompatible types in assignment Output/sumarray.cbe.c:216: error: incompatible types in assignment Output/sumarray.cbe.c:161: warning: return type of 'main' is not 'int' make[3]: [Output/sumarray.cbe] Error 1 (ignored) /home/jo/Delta/llvm/projects/llvm-test/RunSafely.sh 500 0 /dev/null Output/multiplies.out-llc Output/multiplies.llc /home/jo/Delta/llvm/projects/llvm-test/DiffOutput.sh "/home/jo/Delta/llvm/Release/bin/fpcmp " llc multiplies gcc-4.2 -m32 Output/simple.llc.s -o Output/simple.llc -lm -Wl,-melf_i386 -Wl,-melf_i386 /home/jo/Delta/llvm/projects/llvm-test/RunSafely.sh 500 0 /dev/null Output/simple.out-llc Output/simple.llc /home/jo/Delta/llvm/projects/llvm-test/DiffOutput.sh "/home/jo/Delta/llvm/Release/bin/fpcmp " llc simple gcc-4.2 -m32 Output/sumarray-dbl.llc.s -o Output/sumarray-dbl.llc -lm -Wl,-melf_i386 -Wl,-melf_i386 /home/jo/Delta/llvm/projects/llvm-test/RunSafely.sh 500 0 /dev/null Output/sumarray-dbl.out-llc Output/sumarray-dbl.llc /home/jo/Delta/llvm/projects/llvm-test/DiffOutput.sh "/home/jo/Delta/llvm/Release/bin/fpcmp " llc sumarray-dbl gcc-4.2 -m32 Output/sumarray.llc.s -o Output/sumarray.llc -lm -Wl,-melf_i386 -Wl,-melf_i386 /home/jo/Delta/llvm/projects/llvm-test/RunSafely.sh 500 0 /dev/null Output/sumarray.out-llc Output/sumarray.llc /home/jo/Delta/llvm/projects/llvm-test/DiffOutput.sh "/home/jo/Delta/llvm/Release/bin/fpcmp " llc sumarray /home/jo/Delta/llvm/projects/llvm-test/RunSafely.sh 500 0 /dev/null Output/build.out-cbe Output/build.cbe /home/jo/Delta/llvm/projects/llvm-test/DiffOutput.sh "/home/jo/Delta/llvm/Release/bin/fpcmp " cbe build ******************** TEST (cbe) 'build' FAILED! ******************** Execution Context Diff: /home/jo/Delta/llvm/Release/bin/fpcmp: FP Comparison failed, not a numeric difference between '1' and 's' ******************** TEST (cbe) 'build' **************************** /home/jo/Delta/llvm/projects/llvm-test/RunSafely.sh 500 0 /dev/null Output/build2.out-cbe Output/build2.cbe /home/jo/Delta/llvm/projects/llvm-test/DiffOutput.sh "/home/jo/Delta/llvm/Release/bin/fpcmp " cbe build2 ******************** TEST (cbe) 'build2' FAILED! ******************** Execution Context Diff: /home/jo/Delta/llvm/Release/bin/fpcmp: FP Comparison failed, not a numeric difference between '2' and 's' ******************** TEST (cbe) 'build2' **************************** /home/jo/Delta/llvm/projects/llvm-test/RunSafely.sh 500 0 /dev/null Output/divides.out-cbe Output/divides.cbe /home/jo/Delta/llvm/projects/llvm-test/DiffOutput.sh "/home/jo/Delta/llvm/Release/bin/fpcmp " cbe divides ******************** TEST (cbe) 'divides' FAILED! ******************** Execution Context Diff: /home/jo/Delta/llvm/Release/bin/fpcmp: FP Comparison failed, not a numeric difference between 'U' and 's' ******************** TEST (cbe) 'divides' **************************** --- snip --- The lines that generate the errors are these: 142 unsigned int main(unsigned int llvm_cbe_argc, unsigned char **llvm_cbe_argv) { 181 *(&llvm_cbe_x) = { 0x0p+0, 0x0p+0, 0x0p+0, 0x0p+0 }; 182 *(&llvm_cbe_y) = { 0x0p+0, 0x0p+0, 0x0p+0, 0x0p+0 }; 183 *(&llvm_cbe_z) = { 0x0p+0, 0x0p+0, 0x0p+0, 0x0p+0 }; 191 llvm_cbe_z_tmp_0__PHI_TEMPORARY = { 0x0p+0, 0x0p+0, 0x0p+0, 0x0p+0 }; /* for PHI node */ 192 llvm_cbe_y_tmp_0__PHI_TEMPORARY = { 0x0p+0, 0x0p+0, 0x0p+0, 0x0p+0 }; /* for PHI node */ 193 llvm_cbe_x_tmp_0__PHI_TEMPORARY = { 0x0p+0, 0x0p+0, 0x0p+0, 0x0p+0 }; /* for PHI node */ 208 llvm_cbe_z_tmp_0 = llvm_cbe_z_tmp_0__PHI_TEMPORARY; 209 llvm_cbe_y_tmp_0 = llvm_cbe_y_tmp_0__PHI_TEMPORARY; 210 llvm_cbe_x_tmp_0 = llvm_cbe_x_tmp_0__PHI_TEMPORARY; 211 llvm_cbe_tmp19 = (((llvm_cbe_x_tmp_0 + { 0x1p+0, 0x0p+0, 0x0p+0, 0x0p+0 }) + { 0x0p+0, 0x1p+0, 0x0p+0, 0x0p+0 }) + { 0x0p+0, 0x0p+0, 0x1p+0, 0x0p+0 }) + { 0x0p+0, 0x0p+0, 0x0p+0, 0x1p+0 }; 212 llvm_cbe_tmp37 = (((((llvm_cbe_y_tmp_0 + { 0x1p+0, 0x1p+1, 0x0p+0, 0x0p+0 }) + { 0x1p+0, 0x0p+0, 0x1p+1, 0x0p+0 }) + { 0x1p+0, 0x0p+0, 0x0p+0, 0x1p+1 }) + { 0x0p+0, 0x1p+0, 0x1p+1, 0x0p+0 }) + { 0x0p+0, 0x1p+0, 0x0p+0, 0x1p+1 }) + { 0x0p+0, 0x0p+0, 0x1p+0, 0x1p+1 }; 213 llvm_cbe_tmp49 = (((llvm_cbe_z_tmp_0 + { 0x1p+1, 0x1.8p+1, 0x1p+0, 0x0p+0 }) + { 0x1p+0, 0x1p+0, 0x0p+0, 0x1p+1 }) + { 0x1.8p+1, 0x0p+0, 0x1p+1, 0x1p+2 }) + { 0x0p+0, 0x1p+2, 0x1.8p+2, 0x1p+0 }; 219 llvm_cbe_z_tmp_0__PHI_TEMPORARY = llvm_cbe_tmp49; /* for PHI node */ 220 llvm_cbe_y_tmp_0__PHI_TEMPORARY = llvm_cbe_tmp37; /* for PHI node */ 221 llvm_cbe_x_tmp_0__PHI_TEMPORARY = llvm_cbe_tmp19; /* for PHI node */ 228 *(&llvm_cbe_x) = llvm_cbe_tmp19; 229 *(&llvm_cbe_y) = llvm_cbe_tmp37; 230 *(&llvm_cbe_z) = llvm_cbe_tmp49; From bagel99 at gmail.com Wed Mar 5 14:38:09 2008 From: bagel99 at gmail.com (Bagel) Date: Wed, 05 Mar 2008 14:38:09 -0600 Subject: [LLVMdev] removing unnecessary moves with 2-address machine Message-ID: <47CF04B1.5090007@gmail.com> I am new to LLVM and am trying to write a backend for a simple 2-address machine. For a very simple program: define i16 @add2aa(i16 %a, i16 %b) nounwind { entry: %tmp3 = add i16 %b, %a ; [#uses=1] ret i16 %tmp3 } The arguments a and b are passed in r15 and r14. The result is returned in r15. The generated code is: add2aa: add.w r15,r14 mov.w r14,r15 ret If the legs of the add.w were reversed, the mov.w would not be necessary. I have declared the add instruction to be "commutable". What do I have to do to cause the optimization? thanks, bagel From sabre at nondot.org Wed Mar 5 16:04:08 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 5 Mar 2008 14:04:08 -0800 (PST) Subject: [LLVMdev] removing unnecessary moves with 2-address machine In-Reply-To: <47CF04B1.5090007@gmail.com> References: <47CF04B1.5090007@gmail.com> Message-ID: On Wed, 5 Mar 2008, Bagel wrote: > If the legs of the add.w were reversed, the mov.w would not be > necessary. I have declared the add instruction to be "commutable". > What do I have to do to cause the optimization? Marking it commutable and describing the move as a copy instruction should be enough. Are you using llvm mainline or 2.2? Evan implemented this in mainline after 2.2 was released. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From bagel99 at gmail.com Wed Mar 5 15:34:29 2008 From: bagel99 at gmail.com (Bagel) Date: Wed, 05 Mar 2008 15:34:29 -0600 Subject: [LLVMdev] removing unnecessary moves with 2-address machine References: 47CF04B1.5090007@gmail.com Message-ID: <47CF11E5.7010408@gmail.com> I'm using released 2.2. I guess I need to check out the svn trunk to get this enhancement. bagel From johnhull2008 at gmail.com Wed Mar 5 17:07:52 2008 From: johnhull2008 at gmail.com (john hull) Date: Wed, 5 Mar 2008 15:07:52 -0800 Subject: [LLVMdev] getAnalysis*() called on an analysis that was not " "'required' by pass! Message-ID: <16f40f0803051507u7622dd7anf7e1dff84bdbb336@mail.gmail.com> Thanks. Calling getAnalysis with a Function* argument and removing const from iterator solved the problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080305/faff1821/attachment.html From idadesub at users.sourceforge.net Wed Mar 5 19:08:27 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Wed, 5 Mar 2008 17:08:27 -0800 Subject: [LLVMdev] [PATCH] Prefer to use *.opt ocaml executables as they are more efficient. In-Reply-To: <1204700741-13946-1-git-send-email-idadesub@users.sourceforge.net> References: <1204700741-13946-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: <1204765707-18086-1-git-send-email-idadesub@users.sourceforge.net> Hello again, This just brings the patch up to HEAD. -e --- autoconf/configure.ac | 6 ++-- configure | 75 +++++++++++++++++++++++++++++------------------- 2 files changed, 48 insertions(+), 33 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 3201d364fd9d5de011a1b0f5c01a52c5ef958224.diff Type: text/x-patch Size: 9793 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080305/9971e940/attachment.bin From sabre at nondot.org Thu Mar 6 00:57:36 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 5 Mar 2008 22:57:36 -0800 Subject: [LLVMdev] Cloning a function In-Reply-To: <200803030821.05408.zack@tungstengraphics.com> References: <200803030821.05408.zack@tungstengraphics.com> Message-ID: On Mar 3, 2008, at 5:21 AM, Zack Rusin wrote: Hey Zack! > we have two modules, one that we basically use as a library in which > we store > a lot of simple function calls, the other is small program generated > at > run-time. Ok. > Whenever a function call for to one of the builtin functions is > being called > we use CloneFunction to clone the instruction from the library > module and > insert it in the generated module. Ok. You might also be interested in doing this in terms of inlining. In particular, if you're doing code specialization, the CloneAndPruneFunctionInto method is much faster than doing cloning + inlining + dead code elimination, at least for cases where specialization leads to lots of dead code. > The problem is for example when we have something like: > declare float @powf(float, float) > define void @pow(<4 x float>* %res, /*other args*/...) { > entry: > ... > %call = tail call float @powf( float %tmp1, float %tmp3 ) > ... > } > while powf has a similar extern declaration in the generated module, > the > cloned function after the CloneFunction call obviously refers to the > powf > from the library module and asserts as an invalid module. To solve > that we > add a mapping to DenseMap from the powf declaration in the library > module to > the powf declaration in the generated module, as in: > > DenseMap val; > val[m_builtins->getFunction("powf")] = currentModule()- > >getFunction("powf"); > func = CloneFunction(originalFunc, val); > currentModule()->getFunctionList().push_back(func); Ok. > unfortunately after this we get an assert: > vp-tris: /home/zack/projects/general/llvm/lib/Target/X86/ > X86CodeEmitter.cpp:412: > unsigned int sizeOfImm(const llvm::TargetInstrDesc*): Assertion `0 > && "Immediate size not set!"' failed. > > which I'm a little confused about. Any idea what might be causing > this and how > to fix it? This is very strange, and I'm not sure that one follows from the other. Are you running the verifier on the module/function after the IR modifications but before the code generator? Another approach that might be simpler: instead of juggling two modules, you might consider just loading the one module (lazily) from disk, and doing your codegen in that module. This means that you can directly reference globals and copy code around with no problem. As long as you use cloning/inlining to copy code into the newly generated functions before you hack on them, there should be no problem. -Chris From sabre at nondot.org Thu Mar 6 01:03:55 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 5 Mar 2008 23:03:55 -0800 Subject: [LLVMdev] llvm/test: suffix or operands invalid for `push' In-Reply-To: <1204541377.7339.36.camel@kurier> References: <1204103370.6718.83.camel@kurier> <1204541377.7339.36.camel@kurier> Message-ID: On Mar 3, 2008, at 2:49 AM, Joachim Durchholz wrote: > Hi all, > > I found enough to explain the behaviour that I encountered. If I'm > correct, the bugs are just in the dejagnu-based test machinery, not in > LLVM itself. Yep, I believe that. I haven't been following the whole thread very closely, what specific tests are affected here? Before making any significant and widespread changes to llvm/test, please change one test and propose it as a model for other tests. Thanks for working on this! -Chris > > There seem to be two issues: > > > Issue 1 is that the CC, CFLAGS, CXX, and CXXFLAGS settings are not > reflected in the site.exp file. I had > CC=gcc-4.2 > CFLAGS="-m32 -Wl,-melf_i386" > CXX=g++-4.2 > CXXFLAGS=$CFLAGS > ARCH=i686-pc-linux-gnu > ./configure --prefix=$HOME --target=$ARCH --host=$ARCH --build=$ARCH > but site.exp still has > set gccpath "gcc" > set gxxpath "g++" > and no mention of -m32 or -Wl,elf_i386 (these options are required to > force a 64-bit GNU toolchain into 32-bit mode). > > I don't know where these options are lost; I did a little looking > around > in the configure scripts, but didn't find any obvious problems and > decided to leave this kind of issue to the autoconf experts :-) > > > Issue 2 is that the RUN: lines in the dejagnu tests ignore $CC, $CXX, > $CFLAGS and $CXXFLAGS when calling gcc, g++, or as (and possibly > ld). In > most cases things will happen to not fail, but the assembler choked on > 32-bit opcodes when running in default mode (which is 64 bits on an > amd64 machine, of course). > > If I'm correct, this is a bug in the tests, not in LLVM. > Proposed bug fix would then be to replace in all test case files > (hopefully I got the dejagnu macro syntax right): > gcc -> %gccpath > g++ -> %gxxpath > as -> %gccpath (don't call 'as' directly, gcc knows how to call it!) > ld -> %gccpath (just as with 'as') > > > Can anybody confirm or correct these findings? > > Regards, > Jo > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From jo at durchholz.org Thu Mar 6 02:08:46 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 06 Mar 2008 09:08:46 +0100 Subject: [LLVMdev] llvm/test: suffix or operands invalid for `push' In-Reply-To: References: <1204103370.6718.83.camel@kurier> <1204541377.7339.36.camel@kurier> Message-ID: <1204790926.7577.26.camel@kurier> Am Mittwoch, den 05.03.2008, 23:03 -0800 schrieb Chris Lattner: > On Mar 3, 2008, at 2:49 AM, Joachim Durchholz wrote: > > > Hi all, > > > > I found enough to explain the behaviour that I encountered. If I'm > > correct, the bugs are just in the dejagnu-based test machinery, not in > > LLVM itself. > > Yep, I believe that. I haven't been following the whole thread very > closely, what specific tests are affected here? test/C++Frontend/2006-11-06-StackTrace.cpp test/C++Frontend/2006-11-30-NoCompileUnit.cpp test/C++Frontend/2006-11-30-Pubnames.cpp > Before making any significant and widespread changes to llvm/test, > please change one test and propose it as a model for other tests. The changes were actually very local: replace calls to gcc/g++/as with calls to %compile_c and %compile_cxx. I submitted bug reports with patches recently (look for bugs submitted by jo at durchholz.org). The patches are tiny, so it's not a real problem if they need to be modified, and I'm willing to try out any needed modifications and resubmit the patches. (%compile_cxx wouldn't work because %compile_c would be substituted before, so the first patch corrects that.) > Thanks for working on this! You're welcome :-) Regards, Jo From jo at durchholz.org Thu Mar 6 17:04:53 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 07 Mar 2008 00:04:53 +0100 Subject: [LLVMdev] Error messages in llvm-test In-Reply-To: <1204745618.7307.152.camel@kurier> References: <1204745618.7307.152.camel@kurier> Message-ID: <1204844693.8533.40.camel@kurier> Am Mittwoch, den 05.03.2008, 20:33 +0100 schrieb Joachim Durchholz: > Hi all, > > llvm-test fails on me in the first test (and many subsequent tests, but > I hope that fixing the first test will allow me to continue). OK, scrap that one. Serves me right for trying to run the tests from TRUNK with a 2.2 distribution. I do see some errors, but they may be expected ones. I'll be back when I see anything that I don't know how to handle :-) Regards, Jo From hyperquantum at gmail.com Fri Mar 7 08:22:02 2008 From: hyperquantum at gmail.com (HyperQuantum) Date: Fri, 7 Mar 2008 15:22:02 +0100 Subject: [LLVMdev] llvm-gcc and mips In-Reply-To: <20d882600802290523u72568fbbl4033c131b3aade06@mail.gmail.com> References: <20d882600802270838s7fbfd4a2r592696bd8f78e69@mail.gmail.com> <20d882600802280403p4e458ac2w51c62e299ac62f18@mail.gmail.com> <0C9DAA43-29CC-47F0-BF74-DD6B14C8A06A@apple.com> <20d882600802290523u72568fbbl4033c131b3aade06@mail.gmail.com> Message-ID: <20d882600803070622q479a7794i88cae8374f5815de@mail.gmail.com> On Fri, Feb 29, 2008 at 2:23 PM, HyperQuantum wrote: > At least I got llvm-gcc running again. Something is still wrong because I cannot get Pi_Calc to run after compiling it with this semi-cross-compiler, and it worked with the regular llvm-gcc. I configured the cross compiler with target mips-unknown-linux-gnu. Should I use another triple or do I need to hack the llvm-gcc sources some more? From gordonhenriksen at mac.com Fri Mar 7 12:24:02 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Fri, 7 Mar 2008 13:24:02 -0500 Subject: [LLVMdev] [PATCH] Prefer to use *.opt ocaml executables as they are more efficient. In-Reply-To: <1204700741-13946-1-git-send-email-idadesub@users.sourceforge.net> References: <7B98597D-8772-4D07-9A6A-BF39E23BB78D@mac.co> <1204700741-13946-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: <8DAF878C-D81A-4F4A-AD7A-BAEB5B1BC90D@mac.com> On Mar 5, 2008, at 02:05, Erick Tryzelaar wrote: > This is another attempt to use the .opt ocaml executables. I've > attached these instead of inlining them, so hopefully they won't > give you problems applying them. Please let me know if it's still > not working, then I'll just do this the old fashioned way. That worked much better. Applied. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080303/059286.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080303/059287.html Thanks, Erick! ? Gordon From gordonhenriksen at mac.com Fri Mar 7 13:14:04 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Fri, 7 Mar 2008 14:14:04 -0500 Subject: [LLVMdev] new patch without brackets In-Reply-To: <1ef034530803042249t52513846o66ecc17b48e09934@mail.gmail.com> References: <872FECF0-E057-4E98-9C48-89EA8EF33EA7@mac.com> <1204689178-13481-1-git-send-email-idadesub@users.sourceforge.net> <8E3EA324-8263-4AE3-9D2C-C5E2E260E409@mac.com> <1ef034530803042249t52513846o66ecc17b48e09934@mail.gmail.com> Message-ID: <9C99CE2A-1803-43BD-9423-02E1F28AE6CE@mac.com> Applied with a couple of minor edits. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080303/059292.html On Mar 5, 2008, at 01:49, Erick Tryzelaar wrote: > I can in the future use "attach" (which I did with this mail). Please do. > I'm sorry for causing problems. Not at all. Thanks Erick! ? Gordon From bruno.cardoso at gmail.com Fri Mar 7 13:28:05 2008 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Fri, 7 Mar 2008 16:28:05 -0300 Subject: [LLVMdev] llvm-gcc and mips In-Reply-To: <20d882600803070622q479a7794i88cae8374f5815de@mail.gmail.com> References: <20d882600802270838s7fbfd4a2r592696bd8f78e69@mail.gmail.com> <20d882600802280403p4e458ac2w51c62e299ac62f18@mail.gmail.com> <0C9DAA43-29CC-47F0-BF74-DD6B14C8A06A@apple.com> <20d882600802290523u72568fbbl4033c131b3aade06@mail.gmail.com> <20d882600803070622q479a7794i88cae8374f5815de@mail.gmail.com> Message-ID: <275e64e40803071128m783e375q9fd2f58a4d4a1166@mail.gmail.com> Hi, When using mips-unknown-linux-gnu as a cross-compiler, the llvm Mips backend is called by cc1 and with that you get llvm bytecode defined relative to the Mips ABI. This can be messing up somehow your generated C code. 2008/3/7, HyperQuantum : > On Fri, Feb 29, 2008 at 2:23 PM, HyperQuantum wrote: > > At least I got llvm-gcc running again. > > > Something is still wrong because I cannot get Pi_Calc to run after > compiling it with this semi-cross-compiler, and it worked with the > regular llvm-gcc. I configured the cross compiler with target > mips-unknown-linux-gnu. Should I use another triple or do I need to > hack the llvm-gcc sources some more? > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Bruno Cardoso Lopes http://www.brunocardoso.org "Morte: Mas n?o para voc? pistoleiro" From hyperquantum at gmail.com Fri Mar 7 14:10:18 2008 From: hyperquantum at gmail.com (HyperQuantum) Date: Fri, 7 Mar 2008 21:10:18 +0100 Subject: [LLVMdev] llvm-gcc and mips In-Reply-To: <275e64e40803071128m783e375q9fd2f58a4d4a1166@mail.gmail.com> References: <20d882600802270838s7fbfd4a2r592696bd8f78e69@mail.gmail.com> <20d882600802280403p4e458ac2w51c62e299ac62f18@mail.gmail.com> <0C9DAA43-29CC-47F0-BF74-DD6B14C8A06A@apple.com> <20d882600802290523u72568fbbl4033c131b3aade06@mail.gmail.com> <20d882600803070622q479a7794i88cae8374f5815de@mail.gmail.com> <275e64e40803071128m783e375q9fd2f58a4d4a1166@mail.gmail.com> Message-ID: <20d882600803071210yf585e04p9172cdf742d68214@mail.gmail.com> On Fri, Mar 7, 2008 at 8:28 PM, Bruno Cardoso Lopes wrote: > When using mips-unknown-linux-gnu as a cross-compiler, the llvm Mips > backend is called by cc1 and with that you get llvm bytecode defined > relative to the Mips ABI. That was my intention. The PSP has a 32-bit MIPS (derived) CPU. What I don't know is if that triple is the right one to pick. I looked through the patch that turns gcc into psp-gcc and it defines a special triple called simply "psp": diff -burN gcc-4.1.0/config.sub gcc-psp/config.sub --- gcc-4.1.0/config.sub 2005-12-16 12:57:40.000000000 +0000 +++ gcc-psp/config.sub 2006-05-07 13:27:40.000000000 +0100 @@ -264,6 +264,7 @@ | mipsisa64sb1 | mipsisa64sb1el \ | mipsisa64sr71k | mipsisa64sr71kel \ | mipstx39 | mipstx39el \ + | mipsallegrex | mipsallegrexel \ | mn10200 | mn10300 \ | mt \ | msp430 \ @@ -346,6 +347,7 @@ | mipsisa64sb1-* | mipsisa64sb1el-* \ | mipsisa64sr71k-* | mipsisa64sr71kel-* \ | mipstx39-* | mipstx39el-* \ + | mipsallegrex-* | mipsallegrexel-* \ | mmix-* \ | mt-* \ | msp430-* \ @@ -689,6 +691,10 @@ basic_machine=m68k-atari os=-mint ;; + psp) + basic_machine=mipsallegrexel-psp + os=-elf + ;; mips3*-*) basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'` ;; I did not see any changes in the rest of the diff that did something to the ABI; as far as I understand it it's only adding some extra instructions. So I assume that the PSP uses a standard MIPS ABI. And yet something is still wrong, even more than with a native "i686-pc-linux-gnu" llvm-gcc. > This can be messing up somehow your > generated C code. Supposed that you knew my approach was intentional (correct me if I'm wrong), what problem did you see here? Regards, Kevin Andr? From dekruijf at cs.wisc.edu Fri Mar 7 14:52:22 2008 From: dekruijf at cs.wisc.edu (Marc de Kruijf) Date: Fri, 7 Mar 2008 14:52:22 -0600 Subject: [LLVMdev] runtime/GC/SemiSpace/semispace.c does not build in release 2.2? Message-ID: I just downloaded the source for release 2.2, and when I try to build 'make -C runtime' it fails with the following error: ---- [...] llvm[2]: Compiling semispace.c for Release build (bytecode) semispace.c:107: error: syntax error before 'ShadowStackEntry' semispace.c:107: warning: no semicolon at end of struct or union semispace.c:108: error: syntax error before '*' token semispace.c:108: warning: type defaults to 'int' in declaration of 'Map' semispace.c:108: warning: data definition has no type or storage class semispace.c:110: error: syntax error before '}' token semispace.c:111: error: syntax error before '*' token semispace.c:111: warning: type defaults to 'int' in declaration of 'llvm_gc_root_chain' semispace.c:111: warning: data definition has no type or storage class semispace.c: In function 'llvm_cg_walk_gcroots': semispace.c:114: error: 'StackEntry' undeclared (first use in this function) semispace.c:114: error: (Each undeclared identifier is reported only once semispace.c:114: error: for each function it appears in.) semispace.c:114: error: 'R' undeclared (first use in this function) semispace.c:116: warning: value computed is not used [...] ---- A search through the mailing list shed no light on this issue. Is this a known problem? If so, why is it not documented somewhere? If not, how did it make it into a release? Am I missing something obvious? Marc From dag at cray.com Fri Mar 7 14:53:02 2008 From: dag at cray.com (David Greene) Date: Fri, 7 Mar 2008 14:53:02 -0600 Subject: [LLVMdev] Computing Register Pressure Message-ID: <200803071453.02626.dag@cray.com> Is there a convenient way to get the number of live intervals at any program point? Bonus if there's an easy way to iterate through all of the live intervals at each program point. Ideally I'd like to give some routine an instruction index and have it return an iterator to all live intervals at that point. -Dave From gohman at apple.com Fri Mar 7 15:13:29 2008 From: gohman at apple.com (Dan Gohman) Date: Fri, 7 Mar 2008 13:13:29 -0800 Subject: [LLVMdev] Pass::runPass? Message-ID: The virtual function Pass::runPass is a little deceptive; a pass that isn't a ModulePass can be run on a Module when run from a PassManager, but calling runPass(Module *) with the same pass does nothing. Also, runPass doesn't appear to be used anywhere. Can someone explain what runPass is for? Thanks, Dan From gordonhenriksen at mac.com Fri Mar 7 15:20:22 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Fri, 7 Mar 2008 16:20:22 -0500 Subject: [LLVMdev] runtime/GC/SemiSpace/semispace.c does not build in release 2.2? In-Reply-To: References: Message-ID: <55BC7CF4-2115-4876-8EE1-CD6DD1F2DD1E@mac.com> On Mar 7, 2008, at 15:52, Marc de Kruijf wrote: > I just downloaded the source for release 2.2, and when I try to > build 'make -C runtime' it fails with the following error: Yes, this is unfortunate. Please pull from svn where the example is fixed. ? Gordon From dpatel at apple.com Fri Mar 7 15:22:26 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 7 Mar 2008 13:22:26 -0800 Subject: [LLVMdev] Pass::runPass? In-Reply-To: References: Message-ID: On Mar 7, 2008, at 1:13 PM, Dan Gohman wrote: > The virtual function Pass::runPass is a little deceptive; a pass that > isn't a ModulePass can be run on a Module when run from a > PassManager, but calling runPass(Module *) with the same pass > does nothing. Also, runPass doesn't appear to be used anywhere. > Can someone explain what runPass is for? Only BasicBlockPass uses it. I do not see any advantage of keeping this around ? What are you trying to do? - Devang From gohman at apple.com Fri Mar 7 16:27:06 2008 From: gohman at apple.com (Dan Gohman) Date: Fri, 7 Mar 2008 14:27:06 -0800 Subject: [LLVMdev] Pass::runPass? In-Reply-To: References: Message-ID: <65432CE9-28D3-4757-A224-D1B207E6090D@apple.com> On Mar 7, 2008, at 1:22 PM, Devang Patel wrote: > > On Mar 7, 2008, at 1:13 PM, Dan Gohman wrote: > >> The virtual function Pass::runPass is a little deceptive; a pass that >> isn't a ModulePass can be run on a Module when run from a >> PassManager, but calling runPass(Module *) with the same pass >> does nothing. Also, runPass doesn't appear to be used anywhere. >> Can someone explain what runPass is for? > > Only BasicBlockPass uses it. I do not see any advantage of keeping > this around ? What are you trying to do? I'm just reading the code trying to understand what stuff does and how it's used :-). If you don't see any advantage in keeping the runPass methods, can we remove them? Thanks, Dan From dpatel at apple.com Fri Mar 7 16:29:42 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 7 Mar 2008 14:29:42 -0800 Subject: [LLVMdev] Pass::runPass? In-Reply-To: <65432CE9-28D3-4757-A224-D1B207E6090D@apple.com> References: <65432CE9-28D3-4757-A224-D1B207E6090D@apple.com> Message-ID: <4EC3CCE3-483F-41AE-82D6-B266D440ABC2@apple.com> On Mar 7, 2008, at 2:27 PM, Dan Gohman wrote: > > On Mar 7, 2008, at 1:22 PM, Devang Patel wrote: > >> >> On Mar 7, 2008, at 1:13 PM, Dan Gohman wrote: >> >>> The virtual function Pass::runPass is a little deceptive; a pass >>> that >>> isn't a ModulePass can be run on a Module when run from a >>> PassManager, but calling runPass(Module *) with the same pass >>> does nothing. Also, runPass doesn't appear to be used anywhere. >>> Can someone explain what runPass is for? >> >> Only BasicBlockPass uses it. I do not see any advantage of keeping >> this around ? What are you trying to do? > > I'm just reading the code trying to understand what stuff does and > how it's used :-). If you don't see any advantage in keeping the > runPass methods, can we remove them? Yes, we can remove this methods. - Devang From evan.cheng at apple.com Fri Mar 7 17:11:16 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 7 Mar 2008 15:11:16 -0800 Subject: [LLVMdev] Computing Register Pressure In-Reply-To: <200803071453.02626.dag@cray.com> References: <200803071453.02626.dag@cray.com> Message-ID: <9F76F1E7-322D-4AF1-8D79-D6D537A5C355@apple.com> That's potentially very useful. But the current register allocator is not tracking this. This is something that can be computed at the beginning of allocation but it needs to be updated when spills / spilts happen. Evan On Mar 7, 2008, at 12:53 PM, David Greene wrote: > Is there a convenient way to get the number of live intervals at any > program point? Bonus if there's an easy way to iterate through all > of the live intervals at each program point. > > Ideally I'd like to give some routine an instruction index and have > it return an iterator to all live intervals at that point. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From clattner at apple.com Fri Mar 7 17:59:55 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 Mar 2008 15:59:55 -0800 Subject: [LLVMdev] llvm-gcc 4.2 in Xcode Message-ID: I'm happy to announce that the iPhone SDK beta (released yesterday, available on http://developer.apple.com) includes a beta version of llvm-gcc 4.2 as part of the included Xcode 3.1 beta. For more details, please see the llvm-gcc release notes included in the Xcode documentation. LLVM will also be in the final release of Xcode 3.1 for all Mac developers who are not interested in downloading the beta iPhone SDK. This release includes many features and enhancements contributed by LLVM Developers from across the globe. Thank you to everyone who has contributed to LLVM! -Chris From jo at durchholz.org Fri Mar 7 18:54:04 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 08 Mar 2008 01:54:04 +0100 Subject: [LLVMdev] Trying to set up a nightly test Message-ID: <1204937644.7347.66.camel@kurier> Hi, I thought I'd set up a nightly tester and ran across the following issues: 1) Checkout is done using https, which causes the following message: Error validating server certificate for 'https://llvm.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: llvm.org - Valid: from Tue, 26 Jun 2007 19:42:38 GMT until Wed, 25 Jun 2008 19:42:38 GMT - Issuer: Certification Services Division, Thawte Consulting cc, Cape Town, Western Cape, ZA - Fingerprint: 88:06:59:b1:be:ed:96:bb:98:3d:9f:94:fd:0d:9a:d4:23:99:39:0d (R)eject, accept (t)emporarily or accept (p)ermanently? The script will wait for input, however, the prompt is redirected to a log file and not visible on the terminal, so it will look as if the test process hangs. 2) I could include the povray tests since poyray is free, but not the spec2000 tests. Current options for NewNightlyTest don't allow me to do this. 3) After checking out everything, I get this: Changing To: Checkout directory (/home/jo/llvm-nightly-test/build) Changing To: llvm source directory (llvm) sed: -e expression #1, char 9: unterminated `s' command CHANGE HISTORY ANALYSIS STAGE Rev: 48038, Author: void, Date: 2008-03-07, Time: 23:45:15 Rev: 48041, Author: djg, Date: 2008-03-08, Time: 00:19:12 4) Further testing crashed&burned because NewNightlyTest.pl doesn't pass on -gccpath "gcc-4.2 -m32" as a single argument to ./configure. I don't consider this a serious bug, I'll try with -gccflags/-gxxflags/-ldflags tomorrow. 5) I accidentally had the script enter my machine (named "kurier") into the nightly tester database, it seems. Please ignore any results from here. (Hint: a -noreport flag might have prevented this.) Hope this helps. Regards, Jo From dberlin at dberlin.org Fri Mar 7 21:16:08 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Fri, 7 Mar 2008 22:16:08 -0500 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: <4aca3dc20803051127h7b260a96g443d6d34507f6e2c@mail.gmail.com> References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> <4aca3dc20803022029i7034033dl295608bc2e707224@mail.gmail.com> <749b5dd60803030255k49411d02lfa927475c0aa0bf8@mail.gmail.com> <4aca3dc20803051127h7b260a96g443d6d34507f6e2c@mail.gmail.com> Message-ID: <4aca3dc20803071916g6aebfd43v69be2024ac5bd6b1@mail.gmail.com> FWIW, Ben Hardekopf asked me to post this for him on the subject Regarding Whaley and Lam's BDD-based approach to context-sensitive analysis, there is a paper by the same research group (Avots et al in ICSE'05) that adapts their technique for C. The results are not very encouraging -- their system doesn't scale nearly as well for C as it did for Java. The primary difference is that unlike Java, in C top-level variables can have their address taken and be passed between functions, which requires the analysis to maintain 2 contexts for each points-to relation: one for the pointer and one for the pointee. The other problem with their method is that only the top-level variables are treated context-sensitively; everything in the heap (e.g. for Java, all object fields) is context-insensitive. I spoke with John Whaley about this and he said they've tried to use a context-sensitive heap model, but they couldn't get it to scale at all. My personal feeling (backed up by results from some other research groups, e.g. Chen et al in ISPAN'02 and Nystrom et al in PASTE'04) is that a context-sensitive heap model is critical for getting the maximum benefit from a context-sensitive pointer analysis, and I don't know that BDDs, at least as currently used, are the right approach for this. I was impressed by a completely different approach, described by Nystrom et al in SAS'04 and Nystrom's PhD thesis, for doing context-sensitive pointer analysis for C with a context-sensitive heap model. Like Whaley and Lam, and unlike Lattner and Adve's Data Structure Analysis, their technique is inclusion-based (i.e. a context-sensitive version of Andersen's), but unlike Whaley and Lam it also uses a context-sensitive heap model, and it's targeted at C. They managed to scale the analysis to a couple hundred thousand lines of code. I actually have several ideas on how to improve their analysis and make it more scalable, but I haven't had time to implement them -- mainly because I haven't wanted to re-implement their whole analysis in LLVM. I would definitely be interested in any effort to do this, and I think it would have a lot of benefit. In fact, I supervised another student who implemented a simplified version of this analysis for a class project; while the code itself probably isn't re-usable, the student made a number of good observations on the analysis that I would be happy to share with anyone who is interested. Thanks, Ben From christophe.avoinne at laposte.net Sat Mar 8 03:23:39 2008 From: christophe.avoinne at laposte.net (Christophe Avoinne) Date: Sat, 08 Mar 2008 10:23:39 +0100 Subject: [LLVMdev] llvm-gcc 4.2 in Xcode Message-ID: <47D25B1B.4070106@laposte.net> I'm UNhappy to see the iPhone SDK REQUIRES an expensive iMac computer to be able freely to develop programs on iPhone/iPod Touch. On 08/03/2008 00:59:55, Chris Lattner (clattner at apple.com) wrote: > I'm happy to announce that the iPhone SDK beta (released yesterday, > available on http://developer.apple.com) includes a beta version of > llvm-gcc 4.2 as part of the included Xcode 3.1 beta. For more > details, please see the llvm-gcc release notes included in the Xcode > documentation. LLVM will also be in the final release of Xcode 3.1 > for all Mac developers who are not interested in downloading the beta > iPhone SDK. > > This release includes many features and enhancements contributed by > LLVM Developers from across the globe. Thank you to everyone who has > contributed to LLVM! > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From richard.warburton at gmail.com Sat Mar 8 05:23:32 2008 From: richard.warburton at gmail.com (Richard Warburton) Date: Sat, 8 Mar 2008 11:23:32 +0000 Subject: [LLVMdev] Google Summer of Code Idea In-Reply-To: <4aca3dc20803071916g6aebfd43v69be2024ac5bd6b1@mail.gmail.com> References: <749b5dd60802281043r4607840ew243c9a8a0da269e2@mail.gmail.com> <4aca3dc20803022029i7034033dl295608bc2e707224@mail.gmail.com> <749b5dd60803030255k49411d02lfa927475c0aa0bf8@mail.gmail.com> <4aca3dc20803051127h7b260a96g443d6d34507f6e2c@mail.gmail.com> <4aca3dc20803071916g6aebfd43v69be2024ac5bd6b1@mail.gmail.com> Message-ID: <749b5dd60803080323q682387o60efe21d81523389@mail.gmail.com> > Regarding Whaley and Lam's BDD-based approach to context-sensitive > analysis ... Thanks for posting this. In which case its probably a good idea, if I don't go down this route to context sensitivity. > I was impressed by a completely different approach, described by Nystrom > et al in SAS'04 and Nystrom's PhD thesis, for doing context-sensitive > pointer analysis for C with a context-sensitive heap model. Like Whaley > and Lam, and unlike Lattner and Adve's Data Structure Analysis, their > technique is inclusion-based (i.e. a context-sensitive version of > Andersen's), but unlike Whaley and Lam it also uses a context-sensitive > heap model, and it's targeted at C. They managed to scale the analysis to > a couple hundred thousand lines of code. I actually have several ideas on > how to improve their analysis and make it more scalable, but I haven't had > time to implement them -- mainly because I haven't wanted to re-implement > their whole analysis in LLVM. I would definitely be interested in any > effort to do this, and I think it would have a lot of benefit. In fact, I > supervised another student who implemented a simplified version of this > analysis for a class project; while the code itself probably isn't > re-usable, the student made a number of good observations on the analysis > that I would be happy to share with anyone who is interested. I'll have a read through Nystrom's approach. Are there publically availible implementations of this algorithm anywhere else? If he is already in this region in terms of scalability, then improvements might make a context sensitive analysis actually practical. Either way if the claims of this paper hold true then it seems like a viable option for implementation. Would it be possible to get Ben Hardekopf's suggested improvements and his student's ideas posted to the list? Regards, Richard From simon.strandman at telia.com Sat Mar 8 08:29:53 2008 From: simon.strandman at telia.com (Simon Strandman) Date: Sat, 08 Mar 2008 15:29:53 +0100 Subject: [LLVMdev] Trying to build Firefox on OSX with LLVM 2.2 Message-ID: <47D2A2E1.9050301@telia.com> Hello I'm trying to build Firefox with LLVM 2.2 and llvm-gcc 4.2 but I can't get it working. I've tried with Firefox 2.0.0.12 and 3.0 from CVS. The build error from Firefox 2 is this: usr/local/bin/llvm-gcc -o host_mar.o -c -DXP_UNIX -DXP_MACOSX -DNO_X11 -O -I../../../dist/include/libmar -I../../../dist/include/mar -I../../../dist/include -I../../../dist/include/nspr -I../../../dist/sdk/include -I../../../dist/include/nspr /Users/simon/Desktop/mozilla/firefox2/mozilla/modules/libmar/tool/mar.c /usr/local/bin/llvm-gcc -o mar -DXP_UNIX -DXP_MACOSX -DNO_X11 -O host_mar.o ../../../dist/host/lib/libhostmar.a ld: warning in ../../../dist/host/lib/libhostmar.a, file is not of required architecture Undefined symbols: "_mar_open", referenced from: _main in host_mar.o "_mar_enum_items", referenced from: _main in host_mar.o "_mar_extract", referenced from: _main in host_mar.o "_mar_close", referenced from: _main in host_mar.o "_mar_create", referenced from: _main in host_mar.o ld: symbol(s) not found collect2: ld returnerade avslutningsstatus 1 gmake[4]: *** [mar] Fel 1 gmake[4]: Leaving directory `/Users/simon/Desktop/mozilla/firefox2/mozilla/obj-ff/modules/libmar/tool' gmake[3]: *** [libs] Fel 2 gmake[3]: Leaving directory `/Users/simon/Desktop/mozilla/firefox2/mozilla/obj-ff/modules/libmar' gmake[2]: *** [tier_1] Fel 2 gmake[2]: Leaving directory `/Users/simon/Desktop/mozilla/firefox2/mozilla/obj-ff' make[1]: *** [default] Error 2 make: *** [build] Error 2 Disabling optimizations doesn't make a difference. Firefox 3 fails with the same error but on a different file and with different symbols. This is on OSX 10.5.2 with xcode 3.0. Any ideas? I hope this is the correct list to ask about this! Thanks, Simon From asl at math.spbu.ru Sat Mar 8 09:09:42 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sat, 8 Mar 2008 18:09:42 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?VHJ5aW5nIHRvIGJ1aWxkIEZpcmVmb3ggb24gT1NYIHdp?= =?koi8-r?b?dGggTExWTSAyLjI=?= Message-ID: <200803081509.m28F9gm5039059@star.math.spbu.ru> Hello, Simon > ld: warning in ../../../dist/host/lib/libhostmar.a, file is not of > required architecture I can say nothing about FireFox on darwin, but I frequently build Seamonkey on linux for testing purposes without any problems. It your case it looks like 32-bit and 64-bit objects are somehow "mixed" together (thus warning). I'd suggest you to track, where these symbols should be defined and check, that they are linked in properly. -- WBR, Anton Korobeynikov From robert.a.zeh at gmail.com Sat Mar 8 09:48:45 2008 From: robert.a.zeh at gmail.com (Robert Zeh) Date: Sat, 8 Mar 2008 09:48:45 -0600 Subject: [LLVMdev] Changing the return type for a function after construction Message-ID: Is there any way to change the return type of a function after constructing one? Thanks, Robert From jo at durchholz.org Sat Mar 8 12:57:23 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 08 Mar 2008 19:57:23 +0100 Subject: [LLVMdev] NewNightlyTester.pl: split into phases? Message-ID: <1205002643.6742.41.camel@kurier> Hi all, when looking at NewNightlyTester.pl, I see it has several distinct phases: 1. Get a current tree 2. ./configure 3. Build 4. Run a selection of tests 7. Send test results to web site 8. Clean up Wouldn't it make sense to allow each phase to be activated individually? Or possibly a subset of phases, something along the lines of -from-phase=test -to-phase=report With that, I could do all kinds of nifty things, such as checking out once and running the test site for i386 and amd64; or testing compiler options without having to re-download the source tree; or avoiding sending irrelevant test results because the test suite isn't properly installed yet. Does that make sense? Problems? I'd be willing to implement this if something like that is welcomed. Regards, Jo From dberlin at dberlin.org Sat Mar 8 13:33:08 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Sat, 8 Mar 2008 14:33:08 -0500 Subject: [LLVMdev] llvm-gcc 4.2 in Xcode In-Reply-To: <47D25B1B.4070106@laposte.net> References: <47D25B1B.4070106@laposte.net> Message-ID: <4aca3dc20803081133t4cb5c80dpadde73b596bdbd23@mail.gmail.com> This is almost certainly the wrong place to register your discontent. On Sat, Mar 8, 2008 at 4:23 AM, Christophe Avoinne wrote: > I'm UNhappy to see the iPhone SDK REQUIRES an expensive iMac computer to > be able freely to develop programs on iPhone/iPod Touch. > > > > On 08/03/2008 00:59:55, Chris Lattner (clattner at apple.com) wrote: > > I'm happy to announce that the iPhone SDK beta (released yesterday, > > available on http://developer.apple.com) includes a beta version of > > llvm-gcc 4.2 as part of the included Xcode 3.1 beta. For more > > details, please see the llvm-gcc release notes included in the Xcode > > documentation. LLVM will also be in the final release of Xcode 3.1 > > for all Mac developers who are not interested in downloading the beta > > iPhone SDK. > > > > This release includes many features and enhancements contributed by > > LLVM Developers from across the globe. Thank you to everyone who has > > contributed to LLVM! > > > > -Chris > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From sabre at nondot.org Sat Mar 8 14:30:57 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 8 Mar 2008 12:30:57 -0800 Subject: [LLVMdev] Changing the return type for a function after construction In-Reply-To: References: Message-ID: <69CA4E7A-D9E3-469D-8899-2712C1716C4D@nondot.org> On Mar 8, 2008, at 7:48 AM, Robert Zeh wrote: > Is there any way to change the return type of a function after > constructing one? Nope. Once created, you can't change the type of a Value. The best way to do this is to create a new function, splice the body of the old over (a constant time operation) and update the new one. Take a look at the dead argument elimination pass for some example code. -Chris From tonic at nondot.org Sat Mar 8 16:02:43 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sat, 8 Mar 2008 14:02:43 -0800 Subject: [LLVMdev] NewNightlyTester.pl: split into phases? In-Reply-To: <1205002643.6742.41.camel@kurier> References: <1205002643.6742.41.camel@kurier> Message-ID: On Mar 8, 2008, at 10:57 AM, Joachim Durchholz wrote: > Hi all, > > when looking at NewNightlyTester.pl, I see it has several distinct > phases: > > 1. Get a current tree > 2. ./configure > 3. Build > 4. Run a selection of tests > 7. Send test results to web site > 8. Clean up > > Wouldn't it make sense to allow each phase to be activated > individually? > Or possibly a subset of phases, something along the lines of > > -from-phase=test -to-phase=report > > With that, I could do all kinds of nifty things, such as checking out > once and running the test site for i386 and amd64; or testing compiler > options without having to re-download the source tree; or avoiding > sending irrelevant test results because the test suite isn't properly > installed yet. > > Does that make sense? Problems? > I'd be willing to implement this if something like that is welcomed. > Its been on my todo for awhile, but this is what I would like to see. - ability to run the nightly tester from a tree thats already checked out and updated. I think right now it forces you to always check out a new tree and if you don't it reports a build error. - ability to check out llvm-gcc or update llvm-gcc and build it before running tests. In addition to using a prebuilt binary. If you fix the two things above then you should be able to just rerun the script multiple times for different targets like you want. It will also solve problems many others have experienced. A -noreport option is probably a good idea too. Just be sure not to change what it sends to the website. That needs to stay the same. -Tanya > Regards, > Jo > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From jo at durchholz.org Sat Mar 8 16:45:29 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 08 Mar 2008 23:45:29 +0100 Subject: [LLVMdev] NewNightlyTester.pl: split into phases? In-Reply-To: References: <1205002643.6742.41.camel@kurier> Message-ID: <1205016329.6742.68.camel@kurier> Am Samstag, den 08.03.2008, 14:02 -0800 schrieb Tanya Lattner: > - ability to check out llvm-gcc or update llvm-gcc and build it before > running tests. In addition to using a prebuilt binary. Does it need a prebuilt binary? I have been suspecting so since it has been failing with BUILD ERROR for me. I just haven't found the time to verify that yet. I have yet to try building llvm-gcc from sources though. The instructions seem to be clear enough, but it's still possible that I'll hit a hidden snag. Well, I'll try that anyway. I like my software well-done after all :-) > If you fix the two things above then you should be able to just rerun > the script multiple times for different targets like you want. It will > also solve problems many others have experienced. Ensuring that the tree is pristine could be a bit of a challenge. It's always possible that the user inadvertently changed or deleted a file, giving a false alarm for all future checks. Options to avoid that seem to be: 1. Do a 'make dist-clean' before running the tests. Of course, if dist-clean has bugs, this may create trouble. On the other hand, it would exercise dist-clean on a regular basis, which might be a Good Thing. 2. Recreate $BUILDDIR as a copy of a pristine check-out directory each time the tester is run. This would be much faster than a download, but still a lot of unnecessary load. 3. For each test, first run svn revert, then ask svn about any unversioned files and delete them, finally svn update. (2) would be easiest. (3) would be most failsafe. (1) might be more useful for the project because it could uncover bugs in the dist-clean target though. (OTOH one could argue that this should be a separate regression test.) > A -noreport option is probably a good idea too. OK, that should be easy to add. > Just be sure not to change what it sends to the website. That needs to > stay the same. Sure. I think wrapping an if statement around the HTTP send should be easy; the code of NewNightlyTester.pl isn't very complicated. On a tangent: What's the best way to submit patches: Bugzilla? Something else? Regards, Jo From tonic at nondot.org Sat Mar 8 17:11:54 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sat, 8 Mar 2008 15:11:54 -0800 Subject: [LLVMdev] NewNightlyTester.pl: split into phases? In-Reply-To: <1205016329.6742.68.camel@kurier> References: <1205002643.6742.41.camel@kurier> <1205016329.6742.68.camel@kurier> Message-ID: <2C3B6943-3F9C-4299-9868-C8B87AA20964@nondot.org> On Mar 8, 2008, at 2:45 PM, Joachim Durchholz wrote: > > Am Samstag, den 08.03.2008, 14:02 -0800 schrieb Tanya Lattner: >> - ability to check out llvm-gcc or update llvm-gcc and build it >> before >> running tests. In addition to using a prebuilt binary. > > Does it need a prebuilt binary? > I have been suspecting so since it has been failing with BUILD ERROR > for > me. I just haven't found the time to verify that yet. > > I have yet to try building llvm-gcc from sources though. The > instructions seem to be clear enough, but it's still possible that > I'll > hit a hidden snag. > Well, I'll try that anyway. I like my software well-done after all :-) > You need to have an llvm-gcc, so you either build it yourself or use one of the prebuilt binaries. The nightly tester just needs to know where its located, but it doesn't know anything about llvm-gcc otherwise. Since most people are testing TOT and llvm/llvm-gcc are tied together it makes sense to update llvm-gcc before running the nightly tester. However, it takes quite a bit of time to checkout and build llvm-gcc, so having the option to just update existing sources would be nice. > >> If you fix the two things above then you should be able to just rerun >> the script multiple times for different targets like you want. It >> will >> also solve problems many others have experienced. > > Ensuring that the tree is pristine could be a bit of a challenge. It's > always possible that the user inadvertently changed or deleted a file, > giving a false alarm for all future checks. > Options to avoid that seem to be: > 1. Do a 'make dist-clean' before running the tests. Of course, if > dist-clean has bugs, this may create trouble. On the other hand, it > would exercise dist-clean on a regular basis, which might be a Good > Thing. > 2. Recreate $BUILDDIR as a copy of a pristine check-out directory each > time the tester is run. This would be much faster than a download, but > still a lot of unnecessary load. > 3. For each test, first run svn revert, then ask svn about any > unversioned files and delete them, finally svn update. > > (2) would be easiest. (3) would be most failsafe. (1) might be more > useful for the project because it could uncover bugs in the dist-clean > target though. (OTOH one could argue that this should be a separate > regression test.) > I'd rather not use the nightly tester to test make dist-clean. I'm not sure how many people actually use make dist anything right now so it probably has bugs too. This should probably be investigated separately. I think the only way to ensure the tree is pristine is to do a clean checkout like it does now. So I think that should be the preferred way. However, I think its worthwhile to be able to update your tree and build using the nightly tester. Checking out and building llvm can be a time consuming process for people with slow network connections and slow machines. This is worthwhile in my opinion, but its not necessarily the solution to your problem if you want to make sure your tree is perfect. However, I think #2 is the better solution for your particular problem and I don't think you need to do any changes to the nightly tester, just tell it to use a new build directory. >> A -noreport option is probably a good idea too. > > OK, that should be easy to add. > >> Just be sure not to change what it sends to the website. That needs >> to >> stay the same. > > Sure. I think wrapping an if statement around the HTTP send should be > easy; the code of NewNightlyTester.pl isn't very complicated. > Cool. > On a tangent: > What's the best way to submit patches: Bugzilla? Something else? > Send to llvm-commits or llvm-dev (as long as its not too big). -Tanya P.S. I'm not sure if someone has gotten a chance to look at your dejagnu bugs you filed, but if not.. I'll try to take a look this weekend. Unfortunately, I've been preoccupied this week with family matters. > Regards, > Jo > > _______________________________________________ > 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 Sat Mar 8 19:05:35 2008 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Sat, 8 Mar 2008 22:05:35 -0300 Subject: [LLVMdev] llvm-gcc and mips In-Reply-To: <20d882600803071210yf585e04p9172cdf742d68214@mail.gmail.com> References: <20d882600802270838s7fbfd4a2r592696bd8f78e69@mail.gmail.com> <20d882600802280403p4e458ac2w51c62e299ac62f18@mail.gmail.com> <0C9DAA43-29CC-47F0-BF74-DD6B14C8A06A@apple.com> <20d882600802290523u72568fbbl4033c131b3aade06@mail.gmail.com> <20d882600803070622q479a7794i88cae8374f5815de@mail.gmail.com> <275e64e40803071128m783e375q9fd2f58a4d4a1166@mail.gmail.com> <20d882600803071210yf585e04p9172cdf742d68214@mail.gmail.com> Message-ID: <275e64e40803081705i2726666ahf78caa83a941a709@mail.gmail.com> Hi Kevin, > Supposed that you knew my approach was intentional (correct me if I'm > wrong), what problem did you see here? Yes, i'm trying to help raising possible problems. For example, there are Mips machines with different endianess, the llvm Mips default (Big) is different from the psp toochain default one (correct me if I'm wrong - Little), maybe this is messing up... Cheers, -- Bruno Cardoso Lopes http://www.brunocardoso.org "Morte: Mas n?o para voc? pistoleiro" From idadesub at users.sourceforge.net Sat Mar 8 22:03:19 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sat, 8 Mar 2008 20:03:19 -0800 Subject: [LLVMdev] [PATCH] Make the ocaml source comments work with ocamldoc. In-Reply-To: <> References: <> Message-ID: <1205035399-3719-1-git-send-email-idadesub@users.sourceforge.net> This patch cleans up the code so that it formats nicely with ocamldoc. It does not yet hook into the build system, though. --- bindings/ocaml/analysis/llvm_analysis.mli | 21 +- bindings/ocaml/bitreader/llvm_bitreader.mli | 13 +- bindings/ocaml/bitwriter/llvm_bitwriter.mli | 11 +- .../ocaml/executionengine/llvm_executionengine.mli | 118 ++-- bindings/ocaml/llvm/llvm.ml | 1 - bindings/ocaml/llvm/llvm.mli | 587 ++++++++++---------- 6 files changed, 373 insertions(+), 378 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 635c69d7c185e69426022351084ac4981e046e49.diff Type: text/x-patch Size: 91924 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080308/4014e036/attachment-0001.bin From rajikacc at gmail.com Sun Mar 9 00:46:22 2008 From: rajikacc at gmail.com (Rajika Kumarasiri) Date: Sun, 9 Mar 2008 12:16:22 +0530 Subject: [LLVMdev] participating in GSoC 2008 in LLVM Message-ID: <696bc1d50803082246i3020f06l7a4678116aa533a2@mail.gmail.com> Hello every body, I am a Computer Science and Engineering final year undergraduate in here [1]. As you all aware of GSoC 2008 program is now on [2]. I would like to participate in this on a project on LLVM. The reason why I selected LLVM is I am really interested in compiler theory. I took the one semester course on compiler theory and developed a lexical analyzer in C for a subset of Javascript (ECMA script) language. Code is available here[3] if any body interested to have a look. I have a pair knowledge in compilation process. Now I am browsing through LLVM and it's TODO list[4] to familiar with LLVM. Please guide me on doing a GSoC project for LLVM in this year. Thank you very much! (My resume available here [5]) Regards, Rajika [1] - http://www.cse.mrt.ac.lk/ [2] - http://code.google.com/soc/2008 [3] - http://rajikacc.googlepages.com/scanner.tar.gz [4] - http://llvm.org/OpenProjects.html [5] - http://rajikacc.googlepages.com/resume_rajika.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080309/3a24ecdf/attachment.html From gordonhenriksen at mac.com Sun Mar 9 01:21:24 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Sun, 9 Mar 2008 03:21:24 -0400 Subject: [LLVMdev] [PATCH] Make the ocaml source comments work with ocamldoc. In-Reply-To: <1205035399-3719-1-git-send-email-idadesub@users.sourceforge.net> References: <> <1205035399-3719-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: <86700365-1B22-4688-8655-5091DDA1F3A2@mac.com> On Mar 8, 2008, at 23:03, Erick Tryzelaar wrote: > This patch cleans up the code so that it formats nicely with > ocamldoc. It does not yet hook into the build system, though. Fantastic! Applied. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080303/059369.html I made a few minor edits: ? I added some blank lines to compensate for the the reduced prominence of the ------ lines. ? I changed [IoError "msg"] back to [IoError msg]; msg is not a literal string. ? I undid gratuitous whitespace changes in one file. Thanks Erick! ? Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080309/1b1e9ba2/attachment.html From christophe.avoinne at laposte.net Sun Mar 9 04:58:13 2008 From: christophe.avoinne at laposte.net (Christophe Avoinne) Date: Sun, 09 Mar 2008 10:58:13 +0100 Subject: [LLVMdev] llvm-gcc 4.2 in Xcode Message-ID: <47D3B4B5.8070407@laposte.net> Yes, I know. It's just when I see "happy", "Apple" and "iPhone SDK" on an Apple employee's mouth here, I felt a strong urge on the spur of moment to express my discontent towards Apple people who think they should make us buy their iMac just to be able to code freeware applications on iPhone. I've been waiting for so long time until an official SDK is released and finally you get : "no, guy ! you cannot ! you must be an Apple geek !". @Mike Stump (mrs at apple.com) : Just for your information, I'm in Europa. Here in France, iMac are very expensive for what they are. Anyway, that's a very selfish and rude way for you to tell us : "if you really want to code some iPhone applications, just buy an iMac. $600 is nothing". You know what ? 600? is NOT $600 (apparently the price for an old model and second-hand). Worse, the usual price I can find here is above 1000?. Not only that, for each model I can see, it is too much expensive for what its hardware is. I don't know how much money you earn but don't think people here can afford an iMac at the same price you can afford in USA. And the real point is : people shouldn't be forced to buy an iMac only so they could code iPhone applications. You don't need to answer, I was just ironically acknowledging Chris Lattner's annoucement. I'm not expecting for Apple to change their politics by my action here anyway. On 08/03/2008 20:33:08, Daniel Berlin (dberlin at dberlin.org) wrote: > This is almost certainly the wrong place to register your discontent. > > On Sat, Mar 8, 2008 at 4:23 AM, Christophe Avoinne > wrote: > > > I'm UNhappy to see the iPhone SDK REQUIRES an expensive iMac computer to > > be able freely to develop programs on iPhone/iPod Touch. > > > > > > > > On 08/03/2008 00:59:55, Chris Lattner (clattner at apple.com) wrote: > > > I'm > happy to announce that the iPhone SDK beta (released yesterday, > > > available on http://developer.apple.com) includes a beta version of > > > llvm-gcc 4.2 as part of the included Xcode 3.1 beta. From stefan.oestreicher at deluxe-design.at Sun Mar 9 08:07:57 2008 From: stefan.oestreicher at deluxe-design.at (Stefan Oestreicher) Date: Sun, 09 Mar 2008 14:07:57 +0100 Subject: [LLVMdev] linker error (llvm-config, eclipse) Message-ID: <47D3E12D.2060207@deluxe-design.at> Hi, I'm playing around with llvm and the Kaleidoscope tutorial and first of all I have to say I'm really impressed. LLVM rocks! Unfortunately I've now run into a linker error while trying to optimize the IR or turn it to bitcode and likely due to my very limited experience with c++ I just can't figure out how to resolve it. The linker complains that the llvm::WriteBitcodeToFile function is undefined, although I included llvm/Bitcode/ReaderWriter.h: undefined reference to `llvm::WriteBitcodeToFile(llvm::Module const*, std::basic_ostream >&) I also get the same undefined reference error if I call the llvm::createXXXPass and llvm::verifyXXX functions although I included all the files like in the Kaleidoscope tutorial. Everything else works fine though. I'm compiling my project with gcc-4.2 and llvm-config with --libs all and I'm using the RELEASE_22 tag from subversion and Eclipse CDT with managed make (on Ubuntu 32bit). This is the full command that's executed to link the project and its output: g++-4.2 `/home/stefan/projects/llvm/Debug/bin/llvm-config --ldflags --libs` `pkg-config --libs glibmm-2.4` -o"mojo" ./src/mojo.o ./src/mojo/lexer/state/Comment.o ./src/mojo/lexer/state/Default.o ./src/mojo/lexer/state/Numeric.o ./src/mojo/lexer/state/String.o ./src/mojo/lexer/Scanner.o ./src/mojo/lexer/Token.o ./src/mojo/ast/BinaryOperator.o ./src/mojo/ast/ConditionalBlock.o ./src/mojo/ast/FloatingPoint.o ./src/mojo/ast/Function.o ./src/mojo/ast/Integer.o ./src/mojo/ast/Invocation.o ./src/mojo/ast/Statement.o ./src/mojo/ast/Variable.o ./src/mojo/ast/WhileBlock.o ./src/mojo/IR.o ./src/mojo/Parser.o ./src/mojo.o: In function `writeBitCode(mojo::lexer::input::Interface&)': /home/stefan/projects/mojo2/Debug/../src/mojo.cc:140: undefined reference to `llvm::WriteBitcodeToFile(llvm::Module const*, std::basic_ostream >&)' collect2: ld gab 1 als Ende-Status zur?ck make: *** [mojo] Fehler 1 What am I missing? thanks in advance, Stefan Oestreicher From jo at durchholz.org Sun Mar 9 08:26:33 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 09 Mar 2008 14:26:33 +0100 Subject: [LLVMdev] NewNightlyTester.pl: split into phases? In-Reply-To: <2C3B6943-3F9C-4299-9868-C8B87AA20964@nondot.org> References: <1205002643.6742.41.camel@kurier> <1205016329.6742.68.camel@kurier> <2C3B6943-3F9C-4299-9868-C8B87AA20964@nondot.org> Message-ID: <1205069193.9336.30.camel@kurier> Am Samstag, den 08.03.2008, 15:11 -0800 schrieb Tanya Lattner: > >> A -noreport option is probably a good idea too. > > > > OK, that should be easy to add. > > > >> Just be sure not to change what it sends to the website. That needs > >> to > >> stay the same. > > > > Sure. I think wrapping an if statement around the HTTP send should be > > easy; the code of NewNightlyTester.pl isn't very complicated. > > > > Cool. Actually it's trivial. There was an undocumented $TESTING variable that already did exactly what -noreport was supposed to do. Patch is attached. Option is now named -nosubmit, in line with -submit-server and -submit-script. > P.S. I'm not sure if someone has gotten a chance to look at your > dejagnu bugs you filed, No, the bugs have remained undisturbed. (Except that maybe somebody changed the priority.) > but if not.. I'll try to take a look this > weekend. Unfortunately, I've been preoccupied this week with family > matters. I have to admit that I was beginning to wonder how fast bug reports and fixes would get recognized, but I kept reminding myself that all sorts of things can interfere (seems I guessed right with that). Oh, and take your time. Some things are more important than others :-) Regards, Jo -------------- next part -------------- A non-text attachment was scrubbed... Name: NewNightlyTest.pl.nosubmit.patch Type: text/x-patch Size: 1824 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080309/cec5f941/attachment-0001.bin From sam at bishop.dhs.org Sun Mar 9 10:11:45 2008 From: sam at bishop.dhs.org (Sam Bishop) Date: Sun, 09 Mar 2008 09:11:45 -0600 Subject: [LLVMdev] linker error (llvm-config, eclipse) In-Reply-To: <47D3E12D.2060207@deluxe-design.at> References: <47D3E12D.2060207@deluxe-design.at> Message-ID: <47D3FE31.60404@bishop.dhs.org> Hi, Stefan! Stefan Oestreicher wrote: > This is the full command that's executed to link the project and its output: > > g++-4.2 `/home/stefan/projects/llvm/Debug/bin/llvm-config --ldflags > --libs` `pkg-config --libs glibmm-2.4` -o"mojo" ./src/mojo.o The `llvm-config ...` and `pkg-config ...` sections need to be at the end. That ought to get you going. Sam From stefan.oestreicher at deluxe-design.at Sun Mar 9 10:48:59 2008 From: stefan.oestreicher at deluxe-design.at (Stefan Oestreicher) Date: Sun, 09 Mar 2008 16:48:59 +0100 Subject: [LLVMdev] linker error (llvm-config, eclipse) In-Reply-To: <47D3FE31.60404@bishop.dhs.org> References: <47D3E12D.2060207@deluxe-design.at> <47D3FE31.60404@bishop.dhs.org> Message-ID: <47D406EB.1050106@deluxe-design.at> Sam Bishop schrieb: > The `llvm-config ...` and `pkg-config ...` sections need to be at the > end. That ought to get you going. Yes, that's it, thank you very much for the quick help. I guess I should've rtfm more carefully, sorry. best regards Stefan Oestreicher From edwintorok at gmail.com Sun Mar 9 12:11:31 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sun, 09 Mar 2008 19:11:31 +0200 Subject: [LLVMdev] configure testing for linker flags using llvm-gcc Message-ID: <47D41A43.7090707@gmail.com> Hi, I tried to build glibc-2.7 with llvm-gcc4.2. First problem I hit is that glibc tests for -z relro linker flag support using this command: ${CC-cc} -v --help 2>&1|grep "z relro" This test fails for llvm-gcc since it doesn't output linker's --help. I bypassed this check temporarely by editing configure, but my question is where does this bug belong to? Is it an llvm-gcc bug, or is it glibc's configure bug? FWIW I tried icc, and it doesn't output "z relro" either when passed "-v --help". Best regards, --Edwin From sabre at nondot.org Sun Mar 9 14:51:21 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 9 Mar 2008 12:51:21 -0700 Subject: [LLVMdev] llvm-gcc 4.2 in Xcode In-Reply-To: <47D3B4B5.8070407@laposte.net> References: <47D3B4B5.8070407@laposte.net> Message-ID: <317E0265-C451-4F51-A158-B53E826F353D@nondot.org> On Mar 9, 2008, at 1:58 AM, Christophe Avoinne wrote: > Yes, I know. It's just when I see "happy", "Apple" and "iPhone SDK" on > an Apple employee's mouth here, I felt a strong urge on the spur of Again, this is extremely off topic, please take this somewhere else. Our policy for dealing with spammers is to block them from the list. Please stop this now. -Chris From sam at bishop.dhs.org Sun Mar 9 23:52:55 2008 From: sam at bishop.dhs.org (Sam Bishop) Date: Sun, 09 Mar 2008 22:52:55 -0600 Subject: [LLVMdev] linker error (llvm-config, eclipse) In-Reply-To: <47D406EB.1050106@deluxe-design.at> References: <47D3E12D.2060207@deluxe-design.at> <47D3FE31.60404@bishop.dhs.org> <47D406EB.1050106@deluxe-design.at> Message-ID: <47D4BEA7.4080607@bishop.dhs.org> Stefan Oestreicher wrote: > Yes, that's it, thank you very much for the quick help. I guess I > should've rtfm more carefully, sorry. I wouldn't be so hard on yourself. I knew the answer from experience, having done the exact same thing you did. I think the tutorial could use a footnote warning people about this. Regards, Sam From sabre at nondot.org Mon Mar 10 01:39:08 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 9 Mar 2008 23:39:08 -0700 Subject: [LLVMdev] participating in GSoC 2008 in LLVM In-Reply-To: <696bc1d50803082246i3020f06l7a4678116aa533a2@mail.gmail.com> References: <696bc1d50803082246i3020f06l7a4678116aa533a2@mail.gmail.com> Message-ID: <973A6AF8-A946-4236-B1D6-6366ECEB2942@nondot.org> On Mar 8, 2008, at 10:46 PM, Rajika Kumarasiri wrote: > Hello every body, > I am a Computer Science and Engineering final year undergraduate in > here [1]. > As you all aware of GSoC 2008 program is now on [2]. I would like to > participate in this on a project on LLVM. The reason why I selected > LLVM is I am really interested in compiler theory. > I took the one semester course on compiler theory and developed a > lexical analyzer in C for a subset of Javascript (ECMA script) > language. Code is available here[3] if any body interested to have a > look. I have a pair knowledge in compilation process. > Now I am browsing through LLVM and it's TODO list[4] to familiar > with LLVM. > Please guide me on doing a GSoC project for LLVM in this year. > Thank you very much! The best bet is to pick something off the open projects page and make a proposal. If you want feedback, you can send your proposal to llvmdev, otherwise you can file it away in the GSoC system when it is set up. Thanks! -Chris > > (My resume available here [5]) > Regards, > Rajika > > [1] - http://www.cse.mrt.ac.lk/ > [2] - http://code.google.com/soc/2008 > [3] - http://rajikacc.googlepages.com/scanner.tar.gz > [4] - http://llvm.org/OpenProjects.html > [5] - http://rajikacc.googlepages.com/resume_rajika.pdf > > > > > _______________________________________________ > 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/20080309/da4c34f2/attachment.html From sabre at nondot.org Mon Mar 10 01:57:54 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 9 Mar 2008 23:57:54 -0700 Subject: [LLVMdev] llvm/test: suffix or operands invalid for `push' In-Reply-To: <1204790926.7577.26.camel@kurier> References: <1204103370.6718.83.camel@kurier> <1204541377.7339.36.camel@kurier> <1204790926.7577.26.camel@kurier> Message-ID: On Mar 6, 2008, at 12:08 AM, Joachim Durchholz wrote: > > Am Mittwoch, den 05.03.2008, 23:03 -0800 schrieb Chris Lattner: >> On Mar 3, 2008, at 2:49 AM, Joachim Durchholz wrote: >> >>> Hi all, >>> >>> I found enough to explain the behaviour that I encountered. If I'm >>> correct, the bugs are just in the dejagnu-based test machinery, >>> not in >>> LLVM itself. >> >> Yep, I believe that. I haven't been following the whole thread very >> closely, what specific tests are affected here? > > test/C++Frontend/2006-11-06-StackTrace.cpp > test/C++Frontend/2006-11-30-NoCompileUnit.cpp > test/C++Frontend/2006-11-30-Pubnames.cpp > >> Before making any significant and widespread changes to llvm/test, >> please change one test and propose it as a model for other tests. > > The changes were actually very local: replace calls to gcc/g++/as with > calls to %compile_c and %compile_cxx. > I submitted bug reports with patches recently (look for bugs submitted > by jo at durchholz.org). The patches are tiny, so it's not a real problem > if they need to be modified, and I'm willing to try out any needed > modifications and resubmit the patches. > (%compile_cxx wouldn't work because %compile_c would be substituted > before, so the first patch corrects that.) Makes sense! I applied your patch, thanks! -Chris From sabre at nondot.org Mon Mar 10 02:22:05 2008 From: sabre at nondot.org (Chris Lattner) Date: Mon, 10 Mar 2008 00:22:05 -0700 Subject: [LLVMdev] Error messages in llvm-test In-Reply-To: <1204745618.7307.152.camel@kurier> References: <1204745618.7307.152.camel@kurier> Message-ID: <6AF619FA-86AF-4892-875B-5EEDA75C9209@nondot.org> On Mar 5, 2008, at 11:33 AM, Joachim Durchholz wrote: > Hi all, > > llvm-test fails on me in the first test (and many subsequent tests, > but > I hope that fixing the first test will allow me to continue). > > I see syntax errors from the C compiler and core dumps from llc. > Is any of this supposed to happen? > > This is still on my amd64 machine. However, the build process is using > the right incantation to compile (gcc-4.2 -m32 -Wl,-melf_i386). > The llvm-gcc toolchain installed is the precompiled 2.2 Red Hat > package > for Linux. > > See below for the error messages, and further below for the source > lines > mentioned in the messages. > > Should I worry about these messages? I haven't tested actually using > LLVM yet, and I may be barking up the wrong tree. (Having a clean test > suite *would* make me feel more confident, of course.) This looks like you are using a newer llvm-test than your llvm-gcc/ llvm tree are. In particular, CBE support for vector stuff is very new, and wasn't in 2.2. Please make sure that your llvm-test tree matches your llvm-gcc and llvm trees. -Chris From tonic at nondot.org Mon Mar 10 02:28:30 2008 From: tonic at nondot.org (Tanya Lattner) Date: Mon, 10 Mar 2008 00:28:30 -0700 Subject: [LLVMdev] NewNightlyTester.pl: split into phases? In-Reply-To: <1205069193.9336.30.camel@kurier> References: <1205002643.6742.41.camel@kurier> <1205016329.6742.68.camel@kurier> <2C3B6943-3F9C-4299-9868-C8B87AA20964@nondot.org> <1205069193.9336.30.camel@kurier> Message-ID: <59D5984B-F47A-40EE-A184-B41CC4392D02@nondot.org> On Mar 9, 2008, at 6:26 AM, Joachim Durchholz wrote: > Am Samstag, den 08.03.2008, 15:11 -0800 schrieb Tanya Lattner: >>>> A -noreport option is probably a good idea too. >>> >>> OK, that should be easy to add. >>> >>>> Just be sure not to change what it sends to the website. That needs >>>> to >>>> stay the same. >>> >>> Sure. I think wrapping an if statement around the HTTP send should >>> be >>> easy; the code of NewNightlyTester.pl isn't very complicated. >>> >> >> Cool. > > Actually it's trivial. There was an undocumented $TESTING variable > that > already did exactly what -noreport was supposed to do. > > Patch is attached. Option is now named -nosubmit, in line with > -submit-server and -submit-script. > Patch applied. Thanks!!!! -Tanya >> P.S. I'm not sure if someone has gotten a chance to look at your >> dejagnu bugs you filed, > > No, the bugs have remained undisturbed. (Except that maybe somebody > changed the priority.) > >> but if not.. I'll try to take a look this >> weekend. Unfortunately, I've been preoccupied this week with family >> matters. > > I have to admit that I was beginning to wonder how fast bug reports > and > fixes would get recognized, but I kept reminding myself that all sorts > of things can interfere (seems I guessed right with that). > > Oh, and take your time. Some things are more important than others :-) > > Regards, > Jo > < > NewNightlyTest > .pl.nosubmit.patch>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From rajikacc at gmail.com Mon Mar 10 03:05:08 2008 From: rajikacc at gmail.com (Rajika Kumarasiri) Date: Mon, 10 Mar 2008 13:35:08 +0530 Subject: [LLVMdev] participating in GSoC 2008 in LLVM In-Reply-To: <973A6AF8-A946-4236-B1D6-6366ECEB2942@nondot.org> References: <696bc1d50803082246i3020f06l7a4678116aa533a2@mail.gmail.com> <973A6AF8-A946-4236-B1D6-6366ECEB2942@nondot.org> Message-ID: <696bc1d50803100105i6961cc5dq4dba5fc989de9d8@mail.gmail.com> hello Chris, Thank you very much for your suggestions. I am trying to understand what LLVM is on these days by reading excellent set of LLVM documentations, manuals and developer list archives. As you said I'll pick a project from the TODO list and will discuss the proposal in this dev-list. I'll get back to you soon. Thanks again! Regards, Rajika On Mon, Mar 10, 2008 at 12:09 PM, Chris Lattner wrote: > > On Mar 8, 2008, at 10:46 PM, Rajika Kumarasiri wrote: > > Hello every body, > I am a Computer Science and Engineering final year undergraduate in here > [1]. > As you all aware of GSoC 2008 program is now on [2]. I would like to > participate in this on a project on LLVM. The reason why I selected LLVM is > I am really interested in compiler theory. > I took the one semester course on compiler theory and developed a lexical > analyzer in C for a subset of Javascript (ECMA script) language. Code is > available here[3] if any body interested to have a look. I have a pair > knowledge in compilation process. > Now I am browsing through LLVM and it's TODO list[4] to familiar with > LLVM. > Please guide me on doing a GSoC project for LLVM in this year. > Thank you very much! > > > The best bet is to pick something off the open projects page and make a > proposal. If you want feedback, you can send your proposal to llvmdev, > otherwise you can file it away in the GSoC system when it is set up. > > Thanks! > > -Chris > > > (My resume available here [5]) > Regards, > Rajika > > [1] - http://www.cse.mrt.ac.lk/ > [2] - http://code.google.com/soc/2008 > [3] - http://rajikacc.googlepages.com/scanner.tar.gz > [4] - http://llvm.org/OpenProjects.html > [5] - http://rajikacc.googlepages.com/resume_rajika.pdf > > > > > _______________________________________________ > 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 > > -- comp.lang.c - http://groups.google.com/group/comp.lang.c/topics -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080310/983211a4/attachment-0001.html From jon at ffconsultancy.com Mon Mar 10 07:30:14 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Mon, 10 Mar 2008 12:30:14 +0000 Subject: [LLVMdev] The OCaml Journal: first article on LLVM Message-ID: <200803101230.14210.jon@ffconsultancy.com> The OCaml Journal just published its first article on LLVM. This article describes the basic use of LLVM for static and JIT compilation from OCaml programs, including passing data from OCaml to run-time generated code and the compilation of non-trivial expression trees (including control flow constructs). The OCaml Journal is available here: http://www.ffconsultancy.com/products/ocaml_journal/?llvm The ability to generate FFI code on-the-fly is one of the most interesting aspects of LLVM from the OCaml perspective because OCaml's very static compiler implementation currently requires interfaces to be predefined and coded up manually as C stubs that are statically linked into an OCaml executable. With OCaml, existing DLLs can be invoked using run-time generated code, completely removing the need to write C stubs and allowing interoperable OCaml programs to be completely self-contained. This exciting application will be covered in detail in a future OCaml Journal article. Many thanks, -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From hyperquantum at gmail.com Mon Mar 10 07:56:47 2008 From: hyperquantum at gmail.com (HyperQuantum) Date: Mon, 10 Mar 2008 13:56:47 +0100 Subject: [LLVMdev] llvm-gcc and mips In-Reply-To: <275e64e40803081705i2726666ahf78caa83a941a709@mail.gmail.com> References: <20d882600802270838s7fbfd4a2r592696bd8f78e69@mail.gmail.com> <20d882600802280403p4e458ac2w51c62e299ac62f18@mail.gmail.com> <0C9DAA43-29CC-47F0-BF74-DD6B14C8A06A@apple.com> <20d882600802290523u72568fbbl4033c131b3aade06@mail.gmail.com> <20d882600803070622q479a7794i88cae8374f5815de@mail.gmail.com> <275e64e40803071128m783e375q9fd2f58a4d4a1166@mail.gmail.com> <20d882600803071210yf585e04p9172cdf742d68214@mail.gmail.com> <275e64e40803081705i2726666ahf78caa83a941a709@mail.gmail.com> Message-ID: <20d882600803100556j1db9f35cq93f8b48ef5568e95@mail.gmail.com> On Sun, Mar 9, 2008 at 2:05 AM, Bruno Cardoso Lopes wrote: > > Supposed that you knew my approach was intentional (correct me if I'm > > wrong), what problem did you see here? > > Yes, i'm trying to help raising possible problems. For example, there are > Mips machines with different endianess, the llvm Mips default (Big) is > different from > the psp toochain default one (correct me if I'm wrong - Little), maybe > this is messing > up... Good point. I added "-EL" to the options to get little-endian code, but it doesn't solve the problem. And I'm sure the code is compiled as 32-bit because my arch-info program prints 4 for sizeof(int) when compiled with the current llvm-gcc. Could it be something else I missed? Regards, Kevin From vvaditya12 at yahoo.com Mon Mar 10 11:42:52 2008 From: vvaditya12 at yahoo.com (aditya vishnubhotla) Date: Mon, 10 Mar 2008 09:42:52 -0700 (PDT) Subject: [LLVMdev] Verifier Error Message-ID: <502842.96346.qm@web56004.mail.re3.yahoo.com> Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I get the following verifier error. The "indvar.next4" instruction being mentioned in the step wise debug is not present in the LLVM IR (i.e IR before application of my transformation Pass). As seen below the operands of this instructions causing the segfault are NULL pointers. I am quite puzzled where this error is coming from and would be thankful for any hints in this regard. Aditya P.S : Error: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076469152 (LWP 31487)] 0x0861bf59 in llvm::PATypeHolder::get (this=0x8) at Type.cpp:46 46 const Type *NewTy = Ty->getForwardedType(); (gdb) bt #0 0x0861bf59 in llvm::PATypeHolder::get (this=0x8) at Type.cpp:46 #1 0x0837cac5 in llvm::PATypeHolder::operator llvm::Type* (this=0x8) at /work/aditya/llvm-2.2/include/llvm/AbstractTypeUser.h:149 #2 0x0837cadc in llvm::Value::getType (this=0x0) at /work/aditya/llvm-2.2/include/llvm/Value.h:87 #3 0x08637b52 in (anonymous namespace)::Verifier::visitBinaryOperator (this=0x8794f18, B=@0x87994a8) at Verifier.cpp:905 #4 0x0863d81e in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visitAdd (this=0x8794f18, I=@0x87994a8) at /work/aditya/llvm-2.2/include/llvm/Instruction.def:107 #5 0x0863de16 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, I=@0x87994a8) at /work/aditya/llvm-2.2/include/llvm/Instruction.def:107 #6 0x0863e229 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, Start= {> = {<> = {}, }, NodePtr = 0x877fdd0}, End= {> = {<> = {}, }, NodePtr = 0x8780030}) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:92 #7 0x0863e2a0 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, BB=@0x877cc28) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:107 #8 0x0863e2eb in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit > (this=0x8794f18, Start= {> = {<> = {}, }, NodePtr = 0x877cc50}, End= {> = {<> = {}, }, NodePtr = 0x877c9a8}) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:92 #9 0x0863e508 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, F=@0x8777980) at /work/aditya/llvm-2.2/include/llvm/Support/InstVisitor.h:103 #10 0x0863e557 in (anonymous namespace)::Verifier::runOnFunction (this=0x8794f18, F=@0x8777980) at Verifier.cpp:155 #11 0x0860e6ea in llvm::FPPassManager::runOnFunction (this=0x8793ca8, F=@0x8777980) at PassManager.cpp:1171 #12 0x0860e896 in llvm::FPPassManager::runOnModule (this=0x8793ca8, M=@0x8773d10) at PassManager.cpp:1191 #13 0x0860e3ba in llvm::MPPassManager::runOnModule (this=0x87731d8, M=@0x8773d10) at PassManager.cpp:1240 #14 0x0860e570 in llvm::PassManagerImpl::run (this=0x87766b8, M=@0x8773d10) at PassManager.cpp:1313 #15 0x0860e5c2 in llvm::PassManager::run (this=0xbfaeecf8, M=@0x8773d10) at PassManager.cpp:1345 #16 0x0836680d in main (argc=13, argv=0xbfaeeee4) at opt.cpp:426 When I tried debugging stepwise Error: Breakpoint 1, (anonymous namespace)::Verifier::visitBinaryOperator (this=0x8794f08, B=@0x87996a8) at Verifier.cpp:905 905 Assert1(B.getOperand(0)->getType() == B.getOperand(1)->getType(), 1: B.getName () = {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x879bfdc "indvar.next4"}} (gdb) print B->getParent()->getName() Attempt to take contents of a non-pointer value. (gdb) print B->getParent() Attempt to take contents of a non-pointer value. (gdb) print B.getOperand(0) $25 = (class llvm::Value *) 0x0 (gdb) print B.getOperand(1) $26 = (class llvm::Value *) 0x0 ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From dpatel at apple.com Mon Mar 10 12:45:30 2008 From: dpatel at apple.com (Devang Patel) Date: Mon, 10 Mar 2008 10:45:30 -0700 Subject: [LLVMdev] NewNightlyTester.pl: split into phases? In-Reply-To: <1205016329.6742.68.camel@kurier> References: <1205002643.6742.41.camel@kurier> <1205016329.6742.68.camel@kurier> Message-ID: On Mar 8, 2008, at 2:45 PM, Joachim Durchholz wrote: > Am Samstag, den 08.03.2008, 14:02 -0800 schrieb Tanya Lattner: >> - ability to check out llvm-gcc or update llvm-gcc and build it >> before >> running tests. In addition to using a prebuilt binary. > > Does it need a prebuilt binary? > I have been suspecting so since it has been failing with BUILD ERROR > for > me. I just haven't found the time to verify that yet. > > I have yet to try building llvm-gcc from sources though. The > instructions seem to be clear enough, but it's still possible that > I'll > hit a hidden snag. > Well, I'll try that anyway. Thanks!, this will be very useful. > I like my software well-done after all :-) - Devang From mrs at apple.com Mon Mar 10 17:21:32 2008 From: mrs at apple.com (Mike Stump) Date: Mon, 10 Mar 2008 15:21:32 -0700 Subject: [LLVMdev] configure testing for linker flags using llvm-gcc In-Reply-To: <47D41A43.7090707@gmail.com> References: <47D41A43.7090707@gmail.com> Message-ID: <73DD75A8-CBF6-4668-B861-D62E914847C1@apple.com> On Mar 9, 2008, at 10:11 AM, T?r?k Edwin wrote: > I tried to build glibc-2.7 with llvm-gcc4.2. > First problem I hit is that glibc tests for -z relro linker flag > support > using this command: > ${CC-cc} -v --help 2>&1|grep "z relro" > > This test fails for llvm-gcc since it doesn't output linker's --help. I suspect there is an APPLE LOCAL changes that avoid running ld with -- help, as darwin's ld doesn't have that flag. That code should be conditionalized better for darwin. So, that'd be a llvm-gcc-4.2 bug. From pvssvikas at gmail.com Tue Mar 11 00:29:01 2008 From: pvssvikas at gmail.com (vikas) Date: Tue, 11 Mar 2008 10:59:01 +0530 Subject: [LLVMdev] Problem building LLVM in cygwin environment. Message-ID: <6cbf6c150803102229o41821aa2y4d776a9696eac20f@mail.gmail.com> Hi All, prev I was working with llvm1.9 which I was able to successfully built on cygwin. both lvm-gcc & llvm were built with no issues. yesterday when I was trying to build the latest checkout I was facing some issue, can any one suggest me what I was missing, make[1]: Entering directory `/home/Administrator/llvm/lib/System' llvm[1]: Regenerating /home/Administrator/llvm/Makefile.config config.status: creating Makefile.config llvm[1]: Compiling Alarm.cpp for Debug build llvm[1]: Compiling Disassembler.cpp for Debug build In file included from /home/Administrator/llvm/include/llvm/System/Disassembler.h:18, from Disassembler.cpp:16: /home/Administrator/llvm/include/llvm/Support/DataTypes.h:69:3: #error "Don't have a definition for uint64_t on this platform" make[1]: *** [/home/Administrator/llvm/lib/System/Debug/Disassembler.o] Error 1 make[1]: Leaving directory `/home/Administrator/llvm/lib/System' make: *** [all] Error 1 Best Regards, -Vikas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080311/b218d2df/attachment.html From isanbard at gmail.com Tue Mar 11 03:52:28 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 11 Mar 2008 01:52:28 -0700 Subject: [LLVMdev] llvm-gcc 4.2 building failed on x86-64 In-Reply-To: <8abe0dc60803040124y5d0308eft5b60bc1c06f68823@mail.gmail.com> References: <8abe0dc60803040124y5d0308eft5b60bc1c06f68823@mail.gmail.com> Message-ID: <82DB374B-5FE6-4F10-B79A-42A02B77F62F@gmail.com> Hi Sheng, If you're still seeing this, try getting a .ll file from the code and then running bugpoint on it. If you're unable to get the .ll file (it still crashes when using -S -emit-llvm), then try running "delta" on the pre-processed file. See this webpage for details on how to run delta: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction This will at least give us a starting point. :-) -bw On Mar 4, 2008, at 1:24 AM, Zhou Sheng wrote: > Current llvm-gcc 4.2 building failed on X86-64, here is the dump > information: > > xgcc -B/home/zsth/projects/llvm.org/build/cfe4.2obj/./prev-gcc/ -B/ > home/zsth/projects/llvm.org/install/x86_64-unknown-linux-gnu/bin/ - > I../../../cfe4.2/libcpp -I. -I../../../cfe4.2/libcpp/../include - > I../../../cfe4.2/libcpp/include -DENABLE_LLVM -g -O2 -W -Wall - > Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style- > definition -Wmissing-format-attribute -pedantic -Wno-long-long - > I../../../cfe4.2/libcpp -I. -I../../../cfe4.2/libcpp/../include - > I../../../cfe4.2/libcpp/include -DENABLE_LLVM -c -o directives.o - > MT directives.o -MMD -MP -MF .deps/directives.Po ../../../cfe4.2/ > libcpp/directives.c > ../../../cfe4.2/libcpp/directives.c: In function 'do_pragma': > ../../../cfe4.2/libcpp/directives.c:1376: internal compiler error: > Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions > > Any ideas? > > My gcc version: > gcc -v > Using built-in specs. > Target: x86_64-redhat-linux > Configured with: ../gcc-4.0.4/configure --prefix=/home/toolman/ > gcc4.0.4-x86_64 --enable-languages=c,c++ --host=x86_64-redhat-linux > Thread model: posix > gcc version 4.0.4 > > > > Thanks, > Sheng. > _______________________________________________ > 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/20080311/f0d166f2/attachment.html From prabhat.saraswat at gmail.com Tue Mar 11 07:53:47 2008 From: prabhat.saraswat at gmail.com (Prabhat Kumar Saraswat) Date: Tue, 11 Mar 2008 13:53:47 +0100 Subject: [LLVMdev] Cloning a function with a changed return type Message-ID: Hi all, I was working on writing a slicing pass which would remove the parts of the code which are not relevant from the control flow point of view (mainly, the repetitive computations in the body of the loops etc). I have been able to implement it successfully. From the POV of implementation, the pass locates the conditional branches, and then the conditions are identified, all the instructions which could be affecting that value are kept while the rest of them are deleted. This is done by recursively iterating over the defintions and use of those values. Basically, This was done to get a function whose control flow structure is same as that of original, but the computation overhead is less. However, when the instructions are removed, several asserts are encountered during the verifier phase, mostly "Instruction does not dominate all uses!", rightly so because for the functions with a return value, all the instructions computing that value are removed by the pass. Thus, a better thing to do would be to remove the return value statements from the function, but then there are consistency issues with the function declaration, as the function is declared with a return type. Thus, my questions are: 1. Is it possible to clone all basic blocks of the function, along with the function arguments, inside another function, but changing the type of the function (mainly(only) the return type). thus basically ( to illustrate by an example) int foo (int a, int b) { int c; for(i=0;i>=a;i++) { c=c+b; } return c; } after slicing and cloning void foo_cloned (int a, int b) { for(i=0;i>=a;i++) { } } - the function return type is changed, always changed to void() (to be done!!) - computation overhead parts are removed (DONE already) - the control structure is basically the same (DONE already) 2. Alternatively, Is it possible to change the return type of the original function itself during the runonmodule pass ? Any ideas ? :) Danke, Regards Prabhat From jo at durchholz.org Tue Mar 11 10:14:16 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 11 Mar 2008 16:14:16 +0100 Subject: [LLVMdev] NewNightlyTester.pl: split into phases? In-Reply-To: References: <1205002643.6742.41.camel@kurier> Message-ID: <1205248456.7471.63.camel@kurier> Am Samstag, den 08.03.2008, 14:02 -0800 schrieb Tanya Lattner: > - ability to check out llvm-gcc or update llvm-gcc and build it before > running tests. This seems to be a bit more complicated than I thought. There are variations in the build process depending on whether it's a Darwin system or not, installed gcc version, and presence or absence of multilib extensions. I'm not sure that a simple-minded script can reliably detect all the differences. The alternative would be options and letting the user configure. Writing a script would be a difficult task, since it would have to be tested on as many architectures and configurations as possible, with the developer having to rely on error reports to fix things (difficult, lots of work, slow progress). Options, on the other hand, would tend to perpetuate current entry barriers. I'm not too happy about either option, but probably a choice must be made. Which shall it be? > In addition to using a prebuilt binary. This would be simple, of course. Regards, Jo From dpatel at apple.com Tue Mar 11 11:44:06 2008 From: dpatel at apple.com (Devang Patel) Date: Tue, 11 Mar 2008 09:44:06 -0700 Subject: [LLVMdev] NewNightlyTester.pl: split into phases? In-Reply-To: <1205248456.7471.63.camel@kurier> References: <1205002643.6742.41.camel@kurier> <1205248456.7471.63.camel@kurier> Message-ID: <43212762-FBD7-4C3A-A3E1-A055AFF60A92@apple.com> On Mar 11, 2008, at 8:14 AM, Joachim Durchholz wrote: > Am Samstag, den 08.03.2008, 14:02 -0800 schrieb Tanya Lattner: >> - ability to check out llvm-gcc or update llvm-gcc and build it >> before >> running tests. > > This seems to be a bit more complicated than I thought. There are > variations in the build process depending on whether it's a Darwin > system or not, installed gcc version, and presence or absence of > multilib extensions. I'm not sure that a simple-minded script can > reliably detect all the differences. IIUC, all target specific variations are in llvm-gcc configure options. In the beginning it is OK to let user specify llvm-gcc configure options. - Devang > > The alternative would be options and letting the user configure. > > Writing a script would be a difficult task, since it would have to be > tested on as many architectures and configurations as possible, with > the > developer having to rely on error reports to fix things (difficult, > lots > of work, slow progress). > Options, on the other hand, would tend to perpetuate current entry > barriers. > > I'm not too happy about either option, but probably a choice must be > made. > Which shall it be? > >> In addition to using a prebuilt binary. > > This would be simple, of course. > > Regards, > Jo > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tonic at nondot.org Tue Mar 11 12:41:31 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 11 Mar 2008 09:41:31 -0800 (PST) Subject: [LLVMdev] NewNightlyTester.pl: split into phases? In-Reply-To: <43212762-FBD7-4C3A-A3E1-A055AFF60A92@apple.com> References: <1205002643.6742.41.camel@kurier> <1205248456.7471.63.camel@kurier> <43212762-FBD7-4C3A-A3E1-A055AFF60A92@apple.com> Message-ID: >> Am Samstag, den 08.03.2008, 14:02 -0800 schrieb Tanya Lattner: >>> - ability to check out llvm-gcc or update llvm-gcc and build it >>> before >>> running tests. >> >> This seems to be a bit more complicated than I thought. There are >> variations in the build process depending on whether it's a Darwin >> system or not, installed gcc version, and presence or absence of >> multilib extensions. I'm not sure that a simple-minded script can >> reliably detect all the differences. > > IIUC, all target specific variations are in llvm-gcc configure > options. In the beginning it is OK to let user specify llvm-gcc > configure options. I was going to suggest this as well. We should make it *really* simple in that you just specifiy the configure line options (environment variable?) and then we may need a couple extra building options for LLVM (ie. OPTIMIZE_OPTION=-O2). -Tanya > > - > Devang >> >> The alternative would be options and letting the user configure. >> >> Writing a script would be a difficult task, since it would have to be >> tested on as many architectures and configurations as possible, with >> the >> developer having to rely on error reports to fix things (difficult, >> lots >> of work, slow progress). >> Options, on the other hand, would tend to perpetuate current entry >> barriers. >> >> I'm not too happy about either option, but probably a choice must be >> made. >> Which shall it be? >> >>> In addition to using a prebuilt binary. >> >> This would be simple, of course. >> >> Regards, >> Jo >> >> _______________________________________________ >> 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 Tue Mar 11 12:56:48 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 11 Mar 2008 10:56:48 -0700 Subject: [LLVMdev] Cloning a function with a changed return type In-Reply-To: References: Message-ID: <23EDDC77-EA72-45CD-8F35-D979FF5FA26B@nondot.org> On Mar 11, 2008, at 5:53 AM, Prabhat Kumar Saraswat wrote: > Thus, a better thing to do would be to remove the return value > statements from the function, but then there are consistency issues > with the function declaration, as the function is declared with a > return type. > > Thus, my questions are: > > 1. Is it possible to clone all basic blocks of the function, along > with the function arguments, inside another function, but changing the > type of the function (mainly(only) the return type). Yes, there are two ways to do this. You could keep the return value and change all returns to just return undef, this is easy but may not be sufficient for your needs. The second way is to actually change the function. Please look at the standard Dead Argument Elimination pass to see how this is done. -Chris From bruno.cardoso at gmail.com Tue Mar 11 14:56:18 2008 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Tue, 11 Mar 2008 16:56:18 -0300 Subject: [LLVMdev] llvm-gcc and mips In-Reply-To: <20d882600803100556j1db9f35cq93f8b48ef5568e95@mail.gmail.com> References: <20d882600802270838s7fbfd4a2r592696bd8f78e69@mail.gmail.com> <20d882600802280403p4e458ac2w51c62e299ac62f18@mail.gmail.com> <0C9DAA43-29CC-47F0-BF74-DD6B14C8A06A@apple.com> <20d882600802290523u72568fbbl4033c131b3aade06@mail.gmail.com> <20d882600803070622q479a7794i88cae8374f5815de@mail.gmail.com> <275e64e40803071128m783e375q9fd2f58a4d4a1166@mail.gmail.com> <20d882600803071210yf585e04p9172cdf742d68214@mail.gmail.com> <275e64e40803081705i2726666ahf78caa83a941a709@mail.gmail.com> <20d882600803100556j1db9f35cq93f8b48ef5568e95@mail.gmail.com> Message-ID: <275e64e40803111256k79ae49ecr1b9882a29a519f46@mail.gmail.com> > Good point. I added "-EL" to the options to get little-endian code, > but it doesn't solve the problem. And I'm sure the code is compiled as > 32-bit because my arch-info program prints 4 for sizeof(int) when > compiled with the current llvm-gcc. Could it be something else I > missed? I think that "-EL" will no work, I would try changing DataLayout("E-p:32:32:32") to DataLayout("e-p:32:32:32") on MipsTargetMachine.cpp, recompile llvm, cross-compile llvm-gcc to Mips and then use cc1. -- Bruno Cardoso Lopes ( now @ Cocos Island ) http://www.brunocardoso.cc ++ The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom + Isaac Asimov From jules at dsf.org.uk Tue Mar 11 15:14:37 2008 From: jules at dsf.org.uk (Jules) Date: Tue, 11 Mar 2008 20:14:37 +0000 Subject: [LLVMdev] Subversion head: build problem on cygwin? Message-ID: <47D6E82D.1020603@dsf.org.uk> Not sure if this is me or not, because this is the first time I've built LLVM on Cygwin, but I can't get a working compile. I've configured with the following options: $ ./configure --with-llvmgccdir=/cygdrive/i/Projects/llvm-gcc4.2-2.2 --enable-debug-runtime --enable-jit --enable-targets=x86 Configure doesn't suggest there's anything wrong, but when I try make, I almost immediately get the following error: make[1]: Entering directory `/cygdrive/i/Projects/llvm/lib/System' llvm[1]: Compiling Path.cpp for Debug build In file included from Path.cpp:201: Unix/Path.inc: In static member function `static llvm::sys::Path llvm::sys::Path::GetMainExecutable(const char*, void*)': Unix/Path.inc:256: error: `Dl_info' undeclared (first use this function) Unix/Path.inc:256: error: (Each undeclared identifier is reported only once for each function it appears in.) Unix/Path.inc:256: error: expected `;' before "DLInfo" Unix/Path.inc:257: error: `DLInfo' undeclared (first use this function) Unix/Path.inc:257: error: `dladdr' undeclared (first use this function) make[1]: *** [/cygdrive/i/Projects/llvm/lib/System/Debug/Path.o] Error 1 make[1]: Leaving directory `/cygdrive/i/Projects/llvm/lib/System' make: *** [all] Error 1 I have svn revision 48243, a relatively recent cygwin (1.5.24-2) with gcc 3.4.4 (i.e. not the 3.3.3 version described in the docs as not working), and WinXP. Any ideas? From delta17 at cox.net Tue Mar 11 16:25:25 2008 From: delta17 at cox.net (Jon Sargeant) Date: Tue, 11 Mar 2008 14:25:25 -0700 Subject: [LLVMdev] Rounding Mode for fptrunc Instruction Message-ID: <47D6F8C5.5090304@cox.net> Hi, What is the rounding mode for the fptrunc instruction? Round to zero? Round to nearest? Or undefined? Regards, Jon From dalej at apple.com Tue Mar 11 16:49:52 2008 From: dalej at apple.com (Dale Johannesen) Date: Tue, 11 Mar 2008 14:49:52 -0700 Subject: [LLVMdev] Rounding Mode for fptrunc Instruction In-Reply-To: <47D6F8C5.5090304@cox.net> References: <47D6F8C5.5090304@cox.net> Message-ID: On Mar 11, 2008, at 2:25 PM, Jon Sargeant wrote: > Hi, > > What is the rounding mode for the fptrunc instruction? Round to zero? > Round to nearest? Or undefined? > > Regards, > Jon Rounding mode handling is currently primitive. FPTRUNC is (de facto) round to nearest, as is the corresponding BE node FP_ROUND. FP_ROUND_IN_REG is round to nearest on X86 and round to zero on PowerPC. Better would be to have the rounding mode attached to the nodes (or multiple nodes), but nobody's done it yet. We are a long ways from having FENV_ACCESS work. From sam at bishop.dhs.org Tue Mar 11 16:57:20 2008 From: sam at bishop.dhs.org (Sam Bishop) Date: Tue, 11 Mar 2008 15:57:20 -0600 (MDT) Subject: [LLVMdev] Subversion head: build problem on cygwin? In-Reply-To: <47D6E82D.1020603@dsf.org.uk> References: <47D6E82D.1020603@dsf.org.uk> Message-ID: <25258.137.201.242.130.1205272640.squirrel@webmail.nwind.net> Hi, Jules. On Tue, March 11, 2008 2:14 pm, Jules wrote: > Not sure if this is me or not, because this is the first time I've built > LLVM on Cygwin, but I can't get a working compile. Last I checked, LLVM-on-Cygwin has at least two problems, and you've hit one of them. Working around them isn't too bad, though patches to fix them would be appreciated. > llvm::sys::Path::GetMainExecutable(const char*, void*)': > Unix/Path.inc:256: error: `Dl_info' undeclared (first use this function) > Unix/Path.inc:256: error: (Each undeclared identifier is reported only > once for each function it appears in.) > Unix/Path.inc:256: error: expected `;' before "DLInfo" > Unix/Path.inc:257: error: `DLInfo' undeclared (first use this function) > Unix/Path.inc:257: error: `dladdr' undeclared (first use this function) > ... > Any ideas? What LLVM is trying to do here is determine its own path. I don't know if the approach being used will work on Cygwin. (The code is very new, and it's never worked on Cygwin.) You could try reading the /proc/$$/exe symlink. I don't know how long Cygwin has been emulating /proc, though. Once you get past that, the other build errors you'll get will be due to code assuming that uint32_t is typedefed to int. On 32-bit Cygwin, it's typedefed to long. (They're the same size, but it still confuses the compiler.) This is an on-going problem, and I only use Cygwin in a pinch, so I've just modified the 32-bit typedefs in my /usr/include/stdint.h file. I've chosen to fight other battles. :) Hope this helps. Sam From jlerouge at apple.com Tue Mar 11 19:09:53 2008 From: jlerouge at apple.com (Julien Lerouge) Date: Tue, 11 Mar 2008 17:09:53 -0700 Subject: [LLVMdev] [PATCH] Get dlerror() messages Message-ID: <20080312000953.GB22476@jlerouge-mac.apple.com> Hello, Attached is a simple fix for getting error messages from dlerror in LoadLibraryPermanently. The current code modifies the value of a pointer that is passed by value, so the caller never gets the message. Hope this helps, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 PGP Public Key from: keyserver.pgp.com -------------- next part -------------- Index: lib/System/DynamicLibrary.cpp =================================================================== --- lib/System/DynamicLibrary.cpp (revision 48244) +++ lib/System/DynamicLibrary.cpp (working copy) @@ -63,7 +63,8 @@ std::string *ErrMsg) { void *H = dlopen(Filename, RTLD_LAZY); if (H == 0) { - ErrMsg = new std::string(dlerror()); + if (ErrMsg) + *ErrMsg = dlerror(); return true; } OpenedHandles.push_back(H); From lee225 at uiuc.edu Tue Mar 11 19:36:14 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Tue, 11 Mar 2008 19:36:14 -0500 (CDT) Subject: [LLVMdev] Which is the better optimization? Message-ID: <20080311193614.BCY68083@expms2.cites.uiuc.edu> Hello, LLVMers. While making some bitcodes from HL source codes including loops, I came to wonder which was the better one for the optimization between: llvm-gcc -O4 .... (using llvm-gcc optimization) and llvm-gcc -O0 .... (nonoptimization of llvm-gcc) opt -mem2reg -instcombine -indvars .... (w/ optimization pass) After some trials, 'llvm-gcc -O4' seemed better for optimization but not sure. Bitcodes from 'llvm-gcc -O0' w/ 'opt' were quite neat so easy to read and sometimes used less basic blocks than that from 'llvm-gcc -O4' trial. I am not sure about this, is there any body familiar with this? :^) Thanks, Seung From sabre at nondot.org Tue Mar 11 19:50:40 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 11 Mar 2008 17:50:40 -0700 Subject: [LLVMdev] [PATCH] Get dlerror() messages In-Reply-To: <20080312000953.GB22476@jlerouge-mac.apple.com> References: <20080312000953.GB22476@jlerouge-mac.apple.com> Message-ID: <5FA36096-2881-4DE9-8005-85C13BCA4F2B@nondot.org> On Mar 11, 2008, at 5:09 PM, Julien Lerouge wrote: > Attached is a simple fix for getting error messages from dlerror in > LoadLibraryPermanently. The current code modifies the value of a > pointer > that is passed by value, so the caller never gets the message. Your fix looks great, this fixes a memory leak too. Thanks Julien! http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080310/059605.html -Chris From sam at bishop.dhs.org Tue Mar 11 22:10:39 2008 From: sam at bishop.dhs.org (Sam Bishop) Date: Tue, 11 Mar 2008 21:10:39 -0600 Subject: [LLVMdev] Subversion head: build problem on cygwin? In-Reply-To: <25258.137.201.242.130.1205272640.squirrel@webmail.nwind.net> References: <47D6E82D.1020603@dsf.org.uk> <25258.137.201.242.130.1205272640.squirrel@webmail.nwind.net> Message-ID: <47D749AF.3010303@bishop.dhs.org> Sam Bishop wrote: > What LLVM is trying to do here is determine its own path. I don't know > if the approach being used will work on Cygwin. (The code is very new, > and it's never worked on Cygwin.) You could try reading the > /proc/$$/exe symlink. I don't know how long Cygwin has been emulating > /proc, though. The dladdr() code won't work on Cygwin; the function isn't available. However, I've attached a (tested) patch which implements the /proc/$$/exe approach. > Once you get past that, the other build errors you'll get will be due to > code assuming that uint32_t is typedefed to int. On 32-bit Cygwin, it's > typedefed to long. (They're the same size, but it still confuses the > compiler.) This is an on-going problem, and I only use Cygwin in a > pinch, so I've just modified the 32-bit typedefs in my > /usr/include/stdint.h file. I've chosen to fight other battles. :) LLVM compiles fine with my stdint.h changes, for what that's worth. Sam -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cygwin-getmainexecutable-impl.patch Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080311/9cd79853/attachment.pl From dalej at apple.com Tue Mar 11 22:42:56 2008 From: dalej at apple.com (Dale Johannesen) Date: Tue, 11 Mar 2008 20:42:56 -0700 Subject: [LLVMdev] Language lawyer question Message-ID: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> Looking through the gcc testsuite turned up an interesting edge case. Let's assume our target leaves a hole for alignment in struct x, as do x86 and powerpc. Do you think the following code can validly abort? struct x { char c; short s; }; int i; char *p; memset(&X, 0, sizeof(struct x)); memset(&Y, 22, sizeof(struct x)); X = Y; for (i=0, p=(char *)&X; i References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> Message-ID: <106BB1B6-D6A1-4E26-9352-1465320271EB@uiuc.edu> I thought pointer referencing like this was only valid for arrays. I could be wrong, but it might be that looping over the struct like that is invalid, making it undefined behavior (and then the hole doesn't matter because there is no valid way to access it). That said, I've definitely seen a lot of code that uses pointers to reference struct contents. On Mar 11, 2008, at 10:42 PM, Dale Johannesen wrote: > Looking through the gcc testsuite turned up an interesting edge > case. Let's assume our target leaves a hole for alignment in > struct x, as do x86 and powerpc. Do you think the following code > can validly abort? > > struct x { char c; short s; }; > int i; char *p; > memset(&X, 0, sizeof(struct x)); > memset(&Y, 22, sizeof(struct x)); > X = Y; > for (i=0, p=(char *)&X; i if (*p != 22) > abort(); > > The memset's and char-by-char comparison are clearly valid > references; the questionable bit is the struct copy, which llvm-gcc > currently does field-by-field, skipping the hole. C99 says > > In simple assignment (=), the value of the right operand is > converted to the type of the > assignment expression and replaces the value stored in the object > designated by the left > operand. > > I would take "replaces the value" to mean "replaces the entire > value", but it could be read otherwise, I suppose. > > The current code seems to me to assume holes in structs can't ever > be validly accessed, which isn't right, as we see here. They are > often nondeterministic (this is explicit for initialization in C99) > but not always. > > _______________________________________________ > 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/20080311/ef90cc14/attachment.html From ssen at apple.com Wed Mar 12 00:22:00 2008 From: ssen at apple.com (Shantonu Sen) Date: Tue, 11 Mar 2008 22:22:00 -0700 Subject: [LLVMdev] Language lawyer question In-Reply-To: <106BB1B6-D6A1-4E26-9352-1465320271EB@uiuc.edu> References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> <106BB1B6-D6A1-4E26-9352-1465320271EB@uiuc.edu> Message-ID: <24FC6583-0B8F-45B4-8483-A5D5FD4BEC65@apple.com> Does the test case indicate the why it was added? More of an implementation observation than a language interpretation, but if you add a "long l[6];" field, llvm-gcc continues to do field-by- field copies, but at l[7] it turns into machine-word copies, then at some point it turns into a rep/movsl (on Intel), and then at another threshold it turns into a memcpy(3) callout. What part of LLVM's codegen for copying "struct x { char c; short s; long l[6] };" considers a movb + movw + 6 movl's to efficient in either time or space (I was using -Os)? What changes when the overall structure gets to 64 bytes such that it decides its more efficient to copy a word at a time? I think the test case is bogus in terms of language correctness, but it might be indicative of a missed optimization for doing structure copies. Is that what GCC's test case is actually trying to validate? If so, it probably falls under a "gcc test case" and not a "C test case", if one can differentiate them. Maybe it would be reasonable for llvm-gcc to NOT copy the padding at - O0 and do explicit field copies, but to copy the padding as a side effect of an inlined memcpy() implementation for copying sizeof(struct x) when optimization is used. Copying using the largest appropriate registers/instructions given the structure size and alignment seems like it would always be faster than field copies, even for small structures. Shantonu Sent from my MacBook On Mar 11, 2008, at 9:47 PM, Patrick Meredith wrote: > I thought pointer referencing like this was only valid for arrays. > I could be wrong, but it might be that looping over the struct like > that > is invalid, making it undefined behavior (and then the hole doesn't > matter because there is no valid way to access it). That said, I've > definitely > seen a lot of code that uses pointers to reference struct contents. > > On Mar 11, 2008, at 10:42 PM, Dale Johannesen wrote: > >> Looking through the gcc testsuite turned up an interesting edge >> case. Let's assume our target leaves a hole for alignment in >> struct x, as do x86 and powerpc. Do you think the following code >> can validly abort? >> >> struct x { char c; short s; }; >> int i; char *p; >> memset(&X, 0, sizeof(struct x)); >> memset(&Y, 22, sizeof(struct x)); >> X = Y; >> for (i=0, p=(char *)&X; i> if (*p != 22) >> abort(); >> >> The memset's and char-by-char comparison are clearly valid >> references; the questionable bit is the struct copy, which llvm-gcc >> currently does field-by-field, skipping the hole. C99 says >> >> In simple assignment (=), the value of the right operand is >> converted to the type of the >> assignment expression and replaces the value stored in the object >> designated by the left >> operand. >> >> I would take "replaces the value" to mean "replaces the entire >> value", but it could be read otherwise, I suppose. >> >> The current code seems to me to assume holes in structs can't ever >> be validly accessed, which isn't right, as we see here. They are >> often nondeterministic (this is explicit for initialization in C99) >> but not always. >> >> _______________________________________________ >> 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/20080311/56040969/attachment-0001.html From dalej at apple.com Wed Mar 12 00:52:57 2008 From: dalej at apple.com (Dale Johannesen) Date: Tue, 11 Mar 2008 22:52:57 -0700 Subject: [LLVMdev] Language lawyer question In-Reply-To: <106BB1B6-D6A1-4E26-9352-1465320271EB@uiuc.edu> References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> <106BB1B6-D6A1-4E26-9352-1465320271EB@uiuc.edu> Message-ID: On Mar 11, 2008, at 9:47 PM, Patrick Meredith wrote: > I thought pointer referencing like this was only valid for arrays. > I could be wrong, but it might be that looping over the struct like > that > is invalid, making it undefined behavior (and then the hole doesn't > matter because there is no valid way to access it). That said, I've > definitely > seen a lot of code that uses pointers to reference struct contents. Anything can be addressed as characters. C99 6.5, see last line: An object shall have its stored value accessed only by an lvalue expression that has one of the following types:73) ?atype compatible with the effective type of the object, ?aquali?ed version of a type compatible with the effective type of the object, ?atype that is the signed or unsigned type corresponding to the effective type of the object, ?atype that is the signed or unsigned type corresponding to a quali?ed version of the effective type of the object, ?anaggregate or union type that includes one of the aforementioned types among its members (including, recursively,amember of a subaggregate or contained union), or ?a character type. C89 and C++ have similar language. On Mar 11, 2008, at 10:22 PM, Shantonu Sen wrote: > Does the test case indicate the why it was added? Actually it's testing something else entirely and tripped over this before it got to what it's supposed to be testing:( Just assumed it would work, as it does with gcc's codegen, of course. > More of an implementation observation than a language > interpretation, but if you add a "long l[6];" field, llvm-gcc > continues to do field-by-field copies, but at l[7] it turns into > machine-word copies, then at some point it turns into a rep/movsl > (on Intel), and then at another threshold it turns into a memcpy(3) > callout. > > What part of LLVM's codegen for copying "struct x { char c; short s; > long l[6] };" considers a movb + movw + 6 movl's to efficient in > either time or space (I was using -Os)? What changes when the > overall structure gets to 64 bytes such that it decides its more > efficient to copy a word at a time? Yeah, it's not efficient either. I didn't want to get into that since fixing the correctness issue, if there is one, will automatically fix this too. I think the justification is that breaking the struct into fields early makes it easier to do other optimizations. > I think the test case is bogus in terms of language correctness, Why? > but it might be indicative of a missed optimization for doing > structure copies. Is that what GCC's test case is actually trying to > validate? If so, it probably falls under a "gcc test case" and not a > "C test case", if one can differentiate them. There certainly are "gcc test cases", but so far I don't think this is one. > Maybe it would be reasonable for llvm-gcc to NOT copy the padding at > -O0 and do explicit field copies, but to copy the padding as a side > effect of an inlined memcpy() implementation for copying > sizeof(struct x) when optimization is used. Copying using the > largest appropriate registers/instructions given the structure size > and alignment seems like it would always be faster than field > copies, even for small structures. > On Mar 11, 2008, at 10:42 PM, Dale Johannesen wrote: > >> Looking through the gcc testsuite turned up an interesting edge >> case. Let's assume our target leaves a hole for alignment in >> struct x, as do x86 and powerpc. Do you think the following code >> can validly abort? >> >> struct x { char c; short s; }; >> int i; char *p; >> memset(&X, 0, sizeof(struct x)); >> memset(&Y, 22, sizeof(struct x)); >> X = Y; >> for (i=0, p=(char *)&X; i> if (*p != 22) >> abort(); >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080311/d8d7aa61/attachment.html From kcshin at arcs.kaist.ac.kr Wed Mar 12 02:22:19 2008 From: kcshin at arcs.kaist.ac.kr (=?ks_c_5601-1987?B?vcWwx8O2?=) Date: Wed, 12 Mar 2008 16:22:19 +0900 Subject: [LLVMdev] Question about use-def chain Message-ID: <006f01c88411$cee16e90$6ca44bb0$@kaist.ac.kr> Programmers? manual says we can iterate over a use-def chain by op_iterator. It works fine except for load and store instruction of stack variables. For example, a simple bitcode is like the below. i = alloca i32 store i32 0, i32* %i, align 4 %tmp1 = load i32* %i, align 4 If I apply a use-def chain to load instruction, I get alloca instruction. I think store instruction is a correct use-def chain. Am I right? Is there any other method to iterate over a use-def chain in this case? Regards, Keoncheol -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080312/89284d4d/attachment.html From ssen at apple.com Wed Mar 12 02:23:45 2008 From: ssen at apple.com (Shantonu Sen) Date: Wed, 12 Mar 2008 00:23:45 -0700 Subject: [LLVMdev] Language lawyer question In-Reply-To: References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> <106BB1B6-D6A1-4E26-9352-1465320271EB@uiuc.edu> Message-ID: On Mar 11, 2008, at 10:52 PM, Dale Johannesen wrote: >> I think the test case is bogus in terms of language correctness, > > Why? My gut. I listen to my gut. More seriously, C99 section 6.2.6.1 paragraph 6 has: > When a value is stored in an object of structure or union type, > including in a member > object, the bytes of the object representation that correspond to > anypadding bytes take > unspeci?ed values.42) and the footnote says: > 42) Thus, for example, structure assignment need not copyany padding > bits. I think that covers this case for at least C99. The test case should not assume the padding bytes are copied. If you assume "need not copy" semantics, the test case doesn't have much value for correctness. If you want LLVM to assume an implementation-specific "must copy" or "must not copy" behavior, you could tweak the test case as needed, I suppose. But under aggressive optimization, you rapidly approach "must copy" semantics, and then the question is why you don't do that for even the degenerate cases. So again, it turns into an optimization test case. Shantonu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080312/a9121da4/attachment.html From prabhat.saraswat at gmail.com Wed Mar 12 03:07:18 2008 From: prabhat.saraswat at gmail.com (Prabhat Kumar Saraswat) Date: Wed, 12 Mar 2008 09:07:18 +0100 Subject: [LLVMdev] Question about use-def chain In-Reply-To: <006f01c88411$cee16e90$6ca44bb0$@kaist.ac.kr> References: <006f01c88411$cee16e90$6ca44bb0$@kaist.ac.kr> Message-ID: Hi, Well, I ran into an exactly same problem some days back. The problem may lies in the fact that the store instruction does not have a name for its value, thus one can't really use a use-def iterator on the instruction itself. So, i tried a work around this, and it worked.. Basically, i check if the instruction is a store instruction, and if the first/second operand (which ever u want to iterate on, the first one is for the defs, and the second one is for the uses, since the value of first operand is stored in second) is an Instruction, one can iterate over the def-use tree easily. So implementation wise speaking.. . . if (StoreInst* storeInst = dyn_cast((*UI))) // If a store Instruction is found { cerr << " ### StoreFOUND " << *storeInst << "\n"; Instruction &stInst = *Keep; if (Instruction *Op = dyn_cast(stInst.getOperand(0))) // if the first operand is an instruction { IterateOverDef(Op); // Iterate over the definitions of this Instruction } } . . Also, note that the llvm IR is in the SSA form, the def-use chain length is 1, one definition and its use (except with the variables with multiple uses).. so if you want to iterate over or make a def-use tree for the whole module/function/basic block, you have to write a recursive routine, which steps over a def-use tree at a time. Hope this helps.. regards Prabhat 2008/3/12 ??? : > > > > > Programmers' manual says we can iterate over a use-def chain by op_iterator. > > It works fine except for load and store instruction of stack variables. > > > > For example, a simple bitcode is like the below. > > i = alloca i32 > > store i32 0, i32* %i, align 4 > > %tmp1 = load i32* %i, align 4 > > > > If I apply a use-def chain to load instruction, I get alloca instruction. > > I think store instruction is a correct use-def chain. > > Am I right? > > Is there any other method to iterate over a use-def chain in this case? > > > > Regards, > > Keoncheol > > > _______________________________________________ > 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 Mar 12 03:11:01 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 12 Mar 2008 09:11:01 +0100 Subject: [LLVMdev] Language lawyer question In-Reply-To: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> Message-ID: <200803120911.03730.baldrick@free.fr> Hi, > Looking through the gcc testsuite turned up an interesting edge case. > Let's assume our target leaves a hole for alignment in struct x, as do > x86 and powerpc. Do you think the following code can validly abort? I think you should ask this on the gcc mailing list. For what it's worth I'm sure that Ada does not require the values in padding to be preserved. > The current code seems to me to assume holes in structs can't ever be > validly accessed, which isn't right, as we see here. Of course they can be accessed, but that doesn't in itself mean that what they contain needs to be preserved by structure copies. Ciao, Duncan. From isanbard at gmail.com Wed Mar 12 03:59:26 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 12 Mar 2008 01:59:26 -0700 Subject: [LLVMdev] Question about use-def chain In-Reply-To: <006f01c88411$cee16e90$6ca44bb0$@kaist.ac.kr> References: <006f01c88411$cee16e90$6ca44bb0$@kaist.ac.kr> Message-ID: Hi ???, On Mar 12, 2008, at 12:22 AM, ??? wrote: > Programmers? manual says we can iterate over a use-def chain by > op_iterator. > > It works fine except for load and store instruction of stack > variables. > > > > For example, a simple bitcode is like the below. > > i = alloca i32 > > store i32 0, i32* %i, align 4 > > %tmp1 = load i32* %i, align 4 > > > > If I apply a use-def chain to load instruction, I get alloca > instruction. > > I think store instruction is a correct use-def chain. > > Am I right? > > Is there any other method to iterate over a use-def chain in this > case? > The op_iterator will tell you what definitions the instruction uses. So in this case, the "alloca" instruction is the correct one because the store instruction isn't defining %i. If you were to iterate over the uses of the alloca instruction, then you would get the "store" and "load" instructions. If you're trying to determine that %i is the same value for both the "store" and "load" instructions, then you'll probably want to compare the op_iterator values for both the "store" and "load" and see if they match. For example, %i in this case matches, because %i isn't redefined between the store and the load. -bw From jules at dsf.org.uk Wed Mar 12 06:43:29 2008 From: jules at dsf.org.uk (Jules) Date: Wed, 12 Mar 2008 11:43:29 +0000 Subject: [LLVMdev] Subversion head: build problem on cygwin? In-Reply-To: <25258.137.201.242.130.1205272640.squirrel@webmail.nwind.net> References: <47D6E82D.1020603@dsf.org.uk> <25258.137.201.242.130.1205272640.squirrel@webmail.nwind.net> Message-ID: <47D7C1E1.1030300@dsf.org.uk> Sam Bishop wrote: > Once you get past that, the other build errors you'll get will be due to > code assuming that uint32_t is typedefed to int. On 32-bit Cygwin, it's > typedefed to long. (They're the same size, but it still confuses the > compiler.) This is an on-going problem, and I only use Cygwin in a > pinch, so I've just modified the 32-bit typedefs in my > /usr/include/stdint.h file. I've chosen to fight other battles. :) > I think I'm with you. It's not like I can't run a Linux virtual machine on this hardware. :) From gabor at mac.com Wed Mar 12 08:49:10 2008 From: gabor at mac.com (Gabor Greif) Date: Wed, 12 Mar 2008 14:49:10 +0100 Subject: [LLVMdev] OpenProjects correction Message-ID: <47D7DF56.1000305@mac.com> I would do it myself, but this is in CVS: http://llvm.org/OpenProjects.html "Write a new backend for .... MIPS? ...." But: MIPS already has a backend :-) Cheers, Gabor From dalej at apple.com Wed Mar 12 09:37:58 2008 From: dalej at apple.com (Dale Johannesen) Date: Wed, 12 Mar 2008 07:37:58 -0700 Subject: [LLVMdev] Language lawyer question In-Reply-To: References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> <106BB1B6-D6A1-4E26-9352-1465320271EB@uiuc.edu> Message-ID: <0AD9C5CF-D55A-45DE-9C5E-7B5FAED5A2F7@apple.com> On Mar 12, 2008, at 12:23 AM, Shantonu Sen wrote: > On Mar 11, 2008, at 10:52 PM, Dale Johannesen wrote: > >>> I think the test case is bogus in terms of language correctness, >> >> Why? > > My gut. I listen to my gut. More seriously, C99 section 6.2.6.1 > paragraph 6 has: > >> When a value is stored in an object of structure or union type, >> including in a member >> object, the bytes of the object representation that correspond to >> anypadding bytes take >> unspeci?ed values.42) > > and the footnote says: > >> 42) Thus, for example, structure assignment need not copyany >> padding bits. Ah, thanks. I thought that was probably the intent but couldn't find it. That is definitive. > I think that covers this case for at least C99. The test case should > not assume the padding bytes are copied. > > If you assume "need not copy" semantics, the test case doesn't have > much value for correctness. If you want LLVM to assume an > implementation-specific "must copy" or "must not copy" behavior, you > could tweak the test case as needed, I suppose. But under aggressive > optimization, you rapidly approach "must copy" semantics, and then > the question is why you don't do that for even the degenerate cases. > So again, it turns into an optimization test case. > > Shantonu > > _______________________________________________ > 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/20080312/91426372/attachment.html From dberlin at dberlin.org Wed Mar 12 10:43:45 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 12 Mar 2008 11:43:45 -0400 Subject: [LLVMdev] Language lawyer question In-Reply-To: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> Message-ID: <4aca3dc20803120843w711b4227m2855ccbb994490a5@mail.gmail.com> On Tue, Mar 11, 2008 at 11:42 PM, Dale Johannesen wrote: > > Looking through the gcc testsuite turned up an interesting edge case. Let's > assume our target leaves a hole for alignment in struct x, as do x86 and > powerpc. Do you think the following code can validly abort? > > > struct x { char c; short s; }; > int i; char *p; > memset(&X, 0, sizeof(struct x)); > memset(&Y, 22, sizeof(struct x)); > X = Y; > for (i=0, p=(char *)&X; i if (*p != 22) > abort(); > > The memset's and char-by-char comparison are clearly valid references; the > questionable bit is the struct copy, which llvm-gcc currently does > field-by-field, skipping the hole. C99 says > > > In simple assignment (=), the value of the right operand is converted to the > type of the > assignment expression and replaces the value stored in the object designated > by the left > operand. > Padding is allowed to be skipped in structures in this case. See 6.2.6.1. Even further, all padding is allowed to take any value no matter how you try to set it (IE it always allowed to have an undefined value, even if you memset it). We happen to allow memset to clear padding bits, but we don't have to, AFAIK. --Dan From sabre at nondot.org Wed Mar 12 11:45:22 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 12 Mar 2008 09:45:22 -0700 Subject: [LLVMdev] Question about use-def chain In-Reply-To: <006f01c88411$cee16e90$6ca44bb0$@kaist.ac.kr> References: <006f01c88411$cee16e90$6ca44bb0$@kaist.ac.kr> Message-ID: <86FAE04F-8932-44F0-9F15-098541B98F89@nondot.org> On Mar 12, 2008, at 12:22 AM, ??? wrote: > Programmers? manual says we can > iterate over a use-def chain by op_iterator. > It works fine except for load and store instruction of stack > variables. > > For example, a simple bitcode is like the below. > i = alloca i32 > store i32 0, i32* %i, align 4 > %tmp1 = load i32* %i, align 4 > > If I apply a use-def chain to load instruction, I get alloca > instruction. > I think store instruction is a correct use-def chain. > Am I right? > Is there any other method to iterate over a use-def chain in this > case? You should try out Owen's MemDepAnalysis interface, which returns the load/store that another load/store depends on. Note that this is a fuzzy query: it depends on the precision of alias analysis. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080312/87e8af6f/attachment-0001.html From dalej at apple.com Wed Mar 12 12:01:46 2008 From: dalej at apple.com (Dale Johannesen) Date: Wed, 12 Mar 2008 10:01:46 -0700 Subject: [LLVMdev] Language lawyer question In-Reply-To: <4aca3dc20803120843w711b4227m2855ccbb994490a5@mail.gmail.com> References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> <4aca3dc20803120843w711b4227m2855ccbb994490a5@mail.gmail.com> Message-ID: <0BA96DB3-8690-4D85-82FE-1513CCDCD3AB@apple.com> On Mar 12, 2008, at 8:43 AM, Daniel Berlin wrote: > On Tue, Mar 11, 2008 at 11:42 PM, Dale Johannesen > wrote: > Padding is allowed to be skipped in structures in this case. > See 6.2.6.1. > Even further, all padding is allowed to take any value no matter how > you try to set it (IE it always allowed to have an undefined value, > even if you memset it). > > We happen to allow memset to clear padding bits, but we don't have > to, AFAIK. Yes, 6.2.6.1 is clear in C99, thanks. (C90 does not seem to have a corresponding section, though.) This is derived from gcc.dg/vmx/varargs-4.c from the gcc testsuite, if anybody feels like fixing it. From mrs at apple.com Wed Mar 12 14:49:31 2008 From: mrs at apple.com (Mike Stump) Date: Wed, 12 Mar 2008 12:49:31 -0700 Subject: [LLVMdev] Language lawyer question In-Reply-To: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> Message-ID: On Mar 11, 2008, at 8:42 PM, Dale Johannesen wrote: > Looking through the gcc testsuite turned up an interesting edge > case. Let's assume our target leaves a hole for alignment in struct > x, as do x86 and powerpc. Do you think the following code can > validly abort? No. The value of the object referred to be the left hand side must be replaced by the object on the right. The objects are defined to be a sequence of sizeof(x) bytes (I'm assuming the testcase does struct x X, Y;). If a byte isn't so updated, trivially, the object has not been replaced. From mrs at apple.com Wed Mar 12 15:02:43 2008 From: mrs at apple.com (Mike Stump) Date: Wed, 12 Mar 2008 13:02:43 -0700 Subject: [LLVMdev] Language lawyer question In-Reply-To: References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> Message-ID: On Mar 12, 2008, at 12:49 PM, Mike Stump wrote: > No. Doh, you know, I was trying to find the quoted wording... What the big print giveth, the small print takes away. Ignore me... I was wrong. From dberlin at dberlin.org Wed Mar 12 15:05:27 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 12 Mar 2008 16:05:27 -0400 Subject: [LLVMdev] Language lawyer question In-Reply-To: References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> Message-ID: <4aca3dc20803121305w1285fae9h31bfaf3e3e474e11@mail.gmail.com> On Wed, Mar 12, 2008 at 3:49 PM, Mike Stump wrote: > On Mar 11, 2008, at 8:42 PM, Dale Johannesen wrote: > > Looking through the gcc testsuite turned up an interesting edge > > case. Let's assume our target leaves a hole for alignment in struct > > x, as do x86 and powerpc. Do you think the following code can > > validly abort? > > No. The value of the object referred to be the left hand side must be > replaced by the object on the right. The objects are defined to be a > sequence of sizeof(x) bytes (I'm assuming the testcase does struct x > X, Y;). If a byte isn't so updated, trivially, the object has not > been replaced. Except that the standard specifically says the value of the padding bytes are undefined, and that you can do structure copies by member. From dag at cray.com Wed Mar 12 15:56:06 2008 From: dag at cray.com (David Greene) Date: Wed, 12 Mar 2008 14:56:06 -0600 Subject: [LLVMdev] MachineFunction Cloning Message-ID: <200803121556.06889.dag@cray.com> Is there a utility somewhere to clone a MachineFunction? I'd like to do a bunch of complicated transformations and then throw away the results and restore the initial state if I decide it's not good. Are there methods to save and restore dataflow information in the same way? I'm particularly interested in live interval information. -Dave From dberlin at dberlin.org Wed Mar 12 15:59:34 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 12 Mar 2008 16:59:34 -0400 Subject: [LLVMdev] Language lawyer question In-Reply-To: References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> Message-ID: <4aca3dc20803121359w1d33e009yf22335200ed8b0f6@mail.gmail.com> On Wed, Mar 12, 2008 at 4:02 PM, Mike Stump wrote: > On Mar 12, 2008, at 12:49 PM, Mike Stump wrote: > > No. > > Doh, you know, I was trying to find the quoted wording... What the > big print giveth, the small print takes away. Ignore me... I was > wrong. Sadly, a lot of these would be easier to read if they were written with exceptions first, then "except as above, blah blah blah" From evan.cheng at apple.com Wed Mar 12 17:15:22 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 12 Mar 2008 15:15:22 -0700 Subject: [LLVMdev] MachineFunction Cloning In-Reply-To: <200803121556.06889.dag@cray.com> References: <200803121556.06889.dag@cray.com> Message-ID: <7C21293F-14C5-4A0C-8446-6A682DFD1B67@apple.com> On Mar 12, 2008, at 1:56 PM, David Greene wrote: > Is there a utility somewhere to clone a MachineFunction? I'd like > to do a > bunch of complicated transformations and then throw away the results > and > restore the initial state if I decide it's not good. There is a MachineInstr::clone(), but not a MachineFunction::clone(). It's not clear to me whether it is difficult to add. > > Are there methods to save and restore dataflow information in the > same way? > I'm particularly interested in live interval information. There is a LiveInterval::Copy(), but that's about it. I think live interval information should be relatively easy to copy though. Evan > > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From bhurt at spnz.org Wed Mar 12 20:03:08 2008 From: bhurt at spnz.org (Brian Hurt) Date: Wed, 12 Mar 2008 21:03:08 -0400 (EDT) Subject: [LLVMdev] Language lawyer question In-Reply-To: References: <7BE3C832-759F-43B3-BDFD-904D50BB568E@apple.com> <106BB1B6-D6A1-4E26-9352-1465320271EB@uiuc.edu> Message-ID: On Wed, 12 Mar 2008, Shantonu Sen wrote: > If you assume "need not copy" semantics, the test case doesn't have much > value for correctness. If you want LLVM to assume an implementation-specific > "must copy" or "must not copy" behavior, you could tweak the test case as > needed, I suppose. But under aggressive optimization, you rapidly approach > "must copy" semantics, and then the question is why you don't do that for > even the degenerate cases. So again, it turns into an optimization test case. You're assuming the structure you're copying both from and to exist in memory. What happens if the compiler decided to place one of them in registers, such that a structure like: struct example { short x; double y; } is stored in two registers, with no padding? Brian From nicholas at mxc.ca Wed Mar 12 23:54:27 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Wed, 12 Mar 2008 21:54:27 -0700 Subject: [LLVMdev] exact semantics of 'nounwind' Message-ID: <47D8B383.704@mxc.ca> Hi everyone, Since I'm busy muddying the waters by changing how exception handling works, I thought I should ask for clarification on the exact behaviour of the current 'nounwind' attribute found on functions, calls and invokes. I was thinking these would be similar to the AA analysis notes like "doesNotAccessMemory" which is a provable property of the function or call site being analyzed. Duncan mentioned that doesNotThrow is actually an important language semantic meaning that an unwind calls a language-defined behaviour such as calling terminate(). What happens in other languages? Chris and I also couldn't agree on what the semantics ought to be going forward. He suggested having two bits, one to memoize an analysis proving that it can't unwind, and one to mean that an unwind triggers terminate. I happen to think that this ought to be explicitly modelled in the IR by arcing to another BB that calls terminate. We do agree that we need crystal-clear semantics in the language, so I'm taking it to the mailing list to see what if we can form a consensus. Nick From sabre at nondot.org Thu Mar 13 00:16:48 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 12 Mar 2008 22:16:48 -0700 Subject: [LLVMdev] OpenProjects correction In-Reply-To: <47D7DF56.1000305@mac.com> References: <47D7DF56.1000305@mac.com> Message-ID: <006DDB92-97B9-43E5-9AC3-9C5CDBD7A696@nondot.org> On Mar 12, 2008, at 6:49 AM, Gabor Greif wrote: > I would do it myself, but this is in CVS: > > http://llvm.org/OpenProjects.html > > "Write a new backend for .... MIPS? ...." > > But: MIPS already has a backend :-) Fixed. The ones that are left are getting pretty obscure :) -Chris From sabre at nondot.org Thu Mar 13 00:23:06 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 12 Mar 2008 22:23:06 -0700 Subject: [LLVMdev] Subversion head: build problem on cygwin? In-Reply-To: <47D749AF.3010303@bishop.dhs.org> References: <47D6E82D.1020603@dsf.org.uk> <25258.137.201.242.130.1205272640.squirrel@webmail.nwind.net> <47D749AF.3010303@bishop.dhs.org> Message-ID: On Mar 11, 2008, at 8:10 PM, Sam Bishop wrote: > Sam Bishop wrote: >> What LLVM is trying to do here is determine its own path. I don't >> know >> if the approach being used will work on Cygwin. (The code is very >> new, >> and it's never worked on Cygwin.) You could try reading the >> /proc/$$/exe symlink. I don't know how long Cygwin has been >> emulating >> /proc, though. > > The dladdr() code won't work on Cygwin; the function isn't > available. However, I've attached a (tested) patch which implements > the /proc/$$/exe approach. Looks good to me, applied: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080310/059671.html Please attach patches as attachments (and name the file ".patch" just in case). Mail readers commonly munge them (e.g. by removing trailing whitespace) if not, which prevents the patch from applying. Thanks Sam! -Chris From hs4233 at mail.mn-solutions.de Thu Mar 13 02:34:53 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Thu, 13 Mar 2008 08:34:53 +0100 Subject: [LLVMdev] Subversion head: build problem on cygwin? In-Reply-To: References: <47D6E82D.1020603@dsf.org.uk> <47D749AF.3010303@bishop.dhs.org> Message-ID: <200803130834.53526.hs4233@mail.mn-solutions.de> > Please attach patches as attachments (and name the file > ".patch" just in case). Mail readers commonly munge them > (e.g. by removing trailing whitespace) if not, which prevents > the patch from applying. I hope that this is not off-topic, but why is this? I'm doing some amount of linux-driver kernel work, and there you are urged to insert your patch directly into the body, not as an attachment. What you have to do is to disable word-wrapping. The various kernel subsystem maintainers then directly put the patches from their mailclients into git, and trailing whitespace doesn't seem to be a problem there. The benefit is that various web-based mailing list archives have the code snippets there directly, so they end up eventually in google. You can also much better comment on those patches, replying and writing your stuff in-between. For reference, here's an excerpt from linux/Documentation/SubmittingPatches: ------------------------------------------- 7) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of your code. For this reason, all patches should be submitting e-mail "inline". WARNING: Be wary of your editor's word-wrap corrupting your patch, if you choose to cut-n-paste your patch. Do not attach the patch as a MIME attachment, compressed or not. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes Linus a bit more time to process, decreasing the likelihood of your MIME-attached change being accepted. Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME. WARNING: Some mailers like Mozilla send your messages with ---- message header ---- Content-Type: text/plain; charset=us-ascii; format=flowed ---- message header ---- The problem is that "format=flowed" makes some of the mailers on receiving side to replace TABs with spaces and do similar changes. Thus the patches from you can look corrupted. To fix this just make your mozilla defaults/pref/mailnews.js file to look like: pref("mailnews.send_plaintext_flowed", false); // RFC 2646======= pref("mailnews.display.disable_format_flowed_support", true); ------------------------------------------- From gabor at mac.com Thu Mar 13 04:05:56 2008 From: gabor at mac.com (Gabor Greif) Date: Thu, 13 Mar 2008 10:05:56 +0100 Subject: [LLVMdev] OpenProjects correction References: 47D7DF56.1000305@mac.com Message-ID: <47D8EE74.6080504@mac.com> Thanks Chris, while at this, here is an attached patch to llvm.org! Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: llvm.org.patch Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080313/84b4ee29/attachment.pl From cmdkeen at gmx.de Thu Mar 13 06:47:08 2008 From: cmdkeen at gmx.de (Jan Rehders) Date: Thu, 13 Mar 2008 12:47:08 +0100 Subject: [LLVMdev] exact semantics of 'nounwind' In-Reply-To: <47D8B383.704@mxc.ca> References: <47D8B383.704@mxc.ca> Message-ID: <8802BC1F-E1D8-479E-A8EA-A762D0A522A9@gmx.de> Hi, as a language front end developer I am a bit terrified by any "unwind here will call terminate" semantics in the IR. I'd prefer the LLVM IR to be free from any assumptions about the languages compiled to it and this looks like C++ semantics sneaking into LLVM. Thus I'm under the expression the calling terminate semantics should be implemented by the front end. > Chris and I also couldn't agree on what the semantics ought to be > going > forward. He suggested having two bits, one to memoize an analysis > proving that it can't unwind, and one to mean that an unwind triggers > terminate. I happen to think that this ought to be explicitly modelled > in the IR by arcing to another BB that calls terminate. Having two bits might probably be a viable compromise. Just out of interest: how much does a will-not-throw-flag improve the generated code? Jan From baldrick at free.fr Thu Mar 13 08:56:15 2008 From: baldrick at free.fr (Duncan Sands) Date: Thu, 13 Mar 2008 14:56:15 +0100 Subject: [LLVMdev] exact semantics of 'nounwind' In-Reply-To: <8802BC1F-E1D8-479E-A8EA-A762D0A522A9@gmx.de> References: <47D8B383.704@mxc.ca> <8802BC1F-E1D8-479E-A8EA-A762D0A522A9@gmx.de> Message-ID: <200803131456.16087.baldrick@free.fr> Hi, > as a language front end developer I am a bit terrified by any "unwind > here will call terminate" semantics in the IR. in fact there aren't any. Suppose you mark a function call with the 'nounwind' flag. What happens is that when the code generators output the dwarf exception handling info into the object file (basically a sequence of instruction address ranges plus a "handler" address to jump to if an exception unwinds through an instruction in that range), they don't include that call instruction in any addess range. That's always fine if the call never results in an exception being unwound. If an exception does try to unwind through that call, what happens depends on the exception handling personality function. So what is this personality function and where does it come from? It is provided by the front-end, which needs to output an llvm.selector intrinsic call in the IR in the destination block of any invoke call. The llvm.selector intrinsic takes a pointer to the personality function as an argument. Thus the C++ front-end provides a pointer to the C++ personality function, the Ada front-end provides a pointer to the Ada personality function, and your front-end provides a pointer to your personality function. When an exception unwinds, the personality function is queried by the unwinder to decide what should be done. It is the personality function that decides what to do if it sees that the call is not contained in any address range. The Ada personality just keeps on unwinding in this case. The C++ personality function calls terminate. Your personality function makes its own decision. LLVM doesn't know about what the personality is going to do, and doesn't actually care. It just provides a means of communication between the front-end code generator and the personality function (part of the front-end's runtime library) by noting in the unwind table if the front-end set the nounwind flag on a call. > I'd prefer the LLVM IR > to be free from any assumptions about the languages compiled to it and > this looks like C++ semantics sneaking into LLVM. Thus I'm under the > expression the calling terminate semantics should be implemented by > the front end. It is - by the front-end's runtime. > > Chris and I also couldn't agree on what the semantics ought to be > > going > > forward. He suggested having two bits, one to memoize an analysis > > proving that it can't unwind, and one to mean that an unwind triggers > > terminate. I happen to think that this ought to be explicitly modelled > > in the IR by arcing to another BB that calls terminate. > > Having two bits might probably be a viable compromise. > > Just out of interest: how much does a will-not-throw-flag improve the > generated code? It allows you to eliminate invokes. For example llvm-gcc outputs "sin" with the nounwind flag set. Thus any call to "sin" will not throw an exception. Thus (the prune-eh pass does this) any function which only calls "sin" does not throw any exceptions, and thus can be marked nounwind too. Thus any function that only calls that function and "sin" cannot throw exceptions either and can also be marked nounwind. In this way the nounwind attribute is propagated throughout the call-graph. Then any invoke that calls one of these nounwind functions can be turned into a normal call, meaning that the unwind basic block can be discarded leading to further simplifications and a code size reduction etc. The final effect is quite significant for Ada, which tends to have a lot of exception handling code. Ciao, D. From hyperquantum at gmail.com Thu Mar 13 10:19:25 2008 From: hyperquantum at gmail.com (HyperQuantum) Date: Thu, 13 Mar 2008 16:19:25 +0100 Subject: [LLVMdev] llvm-gcc and mips In-Reply-To: <275e64e40803111256k79ae49ecr1b9882a29a519f46@mail.gmail.com> References: <20d882600802270838s7fbfd4a2r592696bd8f78e69@mail.gmail.com> <20d882600802280403p4e458ac2w51c62e299ac62f18@mail.gmail.com> <0C9DAA43-29CC-47F0-BF74-DD6B14C8A06A@apple.com> <20d882600802290523u72568fbbl4033c131b3aade06@mail.gmail.com> <20d882600803070622q479a7794i88cae8374f5815de@mail.gmail.com> <275e64e40803071128m783e375q9fd2f58a4d4a1166@mail.gmail.com> <20d882600803071210yf585e04p9172cdf742d68214@mail.gmail.com> <275e64e40803081705i2726666ahf78caa83a941a709@mail.gmail.com> <20d882600803100556j1db9f35cq93f8b48ef5568e95@mail.gmail.com> <275e64e40803111256k79ae49ecr1b9882a29a519f46@mail.gmail.com> Message-ID: <20d882600803130819m1aede60agb55f7d2fbd5d3665@mail.gmail.com> On Tue, Mar 11, 2008 at 8:56 PM, Bruno Cardoso Lopes wrote: > I think that "-EL" will no work, I would try changing > DataLayout("E-p:32:32:32") to > DataLayout("e-p:32:32:32") on MipsTargetMachine.cpp, recompile llvm, > cross-compile > llvm-gcc to Mips and then use cc1. OK, I did this and it works now. Thanks! Regards, Kevin Andr? From sabre at nondot.org Thu Mar 13 13:27:10 2008 From: sabre at nondot.org (Chris Lattner) Date: Thu, 13 Mar 2008 11:27:10 -0700 Subject: [LLVMdev] Subversion head: build problem on cygwin? In-Reply-To: <200803130834.53526.hs4233@mail.mn-solutions.de> References: <47D6E82D.1020603@dsf.org.uk> <47D749AF.3010303@bishop.dhs.org> <200803130834.53526.hs4233@mail.mn-solutions.de> Message-ID: On Mar 13, 2008, at 12:34 AM, Holger Schurig wrote: >> Please attach patches as attachments (and name the file >> ".patch" just in case). Mail readers commonly munge them >> (e.g. by removing trailing whitespace) if not, which prevents >> the patch from applying. > > I hope that this is not off-topic, but why is this? If you name the file *.txt, various mail clients inline the contents of the file implicitly when it sends it. The reason for including it as an attachment is that various *other* mail readers trim whitespace when they receive/display it. Word wrapping is another problem. In any case, attachments make all this trivial to deal with, which is why we prefer them. -Chris From sam at bishop.dhs.org Thu Mar 13 15:41:52 2008 From: sam at bishop.dhs.org (Sam Bishop) Date: Thu, 13 Mar 2008 14:41:52 -0600 (MDT) Subject: [LLVMdev] Subversion head: build problem on cygwin? In-Reply-To: References: <47D6E82D.1020603@dsf.org.uk> <25258.137.201.242.130.1205272640.squirrel@webmail.nwind.net> <47D749AF.3010303@bishop.dhs.org> Message-ID: <8713.137.201.242.130.1205440912.squirrel@webmail.nwind.net> On Wed, March 12, 2008 11:23 pm, Chris Lattner wrote: > Please attach patches as attachments (and name the file ".patch" just > in case). Mail readers commonly munge them (e.g. by removing trailing > whitespace) if not, which prevents the patch from applying. Hmm... What you got was the result of me telling Thunderbird to attach a file called cygwin-getmainexecutable-impl.patch. You can see here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013029.html All of my previous patches have been sent using SquirrelMail. It looks like I'll keep doing that... Thanks, Sam From gordonhenriksen at mac.com Thu Mar 13 17:42:32 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Thu, 13 Mar 2008 18:42:32 -0400 Subject: [LLVMdev] Subversion head: build problem on cygwin? In-Reply-To: <8713.137.201.242.130.1205440912.squirrel@webmail.nwind.net> References: <47D6E82D.1020603@dsf.org.uk> <25258.137.201.242.130.1205272640.squirrel@webmail.nwind.net> <47D749AF.3010303@bishop.dhs.org> <8713.137.201.242.130.1205440912.squirrel@webmail.nwind.net> Message-ID: <95722C07-D3C6-4B77-B5BD-1BEAAE8900FE@mac.com> On Mar 13, 2008, at 16:41, Sam Bishop wrote: > On Wed, March 12, 2008 11:23 pm, Chris Lattner wrote: > >> Please attach patches as attachments (and name the file ".patch" >> just in case). Mail readers commonly munge them (e.g. by removing >> trailing whitespace) if not, which prevents the patch from applying. > > Hmm... What you got was the result of me telling Thunderbird to > attach a file called cygwin-getmainexecutable-impl.patch. You can > see here: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013029.html > > All of my previous patches have been sent using SquirrelMail. It > looks like I'll keep doing that... Hi Sam, This should help: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-January/011992.html ? Gordon From criswell at uiuc.edu Fri Mar 14 11:48:16 2008 From: criswell at uiuc.edu (John Criswell) Date: Fri, 14 Mar 2008 10:48:16 -0600 Subject: [LLVMdev] Possible llvm.org Downtime Message-ID: <47DAAC50.1010000@uiuc.edu> Dear All, On Monday, March 17, the computer science building will have its cooling system turned off for maintenance. During that time, the offices and computer labs in the building may get warm, and as a consequence, we may need to power off machines. While I am hoping that down time will be unnecessary, we may need to power down llvm.org during the cooling outage. It is also possible that other services, such as the mailing lists, will be powered down as well. Please be prepared for downtime. We are told that the cooling outage will start at 8 am Central time and last no longer than 4 hours. We have also been told that it may take a few hours for temperatures to drop once the cooling system is restarted. If we need to take llvm.org down, I'm hoping that the latest we can have it back up is 1:00 pm, but it depends on how quickly the room can cool. My apologies both for any inconvenience this may cause as well as the inability to predict how long the downtime will last. We will try to keep things running as long as we can and to get things back up as soon as we can should powering down become necessary. Regards, John Criswell From bagel99 at gmail.com Fri Mar 14 12:17:15 2008 From: bagel99 at gmail.com (Bagel) Date: Fri, 14 Mar 2008 12:17:15 -0500 Subject: [LLVMdev] Question on use of subregs Message-ID: <47DAB31B.9090600@gmail.com> I'm trying to write a backend for a machine that has both byte and word instructions. Both varieties of instructions operate on the same set of general registers. A byte mode instruction on a general register always clears the upper bits. Register-to-register byte mode and work mode instructions set condition codes based on bytes and words and thus are not interchangeable. Do I need to have separate classes of registers for the work and byte instructions? If so, I assume the byte registers are declared as SubRegs? Also, this machine supports memory-to-memory operations in byte and word flavors. What do I need to look out for to support this. If have looked at the X86 *.td's, but that architecture is so complex it is hard to extract the information I need. Thanks, Bagel From wmatyjewicz at fastmail.fm Fri Mar 14 14:27:55 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Fri, 14 Mar 2008 20:27:55 +0100 Subject: [LLVMdev] Loop depth concept Message-ID: <47DAD1BB.4040805@fastmail.fm> Hi, I'm working on a simple data dependence analysis pass. I think it would be more natural (in the API and internally) if loops in nests were numbered from 0 than, as it's currently done, from 1. For example, in the former case the loop depth could be directly used to index a direction vector. IMHO it would be more clear in general, not only in the context of my project. Off course, it's only a cosmetic proposition and I'm not going to insist on that change. Currently, there are 2 methods to determine the depth of something: a) unsigned LoopInfo::getLoopDepth(BlockT *BB); // Return the loop nesting level of the specified block. b) unsigned Loop::getLoopDepth() // Return the nesting level of this loop. The reason why numbering in b) starts from 1 is to be consistent with numbering in a) (which starts from 0) --- the depth of BB is the same as the depth of loop it belongs to. But is it really that important? Currently, b) isn't used anywhere outside the LoopInfo.h. Starting numbering from 0 in both cases will also be consistent, but in other way;) "depth" may be defined as the number of loops a BB/loop is contained in. What do you think? Wojtek From wmatyjewicz at fastmail.fm Fri Mar 14 15:03:28 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Fri, 14 Mar 2008 21:03:28 +0100 Subject: [LLVMdev] Loop depth concept In-Reply-To: <47DAD1BB.4040805@fastmail.fm> References: <47DAD1BB.4040805@fastmail.fm> Message-ID: <47DADA10.7090707@fastmail.fm> > Starting numbering from 0 in both cases will also be consistent, but in > other way;) "depth" may be defined as the number of loops a BB/loop is > contained in. Forgot to mention that LoopInto::getLoopDepth(BlockT *B) could be renamed to 'getBlockDepth'... Wojtek From sabre at nondot.org Fri Mar 14 17:00:07 2008 From: sabre at nondot.org (Chris Lattner) Date: Fri, 14 Mar 2008 14:00:07 -0800 (PST) Subject: [LLVMdev] Loop depth concept In-Reply-To: <47DAD1BB.4040805@fastmail.fm> References: <47DAD1BB.4040805@fastmail.fm> Message-ID: On Fri, 14 Mar 2008, Wojciech Matyjewicz wrote: > Starting numbering from 0 in both cases will also be consistent, but in > other way;) "depth" may be defined as the number of loops a BB/loop is > contained in. > > What do you think? Starting at 1 is consistent with the idea of treating the body of the containing function as loop depth 0. Logically you can consider the function to be a "loop" which executes once per invocation. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From edwintorok at gmail.com Fri Mar 14 17:08:20 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sat, 15 Mar 2008 00:08:20 +0200 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: <47DAF754.5070503@gmail.com> David Greene wrote: > 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. > Please see bug #2155, I am seeing an additional testsuite failure with ScheduleDAG patch. I am not saying there is any problem with ScheduleDAG patch itself, it may be just exposing a previously hidden bug. [I tried to add you to the Cc: of the bugreport, but bugzilla didn't find your email address] Best regards, --Edwin From evan.cheng at apple.com Fri Mar 14 18:43:59 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 14 Mar 2008 16:43:59 -0700 Subject: [LLVMdev] Question on use of subregs In-Reply-To: <47DAB31B.9090600@gmail.com> References: <47DAB31B.9090600@gmail.com> Message-ID: <34239E3B-4B64-4F0A-A69A-1F69F8730043@apple.com> On Mar 14, 2008, at 10:17 AM, Bagel wrote: > I'm trying to write a backend for a machine that has both byte and > word > instructions. Both varieties of instructions operate on the same > set of > general registers. A byte mode instruction on a general register > always clears > the upper bits. Register-to-register byte mode and work mode > instructions set > condition codes based on bytes and words and thus are not > interchangeable. > > Do I need to have separate classes of registers for the work and byte > instructions? If so, I assume the byte registers are declared as > SubRegs? Yes. Then you want to declare byte registers as sub-registers of the word-registers. > > > Also, this machine supports memory-to-memory operations in byte and > word > flavors. What do I need to look out for to support this. The instruction selector can be taught to *fold* loads and stores. X86 has many load + modify + write instructions. You can take a look their patterns in X86InstrInfo.td Does the target have operations that operate on multiple memory operands? In theory, it's possible to write patterns to select these as well. > > > If have looked at the X86 *.td's, but that architecture is so > complex it is > hard to extract the information I need. Unfortunately x86 is the only target that supports both of the features you described. If you want to get started by looking at existing examples, it's pretty much the only choice. Evan > > > Thanks, > Bagel > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From joe at inspiringapps.com Fri Mar 14 23:01:56 2008 From: joe at inspiringapps.com (Joe Strout) Date: Fri, 14 Mar 2008 22:01:56 -0600 Subject: [LLVMdev] newbie questions about setting up a new project Message-ID: <7C047E80-D79A-4E7F-8ACD-20E04DE8D2C2@inspiringapps.com> I've downloaded and built LLVM 2.2, and I'm now trying to get to the point where I can get through the first tutorial (which seems to assume that you're already to the point of writing code and linking against LLVM). I've found the Projects.html doc page [1], which describes how to set up a project in the LLVM way. But some things are still unclear to me. (Please excuse my ignorance; I'm used to graphical IDEs and while I've made simple Makefiles before, there doesn't seem to be anything simple about integrating with the LLVM system.) 1. In the "Create a Project from the Sample Project" section, I'm stuck on the third simple step, "Add your source code and Makefiles to your source tree." If I knew how to do that, I wouldn't need the sample! :) The sample includes literally half a dozen Makefiles (if you include Makefile.common). Where exactly should I add "my" Makefile, and what should that file contain? 2. Under "Source Tree Layout," I see that "For each program that you build, you will have one directory in tools that will contain that program's source code." OK, I only want to build one program, and I see that the sample contains a tool subdirectory named "sample". So I renamed that to "tutorial-1", and inside it, I find main.d and main.o. What in the world is main.d? Can I just rename this to main.cpp, replace its mysterious contents with C++ code, and expect it to work? 3. Peeking at the Makefile inside tools/sample (now tools/ tutorial-1), the comments say that "sample is a dynamic library." I'm not sure why that is useful; I want to run a program. Also, quite curiously, there are no references at all that I can find to main.d (which I would presume is the source file sample should be built from). How would I go about modifying this to compile a gcc file (which I'll write following the tutorial), and make an actual executable? 4. With six different Makefiles lounging around in my project, which one would I want to invoke in order to just build my little test program? The one inside tools/tutorial-1, or the one in the project root, or what? (The docs do say "Typically, you will want to build your lib directory first followed by your tools directory" but it's not clear to me how I would do that, nor why I would be typically building libraries anyway.) I think maybe I need a "tutorial 0" that walks me through the steps of setting up my first project! Barring that, any tips you can provide will be greatly appreciated. Thanks, - Joe [1] http://www.llvm.org/releases/2.2/docs/Projects.html -- Joe Strout Inspiring Applications, Inc. http://www.InspiringApps.com From joe at inspiringapps.com Fri Mar 14 23:11:08 2008 From: joe at inspiringapps.com (Joe Strout) Date: Fri, 14 Mar 2008 22:11:08 -0600 Subject: [LLVMdev] newbie questions about setting up a new project Message-ID: <82AD4FE6-84EA-45A8-A1A6-73A9DA8147AA@inspiringapps.com> I've found part of the problem. There is a "projects" directory (including a "sample" subdirectory) inside the folder where I built LLVM, but there is ALSO one inside the llvm-2.2 directory. And they are different. I was working with the former, which contains no source code; the sample project under llvm-2.2 actually includes a main.c and sample.h, and generally makes a lot more sense. (The one in my build directory didn't even have an "include" folder; I created that based on the docs, but now I see I was barking up the wrong tree all along.) So, in such a situation where LLVM was not built in its own source directory, which "projects" folder should be used for my own projects? Thanks, - Joe From sam at bishop.dhs.org Fri Mar 14 23:11:59 2008 From: sam at bishop.dhs.org (Sam Bishop) Date: Fri, 14 Mar 2008 22:11:59 -0600 Subject: [LLVMdev] newbie questions about setting up a new project In-Reply-To: <7C047E80-D79A-4E7F-8ACD-20E04DE8D2C2@inspiringapps.com> References: <7C047E80-D79A-4E7F-8ACD-20E04DE8D2C2@inspiringapps.com> Message-ID: <47DB4C8F.5000705@bishop.dhs.org> Joe, Joe Strout wrote: > I've downloaded and built LLVM 2.2, and I'm now trying to get to the > point where I can get through the first tutorial (which seems to > assume that you're already to the point of writing code and linking > against LLVM). I've found the Projects.html doc page [1], which > describes how to set up a project in the LLVM way. But some things > are still unclear to me. Is the tutorial you're referring to the Projects.html page, or something different? And what OS are you using? Sam From joe at inspiringapps.com Fri Mar 14 23:33:46 2008 From: joe at inspiringapps.com (Joe Strout) Date: Fri, 14 Mar 2008 22:33:46 -0600 Subject: [LLVMdev] newbie questions about setting up a new project In-Reply-To: <47DB4C8F.5000705@bishop.dhs.org> References: <7C047E80-D79A-4E7F-8ACD-20E04DE8D2C2@inspiringapps.com> <47DB4C8F.5000705@bishop.dhs.org> Message-ID: <34481048-D4B5-45DA-9A69-CE592B3F091C@inspiringapps.com> On Mar 14, 2008, at 10:11 PM, Sam Bishop wrote: > Is the tutorial you're referring to the Projects.html page, or > something different? I was referring to , but laboring under the belief that it would first be a good idea to first get through GettingStarted.html, which recommends putting your stuff under "projects" based on "sample", and led me to Projects.html. I'm still stuck on that whole "projects" business -- the sample in my build directory doesn't match the description on Projects.html, but "make" works (apparently referencing source files under llvm-2.2/ projects); and the one under llvm-2.2 matches the description and contains source files, but "make" there doesn't work. However, after looking at the tutorial again, I realized that it doesn't matter -- I don't need a complex file hierarchy or even a Makefile; Owen provides a one-liner to compile and link the tutorial code at the bottom of the page. This works fine for me, regardless of where I put the source file. So, while I still think the projects/sample issue is a confusing stumbling block, I'm willing to ignore it for now and presume that deeper understanding will come later. > And what OS are you using? OS X 10.4.11. Best, - Joe From sam at bishop.dhs.org Fri Mar 14 23:51:05 2008 From: sam at bishop.dhs.org (Sam Bishop) Date: Fri, 14 Mar 2008 22:51:05 -0600 Subject: [LLVMdev] newbie questions about setting up a new project In-Reply-To: <34481048-D4B5-45DA-9A69-CE592B3F091C@inspiringapps.com> References: <7C047E80-D79A-4E7F-8ACD-20E04DE8D2C2@inspiringapps.com> <47DB4C8F.5000705@bishop.dhs.org> <34481048-D4B5-45DA-9A69-CE592B3F091C@inspiringapps.com> Message-ID: <47DB55B9.2060300@bishop.dhs.org> Joe Strout wrote: > However, after looking at the tutorial again, I realized that it > doesn't matter -- I don't need a complex file hierarchy or even a > Makefile; Owen provides a one-liner to compile and link the tutorial > code at the bottom of the page. This works fine for me, regardless > of where I put the source file. Yes, this is exactly what I was going to recommend. I haven't made a project like you are trying to do; maybe someone else can help you with that. But the tutorials you've found are great, and, as you've discovered, it doesn't take much to get them running. Good luck! Sam From idadesub at users.sourceforge.net Sat Mar 15 03:03:47 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sat, 15 Mar 2008 01:03:47 -0700 Subject: [LLVMdev] improving the ocaml binding's type safety Message-ID: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> I was talking to Gordon on #llvm earlier, and he challenged me with coming up with a way to improve the ocaml binding's type safety. We can't go letting haskell beat us now, can we? I think I got an easy solution with phantom types. For those who don't know what the problem is, the ocaml bindings share one type between whole class branches (like values). This means we need to downcast and assert to protect against, say, trying to get the parameter list of a constant. We could try to use ocaml objects to model the c++ classes, but then we run into issues with memory management and complexity. Phantom types are extra types that help with type checking, but are thrown away afterwards. This lets us create tags to distinguish between values and functions without any overhead. When we combine these with polymorphic variants, we get something that's very similar to inheritance. Here's an example. Polymorphic variants are similar to regular variants, but the names can be applied to anything. So, you can have: let a = `Foo 2 let b = `Foo "bar" And it's not a type error. You specify the type like this: type a = [ `Foo ] (* specify a type that can only be a `Foo. *) type b = [ `Foo | `Bar ] (* type can either be `Foo or `Bar. *) type c = [ a | `Bar ] (* equivalent to b. *) type d = [< `Foo | `Bar ] (* match any polymorphic variant that is a subset of [ `Foo | `Bar ], like [ `Foo ]. *) type e = [> `Foo | `Bar ] (* match any polymorphic variant that has a superset of [ `Foo | `Bar ] like [ `Foo | `Baz ] or even `Baz, since without brackets `Baz has the type of all the possible variants. *) So with this we can construct a simplified type hierarchy: type llvalue = [ `Value ] type llfunction = [ llvalue | `Function ] Finally, we'll create a polymorphic type that holds the phantom type: type 'a t And then define functions that work on these types. Since we want a function that can take an llvalue, we need to specify it like this: val use_value: [> `Value ] t -> unit val use_function: [> `Function ] t -> unit For llvalue and llfunction it's obvious that it'll match, but won't it also match `Foo? Yes it will. We'll work around this by making the type 't' abstract. Then, only our module can create values of it. We'll provide helper functions to create llvalues and llfunctions, which will preserve our invariants: val make_value : unit -> llvalue t val make_function : unit -> llfunction t Here's the full example: foo.mli: type 'a t type llvalue = [ `Value ] type llfunction = [ llvalue | `Function ] val use_value : [> `Value] t -> unit val use_function : [> `Function] t -> unit val make_value : unit -> llvalue t val make_function : unit -> llfunction t Finally here are some examples of uses that typecheck Foo.use_value (Foo.make_value ()) Foo.use_value (Foo.make_function ()) Foo.use_function (Foo.make_function ()) And just to be sure, this fails: Bar.use_function (Bar.make_value ()) with: This expression has type Foo.llvalue Foo.t but is here used with type ([> `Function ] as 'a) Foo.t Type Foo.llvalue = [ `Value ] is not compatible with type 'a The first variant type does not allow tag(s) `Function Does this sound like it could work, or am I missing something? From baldrick at free.fr Sat Mar 15 07:41:27 2008 From: baldrick at free.fr (Duncan Sands) Date: Sat, 15 Mar 2008 13:41:27 +0100 Subject: [LLVMdev] exact semantics of 'nounwind' In-Reply-To: <47D8B383.704@mxc.ca> References: <47D8B383.704@mxc.ca> Message-ID: <200803151341.27853.baldrick@free.fr> Hi Nick, > Since I'm busy muddying the waters by changing how exception handling > works, I thought I should ask for clarification on the exact behaviour > of the current 'nounwind' attribute found on functions, calls and invokes. > > I was thinking these would be similar to the AA analysis notes like > "doesNotAccessMemory" which is a provable property of the function or > call site being analyzed. Duncan mentioned that doesNotThrow is actually > an important language semantic meaning that an unwind calls a > language-defined behaviour such as calling terminate(). What happens in > other languages? > > Chris and I also couldn't agree on what the semantics ought to be going > forward. He suggested having two bits, one to memoize an analysis > proving that it can't unwind, and one to mean that an unwind triggers > terminate. I happen to think that this ought to be explicitly modelled > in the IR by arcing to another BB that calls terminate. > > We do agree that we need crystal-clear semantics in the language, so I'm > taking it to the mailing list to see what if we can form a consensus. the exotic part of nounwind semantics has now been removed (this was that the nounwind attribute had to be carefully preserved and propagated down to the codegenerators, which would put a special entry in the dwarf eh tables, because C++ semantic correctness was depending on the runtime being informed about nounwind calls), so now it can simply mean: this has been proved not to throw. And if it does throw, the effect is undefined. Ciao, Duncan. From jon at ffconsultancy.com Sat Mar 15 09:09:37 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Sat, 15 Mar 2008 14:09:37 +0000 Subject: [LLVMdev] improving the ocaml binding's type safety In-Reply-To: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> References: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> Message-ID: <200803151409.37307.jon@ffconsultancy.com> For all LLVM users out there: what kinds of errors do you spend the most time debugging? On Saturday 15 March 2008 08:03:47 Erick Tryzelaar wrote: > Does this sound like it could work, or am I missing something? Excellent idea. You might also consider building a data structure on the OCaml side that is equivalent to the LLVM code: module Op = struct type int_op = [ `IAdd | ... ] type float_op = [ `FAdd | ... ] type bool_op = [ `ILe of int_op * int_op | ... ] type t = [ int_op | float_op | bool_op | ... ] end Now you have int_op and bool_op as subtypes of Op.t. Note that neither of these approaches can be as expressive as using GADTs which, I assume, is what the Haskellers have done. On the other hand, this will probably catch errors that people don't make anyway (hence my opening question). There is an overhead in building these intermediate data structures but I expect it will be insignificant. You also have the advantage that you can print out the blocks that will be passed to LLVM. There are other errors that you can catch using a static type system as well. Several ops can only appear either at the start (e.g. phi node) or end (e.g. unconditional branch) of a block. These should be taken out of the set of general ops and blocks should have different types of start and end: module Block = struct type start = [ `None | Phi of ... ] type end = [ `Return of Op.t | `Branch of Block.t ref ] type t = start * Op.t list * end end Another practical advance I'd like to see is the LLVM bindings catching exceptions on the C++ side and reraising them in OCaml. At the moment you cannot get a stacktrace from an OCaml program that dies due to an exception being raised in LLVM which is a bit frustrating because you have to guess where the program died in the OCaml code. Still, this is all good stuff and I believe OCaml and LLVM have a rosy future together. :-) -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From gordonhenriksen at mac.com Sat Mar 15 10:49:37 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Sat, 15 Mar 2008 11:49:37 -0400 Subject: [LLVMdev] improving the ocaml binding's type safety In-Reply-To: <200803151409.37307.jon@ffconsultancy.com> References: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> <200803151409.37307.jon@ffconsultancy.com> Message-ID: <857BCEE1-3916-4666-8698-0E6102E3F40C@mac.com> On 2008-03-15, at 10:09, Jon Harrop wrote: > There is an overhead in building these intermediate data structures Converting enums to tags, yes. Phantom types no. > Several ops can only appear either at the start (e.g. phi node) or > end (e.g. unconditional branch) of a block. These should be taken > out of the set of general ops and blocks should have different types > of start and end: > > module Block = struct > type start = [ `None | Phi of ... ] > type end = [ `Return of Op.t | `Branch of Block.t ref ] > type t = start * Op.t list * end > end You're reinventing the object model here. There's no reason you shouldn't build your own IR separate from LLVM's, though. Just write an output algorithm to convert your IR into an llmodule using the bindings so you can interoperate with the LLVM infrastructure. > Another practical advance I'd like to see is the LLVM bindings > catching exceptions on the C++ side and reraising them in OCaml. At > the moment you cannot get a stacktrace from an OCaml program that > dies due to an exception being raised in LLVM which is a bit > frustrating because you have to guess where the program died in the > OCaml code. LLVM doesn't use exceptions. assert() failures just print to stderr and call abort() [= exit(1)], so they can't be caught. Even if they could, the stack couldn't be unwound (because the C++ exception tables are not emitted), so the program would leak memory and leave leave the heap in inconsistent state, inevitably leading to crashes. So this isn't going to happen. I'm not disputing that this is a pain point, however. I wouldn't be opposed to patches which check preconditions in the ocaml bindings layer and raise exceptions before calling into the C bindings. ? Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080315/07696bd8/attachment-0001.html From gordonhenriksen at mac.com Sat Mar 15 10:52:04 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Sat, 15 Mar 2008 11:52:04 -0400 Subject: [LLVMdev] improving the ocaml binding's type safety In-Reply-To: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> References: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> Message-ID: Hi Erick, On 2008-03-15, at 04:03, Erick Tryzelaar wrote: > I was talking to Gordon on #llvm earlier, and he challenged me with > coming up with a way to improve the ocaml binding's type safety. I > think I got an easy solution with phantom types. This could be a good step. I'm not sure I can predict all of the implications; I'd suggest you work up a proof of concept. The Value hierarchy is very complicated; it will take much work to apply this technique there, so I would suggest that be a second step. A similar but smaller problem presents itself in the Type hierarchy, which is (relatively speaking) simple. You may be able to implement type safety for Type as a layer on top of the existing bindings, or at least on top of the existing glue; you should have sufficient flexibility to do so because we do expose the TypeID enum via classify_type. In order to be useful, I think it will also be necessary to provide a new class of functions, a set of type checking helpers which play the same role as bool T::isa(T*), U* T::cast(T*), and U* T::dyn_cast(T*): (** @see [bool Type::isa(Type*)] *) val is_function_type : lltype t -> bool (** @see [FunctionType *Type::dyn_cast(Type*)] @raise Invalid_cast if the conversion is impossible. *) val as_function_type : lltype t -> `FunctionTy t For Value, it will be important to push the ISA routines through all of the layers (esp. for Value), but I think you can implement ISA routines in Ocaml relatively painlessly for Type. > Here's the full example: > > foo.mli: > type 'a t > type llvalue = [ `Value ] > type llfunction = [ llvalue | `Function ] > > val use_value : [> `Value] t -> unit > val use_function : [> `Function] t -> unit > > val make_value : unit -> llvalue t > val make_function : unit -> llfunction t > > Does this sound like it could work, or am I missing something? I think your sum types are incorrect here. Value is abstract; I think you want to say something like: type llglobal = [ `GlobalVariable | `Function | ... ] type llconst = [ llglobal | `ConstantInt | ... ] type llany = [ llconst | ... ] With only the concrete classes given tags. (doxygen is your friend here.) Try mocking up the type system for the concrete types GlobalVariable, Function, ConstantFP and ConstantInt; the abstract types GlobalValue, Value and Constant; and the functions set_value_name, linkage, declare_global, set_initializer, declare_function, entry_block, param, const_float, const_int, and const_array. That should be a reasonable survey. > We can't go letting haskell beat us now, can we? To truly compete with Bryan's Haskell bindings in terms of type safety, you'll need to go beyond preventing the cast macros in the C bindings from asserting and actually take over some of the work performed by the verifier. This is very difficult to do correctly outside of toy programs. For instance, given const_add x y, there are several conditions that would be interesting for the type checker to verify: (* Easy; is encoded in the C++ type system. *) isa(x) && isa(y) (* Harder; assertions in C++. *) x->getType() == y->getType() x->getType()->isIntOrIntVector() || x->getType()->isFPOrFPVector() I was very impressed that Bryan made build_call statically type check! Still, there are also some problems that I don't think are tractable. Consider param 1 f. Even if the type checker knows the type of f via something like `Function of ('a v -> 'b v -> 'c v) v, I don't think it's possible for the expression to have the correct type. Thought it might be possible with param0 f, param1 f, etc. And clearly params f can't have a type significantly more restricted than llvalue v array. Speaking of which, Bryan, if you're still reading the list, do you have any plans for submitting your Haskell bindings to the project? > ? Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080315/ea279b74/attachment.html From nicholas at mxc.ca Sat Mar 15 11:22:37 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Sat, 15 Mar 2008 09:22:37 -0700 Subject: [LLVMdev] exact semantics of 'nounwind' In-Reply-To: <200803151341.27853.baldrick@free.fr> References: <47D8B383.704@mxc.ca> <200803151341.27853.baldrick@free.fr> Message-ID: <47DBF7CD.8010100@mxc.ca> Duncan Sands wrote: > the exotic part of nounwind semantics has now been removed (this was that > the nounwind attribute had to be carefully preserved and propagated down > to the codegenerators, which would put a special entry in the dwarf eh > tables, because C++ semantic correctness was depending on the runtime > being informed about nounwind calls), so now it can simply mean: this > has been proved not to throw. And if it does throw, the effect is > undefined. Thanks Duncan! I think this is an improvement! Nick From bagel99 at gmail.com Sat Mar 15 11:42:47 2008 From: bagel99 at gmail.com (Bagel) Date: Sat, 15 Mar 2008 11:42:47 -0500 Subject: [LLVMdev] Question on use of subregs In-Reply-To: <34239E3B-4B64-4F0A-A69A-1F69F8730043@apple.com> References: <47DAB31B.9090600@gmail.com> <34239E3B-4B64-4F0A-A69A-1F69F8730043@apple.com> Message-ID: <47DBFC87.8070501@gmail.com> Thanks, I seem to have gotten sub-registers to work. I can't seem to suppress the zero-extend sometimes. There is no need to explicitly zero extend bytes to words on this machine as all byte operations do that. I have also gotten some memory-to-memory to work. Bagel Evan Cheng wrote: > On Mar 14, 2008, at 10:17 AM, Bagel wrote: > >> I'm trying to write a backend for a machine that has both byte and >> word >> instructions. Both varieties of instructions operate on the same >> set of >> general registers. A byte mode instruction on a general register >> always clears >> the upper bits. Register-to-register byte mode and work mode >> instructions set >> condition codes based on bytes and words and thus are not >> interchangeable. >> >> Do I need to have separate classes of registers for the work and byte >> instructions? If so, I assume the byte registers are declared as >> SubRegs? > > Yes. Then you want to declare byte registers as sub-registers of the > word-registers. > >> >> Also, this machine supports memory-to-memory operations in byte and >> word >> flavors. What do I need to look out for to support this. > > The instruction selector can be taught to *fold* loads and stores. X86 > has many load + modify + write instructions. You can take a look their > patterns in X86InstrInfo.td Does the target have operations that > operate on multiple memory operands? In theory, it's possible to write > patterns to select these as well. > >> >> If have looked at the X86 *.td's, but that architecture is so >> complex it is >> hard to extract the information I need. > > Unfortunately x86 is the only target that supports both of the > features you described. If you want to get started by looking at > existing examples, it's pretty much the only choice. > > Evan > >> >> Thanks, >> Bagel >> _______________________________________________ >> 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 Mar 15 15:23:37 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 15 Mar 2008 13:23:37 -0700 Subject: [LLVMdev] exact semantics of 'nounwind' In-Reply-To: <200803151341.27853.baldrick@free.fr> References: <47D8B383.704@mxc.ca> <200803151341.27853.baldrick@free.fr> Message-ID: <00A34B47-D55F-4903-B8B8-94C0AF03C90E@nondot.org> On Mar 15, 2008, at 5:41 AM, Duncan Sands wrote: >> We do agree that we need crystal-clear semantics in the language, >> so I'm >> taking it to the mailing list to see what if we can form a consensus. > > the exotic part of nounwind semantics has now been removed (this was > that > the nounwind attribute had to be carefully preserved and propagated > down > to the codegenerators, which would put a special entry in the dwarf eh > tables, because C++ semantic correctness was depending on the runtime > being informed about nounwind calls), so now it can simply mean: this > has been proved not to throw. And if it does throw, the effect is > undefined. Excellent, thanks Duncan! -Chris From idadesub at users.sourceforge.net Sat Mar 15 16:49:49 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sat, 15 Mar 2008 14:49:49 -0700 Subject: [LLVMdev] improving the ocaml binding's type safety In-Reply-To: References: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> Message-ID: <1ef034530803151449h4fab0a79hbaf910d8d17885c4@mail.gmail.com> So just to compare, here are two different typesafe phantom type implementations. One is bottom down, the other bottom up. This is an example of the following functions: string Value::getName() bool Constant::isNull() bool GlobalValue::isDeclaration() bool GlobalVariable::isGlobalConstant() bool Function::isVarArg() Driver code: val make_constant : unit -> llconstant t val make_global_variable : unit -> llglobalvariable t val make_function : unit -> llfunction t (* typesafe *) value_name (make_constant ());; value_name (make_global_variable ());; value_name (make_function ());; is_null (make_constant ());; is_declaration (make_global_variable ());; is_declaration (make_function ());; is_global_constant (make_global_variable ());; is_var_arg (make_function ());; (* type errors *) is_null (make_global_variable ());; is_null (make_function ());; is_declaration (make_constant ());; is_global_constant (make_constant ());; is_var_arg (make_constant ());; is_var_arg (make_global_variable ());; Bottom up. The advantage of this one is that we'll always be typesafe since we're saying the arguments must be a subset of the specified variants, and thus all the variants are closed. The disadvantage is that if we want to add another type we have to edit all the type definitions. This also means that we can't add another library that subclasses from something and still use these functions: type 'a t type llfunction = [ `Function ] type llglobalvariable = [ `GlobalVariable ] type llglobalvalue = [ llfunction | llglobalvariable ] type llconstant = [ `Constant ] type llvalue = [ llconstant | llglobalvalue ] val value_name : [< llvalue] t -> string val is_null : [< llconstant] t -> bool val is_declaration : [< llglobalvalue] t -> bool val is_global_constant : [< llglobalvariable] t -> bool val is_var_arg : [< llfunction] t -> bool The other way is top down. This lets us extend our types, but sacrifices some type safety, as we're saying that the arguments are a superset of the variants. We can control this by limiting who can create 't's: type 'a t type llvalue = [ `Value ] type llconstant = [ llvalue | `Constant ] type llglobalvalue = [ llvalue | `GlobalValue ] type llglobalvariable = [ llglobalvalue | `GlobalVariable ] type llfunction = [ llglobalvalue | `Function ] val value_name : [> `Value] t -> string val is_null : [> `Constant] t -> bool val is_declaration : [> `GlobalValue] t -> bool val is_global_constant : [> `GlobalVariable] t -> bool val is_var_arg : [> `Function] t -> bool So what's better to use? From robert.a.zeh at gmail.com Sat Mar 15 17:23:22 2008 From: robert.a.zeh at gmail.com (Robert Zeh) Date: Sat, 15 Mar 2008 17:23:22 -0500 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: <200802110606.m1B66mk5052431@star.math.spbu.ru> References: <200802110606.m1B66mk5052431@star.math.spbu.ru> Message-ID: Did anything ever come of the work on exception handling for x86_64? I'm having problems with exceptions on linux x86_64. Today, on x86_64 with a recently updated working copy of llvm, I tried calling a JITted function that calls an external function that throws: thrower.cpp: (which gets compiled into a dynamic library) extern "C" void throwexception() { throw 5; } My code that invokes the JIT: llvm::Function *q_main = implementationVisitor.m_module- >getFunction("q_main"); std::vector args; try { GenericValue GV=EE->runFunction(q_main, args); } catch (...) { printf("hello!\n"); } } And instead of printing out hello I got Program received signal SIGABRT, Aborted. [Switching to Thread 48011952506048 (LWP 6197)] 0x00002baaa72d1765 in raise () from /lib/libc.so.6 (gdb) where #0 0x00002baaa72d1765 in raise () from /lib/libc.so.6 #1 0x00002baaa72d31c0 in abort () from /lib/libc.so.6 #2 0x00002baaa6bcb7b4 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #3 0x00002baaa6bc9746 in ?? () from /usr/lib/libstdc++.so.6 #4 0x00002baaa6bc9773 in std::terminate () from /usr/lib/libstdc++.so.6 #5 0x00002baaa6bc985a in __cxa_throw () from /usr/lib/libstdc++.so.6 #6 0x00002baaa69046b7 in throwexception () from /usr/local/src/GQ/ libthrower.so #7 0x00002baaa777f06d in ?? () #8 0x34353530372e302d in ?? () #9 0x0000000000000030 in ?? () #10 0x000000000051d7b4 in llvmImplementationVisitorTest () at main.cpp: 365 #11 0x000000000051e06c in main (argc=1, argv=0x7fff047e0298) at main.cpp:389 Am I doing anything wrong? q_main looks like this: After pass manager: ; ModuleID = 'Q' define void @q_main() { entry: call void @throwexception( ) ret void } declare void @throwexception() declare void @abort() On Feb 11, 2008, at 12:06 AM, Anton Korobeynikov wrote: > 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From idadesub at users.sourceforge.net Sat Mar 15 18:17:07 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sat, 15 Mar 2008 16:17:07 -0700 Subject: [LLVMdev] improving the ocaml binding's type safety In-Reply-To: References: <0F9320C0-AEE5-425C-B344-0B3F3EF7F4FC@mac.com> Message-ID: <1ef034530803151617m12e98311t92c6db702eb91549@mail.gmail.com> On Sat, Mar 15, 2008 at 4:00 PM, Gordon Henriksen wrote: > What do the respective type errors look like? Top down looks like: File "foo.ml", line 21, characters 11-36: This expression has type Bar.llglobalvariable Bar.t but is here used with type ([> `Function ] as 'a) Bar.t Type Bar.llglobalvariable = [ `GlobalValue | `GlobalVariable | `Value ] is not compatible with type 'a The first variant type does not allow tag(s) `Function Bottom up looks like: File "foo.ml", line 21, characters 11-36: This expression has type Bar.llglobalvariable Bar.t but is here used with type ([< Bar.llfunction ] as 'a) Bar.t Type Bar.llglobalvariable = [ `GlobalVariable ] is not compatible with type 'a = [< `Function ] These two variant types have no intersection From gordonhenriksen at mac.com Sat Mar 15 17:56:27 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Sat, 15 Mar 2008 18:56:27 -0400 Subject: [LLVMdev] improving the ocaml binding's type safety In-Reply-To: <1ef034530803151449h4fab0a79hbaf910d8d17885c4@mail.gmail.com> References: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> <1ef034530803151449h4fab0a79hbaf910d8d17885c4@mail.gmail.com> Message-ID: <0F9320C0-AEE5-425C-B344-0B3F3EF7F4FC@mac.com> On Mar 15, 2008, at 17:49, Erick Tryzelaar wrote: > The other way is top down. This lets us extend our types, but > sacrifices some type safety, as we're saying that the arguments are > a superset of the variants. We can control this by limiting who can > create 't's: > > type 'a t > > type llvalue = [ `Value ] > type llconstant = [ llvalue | `Constant ] > type llglobalvalue = [ llvalue | `GlobalValue ] > type llglobalvariable = [ llglobalvalue | `GlobalVariable ] > type llfunction = [ llglobalvalue | `Function ] > > val value_name : [> `Value] t -> string > val is_null : [> `Constant] t -> bool > val is_declaration : [> `GlobalValue] t -> bool > val is_global_constant : [> `GlobalVariable] t -> bool > val is_var_arg : [> `Function] t -> bool Ah, I get it now. type b = [ a | `B ] is idiomatic type theoretician for b t is a subclass of a t. This seems slightly a hack, using sum types to do exactly the opposite of what they're designed for. :) I think you want to use the sum types for parameter typing; [> `GlobalValue ] is not compatible with llconstant. > Bottom up. The advantage of this one is that we'll always be > typesafe since we're saying the arguments must be a subset of the > specified variants, and thus all the variants are closed. The > disadvantage is that if we want to add another type we have to edit > all the type definitions. This also means that we can't add another > library that subclasses from something and still use these functions: > > type 'a t > type llfunction = [ `Function ] > type llglobalvariable = [ `GlobalVariable ] > type llglobalvalue = [ llfunction | llglobalvariable ] > type llconstant = [ `Constant ] > type llvalue = [ llconstant | llglobalvalue ] > > val value_name : [< llvalue] t -> string > val is_null : [< llconstant] t -> bool > val is_declaration : [< llglobalvalue] t -> bool > val is_global_constant : [< llglobalvariable] t -> bool > val is_var_arg : [< llfunction] t -> bool I find this intensely more intuitive. The LLVM IR is closed and self- contained within the VMCore library (modulo a couple of private User subclasses in the bitcode libraries), so that's not a problem. Clearly, these are syntactically very similar. With my above comment, the difference is literally > vs. <. Since the IR is closed, they're semantically similar as well. The extensible method is clearly preferable for extensible hierarchies, should we have cause to expose any methods on them. Passes are an example of this. What do the respective type errors look like? ? Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080315/08a6f9a5/attachment.html From alexandre.duchateau at gmail.com Sat Mar 15 18:48:45 2008 From: alexandre.duchateau at gmail.com (=?ISO-8859-1?Q?Alexandre_Duch=E2teau?=) Date: Sat, 15 Mar 2008 18:48:45 -0500 Subject: [LLVMdev] Array Dependence Analysis Message-ID: As part of the advanced compilers course semester project (at UIUC), we are starting to implement array dependence analysis for LLVM. As of now we are considering GCD and Banerjee tests. Any suggestion on features, tests and/or interface are welcome. Our deadline is at the beginning of may so hopefully by then we will have a working prototype to submit. -- Alexandre X. Duch?teau & Albert Sidelnik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080315/56316599/attachment-0001.html From gordonhenriksen at mac.com Sat Mar 15 21:33:59 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Sat, 15 Mar 2008 22:33:59 -0400 Subject: [LLVMdev] improving the ocaml binding's type safety In-Reply-To: <0F9320C0-AEE5-425C-B344-0B3F3EF7F4FC@mac.com> References: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> <1ef034530803151449h4fab0a79hbaf910d8d17885c4@mail.gmail.com> <0F9320C0-AEE5-425C-B344-0B3F3EF7F4FC@mac.com> Message-ID: <80344C50-6720-4DE8-BB59-27B287DF97CE@mac.com> Erick, After some experimentation, I'd prefer the closed system. LLVM has some type peculiarities like the commonality between CallInst and InvokeInst. I find that the closed type system lets me express such constraints more naturally. Expressing these constraints explicitly in the open system involves annotating the C++ class hierarchy with extra variants which are unnecessary in the closed model. Please use 'a Llvm.ty for Type and 'a Llvm.v for Value to save typing. These choices avoid conflicting with the common type binding t and the language keyword val, but promote these important types to the type names into the Llvm module (likely open'd) for brevity's sake. I don't have a better suggestion than just naming the variant sum types Llvm.ll_____. I considered some other options, but decided I'm not fond of them in practice. Thanks, Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080315/7c624f16/attachment.html From christopher.lamb at gmail.com Sat Mar 15 22:19:43 2008 From: christopher.lamb at gmail.com (Christopher Lamb) Date: Sat, 15 Mar 2008 20:19:43 -0700 Subject: [LLVMdev] Question on use of subregs In-Reply-To: <47DBFC87.8070501@gmail.com> References: <47DAB31B.9090600@gmail.com> <34239E3B-4B64-4F0A-A69A-1F69F8730043@apple.com> <47DBFC87.8070501@gmail.com> Message-ID: <4CDC7A7A-68D9-4DD5-9ECA-852868F70738@gmail.com> Fair warning, this area of the code generator is under active development! Take a look at how the x86-64 backend models the implicit sign extending using 'subreg_to_reg' in the X86Instr64bit.td file. -- Chris On Mar 15, 2008, at 9:42 AM, Bagel wrote: > Thanks, I seem to have gotten sub-registers to work. I can't seem > to suppress > the zero-extend sometimes. There is no need to explicitly zero > extend bytes to > words on this machine as all byte operations do that. > > I have also gotten some memory-to-memory to work. > > Bagel > > Evan Cheng wrote: >> On Mar 14, 2008, at 10:17 AM, Bagel wrote: >> >>> I'm trying to write a backend for a machine that has both byte and >>> word >>> instructions. Both varieties of instructions operate on the same >>> set of >>> general registers. A byte mode instruction on a general register >>> always clears >>> the upper bits. Register-to-register byte mode and work mode >>> instructions set >>> condition codes based on bytes and words and thus are not >>> interchangeable. >>> >>> Do I need to have separate classes of registers for the work and >>> byte >>> instructions? If so, I assume the byte registers are declared as >>> SubRegs? >> >> Yes. Then you want to declare byte registers as sub-registers of the >> word-registers. >> >>> >>> Also, this machine supports memory-to-memory operations in byte and >>> word >>> flavors. What do I need to look out for to support this. >> >> The instruction selector can be taught to *fold* loads and stores. >> X86 >> has many load + modify + write instructions. You can take a look >> their >> patterns in X86InstrInfo.td Does the target have operations that >> operate on multiple memory operands? In theory, it's possible to >> write >> patterns to select these as well. >> >>> >>> If have looked at the X86 *.td's, but that architecture is so >>> complex it is >>> hard to extract the information I need. >> >> Unfortunately x86 is the only target that supports both of the >> features you described. If you want to get started by looking at >> existing examples, it's pretty much the only choice. >> >> Evan >> >>> >>> Thanks, >>> Bagel >>> _______________________________________________ >>> 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/20080315/a833de1f/attachment.html From idadesub at users.sourceforge.net Sun Mar 16 02:21:05 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sun, 16 Mar 2008 00:21:05 -0700 Subject: [LLVMdev] improving the ocaml binding's type safety In-Reply-To: <80344C50-6720-4DE8-BB59-27B287DF97CE@mac.com> References: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> <1ef034530803151449h4fab0a79hbaf910d8d17885c4@mail.gmail.com> <0F9320C0-AEE5-425C-B344-0B3F3EF7F4FC@mac.com> <80344C50-6720-4DE8-BB59-27B287DF97CE@mac.com> Message-ID: <1ef034530803160021j641b536crecebc01d5a7e75e4@mail.gmail.com> On Sat, Mar 15, 2008 at 7:33 PM, Gordon Henriksen wrote: > After some experimentation, I'd prefer the closed system. LLVM has some type > peculiarities like the commonality between CallInst and InvokeInst. I find > that the closed type system lets me express such constraints more naturally. > Expressing these constraints explicitly in the open system involves > annotating the C++ class hierarchy with extra variants which are unnecessary > in the closed model. It looks like you might be right, and open variants might not be able to handle the pseudo-shared functions like llvm::CallInst::doesNotReturn and llvm::InvokeInst::doesNotReturn. We can't do the naive val does_not_return : [> `CallInst | `InvokeInst] t -> bool Like we can with closed variants: val does_not_return : [< llcallinst | llinvokeinst] t -> bool. Although... what if we just add another variant? This would work: type llcallinst = [ llinstruction | `CallInst | `CallSite ] type llinvokeinst = [ llinstruction | `InvokeInst | `CallSite ] val does_not_return : [> `CallSite] t -> bool It makes the variant types a little more complicated, but end users wouldn't work directly with the variants so there might not be that much added complexity. They'd just specify "llcallinst t" and the like. The variants would pretty much only get used in llvm.ml. What are other problems that I'm missing? Have any other ideas on when adding yet another variant really would break things down? I have to think about this more. I just don't understand polymorphic types very well. > Please use 'a Llvm.ty for Type and 'a Llvm.v for Value to save typing. These > choices avoid conflicting with the common type binding t and the language > keyword val, but promote these important types to the type names into the > Llvm module (likely open'd) for brevity's sake. > > I don't have a better suggestion than just naming the variant sum types > Llvm.ll_____. I considered some other options, but decided I'm not fond of > them in practice. I think we'd need only one definition of "type 'a whatever". The phantom type would be enough to distinguish everything. For instance, lablgtk has a "type 'a obj" that they use as the base type for all of their variants, which I might copy. We can even hide this type by naming the variants something like "llfunction_variants" and then "type llfunction = llfunction_variants obj" to have roughly the same interface as before. What about putting the types (and functions) in modules, like ModuleProvider? It'd be like my scheme to break up llvm.ml into multiple files without actually splitting it up :) Then you could open Llvm and reference Value.t without obscuring anything. If not, then maybe we should unpack ModuleProvider from a module (which I'd prefer not to do). I was unsure of if it were better to add new functionality in the top level or in a module, so I erred towards module. I'd also like to be able to call "Module.create" instead of "create_module". We could even open or abbreviate the module name in scope for even shorter function names than before. Oh and one last thing that I've been meaning to ask for a long long time. Do you think we could change the ordering of some of the arguments? The builder functions, like: external build_phi : (llvalue * llbasicblock) list -> string -> llbuilder -> llvalue = "llvm_build_phi" Have the builder as the last argument, instead of the first as it normally is done in ocaml libraries. It also hampers currying, but I'm not sure how often that would be used. The downside is that we'd have to translate the order in llvm_ocaml.c, but since more of the functions I want to do this to already have bindings in there, we wouldn't really have any extra overhead. From baldrick at free.fr Sun Mar 16 07:07:04 2008 From: baldrick at free.fr (Duncan Sands) Date: Sun, 16 Mar 2008 13:07:04 +0100 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: References: <200802110606.m1B66mk5052431@star.math.spbu.ru> Message-ID: <200803161307.04915.baldrick@free.fr> > Did anything ever come of the work on exception handling for x86_64? > > I'm having problems with exceptions on linux x86_64. I'm fairly sure that exception handling doesn't currently work on x86-64 linux (it may work with darwin - not sure). I don't know what it would take to get it to work. Ciao, Duncan. From gordonhenriksen at mac.com Sun Mar 16 09:38:51 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Sun, 16 Mar 2008 10:38:51 -0400 Subject: [LLVMdev] improving the ocaml binding's type safety In-Reply-To: <1ef034530803160021j641b536crecebc01d5a7e75e4@mail.gmail.com> References: <1ef034530803150103u42cf9bc9v68a59e1696951938@mail.gmail.com> <1ef034530803151449h4fab0a79hbaf910d8d17885c4@mail.gmail.com> <0F9320C0-AEE5-425C-B344-0B3F3EF7F4FC@mac.com> <80344C50-6720-4DE8-BB59-27B287DF97CE@mac.com> <1ef034530803160021j641b536crecebc01d5a7e75e4@mail.gmail.com> Message-ID: <1F974EFB-6CBE-4A85-8A2F-AA8718D74971@mac.com> On Mar 16, 2008, at 03:21, Erick Tryzelaar wrote: > On Sat, Mar 15, 2008 at 7:33 PM, Gordon Henriksen > wrote: > >> After some experimentation, I'd prefer the closed system. LLVM has >> some type peculiarities like the commonality between CallInst and >> InvokeInst. I find that the closed type system lets me express such >> constraints more naturally. Expressing these constraints explicitly >> in the open system involves annotating the C++ class hierarchy with >> extra variants which are unnecessary in the closed model. > > It looks like you might be right, and open variants might not be > able to handle the pseudo-shared functions like > llvm::CallInst::doesNotReturn and llvm::InvokeInst::doesNotReturn. > We can't do the naive > > val does_not_return : [> `CallInst | `InvokeInst] t -> bool > > Like we can with closed variants: > > val does_not_return : [< llcallinst | llinvokeinst] t -> bool. Exactly. >> Please use 'a Llvm.ty for Type and 'a Llvm.v for Value to save >> typing. These choices avoid conflicting with the common type >> binding t and the language keyword val, but promote these important >> types to the type names into the Llvm module (likely open'd) for >> brevity's sake. >> > > For instance, lablgtk has a "type 'a obj" that they use as the base > type for all of their variants, which I might copy. GTK+ has GtkObject at the root of its type system?an (open) tree of types. Value and Type have truly disjoint class hierarchies with no interfaces in common?a (closed) forest of types. Not only that, but there is cause to consider qualifying values with two phantom variants, which is not the case for types. Please continue to use different abstract types, as we currently do (lltype and llvalue). > I think we'd need only one definition of "type 'a whatever". The > phantom type would be enough to distinguish everything. We can even > hide this type by naming the variants something like > "llfunction_variants" and then "type llfunction = > llfunction_variants obj" to have roughly the same interface as before. I am not convinced that your type definition there would work right. If it is truly compatible (user code can accept and return values of that type, let bind them, put them in structs and refs), please proceed (and provide such aliases for all variants). However, if it's only 'sort of' compatible, please skip the extra layer of complexity. >> I don't have a better suggestion than just naming the variant sum >> types Llvm.ll_____. I considered some other options, but decided >> I'm not fond of them in practice. > > What about putting the types (and functions) in modules, like > ModuleProvider? I do like the submodules for keeping odd classes in their own namespace, but I rather like how users of the core IR functions read in the functional style. Besides, I don't want to change my (user) code without good reason. (By contrast, getting type checking is a good reason to change my type declarations.) > It'd be like my scheme to break up llvm.ml into multiple files > without actually splitting it up :) Then you could open Llvm and > reference Value.t without obscuring anything. We could even open or > abbreviate the module name in scope for even shorter function names > than before. I thought [ I was unsure of if it were better to add new functionality in the > top level or in a module, so I erred towards module. Let's angle to keep the IR in the top-level and the rest in submodules. I think that creates a nice balance of brevity (and compat) for common, core functions and explicitness and isolation for the more obscure features of the infrastructure. > Oh and one last thing that I've been meaning to ask for a long long > time. Do you think we could change the ordering of some of the > arguments? The builder functions, like: At this point, please don't change it. ? Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080316/26549f84/attachment.html From dalej at apple.com Sun Mar 16 12:41:09 2008 From: dalej at apple.com (Dale Johannesen) Date: Sun, 16 Mar 2008 10:41:09 -0700 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: <200803161307.04915.baldrick@free.fr> References: <200802110606.m1B66mk5052431@star.math.spbu.ru> <200803161307.04915.baldrick@free.fr> Message-ID: <8CB9AC6F-6EF1-49B4-861B-8A3AB5DB1EA0@apple.com> On Mar 16, 2008, at 5:07 AM, Duncan Sands wrote: >> Did anything ever come of the work on exception handling for x86_64? >> >> I'm having problems with exceptions on linux x86_64. > > I'm fairly sure that exception handling doesn't currently work on > x86-64 linux (it may work with darwin - not sure). I don't know > what it would take to get it to work. On Darwin, the Dwarf metadata emitted in .s/.o files is correct (although there may be bugs, it hasn't been exercised beyond the llvm and gcc testsuites). The unwinding code in libgcc* has not been ported to x86-64 and does not work. Thus, if you take the libgcc* from a non-llvm gcc and link llvm-gcc-produced .o files with that, things work. It would probably not take much to get Linux x86-64 to this state, I doubt the metadata is much different from Darwin. From wmatyjewicz at fastmail.fm Sun Mar 16 13:22:23 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Sun, 16 Mar 2008 19:22:23 +0100 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: References: Message-ID: <47DD655F.2010600@fastmail.fm> Hi, > As part of the advanced compilers course semester project (at UIUC), we > are starting to implement array dependence analysis for LLVM. I'm currently working on a similar project and hoping to finish it in about two weeks. I am going to share the code when it's ready. I've spent some time analyzing LLVM code for scientific and "ordinary" programs to find out what is necessary to make the IR-level array dependence analysis usable. I've designed techniques that I know will work for chosen programs, but the general precision of the pass implementation is still a mystery to me. If it appears acceptable, you may find some concepts useful for your project. Otherwise, you'll at least know what isn't useful:) As for now, I'm focusing on the dependency analysis engine and publish only a simplistic interface (it only allows to check whether a loop carries a memory dependence). However, the engine is quite self-contained and should be easy to attach to a different interface. For instance, the engine will be able to find dependence direction vectors for an instruction pair. > Any suggestion on features, tests and/or interface are welcome. >From my experience I can say it's essential to use a precise alias analysis as the base for the array dependence analysis. Fortunately, using Data Structure or Andersen's AA for the whole program can provide really good results. Also, on this list I was advised some time ago to look at the Omega test: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-January/012185.html Having taken a look at the Omega library interface I think it shouldn't be a complex task to use it for dependence testing. I'm thinking of adding it to my implementation in the future. It could probably replace Banerjee test. If you're interested, I advise to use the version patched by Jerry James: http://jjames.fedorapeople.org/omega/ Wojtek From sabre at nondot.org Sun Mar 16 20:55:56 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 16 Mar 2008 18:55:56 -0700 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: <47DD655F.2010600@fastmail.fm> References: <47DD655F.2010600@fastmail.fm> Message-ID: >> As part of the advanced compilers course semester project (at >> UIUC), we >> are starting to implement array dependence analysis for LLVM. Great! This is something we've needed for a long time. > I'm currently working on a similar project and hoping to finish it in > about two weeks. Cool! I think the most critical part of this is to get a good interface for dependence analysis. There are lots of interesting implementations that have various time/space tradeoffs. For example, it would be great if Omega was available as an option, even if the compiler didn't use it by default. This argues for making dependence analysis implementations pluggable like alias analyses. > As for now, I'm focusing on the dependency analysis engine and publish > only a simplistic interface (it only allows to check whether a loop > carries a memory dependence). However, the engine is quite > self-contained and should be easy to attach to a different interface. > For instance, the engine will be able to find dependence direction > vectors for an instruction pair. Sounds good. If you have the interface nailed down, it would be good to post what the query interface looks like. Vikram and others have a lot of experience with dependence analysis and know what sorts of queries various clients are interested in. They can help give feedback on the direction you're pursuing independent of the implementation. >> Any suggestion on features, tests and/or interface are welcome. I'd suggest looking at: Using the chains of recurrences algebra for data dependence testing and induction variable substitution MS Thesis, Johnie Birch Array Data Dependence Testing with the Chains of Recurrences Algebra http://citeseer.ist.psu.edu/vanengelen04array.html An empirical evaluation of chains of recurrences for array dependence testing http://doi.acm.org/10.1145/1152154.1152198 etc. >> From my experience I can say it's essential to use a precise alias > analysis as the base for the array dependence analysis. Fortunately, > using Data Structure or Andersen's AA for the whole program can > provide > really good results. Yep, but any particular dep analysis implementation should just require AliasAnalysis instead of a specific implementation. This lets the client (e.g. llvm-gcc) decide what passes to plug together. -Chris From isanbard at gmail.com Mon Mar 17 01:03:13 2008 From: isanbard at gmail.com (Bill Wendling) Date: Sun, 16 Mar 2008 23:03:13 -0700 Subject: [LLVMdev] OCaml "make install" failure Message-ID: Hi all, The OCaml stuff is failing during the "make install" command: $ make install llvm[0]: Installing HTML documentation llvm[0]: Building ocamldoc documentation make[2]: Nothing to be done for `ocamldoc'. make[2]: Nothing to be done for `ocamldoc'. make[2]: Nothing to be done for `ocamldoc'. make[2]: Nothing to be done for `ocamldoc'. make[2]: Nothing to be done for `ocamldoc'. make[2]: Nothing to be done for `ocamldoc'. make[2]: *** No rule to make target `ocamldoc'. Stop. make[1]: *** [ocamldoc] Error 2 make: *** [regen-ocamldoc] Error 2 This happens in the "docs" directory. I'm building with srcdir != objdir. -bw From idadesub at users.sourceforge.net Mon Mar 17 02:08:29 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Mon, 17 Mar 2008 00:08:29 -0700 Subject: [LLVMdev] [PATCH] ocamldoc code needs to be added for every subdirectory in the ocaml bindings. In-Reply-To: References: Message-ID: <1205737709-16448-1-git-send-email-idadesub@users.sourceforge.net> Here's a patch that'll fix the bug you're running into. Could someone commit? --- bindings/ocaml/transforms/Makefile | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: d18893b2d5dd41332dd51a460882fb282c048ebb.diff Type: text/x-patch Size: 361 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080317/3e20c02c/attachment.bin From isanbard at gmail.com Mon Mar 17 02:49:23 2008 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 17 Mar 2008 00:49:23 -0700 Subject: [LLVMdev] [PATCH] ocamldoc code needs to be added for every subdirectory in the ocaml bindings. In-Reply-To: <1205737709-16448-1-git-send-email-idadesub@users.sourceforge.net> References: <1205737709-16448-1-git-send-email-idadesub@users.sourceforge.net> Message-ID: Applied. Thanks! -bw On Mar 17, 2008, at 12:08 AM, Erick Tryzelaar wrote: > > Here's a patch that'll fix the bug you're running into. Could someone > commit? > --- > bindings/ocaml/transforms/Makefile | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > _______________________ > ________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From idadesub at users.sourceforge.net Mon Mar 17 02:54:10 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Mon, 17 Mar 2008 00:54:10 -0700 Subject: [LLVMdev] OCaml "make install" failure In-Reply-To: References: Message-ID: <1ef034530803170054m9cece9cmba5a16ce0e5e2ac2@mail.gmail.com> On Sun, Mar 16, 2008 at 11:03 PM, Bill Wendling wrote: > Hi all, > > The OCaml stuff is failing during the "make install" command: void committed my fix so hopefully this will now work for you. From isanbard at gmail.com Mon Mar 17 06:24:35 2008 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 17 Mar 2008 04:24:35 -0700 Subject: [LLVMdev] OCaml "make install" failure In-Reply-To: <1ef034530803170054m9cece9cmba5a16ce0e5e2ac2@mail.gmail.com> References: <1ef034530803170054m9cece9cmba5a16ce0e5e2ac2@mail.gmail.com> Message-ID: <00B8C087-6522-4D7A-92BA-942C71F76781@gmail.com> On Mar 17, 2008, at 12:54 AM, Erick Tryzelaar wrote: > On Sun, Mar 16, 2008 at 11:03 PM, Bill Wendling > wrote: >> Hi all, >> >> The OCaml stuff is failing during the "make install" command: > > void committed my fix so hopefully this will now work for you. It does...I'm void ;-) -bw From vvaditya12 at yahoo.com Mon Mar 17 11:30:14 2008 From: vvaditya12 at yahoo.com (aditya vishnubhotla) Date: Mon, 17 Mar 2008 09:30:14 -0700 (PDT) Subject: [LLVMdev] Adapting created intrinsics to PowerPC backend Message-ID: <709431.66469.qm@web56003.mail.re3.yahoo.com> Hi, I have implemented intrinsics which are placeholders for instructions executed elsewhere (e.g. in HW). So i have two types of intrinsics migrate_begin and migrate_end. Now i would like to make these intrinsics known to the PowerPC backend. Since the hardware initialization can not be implemented by one instruction it has to be expanded to a library call or lowered to something the ppc backend can understand? If it is possible to add the functionality of these functions to a library: Where is this library and how can these functions be added? Is it correct that entries in IntrinsicsPowerPC.td and PPCInstrInfo.td files have to be done to make these new intrinsics known? "migrate_begin" is an instruction with a variable argument list. Is there some special handling necessary to add variable argument functions? I would be thankful for any hints regarding this PowerPC backend adaptation. Thank You Aditya ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From dpatel at apple.com Mon Mar 17 11:54:00 2008 From: dpatel at apple.com (Devang Patel) Date: Mon, 17 Mar 2008 09:54:00 -0700 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: References: Message-ID: On Mar 15, 2008, at 4:48 PM, Alexandre Duch?teau wrote: > Any suggestion on features, tests and/or interface are welcome. LLVM loop transformer operates at loop level, which is not what many optimizers do in general. So, a loop level interface (i.e. based on LoopPass in llvm) to find loop-carried dependence is preferable to loop optimizer. - Devang From ramon.garcia.f at gmail.com Mon Mar 17 12:49:06 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Mon, 17 Mar 2008 18:49:06 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. Message-ID: As I told you, I am working with the Java frontend. Currently I am working with the code from http://llvm.org/svn/llvm-project/java/. The first task has been to put it up to date, since it was written for LLVM 1.9 and there are few incompatibilities. This is mostly done. How can I submit a patch? I am interested to get this work funded by a Google summer of code grant. Is there anyone interested in mentoring this project? Would be the LLVM interested in it? Best regards, Ramon From asl at math.spbu.ru Mon Mar 17 14:46:25 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Mon, 17 Mar 2008 22:46:25 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?UHJvcG9zYWwgZm9yIGEgR29vZ2xlIHN1bW1lciBvZiBj?= =?koi8-r?b?b2RlIHByb2plY3QgZm9yIHRoZSBKYXZhCWZyb250ZW5kLg==?= Message-ID: <200803171946.m2HJkPsP069971@star.math.spbu.ru> Hello, Ramon > As I told you, I am working with the Java frontend. Currently I am > working with the code from http://llvm.org/svn/llvm-project/java/. The > first task has been to put it up to date, since it was written for > LLVM 1.9 and there are few incompatibilities. This is mostly done. How > can I submit a patch? Just post the patch into llvm-commits mailing list. > I am interested to get this work funded by a Google summer of code > grant. Is there anyone interested in mentoring this project? Would be > the LLVM interested in it? Definitely yes, please submit your application as usual. -- WBR, Anton Korobeynikov From nicolas.geoffray at lip6.fr Mon Mar 17 15:48:48 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 17 Mar 2008 21:48:48 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: References: Message-ID: <47DED930.9000509@lip6.fr> Hi Ramon, Ram?n Garc?a wrote: > I am interested to get this work funded by a Google summer of code > grant. Is there anyone interested in mentoring this project? Would be > the LLVM interested in it? > I'm in the process of checking in a Java and a CLI FE to the llvm repository. I'm not sure what's the shape of llvm-java. Do your changes make it run some applications? Is the grant already provided? I'd be happy to mentor your work if the project can also concern improving my existing implementation ;-) Nicolas > 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 criswell at cs.uiuc.edu Mon Mar 17 16:13:14 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 17 Mar 2008 16:13:14 -0500 Subject: [LLVMdev] Cooling Outage Presumed Over Message-ID: <47DEDEEA.7020401@cs.uiuc.edu> Dear All, Since the cooling outage was scheduled to end at noon and it's now 4:00 pm Central, I'm going to step out on a limb and say that the cooling outage is probably over. :) The temperature in the room where llvm.org is located did not rise significantly, and so we were able to keep everything running as usual. Regards, John Criswell From khamenya at gmail.com Mon Mar 17 18:16:43 2008 From: khamenya at gmail.com (Valery Khamenya) Date: Tue, 18 Mar 2008 00:16:43 +0100 Subject: [LLVMdev] LLVM has entered the google trends! Message-ID: <84fecab0803171616u3546d9f4qb085d417e0bbc81f@mail.gmail.com> Hi all see $subj http://www.google.com/trends?q=llvm congrats! P.S. sorry if known. best regards -- Valery A.Khamenya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080318/2bfc6887/attachment.html From dalej at apple.com Mon Mar 17 19:46:35 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 17 Mar 2008 17:46:35 -0700 Subject: [LLVMdev] Build problem in TOT llvm Message-ID: I'm getting a lot of these from TOT make: /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h: In instantiation of 'llvm::LoopInfoBase': /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:886: instantiated from here /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:573: warning: 'class llvm::LoopInfoBase' has virtual functions but non-virtual destructor From dpatel at apple.com Mon Mar 17 20:22:37 2008 From: dpatel at apple.com (Devang Patel) Date: Mon, 17 Mar 2008 18:22:37 -0700 Subject: [LLVMdev] Build problem in TOT llvm In-Reply-To: References: Message-ID: <0A8220DB-FADA-4CED-9B35-AD8CD91AA5BC@apple.com> On Mar 17, 2008, at 5:46 PM, Dale Johannesen wrote: > I'm getting a lot of these from TOT make: > > /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h: In > instantiation of 'llvm::LoopInfoBase': > /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:886: > instantiated from here > /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:573: > warning: 'class llvm::LoopInfoBase' has virtual > functions but non-virtual destructor Weird, I did not get this error. If following helps, please apply. Thanks, - Devang Index: LoopInfo.h =================================================================== --- LoopInfo.h (revision 48476) +++ LoopInfo.h (working copy) @@ -580,9 +580,6 @@ LoopInfoBase() { } ~LoopInfoBase() { releaseMemory(); } - /// isAnalysis - Return true if this pass is implementing an analysis pass. - virtual bool isAnalysis() const { return true; } - void releaseMemory() { for (typename std::vector* >::iterator I = TopLevelLoops.begin(), E = TopLevelLoops.end(); I != E; ++I) @@ -922,6 +919,9 @@ return LI->isLoopHeader(BB); } + /// isAnalysis - Return true if this pass is implementing an analysis pass. + bool isAnalysis() const { return true; } + /// runOnFunction - Calculate the natural loop information. /// virtual bool runOnFunction(Function &F); From dalej at apple.com Mon Mar 17 20:52:49 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 17 Mar 2008 18:52:49 -0700 Subject: [LLVMdev] Build problem in TOT llvm In-Reply-To: <0A8220DB-FADA-4CED-9B35-AD8CD91AA5BC@apple.com> References: <0A8220DB-FADA-4CED-9B35-AD8CD91AA5BC@apple.com> Message-ID: <9E158A55-EA26-4787-B687-EA1ACB56934A@apple.com> On Mar 17, 2008, at 6:22 PM, Devang Patel wrote: > > On Mar 17, 2008, at 5:46 PM, Dale Johannesen wrote: > >> I'm getting a lot of these from TOT make: >> >> /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h: In >> instantiation of 'llvm::LoopInfoBase': >> /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:886: >> instantiated from here >> /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:573: >> warning: 'class llvm::LoopInfoBase' has virtual >> functions but non-virtual destructor > > Weird, I did not get this error. If following helps, please apply. > Thanks, It does help, I have checked it in. Thanks. From dberlin at dberlin.org Mon Mar 17 21:52:25 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 17 Mar 2008 22:52:25 -0400 Subject: [LLVMdev] LLVM has entered the google trends! In-Reply-To: <84fecab0803171616u3546d9f4qb085d417e0bbc81f@mail.gmail.com> References: <84fecab0803171616u3546d9f4qb085d417e0bbc81f@mail.gmail.com> Message-ID: <4aca3dc20803171952m317b6ec0wcb53d9e8a37ebcee@mail.gmail.com> Google trends will display results for pretty much any query you can think of On Mon, Mar 17, 2008 at 7:16 PM, Valery Khamenya wrote: > Hi all > > see $subj > > http://www.google.com/trends?q=llvm > > congrats! > > P.S. sorry if known. > > best regards > -- > Valery A.Khamenya > _______________________________________________ > 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 Mar 18 01:04:40 2008 From: sabre at nondot.org (Chris Lattner) Date: Mon, 17 Mar 2008 23:04:40 -0700 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: <47DED930.9000509@lip6.fr> References: <47DED930.9000509@lip6.fr> Message-ID: On Mar 17, 2008, at 1:48 PM, Nicolas Geoffray wrote: > Hi Ramon, > Ram?n Garc?a wrote: >> I am interested to get this work funded by a Google summer of code >> grant. Is there anyone interested in mentoring this project? Would be >> the LLVM interested in it? >> > > I'm in the process of checking in a Java and a CLI FE to the llvm > repository. I'm not sure what's the shape of llvm-java. Do your > changes > make it run some applications? > > Is the grant already provided? I'd be happy to mentor your work if the > project can also concern improving my existing implementation ;-) The GSoC project has not really started yet, we haven't started accepting applicants. I think it would be a great thing to focus future java efforts on your front-end, provided it's in better shape than llvm-java (which isn't hard). It would be awesome if you were willing to mentor a student. Please sign up on the GSoC page as a mentor, thanks! -Chris From ramon.garcia.f at gmail.com Tue Mar 18 03:10:12 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Tue, 18 Mar 2008 09:10:12 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: <47DED930.9000509@lip6.fr> References: <47DED930.9000509@lip6.fr> Message-ID: I would like to see the code of your front end. I started working with llvm-java, since it was what was available. It does not run yet (small compilation issues, almost done), but the design seems fine. It can run (when setup complete) small pieces of Java code, but no real application, since it does not support exception handling (jsr/ret bytecodes) yet,nor garbage collection. Implementing these pieces would be the purpose of this summer grant request. A Java and CLI front end would be really interesting. What missing features could I implement? I can start preparing a proposal. Ramon On Mon, Mar 17, 2008 at 9:48 PM, Nicolas Geoffray wrote: > I'm in the process of checking in a Java and a CLI FE to the llvm > repository. I'm not sure what's the shape of llvm-java. Do your changes > make it run some applications? > > Is the grant already provided? I'd be happy to mentor your work if the > project can also concern improving my existing implementation ;-) > From isanbard at gmail.com Tue Mar 18 03:16:56 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 18 Mar 2008 01:16:56 -0700 Subject: [LLVMdev] GCC Merge Coming Up Message-ID: <24A5F9DD-4811-47C7-93A1-B9CF13D762F5@gmail.com> Hi LLVMites, There's going to be new LLVM-GCC merge with Apple's GCC 4.2 coming up. If all goes well, this should happen tomorrow (Tuesday). I'll have Tanya disable emails when I apply the patch so that you aren't inundated with a bunch of messages. But I will send out the patch afterwards as an attachment. One of the main reasons for this merge is to get SSE4 support into LLVM-GCC -- Nate Begeman already started adding support for SSE4 on the code-gen side -- as well as testsuite improvements and other general bug fixes. This merge should go *much* more smoothly than the last merge -- it could hardly be worse, right? ;-) I already did a test compile of llvm-test with the patch and it compiled the programs without a problem. Devang is currently testing it as well so that I have a second opinion. -bw From nicolas.geoffray at lip6.fr Tue Mar 18 03:42:15 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 18 Mar 2008 09:42:15 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: References: <47DED930.9000509@lip6.fr> Message-ID: <47DF8067.7010802@lip6.fr> Ram?n Garc?a wrote: > I would like to see the code of your front end. > > It should be available in a week or two. I'm currently dealing with licensing issues. > I started working with llvm-java, since it was what was available. It > does not run yet (small compilation issues, almost done), > but the design seems fine. It can run (when setup complete) small > pieces of Java code, but no real application, since it does > not support exception handling (jsr/ret bytecodes) yet,nor garbage > collection. Implementing these pieces would be the purpose > of this summer grant request. > > A Java and CLI front end would be really interesting. What missing > features could I implement? I can start preparing a proposal. > There is no real missing feature. The VMs can execute standard applications (last time I checked, the JVM can run tomcat), and the implementations follow the VM specifications. The CLI implementation lacks generics and overflow detection, but this is not top priority in my mind. Among many features, here are the ones that I'd _love_ to see implemented: 1) Compilation optimizations for type-safe languages (including type-based alias analysis) 2) Hotspot-like vm: switching between interpreter and compiler, applying different optimizations depending on a method's hotness, doing on-stack replacement 3) Implementing a garbage collector with llvm facilities: currently my GC is not related to the compiler (consider it like Boehm's). It would be nice to see how do the LLVM intrinsics fit with Java/CLI and JIT. Nicolas > Ramon > > On Mon, Mar 17, 2008 at 9:48 PM, Nicolas Geoffray > wrote: > >> I'm in the process of checking in a Java and a CLI FE to the llvm >> repository. I'm not sure what's the shape of llvm-java. Do your changes >> make it run some applications? >> >> Is the grant already provided? I'd be happy to mentor your work if the >> project can also concern improving my existing implementation ;-) >> >> > _______________________________________________ > 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 Tue Mar 18 03:52:21 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Tue, 18 Mar 2008 11:52:21 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?R0NDIE1lcmdlIENvbWluZyBVcA==?= Message-ID: <200803180852.m2I8qLWE011973@star.math.spbu.ru> Hello, Bill > This merge should go *much* more smoothly than the last merge -- it > could hardly be worse, right? ;-) I already did a test compile of > llvm-test with the patch and it compiled the programs without a > problem. Devang is currently testing it as well so that I have a > second opinion. One thing, which we already saw: please carefully check, that you won't commit any zero-sized files in the gcc/config/i386 directory. -- WBR, Anton Korobeynikov From nicolas.geoffray at lip6.fr Tue Mar 18 04:11:06 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 18 Mar 2008 10:11:06 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: <47DF8067.7010802@lip6.fr> References: <47DED930.9000509@lip6.fr> <47DF8067.7010802@lip6.fr> Message-ID: <47DF872A.8000406@lip6.fr> Nicolas Geoffray wrote: > > There is no real missing feature. The VMs can execute standard > applications (last time I checked, the JVM can run tomcat), and the > implementations follow the VM specifications. The CLI implementation > lacks generics and overflow detection, but this is not top priority in > my mind. > > Among many features, here are the ones that I'd _love_ to see implemented: > 1) Compilation optimizations for type-safe languages (including > type-based alias analysis) > 2) Hotspot-like vm: switching between interpreter and compiler, applying > different optimizations depending on a method's hotness, doing on-stack > replacement > 3) Implementing a garbage collector with llvm facilities: currently my > GC is not related to the compiler (consider it like Boehm's). It would > be nice to see how do the LLVM intrinsics fit with Java/CLI and JIT. > > I also forgot: 4) Generating shared libraries in order to not recompile Java or CLI code. In LLVM bitcode (simpler at first) and then in the ELF/MachO file format. > Nicolas > > >> Ramon >> >> On Mon, Mar 17, 2008 at 9:48 PM, Nicolas Geoffray >> wrote: >> >> >>> I'm in the process of checking in a Java and a CLI FE to the llvm >>> repository. I'm not sure what's the shape of llvm-java. Do your changes >>> make it run some applications? >>> >>> Is the grant already provided? I'd be happy to mentor your work if the >>> project can also concern improving my existing implementation ;-) >>> >>> >>> >> _______________________________________________ >> 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 ramon.garcia.f at gmail.com Tue Mar 18 05:29:48 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Tue, 18 Mar 2008 11:29:48 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: <47DF872A.8000406@lip6.fr> References: <47DED930.9000509@lip6.fr> <47DF8067.7010802@lip6.fr> <47DF872A.8000406@lip6.fr> Message-ID: Based on my experience this last one (the generation of shared libraries) is the most important performance wise, and the one that would make a difference from a performance point of view. I would like to prepare a proposal as soon as posible. Could I have a look at your code privately, even if there are licensing issues pending? I understand that this issues are just temporary, and will in no way block the publication of the code at a certain time. Best regards, Ramon From nicolas.geoffray at lip6.fr Tue Mar 18 06:17:09 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 18 Mar 2008 12:17:09 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: References: <47DED930.9000509@lip6.fr> <47DF8067.7010802@lip6.fr> <47DF872A.8000406@lip6.fr> Message-ID: <47DFA4B5.2070401@lip6.fr> Ram?n Garc?a wrote: > Based on my experience this last one (the generation of shared > libraries) is the most important performance wise, and the one that > would make a difference from a performance point of view. > > That's more or less true: generating shared libraries will improve startup time, not steady-state time. It will decrease steady-state performance (both for Java and CLI) because the VMs ensure a class will be fully initialized before its use. Therefore, while the JIT will have runtime knowledge of a class being fully initialized or not, a static compiler will have to be conservative and insert intialization checks on most uses of a class. What you can do to tackle this issue is to generate different native code statically and let the VM choose which native code it has to execute (depending on which classes were already initialized). > I would like to prepare a proposal as soon as posible. Could I have a > look at your code privately, even if there are licensing issues > pending? I understand that this issues are just temporary, and will in > no way block the publication of the code at a certain time. > > Do you really need the code for the proposal? Legally, I don't have the right (yet) to send it to you. Let's see how things go this week and hope that at the end of the week I'll be able to checkin the code. Nicolas > 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 ramon.garcia.f at gmail.com Tue Mar 18 08:09:42 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Tue, 18 Mar 2008 14:09:42 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: <47DFA4B5.2070401@lip6.fr> References: <47DED930.9000509@lip6.fr> <47DF8067.7010802@lip6.fr> <47DF872A.8000406@lip6.fr> <47DFA4B5.2070401@lip6.fr> Message-ID: I would prefer to see actual code to make safe schedules. With code I can see what changes one must make. I can also show in detail these changes, which would give security to the LLVM project that the proposal is viable. By contrast, without code, neither me nor LLVM project can ensure that the project will be successfully performed behind schedule. Since this is a difficult project (we are talking about compilers which are complicated technologies) it is specially important to have a good planning. On Tue, Mar 18, 2008 at 12:17 PM, Nicolas Geoffray wrote: > > That's more or less true: generating shared libraries will improve > startup time, not steady-state time. It will decrease steady-state > performance (both for Java and CLI) because the VMs ensure a class will > be fully initialized before its use. Therefore, while the JIT will have > runtime knowledge of a class being fully initialized or not, a static > compiler will have to be conservative and insert intialization checks on > most uses of a class. There was a misunderstanding. The issue with dynamic compiling is not only startup time, but also memory consumption, and this is a *huge* issue with Java applications. In addition, I think that in most of the cases a class can be initialized at compile time. From nicolas.geoffray at lip6.fr Tue Mar 18 09:04:35 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 18 Mar 2008 15:04:35 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: References: <47DED930.9000509@lip6.fr> <47DF8067.7010802@lip6.fr> <47DF872A.8000406@lip6.fr> <47DFA4B5.2070401@lip6.fr> Message-ID: <47DFCBF3.2050604@lip6.fr> Ram?n Garc?a wrote: > I would prefer to see actual code to make safe schedules. With code I can see > what changes one must make. I can also show in detail these changes, > which would give security to the LLVM project that the proposal is > viable. By contrast, > without code, neither me nor LLVM project can ensure that the project will > be successfully performed behind schedule. Since this is a difficult > project (we > are talking about compilers which are complicated technologies) it is specially > important to have a good planning. > > OK, let's hope it'll be available soon enough then :) > On Tue, Mar 18, 2008 at 12:17 PM, Nicolas Geoffray > wrote: > >> That's more or less true: generating shared libraries will improve >> startup time, not steady-state time. It will decrease steady-state >> performance (both for Java and CLI) because the VMs ensure a class will >> be fully initialized before its use. Therefore, while the JIT will have >> runtime knowledge of a class being fully initialized or not, a static >> compiler will have to be conservative and insert intialization checks on >> most uses of a class. >> > > There was a misunderstanding. The issue with dynamic compiling is > not only startup time, but also memory consumption, Can you tell me why dynamic compilation consumes memory? Except the fact that you need to embed a JIT in your VM, dynamic compilation should not consume that much memory. Once a method is compiled you can throw away the intermediate representation. Or are you talking about constrained devices where you do not want to embed a JIT? > and this is a *huge* > issue with Java applications. In addition, I think that in most of the cases > a class can be initialized at compile time. > No. Initialization must happen during execution. By intialization, I mean calling the clinit function (e.g. static{...} in Java source), not resolving the class (which can be at compile time). Nicolas > _______________________________________________ > 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 Tue Mar 18 09:31:27 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Tue, 18 Mar 2008 15:31:27 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: <47DFCBF3.2050604@lip6.fr> References: <47DED930.9000509@lip6.fr> <47DF8067.7010802@lip6.fr> <47DF872A.8000406@lip6.fr> <47DFA4B5.2070401@lip6.fr> <47DFCBF3.2050604@lip6.fr> Message-ID: The memory consumed by the code compiled is huge in server applications. And it is not shared by different virtual machine instances. By contrast, shared libraries are memory mapped, therefore they are shared between different instances of the executables using them. It is posible to throw away code after using it, but then compilation cost would be repeated. And dynamic compilation prevents expensive optimization techniques. > Can you tell me why dynamic compilation consumes memory? Except the fact > that you need to embed a JIT in your VM, dynamic compilation should not > consume that much memory. Once a method is compiled you can throw away > the intermediate representation. Or are you talking about constrained > devices where you do not want to embed a JIT? Ramon From nicolas.geoffray at lip6.fr Tue Mar 18 09:59:07 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 18 Mar 2008 15:59:07 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: References: <47DED930.9000509@lip6.fr> <47DF8067.7010802@lip6.fr> <47DF872A.8000406@lip6.fr> <47DFA4B5.2070401@lip6.fr> <47DFCBF3.2050604@lip6.fr> Message-ID: <47DFD8BB.2070308@lip6.fr> OK, I didn't realize you were not one-JVM oriented. Sure, if the code can be shared between different instances of JVMs, that would be great! I actually had this in mind when I wrote the proposition :) Ram?n Garc?a wrote: > The memory consumed by the code compiled is huge in server applications. And > it is not shared by different virtual machine instances. By contrast, > shared libraries > are memory mapped, therefore they are shared between different instances of the > executables using them. It is posible to throw away code after using > it, but then > compilation cost would be repeated. > > And dynamic compilation prevents expensive optimization techniques. > > >> Can you tell me why dynamic compilation consumes memory? Except the fact >> that you need to embed a JIT in your VM, dynamic compilation should not >> consume that much memory. Once a method is compiled you can throw away >> the intermediate representation. Or are you talking about constrained >> devices where you do not want to embed a JIT? >> > > Ramon > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From wmatyjewicz at fastmail.fm Tue Mar 18 10:03:27 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Tue, 18 Mar 2008 16:03:27 +0100 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: References: Message-ID: <47DFD9BF.2020209@fastmail.fm> Hi, Devang Patel wrote: > LLVM loop transformer operates at loop level, which is not what many > optimizers do in general. So, a loop level interface (i.e. based on > LoopPass in llvm) to find loop-carried dependence is preferable to > loop optimizer. Do you mean making Array Dependence Analysis a loop-level analysis? Would its results be available for some function-level pass then? Wojtek From dpatel at apple.com Tue Mar 18 10:34:17 2008 From: dpatel at apple.com (Devang Patel) Date: Tue, 18 Mar 2008 08:34:17 -0700 Subject: [LLVMdev] Build problem in TOT llvm In-Reply-To: <9E158A55-EA26-4787-B687-EA1ACB56934A@apple.com> References: <0A8220DB-FADA-4CED-9B35-AD8CD91AA5BC@apple.com> <9E158A55-EA26-4787-B687-EA1ACB56934A@apple.com> Message-ID: On Mar 17, 2008, at 6:52 PM, Dale Johannesen wrote: > > On Mar 17, 2008, at 6:22 PM, Devang Patel wrote: > >> >> On Mar 17, 2008, at 5:46 PM, Dale Johannesen wrote: >> >>> I'm getting a lot of these from TOT make: >>> >>> /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h: In >>> instantiation of 'llvm::LoopInfoBase': >>> /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:886: >>> instantiated from here >>> /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:573: >>> warning: 'class llvm::LoopInfoBase' has virtual >>> functions but non-virtual destructor >> >> Weird, I did not get this error. If following helps, please apply. >> Thanks, > > It does help, I have checked it in. Thanks. Thanks! - Devang From jo at durchholz.org Tue Mar 18 10:57:33 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 18 Mar 2008 16:57:33 +0100 Subject: [LLVMdev] LLVM has entered the google trends! In-Reply-To: <4aca3dc20803171952m317b6ec0wcb53d9e8a37ebcee@mail.gmail.com> References: <84fecab0803171616u3546d9f4qb085d417e0bbc81f@mail.gmail.com> <4aca3dc20803171952m317b6ec0wcb53d9e8a37ebcee@mail.gmail.com> Message-ID: <1205855853.7523.6.camel@kurier> Am Montag, den 17.03.2008, 22:52 -0400 schrieb Daniel Berlin: > Google trends will display results for pretty much any query you can think of Interestingly enough, queries for llvm are at the same level as "c programming language". Most LLVM queries come from Finland. Most "c programming language" queries come from India. Queries for JVM and J2EE are roughly an order of magnitude more. What's interesting is that all search keywords except llvm have a slowly decreasing rate. LLVM is roughly constant. Jo Useless Facts Dept. ;-) From dpatel at apple.com Tue Mar 18 11:03:31 2008 From: dpatel at apple.com (Devang Patel) Date: Tue, 18 Mar 2008 09:03:31 -0700 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: <47DFD9BF.2020209@fastmail.fm> References: <47DFD9BF.2020209@fastmail.fm> Message-ID: On Mar 18, 2008, at 8:03 AM, Wojciech Matyjewicz wrote: > Hi, > > Devang Patel wrote: >> LLVM loop transformer operates at loop level, which is not what many >> optimizers do in general. So, a loop level interface (i.e. based on >> LoopPass in llvm) to find loop-carried dependence is preferable to >> loop optimizer. > > Do you mean making Array Dependence Analysis a loop-level analysis? > Would its results be available for some function-level pass then? We could extend pass manager framework to let function-level pass use loop-level analysis info. However that is not ideal. A loop level pass operates on a loop only. If a function level pass needs array dependence analysis info then it expects info. to cover entire function. Which means, it will need function level array dependence analysis pass, which is natural. If loop level pass, say LP, is interested in array dependence info, then in many cases it is more interested in loop-carried dependence info for a given loop. If such info. is made available to through a loop level pass then it'd allow loop pass manager to execute allow loop pass manager to handle LP together with other loop passes. - Devang From jo at durchholz.org Tue Mar 18 11:09:35 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 18 Mar 2008 17:09:35 +0100 Subject: [LLVMdev] Proposal for a Google summer of code project for the Java frontend. In-Reply-To: References: <47DED930.9000509@lip6.fr> <47DF8067.7010802@lip6.fr> <47DF872A.8000406@lip6.fr> <47DFA4B5.2070401@lip6.fr> <47DFCBF3.2050604@lip6.fr> Message-ID: <1205856575.7523.15.camel@kurier> Am Dienstag, den 18.03.2008, 15:31 +0100 schrieb Ram?n Garc?a: > The memory consumed by the code compiled is huge in server applications. Do you have statistics about the relative footprints of code and various kinds of objects in such a server application? I know they have huge footprints (a general problem with Java applications, I think), but I never got a useful breakdown along the lines of what's responsible for that. > And > it is not shared by different virtual machine instances. By contrast, > shared libraries > are memory mapped, therefore they are shared between different instances of the > executables using them. It is posible to throw away code after using > it, but then > compilation cost would be repeated. It would suffice to store a hash of the compiled code. That way, when the same class somes along, you can reuse existing compiled code. You'd want to keep the intermediate code if you try global optimizations like monomorphisation (i.e. finding out those parameters and variables that are never assigned to polymorphically - loading another class can invalidate assumptions, so you may have to redo at least parts of the optimization). > And dynamic compilation prevents expensive optimization techniques. Well, then a hash should really be sufficient :-) Regards, Jo From wmatyjewicz at fastmail.fm Tue Mar 18 11:21:38 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Tue, 18 Mar 2008 17:21:38 +0100 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: References: <47DD655F.2010600@fastmail.fm> Message-ID: <47DFEC12.7010502@fastmail.fm> Hi, > Cool! I think the most critical part of this is to get a good > interface for dependence analysis. There are lots of interesting > implementations that have various time/space tradeoffs. > > For example, it would be great if Omega was available as an option, > even if the compiler didn't use it by default. This argues for making > dependence analysis implementations pluggable like alias analyses. Yes, I also thought about it that way. I think we may look at the dependence analysis in LLVM at three levels (from the lowest to the highest one): 1) Testing for dependence given two sequences of GEP indices assuming that base pointers are the same. The indices could have a SCEV form or even be preprocessed to something simpler (affine expressions for example). 2) Testing for dependence of two instructions (that access memory). It would use alias analysis to answer some queries immediately, or to check whether two GEP base pointers equal. If the latter is the case, 1) would be used to check for dependences. 3) Complex queries (for example: does the given loop carry dependence?). It would use 2) and summarize its results. Only the first level could be pluggable allowing to interchange or chain core dependency testing techniques. I think there will be no use in making pluggable the higher ones (please, correct me if I am wrong). This approach would require to divide the analysis structure into two parts, say; DependenceAnalysis and IndexingTester. That said, I must admit I haven't made it that way in my prototype. I have it in mind, but I'm currently trying to keep things simple and just to check whether the precision of my implementation is worth anything. > Sounds good. If you have the interface nailed down, it would be good > to post what the query interface looks like. Vikram and others have a > lot of experience with dependence analysis and know what sorts of > queries various clients are interested in. They can help give > feedback on the direction you're pursuing independent of the > implementation. Ok. I'll post it when it crystallizes (what should happen soon). > I'd suggest looking at: > > Using the chains of recurrences algebra for data dependence testing > and induction variable substitution > MS Thesis, Johnie Birch > > Array Data Dependence Testing with the Chains of Recurrences Algebra > http://citeseer.ist.psu.edu/vanengelen04array.html > > An empirical evaluation of chains of recurrences for array dependence > testing > http://doi.acm.org/10.1145/1152154.1152198 I've read the second one, but am not sure if it's easy to implement if overflow and unknown signedness are taken into account. For now, I will stick to the classical Banerjee test. If time allows I'll return to the article. >>> From my experience I can say it's essential to use a precise alias >> analysis as the base for the array dependence analysis. Fortunately, >> using Data Structure or Andersen's AA for the whole program can >> provide >> really good results. > > Yep, but any particular dep analysis implementation should just > require AliasAnalysis instead of a specific implementation. This lets > the client (e.g. llvm-gcc) decide what passes to plug together. You're right. From the implementation point of view the choice of alias analysis doesn't matter at all. Wojtek From evan.cheng at apple.com Tue Mar 18 12:08:45 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 18 Mar 2008 10:08:45 -0700 Subject: [LLVMdev] Adapting created intrinsics to PowerPC backend In-Reply-To: <709431.66469.qm@web56003.mail.re3.yahoo.com> References: <709431.66469.qm@web56003.mail.re3.yahoo.com> Message-ID: <7E140094-86A9-4BBC-802D-E7E2CFD928F9@apple.com> On Mar 17, 2008, at 9:30 AM, aditya vishnubhotla wrote: > Hi, > > I have implemented intrinsics which are placeholders > for instructions executed elsewhere (e.g. in HW). > > So i have two types of intrinsics migrate_begin and > migrate_end. Now i would like to make these intrinsics > known to the PowerPC backend. Since the hardware > initialization can not be implemented by one > instruction it has to be expanded to a library call or > lowered to something the ppc backend can understand? > > If it is possible to add the functionality of these > functions to a library: > Where is this library and how can these functions be > added? > > Is it correct that entries in IntrinsicsPowerPC.td > and > PPCInstrInfo.td files have to be done to make these > new intrinsics known? You would add the definition to IntrinsicsPowerPC.td to let it be known. Then you can add a instruction selection pattern to PPCInstrInfo.td so it would be translated to the right PPC instruction(s). Alternatively, you can add C++ code to PPCISelDAGToDAG.cpp to do the translation. > > > "migrate_begin" is an instruction with a variable > argument list. Is there some > special handling necessary to add variable argument > functions? In theory, you just need to specify the matching instruction input operands "variable_ops". Evan > > > I would be thankful for any hints regarding this > PowerPC backend adaptation. > > Thank You > Aditya > > > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > _______________________________________________ > 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 Mar 18 12:41:00 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 18 Mar 2008 10:41:00 -0700 Subject: [LLVMdev] GCC Merge Coming Up In-Reply-To: <200803180852.m2I8qLWE011973@star.math.spbu.ru> References: <200803180852.m2I8qLWE011973@star.math.spbu.ru> Message-ID: <16e5fdf90803181041l4f47bc7djf0b3c3cabd03fbae@mail.gmail.com> 2008/3/18 Anton Korobeynikov : > Hello, Bill > > > > This merge should go *much* more smoothly than the last merge -- it > > could hardly be worse, right? ;-) I already did a test compile of > > llvm-test with the patch and it compiled the programs without a > > problem. Devang is currently testing it as well so that I have a > > second opinion. > One thing, which we already saw: please carefully check, that you won't > commit any zero-sized files in the gcc/config/i386 directory. > Definitely! :-) I learned that lesson the hard way. -bw From sabre at nondot.org Tue Mar 18 13:53:11 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 18 Mar 2008 11:53:11 -0700 (PDT) Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: References: <47DFD9BF.2020209@fastmail.fm> Message-ID: On Tue, 18 Mar 2008, Devang Patel wrote: >> Do you mean making Array Dependence Analysis a loop-level analysis? >> Would its results be available for some function-level pass then? > > We could extend pass manager framework to let function-level pass use > loop-level analysis info. However that is not ideal. I agree. I think the dependence analysis pass should be a FunctionPass. LoopPasses can use function passes, but not visaversa. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From isanbard at gmail.com Tue Mar 18 14:41:17 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 18 Mar 2008 12:41:17 -0700 Subject: [LLVMdev] IMPORTANT Please Read: Merging Now Message-ID: <16e5fdf90803181241q69d11796o41f0aa34f74a1f20@mail.gmail.com> Hi all, I'm going to start the merge that I told you about last night. This won't take long, but during that time commit message emails will be disabled. Please hold off committing new patches until we're finished. Sorry for the inconvenience. -bw From isanbard at gmail.com Tue Mar 18 14:57:56 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 18 Mar 2008 12:57:56 -0700 Subject: [LLVMdev] IMPORTANT Please Read: Merge Finished Message-ID: <16e5fdf90803181257w553877d4g77de92d43f685e8c@mail.gmail.com> Hi all, I finished the merge. It's safe to commit things again. Please let me know if you have any problems. -bw From asl at math.spbu.ru Tue Mar 18 15:17:52 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Tue, 18 Mar 2008 23:17:52 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?R29vZ2xlIFN1bW1lciBvZiBDb2RlIDIwMDg=?= Message-ID: <200803182017.m2IKHpSG026329@star.math.spbu.ru> Hello, Everyone LLVM recently was approved to take part in Google Summer of Code 2008. We welcome everyone to apply for this program. The list of ideas for (possible) projects is located at http://llvm.org/OpenProjects.html. Surely you can suggest any other project, if you feel, that it definitely can be useful. Our common requirement for student is to submit proposal to LLVM Developers Mainling list for discussions and suggestions *before* actual submission to Google. Be prepared, that you proposal can be changed a lot as a result of these discussions :) Drupal project has great page about "How to Write Summer of Code Application": http://drupal.org/node/59037, I'd suggest every applicant to read it before writing an application/proposal. We're waiting for you proposals! PS: The students application period (at Google) begins at 12 noon PDT, March 24 (19:00 UTC) and ends 5:00 PM PDT, March 31 (00:00 UTC April 1, 2008). Students application should be submitted to Google at this period. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From jon at ffconsultancy.com Tue Mar 18 16:49:03 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Tue, 18 Mar 2008 21:49:03 +0000 Subject: [LLVMdev] Google Summer of Code 2008 In-Reply-To: <200803182017.m2IKHpSG026329@star.math.spbu.ru> References: <200803182017.m2IKHpSG026329@star.math.spbu.ru> Message-ID: <200803182149.03786.jon@ffconsultancy.com> On Tuesday 18 March 2008 20:17:52 Anton Korobeynikov wrote: > Hello, Everyone > > LLVM recently was approved to take part in Google Summer of Code 2008. > We welcome everyone to apply for this program. > > The list of ideas for (possible) projects is located at > http://llvm.org/OpenProjects.html. Surely you can suggest any other > project, if you feel, that it definitely can be useful. Just some ideas to add to the mix: One of the suggestions is to write a code-density optimizer for the ARM backend. For an interesting alternative, try optimizing for power consumption instead. If you want something super researchy, try doing this for one of the clockless (asynchronous) ARM cores: http://www.arm.com/products/CPUs/ARM996HS.html Another suggestion under "Miscellaneous Additions" was to write a new front-end for Java/OCaml/Forth. IMHO, reimplementing Java or OCaml from scratch is way too much work and a lot of that work is uninteresting baggage. My personal dream is to implement a higher-level VM that bundles an existing concurrent GC with an intermediate representation that exposes high-level language-agnostic features like parametric polymorphism (generics), first-class lexical closures (and maybe even pattern matching) and a backend that type specializes to remove polymorphism (and the associated run-time performance hit, as seen in OCaml) before LLVM code is generated. I would like this for two reasons: a) to provide the foundation for better technical computing environments on Linux and Mac OS X (like F# for Windows). This could greatly improve the open source tools that scientists and engineers use for technical computing. b) to provide a CLR. This could make it much easier for industry to build and sell software written in exotic languages for Linux and Mac OS X. A tamer but related idea is to implement a Fortran 77 front-end for LLVM and then get LAPACK into the LLVM benchmark suite. This could help LLVM to improve and might provide a faster LAPACK library for the open source world. FFTW is another hugely important numerical library that could be used for benchmarking. Aside from simply getting FFTW to work using llvm-gcc, an interesting project might be to rewrite the OCaml source code in FFTW to generate codelets on-the-fly using LLVM or the CLang front-end. LLVM can probably beat GCC here, not least because an LLVM-based implementation would not be limited to a set of precompiled codelets. This could help the millions of people who use FFTW. On an unrelated note, LLVM has great potential for improving OCaml's FFI. At the moment, OCaml programmers are expected to write stubs in C and statically link them in with their OCaml code. A much better solution would be to use LLVM to generate the equivalent of the C stubs at run-time. Calling OpenGL directly from OCaml using LLVM without any existing OpenGL bindings would make an excellent example. This project could really help the OCaml community. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From isanbard at gmail.com Tue Mar 18 17:11:17 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 18 Mar 2008 15:11:17 -0700 Subject: [LLVMdev] Merge Patch File Message-ID: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> Hi all, The LLVM GCC merge patch file is available here: http://nondot.org/~void/llvm-r139307-r142930.diff.gz Share and enjoy! -bw From Alireza.Moshtaghi at microchip.com Tue Mar 18 19:22:40 2008 From: Alireza.Moshtaghi at microchip.com (Alireza.Moshtaghi at microchip.com) Date: Tue, 18 Mar 2008 17:22:40 -0700 Subject: [LLVMdev] 16 bit integers In-Reply-To: References: <47DFD9BF.2020209@fastmail.fm> Message-ID: How can I build the front-end to generate 16-bit integers? From evan.cheng at apple.com Tue Mar 18 19:27:46 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 18 Mar 2008 17:27:46 -0700 Subject: [LLVMdev] Google Summer of Code 2008 In-Reply-To: <200803182149.03786.jon@ffconsultancy.com> References: <200803182017.m2IKHpSG026329@star.math.spbu.ru> <200803182149.03786.jon@ffconsultancy.com> Message-ID: <0C54E4EB-0CB5-4190-9869-B98870F4AF4B@apple.com> On Mar 18, 2008, at 2:49 PM, Jon Harrop wrote: > On Tuesday 18 March 2008 20:17:52 Anton Korobeynikov wrote: >> Hello, Everyone >> >> LLVM recently was approved to take part in Google Summer of Code >> 2008. >> We welcome everyone to apply for this program. >> >> The list of ideas for (possible) projects is located at >> http://llvm.org/OpenProjects.html. Surely you can suggest any other >> project, if you feel, that it definitely can be useful. > > Just some ideas to add to the mix: > > One of the suggestions is to write a code-density optimizer for the > ARM > backend. For an interesting alternative, try optimizing for power > consumption > instead. If you want something super researchy, try doing this for > one of the > clockless (asynchronous) ARM cores: > > http://www.arm.com/products/CPUs/ARM996HS.html While we are talking about ARM. Raul H. worked on ARM JIT support last summer, it would be nice if someone continues the work. Evan > > > Another suggestion under "Miscellaneous Additions" was to write a new > front-end for Java/OCaml/Forth. IMHO, reimplementing Java or OCaml > from > scratch is way too much work and a lot of that work is uninteresting > baggage. > My personal dream is to implement a higher-level VM that bundles an > existing > concurrent GC with an intermediate representation that exposes high- > level > language-agnostic features like parametric polymorphism (generics), > first-class lexical closures (and maybe even pattern matching) and a > backend > that type specializes to remove polymorphism (and the associated run- > time > performance hit, as seen in OCaml) before LLVM code is generated. I > would > like this for two reasons: > > a) to provide the foundation for better technical computing > environments on > Linux and Mac OS X (like F# for Windows). This could greatly improve > the open > source tools that scientists and engineers use for technical > computing. > > b) to provide a CLR. This could make it much easier for industry to > build and > sell software written in exotic languages for Linux and Mac OS X. > > A tamer but related idea is to implement a Fortran 77 front-end for > LLVM and > then get LAPACK into the LLVM benchmark suite. This could help LLVM to > improve and might provide a faster LAPACK library for the open > source world. > > FFTW is another hugely important numerical library that could be > used for > benchmarking. Aside from simply getting FFTW to work using llvm-gcc, > an > interesting project might be to rewrite the OCaml source code in > FFTW to > generate codelets on-the-fly using LLVM or the CLang front-end. LLVM > can > probably beat GCC here, not least because an LLVM-based > implementation would > not be limited to a set of precompiled codelets. This could help the > millions > of people who use FFTW. > > On an unrelated note, LLVM has great potential for improving OCaml's > FFI. At > the moment, OCaml programmers are expected to write stubs in C and > statically > link them in with their OCaml code. A much better solution would be > to use > LLVM to generate the equivalent of the C stubs at run-time. Calling > OpenGL > directly from OCaml using LLVM without any existing OpenGL bindings > would > make an excellent example. This project could really help the OCaml > community. > > -- > Dr Jon D Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/products/?e > _______________________________________________ > 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 Mar 18 20:12:11 2008 From: gohman at apple.com (Dan Gohman) Date: Tue, 18 Mar 2008 18:12:11 -0700 Subject: [LLVMdev] SUBREG instructions and mayLoad/mayStore/etc. Message-ID: <9305AB27-1FAF-4488-AA12-CDACA003598B@apple.com> The new SUBREG target-independent instructions aren't getting mayLoad/mayStore flags set correctly. For example, in the generated X86GenInstrInfo.inc file, there is only one entry for INSERT_SUBREG: { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, OperandInfo107 }, // Inst #5 = INSERT_SUBREG THe sixth field is zero, which means it doesn't have the the MayLoad flag set. x86-64 does have a few variants of INSERT_SUBREG, and one of them does have a load: def : Pat<(i64 (anyext (loadi32 addr:$src))), (INSERT_SUBREG (i64 (IMPLICIT_DEF)), (MOV32rm addr:$src), x86_subreg_32bit)>; This isn't currently being reflected in the InstrInfo tables. Naively, it seems like we should add a separate INSERT_SUBREGrm instruction, and so on, or something like that, in order to be able to have accurate InstrInfo tables. Does anyone familiar with the new subregs infastructure have an opinion on this? Dan From evan.cheng at apple.com Tue Mar 18 20:23:30 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 18 Mar 2008 18:23:30 -0700 Subject: [LLVMdev] SUBREG instructions and mayLoad/mayStore/etc. In-Reply-To: <9305AB27-1FAF-4488-AA12-CDACA003598B@apple.com> References: <9305AB27-1FAF-4488-AA12-CDACA003598B@apple.com> Message-ID: On Mar 18, 2008, at 6:12 PM, Dan Gohman wrote: > The new SUBREG target-independent instructions aren't getting > mayLoad/mayStore flags set correctly. > > For example, in the generated X86GenInstrInfo.inc file, > there is only one entry for INSERT_SUBREG: > > { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, > OperandInfo107 }, // Inst #5 = INSERT_SUBREG > > THe sixth field is zero, which means it doesn't have the the > MayLoad flag set. I am not sure I understand. INSERT_SUBREG shouldn't have mayLoad / mayStore flags set. If it's not coalesced away, it's eventually lowered into a move. > > > x86-64 does have a few variants of INSERT_SUBREG, and one of > them does have a load: > > def : Pat<(i64 (anyext (loadi32 addr:$src))), > (INSERT_SUBREG (i64 (IMPLICIT_DEF)), (MOV32rm addr:$src), > > x86_subreg_32bit)>; > > > This isn't currently being reflected in the InstrInfo tables. > Naively, it seems like we should add a separate INSERT_SUBREGrm > instruction, and so on, or something like that, in order to be able > to have accurate InstrInfo tables. Does anyone familiar with the > new subregs infastructure have an opinion on this? This is saying the pattern should be isel into two instructions. MOV32rm is obviously a load, but INSERT_SUBREG doesn't load or store. Evan > > > Dan > > _______________________________________________ > 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 Mar 18 23:05:33 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 18 Mar 2008 21:05:33 -0700 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: <47DFEC12.7010502@fastmail.fm> References: <47DD655F.2010600@fastmail.fm> <47DFEC12.7010502@fastmail.fm> Message-ID: On Mar 18, 2008, at 9:21 AM, Wojciech Matyjewicz wrote: > Hi, > >> Cool! I think the most critical part of this is to get a good >> interface for dependence analysis. There are lots of interesting >> implementations that have various time/space tradeoffs. >> >> For example, it would be great if Omega was available as an option, >> even if the compiler didn't use it by default. This argues for >> making >> dependence analysis implementations pluggable like alias analyses. > > Yes, I also thought about it that way. I think we may look at the > dependence analysis in LLVM at three levels (from the lowest to the > highest one): > > 1) Testing for dependence given two sequences of GEP indices assuming > that base pointers are the same. The indices could have a SCEV form or > even be preprocessed to something simpler (affine expressions for > example). > > 2) Testing for dependence of two instructions (that access memory). It > would use alias analysis to answer some queries immediately, or to > check > whether two GEP base pointers equal. If the latter is the case, 1) > would > be used to check for dependences. > > 3) Complex queries (for example: does the given loop carry > dependence?). > It would use 2) and summarize its results. > > Only the first level could be pluggable allowing to interchange or > chain > core dependency testing techniques. I think there will be no use in > making pluggable the higher ones (please, correct me if I am wrong). > This approach would require to divide the analysis structure into two > parts, say; DependenceAnalysis and IndexingTester. This all sounds great to me! > That said, I must admit I haven't made it that way in my prototype. I > have it in mind, but I'm currently trying to keep things simple and > just > to check whether the precision of my implementation is worth anything. I'm fine with starting simple and generalizing it out from there. I'd actually recommend against trying to implement a maximally precise dependence analyzer without a client. With no client, there is no way to test that you're getting correct results and whether the improvements in precision are actually useful. I'd suggest starting out with a simple checker, e.g. that handles simple affine cases, and some client (a loop xform?). This should be enough to get the transformation working on simple loops, and when the client is tested and working there, you can use it to evaluate whether the precision improvements are worthwhile. If you're looking for a simple client, I'd suggest something like loop reversal. This requires a pretty simple dependence test and can be useful for some targets. The idea is to turn: for (i = 0 .. 100) A[i] = 4; into: for (i = 100 .. 0) A[i] = 4; Another transform that needs dependence analysis which would be even more useful (but still very simple) is a "loops to memset/memcpy" pass. This optimization would speed up the 'viterbi' program in the test suite a *lot* for the various 'history' loops. A simple version of this is: for (i = 0 .. 100) A[i] = 0; -> memset(A, 0, sizeof(A[0])*100); >> I'd suggest looking at: >> >> Using the chains of recurrences algebra for data dependence testing >> and induction variable substitution >> MS Thesis, Johnie Birch >> >> Array Data Dependence Testing with the Chains of Recurrences Algebra >> http://citeseer.ist.psu.edu/vanengelen04array.html >> >> An empirical evaluation of chains of recurrences for array dependence >> testing >> http://doi.acm.org/10.1145/1152154.1152198 > > I've read the second one, but am not sure if it's easy to implement if > overflow and unknown signedness are taken into account. For now, I > will > stick to the classical Banerjee test. If time allows I'll return to > the > article. Ok. Starting simple is good. Thanks again for working on this, this is a major hole in llvm, -Chris From vadve at cs.uiuc.edu Tue Mar 18 16:28:38 2008 From: vadve at cs.uiuc.edu (Vikram S. Adve) Date: Tue, 18 Mar 2008 17:28:38 -0400 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: References: <47DFD9BF.2020209@fastmail.fm> Message-ID: <9556-SnapperMsg8A45B0A8C406494C@[75.204.155.245]> I would not assume that a loop xform would mainly be interested in loop-*carried* dependencies. Some need loop-independent deps also, and some may even need deps outside loops. So making array dep analysis a function pass seems best. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org ...... Original Message ....... On Tue, 18 Mar 2008 11:03:31 -0500 "Devang Patel" wrote: > >On Mar 18, 2008, at 8:03 AM, Wojciech Matyjewicz wrote: > >> Hi, >> >> Devang Patel wrote: >>> LLVM loop transformer operates at loop level, which is not what many >>> optimizers do in general. So, a loop level interface (i.e. based on >>> LoopPass in llvm) to find loop-carried dependence is preferable to >>> loop optimizer. >> >> Do you mean making Array Dependence Analysis a loop-level analysis? >> Would its results be available for some function-level pass then? > >We could extend pass manager framework to let function-level pass use >loop-level analysis info. However that is not ideal. > >A loop level pass operates on a loop only. If a function level pass >needs array dependence analysis info then it expects info. to cover >entire function. Which means, it will need function level array >dependence analysis pass, which is natural. If loop level pass, say >LP, is interested in array dependence info, then in many cases it is >more interested in loop-carried dependence info for a given loop. If >such info. is made available to through a loop level pass then it'd >allow loop pass manager to execute allow loop pass manager to handle >LP together with other loop passes. > >- >Devang >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From rajikacc at gmail.com Tue Mar 18 23:52:44 2008 From: rajikacc at gmail.com (Rajika Kumarasiri) Date: Wed, 19 Mar 2008 10:22:44 +0530 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite Message-ID: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> hello everybody, I would like to improve the llvm-test suite[1] as a part of GSoC 2008 program for LLVM. I have few concerns/problems regarding this, please give me your feedbacks and suggestions to come up with the proper proposal. *Goal:* Improve the llvm-test testsuite. *Idea:* Extend the llvm-test testsuite to include new programs and benchmarks[2]. Test programs should be more CPU intensive with few library dependencies at the end which are delivered in source format. I have following few problems, please help me to understand them. 1. Before everything I need to clarify something. Normally we add tests in a software to check the correctness of that software code base. Here in this project llvm trying to specific on third party software codes. So I am not sure how a test be structured within llvm to check llvm code base correctness using those third party codes(This is what I understood, please correct me if I am wrong). I'd glad if I can get more information on this. 2. As described llvm testsuite program should be more CPU intensive programs, is there is any reason for that and how a llvm test suite program can make more CPU intensive, any points that should consider to write a more CPU intensive test program for llvm? 3. Since we need to avoid many library dependencies, we need to reduce dependencies to standard C/C++ libraries and llvm libraries itself.Is this correct ? If so any points that need to consider writing tests which has few library decencies? 4. What a test program should cover? As I read in the testsuite guide [3], test programs in llvm-test covers two things in general. It check for a particular LLVM feature or trigger a specific bug in LLVM. So in addition to that any other point that need to consider, along with the structure of a test case would be helpful And also as described test programs are code fragments and whole programs. I think in here also I may need to write either of them depending of the benchmark trying[2]. 5. Finally if I am going cover test programs for[3], may be setting few targets( targets in the sense that I am writing test programs for A variety of C++ benchmarks,BioPerf,LLC bench etc.., ) would be help to define the time line. May be more important one can be done in the first touch. Please guide me on these. Please correct me if I am wrong in anything. Thanks in advance! Me: I am a computer science undergraduate[4]. I'm interested in compiler technology and have experience in C/C++ programming.My resume [5]. [1] - http://llvm.org/OpenProjects.html#llvmtest [2] - http://nondot.org/sabre/LLVMNotes/#benchmarks [3] - http://llvm.org/docs/TestingGuide.html#org [4] - http://www.cse.mrt.ac.lk/ [5] - http://rajikacc.googlepages.com/resume_rajika.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080319/e2e27027/attachment.html From bruno.cardoso at gmail.com Wed Mar 19 00:46:15 2008 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Wed, 19 Mar 2008 02:46:15 -0300 Subject: [LLVMdev] GSoC Mips backend improvement Message-ID: <275e64e40803182246k7fbd0fd0v23b80d4936a1718@mail.gmail.com> Hi all, Last year i was mentored by Chris Lattner at GSoC and i created the Mips back-end for LLVM. The back-end is still experimental (working with simple benchmarks only) and this year i would like to improve it as my GSoC proposal. Mips is still fairly used nowadays in a lot of devices - routers, wireless cards, PSP, PS2 - and it would be great to have a stable mips backend for LLVM. General improvements : + Support little-endian Mips (mipsel) + Improve instruction scheduling to better support non interlock targets. + Support more subtargets. Roadmap : 1) Define a list of benchmarks and get all working. 2) Add float-point support. 3) Repeat 1). 4) Get llvm-gcc as cross-compiler fully working for Mips 5) add Mips32 complete ISA 6) choose one more subtarget to add support (Mips64/PSP/PS2). Which one you would say is more important? Using llvm to generate code for PSP would be very fun! Opinion and comments would be nice. I'll leave the timeline proposal to the students application at Google, i just want some feedback for now! Cheers, -- Bruno Cardoso Lopes ( now @ Cocos Island ) http://www.brunocardoso.cc ++ The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom + Isaac Asimov From baldrick at free.fr Wed Mar 19 03:11:23 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 19 Mar 2008 09:11:23 +0100 Subject: [LLVMdev] 16 bit integers In-Reply-To: References: Message-ID: <200803190911.23561.baldrick@free.fr> > How can I build the front-end to generate 16-bit integers? Please clarify your question. If you are asking how to build llvm-gcc for a 16 bit target, I think the answer is: (1) gcc itself doesn't support 16 bit targets; (2) llvm doesn't currently support any 16 bit targets (but could with a little work). So you are out of luck unless you are willing to work on it. Ciao, Duncan. From baldrick at free.fr Wed Mar 19 03:39:35 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 19 Mar 2008 09:39:35 +0100 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> Message-ID: <200803190939.36482.baldrick@free.fr> I would like to see: (1) LLVM testsuite run every night for all targets, target variants and operating systems, for example by using an emulator to emulate targets for which the hardware is not available. The gcc project has a compile farm which might be usable for this, but we would need to ask them if it is ok. (2) Likewise for the gcc testsuite, with results emailed to the nightly test mailing list. I would like the Fortran and Ada testsuites to be run as well as the C/C++/ObjC tests. Just some thoughts! Ciao, Duncan. From jo at durchholz.org Wed Mar 19 07:13:56 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Mar 2008 13:13:56 +0100 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> Message-ID: <1205928836.6918.15.camel@kurier> Am Mittwoch, den 19.03.2008, 10:22 +0530 schrieb Rajika Kumarasiri: > 2. As described llvm testsuite program should be more CPU intensive > programs, is there is any reason for that and how a llvm test suite > program can make more CPU intensive, any points that should consider > to write a more CPU intensive test program for llvm? I guess that's just trying to get the most effect out of machine time. Running a database application compiled with LLVM will do more to test the disk subsystem rather than the proper compilation of an application program. I think that's twofold. Tests that run a *lot* of complicated code would test the correctness of the compiler. Think code written by crazy people that does crazy things; such code would hit a lot more code paths in the LLVM compiler than something written by in-house application programmers that slavishly obey a set of style guidelines. The other situation is the usual CPU-intensive benchmarks. Number crunching of any kind, large symbolic computations (such as the program that first proved the four-color conjecture), scheduling programs for machine parks or logistics, running any kind of program on a JVM interpreter. This sort of stuff burns a whole lot of CPU cycles, and you can easily see whether the optimization passes are doing their work (and if you hit a case that takes longer than it should, there's an opportunity to identify yet another optimization technique or a mising tweak in an existing one that helps this particular application and - hopefully - all others, too). > 3. Since we need to avoid many library dependencies, we need to reduce > dependencies to standard C/C++ libraries and llvm libraries itself.Is > this correct ? I suspect dependencies on LLVM libs are OK. An application that needs lots of standard libraries would more likely hit version mismatch problems. Or the library in question would be unavailable for all platform (not so much a problem with open source libs, but closed ones are probably a no-no). > 4. What a test program should cover? > As I read in the testsuite guide [3], test programs in llvm-test > covers two things in general. It check for a particular LLVM feature > or trigger a specific bug in LLVM. So in addition to that any other > point that need to consider, along with the structure of a test case > would be helpful > And also as described test programs are code fragments and whole > programs. I think in here also I may need to write either of them > depending of the benchmark trying[2]. There are two test suites. One lives in llvm/test and I gather it checks for regressions and essential features (mostly). It is designed to run quickly (a few minutes). The other lives in projects/llvm-test and exercizes the full array of available tests, in particular those that take a lot of time (such tests help to identify optimizations that could improve). To further complicate matters, the llvm/test suite uses dejagnu to manage tests and collect results, while projects/llvm-test uses just makefiles. (I'm pretty sure I overlooked some aspects, I just read some tests, makefiles, and test results.) Hope I'm not too far off the mark :-) Regards, Jo From baldrick at free.fr Wed Mar 19 07:51:05 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 19 Mar 2008 13:51:05 +0100 Subject: [LLVMdev] Merge Patch File In-Reply-To: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> Message-ID: <200803191351.05786.baldrick@free.fr> > The LLVM GCC merge patch file is available here: > > http://nondot.org/~void/llvm-r139307-r142930.diff.gz > > Share and enjoy! On x86-linux: ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function ?output_pic_addr_const?: ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:7682: error: ?darwin_stubs? undeclared (first use in this function) ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:7682: error: (Each undeclared identifier is reported only once ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:7682: error: for each function it appears in.) ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function ?ix86_expand_move?: ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:9453: warning: unused variable ?insn? ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function ?ix86_expand_convert_uns_DI2DF_sse?: ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:10270: warning: large integer implicitly truncated to unsigned type ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function ?ix86_expand_convert_sign_DI2DF_sse?: ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:10377: warning: large integer implicitly truncated to unsigned type Ciao, D. From asl at math.spbu.ru Wed Mar 19 08:19:18 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Wed, 19 Mar 2008 16:19:18 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?UHJvcG9zYWwgZm9yIEdTb0MgcHJvamVjdCBmb3IgaW1w?= =?koi8-r?b?cm92aW5nCWxsdm0tdGVzdAl0ZXN0c3VpdGU=?= Message-ID: <200803191319.m2JDJIC4045408@star.math.spbu.ru> Hello, Everyone > Tests that run a *lot* of complicated code would test the correctness of > the compiler. Think code written by crazy people that does crazy things; Just my two cents. From time to time I'm testing LLVM via compiling & running such big beasts as Qt and Mozilla. Also, at 2.0 time I tried to compile & test bunch of software from KDE and many others. They cannot be easily included into LLVM testsuite: their build system usually is pretty complicated. But some solution definitely needs to be introduced. -- WBR, Anton Korobeynikov From hs4233 at mail.mn-solutions.de Wed Mar 19 08:49:43 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Wed, 19 Mar 2008 14:49:43 +0100 Subject: [LLVMdev] =?iso-8859-1?q?Proposal_for_GSoC_project_for_improving?= =?iso-8859-1?q?=09llvm-test=09testsuite?= In-Reply-To: <200803191319.m2JDJIC4045408@star.math.spbu.ru> References: <200803191319.m2JDJIC4045408@star.math.spbu.ru> Message-ID: <200803191449.43831.hs4233@mail.mn-solutions.de> > Just my two cents. From time to time I'm testing LLVM via > compiling & running such big beasts as Qt and Mozilla. Also, > at 2.0 time I tried to compile & test bunch of software from > KDE and many others. I tried to compile the 3D game engine "darkplaces" with llvm-gcc 4.2, but the produced binary didn't work. However, I didn't find out how debug this further :-/ If you want, I can send the commands to get darkplaces, Nexuiz data files, patch to makefile & makefile.inc for llvm-gcc compilation. From akyrtzi at gmail.com Wed Mar 19 09:11:43 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Wed, 19 Mar 2008 07:11:43 -0700 Subject: [LLVMdev] Proposal for GSoC project for clang front end Message-ID: <47E11F1F.4070806@gmail.com> Hi all, I'd like to hear your opinions and ideas for a proposal to improve support for C++ parsing for LLVM's clang front end. Goal: Improve clang's C++ support. The scope of the project will be limited to C++ parsing, not code generation (I think the timeframe of a GSoC project and the complexity of C++ doesn't allow full C++ support to be developed). C++ parsing support includes (but is not limited to): -Namespace declarations, using directives. -Class declarations, class members, methods etc. -Overload method/function matching. -C++ name lookup rules, scope resolution. -Class/function templates. Is LLVM interested in accepting such a proposal ? If yes, can you offer me hints on what is the best way to describe such a proposal (I mean, should I make a list about each and every specific C++ feature that the parser should be able to handle ?) Any thoughts about the subject will be greatly appreciated. About me: I'm an undergraduate student of electrical engineering in Democritus University of Greece (http://www.ee.duth.gr). I've been a user, contributor, and project leader, of various open-source projects over the years. I've gained some experience in C++ parsing when I developed an automatic wrapper for Ogre3D (http://www.ogre3d.org), that produces bindings for the CLR (http://sourceforge.net/projects/mogre). I think that LLVM+clang is the future of C++ development, and I'd be really happy to make a useful contribution to this great project :). -Argiris Kirtzidis From criswell at cs.uiuc.edu Wed Mar 19 09:54:57 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 19 Mar 2008 09:54:57 -0500 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> Message-ID: <47E12941.8010200@cs.uiuc.edu> Rajika Kumarasiri wrote: > hello everybody, > I would like to improve the llvm-test suite[1] as a part of GSoC 2008 program for LLVM. > I have few concerns/problems regarding this, please give me your feedbacks and suggestions to come up with the proper proposal. > So, here's the type of programs that I would like to see added to llvm-test. These are biased by past and current research agendas, so I'd be interested in knowing whether others would find such additions useful: 1) Pointer intensive applications (especially those written in C). We have a number of transforms that either improve memory performance (Automatic Pool Allocation) or whose overhead can be greater for pointer intensive programs (SAFECode). Having such programs would be useful for our research; they could also be used by others who are working on pointer-analysis based optimizations for LLVM. 2) Programs that are memory intensive (for the same reasons that I want pointer intensive programs). 3) Programs that are known to have found bugs in LLVM. There are many programs that LLVM compiles correctly. However, if you find one that exposes one or more bugs in LLVM, it might make a good candidate. kimwitu++ is in the test suite because it triggered 4 bugs and motivated 1 JIT optimization. -- John T. > Goal: Improve the llvm-test testsuite. > > Idea: Extend the llvm-test testsuite to include new programs and benchmarks[2]. Test programs should be more CPU intensive with few library dependencies at the end which are delivered in source format. > > I have following few problems, please help me to understand them. > > 1. Before everything I need to clarify something. > Normally we add tests in a software to check the correctness of that software code base. Here in this project llvm trying to specific on third party software codes. So I am not sure how a test be structured within llvm to check llvm code base correctness using those third party codes(This is what I understood, please correct me if I am wrong). I'd glad if I can get more information on this. > > 2. As described llvm testsuite program should be more CPU intensive programs, is there is any reason for that and how a llvm test suite program can make more CPU intensive, any points that should consider to write a more CPU intensive test program for llvm? > > 3. Since we need to avoid many library dependencies, we need to reduce dependencies to standard C/C++ libraries and llvm libraries itself.Is this correct ? If so any points that need to consider writing tests which has few library decencies? > > 4. What a test program should cover? > As I read in the testsuite guide [3], test programs in llvm-test covers two things in general. It check for a particular LLVM feature or trigger a specific bug in LLVM. So in addition to that any other point that need to consider, along with the structure of a test case would be helpful > And also as described test programs are code fragments and whole programs. I think in here also I may need to write either of them depending of the benchmark trying[2]. > > 5. Finally if I am going cover test programs for[3], may be setting few targets( targets in the sense that I am writing test programs for A variety of C++ benchmarks,BioPerf,LLC bench etc.., ) would be help to define the time line. May be more important one can be done in the first touch. > > Please guide me on these. Please correct me if I am wrong in anything. Thanks in advance! > > Me: > I am a computer science undergraduate[4]. I'm interested in compiler technology and have experience in C/C++ programming.My resume [5]. > > > [1] - http://llvm.org/OpenProjects.html#llvmtest > [2] - http://nondot.org/sabre/LLVMNotes/#benchmarks > [3] - http://llvm.org/docs/TestingGuide.html#org > [4] - http://www.cse.mrt.ac.lk/ > [5] - http://rajikacc.googlepages.com/resume_rajika.pdf > > > From jo at durchholz.org Wed Mar 19 10:59:17 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Mar 2008 16:59:17 +0100 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <200803191449.43831.hs4233@mail.mn-solutions.de> References: <200803191319.m2JDJIC4045408@star.math.spbu.ru> <200803191449.43831.hs4233@mail.mn-solutions.de> Message-ID: <1205942357.6918.39.camel@kurier> Am Mittwoch, den 19.03.2008, 14:49 +0100 schrieb Holger Schurig: > > Just my two cents. From time to time I'm testing LLVM via > > compiling & running such big beasts as Qt and Mozilla. Also, > > at 2.0 time I tried to compile & test bunch of software from > > KDE and many others. > > I tried to compile the 3D game engine "darkplaces" with llvm-gcc > 4.2, but the produced binary didn't work. "Didn't work" means... what? Compilation failed? Program doesn't work? Either way: what mesages do you get? Are there any differences when compiling with the standard 4.2 gcc? (Some distributions install gcc 4.0, you have to explicitly install gcc-4.2 to get the equivalent GNU compiler.) > However, I didn't find out how debug this further :-/ No problem, just run a few preliminary tests. This will allow people to determine what component the problem is in: code generator (if gcc works but gcc-llvm doesn't), language semantics (if neither gcc nor llvm-gcc work - probably a gcc problem then, playing around with -O2 or -O0 might make the problem go away; if that still doesn't help, there's a real possibility that the 3D driver or hardware is broken). Darkplaces is probably not a good test for the LLVM test suite. Any failure may be due to problems with the 3D hardware or the drivers, Regards, Jo From hs4233 at mail.mn-solutions.de Wed Mar 19 11:51:34 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Wed, 19 Mar 2008 17:51:34 +0100 Subject: [LLVMdev] =?iso-8859-1?q?Proposal_for_GSoC_project_for=09improvin?= =?iso-8859-1?q?g=09llvm-test=09testsuite?= In-Reply-To: <1205942357.6918.39.camel@kurier> References: <200803191319.m2JDJIC4045408@star.math.spbu.ru> <200803191449.43831.hs4233@mail.mn-solutions.de> <1205942357.6918.39.camel@kurier> Message-ID: <200803191751.34472.hs4233@mail.mn-solutions.de> > "Didn't work" means... what? Compilation failed? Program > doesn't work? Either way: what mesages do you get? Hey, this was two weeks ago. Compilation was fine, I get a binary. The game engine also emits various log statemtens when it starts, but then stopped somehow. Sorry for being so scarce on details, but I did this at home and am now at work. At about 20:30 hours german time my kids are in bed and I can give more details, even the exact llvm svn revision that I used for my test. > Are there any differences when compiling with the standard 4.2 > gcc? (Some distributions install gcc 4.0, you have to > explicitly install gcc-4.2 to get the equivalent GNU > compiler.) I'm on debian unstable, so I have lot's of different GCCs to try against. Normally I compile with the debian brand of gcc-4.2 and there it works. It's an actively maintained project, it works even with gcc-4.3 (this is from hearsay, not my own experiments). > Darkplaces is probably not a good test for the LLVM test > suite. I tried darkplaces because a) it's a complicated program, b) I play it once in a while with the nexuiz data and c) it has a benchmark mode, called "time demo". However, I too think that darkplaces in it's current for isn't for the automatic test suite because of the 3D hardware requirements. > Any failure may be due to problems with the 3D hardware > or the drivers, Maybe, but the game works correctly with several gcc compilers. From bagel99 at gmail.com Wed Mar 19 12:07:25 2008 From: bagel99 at gmail.com (Bagel) Date: Wed, 19 Mar 2008 12:07:25 -0500 Subject: [LLVMdev] Use of flags in selection dags Message-ID: <47E1484D.7030600@gmail.com> Can someone tell me, or point me to documentation, that explains the use of "flags" in the selection DAG? I figured out that, if one is present, it must be the last operand. But when are "flags" used and why? thanks, Bagel From dpatel at apple.com Wed Mar 19 12:21:03 2008 From: dpatel at apple.com (Devang Patel) Date: Wed, 19 Mar 2008 10:21:03 -0700 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <1205928836.6918.15.camel@kurier> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> <1205928836.6918.15.camel@kurier> Message-ID: <7699ECC8-A662-4E9C-AAB1-6A108ADDBECC@apple.com> On Mar 19, 2008, at 5:13 AM, Joachim Durchholz wrote: > There are two test suites. One lives in llvm/test and I gather it > checks > for regressions and essential features (mostly). It is designed to run > quickly (a few minutes). The goal here is to test features and check regressions. The tests are written by LLVM developers. Usually the tests are based on new features OR derived from bug reports. It is expected that each llvm check-in is proceeded by at least on llvm/test check. > The other lives in projects/llvm-test and exercizes the full array of > available tests, in particular those that take a lot of time (such > tests > help to identify optimizations that could improve). The primary goal here is to measure and monitor performance. This suite includes benchmarks and applications from various domains. This suite uses makefiles to accommodate benchmark and application specific build instructions. > To further complicate matters, the llvm/test suite uses dejagnu to > manage tests and collect results, while projects/llvm-test uses just > makefiles. - Devang From dpatel at apple.com Wed Mar 19 12:28:04 2008 From: dpatel at apple.com (Devang Patel) Date: Wed, 19 Mar 2008 10:28:04 -0700 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <200803190939.36482.baldrick@free.fr> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> <200803190939.36482.baldrick@free.fr> Message-ID: <3DF6E7B9-6E5A-4A73-A379-8A1858F8A7E1@apple.com> On Mar 19, 2008, at 1:39 AM, Duncan Sands wrote: > I would like to see: > > (1) LLVM testsuite run every night for all targets, target variants > and > operating systems, for example by using an emulator to emulate targets > for which the hardware is not available. The gcc project has a > compile > farm which might be usable for this, but we would need to ask them > if it > is ok. > (2) Likewise for the gcc testsuite, with results emailed to the > nightly > test mailing list. I would like the Fortran and Ada testsuites to > be run > as well as the C/C++/ObjC tests. > > Just some thoughts! I agree this would be useful. However these two items require access to lots of machine cycles. Do you anticipate lots of work, enough to justify for a GSoC proposal, in existing test setup to accommodate these two specific goals ? > > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev - Devang From baldrick at free.fr Wed Mar 19 12:47:52 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 19 Mar 2008 18:47:52 +0100 Subject: [LLVMdev] Use of flags in selection dags In-Reply-To: <47E1484D.7030600@gmail.com> References: <47E1484D.7030600@gmail.com> Message-ID: <200803191847.53408.baldrick@free.fr> > Can someone tell me, or point me to documentation, that explains the use > of "flags" in the selection DAG? I figured out that, if one is > present, it must be the last operand. But when are "flags" used and why? Please give details of the context, such as the kind of node you are looking at. Thanks, Duncan. From dpatel at apple.com Wed Mar 19 13:12:18 2008 From: dpatel at apple.com (Devang Patel) Date: Wed, 19 Mar 2008 11:12:18 -0700 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> Message-ID: <477C9932-BAC7-4D88-8EB7-D22B6B613A75@apple.com> On Mar 18, 2008, at 9:52 PM, Rajika Kumarasiri wrote: > hello everybody, > I would like to improve the llvm-test suite[1] as a part of GSoC > 2008 program for LLVM. > I have few concerns/problems regarding this, please give me your > feedbacks and suggestions to come up with the proper proposal. > > Goal: Improve the llvm-test testsuite. There are two parts : 1) llvm-project/llvm/test in svn. This part checks correctness and features. 2) Whole program testsuite, which is located at llvm-project/test- suite. This part includes benchmarks and applications. > > > Idea: Extend the llvm-test testsuite to include new programs and > benchmarks[2]. Test programs should be more CPU intensive with few > library dependencies at the end which are delivered in source format. > > I have following few problems, please help me to understand them. > > 1. Before everything I need to clarify something. > Normally we add tests in a software to check the correctness of > that software code base. This is done in 1)st part. > Here in this project llvm trying to specific on third party software > codes. So I am not sure how a test be structured within llvm to > check llvm code base correctness using those third party codes(This > is what I understood, please correct me if I am wrong). I'd glad if > I can get more information on this. When LLVM fails to build third party code, you want to derive small test cases to reproduce such failures. This small and independent tests are added in 1st part. > 2. As described llvm testsuite program should be more CPU intensive > programs, is there is any reason for that The goal here (in 2)nd part) is to measure the performance of the code generated by LLVM. > and how a llvm test suite program can make more CPU intensive, any > points that should consider to write a more CPU intensive test > program for llvm? IIUC, You do not want to write new test suite program here. You want to adopt existing programs and benchmarks and update them such that they fit in 2)nd part. Let's take BioPerf as an example. You want to take this existing benchmark and appropriately update its makefiles so that it builds on 2)nd part of llvm test-suite. I am not familiar with this benchmark itself, but it uses many external libraries the you want to minimize library use if possible. Finally, the benchmark is likely to use some sort of input data to measure performance. You want to adjust input data set such that it does not take hours to run this benchmark and at the same time it takes enough time to notice performance changes. > 3. Since we need to avoid many library dependencies, we need to > reduce dependencies to standard C/C++ libraries and llvm libraries > itself.Is this correct ? If so any points that need to consider > writing tests which has few library decencies? > > 4. What a test program should cover? > As I read in the testsuite guide [3], test programs in llvm-test > covers two things in general. It check for a particular LLVM feature > or trigger a specific bug in LLVM. So in addition to that any other > point that need to consider, along with the structure of a test case > would be helpful > And also as described test programs are code fragments and whole > programs. I think in here also I may need to write either of them > depending of the benchmark trying[2]. > > 5. Finally if I am going cover test programs for[3], may be setting > few targets( targets in the sense that I am writing test programs > for A variety of C++ benchmarks,BioPerf,LLC bench etc.., ) would be > help to define the time line. May be more important one can be done > in the first touch. > > > Please guide me on these. Please correct me if I am wrong in > anything. Thanks in advance! > > Me: > I am a computer science undergraduate[4]. I'm interested in compiler > technology and have experience in C/C++ programming.My resume [5]. > > > [1] - http://llvm.org/OpenProjects.html#llvmtest > [2] - http://nondot.org/sabre/LLVMNotes/#benchmarks > [3] - http://llvm.org/docs/TestingGuide.html#org > [4] - http://www.cse.mrt.ac.lk/ > [5] - http://rajikacc.googlepages.com/resume_rajika.pdf > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080319/5bdcd6b2/attachment.html From krad at crammerz-inc.net Wed Mar 19 13:16:15 2008 From: krad at crammerz-inc.net (Wilhansen Li) Date: Thu, 20 Mar 2008 02:16:15 +0800 Subject: [LLVMdev] Proposal for GSoC project for clang front end In-Reply-To: <47E11F1F.4070806@gmail.com> References: <47E11F1F.4070806@gmail.com> Message-ID: On 3/19/08, Argiris Kirtzidis wrote: > I'd like to hear your opinions and ideas for a proposal to improve > support for C++ parsing for LLVM's clang front end. > > Goal: > Improve clang's C++ support. The scope of the project will be limited to > C++ parsing, not code generation (I think the > timeframe of a GSoC project and the complexity of C++ doesn't allow full > C++ support to be developed). > > C++ parsing support includes (but is not limited to): > -Namespace declarations, using directives. > -Class declarations, class members, methods etc. > -Overload method/function matching. > -C++ name lookup rules, scope resolution. > -Class/function templates. > > Is LLVM interested in accepting such a proposal ? > If yes, can you offer me hints on what is the best way to describe such > a proposal (I mean, should I make a list about > each and every specific C++ feature that the parser should be able to > handle ?) > > Any thoughts about the subject will be greatly appreciated. > I'm also quite interested in improving the clang front-end: there are too many projects in dire need of a good C/C++ parser (like Code::Blocks or Eclipse's CDT for instance). However, I will have to admit that I'm not very experienced with creating parsers for programming languages (though I'm quite proficient with C++). In any case, I could probably take on a less daunting task like writing the documentation for clang (right now, the documentation is very, very....lacking), helping another participant (not too sure how to work it out though) or fixing some TODOs in the clang code (like providing a better alternative for the hard-coded include paths). Before I forget my introductions, I'm an undergrad of Computer Science and Math from Ateneo de Manila University (http://www.admu.edu.ph/) in the Philippines. -- Life is too short for dial-up. From isanbard at gmail.com Wed Mar 19 13:20:12 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 19 Mar 2008 11:20:12 -0700 Subject: [LLVMdev] Merge Patch File In-Reply-To: <200803191351.05786.baldrick@free.fr> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> Message-ID: <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> On Wed, Mar 19, 2008 at 5:51 AM, Duncan Sands wrote: > > The LLVM GCC merge patch file is available here: > > > > http://nondot.org/~void/llvm-r139307-r142930.diff.gz > > > > Share and enjoy! > > On x86-linux: > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function 'output_pic_addr_const': > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:7682: error: 'darwin_stubs' undeclared (first use in this function) > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:7682: error: (Each undeclared identifier is reported only once > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:7682: error: for each function it appears in.) > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function 'ix86_expand_move': > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:9453: warning: unused variable 'insn' Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080317/059912.html > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function 'ix86_expand_convert_uns_DI2DF_sse': > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:10270: warning: large integer implicitly truncated to unsigned type > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function 'ix86_expand_convert_sign_DI2DF_sse': > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:10377: warning: large integer implicitly truncated to unsigned type > These aren't from the patch... -bw From jo at durchholz.org Wed Mar 19 14:00:48 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Mar 2008 20:00:48 +0100 Subject: [LLVMdev] Proposal for GSoC project for clang front end In-Reply-To: References: <47E11F1F.4070806@gmail.com> Message-ID: <1205953248.6918.50.camel@kurier> Am Donnerstag, den 20.03.2008, 02:16 +0800 schrieb Wilhansen Li: > I'm also quite interested in improving the clang front-end: there are > too many projects in dire need of a good C/C++ parser (like > Code::Blocks or Eclipse's CDT for instance). Yes, and C++ is one of the worst parsing nightmares that exist. Prepare to maintain your code for years to come, or consider it a throwaway project. Does anybody know what the status of gcc-xml relative to clang is? (gcc-xml is reworking the g++ parser to emit XML. It's not complete, but it should fit the needs of Code::Blocks or CDT nicely once it's done.) Regards, Jo From baldrick at free.fr Wed Mar 19 14:11:15 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 19 Mar 2008 20:11:15 +0100 Subject: [LLVMdev] Merge Patch File In-Reply-To: <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> Message-ID: <200803192011.16462.baldrick@free.fr> Hi Bill, thanks for fixing it. > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function 'ix86_expand_convert_uns_DI2DF_sse': > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:10270: warning: large integer implicitly truncated to unsigned type > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function 'ix86_expand_convert_sign_DI2DF_sse': > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:10377: warning: large integer implicitly truncated to unsigned type > > > These aren't from the patch... Yup, it's been like that for ever. I was secretly hoping you would fix them too :) Ciao, Duncan. From gabor at mac.com Wed Mar 19 14:58:33 2008 From: gabor at mac.com (Gabor Greif) Date: Wed, 19 Mar 2008 20:58:33 +0100 Subject: [LLVMdev] 2 experimental projects Message-ID: <8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com> Hi all, I have two llvm projects in different stages of execution: 1) Parallel "make check". Modelled after the successful clang "make test -jX" experiment, I am now bold enough to sink my teeth into the LLVM test suite. I have a prototype implementation, along the same lines, ready. 2) size reduction. After some conversation with Chris I think we are ready for a 16 -> 12 byte size reduction of the Use class. There are some collateral improvements too. This project is in its conceptual phase. To drive forward these projects I prefer to work on branches. So I apply for a branches/ggreif/... hierarchy in the repository. I shall make it easy to use "svn switch ..." for the relevant directories for anybody who wants to test my work. After I feel that all is stable and nice, I will make a diff for review and get back to this list. After successful review and rework, I shall merge back to main. What do you think? Cheers, Gabor PS: These are *not* GSoC projects :-) From hs4233 at mail.mn-solutions.de Wed Mar 19 15:09:26 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Wed, 19 Mar 2008 21:09:26 +0100 Subject: [LLVMdev] =?iso-8859-1?q?Proposal_for_GSoC_project_for=09improvin?= =?iso-8859-1?q?g=09llvm-test=09testsuite?= In-Reply-To: <1205942357.6918.39.camel@kurier> References: <200803191319.m2JDJIC4045408@star.math.spbu.ru> <200803191449.43831.hs4233@mail.mn-solutions.de> <1205942357.6918.39.camel@kurier> Message-ID: <200803192109.27283.hs4233@mail.mn-solutions.de> > "Didn't work" means... what? Compilation failed? Program doesn't work? > Either way: what mesages do you get? The graphical screen was just blank. darkplaces emits some log messages as usual. But step by step... Used LLVM-GCC ------------- The used llvm-gcc, when run with "llmv-gcc --version" shows "llvm-gcc (GCC) 4.2.1 (Based on Apple Inc. build 5546) (LLVM build 47212)". So it has been a month ago when I did this test. I'm building llvm and llvm-gcc with the attached Makefile. There you can see what I'm using for configure, but I guess that's nothing too fancy. Used Darkplaces --------------- I'm used darkplaces from SVN. Not sure what SVN revision it was a month ago, but the same problem happens with the current one. To get exactly the same engine source code that I currently have, do $ svn co -r8212 svn://svn.icculus.org/twilight/trunk/darkplaces Now apply the following attached "llvm.patch" to it. The patch changes: * DO_CC to be "llvm-gcc --emit-llvm" * DO_LD to be "llvm-ld -O2 -native -time-passes" * CPUOPTIMIZATIONS=-march=athlon * don't compile builddate.c on-the-fly at link time, because llvm-ld can't do that * don't set LDFLAGS_RELEASE to be the same as the compiler optimization flags Now do "make cl-release" and you should get an executable named "darkplaces-glx". Used Nexuiz data files ---------------------- Finally you need the nexuiz data files. They are rather huge, a whopping 363 MB. Get them like this from http://mesh.dl.sourceforge.net/sourceforge/nexuiz/nexuiz-24.zip. Extract it, e.g. with "unzip -x nexuiz-24.zip" Run the whole thing ------------------- I call the engine this way: $ ./darkplaces-glx \ -window -developer -nexuiz -basedir /usr/src/darkplaces/Nexuiz "-window" makes the program not use fullscreen, then you can still see the log output. "-developer" turns additional messages and warnings on. "-nexuiz" switches the engine into nexuiz mode, the mode must suit the data files. And for "-basedir" add the full path to the data files you downloaded and extract. Once started, the game will emit lot's of log output: Console initialized. Nexuiz Linux 20:12:44 Mar 19 2008 Trying to load library... "libz.so.1" - loaded. ... ========Initialized========= Client using an automatically assigned port Client opened a socket on address local:2 Client opened a socket on address 0.0.0.0:56687 Besides the log output to stdout, it also opens a graphical window. Then the engine should display a graphical, stylized "n" shortly before it emits the "Initialized" line. And this is the first difference between the llvm-gcc darkplaces-glx and the gcc-4.2 darkplaces. Later it should show another uglier "n", then three screens where you can use the mouse to select things. However, with the llvm-gcc version I just see a dark screen. And here it hangs and eat's CPU time. I must admit that I was too lazy to simply run the program under gdb's auspice and interrupt/backtrace it :-/ Used gcc-4.2 darkplace engine ----------------------------- To get a working engine from SVN, I keep the makefile/makefile.inc in it's (almost) original form and just make sure that CC=gcc-4.2 CPUOPTIMIZATIONS=-march=athlon Now I also compile with "make cl-release". The used compiler show fors "gcc-4.2 --version" the text "gcc-4.2 (GCC) 4.2.3 (Debian 4.2.3-2)". With this version, there is a graphical output, a stylized n, displayed even before the line "========Initialized=========" appears in the log. The gcc-compiled one emits some more messages to log: ========Initialized========= Client using an automatically assigned port Client opened a socket on address local:2 Client opened a socket on address 0.0.0.0:56687 Map farewell provides unknown info item author_email, ignored Map farewell provides unknown info item author_www, ignored Map warfare provides unknown info item author_email, ignored Map warfare provides unknown info item author_www, ignored Attempted division by zero in menu Attempted division by zero in menu Attempted division by zero in menu Attempted division by zero in menu ln: 5 iterations Sending extended response requests... Fake CD track 1 playing... At this time, I see the game menu and can select any options. -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: text/x-makefile Size: 5945 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080319/f3bbb813/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: text/x-diff Size: 3663 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080319/f3bbb813/attachment-0003.bin From isanbard at gmail.com Wed Mar 19 15:10:31 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 19 Mar 2008 13:10:31 -0700 Subject: [LLVMdev] Merge Patch File In-Reply-To: <200803192011.16462.baldrick@free.fr> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> <200803192011.16462.baldrick@free.fr> Message-ID: <16e5fdf90803191310s385d3908hcfdad1df7e1ec95a@mail.gmail.com> On Wed, Mar 19, 2008 at 12:11 PM, Duncan Sands wrote: > Hi Bill, thanks for fixing it. > No prob! :-) > > > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function 'ix86_expand_convert_uns_DI2DF_sse': > > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:10270: warning: large integer implicitly truncated to unsigned type > > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function 'ix86_expand_convert_sign_DI2DF_sse': > > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:10377: warning: large integer implicitly truncated to unsigned type > > > > > These aren't from the patch... > > Yup, it's been like that for ever. I was secretly hoping you would > fix them too :) > :-) Yeah, I looked at the code and didn't know of a good way to tackle it...I'm *assuming* that it's complaining about this value: 0x10000000000000ULL but can't be for sure. I'm nervous dealing with the REAL_VALUE_FROM_INT functions... -bw From tonic at nondot.org Wed Mar 19 15:35:20 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Wed, 19 Mar 2008 13:35:20 -0700 (PDT) Subject: [LLVMdev] 2 experimental projects In-Reply-To: <8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com> References: <8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com> Message-ID: > 1) Parallel "make check". > Modelled after the successful clang "make test -jX" experiment, I am > now bold enough to sink my teeth into the LLVM test suite. > I have a prototype implementation, along the same lines, ready. Can you please explain this in detail. Thanks, Tanya From sabre at nondot.org Wed Mar 19 15:45:34 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 19 Mar 2008 13:45:34 -0700 (PDT) Subject: [LLVMdev] 2 experimental projects In-Reply-To: <8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com> References: <8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com> Message-ID: On Wed, 19 Mar 2008, Gabor Greif wrote: > 2) size reduction. > After some conversation with Chris I think we are ready for a > 16 -> 12 byte size reduction of the Use class. There are some > collateral improvements too. This project is in its conceptual phase. Yay. > To drive forward these projects I prefer to work on branches. So I > apply for a branches/ggreif/... hierarchy in the repository. I shall > make > it easy to use "svn switch ..." for the relevant directories for anybody > who wants to test my work. Sure, go for it. > After I feel that all is stable and nice, I will make a diff for review > and get back to this list. After successful review and rework, I shall > merge back to main. Sounds good. Just for sake of making patch review simpler, please make the proposed patches as small and independent as possible. > PS: These are *not* GSoC projects :-) :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From gabor at mac.com Wed Mar 19 15:38:51 2008 From: gabor at mac.com (Gabor Greif) Date: Wed, 19 Mar 2008 21:38:51 +0100 Subject: [LLVMdev] 2 experimental projects Message-ID: <2C97762B-F660-4D86-BBC5-FB9011BDED32@mac.com> >> 1) Parallel "make check". >> Modelled after the successful clang "make test -jX" experiment, I am >> now bold enough to sink my teeth into the LLVM test suite. >> I have a prototype implementation, along the same lines, ready. > >Can you please explain this in detail. > >Thanks, >Tanya Sure. This is how "make test -j4" in clang works now: The makefile locates all relevant test files inside the specified test directories, that is files ending with ".cpp", ".c" and ".m", synthesizes the targets by appending ".testresults". These targets are then built in parallel by a recursive invocation of $(MAKE). A build rule of form Output/%.testresults: % invokes the TestRunner.sh script. Depending on the verbosity asked for, more or less summary and error information is shown to the user. My measurements on a 4-processor machine have shown test time reduction of 60% when the tests were invoked as "make test -j8". In case of the llvm tests the situation is somewhat more complicated, since dejagnu is driving the process, and dejagnu hinders us in a direct $(MAKE) invocation, so it falls back to -j1. My approach is thus using dejagnu to build up makefiles in test/.../Output/... and when these makefiles are executed by $(MAKE) we will get the same output as before. Each of the makefiles shall create the .testresults files just like clang tests do. This is the plan. Cheers, Gabor From nadav256 at gmail.com Wed Mar 19 15:42:17 2008 From: nadav256 at gmail.com (Nadav Rotem) Date: Wed, 19 Mar 2008 22:42:17 +0200 Subject: [LLVMdev] LLVM Python binding Message-ID: <47E17AA9.5080309@gmail.com> Hello, I am developing an application which is Python based and uses LLVM. I use LLVM by generating textual bitcode files and feeding them to my plug-in. I wish LLVM had Python binding. I would love to see Python binding as one of the GSoC projects so someone from the community can pick it up. Cheers, Nadav From sabre at nondot.org Wed Mar 19 16:15:20 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 19 Mar 2008 14:15:20 -0700 (PDT) Subject: [LLVMdev] 16 bit integers In-Reply-To: <200803190911.23561.baldrick@free.fr> References: <200803190911.23561.baldrick@free.fr> Message-ID: On Wed, 19 Mar 2008, Duncan Sands wrote: >> How can I build the front-end to generate 16-bit integers? > > Please clarify your question. > If you are asking how to build llvm-gcc for a 16 bit target, > I think the answer is: (1) gcc itself doesn't support 16 bit > targets; (2) llvm doesn't currently support any 16 bit targets > (but could with a little work). So you are out of luck unless > you are willing to work on it. Note that if you only care about C/ObjC (not C++, fortran, ada, etc) that clang may be a good option for you. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From tonic at nondot.org Wed Mar 19 16:19:07 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Wed, 19 Mar 2008 14:19:07 -0700 (PDT) Subject: [LLVMdev] 2 experimental projects In-Reply-To: <2C97762B-F660-4D86-BBC5-FB9011BDED32@mac.com> References: <2C97762B-F660-4D86-BBC5-FB9011BDED32@mac.com> Message-ID: > In case of the llvm tests the situation is somewhat more > complicated, since dejagnu is driving the process, and > dejagnu hinders us in a direct $(MAKE) invocation, so > it falls back to -j1. My approach is thus using dejagnu > to build up makefiles in test/.../Output/... and when > these makefiles are executed by $(MAKE) we will > get the same output as before. Each of the makefiles > shall create the .testresults files just like clang tests do. To be clear... do you plan to use the exisiting mechanism to execute the "RUN" lines? This is much preferred over the TestRunner script and there are many reasons why we transition away from using TestRunner. Also, will you preserve the ability to run a subset of tests via TESTSUITE=X? Will dejagnu still produce one log file or will there be multiples? How will this impact the nightly testers? While its cool to run them in parallel, I don't want to lose the functionality that we have now with dejagnu/tcl. Thanks, Tanya From sabre at nondot.org Wed Mar 19 16:27:18 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 19 Mar 2008 14:27:18 -0700 (PDT) Subject: [LLVMdev] Proposal for GSoC project for clang front end In-Reply-To: <47E11F1F.4070806@gmail.com> References: <47E11F1F.4070806@gmail.com> Message-ID: On Wed, 19 Mar 2008, Argiris Kirtzidis wrote: > I'd like to hear your opinions and ideas for a proposal to improve > support for C++ parsing for LLVM's clang front end. Some meta feedback: C++ support in clang is a huge project, far and away more than any mortal can get done in a summer. While it would be possible to sketch out the parser itself in the summer (providing the equivalent of -parse-noop for C) this won't be able to handle a lot of interesting cases. C++ requires a significant amount of semantic analysis just to get parsing correct. > Goal: > Improve clang's C++ support. The scope of the project will be limited to > C++ parsing, not code generation (I think the > timeframe of a GSoC project and the complexity of C++ doesn't allow full > C++ support to be developed). Ok, remember that parsing is only one piece of the puzzle. We also have semantic analysis/typechecking/ASTBuilding as well. I think that focusing on -fsyntax-only is a good place to be. > C++ parsing support includes (but is not limited to): > -Namespace declarations, using directives. > -Class declarations, class members, methods etc. > -Overload method/function matching. > -C++ name lookup rules, scope resolution. > -Class/function templates. Ok, pick one or maybe two of these. I think it would be much better to have namespaces fully implemented than have everything sorta implemented. If I were going to pick, I would suggest focusing on getting simple methods implemented, along with instance variables, etc through -fsyntax-only. This should be a reasonable amount of work for a summer. Something like this should work for example: class foo { int X; typedef float Z; int test(Z a) { return a+X; } int test2(q r); tyepdef float q; }; int foo::test2(q r) { return X+r; } No overloading, not templates, but handling the basic "class issues". Static methods would be a bonus :) > Is LLVM interested in accepting such a proposal ? Yes! -Chris -- http://nondot.org/sabre/ http://llvm.org/ From edwintorok at gmail.com Wed Mar 19 16:03:06 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Wed, 19 Mar 2008 23:03:06 +0200 Subject: [LLVMdev] Merge Patch File In-Reply-To: <16e5fdf90803191310s385d3908hcfdad1df7e1ec95a@mail.gmail.com> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> <200803192011.16462.baldrick@free.fr> <16e5fdf90803191310s385d3908hcfdad1df7e1ec95a@mail.gmail.com> Message-ID: <47E17F8A.9090504@gmail.com> Bill Wendling wrote: > On Wed, Mar 19, 2008 at 12:11 PM, Duncan Sands wrote: > >> Hi Bill, thanks for fixing it. >> >> > No prob! :-) I can't build llvm-gcc4.2 on x86-32 Linux. What is kext64, and how do I disable it? (I suppose I don't need it on a 32-bit platform?) ..... ranlib kext/libgcc_eh.a /home/edwin/llvm/obj42/./gcc/xgcc -B/home/edwin/llvm/obj42/./gcc/ -B/home/edwin/llvm/obj42/../install/i686-pc-linux-gnu/bin/ -B/home/edwin/llvm/obj42/../install/i686-pc-linux-gnu/lib/ -isystem /home/edwin/llvm/obj42/../install/i686-pc-linux-gnu/include -isystem /home/edwin/llvm/obj42/../install/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../llvm-gcc4.2/gcc -I../../llvm-gcc4.2/gcc/. -I../../llvm-gcc4.2/gcc/../include -I../../llvm-gcc4.2/gcc/../libcpp/include -I../../llvm-gcc4.2/gcc/../libdecnumber -I../libdecnumber -I/home/edwin/llvm/llvm-svn/trunk/include -I/home/edwin/llvm/llvm-svn/trunk//include -mkernel -m64 -Dmalloc=kern_os_malloc -Dfree=kern_os_free -DLIBCC_KEXT -DL_muldi3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../llvm-gcc4.2/gcc/libgcc2.c -o libgcc/kext64/_muldi3.o ../../llvm-gcc4.2/gcc/libgcc2.c:1: sorry, unimplemented: 64-bit mode not compiled in make[4]: *** [libgcc/kext64/_muldi3.o] Error 1 make[4]: Leaving directory `/var/local/src/llvm/obj42/gcc' I configured as: ../llvm-gcc4.2/configure --prefix=/home/edwin/llvm/obj42/../install --enable-llvm=/home/edwin/llvm/llvm-svn/trunk/ --program-prefix=llvm- --enable-checking=release --enable-languages=c,c++ Thanks, --Edwin From Alireza.Moshtaghi at microchip.com Wed Mar 19 16:17:07 2008 From: Alireza.Moshtaghi at microchip.com (Alireza.Moshtaghi at microchip.com) Date: Wed, 19 Mar 2008 14:17:07 -0700 Subject: [LLVMdev] 16 bit integers In-Reply-To: References: <200803190911.23561.baldrick@free.fr> Message-ID: Yes, I am working on an 8-bit target and I am only interested in C. We have made some progress in adapting llvm to lower and generate the target instructions from the current llvm-gcc output, however, we would like to have 16-bit int type for this target, and currently, llvm-gcc assumes 32-bit int, and of course, 32-bit integer promotions. I know some other ports of gcc have 16-bit int type, so I am looking for a way to configure (or if needed to modify) the front-end to generate 16-bit int type and only promote the integer calculation to 16-bit. Ideally I would like to disable the integer promotions in the front-end (going out of the standard for performance purposes) and take care of them in my backend as needed. Thanks, A. -----Original Message----- From: Chris Lattner [mailto:sabre at nondot.org] Sent: Wednesday, March 19, 2008 2:15 PM To: LLVM Developers Mailing List Cc: Alireza Moshtaghi - C13012 Subject: Re: [LLVMdev] 16 bit integers On Wed, 19 Mar 2008, Duncan Sands wrote: >> How can I build the front-end to generate 16-bit integers? > > Please clarify your question. > If you are asking how to build llvm-gcc for a 16 bit target, > I think the answer is: (1) gcc itself doesn't support 16 bit > targets; (2) llvm doesn't currently support any 16 bit targets > (but could with a little work). So you are out of luck unless > you are willing to work on it. Note that if you only care about C/ObjC (not C++, fortran, ada, etc) that clang may be a good option for you. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From mrs at apple.com Wed Mar 19 16:37:55 2008 From: mrs at apple.com (Mike Stump) Date: Wed, 19 Mar 2008 14:37:55 -0700 Subject: [LLVMdev] Merge Patch File In-Reply-To: <47E17F8A.9090504@gmail.com> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> <200803192011.16462.baldrick@free.fr> <16e5fdf90803191310s385d3908hcfdad1df7e1ec95a@mail.gmail.com> <47E17F8A.9090504@gmail.com> Message-ID: On Mar 19, 2008, at 2:03 PM, T?r?k Edwin wrote: > > What is kext64, and how do I disable it? Comes from: APPLE_LOCAL='APPLE LOCAL libcc_kext' \ MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` static;@static at fno-pic kext;@Dmal loc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT@static at fno-pic@fno- exceptions at fno-non-ca ll-exceptions$(KEXT_EXTRA_FLAGS) $(if $(findstring i686,$ (target)),kext64;@mkernel at m64@Dma lloc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT$ (KEXT_EXTRA_FLAGS))" \ EXTRA_MULTILIB_PARTS='$(EXTRA_MULTILIB_PARTS)' \ in gcc/Makefile.in. I'd recommend something like: # APPLE LOCAL begin libcc_kext ifeq ($taregt, *-*-darwin*) SPELLING APPLE_EXTRA_MULTI := static;@static at fno-pic kext;@Dmalloc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT@static at fno- pic at fno-exceptions@fno-non-call-exceptions$(KEXT_EXTRA_FLAGS) $(if $ (findstring i686,$ (target )),kext64 ;@mkernel at m64@Dmalloc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT$ (KEXT_EXTRA_FLAGS)) endif # APPLE LOCAL end libcc_kext APPLE_LOCAL='APPLE LOCAL libcc_kext' \ MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` $ (APPLE_EXTRA_MULTI)" \ EXTRA_MULTILIB_PARTS='$(EXTRA_MULTILIB_PARTS)' \ From gabor at mac.com Wed Mar 19 16:48:21 2008 From: gabor at mac.com (Gabor Greif) Date: Wed, 19 Mar 2008 22:48:21 +0100 Subject: [LLVMdev] 2 experimental projects Message-ID: >> In case of the llvm tests the situation is somewhat more >> complicated, since dejagnu is driving the process, and >> dejagnu hinders us in a direct $(MAKE) invocation, so >> it falls back to -j1. My approach is thus using dejagnu >> to build up makefiles in test/.../Output/... and when >> these makefiles are executed by $(MAKE) we will >> get the same output as before. Each of the makefiles >> shall create the .testresults files just like clang tests do. > >To be clear... do you plan to use the exisiting mechanism to execute the >"RUN" lines? This is much preferred over the TestRunner script and there >are many reasons why we transition away from using TestRunner. The RUN: lines will be executed in the same way as before. > >Also, will you preserve the ability to run a subset of tests via >TESTSUITE=X? > Yes. >Will dejagnu still produce one log file or will there be multiples? > There will be per-suite logfiles and also the big digest concatenated together. >How will this impact the nightly testers? > It shouldn't. If it does, then it is a bug and will be fixed. >While its cool to run them in parallel, I don't want to lose the >functionality that we have now with dejagnu/tcl. > Me neither :-) >Thanks, >Tanya Cheers, Gabor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080319/5e8a1c22/attachment.html From isanbard at gmail.com Wed Mar 19 16:55:44 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 19 Mar 2008 14:55:44 -0700 Subject: [LLVMdev] Merge Patch File In-Reply-To: References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> <200803192011.16462.baldrick@free.fr> <16e5fdf90803191310s385d3908hcfdad1df7e1ec95a@mail.gmail.com> <47E17F8A.9090504@gmail.com> Message-ID: <16e5fdf90803191455vdfdb493t895f836753418386@mail.gmail.com> Thanks, Mike! I applied this to the tree. T?r?k, please give it a try. In the meantime, I'm going to try on a Linux machine I just got access to. -bw On Wed, Mar 19, 2008 at 2:37 PM, Mike Stump wrote: > On Mar 19, 2008, at 2:03 PM, T?r?k Edwin wrote: > > > > What is kext64, and how do I disable it? > > Comes from: > > APPLE_LOCAL='APPLE LOCAL libcc_kext' \ > MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` > static;@static at fno-pic kext;@Dmal > loc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT@static at fno-pic@fno- > exceptions at fno-non-ca > ll-exceptions$(KEXT_EXTRA_FLAGS) $(if $(findstring i686,$ > (target)),kext64;@mkernel at m64@Dma > lloc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT$ > (KEXT_EXTRA_FLAGS))" \ > EXTRA_MULTILIB_PARTS='$(EXTRA_MULTILIB_PARTS)' \ > > in gcc/Makefile.in. I'd recommend something like: > > # APPLE LOCAL begin libcc_kext > ifeq ($taregt, *-*-darwin*) SPELLING > APPLE_EXTRA_MULTI := static;@static at fno-pic > kext;@Dmalloc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT@static at fno- > pic at fno-exceptions@fno-non-call-exceptions$(KEXT_EXTRA_FLAGS) $(if $ > (findstring i686,$ > (target > )),kext64 > ;@mkernel at m64@Dmalloc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT$ > (KEXT_EXTRA_FLAGS)) > endif > # APPLE LOCAL end libcc_kext > > APPLE_LOCAL='APPLE LOCAL libcc_kext' \ > MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` $ > (APPLE_EXTRA_MULTI)" \ > EXTRA_MULTILIB_PARTS='$(EXTRA_MULTILIB_PARTS)' \ > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From gohman at apple.com Wed Mar 19 17:23:56 2008 From: gohman at apple.com (Dan Gohman) Date: Wed, 19 Mar 2008 15:23:56 -0700 Subject: [LLVMdev] SUBREG instructions and mayLoad/mayStore/etc. In-Reply-To: References: <9305AB27-1FAF-4488-AA12-CDACA003598B@apple.com> Message-ID: On Mar 18, 2008, at 6:23 PM, Evan Cheng wrote: >> >> This isn't currently being reflected in the InstrInfo tables. >> Naively, it seems like we should add a separate INSERT_SUBREGrm >> instruction, and so on, or something like that, in order to be able >> to have accurate InstrInfo tables. Does anyone familiar with the >> new subregs infastructure have an opinion on this? > > This is saying the pattern should be isel into two instructions. > MOV32rm is obviously a load, but INSERT_SUBREG doesn't load or store. Thanks, this is where I was confused. Dan From mrs at apple.com Wed Mar 19 18:33:10 2008 From: mrs at apple.com (Mike Stump) Date: Wed, 19 Mar 2008 16:33:10 -0700 Subject: [LLVMdev] Merge Patch File In-Reply-To: <16e5fdf90803191455vdfdb493t895f836753418386@mail.gmail.com> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> <200803192011.16462.baldrick@free.fr> <16e5fdf90803191310s385d3908hcfdad1df7e1ec95a@mail.gmail.com> <47E17F8A.9090504@gmail.com> <16e5fdf90803191455vdfdb493t895f836753418386@mail.gmail.com> Message-ID: <4B87EF4D-3C61-4CEA-8AFA-133D8DCF1AE6@apple.com> On Mar 19, 2008, at 2:55 PM, Bill Wendling wrote: > Thanks, Mike! I applied this to the tree. No, you applied something else to the tree! :-) I had a space before the \ and after the ". The below should fix it. Doing diffs in .: --- ./Makefile.in.~1~ 2008-03-19 15:45:54.000000000 -0700 +++ ./Makefile.in 2008-03-19 16:30:07.000000000 -0700 @@ -1689,7 +1689,7 @@ libgcc.mk: config.status Makefile mklibg D128PBIT='$(D128PBIT)' \ D128PBIT_FUNCS='$(D128PBIT_FUNCS)' \ APPLE_LOCAL='APPLE LOCAL libcc_kext' \ - MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` $ (APPLE_EXTRA_MULTI)"\ + MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` $ (APPLE_EXTRA_MULTI)" \ EXTRA_MULTILIB_PARTS='$(EXTRA_MULTILIB_PARTS)' \ SHLIB_LINK='$(SHLIB_LINK)' \ SHLIB_INSTALL='$(SHLIB_INSTALL)' \ -------------- From echristo at apple.com Wed Mar 19 19:22:30 2008 From: echristo at apple.com (Eric Christopher) Date: Wed, 19 Mar 2008 17:22:30 -0700 Subject: [LLVMdev] 16 bit integers In-Reply-To: <200803190911.23561.baldrick@free.fr> References: <200803190911.23561.baldrick@free.fr> Message-ID: <53CECC9A-F2F3-42BB-B932-16DA5CA0EB9F@apple.com> On Mar 19, 2008, at 1:11 AM, Duncan Sands wrote: > I think the answer is: (1) gcc itself doesn't support 16 bit > targets; gcc does, in fact, support some 16-bit targets. -eric From wmatyjewicz at fastmail.fm Wed Mar 19 19:35:41 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Thu, 20 Mar 2008 01:35:41 +0100 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: References: <47DD655F.2010600@fastmail.fm> <47DFEC12.7010502@fastmail.fm> Message-ID: <47E1B15D.7040802@fastmail.fm> Chris Lattner wrote: > I'm fine with starting simple and generalizing it out from there. I'd > actually recommend against trying to implement a maximally precise > dependence analyzer without a client. With no client, there is no way > to test that you're getting correct results and whether the > improvements in precision are actually useful. > > I'd suggest starting out with a simple checker, e.g. that handles > simple affine cases, and some client (a loop xform?). This should be > enough to get the transformation working on simple loops, and when the > client is tested and working there, you can use it to evaluate whether > the precision improvements are worthwhile. In fact, I've a client to test dependence analysis. It's a simple loop parallelization pass. Basically, it tries to divide the set of iterations into smaller sets and execute them in separate threads. The loop is parallelized if it has appropriate shape (i.e. is rotated, has canonical indvar), has known iteration count (at runtime) and doesn't carry any dependence. The new dependence analysis is used to check if there are no memory dependences. Register dependences are simpler to detect as they are introduced only by the loop header PHI nodes. Some register dependences can be eliminated (in case of scalar reduction, for example). This pass is almost finished with some minor FIXMEs for corner cases. If there is an interest I can share/contribute it soon. However, I wouldn't expect much from it and would rather treat it as a toy. After your advice, I am going to prepare (locally) custom tests for llvm-test testsuite. The number of loops not carrying memory dependences, or parallelizable ones can be a good measure of dependence analysis precision. Comparing output of parallelized programs to the original ones would, probably, help to check its correctness. > If you're looking for a simple client, I'd suggest something like loop > reversal. I think it would exercise dependence analysis in the same way as the above pass. Off course, it's still worthy to implement it. Unfortunately, I am not sure if I'll have time for it in the nearest future. Maybe someone else is interested?:) > Another transform that needs dependence analysis which would be even > more useful (but still very simple) is a "loops to memset/memcpy" > pass. This optimization would speed up the 'viterbi' program in the > test suite a *lot* for the various 'history' loops. Ok, but, unfortunately, as above... Wojtek From isanbard at gmail.com Wed Mar 19 19:39:45 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 19 Mar 2008 17:39:45 -0700 Subject: [LLVMdev] Merge Patch File In-Reply-To: <4B87EF4D-3C61-4CEA-8AFA-133D8DCF1AE6@apple.com> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> <200803192011.16462.baldrick@free.fr> <16e5fdf90803191310s385d3908hcfdad1df7e1ec95a@mail.gmail.com> <47E17F8A.9090504@gmail.com> <16e5fdf90803191455vdfdb493t895f836753418386@mail.gmail.com> <4B87EF4D-3C61-4CEA-8AFA-133D8DCF1AE6@apple.com> Message-ID: <16e5fdf90803191739v54ec5acdjcaf24c79da6585f2@mail.gmail.com> On Wed, Mar 19, 2008 at 4:33 PM, Mike Stump wrote: > On Mar 19, 2008, at 2:55 PM, Bill Wendling wrote: > > Thanks, Mike! I applied this to the tree. > > No, you applied something else to the tree! :-) I had a space before > the \ and after the ". The below should fix it. > > Doing diffs in .: > --- ./Makefile.in.~1~ 2008-03-19 15:45:54.000000000 -0700 > +++ ./Makefile.in 2008-03-19 16:30:07.000000000 -0700 > @@ -1689,7 +1689,7 @@ libgcc.mk: config.status Makefile mklibg > D128PBIT='$(D128PBIT)' \ > D128PBIT_FUNCS='$(D128PBIT_FUNCS)' \ > > APPLE_LOCAL='APPLE LOCAL libcc_kext' \ > - MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` $ > (APPLE_EXTRA_MULTI)"\ > + MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` $ > > (APPLE_EXTRA_MULTI)" \ > EXTRA_MULTILIB_PARTS='$(EXTRA_MULTILIB_PARTS)' \ > SHLIB_LINK='$(SHLIB_LINK)' \ > SHLIB_INSTALL='$(SHLIB_INSTALL)' \ > -------------- You're right. :-( Fixed. Thanks! -bw From mrs at apple.com Wed Mar 19 20:10:35 2008 From: mrs at apple.com (Mike Stump) Date: Wed, 19 Mar 2008 18:10:35 -0700 Subject: [LLVMdev] detab llvm Message-ID: <5455673C-BC1D-40D8-A6A1-6AC6B212EC5D@apple.com> Here is a patch to detabify llvm... -------------- next part -------------- A non-text attachment was scrubbed... Name: detab-1.patch Type: application/octet-stream Size: 11426 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080319/e55f923c/attachment.obj -------------- next part -------------- From sabre at nondot.org Wed Mar 19 20:13:43 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 19 Mar 2008 18:13:43 -0700 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: <47E1B15D.7040802@fastmail.fm> References: <47DD655F.2010600@fastmail.fm> <47DFEC12.7010502@fastmail.fm> <47E1B15D.7040802@fastmail.fm> Message-ID: On Mar 19, 2008, at 5:35 PM, Wojciech Matyjewicz wrote: > Chris Lattner wrote: >> I'm fine with starting simple and generalizing it out from there. >> I'd >> actually recommend against trying to implement a maximally precise >> dependence analyzer without a client. With no client, there is no >> way >> to test that you're getting correct results and whether the >> improvements in precision are actually useful. >> >> I'd suggest starting out with a simple checker, e.g. that handles >> simple affine cases, and some client (a loop xform?). This should be >> enough to get the transformation working on simple loops, and when >> the >> client is tested and working there, you can use it to evaluate >> whether >> the precision improvements are worthwhile. > > In fact, I've a client to test dependence analysis. It's a simple loop > parallelization pass. Basically, it tries to divide the set of > iterations into smaller sets and execute them in separate threads. The > loop is parallelized if it has appropriate shape (i.e. is rotated, has > canonical indvar), has known iteration count (at runtime) and doesn't > carry any dependence. The new dependence analysis is used to check if > there are no memory dependences. Register dependences are simpler to > detect as they are introduced only by the loop header PHI nodes. Some > register dependences can be eliminated (in case of scalar reduction, > for > example). This pass is almost finished with some minor FIXMEs for > corner > cases. If there is an interest I can share/contribute it soon. > However, > I wouldn't expect much from it and would rather treat it as a toy. > > After your advice, I am going to prepare (locally) custom tests for > llvm-test testsuite. The number of loops not carrying memory > dependences, or parallelizable ones can be a good measure of > dependence > analysis precision. Comparing output of parallelized programs to the > original ones would, probably, help to check its correctness. Makes sense, sounds fun! -Chris From sabre at nondot.org Wed Mar 19 20:23:30 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 19 Mar 2008 18:23:30 -0700 Subject: [LLVMdev] detab llvm In-Reply-To: <5455673C-BC1D-40D8-A6A1-6AC6B212EC5D@apple.com> References: <5455673C-BC1D-40D8-A6A1-6AC6B212EC5D@apple.com> Message-ID: <24FBFA68-6C4B-4D35-9086-D972840E032B@nondot.org> On Mar 19, 2008, at 6:10 PM, Mike Stump wrote: > Here is a patch to detabify llvm... Thanks, applied! http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080317/059946.html -Chris > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Wed Mar 19 21:24:23 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 19 Mar 2008 19:24:23 -0700 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <200803192109.27283.hs4233@mail.mn-solutions.de> References: <200803191319.m2JDJIC4045408@star.math.spbu.ru> <200803191449.43831.hs4233@mail.mn-solutions.de> <1205942357.6918.39.camel@kurier> <200803192109.27283.hs4233@mail.mn-solutions.de> Message-ID: <6AFBA9CD-956F-40F2-AA34-3F3C68E9EB2B@apple.com> Let's use llvm to build more games! :-) How about Marathon? http://source.bungie.org/ Evan On Mar 19, 2008, at 1:09 PM, Holger Schurig wrote: >> "Didn't work" means... what? Compilation failed? Program doesn't >> work? >> Either way: what mesages do you get? > > The graphical screen was just blank. darkplaces emits some log > messages as usual. But step by step... > > > Used LLVM-GCC > ------------- > The used llvm-gcc, when run with "llmv-gcc --version" shows "llvm- > gcc (GCC) 4.2.1 (Based on Apple Inc. build 5546) (LLVM build 47212)". > > So it has been a month ago when I did this test. > > I'm building llvm and llvm-gcc with the attached Makefile. There you > can see what I'm using for configure, but I guess that's nothing too > fancy. > > > Used Darkplaces > --------------- > I'm used darkplaces from SVN. Not sure what SVN revision it was a > month ago, but the same problem happens with the current one. To get > exactly the same engine source code that I currently have, do > > $ svn co -r8212 svn://svn.icculus.org/twilight/trunk/darkplaces > > Now apply the following attached "llvm.patch" to it. The patch > changes: > > * DO_CC to be "llvm-gcc --emit-llvm" > * DO_LD to be "llvm-ld -O2 -native -time-passes" > * CPUOPTIMIZATIONS=-march=athlon > * don't compile builddate.c on-the-fly at link time, because > llvm-ld can't do that > * don't set LDFLAGS_RELEASE to be the same as the compiler > optimization flags > > Now do "make cl-release" and you should get an executable named > "darkplaces-glx". > > > Used Nexuiz data files > ---------------------- > Finally you need the nexuiz data files. They are rather huge, a > whopping 363 MB. Get them like this from http://mesh.dl.sourceforge.net/sourceforge/nexuiz/nexuiz-24.zip > . Extract it, e.g. with "unzip -x nexuiz-24.zip" > > > Run the whole thing > ------------------- > I call the engine this way: > > $ ./darkplaces-glx \ > -window > -developer > -nexuiz > -basedir /usr/src/darkplaces/Nexuiz > > "-window" makes the program not use fullscreen, then you can still > see the log output. "-developer" turns additional messages and > warnings on. "-nexuiz" switches the engine into nexuiz mode, the > mode must suit the data files. And for "-basedir" add the full path > to the data files you downloaded and extract. > > Once started, the game will emit lot's of log output: > > Console initialized. > Nexuiz Linux 20:12:44 Mar 19 2008 > Trying to load library... "libz.so.1" - loaded. > ... > ========Initialized========= > Client using an automatically assigned port > Client opened a socket on address local:2 > Client opened a socket on address 0.0.0.0:56687 > > Besides the log output to stdout, it also opens a graphical window. > Then the engine should display a graphical, stylized "n" shortly > before it emits the "Initialized" line. And this is the first > difference between the llvm-gcc darkplaces-glx and the gcc-4.2 > darkplaces. Later it should show another uglier "n", then three > screens where you can use the mouse to select things. > > However, with the llvm-gcc version I just see a dark screen. And > here it hangs and eat's CPU time. I must admit that I was too lazy > to simply run the program under gdb's auspice and interrupt/ > backtrace it :-/ > > > > Used gcc-4.2 darkplace engine > ----------------------------- > To get a working engine from SVN, I keep the makefile/makefile.inc > in it's (almost) original form and just make sure that > > CC=gcc-4.2 > CPUOPTIMIZATIONS=-march=athlon > > Now I also compile with "make cl-release". The used compiler show > fors "gcc-4.2 --version" the text "gcc-4.2 (GCC) 4.2.3 (Debian > 4.2.3-2)". > > With this version, there is a graphical output, a stylized n, > displayed even before the line "========Initialized=========" > appears in the log. > > The gcc-compiled one emits some more messages to log: > > ========Initialized========= > Client using an automatically assigned port > Client opened a socket on address local:2 > Client opened a socket on address 0.0.0.0:56687 > Map farewell provides unknown info item author_email, ignored > Map farewell provides unknown info item author_www, ignored > Map warfare provides unknown info item author_email, ignored > Map warfare provides unknown info item author_www, ignored > Attempted division by zero in menu > Attempted division by zero in menu > Attempted division by zero in menu > Attempted division by zero in menu > ln: 5 iterations > Sending extended response requests... > Fake CD track 1 playing... > > At this time, I see the game menu and can select any options. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ami at amaret.net Wed Mar 19 22:08:37 2008 From: ami at amaret.net (Amichi Amar) Date: Wed, 19 Mar 2008 20:08:37 -0700 Subject: [LLVMdev] arm code generation Message-ID: <91C65606-8413-40F6-94B6-128DA100527E@amaret.net> Hello, I'm trying to do the following and encountering problems with the generated arm assembly code: I've got an application in two parts that i've compiled into llvm bitcode using: llvm-gcc -emit-llvm -c part1.c -o part1.bc llvm-gcc -emit-llvm -c part2.c -o part2.bc Then I link them together: llvm-ld part1.bc part2.bc -o combined.bc Now I use the ARM backend via llc to generate the assembly for my target processor from combined.bc: llc -march=arm -mcpu=arm7tdmi combined.bc The problem is when I run the generated file (combined.s) through an arm cross compiler for my target (arm-elf gcc toolchain) I get the following errors below. Has anybody encountered this before? Is there a way to do this? combined.s: Assembler messages: combined.s:216: rd and rm should be different in mul ... repeated a few times combined.s:969: rd and rm should be different in mla ... repeated a few times combined.s:1330: Error: unknown pseudo-op: `.cstring' combined.s:1335: Error: junk at end of line, first unrecognized character is `,' .. repeated many times combined.s:1366: Error: character following name is not '#' combined.s:1370: Error: unknown pseudo-op: `.indirect_symbol' combined.s:1375: Error: unknown pseudo-op: `.lazy_symbol_pointer' combined.s:1377: Error: unknown pseudo-op: `.indirect_symbol' .. repeated a few times combined.s:1393: Error: unknown pseudo-op: `.subsections_via_symbols' Thank you, -aa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080319/4ca23d47/attachment.html From vadve at cs.uiuc.edu Wed Mar 19 22:37:25 2008 From: vadve at cs.uiuc.edu (Vikram S. Adve) Date: Wed, 19 Mar 2008 22:37:25 -0500 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: <47DFEC12.7010502@fastmail.fm> References: <47DD655F.2010600@fastmail.fm> <47DFEC12.7010502@fastmail.fm> Message-ID: <9551-SnapperMsg8A45B0A8C4078C91@[75.204.155.245]> Wojtek, If you like, I can help guide this SoC project. I would also like to see if we can coordinate with Alex and Albert, who are doing the class project here. As a first comment, your 3 layers are a good organization but two comments: 1. Layer 1 shd also look at loop bounds and array bounds: those can be used to disprove some deps. 2. The interface will also need to compute direction and perhaps distance vectors. Those may or may not be easy to put in one of your layers (say, layer 3, where they belong). --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org ...... Original Message ....... On Tue, 18 Mar 2008 11:21:38 -0500 "Wojciech Matyjewicz" wrote: >Hi, > >> Cool! I think the most critical part of this is to get a good >> interface for dependence analysis. There are lots of interesting >> implementations that have various time/space tradeoffs. >> >> For example, it would be great if Omega was available as an option, >> even if the compiler didn't use it by default. This argues for making >> dependence analysis implementations pluggable like alias analyses. > >Yes, I also thought about it that way. I think we may look at the >dependence analysis in LLVM at three levels (from the lowest to the >highest one): > >1) Testing for dependence given two sequences of GEP indices assuming >that base pointers are the same. The indices could have a SCEV form or >even be preprocessed to something simpler (affine expressions for example). > >2) Testing for dependence of two instructions (that access memory). It >would use alias analysis to answer some queries immediately, or to check >whether two GEP base pointers equal. If the latter is the case, 1) would >be used to check for dependences. > >3) Complex queries (for example: does the given loop carry dependence?). >It would use 2) and summarize its results. > >Only the first level could be pluggable allowing to interchange or chain >core dependency testing techniques. I think there will be no use in >making pluggable the higher ones (please, correct me if I am wrong). >This approach would require to divide the analysis structure into two >parts, say; DependenceAnalysis and IndexingTester. > >That said, I must admit I haven't made it that way in my prototype. I >have it in mind, but I'm currently trying to keep things simple and just >to check whether the precision of my implementation is worth anything. > >> Sounds good. If you have the interface nailed down, it would be good >> to post what the query interface looks like. Vikram and others have a >> lot of experience with dependence analysis and know what sorts of >> queries various clients are interested in. They can help give >> feedback on the direction you're pursuing independent of the >> implementation. > >Ok. I'll post it when it crystallizes (what should happen soon). > >> I'd suggest looking at: >> >> Using the chains of recurrences algebra for data dependence testing >> and induction variable substitution >> MS Thesis, Johnie Birch >> >> Array Data Dependence Testing with the Chains of Recurrences Algebra >> http://citeseer.ist.psu.edu/vanengelen04array.html >> >> An empirical evaluation of chains of recurrences for array dependence >> testing >> http://doi.acm.org/10.1145/1152154.1152198 > >I've read the second one, but am not sure if it's easy to implement if >overflow and unknown signedness are taken into account. For now, I will >stick to the classical Banerjee test. If time allows I'll return to the >article. > >>>> From my experience I can say it's essential to use a precise alias >>> analysis as the base for the array dependence analysis. Fortunately, >>> using Data Structure or Andersen's AA for the whole program can >>> provide >>> really good results. >> >> Yep, but any particular dep analysis implementation should just >> require AliasAnalysis instead of a specific implementation. This lets >> the client (e.g. llvm-gcc) decide what passes to plug together. > >You're right. From the implementation point of view the choice of alias >analysis doesn't matter at all. > >Wojtek >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From nicholas at mxc.ca Wed Mar 19 22:38:29 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Wed, 19 Mar 2008 20:38:29 -0700 Subject: [LLVMdev] 2 experimental projects In-Reply-To: <8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com> References: <8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com> Message-ID: <47E1DC35.3080101@mxc.ca> Gabor Greif wrote: > 2) size reduction. > After some conversation with Chris I think we are ready for a > 16 -> 12 byte size reduction of the Use class. There are some > collateral improvements too. This project is in its conceptual phase. Could you explain this in detail? I want to be sure that you're considering both the case where Use is embedded in a User and where it isn't, such as when it's malloc'd. Nick From sabre at nondot.org Wed Mar 19 22:46:22 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 19 Mar 2008 20:46:22 -0700 Subject: [LLVMdev] arm code generation In-Reply-To: <91C65606-8413-40F6-94B6-128DA100527E@amaret.net> References: <91C65606-8413-40F6-94B6-128DA100527E@amaret.net> Message-ID: <188108C3-9615-499D-B911-76C8BD21EFBA@nondot.org> On Mar 19, 2008, at 8:08 PM, Amichi Amar wrote: > Hello, > > I'm trying to do the following and encountering problems with the > generated arm assembly code: > > I've got an application in two parts that i've compiled into llvm > bitcode using: > llvm-gcc -emit-llvm -c part1.c -o part1.bc > llvm-gcc -emit-llvm -c part2.c -o part2.bc > > Then I link them together: > llvm-ld part1.bc part2.bc -o combined.bc > > Now I use the ARM backend via llc to generate the assembly for my > target processor from combined.bc: > llc -march=arm -mcpu=arm7tdmi combined.bc > > The problem is when I run the generated file (combined.s) through an > arm cross compiler for my target (arm-elf gcc toolchain) I get the > following errors below. Has anybody encountered this before? Is > there a way to do this? > For this to work, you need to build llvm-gcc as a cross compiler to the appropriate arm target. -Chris From asl at math.spbu.ru Wed Mar 19 23:18:49 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 20 Mar 2008 07:18:49 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?YXJtIGNvZGUgZ2VuZXJhdGlvbg==?= Message-ID: <200803200418.m2K4In0R044006@star.math.spbu.ru> Hello, > combined.s:1370: Error: unknown pseudo-op: `.indirect_symbol' > combined.s:1375: Error: unknown pseudo-op: `.lazy_symbol_pointer' > combined.s:1377: Error: unknown pseudo-op: `.indirect_symbol' > .. repeated a few times > combined.s:1393: Error: unknown pseudo-op: `.subsections_via_symbols' Looks like you've generated assembler for darwin. Provide correct target triplet. -- WBR, Anton Korobeynikov From sabre at nondot.org Thu Mar 20 00:22:34 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 19 Mar 2008 22:22:34 -0700 Subject: [LLVMdev] GSoC Mips backend improvement In-Reply-To: <275e64e40803182246k7fbd0fd0v23b80d4936a1718@mail.gmail.com> References: <275e64e40803182246k7fbd0fd0v23b80d4936a1718@mail.gmail.com> Message-ID: On Mar 18, 2008, at 10:46 PM, Bruno Cardoso Lopes wrote: > Hi all, > > Last year i was mentored by Chris Lattner at GSoC and i created the > Mips back-end for LLVM. The back-end is still experimental (working > with simple benchmarks only) and this year i would like to improve it > as my GSoC proposal. Mips is still fairly used nowadays in a lot of > devices - routers, wireless cards, PSP, PS2 - and it would be great to > have a stable mips backend for LLVM. Hi Bruno! I think that improving the MIPS backend would be great. However, instead of "general improvements", I'd strongly suggest focusing your efforts on a specific use (e.g. PSP, PS2 or whatever else you have to play with). Based on that, I'd work on getting the rest of llvm-test to work, adding subtarget features (FP etc) needed for that specific CPU, then working on performance etc. I think this would be a much more useful and focused project than just "make the backend better". This will also hopefully allow us to say "llvm supports MIPS for the PSP" (or whatever), instead of just saying "we support some mips chips". What do you think? -Chris > > > General improvements : > > + Support little-endian Mips (mipsel) > + Improve instruction scheduling to better support non interlock > targets. > + Support more subtargets. > > Roadmap : > > 1) Define a list of benchmarks and get all working. > 2) Add float-point support. > 3) Repeat 1). > 4) Get llvm-gcc as cross-compiler fully working for Mips > 5) add Mips32 complete ISA > 6) choose one more subtarget to add support (Mips64/PSP/PS2). > Which one you would say is more important? Using llvm to > generate code for PSP would be very fun! > > Opinion and comments would be nice. > I'll leave the timeline proposal to the students application at > Google, > i just want some feedback for now! > > Cheers, > > -- > Bruno Cardoso Lopes ( now @ Cocos Island ) > http://www.brunocardoso.cc > > ++ The saddest aspect of life right now is that > science gathers knowledge faster than society > gathers wisdom + Isaac Asimov > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From echristo at apple.com Thu Mar 20 00:33:55 2008 From: echristo at apple.com (Eric Christopher) Date: Wed, 19 Mar 2008 22:33:55 -0700 Subject: [LLVMdev] GSoC Mips backend improvement In-Reply-To: References: <275e64e40803182246k7fbd0fd0v23b80d4936a1718@mail.gmail.com> Message-ID: <06891AB0-018C-48C3-8CB6-2533C53076E9@apple.com> > > I think this would be a much more useful and focused project than just > "make the backend better". This will also hopefully allow us to say > "llvm supports MIPS for the PSP" (or whatever), instead of just saying > "we support some mips chips". What do you think? FWIW I would highly suggest not going with the ps2 chip (emotion engine) as the next thing for the backend. It is more than a bit complicated. -eric From hs4233 at mail.mn-solutions.de Thu Mar 20 03:37:49 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Thu, 20 Mar 2008 09:37:49 +0100 Subject: [LLVMdev] 2 experimental projects In-Reply-To: <8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com> References: <8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com> Message-ID: <200803200937.49999.hs4233@mail.mn-solutions.de> > To drive forward these projects I prefer to work on branches. > So I apply for a branches/ggreif/... hierarchy in the > repository. I shall make > it easy to use "svn switch ..." for the relevant directories > for anybody who wants to test my work. I think that this might not generally be known, but you can use "git" as your SCM/DSCM and have lot's of local, fast and cheap branches ... and yet you can commit/update to/from an svn repository. E.g. you can do $ git svn clone -s -r101 svn://svn.foo.com/svn/proj This clones the names repository with revision 101 ("-r101") and a standard trunk/ branches/ tags/ layout ("-s"). $ cd proj $ git checkout -b test This creates a test branch and checks it out. This is very fast. Way faster than "svn switch" ... and you don't have to remember the different URLs but just use a simple name. Now edit. Then $ git commit -a to check your local change in. You can have as many local branches as you want and, once the branch is created, you can switch very fast between them using "git checkout master", "git checkout test". You can even stash away uncommitted stuff in a hurry (without committing it) with "git stash", see "git stash --help". Once you're done, send your commits back to svn: $ git svn dcommit Now the subversion users will have your commits as well. More about git-svn ------------------ http://tsunanet.blogspot.com/2007/07/learning-git-svn-in-5min.html http://utsl.gen.nz/talks/git-svn/intro.html http://www.kernel.org/pub/software/scm/git/docs/git-svn.html Git on MAC OS X --------------- http://www.dekorte.com/blog/blog.cgi?do=item&id=2539 From baldrick at free.fr Thu Mar 20 05:33:16 2008 From: baldrick at free.fr (Duncan Sands) Date: Thu, 20 Mar 2008 11:33:16 +0100 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <3DF6E7B9-6E5A-4A73-A379-8A1858F8A7E1@apple.com> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> <200803190939.36482.baldrick@free.fr> <3DF6E7B9-6E5A-4A73-A379-8A1858F8A7E1@apple.com> Message-ID: <200803201133.18563.baldrick@free.fr> Hi, > I agree this would be useful. However these two items require access > to lots of machine cycles. that's why I suggested using gcc's cfarm compile farm. > Do you anticipate lots of work, enough to > justify for a GSoC proposal, in existing test setup to accommodate > these two specific goals ? I think it would take at least two weeks to set this up. I don't know how long a SoC project is supposed to take, but presumably more than this. So this could be part of a larger testing framework. I must admit that setting this kind of thing up isn't very exciting or cutting edge, but it is important. My impression is that LLVM isn't tested half as hard as it needs to be. It would also be nice to have some kind of automated patch queue, to which patches can be submitted and which runs the testsuite with them applied. Ciao, Duncan. From gabor at mac.com Thu Mar 20 11:34:44 2008 From: gabor at mac.com (Gabor Greif) Date: Thu, 20 Mar 2008 17:34:44 +0100 Subject: [LLVMdev] 2 experimental projects References: 8471FD50-88C3-479F-83E5-5CE5BDC5CAD9@mac.com Message-ID: <47E29224.1070406@mac.com> > Could you explain this in detail? > > I want to be sure that you're considering both the case where Use is > embedded in a User and where it isn't, such as when it's malloc'd. > > Nick Yep. This is one of the design constraints. A design sketch should be up for review in a few days. Cheers, Gabor From bagel99 at gmail.com Thu Mar 20 11:39:57 2008 From: bagel99 at gmail.com (Bagel) Date: Thu, 20 Mar 2008 11:39:57 -0500 Subject: [LLVMdev] Use of flags in selection dags In-Reply-To: <200803191847.53408.baldrick@free.fr> References: <47E1484D.7030600@gmail.com> <200803191847.53408.baldrick@free.fr> Message-ID: <47E2935D.6030109@gmail.com> Duncan Sands wrote: >> Can someone tell me, or point me to documentation, that explains the use >> of "flags" in the selection DAG? I figured out that, if one is >> present, it must be the last operand. But when are "flags" used and why? >> > > Please give details of the context, such as the kind of node you are looking at. > > Thanks, > > Duncan. > I'm looking at this in general as one would when writing patterns for a new machine. It appears that flags are used in patterns that use or set condition codes. Is this because the condition code register is not modelled or is it more that the dags can't handle two outputs. I just want to know what the rules are on when and how to use "flags". Thanks, Bagel From edwintorok at gmail.com Thu Mar 20 11:56:11 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Thu, 20 Mar 2008 18:56:11 +0200 Subject: [LLVMdev] Merge Patch File In-Reply-To: <16e5fdf90803191455vdfdb493t895f836753418386@mail.gmail.com> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> <200803192011.16462.baldrick@free.fr> <16e5fdf90803191310s385d3908hcfdad1df7e1ec95a@mail.gmail.com> <47E17F8A.9090504@gmail.com> <16e5fdf90803191455vdfdb493t895f836753418386@mail.gmail.com> Message-ID: <47E2972B.9060702@gmail.com> Bill Wendling wrote: > Thanks, Mike! I applied this to the tree. T?r?k, please give it a try. I have successfully bootstrapped llvm-gcc4.2 r48587 on 32-bit Linux. Thanks, --Edwin From baldrick at free.fr Thu Mar 20 12:05:45 2008 From: baldrick at free.fr (Duncan Sands) Date: Thu, 20 Mar 2008 18:05:45 +0100 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <3DF6E7B9-6E5A-4A73-A379-8A1858F8A7E1@apple.com> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> <200803190939.36482.baldrick@free.fr> <3DF6E7B9-6E5A-4A73-A379-8A1858F8A7E1@apple.com> Message-ID: <200803201805.47745.baldrick@free.fr> While on the subject of the testsuite, some random thoughts: - show how test results changed from one week and one month ago, and compared to the last release, rather than just comparing with the previous run as now. Good for spotting trends. - fix the testsuite so that buildlogs are really available: I occasionally see that a nightly tester failed the build, and in the message it gives a url where you can get the build log. Only the logs aren't there... Ciao, Duncan. From dalej at apple.com Thu Mar 20 12:08:39 2008 From: dalej at apple.com (Dale Johannesen) Date: Thu, 20 Mar 2008 10:08:39 -0700 Subject: [LLVMdev] testsuite problems after merge Message-ID: I'm seeing ~100 new failures in the gcc testsuite due to the test file being doubled or tripled, as below. This appears to affect only files that were newly imported from gcc-4.2 in the recent merge. Does anybody have an idea for how to mechanize fixing these (I doubt you can count on the APPLE LOCAL comment being there)? If there's no better way than slogging through I'll help. And of course we should figure out why and prevent it from happening again.... now what? more $ld/gcc/llvm-gcc-4.2/gcc/testsuite/gcc.apple/5597292.c /* APPLE LOCAL file 5597292 */ /* { dg-do compile } */ /* { dg-options "-static -O0 -gstabs+" } */ void * foo(unsigned int size) { union { char _m[size]; } *mem; } /* APPLE LOCAL file 5597292 */ /* { dg-do compile } */ /* { dg-options "-static -O0 -gstabs+" } */ void * foo(unsigned int size) { union { char _m[size]; } *mem; } /* APPLE LOCAL file 5597292 */ /* { dg-do compile } */ /* { dg-options "-static -O0 -gstabs+" } */ void * foo(unsigned int size) { union { char _m[size]; } *mem; } From mrs at apple.com Thu Mar 20 12:30:21 2008 From: mrs at apple.com (Mike Stump) Date: Thu, 20 Mar 2008 10:30:21 -0700 Subject: [LLVMdev] Merge Patch File In-Reply-To: <47E2972B.9060702@gmail.com> References: <16e5fdf90803181511m76d84378n8683050e664ec04e@mail.gmail.com> <200803191351.05786.baldrick@free.fr> <16e5fdf90803191120x2affac8cl3f1a54f1d29931f3@mail.gmail.com> <200803192011.16462.baldrick@free.fr> <16e5fdf90803191310s385d3908hcfdad1df7e1ec95a@mail.gmail.com> <47E17F8A.9090504@gmail.com> <16e5fdf90803191455vdfdb493t895f836753418386@mail.gmail.com> <47E2972B.9060702@gmail.com> Message-ID: On Mar 20, 2008, at 9:56 AM, T?r?k Edwin wrote: > Bill Wendling wrote: >> Thanks, Mike! I applied this to the tree. T?r?k, please give it a >> try. > > I have successfully bootstrapped llvm-gcc4.2 r48587 on 32-bit Linux. Wonderful, thanks for the report. From mrs at apple.com Thu Mar 20 12:39:23 2008 From: mrs at apple.com (Mike Stump) Date: Thu, 20 Mar 2008 10:39:23 -0700 Subject: [LLVMdev] testsuite problems after merge In-Reply-To: References: Message-ID: <7D85EF99-D0F0-46BC-93BF-E1C6AED14A1A@apple.com> On Mar 20, 2008, at 10:08 AM, Dale Johannesen wrote: > I'm seeing ~100 new failures in the gcc testsuite due to the test > file being doubled or tripled, as below. This is due to an incorrect use of the tools. Bill, I'd be happy to help out, but, you'd need to say how you did the merge. I suspect you may have just grabbed a patch and applied it three times in a row. Roughly, what you need to do is to have a import branch that is unmodified upstream, and then you just merge the last version of that branch to the current version of that branch using svn merge onto your llvm branch. diff -r upstream current and then look for APPLE LOCAL markers that have been added, there should be none. That's the best auditing method I can come up with in seconds. > (I doubt you can count on the APPLE LOCAL comment being there)? Yes, you can count on them being there. From wendling at apple.com Thu Mar 20 13:10:21 2008 From: wendling at apple.com (Bill Wendling) Date: Thu, 20 Mar 2008 11:10:21 -0700 Subject: [LLVMdev] testsuite problems after merge In-Reply-To: References: Message-ID: <6912EC9C-C968-42A4-8D2B-6F47F5F4CC9B@apple.com> On Mar 20, 2008, at 10:08 AM, Dale Johannesen wrote: > I'm seeing ~100 new failures in the gcc testsuite due to the test > file being doubled or tripled, as below. This appears to affect > only files that were newly imported from gcc-4.2 in the recent > merge. Does anybody have an idea for how to mechanize fixing these > (I doubt you can count on the APPLE LOCAL comment being there)? If > there's no better way than slogging through I'll help. And of > course we should figure out why and prevent it from happening > again.... I'll help you track these down. Give me a list of the ones that are failing and I can start slogging through them. It should be easy to fix, at least. I don't know what happened. The method I used was "svn diff" followed by "patch -p0". *shrugs* We should take Mike's suggestion next time. -bw From evan.cheng at apple.com Thu Mar 20 14:58:50 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 20 Mar 2008 12:58:50 -0700 Subject: [LLVMdev] arm code generation In-Reply-To: <91C65606-8413-40F6-94B6-128DA100527E@amaret.net> References: <91C65606-8413-40F6-94B6-128DA100527E@amaret.net> Message-ID: On Mar 19, 2008, at 8:08 PM, Amichi Amar wrote: > Hello, > > I'm trying to do the following and encountering problems with the > generated arm assembly code: > > I've got an application in two parts that i've compiled into llvm > bitcode using: > llvm-gcc -emit-llvm -c part1.c -o part1.bc > llvm-gcc -emit-llvm -c part2.c -o part2.bc > > Then I link them together: > llvm-ld part1.bc part2.bc -o combined.bc > > Now I use the ARM backend via llc to generate the assembly for my > target processor from combined.bc: > llc -march=arm -mcpu=arm7tdmi combined.bc > > The problem is when I run the generated file (combined.s) through an > arm cross compiler for my target (arm-elf gcc toolchain) I get the > following errors below. Has anybody encountered this before? Is > there a way to do this? > > > combined.s: Assembler messages: > combined.s:216: rd and rm should be different in mul > ... repeated a few times > combined.s:969: rd and rm should be different in mla > ... repeated a few times Your assembler is probably outdated. This restriction is not present in newish ARM incarnations. Evan > combined.s:1330: Error: unknown pseudo-op: `.cstring' > combined.s:1335: Error: junk at end of line, first unrecognized > character is `,' > .. repeated many times > combined.s:1366: Error: character following name is not '#' > combined.s:1370: Error: unknown pseudo-op: `.indirect_symbol' > combined.s:1375: Error: unknown pseudo-op: `.lazy_symbol_pointer' > combined.s:1377: Error: unknown pseudo-op: `.indirect_symbol' > .. repeated a few times > combined.s:1393: Error: unknown pseudo-op: `.subsections_via_symbols' > > > Thank you, > > -aa > > > _______________________________________________ > 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/20080320/3e29b839/attachment.html From mrs at apple.com Thu Mar 20 15:34:01 2008 From: mrs at apple.com (Mike Stump) Date: Thu, 20 Mar 2008 13:34:01 -0700 Subject: [LLVMdev] testsuite problems after merge In-Reply-To: <6912EC9C-C968-42A4-8D2B-6F47F5F4CC9B@apple.com> References: <6912EC9C-C968-42A4-8D2B-6F47F5F4CC9B@apple.com> Message-ID: <0A924BDB-F809-4FC5-A57F-45051023F515@apple.com> On Mar 20, 2008, at 11:10 AM, Bill Wendling wrote: > The method I used was "svn diff" If you did diff -r1 -r2, then diff -r2 -r3, then diff -r3 -r4, it should have worked. From akyrtzi at gmail.com Thu Mar 20 15:52:02 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Thu, 20 Mar 2008 13:52:02 -0700 Subject: [LLVMdev] Proposal for GSoC project for clang front end In-Reply-To: References: <47E11F1F.4070806@gmail.com> Message-ID: <47E2CE72.7060707@gmail.com> Thanks for your feedback Chris, Chris Lattner wrote: > If I were going to pick, I would suggest focusing on getting simple > methods implemented, along with instance variables, etc through > -fsyntax-only. This should be a reasonable amount of work for a summer. > Something like this should work for example: > > class foo { > int X; > typedef float Z; > int test(Z a) { return a+X; } > int test2(q r); > tyepdef float q; > }; > > int foo::test2(q r) { > return X+r; > } > > No overloading, not templates, but handling the basic "class issues". > Static methods would be a bonus :) Ok, adding basic class support sounds great. It will include: 1) declaring methods, nested classes, enumerations and typedefs. (nested types will be accessible only by class methods, unless class scope resolution is implemented; see below) 2) member access control ("public:" etc) 3) calling instance methods. > int foo::test2(q r) { > return X+r; > } This is actually quite tricky, because clang currently assumes that a declaration can be "found" only by using an identifier (support for '::' in "foo::test2" needed), and for name lookup it assumes that the declaration is accessible at the current scope or at an enclosing scope of the current one (support for resolving X in "return X+r;" needed). So either a kind of "hack" would be employed to get correct parsing for this situation only, or "proper" C++ name lookup would be developed to also accommodate access to class nested types and static members. Personally I'd prefer the latter, but I'd like to hear your opinion whether [1) - 3)] plus "C++ name lookup" is a reasonable amount of work for the summer or something should be dropped or simplified. -Argiris From overminddl1 at gmail.com Thu Mar 20 16:38:03 2008 From: overminddl1 at gmail.com (OvermindDL1) Date: Thu, 20 Mar 2008 15:38:03 -0600 Subject: [LLVMdev] LLVM Python binding In-Reply-To: <47E17AA9.5080309@gmail.com> References: <47E17AA9.5080309@gmail.com> Message-ID: <3f49a9f40803201438l2e0b48c2hb89c04703f82f2f6@mail.gmail.com> I'd might think about that, I have created quite a few Python bindings and, oddly enough, do enjoy it, probably just because of how easy boost::python makes it (I have always manually done it directly using that, but because of the sheer size of LLVM I may use a code generator to generate the basics, and yes I know how to manually create python C modules without any binder, but boost::python drastically cuts down the time for all the glue code). What would you be looking at, the same C++ interface for generating the bytecode (the Module, Value, etc... and so forth) in addition to what other functions would you want? I have only written a LLVM generator for a toy language so this may be beneficial for both you (in getting Python bindings) and me (in learning the full interface and what is really required). Bindings are easy to extend and (thanks to boost::python if I used it) the interface stays very type-safe for any C-style bindings. The python setup system makes it easy to compile and install in the python distribution on any OS so it should literally be as easy as just downloading it and running setup.py in its root directory (or easy_install if added to the python cheeseshop). If you really wanted it to be done manually without external libraries (and the parts of boost I use can be included in the distribution, so that would really be a non-issue unless there is some aversion to it) then it would take longer then the time I have free, whereas with boost::python I could probably get something working with the main interfaces in a couple of days, and depending on the size of the LLVM interface that would be wanted, a month or so, with more time to make test-cases to make sure it works correctly. Any thoughts on it being made into a GSoC project, or should I do it on my own (much less incentive to get it done quickly as I have other paying things to deal with, I would still get it done if started, just take longer to get fully finished)? Also, have you looked at PyPy? It is no where near finished (or honestly, anywhere near usable on the front-end), but it has an LLVM back-end, might work well enough for now depending on what you are doing. On Wed, Mar 19, 2008 at 2:42 PM, Nadav Rotem wrote: > Hello, > > > I am developing an application which is Python based and uses LLVM. I > use LLVM by generating textual bitcode files and feeding them to my > plug-in. I wish LLVM had Python binding. > > > I would love to see Python binding as one of the GSoC projects so > someone from the community can pick it up. > > > Cheers, > > Nadav > > _______________________________________________ > 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/20080320/b56c0194/attachment.html From jo at durchholz.org Thu Mar 20 17:00:36 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 20 Mar 2008 23:00:36 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc Message-ID: <1206050436.7545.40.camel@kurier> Hi all, I just forgot to ./configure with CC=gcc-4.2 CXX=g++-4.2, getting the (broken-for-LLVM) gcc-4.1 as a compiler. The error message that I got was this: make[1]: Entering directory `/home/jo/llvm-wrk/lib/VMCore' make[1]: *** No rule to make target `/home/jo/llvm-wrk/Release/bin/tblgen', needed by `/home/jo/llvm-wrk/lib/VMCore/Release/Intrinsics.gen.tmp'. Stop. make[1]: Leaving directory `/home/jo/llvm-wrk/lib/VMCore' make: *** [install] Error 1 It took me a while to figure out what went wrong. I guess I'm not the only one to stumble upon this problem. Would it be a good idea to make ./configure check whether there's an incompatible tool configured, and carp if it finds one? Regards, Jo From wmatyjewicz at fastmail.fm Thu Mar 20 17:08:09 2008 From: wmatyjewicz at fastmail.fm (Wojciech Matyjewicz) Date: Thu, 20 Mar 2008 23:08:09 +0100 Subject: [LLVMdev] Array Dependence Analysis In-Reply-To: <9551-SnapperMsg8A45B0A8C4078C91@[75.204.155.245]> References: <47DD655F.2010600@fastmail.fm> <47DFEC12.7010502@fastmail.fm> <9551-SnapperMsg8A45B0A8C4078C91@[75.204.155.245]> Message-ID: <47E2E049.2080505@fastmail.fm> Vikram, > If you like, I can help guide this SoC project. Unfortunately, I am not eligible for the SoC programme as I will be graduating in April. In fact, data dependence analysis (in basic version at least) is one of my master thesis' parts. I should get the basic version working in a few days. Internally, it is more or less the algorithm described in the textbook by Allen and Kennedy, but externally it has very limited interface. I was planning to improve it after the graduation, if my time allows. But now, as there is more people to work on the issue it may be more interesting to develop something better. > I would also like to see if we can coordinate with Alex and Albert, who are > doing the class project here. Although I'm willing to help, I suppose Alex and Albert would feel more comfortable if the schedule of their course project was independent of a guy living on another hemisphere:) My intention was to signalize that some efforts towards implementing dependence analysis have already been made. I will try to post my first prototype in the beginning of April. I'll also try to write down some thoughts about the pass interface, its internal structure and, also, problems I've encountered during my "research". Some of the problems aren't directly connected to dependence analysis but block it from being precise. For example, in codes coming from translating Fortran programs, arrays that are declared in COMMON blocks and passed as function arguments become a problem for alias analysis. Often a conservative "there is a dependence" answer must be returned without, even, checking indices. But returning to the main subject, maybe some parts of my prototype and some thoughts would be useful for the "next generation" implementation... As for my role, I'm ready to share the experience I've gained while implementing the prototype. Also, if there is a self-contained part that can be written independently I may try to do it. I'd be happy to take advantage of your guidance then. > As a first comment, your 3 layers are a good organization but two comments: > > 1. Layer 1 shd also look at loop bounds and array bounds: those can be used > to disprove some deps. Currently, I do use loop bounds to disprove deps. However I don't take into account trapezoidal or triangular loops. > 2. The interface will also need to compute direction and perhaps distance > vectors. Those may or may not be easy to put in one of your layers (say, > layer 3, where they belong). Yes. "The layers" is only a concept describing which other analysis queries the given query depends on. Internally, the analysis can be one class so propagating direction vector from the lowest layer (where they are computed) to the highest (where they are given to the client) is not a problem. Wojtek From echristo at apple.com Thu Mar 20 17:14:14 2008 From: echristo at apple.com (Eric Christopher) Date: Thu, 20 Mar 2008 15:14:14 -0700 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <1206050436.7545.40.camel@kurier> References: <1206050436.7545.40.camel@kurier> Message-ID: <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> On Mar 20, 2008, at 3:00 PM, Joachim Durchholz wrote: > Hi all, > > I just forgot to ./configure with CC=gcc-4.2 CXX=g++-4.2, getting the > (broken-for-LLVM) gcc-4.1 as a compiler. > The error message that I got was this: > make[1]: Entering directory `/home/jo/llvm-wrk/lib/VMCore' > make[1]: *** No rule to make target > `/home/jo/llvm-wrk/Release/bin/tblgen', needed by > `/home/jo/llvm-wrk/lib/VMCore/Release/Intrinsics.gen.tmp'. Stop. > make[1]: Leaving directory `/home/jo/llvm-wrk/lib/VMCore' > make: *** [install] Error 1 > > It took me a while to figure out what went wrong. > > I guess I'm not the only one to stumble upon this problem. > > Would it be a good idea to make ./configure check whether there's an > incompatible tool configured, and carp if it finds one? Probably be a good idea. It's reasonably easy to check major/minor versions. -eric From ssen at apple.com Thu Mar 20 17:27:50 2008 From: ssen at apple.com (Shantonu Sen) Date: Thu, 20 Mar 2008 15:27:50 -0700 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> Message-ID: llvm's ./configure already does that for gcc < 3. What are valid versions? Exactly 4.0 and 4.2? 4.0 and >=4.2? dnl Verify that GCC is version 3.0 or higher if test "$GCC" = "yes" then AC_COMPILE_IFELSE([[#if !defined(__GNUC__) || __GNUC__ < 3 #error Unsupported GCC version #endif ]], [], [AC_MSG_ERROR([gcc 3.x required, but you have a lower version])]) fi Shantonu Sen ssen at apple.com Sent from my Mac Pro On Mar 20, 2008, at 3:14 PM, Eric Christopher wrote: > > On Mar 20, 2008, at 3:00 PM, Joachim Durchholz wrote: >> Hi all, >> >> I just forgot to ./configure with CC=gcc-4.2 CXX=g++-4.2, getting the >> (broken-for-LLVM) gcc-4.1 as a compiler. >> The error message that I got was this: >> make[1]: Entering directory `/home/jo/llvm-wrk/lib/VMCore' >> make[1]: *** No rule to make target >> `/home/jo/llvm-wrk/Release/bin/tblgen', needed by >> `/home/jo/llvm-wrk/lib/VMCore/Release/Intrinsics.gen.tmp'. Stop. >> make[1]: Leaving directory `/home/jo/llvm-wrk/lib/VMCore' >> make: *** [install] Error 1 >> >> It took me a while to figure out what went wrong. >> >> I guess I'm not the only one to stumble upon this problem. >> >> Would it be a good idea to make ./configure check whether there's an >> incompatible tool configured, and carp if it finds one? > > Probably be a good idea. It's reasonably easy to check major/minor > versions. > > -eric > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From jo at durchholz.org Thu Mar 20 17:43:38 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 20 Mar 2008 23:43:38 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> Message-ID: <1206053018.7545.48.camel@kurier> Am Donnerstag, den 20.03.2008, 15:27 -0700 schrieb Shantonu Sen: > llvm's ./configure already does that for gcc < 3. > > What are valid versions? Exactly 4.0 and 4.2? 4.0 and >=4.2? There's a list at http://llvm.org/docs/GettingStarted.html#brokengcc so there is a reasonable basis. The list isn't comprehensive, of course, and will likely grow in the future. OTOH extending it as new problems come up should be easy to do. > dnl Verify that GCC is version 3.0 or higher > if test "$GCC" = "yes" > then > AC_COMPILE_IFELSE([[#if !defined(__GNUC__) || __GNUC__ < 3 > #error Unsupported GCC version > #endif > ]], [], [AC_MSG_ERROR([gcc 3.x required, but you have a lower > version])]) > fi It might be simpler (and faster) to check the output of gcc -v. Extending the list to other tools would be easier, too. Anybody able to give model code for that? Regards, Jo From tonic at nondot.org Thu Mar 20 17:44:33 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Thu, 20 Mar 2008 15:44:33 -0700 (PDT) Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> Message-ID: >> I just forgot to ./configure with CC=gcc-4.2 CXX=g++-4.2, getting the >> (broken-for-LLVM) gcc-4.1 as a compiler. >> The error message that I got was this: >> make[1]: Entering directory `/home/jo/llvm-wrk/lib/VMCore' >> make[1]: *** No rule to make target >> `/home/jo/llvm-wrk/Release/bin/tblgen', needed by >> `/home/jo/llvm-wrk/lib/VMCore/Release/Intrinsics.gen.tmp'. Stop. >> make[1]: Leaving directory `/home/jo/llvm-wrk/lib/VMCore' >> make: *** [install] Error 1 >> >> It took me a while to figure out what went wrong. >> >> I guess I'm not the only one to stumble upon this problem. >> >> Would it be a good idea to make ./configure check whether there's an >> incompatible tool configured, and carp if it finds one? > > Probably be a good idea. It's reasonably easy to check major/minor > versions. Its not just a matter of checking major/minor versions. It also depends on the target and in some cases the OS. http://llvm.org/docs/GettingStarted.html#brokengcc So for example, GCC 3.3.3 on Suse or GCC 3.4.0 on linux/x86 (32-bit) has issues. Is it easy to check these kinds of things? Do we even want to? I guess it could be done for things like 4.1.1 or a couple of others on the list. -Tanya From wendling at apple.com Thu Mar 20 18:07:03 2008 From: wendling at apple.com (Bill Wendling) Date: Thu, 20 Mar 2008 16:07:03 -0700 Subject: [LLVMdev] testsuite problems after merge In-Reply-To: References: Message-ID: <7004FB92-2FAB-420A-9072-0BF1676D6853@apple.com> These should be fixed now. Sorry for the mess. -bw On Mar 20, 2008, at 10:08 AM, Dale Johannesen wrote: > I'm seeing ~100 new failures in the gcc testsuite due to the test > file being doubled or tripled, as below. This appears to affect > only files that were newly imported from gcc-4.2 in the recent > merge. Does anybody have an idea for how to mechanize fixing these > (I doubt you can count on the APPLE LOCAL comment being there)? If > there's no better way than slogging through I'll help. And of > course we should figure out why and prevent it from happening > again.... > > now what? more $ld/gcc/llvm-gcc-4.2/gcc/testsuite/gcc.apple/5597292.c > /* APPLE LOCAL file 5597292 */ > /* { dg-do compile } */ > /* { dg-options "-static -O0 -gstabs+" } */ > void * foo(unsigned int size) > { > union { > char _m[size]; > } *mem; > } > /* APPLE LOCAL file 5597292 */ > /* { dg-do compile } */ > /* { dg-options "-static -O0 -gstabs+" } */ > void * foo(unsigned int size) > { > union { > char _m[size]; > } *mem; > } > /* APPLE LOCAL file 5597292 */ > /* { dg-do compile } */ > /* { dg-options "-static -O0 -gstabs+" } */ > void * foo(unsigned int size) > { > union { > char _m[size]; > } *mem; > } > From jo at durchholz.org Thu Mar 20 18:08:51 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 21 Mar 2008 00:08:51 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> Message-ID: <1206054531.7545.61.camel@kurier> Am Donnerstag, den 20.03.2008, 15:44 -0700 schrieb Tanya M. Lattner: > Its not just a matter of checking major/minor versions. It also depends on > the target and in some cases the OS. > http://llvm.org/docs/GettingStarted.html#brokengcc > > So for example, GCC 3.3.3 on Suse or GCC 3.4.0 on linux/x86 > (32-bit) has issues. Is it easy to check these kinds of things? uname identifies arch. /etc/lsb-release identifies Linux distribution; I'm not sure how to identify Apple and Cygwin. $prog --version gives a version string for all $progs that follow GNU conventions (most do). > Do we even want to? Dunno, that's why I'm asking. The one thing that counts for doing it is that ./configure is exactly for dealing with all those little annoyances that different OSes, tool versions etc. bring. The thing that counts against them is that keeping the list of broken-for-llvm tool versions is a neverending task - but then that's normal for what ./configure does, so does this really count? > I guess it could be done for things like 4.1.1 or a couple of others on > the list. For those cases where the script cannot fully determine the conditions, it might be helpful to emit just a warning. Describe what the issue is, how any problems would manifest, and let the user go ahead in such a case. Just my 2c. Regards, Jo From dalej at apple.com Thu Mar 20 18:13:01 2008 From: dalej at apple.com (Dale Johannesen) Date: Thu, 20 Mar 2008 16:13:01 -0700 Subject: [LLVMdev] testsuite problems after merge In-Reply-To: <7004FB92-2FAB-420A-9072-0BF1676D6853@apple.com> References: <7004FB92-2FAB-420A-9072-0BF1676D6853@apple.com> Message-ID: <54914061-52F0-4F95-B392-A47FF1C80F6B@apple.com> On Mar 20, 2008, at 4:07 PM, Bill Wendling wrote: > These should be fixed now. Sorry for the mess. > > -bw Thanks for fixing it all. I'll try again overnight and let you know if you missed any:) From dconnors at Colorado.EDU Thu Mar 20 17:15:32 2008 From: dconnors at Colorado.EDU (Dan Connors) Date: Thu, 20 Mar 2008 16:15:32 -0600 (MDT) Subject: [LLVMdev] LLVM error: "Bitcode stream should be a multiple of 4 bytes in length" (fwd) Message-ID: Do you know why I might be getting this error? [dconnors at eces-shell Hello]$ llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc [dconnors at eces-shell Hello]$ llc hello.bc -o hello.s llc: bitcode didn't read correctly. Reason: Bitcode stream should be a multiple of 4 bytes in length I am using: LLVM-GCC 4.2 Front End Binaries for Red Hat Enterprise Linux4/x86 LLVM source code 2.2 I've looked everywhere for possible error explanations, and only find code logs having the line regarding bitcode. All of the tools lli, etc also report the problem of 4 bytes in length. thanks! Dan From sabre at nondot.org Thu Mar 20 22:49:35 2008 From: sabre at nondot.org (Chris Lattner) Date: Thu, 20 Mar 2008 20:49:35 -0700 Subject: [LLVMdev] Proposal for GSoC project for clang front end In-Reply-To: <47E2CE72.7060707@gmail.com> References: <47E11F1F.4070806@gmail.com> <47E2CE72.7060707@gmail.com> Message-ID: <38832715-C4AE-4220-804A-FD283A68CDFF@nondot.org> >> No overloading, not templates, but handling the basic "class issues". >> Static methods would be a bonus :) > Ok, adding basic class support sounds great. It will include: > > 1) declaring methods, nested classes, enumerations and typedefs. > (nested > types will be accessible > only by class methods, unless class scope resolution is > implemented; > see below) > 2) member access control ("public:" etc) Note that 'test' exercises a cute detail of C++: inline methods cannot be parsed until the whole class is processed. You need to analyze the q typedef before you can parse the body of test. This should be straight-forward to handle in clang, please discuss on cfe-dev when it becomes time. > 3) calling instance methods. >> int foo::test2(q r) { >> return X+r; >> } > This is actually quite tricky, because clang currently assumes that a > declaration can be "found" > only by using an identifier (support for '::' in "foo::test2" needed), > and for name lookup it > assumes that the declaration is accessible at the current scope or > at an > enclosing scope of the > current one (support for resolving X in "return X+r;" needed). It's not that bad, we already handle it for instance variables in ObjC. > So either a kind of "hack" would be employed to get correct parsing > for > this situation only, > or "proper" C++ name lookup would be developed to also accommodate > access to class nested types > and static members. Personally I'd prefer the latter, but I'd like to > hear your opinion whether > [1) - 3)] plus "C++ name lookup" is a reasonable amount of work for > the > summer or something > should be dropped or simplified. I'd stick with the minimal amount of name lookup to get classes themselves working. instance variables are included, but not overloading or anything tricky. -Chris From dom.hamon at gmail.com Fri Mar 21 02:17:06 2008 From: dom.hamon at gmail.com (Dominic Hamon) Date: Fri, 21 Mar 2008 15:17:06 +0800 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <1206054531.7545.61.camel@kurier> References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> <1206054531.7545.61.camel@kurier> Message-ID: <47E360F2.4020605@gmail.com> Joachim Durchholz wrote: > Am Donnerstag, den 20.03.2008, 15:44 -0700 schrieb Tanya M. Lattner: > >> Its not just a matter of checking major/minor versions. It also depends on >> the target and in some cases the OS. >> http://llvm.org/docs/GettingStarted.html#brokengcc >> >> So for example, GCC 3.3.3 on Suse or GCC 3.4.0 on linux/x86 >> (32-bit) has issues. Is it easy to check these kinds of things? >> > > uname identifies arch. > > /etc/lsb-release identifies Linux distribution; I'm not sure how to > identify Apple and Cygwin. > > uname on Apple (at least in a Terminal) returns 'Darwin'. dom From baldrick at free.fr Fri Mar 21 03:16:21 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 21 Mar 2008 09:16:21 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <1206053018.7545.48.camel@kurier> References: <1206050436.7545.40.camel@kurier> <1206053018.7545.48.camel@kurier> Message-ID: <200803210916.22202.baldrick@free.fr> Hi, > There's a list at http://llvm.org/docs/GettingStarted.html#brokengcc so > there is a reasonable basis. > The list isn't comprehensive, of course, and will likely grow in the > future. OTOH extending it as new problems come up should be easy to do. that list is not very reliable. For example it says that gcc-4.1 is problematic, but I never had any problems with it on ubuntu linux. So it's probably best to warn if a dubious tool is seen, rather than erroring out. Ciao, Duncan. From baldrick at free.fr Fri Mar 21 03:17:43 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 21 Mar 2008 09:17:43 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> Message-ID: <200803210917.44039.baldrick@free.fr> > I guess it could be done for things like 4.1.1 or a couple of others on > the list. This gcc version always worked fine for me on ubuntu linux (though it might have been 4.1.2, I don't recall). Ciao, Duncan. From baldrick at free.fr Fri Mar 21 03:23:12 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 21 Mar 2008 09:23:12 +0100 Subject: [LLVMdev] LLVM error: "Bitcode stream should be a multiple of 4 bytes in length" (fwd) In-Reply-To: References: Message-ID: <200803210923.12779.baldrick@free.fr> Hi, > Do you know why I might be getting this error? > > > [dconnors at eces-shell Hello]$ llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc > [dconnors at eces-shell Hello]$ llc hello.bc -o hello.s > llc: bitcode didn't read correctly. > Reason: Bitcode stream should be a multiple of 4 bytes in length this means that hello.bc doesn't contain bitcode, though I suppose it might contain an out-of-date version of bitcode. My guess is that you have an old llvm-gcc or llc floating around in your path, which is getting used accidentally. You might want to look inside hello.bc, and see what the first 10 characters or so look like. Also, try doing "file hello.bc". If it is bitcode you should get "hello.bc: data". Ciao, Duncan. PS: I tried your command lines here and it worked fine (ubuntu x86-32). From jo at durchholz.org Fri Mar 21 05:54:01 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 21 Mar 2008 11:54:01 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <47E360F2.4020605@gmail.com> References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> <1206054531.7545.61.camel@kurier> <47E360F2.4020605@gmail.com> Message-ID: <1206096841.7905.9.camel@kurier> Am Freitag, den 21.03.2008, 15:17 +0800 schrieb Dominic Hamon: > Joachim Durchholz wrote: > > Am Donnerstag, den 20.03.2008, 15:44 -0700 schrieb Tanya M. Lattner: > > > >> Its not just a matter of checking major/minor versions. It also depends on > >> the target and in some cases the OS. > >> http://llvm.org/docs/GettingStarted.html#brokengcc > >> > >> So for example, GCC 3.3.3 on Suse or GCC 3.4.0 on linux/x86 > >> (32-bit) has issues. Is it easy to check these kinds of things? > >> > > > > uname identifies arch. > > > > /etc/lsb-release identifies Linux distribution; I'm not sure how to > > identify Apple and Cygwin. > > > > > uname on Apple (at least in a Terminal) returns 'Darwin'. Ah, right. It should be uname -m uname -p uname -i uname without an option is the same as uname -s, which is the name of the kernel ("Linux" for me). BTW ./configure already gathers that information (indeed via these uname calls). Regards, Jo From jo at durchholz.org Fri Mar 21 06:35:17 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 21 Mar 2008 12:35:17 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <200803210917.44039.baldrick@free.fr> References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> <200803210917.44039.baldrick@free.fr> Message-ID: <1206099317.7905.11.camel@kurier> Am Freitag, den 21.03.2008, 09:16 +0100 schrieb Duncan Sands: > > There's a list at http://llvm.org/docs/GettingStarted.html#brokengcc so > > there is a reasonable basis. > > The list isn't comprehensive, of course, and will likely grow in the > > future. OTOH extending it as new problems come up should be easy to do. > > that list is not very reliable. For example it says that gcc-4.1 is > problematic, but I never had any problems with it on ubuntu linux. So > it's probably best to warn if a dubious tool is seen, rather than erroring > out. I have to report that the Ubuntu gcc-4.1 will fail. 'make' would run without giving more than a few warnings, but 'make install' will complain that it doesn't know how to build one of the intermediate targets and error out (some VMCore/tablegen file IIRC, I don't have the log anymore). Of course, such a list cannot ever be reliable, so giving a warning is probably the best strategy anyway. Is there a real difference between an error and a warning in ./configure, anyway? Regards, Jo From jo at durchholz.org Fri Mar 21 07:34:55 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 21 Mar 2008 13:34:55 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc Message-ID: <1206102895.7905.17.camel@kurier> Am Freitag, den 21.03.2008, 13:03 +0100 schrieb Duncan Sands: > Hi Joachim, > > > I have to report that the Ubuntu gcc-4.1 will fail. 'make' would run > > without giving more than a few warnings, but 'make install' will > > complain that it doesn't know how to build one of the intermediate > > targets and error out (some VMCore/tablegen file IIRC, I don't have > > the log anymore). > > I just did a successful "make" and "make install" using gcc-4.1 on > ubuntu: > gcc version 4.1.3 20080308 (prerelease) (Ubuntu 4.1.2-21ubuntu1) > I built as follows (I note I'm using a seperate build directory): > export CC=gcc-4.1 > export CXX=g++-4.1 > ../llvm/configure --prefix=/usr/local > make && make install Maybe we're using different architectures? I'm on the amd64 version of Ubuntu, with multilibs installed. Either way, it's probably best to just issue warnings. (Assuming there's any difference between warnings and errors in ./configure.) (Good thing Ubuntu comes with a 4.2 gcc...) Regards, Jo From robert.a.zeh at gmail.com Fri Mar 21 07:40:02 2008 From: robert.a.zeh at gmail.com (Robert Zeh) Date: Fri, 21 Mar 2008 07:40:02 -0500 Subject: [LLVMdev] exception handling broken on x86-64? In-Reply-To: <8CB9AC6F-6EF1-49B4-861B-8A3AB5DB1EA0@apple.com> References: <200802110606.m1B66mk5052431@star.math.spbu.ru> <200803161307.04915.baldrick@free.fr> <8CB9AC6F-6EF1-49B4-861B-8A3AB5DB1EA0@apple.com> Message-ID: <65B57045-E022-46A7-B00D-09B6304B5405@gmail.com> I'm sorry to beat a dead horse, but I just want to be clear that I'm asking about exception handling from within the JIT, not the native code produced by llvm-g++. For example, the following doesn't work for me on linux x86 (let alone x86_64). I'm using an llvm build from revision 48493 (March 18th). exceptiontest.cpp: #include int main(int argc, char *argv[]) { try { throw 5; } catch (int i) { printf("caught %d\n", i); } return 0; } $ llvm-g++ -emit-llvm exceptiontest.cpp -c $ lli -enable-eh -enable-correct-eh-support exceptiontest.o terminate called after throwing an instance of 'int' lli(_ZN40_GLOBAL__N_Signals.cpp_00000000_17C8705F15PrintStackTraceEv +0x24)[0x884948c] lli(_ZN40_GLOBAL__N_Signals.cpp_00000000_17C8705F13SignalHandlerEi +0x115)[0x8849623] [0xffffe420] /lib/tls/libc.so.6(abort+0xeb)[0x4018fdbb] /usr/lib/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv +0x179)[0x4010b489] /usr/lib/libstdc++.so.6[0x40108e15] /usr/lib/libstdc++.so.6[0x40108e52] /usr/lib/libstdc++.so.6[0x40108fba] [0x40307055] lli (_ZN4llvm15ExecutionEngine17runFunctionAsMainEPNS_8FunctionERKSt6vectorISsSaISsEEPKPKc +0x41c)[0x84f7428] lli(main+0x44b)[0x83b66d3] /lib/tls/libc.so.6(__libc_start_main+0xd0)[0x4017bea0] lli[0x83b61c1] Aborted I had hoped this would work --- and if I use llvm-g++ to compile exceptiontest.cpp to native code it does. But it looks like the JIT is producing stack frames that the C++ runtime doesn't like. Robert On Mar 16, 2008, at 12:41 PM, Dale Johannesen wrote: > > On Mar 16, 2008, at 5:07 AM, Duncan Sands wrote: > >>> Did anything ever come of the work on exception handling for x86_64? >>> >>> I'm having problems with exceptions on linux x86_64. >> >> I'm fairly sure that exception handling doesn't currently work on >> x86-64 linux (it may work with darwin - not sure). I don't know >> what it would take to get it to work. > > On Darwin, the Dwarf metadata emitted in .s/.o files is correct > (although there may be bugs, it hasn't been exercised beyond the > llvm and gcc testsuites). The unwinding code in libgcc* has not > been ported to x86-64 and does not work. Thus, if you take the > libgcc* from a non-llvm gcc and link llvm-gcc-produced .o files with > that, things work. > It would probably not take much to get Linux x86-64 to this state, I > doubt the metadata is much different from Darwin. > From ssen at apple.com Fri Mar 21 08:56:23 2008 From: ssen at apple.com (Shantonu Sen) Date: Fri, 21 Mar 2008 06:56:23 -0700 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <1206053018.7545.48.camel@kurier> References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> <1206053018.7545.48.camel@kurier> Message-ID: <899E6FC5-0A18-4CE2-8E8C-8F29E3912CDD@apple.com> I recommend you don't parse version strings. In fact I switch the check to use AC_COMPILE precisely for the reason that gcc --version is totally unreliable and vendor specific. For example, what's the regular expression that tells you what the GCC version is: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5470) (Aspen 5470.3) Per the rest of this thread, you can't even be sure that gcc 4.x.y on one linux distribution is compile the same as on another. If there are test cases that you'd like to embed directly into the configure script that will crash the compiler, that's probably worth doing up front. For the "gcc miscompiles llvm" bugs, can we rely on anything other than the testsuite? Shantonu Sent from my MacBook On Mar 20, 2008, at 3:43 PM, Joachim Durchholz wrote: > > Am Donnerstag, den 20.03.2008, 15:27 -0700 schrieb Shantonu Sen: >> llvm's ./configure already does that for gcc < 3. >> >> What are valid versions? Exactly 4.0 and 4.2? 4.0 and >=4.2? > > There's a list at http://llvm.org/docs/GettingStarted.html#brokengcc > so > there is a reasonable basis. > The list isn't comprehensive, of course, and will likely grow in the > future. OTOH extending it as new problems come up should be easy to > do. > >> dnl Verify that GCC is version 3.0 or higher >> if test "$GCC" = "yes" >> then >> AC_COMPILE_IFELSE([[#if !defined(__GNUC__) || __GNUC__ < 3 >> #error Unsupported GCC version >> #endif >> ]], [], [AC_MSG_ERROR([gcc 3.x required, but you have a lower >> version])]) >> fi > > It might be simpler (and faster) to check the output of gcc -v. > Extending the list to other tools would be easier, too. > > Anybody able to give model code for that? > > Regards, > Jo > > _______________________________________________ > 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 Fri Mar 21 10:42:55 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 21 Mar 2008 18:42:55 +0300 (MSK) Subject: [LLVMdev] =?koi8-r?b?ZXhjZXB0aW9uIGhhbmRsaW5nIGJyb2tlbiBvbiB4ODYt?= =?koi8-r?b?NjQ/?= Message-ID: <200803211542.m2LFgtQQ041091@star.math.spbu.ru> Hello, Robert > I had hoped this would work --- and if I use llvm-g++ to compile > exceptiontest.cpp to native code it does. But it looks like the JIT > is producing stack frames that the C++ runtime doesn't like. Yes, surely. Emission of frames 'on fly' won't automatically make them visible for the unwinding runtime. JIT currently doesn't register these frames at all. I'll try to look into this issue little bit later. -- WBR, Anton Korobeynikov From jlerouge at apple.com Fri Mar 21 12:59:09 2008 From: jlerouge at apple.com (Julien Lerouge) Date: Fri, 21 Mar 2008 10:59:09 -0700 Subject: [LLVMdev] Apple's GCC and .s/.S files in llvm-test Message-ID: <20080321175908.GA6247@jlerouge-mac.apple.com> Hello, Apple's GCC does not make the distinction between .s and .S files and always run the preprocessor. From the man: | file.s | Assembler code. Apple's version of GCC runs the preprocessor on these | files as well as those ending in .S. | | file.S | Assembler code which must be preprocessed. The problem is that sometimes llc generates comments in the assembly that look like this for x86: ... pushl %esi ... # implicit-def: EDI ... ret The comment line is perfectly valid for the assembler, but the preprocessor does not like it because it tries to interpret it as a macro... I can see it happening for example if -std=c99 is set in the CFLAGS (that's the case in SingleSource/Regression/C++) : $ gcc --std=c99 -o t t.s t.s:5:4: error: invalid preprocessing directive #implicit One solution is to force the language to be assembler (and not assembler-with-cpp) on Darwin, that's what the attached patch does, but maybe there is a nicer solution ? Thanks, julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 PGP Public Key from: keyserver.pgp.com -------------- next part -------------- Index: Makefile.programs =================================================================== --- Makefile.programs (revision 48557) +++ Makefile.programs (working copy) @@ -377,15 +377,25 @@ LLCASSEMBLERFLAGS = -mcpu=v9 endif +# On darwin, Apple's GCC doesn't make a distinction between file.s and file.S, +# it always run the preprocessor. One way to disable that is to force the +# language to be assembler (not assembler-with-cpp). +FORCEASM = +ifeq ($(OS),Darwin) +FORCEASM = -x assembler +endif + # Assemble (and link) an LLVM-linked program using the system assembler... # $(PROGRAMS_TO_TEST:%=Output/%.llc): \ Output/%.llc: Output/%.llc.s - -$(LLVMGCCLD) $< -o $@ $(LLCLIBS) $(LLCASSEMBLERFLAGS) $(TARGET_FLAGS) $(LDFLAGS) + -$(LLVMGCCLD) $(FORCEASM) $< -o $@ $(LLCLIBS) $(LLCASSEMBLERFLAGS) \ + $(TARGET_FLAGS) $(LDFLAGS) $(PROGRAMS_TO_TEST:%=Output/%.llc-beta): \ Output/%.llc-beta: Output/%.llc-beta.s - -$(LLVMGCCLD) $< -o $@ $(LLCLIBS) $(LLCASSEMBLERFLAGS) $(TARGET_FLAGS) $(LDFLAGS) + -$(LLVMGCCLD) $(FORCEASM) $< -o $@ $(LLCLIBS) $(LLCASSEMBLERFLAGS) \ + $(TARGET_FLAGS) $(LDFLAGS) # From jo at durchholz.org Fri Mar 21 13:48:27 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 21 Mar 2008 19:48:27 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <899E6FC5-0A18-4CE2-8E8C-8F29E3912CDD@apple.com> References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> <1206053018.7545.48.camel@kurier> <899E6FC5-0A18-4CE2-8E8C-8F29E3912CDD@apple.com> Message-ID: <1206125307.7905.89.camel@kurier> Am Freitag, den 21.03.2008, 06:56 -0700 schrieb Shantonu Sen: > I recommend you don't parse version strings. In fact I switch the > check to use AC_COMPILE precisely for the reason that gcc --version is > totally unreliable and vendor specific. For example, what's the > regular expression that tells you what the GCC version is: > i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5470) > (Aspen 5470.3) Rrright. -v isn't very helpful; I'd have thought it would. Alternatives would be gcc -dumpversion or __GNUC__, __GNUC_MINOR__, and __GNUC_PATCHLEVEL__ from inside a C program. (I just checked, __GNUC_PATCHLEVEL is documented to be available since 3.0, -dumpversion since 3.0.4 or possibly earlier.) > Per the rest of this thread, you can't even be sure that gcc 4.x.y on > one linux distribution is compile the same as on another. Sure. OTOH one could issue warnings instead of errors in those situations that are difficult to diagnose exactly. Here's some pseudocode, take a look at what's happening for 3.3.3 (which assumes that we can identify cygwin but not SuSE 9.1): -- snip -- switch gcc-version 1.*, 2.*) error "gcc before version 3.0 has several problems in the STL that effectively prevent it from compiling LLVM. Please upgrade to a newer gcc." 3.2.2, 3.2.3) error "gcc 3.2.2 and 3.2.3 fail to compile LLVM with a bogus template error. Please upgrade to a newer gcc." 3.3.3) if arch = cygwin then error "gcc 3.3.3 on Cygwin does not work. Please upgrade to a newer gcc." else warning "The version of GCC 3.3.3 shipped with SuSE 9.1 (and possibly others) does not compile LLVM correctly (it appears that exception handling is broken in some cases). Please download the FSF 3.3.3 or upgrade to a newer version of GCC." 3.4.0) if arch = x86 then error "gcc 3.4.0 for x86 miscompiles portions of the code generator, causing an infinite loop in the llvm-gcc build when built with optimizations enabled (i.e. a release build). Please upgrade to a newer gcc." 3.4.2) if arch = x86 then warning "gcc 3.4.2 for x86 miscompiles portions of the code generator, causing an infinite loop in the llvm-gcc build when built with full optimizations enabled (i.e. a release build). The workaround is to use -O2 instead of -O3 as optimization level, which has been set." activate OPTIMIZE_OPTION=-O2 3.4.4) if arch = arm then warning "gcc 3.4.4 for ARM (CodeSourcery ARM 2005q3-2) miscompiles LLVM when building with full optimizations enabled. The workaround is to use -O1 instead of -O3 as optimization level, which has been set." activate OPTIMIZE_OPTION=-O1 4.0.0) if arch = ia64 then error "gcc 4.0.0 for ia-64 miscompiles LLVM. Please upgrade to a newer version of gcc." 4.1.1) error "gcc 4.1.1 fails to build LLVM with template concept check errors compiling some files. Please update to a newer version of gcc." 4.1.2) warning "gcc 4.1.1 on OpenSuSE segfaults during libstdc++ build. Please update to a newer version of gcc if this is OpenSuSE." if arch = x86_64 && gcc-version = 3.4.* then error "gcc 3.4 for x86_64 miscompiles portions of LLVM. Please upgrade to a newer gcc." if Xcode 2.3 then warning "Xcode 2.3 crashes when compiling LLVM with full optimizations enabled. The workaround is to use -O1 instead of -O2 as optimization level, which has been set." activate OPTIMIZE_OPTION=-O2 -- snip -- I'm not sure how to best identify binutils. Assuming their version is in binutils-version, we could do: -- snip -- switch binutils-version 2.16.*) warning "Some 2.16.X versions of the ld linker will produce very long warning messages complaining that some ".gnu.linkonce.t.*" symbol was defined in a discarded section. You can safely ignore these messages as they are erroneous and the linkage is correct." 2.17.*) warning "Binutils 2.17 contains a bug which causes huge link times (minutes instead of seconds) when building LLVM. Please upgrade to binutils 2.17.50.0.4 or later." -- snip -- > If there are > test cases that you'd like to embed directly into the configure script > that will crash the compiler, that's probably worth doing up front. Can't say anything for or against that. It's not the problem I was having. > For the "gcc miscompiles llvm" bugs, can we rely on anything other > than the testsuite? These things cannot be tested before llvm is compiled, at which point you're ready to run the test suite anyway. Regards, jo From nicolas.geoffray at lip6.fr Fri Mar 21 16:52:32 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Fri, 21 Mar 2008 22:52:32 +0100 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM Message-ID: <47E42E20.60505@lip6.fr> Hi everyone, I've just checked in a JVM and a CLI for LLVM (called JnJVM and N3). Both are placed in the vmkit svn directory. You can find the source code here: svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit Its licensed under the U of I Open Source License, so now that's in svn, you can change whatever you want, as long as HelloWorld.java and HelloWorld.cs work ;-) I haven't tested the build process on many machines, mostly on gentoo linux/x86 and linux/ppc. There are probably some dev libs that VMKit requires and the configure script does not check. A good thing would be to make the build process cleaner. The README file on root explains the few steps to run the virtual machines. I should probably say here that you currently need to patch llvm to get things working :( Let's hope this won't be true too long. Happy hacking! Nicolas PS: I won't be able to check my emails until Wednesday, so really, happy hacking! ;-) From gonsolo at gmail.com Fri Mar 21 19:00:30 2008 From: gonsolo at gmail.com (Gonsolo) Date: Sat, 22 Mar 2008 01:00:30 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <1206125307.7905.89.camel@kurier> References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> <1206053018.7545.48.camel@kurier> <899E6FC5-0A18-4CE2-8E8C-8F29E3912CDD@apple.com> <1206125307.7905.89.camel@kurier> Message-ID: <47E44C1E.3050906@gmail.com> Joachim Durchholz schrieb: > Am Freitag, den 21.03.2008, 06:56 -0700 schrieb Shantonu Sen: >> I recommend you don't parse version strings. In fact I switch the >> check to use AC_COMPILE precisely for the reason that gcc --version is >> totally unreliable and vendor specific. For example, what's the >> regular expression that tells you what the GCC version is: >> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5470) >> (Aspen 5470.3) > > Rrright. -v isn't very helpful; I'd have thought it would. > > Alternatives would be > gcc -dumpversion > or __GNUC__, __GNUC_MINOR__, and __GNUC_PATCHLEVEL__ from inside a C > program. (I just checked, __GNUC_PATCHLEVEL is documented to be > available since 3.0, -dumpversion since 3.0.4 or possibly earlier.) The Linux kernel uses a script called gcc-version that returns "0402" for gcc-4.2. It can be found at http://tinyurl.com/3xvbhh . It is essentially a call to echo __GNUC__ | gcc -E -xc - | tail -n1 . g From resistor at mac.com Fri Mar 21 23:00:27 2008 From: resistor at mac.com (Owen Anderson) Date: Fri, 21 Mar 2008 23:00:27 -0500 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47E42E20.60505@lip6.fr> References: <47E42E20.60505@lip6.fr> Message-ID: <583B623E-92DE-4B1B-8E2D-22072B1C2111@mac.com> Here's a patch that gets Mvm compiling on Darwin. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: mvm.patch.gz Type: application/x-gzip Size: 669 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080321/30544c25/attachment.gz -------------- next part -------------- On Mar 21, 2008, at 4:52 PM, Nicolas Geoffray wrote: > Hi everyone, > > I've just checked in a JVM and a CLI for LLVM (called JnJVM and N3). > Both are placed in the vmkit svn directory. > You can find the source code here: > > svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit > > Its licensed under the U of I Open Source License, so now that's in > svn, > you can change whatever you want, as long as HelloWorld.java and > HelloWorld.cs work ;-) > > I haven't tested the build process on many machines, mostly on gentoo > linux/x86 and linux/ppc. There are probably some dev libs that VMKit > requires and the configure script does not check. A good thing would > be > to make the build process cleaner. > > The README file on root explains the few steps to run the virtual > machines. > > I should probably say here that you currently need to patch llvm to > get > things working :( Let's hope this won't be true too long. > > Happy hacking! > > Nicolas > > PS: I won't be able to check my emails until Wednesday, so really, > happy > hacking! ;-) > _______________________________________________ > 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/20080321/30544c25/attachment.bin From bruno.cardoso at gmail.com Fri Mar 21 23:02:05 2008 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Sat, 22 Mar 2008 04:02:05 +0000 Subject: [LLVMdev] GSoC Mips backend improvement In-Reply-To: References: <275e64e40803182246k7fbd0fd0v23b80d4936a1718@mail.gmail.com> Message-ID: <275e64e40803212102t1da2fadaqf98b8d147c3888a3@mail.gmail.com> On Thu, Mar 20, 2008 at 2:22 AM, Chris Lattner wrote: > Hi Bruno! Hi Chris, > I think that improving the MIPS backend would be great. However, > instead of "general improvements", I'd strongly suggest focusing your > efforts on a specific use (e.g. PSP, PS2 or whatever else you have to > play with). > > Based on that, I'd work on getting the rest of llvm-test to work, > adding subtarget features (FP etc) needed for that specific CPU, then > working on performance etc. > > I think this would be a much more useful and focused project than just > "make the backend better". This will also hopefully allow us to say > "llvm supports MIPS for the PSP" (or whatever), instead of just saying > "we support some mips chips". What do you think? You're right, the focused approach is more likely to get better results! I'll focus on PSP at the proposal, it seems the better choice too me, it would be nice to hear "llvm supports MIPS for the PSP" ;) -- Bruno Cardoso Lopes ( now @ Cocos Island ) http://www.brunocardoso.cc ++ The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom + Isaac Asimov From rajikacc at gmail.com Fri Mar 21 23:22:52 2008 From: rajikacc at gmail.com (Rajika Kumarasiri) Date: Sat, 22 Mar 2008 09:52:52 +0530 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <200803201805.47745.baldrick@free.fr> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> <200803190939.36482.baldrick@free.fr> <3DF6E7B9-6E5A-4A73-A379-8A1858F8A7E1@apple.com> <200803201805.47745.baldrick@free.fr> Message-ID: <696bc1d50803212122x3e81883au708e27ff3fa48d6d@mail.gmail.com> Hello every body, Thank you all for your great suggestions and feedbacks, I'd forward the detailed proposal within couple of days. And also if I need to clarify any thing I'll ask in the list. Thanks again. Regards, Rajika On Thu, Mar 20, 2008 at 10:35 PM, Duncan Sands wrote: > While on the subject of the testsuite, some random thoughts: > > - show how test results changed from one week and one month > ago, and compared to the last release, rather than just > comparing with the previous run as now. Good for spotting > trends. > - fix the testsuite so that buildlogs are really available: > I occasionally see that a nightly tester failed the build, and > in the message it gives a url where you can get the build log. > Only the logs aren't there... > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- comp.lang.c - http://groups.google.com/group/comp.lang.c/topics -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080322/037e4d40/attachment.html From jo at durchholz.org Sat Mar 22 03:17:04 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 22 Mar 2008 09:17:04 +0100 Subject: [LLVMdev] Just got bitten by accidentally using the wrong gcc In-Reply-To: <1206125307.7905.89.camel@kurier> References: <1206050436.7545.40.camel@kurier> <330E4F05-5F75-45A0-9416-33CC49C4D6A2@apple.com> <1206053018.7545.48.camel@kurier> <899E6FC5-0A18-4CE2-8E8C-8F29E3912CDD@apple.com> <1206125307.7905.89.camel@kurier> Message-ID: <1206173824.7605.14.camel@kurier> Let me give a shorter version of my previous mail: Am Freitag, den 21.03.2008, 19:48 +0100 schrieb Joachim Durchholz: > Am Freitag, den 21.03.2008, 06:56 -0700 schrieb Shantonu Sen: > > I recommend you don't parse version strings. I think you mean one shouldn't parse output intended for humans, and I agree that one should avoid this if possible. In the case of gcc, the -dumpversion option emits an easily parsable, bare version string. For binutils (including ld), this is far more difficult because (a) there is no bare version number available, and (b) llvm does not assume GNU tools. Probably it's best to match the output of ld -v for *GNU ld*2.16* *GNU ld*2.17* to catch the two versions that are known to cause problems. > > If there are > > test cases that you'd like to embed directly into the configure script > > that will crash the compiler, that's probably worth doing up front. That might be useful, but this is not what I'm after. I'd like to see ./configure check the requirements listed in sections "Software" and "Broken versions of GCC and other tools" on page file:///home/jo/Desktop/Delta/llvm/docs/GettingStarted.html . If a version cannot be identified, it's enough to issue a warning. If downgrading an optimizer option is enough, then this should be made the default (and issuing a warning would be OK so performance-conscious people will know they should upgrade). Regards, Jo From jo at durchholz.org Sat Mar 22 05:00:09 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 22 Mar 2008 11:00:09 +0100 Subject: [LLVMdev] Status of LLVM-GCC 4.2? Message-ID: <1206180009.7605.17.camel@kurier> Hi all, I'm wondering what the comparative status of llvm-gcc4.0 vs. llvm-gcc4.2 is. Can anybody tell? (A URL would be fine, I may have been just too dumb to find it.) Regards, Jo From edwintorok at gmail.com Sat Mar 22 05:39:35 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sat, 22 Mar 2008 12:39:35 +0200 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47E42E20.60505@lip6.fr> References: <47E42E20.60505@lip6.fr> Message-ID: <47E4E1E7.2070707@gmail.com> Nicolas Geoffray wrote: > Hi everyone, > > I've just checked in a JVM and a CLI for LLVM (called JnJVM and N3). > Both are placed in the vmkit svn directory. > You can find the source code here: > Very nice! > svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit > > Its licensed under the U of I Open Source License, so now that's in svn, > you can change whatever you want, as long as HelloWorld.java and > HelloWorld.cs work ;-) > > I haven't tested the build process on many machines, mostly on gentoo > linux/x86 and linux/ppc. There are probably some dev libs that VMKit > requires and the configure script does not check. A good thing would be > to make the build process cleaner. The code is not 64-bit clean, attached is a patch to get it compile on x86-64 Linux. I also fixed some g++-4.2 warnings (const issues, symbol visibility). The libJnJVM directory builds, but it won't run, I get endless messages like this: ; ****************************************************** ; ; SIGSEGV occured during a collection ; ; I'm trying to let the allocator in a coherent stat ; ; but the collector is DEAD and will never collect again ; ; ****************************************************** ; Probably there are more 64-bit issues to solve. Unfortunately I don't have time to look into this deeper now. Best regards, --Edwin -------------- next part -------------- A non-text attachment was scrubbed... Name: build64.patch Type: text/x-diff Size: 30879 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080322/bfcc9ba2/attachment-0001.bin From andrewl at lenharth.org Sat Mar 22 09:45:20 2008 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sat, 22 Mar 2008 09:45:20 -0500 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <1206180009.7605.17.camel@kurier> References: <1206180009.7605.17.camel@kurier> Message-ID: <85dfcd7f0803220745m45d03043r7b4697d0dae9775a@mail.gmail.com> officially support for llvm-gcc4.0 has been dropped. unofficially I still keep llvm-gcc4.0 compiling because I need it for some stuff. But this will only last until I can use 4.2. Andrew On Sat, Mar 22, 2008 at 5:00 AM, Joachim Durchholz wrote: > Hi all, > > I'm wondering what the comparative status of llvm-gcc4.0 vs. llvm-gcc4.2 > is. Can anybody tell? (A URL would be fine, I may have been just too > dumb to find it.) > > Regards, > Jo > > _______________________________________________ > 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 Mar 22 10:20:31 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sat, 22 Mar 2008 17:20:31 +0200 Subject: [LLVMdev] Adding SQLite3 to llvm test-suite Message-ID: <47E523BF.7040200@gmail.com> Hi, SQLite3 has a very simple build system, and it comes with an extensive testsuite (over 40000 tests). It hasn't shown any bugs in LLVM, but it is fairly simple to build [even turn off features via -D], and can be CPU intensive. I have integrated SQLite3 into llvm-test's build system, it is too large to send as attachment (784K), you can get it from here: http://edwintorok.googlepages.com/SQLite_llvm_test.tar.gz The testsuite is using tcl, and needs tcl headers available at build-time so I didn't add that [they are mostly I/O bound anyway] Instead I found a "speedtest" script in the sqlite distribution. I modified it to generate sql files instead of directly running sqlite. The results are here, LLVM is ~20% slower than GCC: 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 lemon/lemon | 0.3833 149404 0.5699 * 0.5166 | 0.04 0.04 0.05 * 0.62 | - - n/a n/a sqlite3/sqlite3 | 4.8063 1744588 5.3996 * 3.7497 | 7.09 8.19 8.78 * 13.68 | 0.87 0.81 n/a n/a There are more speedtest scripts in its testsuite, but the generated sql is large (>10 Mb), and I think the above shows a clear difference between LLVM and GCC. Can somebody please review and commit this to llvm-test? Best regards, --Edwin From tonic at nondot.org Sat Mar 22 11:17:46 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sat, 22 Mar 2008 09:17:46 -0700 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <1206180009.7605.17.camel@kurier> References: <1206180009.7605.17.camel@kurier> Message-ID: <87EABBD6-921B-4214-AE84-0A47A739376A@nondot.org> On Mar 22, 2008, at 3:00 AM, Joachim Durchholz wrote: > Hi all, > > I'm wondering what the comparative status of llvm-gcc4.0 vs. llvm- > gcc4.2 > is. Can anybody tell? (A URL would be fine, I may have been just too > dumb to find it.) > There isn't one. I can tell you that when I did the release testing that for most platforms there were no new regressions with llvm-gcc-4.2 on llvm- test. I didn't look at performance between the two though. Since LLVM 2.2 we have dropped support for llvm-gcc-4.0. -Tanya > Regards, > Jo > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From baldrick at free.fr Sat Mar 22 12:49:02 2008 From: baldrick at free.fr (Duncan Sands) Date: Sat, 22 Mar 2008 18:49:02 +0100 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <1206180009.7605.17.camel@kurier> References: <1206180009.7605.17.camel@kurier> Message-ID: <200803221849.03983.baldrick@free.fr> Hi Jo, > I'm wondering what the comparative status of llvm-gcc4.0 vs. llvm-gcc4.2 > is. Can anybody tell? (A URL would be fine, I may have been just too > dumb to find it.) development of llvm-gcc-4.0 has stopped: only 4.2 is being worked on. The version of 4.2 in the last LLVM release was already mostly superior to 4.0 IMHO. Ciao, Duncan. From asl at math.spbu.ru Sat Mar 22 12:50:53 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sat, 22 Mar 2008 20:50:53 +0300 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47E4E1E7.2070707.SS32976SS@gmail.com> References: <47E42E20.60505@lip6.fr> <47E4E1E7.2070707.SS32976SS@gmail.com> Message-ID: <1206208253.16812.70.camel@asl.dorms.spbu.ru> Hello, Edwin > Probably there are more 64-bit issues to solve. Unfortunately I don't > have time to look into this deeper now. At least these "4" looks pretty suspicious: - (void *)gcset((gc **)((unsigned int)this + nbb + 4 - sizeof(void *)), + (void *)gcset((gc **)((size_t)this + nbb + 4 - sizeof(void *)), (Object*)m); -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From jo at durchholz.org Sat Mar 22 13:05:31 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 22 Mar 2008 19:05:31 +0100 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <200803221849.03983.baldrick@free.fr> References: <1206180009.7605.17.camel@kurier> <200803221849.03983.baldrick@free.fr> Message-ID: <1206209131.7605.20.camel@kurier> Am Samstag, den 22.03.2008, 18:49 +0100 schrieb Duncan Sands: > development of llvm-gcc-4.0 has stopped: only 4.2 is being worked on. > The version of 4.2 in the last LLVM release was already mostly superior > to 4.0 IMHO. So the recommendation would be to use 4.2 for all uses, yes? (Bootstrapping LLVM itself, compiling C/C++ software, whatever.) Regards, Jo From evan.cheng at apple.com Sat Mar 22 13:43:54 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sat, 22 Mar 2008 11:43:54 -0700 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <1206180009.7605.17.camel@kurier> References: <1206180009.7605.17.camel@kurier> Message-ID: <550FDD67-43E2-4B97-A8EF-DDDEA9CE4F1F@apple.com> 4.2 is *complete*. Are you looking for performance #? Since llvm-gcc doesn't use any of gcc's optimization and codegen passes it should roughly the same. In fact, that's what we have been seeing. We have formally deprecated llvm-gcc 4.0 as far as I know. Evan On Mar 22, 2008, at 3:00 AM, Joachim Durchholz wrote: > Hi all, > > I'm wondering what the comparative status of llvm-gcc4.0 vs. llvm- > gcc4.2 > is. Can anybody tell? (A URL would be fine, I may have been just too > dumb to find it.) > > Regards, > Jo > > _______________________________________________ > 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 Mar 22 13:58:37 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Sat, 22 Mar 2008 19:58:37 +0100 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47E42E20.60505@lip6.fr> References: <47E42E20.60505@lip6.fr> Message-ID: Thanks, I am going to download now. From jo at durchholz.org Sat Mar 22 17:37:35 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 22 Mar 2008 23:37:35 +0100 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <85dfcd7f0803220745m45d03043r7b4697d0dae9775a@mail.gmail.com> References: <1206180009.7605.17.camel@kurier> <85dfcd7f0803220745m45d03043r7b4697d0dae9775a@mail.gmail.com> Message-ID: <1206225455.7605.29.camel@kurier> Am Samstag, den 22.03.2008, 09:45 -0500 schrieb Andrew Lenharth: > officially support for llvm-gcc4.0 has been dropped. > unofficially I still keep llvm-gcc4.0 compiling because I need it for > some stuff. But this will only last until I can use 4.2. OK, that's a clear roadmap. Maybe the docs should be updated to reflect this status? They still present 4.0 as if it were the default that one should use. Regards, Jo From isanbard at gmail.com Sat Mar 22 19:22:48 2008 From: isanbard at gmail.com (Bill Wendling) Date: Sat, 22 Mar 2008 17:22:48 -0700 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <1206180009.7605.17.camel@kurier> References: <1206180009.7605.17.camel@kurier> Message-ID: On Mar 22, 2008, at 3:00 AM, Joachim Durchholz wrote: > Hi all, > > I'm wondering what the comparative status of llvm-gcc4.0 vs. llvm- > gcc4.2 > is. Can anybody tell? (A URL would be fine, I may have been just too > dumb to find it.) > Hi Joachim, We've officially moved to llvm-gcc 4.2 and are no longer keeping llvm- gcc 4.0 up-to-date. (Andrew keeps 4.0 compiling, but we no longer care about keeping it feature-compatible with 4.2.) -bw From isanbard at gmail.com Sun Mar 23 04:20:09 2008 From: isanbard at gmail.com (Bill Wendling) Date: Sun, 23 Mar 2008 02:20:09 -0700 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <1206209131.7605.20.camel@kurier> References: <1206180009.7605.17.camel@kurier> <200803221849.03983.baldrick@free.fr> <1206209131.7605.20.camel@kurier> Message-ID: <673C63C3-97B2-4DEA-970D-017D47F8C830@gmail.com> On Mar 22, 2008, at 11:05 AM, Joachim Durchholz wrote: > Am Samstag, den 22.03.2008, 18:49 +0100 schrieb Duncan Sands: >> development of llvm-gcc-4.0 has stopped: only 4.2 is being worked on. >> The version of 4.2 in the last LLVM release was already mostly >> superior >> to 4.0 IMHO. > > So the recommendation would be to use 4.2 for all uses, yes? > (Bootstrapping LLVM itself, compiling C/C++ software, whatever.) > Yes. :-) -bw From isanbard at gmail.com Sun Mar 23 04:19:02 2008 From: isanbard at gmail.com (Bill Wendling) Date: Sun, 23 Mar 2008 02:19:02 -0700 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47E4E1E7.2070707@gmail.com> References: <47E42E20.60505@lip6.fr> <47E4E1E7.2070707@gmail.com> Message-ID: <1FB8560D-5BB6-4663-BADB-AD1E38052F5B@gmail.com> On Mar 22, 2008, at 3:39 AM, T?r?k Edwin wrote: >> I haven't tested the build process on many machines, mostly on gentoo >> linux/x86 and linux/ppc. There are probably some dev libs that VMKit >> requires and the configure script does not check. A good thing >> would be >> to make the build process cleaner. > > The code is not 64-bit clean, attached is a patch to get it compile on > x86-64 Linux. > I also fixed some g++-4.2 warnings (const issues, symbol visibility). > > The libJnJVM directory builds, but it won't run, I get endless > messages > like this: > ; ****************************************************** ; > ; SIGSEGV occured during a collection ; > ; I'm trying to let the allocator in a coherent stat ; > ; but the collector is DEAD and will never collect again ; > ; ****************************************************** ; > > Probably there are more 64-bit issues to solve. Unfortunately I don't > have time to look into this deeper now. > > Best regards, > --Edwin > Index: include/mvm/Method.h > =================================================================== > --- include/mvm/Method.h (revision 48684) > +++ include/mvm/Method.h (working copy) > @@ -47,11 +47,11 @@ > > inline Method *method(Method *m, size_t nbb) { > return > - (Method *)gcset((gc **)((unsigned int)this + nbb + 4 - > sizeof(Method *)), m); > + (Method *)gcset((gc **)((size_t)this + nbb + 4 - > sizeof(Method *)), m); Instead of "size_t" and "ssize_t", it be better to use "uintptr_t" and "intptr_t" in all cases, since they were made for these situations. -bw From jo at durchholz.org Sun Mar 23 06:18:32 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 23 Mar 2008 12:18:32 +0100 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <550FDD67-43E2-4B97-A8EF-DDDEA9CE4F1F@apple.com> References: <1206180009.7605.17.camel@kurier> <550FDD67-43E2-4B97-A8EF-DDDEA9CE4F1F@apple.com> Message-ID: <1206271112.7631.8.camel@kurier> Am Samstag, den 22.03.2008, 11:43 -0700 schrieb Evan Cheng: > 4.2 is *complete*. Are you looking for performance #? No, I'm just trying to bootstrap llvm-gcc. Even after that, performance will remain relatively unimportant for me for quite a while, and even then I'll want to compete with PHP (or Python, Ruby, Perl), and I don't think this will be a challenge. Regards, Jo From saurik at saurik.com Sun Mar 23 06:39:20 2008 From: saurik at saurik.com (Jay Freeman (saurik)) Date: Sun, 23 Mar 2008 04:39:20 -0700 Subject: [LLVMdev] a quick typo in the ARM LLVM backend Message-ID: So, a while back I got a compile error where the assembly was missing some whitespace between a .set and the identifier and tracked it down to this simple mistake that I just verified is still in the tree: Index: lib/Target/ARM/ARMTargetAsmInfo.cpp =================================================================== --- lib/Target/ARM/ARMTargetAsmInfo.cpp (revision 48700) +++ lib/Target/ARM/ARMTargetAsmInfo.cpp (working copy) @@ -49,7 +49,7 @@ PrivateGlobalPrefix = "L"; BSSSection = 0; // no BSS section. ZeroFillDirective = "\t.zerofill\t"; // Uses .zerofill - SetDirective = "\t.set"; + SetDirective = "\t.set\t"; WeakRefDirective = "\t.weak_reference\t"; HiddenDirective = "\t.private_extern\t"; ProtectedDirective = NULL; I unfortunately don't have the code that died anymore (it was a couple months ago, and I'm unfortunately just now getting on this mailing list to report the issue), but it seems pretty obvious from the surrounding context to be wrong, and there's even another initialization of SetDirective in the same file that _does_ have the traililng \t. Sincerely, Jay Freeman (saurik) saurik at saurik.com http://www.saurik.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080323/1f9b86f0/attachment-0001.html From saurik at saurik.com Sun Mar 23 06:50:48 2008 From: saurik at saurik.com (Jay Freeman (saurik)) Date: Sun, 23 Mar 2008 04:50:48 -0700 Subject: [LLVMdev] non-enable-llvm support in llvm-gcc-4.2 issue Message-ID: <80C643111EC3473B8EFA65E833AA5306@ccs.ucsb.edu> There seems to be a bunch of code for making certain that gcc still works even if --enable-gcc isn't used, so I'm assuming that it's at least supposed to be a supported configuration, and hence this issue that I found should probably be looked at: If you compile llvm-gcc-4.2 _without_ --enable-gcc, and then try to compile the following program, you get a rather nasty RTL error. void f() { try { throw; } catch (...) {} } test.cpp: In function .void f().: test.cpp:1: error: unrecognizable insn: (insn 39 5 40 2 (set (reg:SI 107) (UnKnown Unknown)) -1 (nil) (nil)) test.cpp:1: internal compiler error: in extract_insn, at recog.c:2100 I managed to track this down to init_one_libfunc being broken. There's some logic to try to divert an llvm_init_one_libfunc to the old implementation (via some #defines) when --emnable-llvm isn't being used, but it doesn't even have the right return type anymore and only seems to do half the old logic (the rest being in llvm_init_one_libfunnc now). I've managed to fix it pretty easily with the following hack, but it really does feel like a hack: diff --git a/gcc/expr.h b/gcc/expr.h index 850e7af..265b550 100644 --- a/gcc/expr.h +++ b/gcc/expr.h @@ -753,9 +753,6 @@ extern rtx init_one_libfunc (const char *); /* LLVM LOCAL begin */ /* Call this to initialize an optab function tree. */ extern tree llvm_init_one_libfunc (const char *); -#ifndef ENABLE_LLVM -#define llvm_init_one_libfunc init_one_libfunc -#endif /* LLVM LOCAL end */ extern int vector_mode_valid_p (enum machine_mode); diff --git a/gcc/optabs.c b/gcc/optabs.c index 06243c9..d5a1b19 100644 --- a/gcc/optabs.c +++ b/gcc/optabs.c @@ -5137,7 +5137,6 @@ init_intraclass_conv_libfuncs (convert_optab tab, const char *opname, /* LLVM local begin */ -#undef llvm_init_one_libfunc tree llvm_init_one_libfunc (const char *name) { Sincerely, Jay Freeman (saurik) saurik at saurik.com http://www.saurik.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080323/450d9fb1/attachment.html From tonic at nondot.org Sun Mar 23 13:22:10 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sun, 23 Mar 2008 11:22:10 -0700 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <1206225455.7605.29.camel@kurier> References: <1206180009.7605.17.camel@kurier> <85dfcd7f0803220745m45d03043r7b4697d0dae9775a@mail.gmail.com> <1206225455.7605.29.camel@kurier> Message-ID: <6B9F757D-17BB-4FAF-9E43-6DA51BF6208D@nondot.org> On Mar 22, 2008, at 3:37 PM, Joachim Durchholz wrote: > Am Samstag, den 22.03.2008, 09:45 -0500 schrieb Andrew Lenharth: >> officially support for llvm-gcc4.0 has been dropped. >> unofficially I still keep llvm-gcc4.0 compiling because I need it for >> some stuff. But this will only last until I can use 4.2. > > OK, that's a clear roadmap. > Please do not rely on llvm-gcc.40. I sent out this announcement last month: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-February/012416.html > Maybe the docs should be updated to reflect this status? They still > present 4.0 as if it were the default that one should use. > 2.2 docs will still have references to llvm-gcc4.0. Can you point out specifically which docs you are referring to? I'm pretty sure we were ambiguous on which one to use ;) but regardless should be updated. -Tanya > Regards, > Jo > > _______________________________________________ > 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 alacatialabs.com Sun Mar 23 16:45:51 2008 From: jon at alacatialabs.com (Jonathan Johnson) Date: Sun, 23 Mar 2008 16:45:51 -0500 Subject: [LLVMdev] LLVM 2008 Developer Meeting Survey Message-ID: <265DBF59-88E1-4101-B461-E348B8BA0B32@alacatialabs.com> Hey everyone, I've updated the website to include a link to a two-question survey regarding the possible dates of the meeting. We're looking to get some input on which dates are most convenient for everyone. You can take the survey here: Thanks! -Jon -- Jonathan Johnson President Alacatia Labs, Inc. http://www.alacatialabs.com/ From baldrick at free.fr Sun Mar 23 17:00:11 2008 From: baldrick at free.fr (Duncan Sands) Date: Sun, 23 Mar 2008 23:00:11 +0100 Subject: [LLVMdev] Announcement: GNAT ported to LLVM Message-ID: <200803232300.13178.baldrick@free.fr> Hi, this is to let people know that the recently released LLVM 2.2 compiler toolkit contains experimental support for Ada through the llvm-gcc-4.2 compiler. Currently the only platform it works on is linux running on 32 bit intel x86. This is because that's what I run, and I'm the only one who's been working on this. I would appreciate help from other Ada guys, both for porting to new platforms and adding support for missing features, not to mention testing and bug fixing!. LLVM (http://llvm.org/) is a set of compiler libraries and tools for optimization and static and just-in-time code generation. Personally I find LLVM a lot of fun, and pleasant to work with due to the good design and clean implementation. I hope you will too! llvm-gcc is gcc with the gcc optimizers replaced by LLVM's; llvm-gcc-4.2 is the version of llvm-gcc based on gcc-4.2. The way llvm-gcc works (this is transparent to users) is that the gcc-4.2 GNAT front-end converts Ada into "gimple", gcc's internal language independent representation. The gimple is then turned into LLVM's internal form, referred to as IR. This in then run through LLVM's optimizers, followed by LLVM's code generators which squirt it out as assembler or object code. In practice you can use llvm-gcc as a drop in replacement for gcc. However the use of LLVM opens up other possibilities too. For example, it is possible to have llvm-gcc squirt out LLVM IR rather than object code (by using -emit-llvm on the command line). It is possible to link the LLVM IR for different compilation units together and reoptimize them. In other words you can do link-time optimization. This is all language independent, so if part of your program is written in Ada and other parts in C/C++/Fortran etc, you can link them all together and mutually optimize them, resulting in C routines being inlined into Ada etc. The compiler works quite well, but it is still experimental. All of the ACATS testsuite passes except for c380004 and c393010. Since c380004 also fails with gcc-4.2, that makes c393010 the only failure due to the use of the LLVM infrastructure (the problem comes from the GNAT front-end which produces a bogus type declaration that the gimple -> LLVM convertor rejects). On the other hand, many of the tests in the GNAT testsuite fail. The release notes give some more details of what works and what doesn't: http://llvm.org/releases/2.2/docs/ReleaseNotes.html The precompiled llvm-gcc-4.2 shipped with the LLVM 2.2 release was built without support for Ada, so you will need to build the compiler yourself. You can find instructions at http://llvm.org/docs/GCCFEBuildInstrs.html Please report bugs and problems to the LLVM mailing lists, or using http://llvm.org/bugs/ One nice thing about LLVM is that people are responsive and quickly fix bugs (often by the next day). The LLVM IR is easy to read (with a bit of practice), and since it contains the entire LLVM state you get to see exactly what has happened to your program. This might be useful for static analysis, it is certainly useful for understanding how the various Ada constructs are implemented. To give you a taste for what it looks like, here is an example showing what a simple Ada program gets turned into. Here is the Ada: with Ada.Text_IO; procedure Hello is begin Ada.Text_IO.Put_Line ("Hello world!"); end; Here's the result of compiling it: $ gcc -S -O2 -emit-llvm -o - hello.adb ... %struct.string___XUB = type { i32, i32 } ... @.str = internal constant [12 x i8] c"Hello world!" ; <[12 x i8]*> [#uses=1] @C.168.1155 = internal constant %struct.string___XUB { i32 1, i32 12 } ; <%struct.string___XUB*> [#uses=1] define void @_ada_hello() { entry: tail call void @ada__text_io__put_line__2( i8* getelementptr ([12 x i8]* @.str, i32 0, i32 0), %struct.string___XUB* @C.168.1155 ) ret void } declare void @ada__text_io__put_line__2(i8*, %struct.string___XUB*) I've dropped the declarations of some uninteresting types and other info, thus the ... Note that passing -S -emit-llvm results in LLVM assembler being output (the human readable version of LLVM IR); using -c -emit-llvm would result in the compact binary form of LLVM IR, known as bitcode. Passing -o - causes the assembler to be dumped to the terminal. Here you can see: (1) The declaration of Ada.Text_IO.Put_Line: declare void @ada__text_io__put_line__2(i8*, %struct.string___XUB*) The name ada__text_io__put_line__2 is that generated by GNAT for this routine. The function returns no value ("void") and has two arguments: a pointer to an i8 (an i8 is an 8 bit integer, in this case a character) and a pointer to a %struct.string___XUB, which is a record type. The declaration of the type is %struct.string___XUB = type { i32, i32 } which is a record containing two 32 bit integers. These are the lower and upper bounds for the string. Thus a call two Ada.Text_IO.Put_Line in fact passes two arguments, a pointer to the string contents and a pointer to the string bounds. (2) The code defining Hello (_ada_hello). There is one basic block, the entry block marked "entry:". It contains two instructions: a call and a return instruction. The call tail call void @ada__text_io__put_line__2( i8* getelementptr ([12 x i8]* @.str, i32 0, i32 0), %struct.string___XUB* @C.168.1155 ) is marked as a "tail call". If you don't know what that means, don't worry about it. The call is to the function @ada__text_io__put_line__2, see (1) above. The first parameter is an i8*, a pointer to an 8 bit integer, and has the value getelementptr ([12 x i8]* @.str, i32 0, i32 0) What is this? First off, @.str is the string constant @.str = internal constant [12 x i8] c"Hello world!" ; <[12 x i8]*> [#uses=1] This is an internal constant, meaning that it is not visible outside this compilation unit. It has type [12 x i8], which is an array of 12 i8's. It has the value "Hello world!", which is indeed 12 characters long. There is a comment on the end of the line (starting with ";") pointing out the type of @.str, which [12 x i8]*, a pointer to an array of 12 characters, and the fact that @.str is only used in one place. The getelementptr instruction is explained in the LLVM docs, see http://llvm.org/docs/LangRef.html and also http://llvm.org/docs/GetElementPtr.html Here it just converts @.str from a [12 x i8]* into an i8* before passing it to @ada__text_io__put_line__2. In short: a pointer to the H in Hello World! is passed as the first parameter of the call. The second parameter is a pointer to a %struct.string___XUB, a record holding the lower and upper bounds for the string. The value passed is @C.168.1155, which is the constant declared as: @C.168.1155 = internal constant %struct.string___XUB { i32 1, i32 12 } ; <%struct.string___XUB*> [#uses=1] This is a constant record containing the values 1 (the lower bound) and 12 (the upper bound). The return instruction "ret void" completes execution of the function, and returns control to the caller. The "void" indicates that this routine does not actually return anything. I hope you have fun playing with LLVM! Duncan. From jo at durchholz.org Sun Mar 23 17:26:03 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 23 Mar 2008 23:26:03 +0100 Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure Message-ID: <1206311163.7598.26.camel@kurier> Just a quick heads-up: The ./configure in the llvm 2.2 package will work on my amd64 machine with this command line: ./configure --prefix=$HOME --enable-optimized \ --build=i686-pc-linux-gnu CC=gcc-4.2 CXX=g++-4.2 Note that the CC and CXX flags are set on the command line, not as environment variables - trying to submit them via the environment got me all kinds of breakage. Also not that this needs to set just --build, not --host (which defaults to the setting of --build) nor --target (which defaults to whatever value --host ends up as). Now the ./configure in llvm-gcc4.2 as of version 2.2 will choke badly on such a command line. First, it misinterprets the CC= and CXX= strings as target architecture names, and continues to complain that it cannot configure for multiple architectures at once. Second, it does not default --host or --target to --build. Third, even with --target and --host explicitly set to i686-pc-linux-gnu, the assembler will be fed with 64-bit code. The failing command is /home/jo/llvm-gcc-wrk/gcc/xgcc -B/home/jo/llvm-gcc-wrk/gcc/ -B/home/jo/i686-pc-linux-gnu/bin/ -B/home/jo/i686-pc-linux-gnu/lib/ -isystem /home/jo/i686-pc-linux-gnu/include -isystem /home/jo/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/. -I/home/jo/llvm-gcc-src/gcc/../include -I/home/jo/llvm-gcc-src/gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O -o crtbeginT.o (slightly edited to leave out multiple blanks and line continuation backslashes). The error messages are just what I had seen earlier: /tmp/ccVjR8Qt.s: Assembler messages: /tmp/ccVjR8Qt.s:33: Error: suffix or operands invalid for `push' /tmp/ccVjR8Qt.s:43: Error: suffix or operands invalid for `call' /tmp/ccVjR8Qt.s:61: Error: suffix or operands invalid for `push' /tmp/ccVjR8Qt.s:71: Error: suffix or operands invalid for `call' It seems that the ./configure for llvm-gcc is doing some, er, seriously nonstandard things with autoconf... This is close to a showstopper for integrating an llvm-gcc bootstrap into the nightly tester. The llvm-gcc ./configure needs to be called very differently from the llvm ./configure, and keeping two set of options is Not Worth The Trouble, at least IMHO. Next thing I'll check whether the same problems occur with SVN trunk. Regards, Jo P.S.: Don't worry, I'll use LLVM for my projects even if I don't manage to bootstrap it or run the nightly tester :-D From jo at durchholz.org Mon Mar 24 06:34:41 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 24 Mar 2008 12:34:41 +0100 Subject: [LLVMdev] Status of LLVM-GCC 4.2? In-Reply-To: <6B9F757D-17BB-4FAF-9E43-6DA51BF6208D@nondot.org> References: <1206180009.7605.17.camel@kurier> <85dfcd7f0803220745m45d03043r7b4697d0dae9775a@mail.gmail.com> <1206225455.7605.29.camel@kurier> <6B9F757D-17BB-4FAF-9E43-6DA51BF6208D@nondot.org> Message-ID: <1206358481.7456.2.camel@kurier> Am Sonntag, den 23.03.2008, 11:22 -0700 schrieb Tanya Lattner: > 2.2 docs will still have references to llvm-gcc4.0. Can you point out > specifically which docs you are referring to? I'm pretty sure we were > ambiguous on which one to use ;) but regardless should be updated. http://llvm.org/docs/GettingStarted.html#quickstart says on item #4: "Install the llvm-gcc4.0 (or llvm-gcc4.2) front end if you intend to compile C or C++" (Actually this passage should be updated with a hint why one would want to choose one or the other compiler.) I'm not sure about other passages, that's just he page I was working off. Regards, Jo From jo at durchholz.org Mon Mar 24 09:16:51 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 24 Mar 2008 15:16:51 +0100 Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure Message-ID: <1206368211.7456.6.camel@kurier> (Apologies if this appears twice, it seems to not have made it into the list. I added an update for SVN trunk.) Just a quick heads-up for 2.2 and SVN trunk: ./configure in the llvm package will work on my amd64 machine with this command line: ./configure --prefix=$HOME --enable-optimized \ --build=i686-pc-linux-gnu CC=gcc-4.2 CXX=g++-4.2 Note that the CC and CXX flags are set on the command line, not as environment variables - trying to submit them via the environment got me all kinds of breakage. Also not that this needs to set just --build, not --host (which defaults to the setting of --build) nor --target (which defaults to whatever value --host ends up as). Now the ./configure in llvm-gcc4.2 will choke badly on such a command line. First, it misinterprets the CC= and CXX= strings as target architecture names, and continues to complain that it cannot configure for multiple architectures at once. Second, it does not default --host or --target to --build. Third, even with --target and --host explicitly set to i686-pc-linux-gnu, the assembler will be fed with 64-bit code. The failing command is /home/jo/llvm-gcc-wrk/gcc/xgcc -B/home/jo/llvm-gcc-wrk/gcc/ -B/home/jo/i686-pc-linux-gnu/bin/ -B/home/jo/i686-pc-linux-gnu/lib/ -isystem /home/jo/i686-pc-linux-gnu/include -isystem /home/jo/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/. -I/home/jo/llvm-gcc-src/gcc/../include -I/home/jo/llvm-gcc-src/gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O -o crtbeginT.o (slightly edited to leave out multiple blanks and line continuation backslashes). The error messages are just what I had seen earlier: /tmp/ccVjR8Qt.s: Assembler messages: /tmp/ccVjR8Qt.s:33: Error: suffix or operands invalid for `push' /tmp/ccVjR8Qt.s:43: Error: suffix or operands invalid for `call' /tmp/ccVjR8Qt.s:61: Error: suffix or operands invalid for `push' /tmp/ccVjR8Qt.s:71: Error: suffix or operands invalid for `call' It seems that the ./configure for llvm-gcc is doing some, er, seriously nonstandard things with autoconf... This is close to a showstopper for integrating an llvm-gcc bootstrap into the nightly tester. The llvm-gcc ./configure needs to be called very differently from the llvm ./configure, and keeping two sets of options is Not Worth The Trouble, at least IMHO. Regards, Jo P.S.: Don't worry, I'll use LLVM for my projects even if I don't manage to bootstrap it or run the nightly tester :-D From dberlin at dberlin.org Mon Mar 24 10:37:25 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 24 Mar 2008 11:37:25 -0400 Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure In-Reply-To: <1206368211.7456.6.camel@kurier> References: <1206368211.7456.6.camel@kurier> Message-ID: <4aca3dc20803240837l18b8b246ne761df0f46abc8e3@mail.gmail.com> > > ./configure in the llvm package will work on my amd64 machine > with this command line: > > ./configure --prefix=$HOME --enable-optimized \ > --build=i686-pc-linux-gnu CC=gcc-4.2 CXX=g++-4.2 > > Note that the CC and CXX flags are set on the command line, not as > environment variables - trying to submit them via the environment got me > all kinds of breakage. Err, you should set them as env vars. Really. > > Also not that this needs to set just --build, not --host (which defaults > to the setting of --build) nor --target (which defaults to whatever > value --host ends up as). > > > Now the ./configure in llvm-gcc4.2 will choke badly on such a command line. > > First, it misinterprets the CC= and CXX= strings as target architecture > names, and continues to complain that it cannot configure for multiple > architectures at once. Which is why you should be setting them as env vars :) > > Second, it does not default --host or --target to --build. This is normal. Crappy, but normal. > > Third, even with --target and --host explicitly set to > i686-pc-linux-gnu, the assembler will be fed with 64-bit code. The > failing command is > > /home/jo/llvm-gcc-wrk/gcc/xgcc -B/home/jo/llvm-gcc-wrk/gcc/ > -B/home/jo/i686-pc-linux-gnu/bin/ -B/home/jo/i686-pc-linux-gnu/lib/ > -isystem /home/jo/i686-pc-linux-gnu/include > -isystem /home/jo/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -I. -I. > -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/. > -I/home/jo/llvm-gcc-src/gcc/../include > -I/home/jo/llvm-gcc-src/gcc/../libcpp/include -g0 > -finhibit-size-directive -fno-inline-functions -fno-exceptions > -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer > -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O > -o crtbeginT.o > > (slightly edited to leave out multiple blanks and line continuation > backslashes). > > The error messages are just what I had seen earlier: > > /tmp/ccVjR8Qt.s: Assembler messages: > /tmp/ccVjR8Qt.s:33: Error: suffix or operands invalid for `push' > /tmp/ccVjR8Qt.s:43: Error: suffix or operands invalid for `call' > /tmp/ccVjR8Qt.s:61: Error: suffix or operands invalid for `push' > /tmp/ccVjR8Qt.s:71: Error: suffix or operands invalid for `call' > This is interesting, and I wonder if it appears in gcc itself. If so, it is a bug. From jo at durchholz.org Mon Mar 24 13:41:01 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 24 Mar 2008 19:41:01 +0100 Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure In-Reply-To: <4aca3dc20803240837l18b8b246ne761df0f46abc8e3@mail.gmail.com> References: <1206368211.7456.6.camel@kurier> <4aca3dc20803240837l18b8b246ne761df0f46abc8e3@mail.gmail.com> Message-ID: <1206384061.7456.22.camel@kurier> Am Montag, den 24.03.2008, 11:37 -0400 schrieb Daniel Berlin: > > > > ./configure in the llvm package will work on my amd64 machine > > with this command line: > > > > ./configure --prefix=$HOME --enable-optimized \ > > --build=i686-pc-linux-gnu CC=gcc-4.2 CXX=g++-4.2 > > > > Note that the CC and CXX flags are set on the command line, not as > > environment variables - trying to submit them via the environment got me > > all kinds of breakage. > > Err, you should set them as env vars. > Really. Hm. For some reason, ld kept searching the wrong (64-bit) library paths when trying to link the 32-bit results. I just retried and now everything is fine. Mystifying. Ah well. Probably my first experiments had some stry env var set that shouldn't have been, derailing the build machinery. > > Also not that this needs to set just --build, not --host (which defaults > > to the setting of --build) nor --target (which defaults to whatever > > value --host ends up as). > > > > > > Now the ./configure in llvm-gcc4.2 will choke badly on such a command line. > > > > First, it misinterprets the CC= and CXX= strings as target architecture > > names, and continues to complain that it cannot configure for multiple > > architectures at once. > Which is why you should be setting them as env vars :) > > > > > Second, it does not default --host or --target to --build. > > This is normal. > Crappy, but normal. According to the autoconf docs, this should be everything but normal! In fact it works for llvm. It's just llvm-gcc that fails to do that right. (Checked with the config.logs of both runs.) My best guess is that something is wrong in the .ac file for llvm-gcc, and the llvm .ac file got it right. Regards, Jo From tonic at nondot.org Mon Mar 24 14:06:32 2008 From: tonic at nondot.org (Tanya M. Lattner) Date: Mon, 24 Mar 2008 12:06:32 -0700 (PDT) Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure In-Reply-To: <1206368211.7456.6.camel@kurier> References: <1206368211.7456.6.camel@kurier> Message-ID: > This is close to a showstopper for integrating an llvm-gcc bootstrap > into the nightly tester. The llvm-gcc ./configure needs to be called > very differently from the llvm ./configure, and keeping two sets of > options is Not Worth The Trouble, at least IMHO. So you didn't like the suggestion of having the configure for llvm-gcc set via an environment variable? That avoids having to deal with this directly in the script. Or am I missing something? -Tanya > > > Regards, > Jo > > P.S.: Don't worry, I'll use LLVM for my projects even if I don't manage > to bootstrap it or run the nightly tester :-D > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From jo at durchholz.org Mon Mar 24 13:47:26 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 24 Mar 2008 19:47:26 +0100 Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure In-Reply-To: <4aca3dc20803240837l18b8b246ne761df0f46abc8e3@mail.gmail.com> References: <1206368211.7456.6.camel@kurier> <4aca3dc20803240837l18b8b246ne761df0f46abc8e3@mail.gmail.com> Message-ID: <1206384446.7456.26.camel@kurier> Am Montag, den 24.03.2008, 11:37 -0400 schrieb Daniel Berlin: > > > > Third, even with --target and --host explicitly set to > > i686-pc-linux-gnu, the assembler will be fed with 64-bit code. The > > failing command is > > > > /home/jo/llvm-gcc-wrk/gcc/xgcc -B/home/jo/llvm-gcc-wrk/gcc/ > > -B/home/jo/i686-pc-linux-gnu/bin/ -B/home/jo/i686-pc-linux-gnu/lib/ > > -isystem /home/jo/i686-pc-linux-gnu/include > > -isystem /home/jo/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > > -Wold-style-definition -isystem ./include -I. -I. > > -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/. > > -I/home/jo/llvm-gcc-src/gcc/../include > > -I/home/jo/llvm-gcc-src/gcc/../libcpp/include -g0 > > -finhibit-size-directive -fno-inline-functions -fno-exceptions > > -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer > > -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O > > -o crtbeginT.o > > > > (slightly edited to leave out multiple blanks and line continuation > > backslashes). > > > > The error messages are just what I had seen earlier: > > > > /tmp/ccVjR8Qt.s: Assembler messages: > > /tmp/ccVjR8Qt.s:33: Error: suffix or operands invalid for `push' > > /tmp/ccVjR8Qt.s:43: Error: suffix or operands invalid for `call' > > /tmp/ccVjR8Qt.s:61: Error: suffix or operands invalid for `push' > > /tmp/ccVjR8Qt.s:71: Error: suffix or operands invalid for `call' > > > > This is interesting, and I wonder if it appears in gcc itself. If so, > it is a bug. The problem persists even when submitting gcc-4.2 and g++-4.2 via environment variables per your suggestion. (The failing xgcc command has slightly different options, and the reported line numbers differ slightly, but that's all.) I don't know how to check whether it appears in gcc itself. I don't have an xgcc command installed other than via llvm. Regards, Jo From basile at starynkevitch.net Mon Mar 24 14:15:26 2008 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Mon, 24 Mar 2008 20:15:26 +0100 Subject: [LLVMdev] AsmParser/Lexer.l error Message-ID: <47E7FDCE.4040703@starynkevitch.net> Hello With the latest LLVM from Subversion (rev48737 from http://llvm.org/svn/llvm-project/llvm/trunk) I'm getting make[2]: Entering directory `/usr/src/Lang/llvm/_Obj/lib/AsmParser' llvm[2]: Flexing Lexer.l llvm[2]: Compiling Lexer.cpp for Debug build /usr/src/Lang/llvm/lib/AsmParser/Lexer.l: In function 'int llvmAsmlex()': /usr/src/Lang/llvm/lib/AsmParser/Lexer.l:278: error: 'PURE' was not declared in this scope /usr/src/Lang/llvm/lib/AsmParser/Lexer.l:279: error: 'CONST' was not declared in this scope Lexer.cpp: In function 'int yy_get_next_buffer()': I'm on Debian/Sid/AMD64, build directory is /usr/src/Lang/llvm/_Obj (a subdir of the source). Even by removing /usr/src/Lang/llvm/lib/AsmParser/Lexer.cpp as suggested inhttp://lists.cs.uiuc.edu/pipermail/cfe-dev/2007-November/000483.html I'm getting the same message. I'm quite sure it is a common mistake of mine, but I thought that removing the generated /usr/src/Lang/llvm/lib/AsmParser/Lexer.cpp would be enough. flex --version :: flex 2.5.34 g++ --version :: g++ (GCC) 4.2.3 (Debian 4.2.3-2) Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From jo at durchholz.org Mon Mar 24 14:16:36 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 24 Mar 2008 20:16:36 +0100 Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure In-Reply-To: References: <1206368211.7456.6.camel@kurier> Message-ID: <1206386196.7456.38.camel@kurier> Am Montag, den 24.03.2008, 12:06 -0700 schrieb Tanya M. Lattner: > > This is close to a showstopper for integrating an llvm-gcc bootstrap > > into the nightly tester. The llvm-gcc ./configure needs to be called > > very differently from the llvm ./configure, and keeping two sets of > > options is Not Worth The Trouble, at least IMHO. > > So you didn't like the suggestion of having the configure for llvm-gcc set > via an environment variable? That avoids having to deal with this directly > in the script. Or am I missing something? No, that was written under the assumption that passing in CC and CXX via env variables wouldn't work. Things work now, so that assumption is obviously wrong. I still don't like environment variables. They tend to remain in effect long after I forgot that I set them, creating all sorts of hassle. In fact I suspect I already fell prey to this, getting llvm to compile and check one day and nearly despairing when trying to reproduce that success on the next day. But, well, you use what you need to use to get the job done, so there :-) Regards, Jo From asl at math.spbu.ru Mon Mar 24 14:34:16 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Mon, 24 Mar 2008 22:34:16 +0300 Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure In-Reply-To: <1206384061.7456.22.camel.SS1921SS@kurier> References: <1206368211.7456.6.camel@kurier> <4aca3dc20803240837l18b8b246ne761df0f46abc8e3@mail.gmail.com> <1206384061.7456.22.camel.SS1921SS@kurier> Message-ID: <1206387256.16812.206.camel@asl.dorms.spbu.ru> Hello, Joachim > Hm. For some reason, ld kept searching the wrong (64-bit) library paths > when trying to link the 32-bit results. Hrm. This looks like to be old story about 'lib vs lib32 vs lib64' directories in different distributions. Almost every of them patch gcc inside their packages to provide valid library paths. Look for example, here: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01991.html -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From baldrick at free.fr Mon Mar 24 15:11:49 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 24 Mar 2008 21:11:49 +0100 Subject: [LLVMdev] AsmParser/Lexer.l error In-Reply-To: <47E7FDCE.4040703@starynkevitch.net> References: <47E7FDCE.4040703@starynkevitch.net> Message-ID: <200803242111.50439.baldrick@free.fr> Hi, > /usr/src/Lang/llvm/lib/AsmParser/Lexer.l: In function 'int llvmAsmlex()': > /usr/src/Lang/llvm/lib/AsmParser/Lexer.l:278: error: 'PURE' was not > declared in this scope > /usr/src/Lang/llvm/lib/AsmParser/Lexer.l:279: error: 'CONST' was not > declared in this scope > Lexer.cpp: In function 'int yy_get_next_buffer()': these don't exist any more so you must have old files hanging around. > I'm on Debian/Sid/AMD64, build directory is /usr/src/Lang/llvm/_Obj (a > subdir of the source). Even by removing > /usr/src/Lang/llvm/lib/AsmParser/Lexer.cpp as suggested > inhttp://lists.cs.uiuc.edu/pipermail/cfe-dev/2007-November/000483.html > I'm getting the same message. > > I'm quite sure it is a common mistake of mine, but I thought that > removing the generated /usr/src/Lang/llvm/lib/AsmParser/Lexer.cpp would > be enough. If you do svn status it should tell you (with a ?) about files that aren't in the repository. Ciao, Duncan. From jo at durchholz.org Mon Mar 24 15:26:07 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 24 Mar 2008 21:26:07 +0100 Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure In-Reply-To: <1206387256.16812.206.camel@asl.dorms.spbu.ru> References: <1206368211.7456.6.camel@kurier> <4aca3dc20803240837l18b8b246ne761df0f46abc8e3@mail.gmail.com> <1206384061.7456.22.camel.SS1921SS@kurier> <1206387256.16812.206.camel@asl.dorms.spbu.ru> Message-ID: <1206390367.7456.42.camel@kurier> Am Montag, den 24.03.2008, 22:34 +0300 schrieb Anton Korobeynikov: > Hello, Joachim > > > Hm. For some reason, ld kept searching the wrong (64-bit) library paths > > when trying to link the 32-bit results. > Hrm. This looks like to be old story about 'lib vs lib32 vs lib64' > directories in different distributions. Almost every of them patch gcc > inside their packages to provide valid library paths. Right. However, I don't think that's the issue here. After all, it will work when CC and GCC are passed in via environment variables. Regards, Jo From dalej at apple.com Mon Mar 24 16:40:53 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 24 Mar 2008 14:40:53 -0700 Subject: [LLVMdev] Apple's GCC and .s/.S files in llvm-test (fwd) In-Reply-To: References: Message-ID: On Mar 21, 2008, at 10:59 AM, Julien Lerouge wrote: > Hello, > > Apple's GCC does not make the distinction between .s and .S files and > always run the preprocessor. From the man: > > | file.s > | Assembler code. Apple's version of GCC runs the preprocessor > on these > | files as well as those ending in .S. > | > | file.S > | Assembler code which must be preprocessed. Yes. The reason for this is that MacOS supports some non-case- sensitive filesystems, so .s and .S are not in general distinguishable. > The problem is that sometimes llc generates comments in the assembly > that look like this for x86: > > ... > pushl %esi > ... > # implicit-def: EDI > ... > ret > > The comment line is perfectly valid for the assembler, but the > preprocessor does not like it because it tries to interpret it as a > macro... I can see it happening for example if -std=c99 is set in the > CFLAGS (that's the case in SingleSource/Regression/C++) : > > $ gcc --std=c99 -o t t.s > t.s:5:4: error: invalid preprocessing directive #implicit > > One solution is to force the language to be assembler (and not > assembler-with-cpp) on Darwin, that's what the attached patch does, > but > maybe there is a nicer solution ? In general I think we want llvm-gcc's output .s files to be acceptable as input to gcc, so the right thing is to change the x86 asm printer so it doesn't generate these comments. I don't see a good way to do full-line comments that works both if you run the preprocessor and if you don't. (Using #pragma works since compilers are required to ignore unknown pragmas, but nobody would call that good.) If we're willing to build in the assumption that the preprocessor will be run, // or /**/ comments work. Or attaching them to the end of the previous line works. From mrs at apple.com Mon Mar 24 17:35:29 2008 From: mrs at apple.com (Mike Stump) Date: Mon, 24 Mar 2008 15:35:29 -0700 Subject: [LLVMdev] Apple's GCC and .s/.S files in llvm-test (fwd) In-Reply-To: References: Message-ID: <009DDBC1-7B1A-4F89-B36C-C313943A74FC@apple.com> On Mar 24, 2008, at 2:40 PM, Dale Johannesen wrote: > On Mar 21, 2008, at 10:59 AM, Julien Lerouge wrote: >> Hello, >> >> Apple's GCC does not make the distinction between .s and .S files and >> always run the preprocessor. From the man: >> >> | file.s >> | Assembler code. Apple's version of GCC runs the preprocessor >> on these >> | files as well as those ending in .S. >> | >> | file.S >> | Assembler code which must be preprocessed. > > Yes. The reason for this is that MacOS supports some non-case- > sensitive filesystems, so .s and .S are not in general > distinguishable. I'm skeptical. The case of the extension comes from the user, the user _knows_ what language the file is in. The user can be obligated to get the case right. Also, on darwin, the filenames are case preserving, meaning, the filesystem can even track the language directly as encoded by the filename, .s, no cpp, .S, run cpp. I'm be tempted to eject this and see what breaks, then get them to fix it. From evan.cheng at apple.com Mon Mar 24 18:37:02 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 24 Mar 2008 16:37:02 -0700 Subject: [LLVMdev] a quick typo in the ARM LLVM backend In-Reply-To: References: Message-ID: Committed. Thanks! Evan On Mar 23, 2008, at 4:39 AM, Jay Freeman (saurik) wrote: > So, a while back I got a compile error where the assembly was > missing some whitespace between a .set and the identifier and > tracked it down to this simple mistake that I just verified is still > in the tree: > > Index: lib/Target/ARM/ARMTargetAsmInfo.cpp > =================================================================== > --- lib/Target/ARM/ARMTargetAsmInfo.cpp (revision 48700) > +++ lib/Target/ARM/ARMTargetAsmInfo.cpp (working copy) > @@ -49,7 +49,7 @@ > PrivateGlobalPrefix = "L"; > BSSSection = 0; // no BSS section. > ZeroFillDirective = "\t.zerofill\t"; // Uses .zerofill > - SetDirective = "\t.set"; > + SetDirective = "\t.set\t"; > WeakRefDirective = "\t.weak_reference\t"; > HiddenDirective = "\t.private_extern\t"; > ProtectedDirective = NULL; > I unfortunately don't have the code that died anymore (it was a > couple months ago, and I'm unfortunately just now getting on this > mailing list to report the issue), but it seems pretty obvious from > the surrounding context to be wrong, and there's even another > initialization of SetDirective in the same file that _does_ have the > traililng \t. > > Sincerely, > Jay Freeman (saurik) > saurik at saurik.com > http://www.saurik.com/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080324/fe2832e3/attachment.html From evan.cheng at apple.com Mon Mar 24 18:42:56 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 24 Mar 2008 16:42:56 -0700 Subject: [LLVMdev] Adding SQLite3 to llvm test-suite In-Reply-To: <47E523BF.7040200@gmail.com> References: <47E523BF.7040200@gmail.com> Message-ID: <3436D44D-3305-4886-96CE-92ACE46368D9@apple.com> Hi Edwin, It works fine for me. Thanks! We prefer a flat directory structure. Is it possible for you to separate it out to sqlite3 and lemon rather than having them as sub- directories under SQLite? Also, can you increase lemon's test size? Please file bug about the performance issue. Thanks! Evan On Mar 22, 2008, at 8:20 AM, T?r?k Edwin wrote: > Hi, > > SQLite3 has a very simple build system, and it comes with an extensive > testsuite (over 40000 tests). > It hasn't shown any bugs in LLVM, but it is fairly simple to build > [even > turn off features via -D], and can be CPU intensive. > > I have integrated SQLite3 into llvm-test's build system, it is too > large > to send as attachment (784K), you can get it from here: > http://edwintorok.googlepages.com/SQLite_llvm_test.tar.gz > > The testsuite is using tcl, and needs tcl headers available at > build-time so I didn't add that [they are mostly I/O bound anyway] > Instead I found a "speedtest" script in the sqlite distribution. I > modified it to generate sql files instead of directly running sqlite. > > The results are here, LLVM is ~20% slower than GCC: > > 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 > lemon/lemon | 0.3833 149404 0.5699 * > 0.5166 | 0.04 0.04 0.05 * 0.62 | - - > n/a n/a > sqlite3/sqlite3 | 4.8063 1744588 5.3996 * > 3.7497 | 7.09 8.19 8.78 * 13.68 | 0.87 0.81 > n/a n/a > > There are more speedtest scripts in its testsuite, but the generated > sql > is large (>10 Mb), and I think the above shows a clear difference > between LLVM and GCC. > > Can somebody please review and commit this to llvm-test? > > 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 evan.cheng at apple.com Mon Mar 24 18:45:34 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 24 Mar 2008 16:45:34 -0700 Subject: [LLVMdev] Use of flags in selection dags In-Reply-To: <47E2935D.6030109@gmail.com> References: <47E1484D.7030600@gmail.com> <200803191847.53408.baldrick@free.fr> <47E2935D.6030109@gmail.com> Message-ID: On Mar 20, 2008, at 9:39 AM, Bagel wrote: > Duncan Sands wrote: >>> Can someone tell me, or point me to documentation, that explains >>> the use >>> of "flags" in the selection DAG? I figured out that, if one is >>> present, it must be the last operand. But when are "flags" used >>> and why? >>> >> >> Please give details of the context, such as the kind of node you >> are looking at. >> >> Thanks, >> >> Duncan. >> > I'm looking at this in general as one would when writing patterns > for a > new machine. It appears that flags are used in patterns that use or > set > condition codes. Is this because the condition code register is not > modelled or is it more that the dags can't handle two outputs. I just > want to know what the rules are on when and how to use "flags". X86 does model condition register as a "physical register output". But other targets model them as flags. The later restrict scheduling freedom. But if you don't care that much about it, it's easier to get right. Flags are also used in other cases when you want to ensure the instructions translated from the two selectiondag nodes are scheduled at the same time. Evan > > > Thanks, > Bagel > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From christopher.lamb at gmail.com Mon Mar 24 23:17:22 2008 From: christopher.lamb at gmail.com (Christopher Lamb) Date: Mon, 24 Mar 2008 21:17:22 -0700 Subject: [LLVMdev] What is "strong phi elimination" Message-ID: Can you describe quickly (or point to references for the inclined) what this pass will do and what other stuff it might enable for LLVM? I'm just curious. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080324/46829334/attachment.html From resistor at mac.com Mon Mar 24 23:22:25 2008 From: resistor at mac.com (Owen Anderson) Date: Mon, 24 Mar 2008 23:22:25 -0500 Subject: [LLVMdev] What is "strong phi elimination" In-Reply-To: References: Message-ID: <634E6E7E-CEF5-4E54-AEB8-E2973CC89298@mac.com> Ask an ye shall receive. From the .cpp file: // = = =---------------------------------------------------------------------- ===// // // This pass eliminates machine instruction PHI nodes by inserting copy // instructions, using an intelligent copy-folding technique based on // dominator information. This is technique is derived from: // // Budimlic, et al. Fast copy coalescing and live-range identification. // In Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language // Design and Implementation (Berlin, Germany, June 17 - 19, 2002). // PLDI '02. ACM, New York, NY, 25-32. // DOI= http://doi.acm.org/10.1145/512529.512534 // // = = =---------------------------------------------------------------------- ===// Basically, it's PHI elimination with built-in coallescing. --Owen On Mar 24, 2008, at 11:17 PM, Christopher Lamb wrote: > Can you describe quickly (or point to references for the inclined) > what this pass will do and what other stuff it might enable for > LLVM? I'm just curious. > > -- > Christopher Lamb > > > -------------- 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/20080324/de4a380b/attachment-0001.bin From daveed at vandevoorde.com Mon Mar 24 17:18:03 2008 From: daveed at vandevoorde.com (David Vandevoorde) Date: Mon, 24 Mar 2008 18:18:03 -0400 Subject: [LLVMdev] Apple's GCC and .s/.S files in llvm-test (fwd) In-Reply-To: References: Message-ID: <615FE299-083C-4CC3-BFB7-3D164CC7607B@vandevoorde.com> On Mar 24, 2008, at 5:40 PM, Dale Johannesen wrote: [...] > I don't see a good way to do > full-line comments that works both if you run the preprocessor and if > you don't. Could you use "##" instead of "#"? Daveed From sabre at nondot.org Mon Mar 24 23:43:06 2008 From: sabre at nondot.org (Chris Lattner) Date: Mon, 24 Mar 2008 21:43:06 -0700 Subject: [LLVMdev] What is "strong phi elimination" In-Reply-To: <634E6E7E-CEF5-4E54-AEB8-E2973CC89298@mac.com> References: <634E6E7E-CEF5-4E54-AEB8-E2973CC89298@mac.com> Message-ID: <23300B67-4C63-4C0D-9117-5BD38AB90E0B@nondot.org> On Mar 24, 2008, at 9:22 PM, Owen Anderson wrote: > Ask an ye shall receive. From the .cpp file: > Basically, it's PHI elimination with built-in coallescing. You mean "coalescing" (tips hat to Gabor :). Another way to look at it is that it is the "normal" SSA phi elimination algorithm, which is normally implemented in terms of an interference graph, without the IG. Not using an IG saves having to build an awful N^2 data structure, which is possible through clever use of SSA properties. -Chris From lee225 at uiuc.edu Tue Mar 25 00:25:49 2008 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Tue, 25 Mar 2008 00:25:49 -0500 (CDT) Subject: [LLVMdev] What is "strong phi elimination" Message-ID: <20080325002549.BDK51223@expms2.cites.uiuc.edu> Do you mean that "normal" SSA phi elimination algorithm is DemotePHI()? Thx, Seung ---- Original message ---- >Date: Mon, 24 Mar 2008 21:43:06 -0700 >From: Chris Lattner >Subject: Re: [LLVMdev] What is "strong phi elimination" >To: LLVM Developers Mailing List >Cc: Christopher Lamb > > >On Mar 24, 2008, at 9:22 PM, Owen Anderson wrote: >> Ask an ye shall receive. From the .cpp file: >> Basically, it's PHI elimination with built-in coallescing. > >You mean "coalescing" (tips hat to Gabor :). > >Another way to look at it is that it is the "normal" SSA phi >elimination algorithm, which is normally implemented in terms of an >interference graph, without the IG. Not using an IG saves having to >build an awful N^2 data structure, which is possible through clever >use of SSA properties. > >-Chris > >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From christopher.lamb at gmail.com Tue Mar 25 00:47:05 2008 From: christopher.lamb at gmail.com (Christopher Lamb) Date: Mon, 24 Mar 2008 22:47:05 -0700 Subject: [LLVMdev] Whole-function isel Message-ID: <252D6A2B-5F7D-46BA-9239-29612BFE7A20@gmail.com> I know that this has been discussed (at least in passing) a few times on the list, but I couldn't locate a bug for it. Have any architectural plans been made for it? Are there architectural roadblocks with the current LLVM infrastructure that will complicate the process? What has demotivated the implementation of this so far (is it not that big a benefit on important targets, too much time/effort for the payoff)? In toying with some code generators I've been frustrated in getting the code gen prepare pass + isel to implement the heuristics I need to match some addressing modes and I believe that whole-function isel might be the answer. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080324/398aa7b8/attachment.html From christopher.lamb at gmail.com Tue Mar 25 00:54:16 2008 From: christopher.lamb at gmail.com (Christopher Lamb) Date: Mon, 24 Mar 2008 22:54:16 -0700 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <696bc1d50803212122x3e81883au708e27ff3fa48d6d@mail.gmail.com> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> <200803190939.36482.baldrick@free.fr> <3DF6E7B9-6E5A-4A73-A379-8A1858F8A7E1@apple.com> <200803201805.47745.baldrick@free.fr> <696bc1d50803212122x3e81883au708e27ff3fa48d6d@mail.gmail.com> Message-ID: <4FFDA726-21AE-4946-9CB4-E82C956EEB08@gmail.com> Another suggestion: a web service that would allow you to submit a test build and it would provide you feedback on deviations from known good for that target. I know a lot of people keep two trees around for this purpose, and I'd personally like to ditch the duplicate if I could. -- Chris On Mar 21, 2008, at 9:22 PM, Rajika Kumarasiri wrote: > Hello every body, > Thank you all for your great suggestions and feedbacks, I'd forward > the detailed proposal within couple of days. And also if I need to > clarify any thing I'll ask in the list. Thanks again. > Regards, > Rajika > > On Thu, Mar 20, 2008 at 10:35 PM, Duncan Sands > wrote: > While on the subject of the testsuite, some random thoughts: > > - show how test results changed from one week and one month > ago, and compared to the last release, rather than just > comparing with the previous run as now. Good for spotting > trends. > - fix the testsuite so that buildlogs are really available: > I occasionally see that a nightly tester failed the build, and > in the message it gives a url where you can get the build log. > Only the logs aren't there... > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > comp.lang.c - http://groups.google.com/group/comp.lang.c/topics > _______________________________________________ > 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/20080324/0e2bdad6/attachment.html From sabre at nondot.org Tue Mar 25 00:55:39 2008 From: sabre at nondot.org (Chris Lattner) Date: Mon, 24 Mar 2008 22:55:39 -0700 Subject: [LLVMdev] What is "strong phi elimination" In-Reply-To: <20080325002549.BDK51223@expms2.cites.uiuc.edu> References: <20080325002549.BDK51223@expms2.cites.uiuc.edu> Message-ID: <7BC38E3A-48E4-4AEB-8490-EE56B3790352@nondot.org> On Mar 24, 2008, at 10:25 PM, Seung Jae Lee wrote: > Do you mean that "normal" SSA phi elimination algorithm is > DemotePHI()? No, DemotePHI doesn't build an interference graph, and is not part of the code generator. -Chris From clattner at apple.com Tue Mar 25 01:38:18 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 24 Mar 2008 23:38:18 -0700 Subject: [LLVMdev] Whole-function isel In-Reply-To: <252D6A2B-5F7D-46BA-9239-29612BFE7A20@gmail.com> References: <252D6A2B-5F7D-46BA-9239-29612BFE7A20@gmail.com> Message-ID: On Mar 24, 2008, at 10:47 PM, Christopher Lamb wrote: > I know that this has been discussed (at least in passing) a few > times on the list, but I couldn't locate a bug for it. Have any > architectural plans been made for it? Funny you bring this up. Evan and I were tossing around crazy ideas about this just today. If you're interested, maybe we should get together for lunch or coffee or something. > Are there architectural roadblocks with the current LLVM > infrastructure that will complicate the process? What has > demotivated the implementation of this so far (is it not that big a > benefit on important targets, too much time/effort for the payoff)? There is a huge payoff to doing this or even making progress on it. It is an elegant solution to many issues. There are two current problems: 1) There are some scalability issues (in compile time) with large selectiondags. Roman has been tackling this recently, so this will hopefully be a non-issue really soon. In any case, it would be very reasonable continue doing single MBB selectiondags when in "-fast" mode (i.e. -O0) and do whole function ones when compile time is worth it (-O2+ etc). 2) The bigger issue is one of scheduling. The great thing about whole function isel is that nothing up to scheduling needs to care about what block something is in (as long as chain nodes pin side-effecting instrs to their block of course). Things like machine-code loop invariant code motion, CSE of values from different blocks, sinking and many other details are easily handled, and directly in the selection dags: this is really cool! :) The problem is that *something has to decide what block to put all the operations in. The most logical thing to do here is to have a pass either part of sched or right before it that assigns a block to each node (which is a target instr node) and then have sched remain a single-bb at a time (for now, it could obviously be improved later to work on traces etc). The problem is that in full generality, this is a problem very similar to PRE: assigning blocks to operations optimally is complex and somewhat subtle. An excellent place to start looking at this is Cliff Click's thesis, which is available online (and incidentally inspired a lot of selection dag design). In his thesis, he has a hacky solution that is probably good enough, certainly to start out with. The reason this hasn't been done so far is that we (people at apple) haven't been able to justify the "big project" of tackling this when there are still tons of little projects that are lower hanging for our needs. We will almost certainly do this someday (and would have already done it if it were blocking some project of ours), but would love to have someone work on it in the shorter term. The thing that Evan and I were discussing today is that there are a variety of ways to get intermediate results without tackling the full generality of the problem: 1) One annoying problem for targets like PPC and ARM (which promote i8/ i16 to i32) can be solved with a really simple hack. Consider a switch on i16 that codegens to a branch tree. This turns into a bunch of small blocks: the first zext's the value then does an unsigned comparison against the range typically, and each subsequent block does an unsigned comparison against the subportion of the range. The problem is that right now, the subsequent comparisons just see that the i16 value is promoted, which means the top bits are unknown. This means that each block ends up doing tons of redundant "and"s to clear out the top bits before their comparison. This is obviously a special case of a general problem: uses of values in blocks that aren't the def can't see properties of the value. This (and similar problems) boil down to not knowing info about a cross-block promoted value. This sort of thing can be solved with a very simple hack by adding a few maps to SDISel. The idea is that, in ISel, each cross-block CopyToReg for a Vreg can call ComputeMaskedBits and ComputeSignBits and record the known live out bit+sign information for the vreg. Later, if someone calls ComputeMaskedBits or ComputeSignBits and it recurses up to a CopyFromReg from the vreg, the information can be provided from its definition. This elegantly and cheaply solves the problem. The reason I call it a hack is that it means you get different code for a function based on the order that blocks are selected (i.e. it is better to compile the defs of values before the uses), which is annoying, but actually probably just fine in practice. Codegen remains deterministic of course. 2) An intermediate step to whole function isel is to do region based isel with regions limited by what makes the sched problem simple. One very interesting class of region is a Single-Entry-Multiple-Exit region. It would be straight-forward to break each function into SEME regions and select them one at a time, allowing them to compile to multiple MBBs. In addition to the obvious dag combiner and isel improvements that would come from larger regions, SEME regions encapsulate a number of interesting things (such as switch lowering). Having SEME regions would allow us to remove the block juggling in SDISel: switches would just lower to multiple blocks in one dag. SEME regions are also totally trivial for the sched problem: because your region is just a tree, all you have to do is move a computation "up" the tree towards the root to the place that dominates all its uses. Another interesting thing about SEME regions is that you don't have to worry about phi nodes etc. OTOH, SEME regions are still limiting, so we would eventually want to do whole function (or at least "arbitrary region") isel. SEME regions do handle "sinking" well, but don't handle LICM (because you can't have a whole loop in the region) and don't handle the diamond pattern than "select" lowers to when a target doesn't support cmov. Wouldn't it be nice if legalize could lower select directly for targets (by inserting blocks into the DAG), instead of having to do the "custom sched inserter" hack? :) Wouldn't it be nice if dag combine could actually itself form cmovs from diamond shapes in the cfg? :) At the end of the day, attacking a subclass of the "big problem" is a really interesting way (to me) to incrementally tackle this problem, and I strongly encourage anyone interested in this to start with SEME regions first. This allows us to figure out things like "how do we represent the start of a bb" (probably a new chained node), "how does the sched pass set the block that an instruction goes in" (probably a new field in SDNode), and allows us to do some cleanups (e.g. switch lowering) without tackling some of the other hard problems. Once SEME regions are working really well, we can tackle the rest of the hard problems, because they are obviously worthwhile doing eventually. > In toying with some code generators I've been frustrated in getting > the code gen prepare pass + isel to implement the heuristics I need > to match some addressing modes and I believe that whole-function > isel might be the answer. I would love to see any progress in this area. It is clearly an important thing to tackle, and it is blocking other interesting improvements in the code generator. It would also allow us to eliminate a significant amount of weirdness that exists to hack around this (e.g. switch lowering). That said, even when we *can* do whole function isel, I think we should keep the ability to handle subregions of the function for -O0, at least until SD stuff scales perfectly :). -Chris From chandlerc at gmail.com Tue Mar 25 01:49:05 2008 From: chandlerc at gmail.com (Chandler Carruth) Date: Mon, 24 Mar 2008 23:49:05 -0700 Subject: [LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64 Message-ID: <18edb2ad0803242349h19382b18o710cd06d80945b04@mail.gmail.com> Hello, Trying to get my machine building up-to-date, and a nightly going, i ran into an assertion during the build of llvm-gcc 4.2: $ make -j2 /home/chandlerc/code/compilers/build/llvm-gcc/./gcc/xgcc -B/home/chandlerc/code/compilers/build/llvm-gcc/./gcc/ -B/home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux-gnu/bin/ -B/home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux-gnu/lib/ -isystem /home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux-gnu/include -isystem /home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux-gnu/sys-include -O2 -O2 -march=k8 -mfpmath=sse -pipe -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I/home/chandlerc/code/compilers/llvm-gcc/gcc -I/home/chandlerc/code/compilers/llvm-gcc/gcc/. -I/home/chandlerc/code/compilers/llvm-gcc/gcc/../include -I/home/chandlerc/code/compilers/llvm-gcc/gcc/../libcpp/include -I/home/chandlerc/code/compilers/llvm-gcc/gcc/../libdecnumber -I../libdecnumber -I/home/chandlerc/code/compilers/llvm/include -I/home/chandlerc/code/compilers/build/llvm/include -DL_powitf2 -c /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c -o libgcc/./_powitf2.o cc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): Assertion `(!(__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size) || !Ty->isSized() || !isInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) == getTargetData().getABITypeSizeInBits(Ty)) && "LLVM type size doesn't match GCC type size!"' failed. /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c: In function '__powixf2': /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c:1765: internal compiler error: Aborted My configure: .../configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/home/chandlerc/code/compilers/install/llvm-gcc --disable-multilib --disable-shared --enable-llvm=/home/chandlerc/code/compilers/build/llvm --program-prefix=llvm- --enable-languages=c,c++ If more information would help, just let me know. -Chandler From gabor at mac.com Tue Mar 25 02:28:50 2008 From: gabor at mac.com (Gabor Greif) Date: Tue, 25 Mar 2008 08:28:50 +0100 Subject: [LLVMdev] test/Transforms/DecomposeMultiDimRefs References: 252D6A2B-5F7D-46BA-9239-29612BFE7A20@gmail.com Message-ID: <47E8A9B2.4050007@mac.com> Looks like this suite is pretty empty :-) May I delete it or should it be beefed up some time? Cheers, Gabor From isanbard at gmail.com Tue Mar 25 02:51:00 2008 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 25 Mar 2008 00:51:00 -0700 Subject: [LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64 In-Reply-To: <18edb2ad0803242349h19382b18o710cd06d80945b04@mail.gmail.com> References: <18edb2ad0803242349h19382b18o710cd06d80945b04@mail.gmail.com> Message-ID: <8E416D69-4749-4231-8279-F733E2645265@gmail.com> Hi Chandler, This looks like a FE error, so you probably won't be able to get an LLVM bitcode file for us. You could help by whittling the test case down to something managable. First get a preprocessed file. Then I would suggest following the instructions on this page to reduce the testcase: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction That will help us a lot with the bug report. -bw On Mar 24, 2008, at 11:49 PM, Chandler Carruth wrote: > Hello, > > Trying to get my machine building up-to-date, and a nightly going, i > ran into an assertion during the build of llvm-gcc 4.2: > > $ make -j2 > > /home/chandlerc/code/compilers/build/llvm-gcc/./gcc/xgcc > -B/home/chandlerc/code/compilers/build/llvm-gcc/./gcc/ > -B/home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux- > gnu/bin/ > -B/home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux- > gnu/lib/ > -isystem /home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc- > linux-gnu/include > -isystem /home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc- > linux-gnu/sys-include > -O2 -O2 -march=k8 -mfpmath=sse -pipe -DIN_GCC -W -Wall > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -fPIC -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. > -I/home/chandlerc/code/compilers/llvm-gcc/gcc > -I/home/chandlerc/code/compilers/llvm-gcc/gcc/. > -I/home/chandlerc/code/compilers/llvm-gcc/gcc/../include > -I/home/chandlerc/code/compilers/llvm-gcc/gcc/../libcpp/include > -I/home/chandlerc/code/compilers/llvm-gcc/gcc/../libdecnumber > -I../libdecnumber -I/home/chandlerc/code/compilers/llvm/include > -I/home/chandlerc/code/compilers/build/llvm/include -DL_powitf2 -c > /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c -o > libgcc/./_powitf2.o > cc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: > const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): > Assertion `(!(__extension__ ({ const tree __t = (Tr); if > (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != > (tcc_type)) tree_class_check_failed (__t, (tcc_type), > "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, > __FUNCTION__); __t; })->type.size) || !Ty->isSized() || > !isInt64((__extension__ ({ const tree __t = (Tr); if > (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != > (tcc_type)) tree_class_check_failed (__t, (tcc_type), > "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, > __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ > ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) > (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, > (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm- > types.cpp", > 81, __FUNCTION__); __t; })->type.size), true) == > getTargetData().getABITypeSizeInBits(Ty)) && "LLVM type size doesn't > match GCC type size!"' failed. > /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c: In function > '__powixf2': > /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c:1765: internal > compiler error: Aborted > > My configure: > .../configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu > --target=x86_64-pc-linux-gnu > --prefix=/home/chandlerc/code/compilers/install/llvm-gcc > --disable-multilib --disable-shared > --enable-llvm=/home/chandlerc/code/compilers/build/llvm > --program-prefix=llvm- --enable-languages=c,c++ > > If more information would help, just let me know. > > -Chandler > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From pertti.kellomaki at tut.fi Tue Mar 25 05:22:45 2008 From: pertti.kellomaki at tut.fi (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=) Date: Tue, 25 Mar 2008 12:22:45 +0200 Subject: [LLVMdev] LLVM Python binding In-Reply-To: <3f49a9f40803201438l2e0b48c2hb89c04703f82f2f6@mail.gmail.com> References: <47E17AA9.5080309@gmail.com> <3f49a9f40803201438l2e0b48c2hb89c04703f82f2f6@mail.gmail.com> Message-ID: <47E8D275.8090800@tut.fi> OvermindDL1 wrote: > because of the sheer size of LLVM I may use a code generator > to generate the basics For what it is worth, I have had a good experience using the Py++ binding generator in another project. -- Pertti From llvmdev at gmail.com Tue Mar 25 05:45:57 2008 From: llvmdev at gmail.com (Sanjiv Gupta) Date: Tue, 25 Mar 2008 16:15:57 +0530 Subject: [LLVMdev] 16 bit integers In-Reply-To: References: <200803190911.23561.baldrick@free.fr> Message-ID: <56aaf0ef0803250345t507cdcf8u785fd2fac564c8e0@mail.gmail.com> I was able to build and play with clang today. Clang also promotes integer arithmetic to 32-bit. Any pointers on how to tweak it so that it generate i16 for "int" and also promote int operations to 16-bit operations only? Thanks, Sanjiv On 3/20/08, Chris Lattner wrote: > > On Wed, 19 Mar 2008, Duncan Sands wrote: > >> How can I build the front-end to generate 16-bit integers? > > > > Please clarify your question. > > If you are asking how to build llvm-gcc for a 16 bit target, > > I think the answer is: (1) gcc itself doesn't support 16 bit > > targets; (2) llvm doesn't currently support any 16 bit targets > > (but could with a little work). So you are out of luck unless > > you are willing to work on it. > > Note that if you only care about C/ObjC (not C++, fortran, ada, etc) that > clang may be a good option for you. > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080325/3c2646a5/attachment.html From rajikacc at gmail.com Tue Mar 25 06:05:22 2008 From: rajikacc at gmail.com (Rajika Kumarasiri) Date: Tue, 25 Mar 2008 16:35:22 +0530 Subject: [LLVMdev] Proposal for GSoC project for improving llvm-test testsuite In-Reply-To: <4FFDA726-21AE-4946-9CB4-E82C956EEB08@gmail.com> References: <696bc1d50803182152k39efe982uec66ed05a5099c6f@mail.gmail.com> <200803190939.36482.baldrick@free.fr> <3DF6E7B9-6E5A-4A73-A379-8A1858F8A7E1@apple.com> <200803201805.47745.baldrick@free.fr> <696bc1d50803212122x3e81883au708e27ff3fa48d6d@mail.gmail.com> <4FFDA726-21AE-4946-9CB4-E82C956EEB08@gmail.com> Message-ID: <696bc1d50803250405r5cd8c158w9717a02b5fb6ef27@mail.gmail.com> This will seems to be a very interesting and also very useful, suggesstion. I'll add this also for the GSoC propsal since I have some experince in web services. We can defeniitely use Axis2/C[1] web service frame work for this purpose. Thanks! Regards , Rajika [1] - http://ws.apache.org/axis2/c/ On Tue, Mar 25, 2008 at 11:24 AM, Christopher Lamb < christopher.lamb at gmail.com> wrote: > Another suggestion: a web service that would allow you to submit a test > build and it would provide you feedback on deviations from known good for > that target. I know a lot of people keep two trees around for this purpose, > and I'd personally like to ditch the duplicate if I could. > > -- > Chris > > On Mar 21, 2008, at 9:22 PM, Rajika Kumarasiri wrote: > > Hello every body, > Thank you all for your great suggestions and feedbacks, I'd forward the > detailed proposal within couple of days. And also if I need to clarify any > thing I'll ask in the list. Thanks again. > Regards, > Rajika > > On Thu, Mar 20, 2008 at 10:35 PM, Duncan Sands wrote: > > > While on the subject of the testsuite, some random thoughts: > > > > - show how test results changed from one week and one month > > ago, and compared to the last release, rather than just > > comparing with the previous run as now. Good for spotting > > trends. > > - fix the testsuite so that buildlogs are really available: > > I occasionally see that a nightly tester failed the build, and > > in the message it gives a url where you can get the build log. > > Only the logs aren't there... > > > > Ciao, > > > > Duncan. > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > comp.lang.c - http://groups.google.com/group/comp.lang.c/topics > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > -- > Christopher Lamb > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- comp.lang.c - http://groups.google.com/group/comp.lang.c/topics -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080325/2be737b8/attachment-0001.html From ralph at inputplus.co.uk Tue Mar 25 07:08:30 2008 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 25 Mar 2008 12:08:30 +0000 Subject: [LLVMdev] Potential breakage in llvm-gcc's ./configure In-Reply-To: <1206386196.7456.38.camel@kurier> References: <1206368211.7456.6.camel@kurier> <1206386196.7456.38.camel@kurier> Message-ID: <20080325120830.58D9043E2@blake.inputplus.co.uk> Hi Jo, > No, that was written under the assumption that passing in CC and CXX > via env variables wouldn't work. Things work now, so that assumption > is obviously wrong. > > I still don't like environment variables. They tend to remain in > effect long after I forgot that I set them, creating all sorts of > hassle. In fact I suspect I already fell prey to this, getting llvm to > compile and check one day and nearly despairing when trying to > reproduce that success on the next day. But, well, you use what you > need to use to get the job done, so there :-) Are you aware that FOO=bar ./configure makes the shell set an environment variable just for the running of ./configure, i.e. it isn't an envvar in your shell as FOO=bar; export FOO ./configure would do. But it still an envvar, unlike ./configure FOO=bar It may help. $ env | grep FOO $ FOO=bar env | grep FOO FOO=bar $ Cheers, Ralph. From jo at durchholz.org Tue Mar 25 07:47:15 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 25 Mar 2008 13:47:15 +0100 Subject: [LLVMdev] Environment variables considered evil In-Reply-To: <20080325120830.58D9043E2@blake.inputplus.co.uk> References: <1206368211.7456.6.camel@kurier> <1206386196.7456.38.camel@kurier> <20080325120830.58D9043E2@blake.inputplus.co.uk> Message-ID: <1206449235.7728.15.camel@kurier> Am Dienstag, den 25.03.2008, 12:08 +0000 schrieb Ralph Corderoy: > > No, that was written under the assumption that passing in CC and CXX > > via env variables wouldn't work. Things work now, so that assumption > > is obviously wrong. > > > > I still don't like environment variables. They tend to remain in > > effect long after I forgot that I set them, creating all sorts of > > hassle. In fact I suspect I already fell prey to this, getting llvm to > > compile and check one day and nearly despairing when trying to > > reproduce that success on the next day. But, well, you use what you > > need to use to get the job done, so there :-) > > Are you aware that > > FOO=bar ./configure > > makes the shell set an environment variable just for the running of > ./configure, I am. I'm not sure that FOO=bar BAZ=boo ./configure will work; at least I got some funny results (though that may have been due to other reasons). Well, you live and learn. I have now switched to opening a new shell window whenever I start an experiment, since gcc won't become environment-agnostic in my lifetime anyway. Though that's bad. If some overambitious sysadmin adds a CFLAGS variable to /etc/profile, people on that machine will get funny results. To make matters worse, there does not seem to be an exhaustive list of environment variables to check, at least not for gcc and autoconf (though there are plenty of non-exhaustive ones). I know I have to check CC, CXX, CCFLAGS, CPPFLAGS, CXXFLAGS, and LDFLAGS; does an ASFLAGS exist? A RANLIBFLAGS? ARFLAGS? (This is essentially the same problem as with global variables: lack of information hiding, making it very difficult to check all dependencies.) I'm pretty sure that I'm not the first to observe this kind of difficulty, and the GNU project probably won't change their conventions anyway, I'll stop my rant now :-) Regards, Jo From ebner at complang.tuwien.ac.at Tue Mar 25 11:40:29 2008 From: ebner at complang.tuwien.ac.at (Dietmar Ebner) Date: Tue, 25 Mar 2008 17:40:29 +0100 Subject: [LLVMdev] Whole-function isel In-Reply-To: References: <252D6A2B-5F7D-46BA-9239-29612BFE7A20@gmail.com> Message-ID: <47E92AFD.7010104@complang.tuwien.ac.at> Chris, Chris Lattner wrote: > I would love to see any progress in this area. It is clearly an > important thing to tackle, and it is blocking other interesting > improvements in the code generator. It would also allow us to > eliminate a significant amount of weirdness that exists to hack around > this (e.g. switch lowering). we've been working on a whole-function instruction selector here at the vienna university of technology in the recent past. our approach considers ssa graphs and is based on a problem transformation to a specialized quadratic assignment problem (pbqp). in contrast to previous work [1], the technique is flexible enough to cope with general DAG patterns such as pre/postincrement or divmod patterns. the instruction selector is a drop-in replacement for the original implementation (llvm 2.1). we've used the ARM backend for evaluation and obtained quite encouraging results: speedups are up to 10% for SPEC/Mibench and up to 57% for simple loop kernels. the compile time increase is about a factor of 2. the paper has been accepted for this year's LCTES conference (june 12-13, tucson, az). i'm afraid i cannot post it on the list but i'm happy to send a preliminary version to anybody who's interested. the implementation is not yet as efficient as it could be (e.g., we maintain an additional datastructure for the ssa graph along with the selection DAG) and i'm afraid there are licensing issues that do not allow me to directly post or contribute the code. however, i'm happy to share further experimental results and discuss the approach in case somebody is interested. - dietmar [1] Erik Eckstein, Oliver K?nig and Bernhard Scholz Code Instruction Selection Based on SSA-Graphs SCOPES 2003 http://springerlink.metapress.com/content/83cj0ebgtm998hj8 -- --------------------------------------------------------------------- Dietmar Ebner CD Laboratory - Compilation Techniques for Embedded Processors Institut fuer Computersprachen E: ebner at complang.tuwien.ac.at Technische Universitaet Wien F: (+431) 58801-18598 Argentinierstrasse 8 / E1851 T: (+431) 58801-58521 1040 Wien, Austria W: www.complang.tuwien.ac.at/cd/ebner From dalej at apple.com Tue Mar 25 12:08:58 2008 From: dalej at apple.com (Dale Johannesen) Date: Tue, 25 Mar 2008 10:08:58 -0700 Subject: [LLVMdev] Apple's GCC and .s/.S files in llvm-test (fwd) In-Reply-To: <615FE299-083C-4CC3-BFB7-3D164CC7607B@vandevoorde.com> References: <615FE299-083C-4CC3-BFB7-3D164CC7607B@vandevoorde.com> Message-ID: <37C04C17-E1D5-4FC3-B880-79627A64ACDF@apple.com> On Mar 24, 2008, at 3:18 PM, David Vandevoorde wrote: > > On Mar 24, 2008, at 5:40 PM, Dale Johannesen wrote: > [...] >> I don't see a good way to do >> full-line comments that works both if you run the preprocessor and if >> you don't. > > > Could you use "##" instead of "#"? Pragmatically, that works (as I'm sure you know). Digging into the legalities of C99 I'm not sure that it's guaranteed to work, though. Unknown directives actually match the "non-directive" case in the grammar in 6.10; while nothing is said anywhere about semantics that I can find, I'm not sure why gcc feels this should be a hard error at all.... From sabre at nondot.org Tue Mar 25 12:43:13 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 25 Mar 2008 10:43:13 -0700 (PDT) Subject: [LLVMdev] test/Transforms/DecomposeMultiDimRefs In-Reply-To: <47E8A9B2.4050007@mac.com> References: 252D6A2B-5F7D-46BA-9239-29612BFE7A20@gmail.com <47E8A9B2.4050007@mac.com> Message-ID: On Tue, 25 Mar 2008, Gabor Greif wrote: > Looks like this suite is pretty empty :-) > May I delete it or should it be beefed up some time? Please delete it, that pass is long gone. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From daveed at vandevoorde.com Tue Mar 25 13:04:19 2008 From: daveed at vandevoorde.com (David Vandevoorde) Date: Tue, 25 Mar 2008 14:04:19 -0400 Subject: [LLVMdev] Apple's GCC and .s/.S files in llvm-test (fwd) In-Reply-To: <37C04C17-E1D5-4FC3-B880-79627A64ACDF@apple.com> References: <615FE299-083C-4CC3-BFB7-3D164CC7607B@vandevoorde.com> <37C04C17-E1D5-4FC3-B880-79627A64ACDF@apple.com> Message-ID: On Mar 25, 2008, at 1:08 PM, Dale Johannesen wrote: > > On Mar 24, 2008, at 3:18 PM, David Vandevoorde wrote: > >> >> On Mar 24, 2008, at 5:40 PM, Dale Johannesen wrote: >> [...] >>> I don't see a good way to do >>> full-line comments that works both if you run the preprocessor and >>> if >>> you don't. >> >> >> Could you use "##" instead of "#"? > > Pragmatically, that works (as I'm sure you know). Digging into the > legalities of C99 I'm not sure that it's guaranteed to work, though. > Unknown directives actually match the "non-directive" case in the > grammar in 6.10; while nothing is said anywhere about semantics that I > can find, I'm not sure why gcc feels this should be a hard error at > all.... "##" is a punctuator (6.4.6) and therefore a preprocessing token of its own (6.4/1). A line that starts with "##" is therefore a text-line in 6.10/1 parlance (i.e., it doesn't match the "# non-directive" rule), and so yes, I think it's guaranteed to work on the preprocessor side of things. (I know next to nothing about the assembler side of things.) I don't know either why GCC faults non-directive "# ..." cases. Maybe it's a C89 leftover, or maybe it has to do with the older "# " forms. Daveed From sabre at nondot.org Tue Mar 25 13:28:27 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 25 Mar 2008 11:28:27 -0700 (PDT) Subject: [LLVMdev] Apple's GCC and .s/.S files in llvm-test (fwd) In-Reply-To: <37C04C17-E1D5-4FC3-B880-79627A64ACDF@apple.com> References: <615FE299-083C-4CC3-BFB7-3D164CC7607B@vandevoorde.com> <37C04C17-E1D5-4FC3-B880-79627A64ACDF@apple.com> Message-ID: On Tue, 25 Mar 2008, Dale Johannesen wrote: >> On Mar 24, 2008, at 5:40 PM, Dale Johannesen wrote: >> [...] >>> I don't see a good way to do >>> full-line comments that works both if you run the preprocessor and if >>> you don't. >> >> >> Could you use "##" instead of "#"? > > Pragmatically, that works (as I'm sure you know). Digging into the > legalities of C99 I'm not sure that it's guaranteed to work, though. > Unknown directives actually match the "non-directive" case in the > grammar in 6.10; while nothing is said anywhere about semantics that I > can find, I'm not sure why gcc feels this should be a hard error at > all.... I think that this is an extremely clever hack, and is nice and simple. It works because ## is a token that just gets passed through when not in a macro replacement list. Because of maximal munch, it prevents the preprocessor from seeing it as a #. Dale, do you see any problem with changing the "comment character" to "##"? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From dalej at apple.com Tue Mar 25 13:18:43 2008 From: dalej at apple.com (Dale Johannesen) Date: Tue, 25 Mar 2008 11:18:43 -0700 Subject: [LLVMdev] Apple's GCC and .s/.S files in llvm-test (fwd) In-Reply-To: References: <615FE299-083C-4CC3-BFB7-3D164CC7607B@vandevoorde.com> <37C04C17-E1D5-4FC3-B880-79627A64ACDF@apple.com> Message-ID: <35D2C5F1-B6BD-4967-A8BD-1128C21563E6@apple.com> On Mar 25, 2008, at 11:04 AM, David Vandevoorde wrote: > > On Mar 25, 2008, at 1:08 PM, Dale Johannesen wrote: >> >> On Mar 24, 2008, at 3:18 PM, David Vandevoorde wrote: >> >>> >>> On Mar 24, 2008, at 5:40 PM, Dale Johannesen wrote: >>> [...] >>>> I don't see a good way to do >>>> full-line comments that works both if you run the preprocessor and >>>> if >>>> you don't. >>> >>> >>> Could you use "##" instead of "#"? >> >> Pragmatically, that works (as I'm sure you know). Digging into the >> legalities of C99 I'm not sure that it's guaranteed to work, though. >> Unknown directives actually match the "non-directive" case in the >> grammar in 6.10; while nothing is said anywhere about semantics >> that I >> can find, I'm not sure why gcc feels this should be a hard error at >> all.... > > "##" is a punctuator (6.4.6) and therefore a preprocessing token of > its own (6.4/1). > > A line that starts with "##" is therefore a text-line in 6.10/1 > parlance (i.e., it doesn't match the "# non-directive" rule), and so > yes, I think it's guaranteed to work on the preprocessor side of > things. (I know next to nothing about the assembler side of things.) Ah right, ## is still a token although it can appear only in restricted places...ok, now I like this. This is documented to work in the assembler, so it looks good. Thanks. From evan.cheng at apple.com Tue Mar 25 13:33:48 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 25 Mar 2008 11:33:48 -0700 Subject: [LLVMdev] Whole-function isel In-Reply-To: <47E92AFD.7010104@complang.tuwien.ac.at> References: <252D6A2B-5F7D-46BA-9239-29612BFE7A20@gmail.com> <47E92AFD.7010104@complang.tuwien.ac.at> Message-ID: On Mar 25, 2008, at 9:40 AM, Dietmar Ebner wrote: > Chris, > > Chris Lattner wrote: >> I would love to see any progress in this area. It is clearly an >> important thing to tackle, and it is blocking other interesting >> improvements in the code generator. It would also allow us to >> eliminate a significant amount of weirdness that exists to hack >> around >> this (e.g. switch lowering). > we've been working on a whole-function instruction selector here at > the > vienna university of technology in the recent past. our approach > considers ssa graphs and is based on a problem transformation to a > specialized quadratic assignment problem (pbqp). in contrast to > previous > work [1], the technique is flexible enough to cope with general DAG > patterns such as pre/postincrement or divmod patterns. > > the instruction selector is a drop-in replacement for the original > implementation (llvm 2.1). we've used the ARM backend for evaluation > and > obtained quite encouraging results: speedups are up to 10% for > SPEC/Mibench and up to 57% for simple loop kernels. the compile time > increase is about a factor of 2. Very nice! > > > the paper has been accepted for this year's LCTES conference (june > 12-13, tucson, az). i'm afraid i cannot post it on the list but i'm > happy to send a preliminary version to anybody who's interested. > > the implementation is not yet as efficient as it could be (e.g., we > maintain an additional datastructure for the ssa graph along with the > selection DAG) and i'm afraid there are licensing issues that do not > allow me to directly post or contribute the code. however, i'm happy > to > share further experimental results and discuss the approach in case > somebody is interested. That's unfortunate. What kind of licensing issues are there? Evan > > > - > dietmar > > > [1] Erik Eckstein, Oliver K?nig and Bernhard Scholz > Code Instruction Selection Based on SSA-Graphs > SCOPES 2003 > http://springerlink.metapress.com/content/83cj0ebgtm998hj8 > > -- > --------------------------------------------------------------------- > Dietmar Ebner > CD Laboratory - Compilation Techniques for Embedded Processors > Institut fuer Computersprachen E: ebner at complang.tuwien.ac.at > Technische Universitaet Wien F: (+431) 58801-18598 > Argentinierstrasse 8 / E1851 T: (+431) 58801-58521 > 1040 Wien, Austria W: www.complang.tuwien.ac.at/cd/ebner > > _______________________________________________ > 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 Mar 25 14:12:54 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 25 Mar 2008 12:12:54 -0700 (PDT) Subject: [LLVMdev] 16 bit integers In-Reply-To: <56aaf0ef0803250345t507cdcf8u785fd2fac564c8e0@mail.gmail.com> References: <200803190911.23561.baldrick@free.fr> <56aaf0ef0803250345t507cdcf8u785fd2fac564c8e0@mail.gmail.com> Message-ID: On Tue, 25 Mar 2008, Sanjiv Gupta wrote: > I was able to build and play with clang today. > Clang also promotes integer arithmetic to 32-bit. Right, C requires promotion to int. > Any pointers on how to tweak it so that it generate i16 for "int" and also > promote int operations to 16-bit operations only? The way to fix this is to shrink int to 16 bits. This can be done by changing TargetInfo.h (in the clang include/clang/Basic directory) to: unsigned getIntWidth() const { return 16; } unsigned getIntAlign() const { return 16; } -Chris > > On 3/20/08, Chris Lattner wrote: >> >> On Wed, 19 Mar 2008, Duncan Sands wrote: >>>> How can I build the front-end to generate 16-bit integers? >>> >>> Please clarify your question. >>> If you are asking how to build llvm-gcc for a 16 bit target, >>> I think the answer is: (1) gcc itself doesn't support 16 bit >>> targets; (2) llvm doesn't currently support any 16 bit targets >>> (but could with a little work). So you are out of luck unless >>> you are willing to work on it. >> >> Note that if you only care about C/ObjC (not C++, fortran, ada, etc) that >> clang may be a good option for you. >> >> -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 >> > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From edwintorok at gmail.com Tue Mar 25 14:56:20 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Tue, 25 Mar 2008 21:56:20 +0200 Subject: [LLVMdev] Adding SQLite3 to llvm test-suite In-Reply-To: <3436D44D-3305-4886-96CE-92ACE46368D9@apple.com> References: <47E523BF.7040200@gmail.com> <3436D44D-3305-4886-96CE-92ACE46368D9@apple.com> Message-ID: <47E958E4.6040102@gmail.com> Evan Cheng wrote: > Hi Edwin, > Hi Evan, > It works fine for me. Thanks! > > We prefer a flat directory structure. Is it possible for you to > separate it out to sqlite3 and lemon rather than having them as sub- > directories under SQLite? Ok. The new package is here: http://edwintorok.googlepages.com/sqlite_lemon_llvmtest.tar.gz Anything else I should change? > Also, can you increase lemon's test size? > Lemon doesn't have a testsuite (those 40000+ tests are all for SQLite), however I found some projects that use lemon (its syntax is not compatible with yacc), and copied their grammar files into lemon's directory. I also wrote a wrapper main function for lemon that forks/executes for each file (lemon keeps some state in global variables, so I have to fork). The difference isn't much, it now takes 0.12 seconds to run lemon. > Please file bug about the performance issue. Thanks! > Done, bug #2174. Best regards, --Edwin From edwintorok at gmail.com Tue Mar 25 15:58:25 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Tue, 25 Mar 2008 22:58:25 +0200 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <1206208253.16812.70.camel@asl.dorms.spbu.ru> References: <47E42E20.60505@lip6.fr> <47E4E1E7.2070707.SS32976SS@gmail.com> <1206208253.16812.70.camel@asl.dorms.spbu.ru> Message-ID: <47E96771.7090404@gmail.com> Anton Korobeynikov wrote: > Hello, Edwin > Hi Anton, >> Probably there are more 64-bit issues to solve. Unfortunately I don't >> have time to look into this deeper now. >> > At least these "4" looks pretty suspicious: > > - (void *)gcset((gc **)((unsigned int)this + nbb + 4 - sizeof(void > *)), > + (void *)gcset((gc **)((size_t)this + nbb + 4 - sizeof(void *)), > (Object*)m); > Good point. I think it would be best to review the code Class by Class to locate 64-bit problems. Having unit-tests for this code would make this a lot easier .... Maybe somebody participating at GSoC could take care of this ;) Best regards, --Edwin From mrs at apple.com Tue Mar 25 20:19:42 2008 From: mrs at apple.com (Mike Stump) Date: Tue, 25 Mar 2008 18:19:42 -0700 Subject: [LLVMdev] Environment variables considered evil In-Reply-To: <1206449235.7728.15.camel@kurier> References: <1206368211.7456.6.camel@kurier> <1206386196.7456.38.camel@kurier> <20080325120830.58D9043E2@blake.inputplus.co.uk> <1206449235.7728.15.camel@kurier> Message-ID: On Mar 25, 2008, at 5:47 AM, Joachim Durchholz wrote: > > I'm not sure that > FOO=bar BAZ=boo ./configure > will work It will. From evan.cheng at apple.com Tue Mar 25 21:09:41 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 25 Mar 2008 19:09:41 -0700 Subject: [LLVMdev] Adding SQLite3 to llvm test-suite In-Reply-To: <47E958E4.6040102@gmail.com> References: <47E523BF.7040200@gmail.com> <3436D44D-3305-4886-96CE-92ACE46368D9@apple.com> <47E958E4.6040102@gmail.com> Message-ID: On Mar 25, 2008, at 12:56 PM, T?r?k Edwin wrote: > Evan Cheng wrote: >> Hi Edwin, >> > > Hi Evan, > >> It works fine for me. Thanks! >> >> We prefer a flat directory structure. Is it possible for you to >> separate it out to sqlite3 and lemon rather than having them as sub- >> directories under SQLite? > > Ok. > The new package is here: > http://edwintorok.googlepages.com/sqlite_lemon_llvmtest.tar.gz > Anything else I should change? Looks good. Please commit. > > >> Also, can you increase lemon's test size? >> > > Lemon doesn't have a testsuite (those 40000+ tests are all for > SQLite), > however I found some projects that use lemon (its syntax is not > compatible with yacc), and copied their grammar files into lemon's > directory. > I also wrote a wrapper main function for lemon that forks/executes for > each file (lemon keeps some state in global variables, so I have to > fork). > > The difference isn't much, it now takes 0.12 seconds to run lemon. Still much too small to be really useful as a benchmark. Can you just run it 10 times? Evan > > >> Please file bug about the performance issue. Thanks! >> > > Done, bug #2174. > > 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 shap at eros-os.com Tue Mar 25 22:25:16 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Tue, 25 Mar 2008 23:25:16 -0400 Subject: [LLVMdev] Checked arithmetic Message-ID: <1206501916.23853.13.camel@vmx.home> In looking at the LLVM reference manual, it is conspicuous that (a) the IR does not define condition codes, and (b) the IR does not define opcodes that return condition results in addition to their computational results. Given the IR as it stands, how does one go about *efficiently* implementing a language that requires checked arithmetic? I do understand that it can be done using intrinsics, but that implementation is (to put it mildly) suboptimal. For integer ops, I really want to be able to get at the carry/overflow bit. For floating point ops, I really want to be able to get out the floating point NaN state in order to exploit the NaN propagation features provided by some hardware. I'm sure this has been considered, but no means for dealing with this sort of thing is jumping out at me from looking at the IR spec. What am I missing? Note: I can see at least two ways to deal with this by extending the IR, but I would like to understand the current intentions first. shap From shap at eros-os.com Tue Mar 25 22:32:57 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Tue, 25 Mar 2008 23:32:57 -0400 Subject: [LLVMdev] Order of operations Message-ID: <1206502377.23853.21.camel@vmx.home> Given variables a b c d of compatible scalar arithmetic types, consider the expression: a + b + c + d There are multiple implementation orders for computing this sum, and the one you want can be dependent on the source language specification. In particular, the + operation must not be considered commutative if these are floating point values and we care about error ranges. It is not obvious to me from the IR specification how the front end can specify prescriptively that some particular order of operation is required. I'm probably missing something very obvious here. shap From sabre at nondot.org Tue Mar 25 22:42:05 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 25 Mar 2008 20:42:05 -0700 Subject: [LLVMdev] Order of operations In-Reply-To: <1206502377.23853.21.camel@vmx.home> References: <1206502377.23853.21.camel@vmx.home> Message-ID: <47139F39-BF80-45C5-9CAE-F570FC983AF5@nondot.org> On Mar 25, 2008, at 8:32 PM, Jonathan S. Shapiro wrote: > Given variables a b c d of compatible scalar arithmetic types, > consider > the expression: > > a + b + c + d > > There are multiple implementation orders for computing this sum, and > the > one you want can be dependent on the source language specification. In > particular, the + operation must not be considered commutative if > these > are floating point values and we care about error ranges. > > It is not obvious to me from the IR specification how the front end > can > specify prescriptively that some particular order of operation is > required. > > I'm probably missing something very obvious here. LLVM IR is three address code, not a tree form. This requires the front-end to pick an ordering that works for it explicitly as it lowers to LLVM IR. -Chris From shap at eros-os.com Tue Mar 25 22:57:38 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Tue, 25 Mar 2008 23:57:38 -0400 Subject: [LLVMdev] Order of operations In-Reply-To: <47139F39-BF80-45C5-9CAE-F570FC983AF5@nondot.org> References: <1206502377.23853.21.camel@vmx.home> <47139F39-BF80-45C5-9CAE-F570FC983AF5@nondot.org> Message-ID: <1206503858.23853.32.camel@vmx.home> On Tue, 2008-03-25 at 20:42 -0700, Chris Lattner wrote: > LLVM IR is three address code, not a tree form. This requires the > front-end to pick an ordering that works for it explicitly as it > lowers to LLVM IR. I got that much. But I assume that optimization passes, if used, are entitled to rewrite the IR. For example: ANSI C requires that certain types of parenthesization be honored rigorously, while other operations can legally be combined or reordered. How does the front end specify in it's IR emission which kinds are which, so that the optimizer knows which parts it is not permitted to re-arrange? From sabre at nondot.org Tue Mar 25 23:05:11 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 25 Mar 2008 21:05:11 -0700 Subject: [LLVMdev] Order of operations In-Reply-To: <1206503858.23853.32.camel@vmx.home> References: <1206502377.23853.21.camel@vmx.home> <47139F39-BF80-45C5-9CAE-F570FC983AF5@nondot.org> <1206503858.23853.32.camel@vmx.home> Message-ID: <5FB47B94-E25B-45FA-A996-CF3AFAC0C28E@nondot.org> On Mar 25, 2008, at 8:57 PM, Jonathan S. Shapiro wrote: > On Tue, 2008-03-25 at 20:42 -0700, Chris Lattner wrote: > >> LLVM IR is three address code, not a tree form. This requires the >> front-end to pick an ordering that works for it explicitly as it >> lowers to LLVM IR. > > I got that much. But I assume that optimization passes, if used, are > entitled to rewrite the IR. For example: ANSI C requires that certain > types of parenthesization be honored rigorously, You're thinking about FORTRAN, not C. > while other operations > can legally be combined or reordered. How does the front end specify > in > it's IR emission which kinds are which, so that the optimizer knows > which parts it is not permitted to re-arrange? The compiler currently doesn't change code if it changes its semantics. This means it doesn't reassociate FP operations etc. In the future, we may extend the IR to capture information to tell the optimizer when it is safe to do this, until then it is completely conservative. -Chris From sabre at nondot.org Tue Mar 25 23:18:03 2008 From: sabre at nondot.org (Chris Lattner) Date: Tue, 25 Mar 2008 21:18:03 -0700 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <1206501916.23853.13.camel@vmx.home> References: <1206501916.23853.13.camel@vmx.home> Message-ID: <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> On Mar 25, 2008, at 8:25 PM, Jonathan S. Shapiro wrote: > In looking at the LLVM reference manual, it is conspicuous that (a) > the > IR does not define condition codes, and (b) the IR does not define > opcodes that return condition results in addition to their > computational > results. We currently don't have this because noone has implemented it yet. It would be great to have this. > Given the IR as it stands, how does one go about *efficiently* > implementing a language that requires checked arithmetic? I do > understand that it can be done using intrinsics, but that > implementation > is (to put it mildly) suboptimal. Why? -Chris From shap at eros-os.com Tue Mar 25 23:29:22 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 00:29:22 -0400 Subject: [LLVMdev] Order of operations In-Reply-To: <5FB47B94-E25B-45FA-A996-CF3AFAC0C28E@nondot.org> References: <1206502377.23853.21.camel@vmx.home> <47139F39-BF80-45C5-9CAE-F570FC983AF5@nondot.org> <1206503858.23853.32.camel@vmx.home> <5FB47B94-E25B-45FA-A996-CF3AFAC0C28E@nondot.org> Message-ID: <1206505764.23853.34.camel@vmx.home> On Tue, 2008-03-25 at 21:05 -0700, Chris Lattner wrote: > The compiler currently doesn't change code if it changes its > semantics. This means it doesn't reassociate FP operations etc. In > the future, we may extend the IR to capture information to tell the > optimizer when it is safe to do this, until then it is completely > conservative. Thanks. From shap at eros-os.com Tue Mar 25 23:49:36 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 00:49:36 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> Message-ID: <1206506976.23853.36.camel@vmx.home> On Tue, 2008-03-25 at 21:18 -0700, Chris Lattner wrote: > > Given the IR as it stands, how does one go about *efficiently* > > implementing a language that requires checked arithmetic? I do > > understand that it can be done using intrinsics, but that > > implementation > > is (to put it mildly) suboptimal. > > Why? Hmm. Perhaps I shouldn't have written so quickly. My assumption was that intrinsics would likely entail a procedure call. More later -- my three year old just woke up. shap From ofv at wanadoo.es Wed Mar 26 01:23:54 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Wed, 26 Mar 2008 07:23:54 +0100 Subject: [LLVMdev] Wrong calling convention? Message-ID: When my llvm code calls certain function, either it receives a wrong result or the application ends on what it seems a corrupt stack. The function is a C++ static method that returns a class with just a `double' data member: class Foo { double data; }; My compiler abstracts this as a [8 x i8] array. This is the llvm code: define internal i1 @Addr_045442A0() { alloca [8 x i8], align 4 ; <[8 x i8]*>:1 [#uses=2] alloca i1, align 4 ; :2 [#uses=2] tail call void @F95478DA5_FFI_FN( [8 x i8]* %1 sret ) bitcast [8 x i8]* %1 to i8* ; :3 [#uses=1] tail call void @Addr_004DDA18( i8* inttoptr (i32 14545104 to i8*), i8* %3 ) store i1 true, i1* %2 load i1* %2 ; :4 [#uses=1] ret i1 %4 } It is a function that just calls the above mentioned C++ static method, calls another external function which is known to be "safe" (as it does nothing and is called thousands of times everywhere without problems) and returns bool. This is the generated machine code, obtained with gdb: 0x0e8d9370: push %esi 0x0e8d9371: sub $0x18,%esp 0x0e8d9374: lea 0x10(%esp),%esi 0x0e8d9378: mov %esi,(%esp) 0x0e8d937b: call 0x5053b0 <_ZN3lp04OpF0IN5IncDB9TDateTimeEXadL_ZNS2_3NowEvEEE1wEv> 0x0e8d9380: sub $0x4,%esp 0x0e8d9383: mov %esi,0x4(%esp) 0x0e8d9387: movl $0x8def210,(%esp) 0x0e8d938e: call 0x4b3ca0 <_ZN3lp015BasicDestructorIN5IncDB9TDateTimeEEEvRNS_8TipoInfoEPv> 0x0e8d9393: movb $0x1,0x8(%esp) 0x0e8d9398: movzbl 0x8(%esp),%eax 0x0e8d939d: add $0x18,%esp 0x0e8d93a0: pop %esi 0x0e8d93a1: ret I'm using setCallingConv(CallingConv::C). After hours and hours of debugging, I'm lost. Do you see something wrong here? My setup is llvm 2.1 on Windows XPSP2. Everything is compiled with MinGW g++.exe (GCC) 4.2.1-dw2 (mingw32-2) -- Oscar From edwintorok at gmail.com Wed Mar 26 02:03:37 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edvin?=) Date: Wed, 26 Mar 2008 09:03:37 +0200 Subject: [LLVMdev] Adding SQLite3 to llvm test-suite In-Reply-To: References: <47E523BF.7040200@gmail.com> <3436D44D-3305-4886-96CE-92ACE46368D9@apple.com> <47E958E4.6040102@gmail.com> Message-ID: <4354d3270803260003m1e6b8f3exb33dd11477a04582@mail.gmail.com> On Wed, Mar 26, 2008 at 4:09 AM, Evan Cheng wrote: > > On Mar 25, 2008, at 12:56 PM, T?r?k Edwin wrote: > > The new package is here: > > http://edwintorok.googlepages.com/sqlite_lemon_llvmtest.tar.gz > > Anything else I should change? > > Looks good. Please commit. Should I speak with Chris about commit access? I made the change below for lemon: http://edwintorok.googlepages.com/sqlite_lemon_llvmtest_2.tar.gz > > > > > > The difference isn't much, it now takes 0.12 seconds to run lemon. > > Still much too small to be really useful as a benchmark. Can you just > run it 10 times? > Ok, now it takes ~1.3 seconds. Best regards, --Edwin From baldrick at free.fr Wed Mar 26 03:06:17 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 26 Mar 2008 09:06:17 +0100 Subject: [LLVMdev] Wrong calling convention? In-Reply-To: References: Message-ID: <200803260906.18508.baldrick@free.fr> Hi, > define internal i1 @Addr_045442A0() { > alloca [8 x i8], align 4 ; <[8 x i8]*>:1 [#uses=2] > alloca i1, align 4 ; :2 [#uses=2] > tail call void @F95478DA5_FFI_FN( [8 x i8]* %1 sret ) this call uses the "struct-return" convention (due to the sret attribute). On x86 this means that the caller is responsible for adjusting the stack pointer after the call for the sret parameter. If the callee is not following the sret convention then the stack pointer will be adjusted wrongly and your program will die horribly. > 0x0e8d937b: call 0x5053b0 <_ZN3lp04OpF0IN5IncDB9TDateTimeEXadL_ZNS2_3NowEvEEE1wEv> > 0x0e8d9380: sub $0x4,%esp Here you see the sret stack adjustment. Ciao, Duncan. From baldrick at free.fr Wed Mar 26 03:13:19 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 26 Mar 2008 09:13:19 +0100 Subject: [LLVMdev] non-enable-llvm support in llvm-gcc-4.2 issue In-Reply-To: <80C643111EC3473B8EFA65E833AA5306@ccs.ucsb.edu> References: <80C643111EC3473B8EFA65E833AA5306@ccs.ucsb.edu> Message-ID: <200803260913.19573.baldrick@free.fr> Hi Jay, this should be fixed now (commit 48816). Can you please check. Ciao, Duncan. From ebner at complang.tuwien.ac.at Wed Mar 26 04:58:47 2008 From: ebner at complang.tuwien.ac.at (Dietmar Ebner) Date: Wed, 26 Mar 2008 10:58:47 +0100 Subject: [LLVMdev] Whole-function isel In-Reply-To: References: <252D6A2B-5F7D-46BA-9239-29612BFE7A20@gmail.com> <47E92AFD.7010104@complang.tuwien.ac.at> Message-ID: <47EA1E57.7010804@complang.tuwien.ac.at> Evan Cheng wrote: >> the implementation is not yet as efficient as it could be (e.g., we >> maintain an additional datastructure for the ssa graph along with the >> selection DAG) and i'm afraid there are licensing issues that do not >> allow me to directly post or contribute the code. however, i'm happy >> to >> share further experimental results and discuss the approach in case >> somebody is interested. > > That's unfortunate. What kind of licensing issues are there? i'm working in a christian doppler laboratory. projects are funded partially by industry and the developed code "belongs" to the partner company unless they decide to release it. i would have to talk to them and see what i can do. furthermore, there's a generic solver that has been implemented by bernhard scholz (university of sydney) [1]. it's free for research purposes but would have to be re-licensed for llvm. however, the latter would be no problem if you just want to play with it. note that the implementation is pretty stable but sincerely not ready for prime time. several parts would have to be revised and/or replaced and some design decisions would probably be different for a production quality system vs. a research prototype. - dietmar [1] http://www.it.usyd.edu.au/~scholz/pbqp.html -- --------------------------------------------------------------------- Dietmar Ebner CD Laboratory - Compilation Techniques for Embedded Processors Institut fuer Computersprachen E: ebner at complang.tuwien.ac.at Technische Universitaet Wien F: (+431) 58801-18598 Argentinierstrasse 8 / E1851 T: (+431) 58801-58521 1040 Wien, Austria W: www.complang.tuwien.ac.at/cd/ebner From mdevan.foobar at gmail.com Wed Mar 26 05:39:44 2008 From: mdevan.foobar at gmail.com (Mahadevan R) Date: Wed, 26 Mar 2008 16:09:44 +0530 Subject: [LLVMdev] Python bindings? Message-ID: Hi, Are there Python bindings for LLVM? Apparently there was one ~2005; has this been updated since? Is anyone working on this? Is the LLVM dev community interested in this? Thanks & Regards, -Mahadevan. From ndbecker2 at gmail.com Wed Mar 26 06:10:48 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 26 Mar 2008 07:10:48 -0400 Subject: [LLVMdev] Python bindings? References: Message-ID: Mahadevan R wrote: > Hi, > > Are there Python bindings for LLVM? > > Apparently there was one ~2005; has this been updated since? Is anyone > working on this? > > Is the LLVM dev community interested in this? > I'm curious. What would you use this for? From mdevan.foobar at gmail.com Wed Mar 26 06:31:14 2008 From: mdevan.foobar at gmail.com (Mahadevan R) Date: Wed, 26 Mar 2008 17:01:14 +0530 Subject: [LLVMdev] Python bindings? In-Reply-To: References: Message-ID: HI Nick, > > Are there Python bindings for LLVM? > > I'm curious. What would you use this for? Mainly because it'd be easier to play around with the LLVM APIs, to create toy languages like the Kaleidoscope (from the tutorial). For the LLVM development itself, perhaps it can also be used to create unit/regression test scripts. Its also a good way to learn LLVM ;-) Regards, -Mahadevan. From gordonhenriksen at mac.com Wed Mar 26 07:13:41 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Wed, 26 Mar 2008 08:13:41 -0400 Subject: [LLVMdev] Python bindings? In-Reply-To: References: Message-ID: <92C2DA77-A681-4023-AF56-B627BF64E16C@mac.com> On Mar 26, 2008, at 06:39, Mahadevan R wrote: > Are there Python bindings for LLVM? I'm not aware of any. The PyPy compiler pipes LLVM assembly to llc rather than building the C++ IR in memory. > Apparently there was one ~2005; has this been updated since? Is > anyone working on this? > > Is the LLVM dev community interested in this? Yes! Note that C bindings have been introduced since 2005, so there may be a different route available than was taken then. Look in include/llvm- c. The intent of the C bindings is to enable high-level language bindings. The current focus is on enabling front-end compilers. Ocaml and Haskell bindings have been developed atop them, the former being in the LLVM source tree. ? Gordon From shap at eros-os.com Wed Mar 26 08:06:29 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 09:06:29 -0400 Subject: [LLVMdev] JIT and anonymous procs Message-ID: <1206536789.26804.3.camel@vmx.home> The Kaleidoscope tutorial has us "interpreting" top-level expressions by generating a one-shot anonymous procedure and executing that. Once the expressions have been executed, these procedures will never be called again. How can the associated storage for this anonymous procedure be reclaimed? shap From shap at eros-os.com Wed Mar 26 08:19:21 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 09:19:21 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> Message-ID: <1206537564.26804.17.camel@vmx.home> On Tue, 2008-03-25 at 21:18 -0700, Chris Lattner wrote: > On Mar 25, 2008, at 8:25 PM, Jonathan S. Shapiro wrote: > > > In looking at the LLVM reference manual, it is conspicuous that (a) > > the > > IR does not define condition codes, and (b) the IR does not define > > opcodes that return condition results in addition to their > > computational > > results. > > We currently don't have this because noone has implemented it yet. It > would be great to have this. I want to background process this for a bit, but it would be helpful to discuss some approaches first. There would appear to be three approaches: 1. Introduce a CC register class into the IR. This seems to be a fairly major overhaul. 2. Introduce a set of scalar and fp computation quasi-instructions that accept the same arguments as their computational counterparts, but produce *only* the condition code. For example: add i32 ... produces result add_cc i32 ... produces condition codes Once this exists, re-combine the instructions in the back end with peepholes. 3. Handle CC as a black magic special case, which at least has the merit of tradition. :-) Given the number of different ways that different bits of hardware handle CCs, I am inclined to think that the right approach, in abstract, is to introduce a CC register class and deal with CCs in a fully general way. If so, this is not a small change. Opinions/reactions? From ofv at wanadoo.es Wed Mar 26 08:39:49 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Wed, 26 Mar 2008 14:39:49 +0100 Subject: [LLVMdev] Wrong calling convention? References: <200803260906.18508.baldrick@free.fr> Message-ID: Hi Duncan. Duncan Sands writes: >> define internal i1 @Addr_045442A0() { >> alloca [8 x i8], align 4 ; <[8 x i8]*>:1 [#uses=2] >> alloca i1, align 4 ; :2 [#uses=2] >> tail call void @F95478DA5_FFI_FN( [8 x i8]* %1 sret ) > > this call uses the "struct-return" convention (due to the sret attribute). > On x86 this means that the caller is responsible for adjusting the stack > pointer after the call for the sret parameter. If the callee is not following > the sret convention then the stack pointer will be adjusted wrongly and your > program will die horribly. > >> 0x0e8d937b: call 0x5053b0 <_ZN3lp04OpF0IN5IncDB9TDateTimeEXadL_ZNS2_3NowEvEEE1wEv> >> 0x0e8d9380: sub $0x4,%esp > > Here you see the sret stack adjustment. This looks like the opposite: it is making room for passing a parameter to the next call (the stack grows downwards). But you put me on the right track. The problem is that the class is returned on the stack. This is the class: class Foo { public: Foo() : data(113.5) {} static Foo GetFoo() { return Foo(); } private: double data; }; This is the assembler code for Foo::GetFoo: Dump of assembler code for function _ZN3Foo6GetFooEv: 0x6e08b5a4 <_ZN3Foo6GetFooEv+0>: push %ebp 0x6e08b5a5 <_ZN3Foo6GetFooEv+1>: mov %esp,%ebp 0x6e08b5a7 <_ZN3Foo6GetFooEv+3>: sub $0x14,%esp 0x6e08b5aa <_ZN3Foo6GetFooEv+6>: lea -0x8(%ebp),%eax 0x6e08b5ad <_ZN3Foo6GetFooEv+9>: mov %eax,(%esp) 0x6e08b5b0 <_ZN3Foo6GetFooEv+12>: call 0x6e08b5bc 0x6e08b5b5 <_ZN3Foo6GetFooEv+17>: fldl -0x8(%ebp) 0x6e08b5b8 <_ZN3Foo6GetFooEv+20>: leave 0x6e08b5b9 <_ZN3Foo6GetFooEv+21>: ret End of assembler dump. I guess that g++ exploits its knowledge of Foo's internals for deciding how to return the class. But my compiler knows nothing about Foo, so I must disable this "feature" of g++. Suggestions welcome. -- Oscar From baldrick at free.fr Wed Mar 26 09:07:16 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 26 Mar 2008 15:07:16 +0100 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <1206537564.26804.17.camel@vmx.home> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> Message-ID: <200803261507.18061.baldrick@free.fr> Hi, > There would appear to be three approaches: > > 1. Introduce a CC register class into the IR. This seems to be a > fairly major overhaul. > > 2. Introduce a set of scalar and fp computation quasi-instructions > that accept the same arguments as their computational counterparts, > but produce *only* the condition code. For example: > > add i32 ... produces result > add_cc i32 ... produces condition codes > > Once this exists, re-combine the instructions in the back end with > peepholes. > > 3. Handle CC as a black magic special case, which at least has the > merit of tradition. :-) 4. Do arithmetic in a type with one more bit. For example, suppose you want to know if an i32 add "x+y" will overflow. Extend x and y to 33 bit integers, and do an i33 add. Inspect the upper bit to see if it overflowed. Truncate to 32 bits to get the result. Probably codegen can be taught to implement this as a 32 bit add + inspection of the CC. Ciao, Duncan. PS: In order for codegen to be able to handle i33, you need to turn on the new LegalizeTypes infrastructure. From shap at eros-os.com Wed Mar 26 09:33:24 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 10:33:24 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <200803261507.18061.baldrick@free.fr> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <200803261507.18061.baldrick@free.fr> Message-ID: <1206542004.27074.1.camel@vmx.home> On Wed, 2008-03-26 at 15:07 +0100, Duncan Sands wrote: > 4. Do arithmetic in a type with one more bit. For example, suppose you > want to know if an i32 add "x+y" will overflow. Extend x and y to 33 > bit integers, and do an i33 add. Inspect the upper bit to see if it > overflowed. Truncate to 32 bits to get the result. Probably codegen > can be taught to implement this as a 32 bit add + inspection of the CC. As a quick fix, that isn't a bad solution for bignum arithmetic, but it doesn't deal with the upper bits from multiply, and it doesn't deal with floating point condition codes at all. shap From baldrick at free.fr Wed Mar 26 09:47:59 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 26 Mar 2008 15:47:59 +0100 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <1206542004.27074.1.camel@vmx.home> References: <1206501916.23853.13.camel@vmx.home> <200803261507.18061.baldrick@free.fr> <1206542004.27074.1.camel@vmx.home> Message-ID: <200803261548.01561.baldrick@free.fr> Hi Shap, > > 4. Do arithmetic in a type with one more bit. For example, suppose you > > want to know if an i32 add "x+y" will overflow. Extend x and y to 33 > > bit integers, and do an i33 add. Inspect the upper bit to see if it > > overflowed. Truncate to 32 bits to get the result. Probably codegen > > can be taught to implement this as a 32 bit add + inspection of the CC. > > As a quick fix, that isn't a bad solution for bignum arithmetic, but it > doesn't deal with the upper bits from multiply, and it doesn't deal with > floating point condition codes at all. can you really use condition codes for multiply and floating point? You can handle integer multiply by doing it in an integer twice as wide as the one you are interested in, so an i64 on a 32 bit machine. Is there hardware that supports checking for multiply overflow in a more efficient fashion, and if so how does it work/get used? Thanks, Duncan. From shap at eros-os.com Wed Mar 26 10:07:29 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 11:07:29 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <200803261548.01561.baldrick@free.fr> References: <1206501916.23853.13.camel@vmx.home> <200803261507.18061.baldrick@free.fr> <1206542004.27074.1.camel@vmx.home> <200803261548.01561.baldrick@free.fr> Message-ID: <1206544049.2137.8.camel@shaptop.om-md.eros-os.com> On Wed, 2008-03-26 at 15:47 +0100, Duncan Sands wrote: > can you really use condition codes for multiply and floating point? For scalar multiply, not really. What you *can* do is use the native multiply instruction that does (32x32)->(lower,upper), and then decide based on the upper 32 bits of the result whether you had a multiply-carry. Similarly for i-divide 64->(quotient,remainder). For floating point I am thinking about something else entirely. There is a NaN propagation mode specified in IEEE that lets you run a chain of FP ops and then check for NaN at the end, with the guarantee that the intervening ops will be NaN-preserving. You can't store the results back to memory without a check, but the technique avoids a check in the fp pipeline that can be serializing on intermediate expression results. The catch is that you can't use that technique unless you can ensure that the FPcc isn't clobbered by something else in the middle, which seems to suggest that you want to track the FP condition code as a register. And then there are machines with multiple condition codes, and machines the simply put the condition codes into a scalar register. These seem to suggest that first-rate support for condition codes wants them to be handled as a register class. > You > can handle integer multiply by doing it in an integer twice as wide as the > one you are interested in, so an i64 on a 32 bit machine. Is there hardware > that supports checking for multiply overflow in a more efficient fashion, > and if so how does it work/get used? On some machines there is. For example, both SPARC and MIPS have instructions that do a 32x32 multiply producing a 64 bit result. The upper bits of the result go into a side register, or in some cases the output of the multiply unit goes into a distinct (lower, upper) register pair that is not part of the normal register set. This is an idea that comes and goes. The side register has to be renamed specially, and can become a rename bottleneck in the issue unit, so it may be an idea whose time came and went. On machines that do 32x32->32, I do not know what outcome happens on the condition codes, but we can surely look that up. shap From baldrick at free.fr Wed Mar 26 10:24:02 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 26 Mar 2008 16:24:02 +0100 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <1206544049.2137.8.camel@shaptop.om-md.eros-os.com> References: <1206501916.23853.13.camel@vmx.home> <200803261548.01561.baldrick@free.fr> <1206544049.2137.8.camel@shaptop.om-md.eros-os.com> Message-ID: <200803261624.04573.baldrick@free.fr> Hi, > > can you really use condition codes for multiply and floating point? > > For scalar multiply, not really. What you *can* do is use the native > multiply instruction that does (32x32)->(lower,upper), and then decide > based on the upper 32 bits of the result whether you had a > multiply-carry. Similarly for i-divide 64->(quotient,remainder). I think this is what you get if you do the multiply in an integer of twice the width. > For floating point I am thinking about something else entirely. There is > a NaN propagation mode specified in IEEE that lets you run a chain of FP > ops and then check for NaN at the end, with the guarantee that the > intervening ops will be NaN-preserving. You can't store the results back > to memory without a check, but the technique avoids a check in the fp > pipeline that can be serializing on intermediate expression results. Yes. > The catch is that you can't use that technique unless you can ensure > that the FPcc isn't clobbered by something else in the middle, which > seems to suggest that you want to track the FP condition code as a > register. > > And then there are machines with multiple condition codes, and machines > the simply put the condition codes into a scalar register. These seem to > suggest that first-rate support for condition codes wants them to be > handled as a register class. In any case, this is all at the codegen level. You suggested introducing condition codes into the IR, and I tried to point out that you can get at least some of what you want by using arbitrary precision integers and floating point types (these last don't exist yet) in the IR. For sure there needs to be some careful codegen work to have everything come out optimally when you codegen. > > You > > can handle integer multiply by doing it in an integer twice as wide as the > > one you are interested in, so an i64 on a 32 bit machine. Is there hardware > > that supports checking for multiply overflow in a more efficient fashion, > > and if so how does it work/get used? > > On some machines there is. For example, both SPARC and MIPS have > instructions that do a 32x32 multiply producing a 64 bit result. The > upper bits of the result go into a side register, or in some cases the > output of the multiply unit goes into a distinct (lower, upper) register > pair that is not part of the normal register set. > > This is an idea that comes and goes. The side register has to be renamed > specially, and can become a rename bottleneck in the issue unit, so it > may be an idea whose time came and went. On machines that do 32x32->32, > I do not know what outcome happens on the condition codes, but we can > surely look that up. Ciao, Duncan. From baldrick at free.fr Wed Mar 26 10:30:03 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 26 Mar 2008 16:30:03 +0100 Subject: [LLVMdev] Wrong calling convention? In-Reply-To: References: <200803260906.18508.baldrick@free.fr> Message-ID: <200803261630.06793.baldrick@free.fr> Hi ?scar, > >> define internal i1 @Addr_045442A0() { > >> alloca [8 x i8], align 4 ; <[8 x i8]*>:1 [#uses=2] > >> alloca i1, align 4 ; :2 [#uses=2] > >> tail call void @F95478DA5_FFI_FN( [8 x i8]* %1 sret ) > > > > this call uses the "struct-return" convention (due to the sret attribute). > > On x86 this means that the caller is responsible for adjusting the stack > > pointer after the call for the sret parameter. If the callee is not following > > the sret convention then the stack pointer will be adjusted wrongly and your > > program will die horribly. > > > >> 0x0e8d937b: call 0x5053b0 <_ZN3lp04OpF0IN5IncDB9TDateTimeEXadL_ZNS2_3NowEvEEE1wEv> > >> 0x0e8d9380: sub $0x4,%esp > > > > Here you see the sret stack adjustment. > > This looks like the opposite: it is making room for passing a parameter > to the next call (the stack grows downwards). yes I said it the wrong way round: with sret the callee pops the sret parameter, so the caller needs to correct for that. I'm pretty sure that's exactly what this sub is doing. > But you put me on the right track. The problem is that the class is > returned on the stack. > > This is the class: > > class Foo { > public: > Foo() : data(113.5) {} > static Foo GetFoo() { return Foo(); } > private: > double data; > }; > > This is the assembler code for Foo::GetFoo: > > Dump of assembler code for function _ZN3Foo6GetFooEv: > 0x6e08b5a4 <_ZN3Foo6GetFooEv+0>: push %ebp > 0x6e08b5a5 <_ZN3Foo6GetFooEv+1>: mov %esp,%ebp > 0x6e08b5a7 <_ZN3Foo6GetFooEv+3>: sub $0x14,%esp > 0x6e08b5aa <_ZN3Foo6GetFooEv+6>: lea -0x8(%ebp),%eax > 0x6e08b5ad <_ZN3Foo6GetFooEv+9>: mov %eax,(%esp) > 0x6e08b5b0 <_ZN3Foo6GetFooEv+12>: call 0x6e08b5bc > 0x6e08b5b5 <_ZN3Foo6GetFooEv+17>: fldl -0x8(%ebp) > 0x6e08b5b8 <_ZN3Foo6GetFooEv+20>: leave > 0x6e08b5b9 <_ZN3Foo6GetFooEv+21>: ret > End of assembler dump. > > I guess that g++ exploits its knowledge of Foo's internals for deciding > how to return the class. How Foo is returned is specified by the platform ABI. It is not really a feature of g++. > But my compiler knows nothing about Foo, so I > must disable this "feature" of g++. Suggestions welcome. It is not possible to correctly codegen parameter passing/result returning without knowing the type (though not all details of the type are relevant). Your compiler needs to know something about Foo. Ciao, Duncan. From ofv at wanadoo.es Wed Mar 26 11:02:38 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Wed, 26 Mar 2008 17:02:38 +0100 Subject: [LLVMdev] Wrong calling convention? References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> Message-ID: <63v9ean5.fsf@telefonica.net> Duncan Sands writes: >> But you put me on the right track. The problem is that the class is >> returned on the stack. Correction: The class is returned on the FP stack: >> 0x6e08b5b5 <_ZN3Foo6GetFooEv+17>: fldl -0x8(%ebp) >> 0x6e08b5b8 <_ZN3Foo6GetFooEv+20>: leave >> 0x6e08b5b9 <_ZN3Foo6GetFooEv+21>: ret >> End of assembler dump. >> >> I guess that g++ exploits its knowledge of Foo's internals for deciding >> how to return the class. > > How Foo is returned is specified by the platform ABI. It is not really a > feature of g++. This is C++ land, so there is no "platform ABI", although static methods usually follow C calling convention. I've checked that wrapping the class definition with extern "C" changes nothing, so maybe it is following the platform ABI, after all. BTW, -fpcc-struct-return solves the case that motivated this thread. >> But my compiler knows nothing about Foo, so I >> must disable this "feature" of g++. Suggestions welcome. > > It is not possible to correctly codegen parameter passing/result returning > without knowing the type (though not all details of the type are relevant). > Your compiler needs to know something about Foo. I'm afraid you are right. Current available information includes the specific type (if it is fundamental), and type size (if it is derived). It also knows the default constructor, copier and destructor of each type. I hope that this, together with -fpcc-struct-return, is enough to complete my C++ <-> LLVM interface, which only has to deal with static methods. -- Oscar From evan.cheng at apple.com Wed Mar 26 12:04:33 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 26 Mar 2008 10:04:33 -0700 Subject: [LLVMdev] Adding SQLite3 to llvm test-suite In-Reply-To: <4354d3270803260003m1e6b8f3exb33dd11477a04582@mail.gmail.com> References: <47E523BF.7040200@gmail.com> <3436D44D-3305-4886-96CE-92ACE46368D9@apple.com> <47E958E4.6040102@gmail.com> <4354d3270803260003m1e6b8f3exb33dd11477a04582@mail.gmail.com> Message-ID: <615DC0B7-AC3A-4AA2-9F20-C2BCAE88EEE0@apple.com> On Mar 26, 2008, at 12:03 AM, T?r?k Edvin wrote: > On Wed, Mar 26, 2008 at 4:09 AM, Evan Cheng > wrote: >> >> On Mar 25, 2008, at 12:56 PM, T?r?k Edwin wrote: >>> The new package is here: >>> http://edwintorok.googlepages.com/sqlite_lemon_llvmtest.tar.gz >>> Anything else I should change? >> >> Looks good. Please commit. > > Should I speak with Chris about commit access? I've committed it for you. Ping Chris about commit access next time. > > > I made the change below for lemon: > http://edwintorok.googlepages.com/sqlite_lemon_llvmtest_2.tar.gz > >> >> >>> >>> The difference isn't much, it now takes 0.12 seconds to run lemon. >> >> Still much too small to be really useful as a benchmark. Can you just >> run it 10 times? >> > > Ok, now it takes ~1.3 seconds. Thanks. I've bumped it up a bit more. Evan > > > 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 callmeno2 at gmail.com Wed Mar 26 12:07:03 2008 From: callmeno2 at gmail.com (karthik parvathaneni) Date: Wed, 26 Mar 2008 22:37:03 +0530 Subject: [LLVMdev] compile programs with the LLVM compiler Message-ID: <347f9e8c0803261007x393c238xeb2a44b37cd24233@mail.gmail.com> hello everyone ... my name is Karthik Parvathaneni ... and i am interested in working on this project ... can anyone please help me out with a detailed description of the project ??? .... i mean is it just writing codes and compiling using the compiler or something else ??? .. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080326/641b8875/attachment.html From nicolas.geoffray at lip6.fr Wed Mar 26 12:09:06 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Wed, 26 Mar 2008 18:09:06 +0100 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <583B623E-92DE-4B1B-8E2D-22072B1C2111@mac.com> References: <47E42E20.60505@lip6.fr> <583B623E-92DE-4B1B-8E2D-22072B1C2111@mac.com> Message-ID: <47EA8332.4030108@lip6.fr> Owen Anderson wrote: > Here's a patch that gets Mvm compiling on Darwin. Applied! Thanks Owen. I've also modified configure.ac so that libopcodes is not used on darwin. Nicolas > > --Owen > > > > > On Mar 21, 2008, at 4:52 PM, Nicolas Geoffray wrote: > >> Hi everyone, >> >> I've just checked in a JVM and a CLI for LLVM (called JnJVM and N3). >> Both are placed in the vmkit svn directory. >> You can find the source code here: >> >> svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit >> >> Its licensed under the U of I Open Source License, so now that's in svn, >> you can change whatever you want, as long as HelloWorld.java and >> HelloWorld.cs work ;-) >> >> I haven't tested the build process on many machines, mostly on gentoo >> linux/x86 and linux/ppc. There are probably some dev libs that VMKit >> requires and the configure script does not check. A good thing would be >> to make the build process cleaner. >> >> The README file on root explains the few steps to run the virtual >> machines. >> >> I should probably say here that you currently need to patch llvm to get >> things working :( Let's hope this won't be true too long. >> >> Happy hacking! >> >> Nicolas >> >> PS: I won't be able to check my emails until Wednesday, so really, happy >> hacking! ;-) >> _______________________________________________ >> 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 Mar 26 12:40:59 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 26 Mar 2008 10:40:59 -0700 (PDT) Subject: [LLVMdev] JIT and anonymous procs In-Reply-To: <1206536789.26804.3.camel@vmx.home> References: <1206536789.26804.3.camel@vmx.home> Message-ID: On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > The Kaleidoscope tutorial has us "interpreting" top-level expressions by > generating a one-shot anonymous procedure and executing that. Once the > expressions have been executed, these procedures will never be called > again. > > How can the associated storage for this anonymous procedure be > reclaimed? All functions in the tutorial are referenced by their Function*. The Function* uniquely identifies a function and is independent of the name. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From ofv at wanadoo.es Wed Mar 26 12:31:18 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Wed, 26 Mar 2008 18:31:18 +0100 Subject: [LLVMdev] Wrong calling convention? References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf@telefonica.net> Message-ID: <1w5xe6jd.fsf@telefonica.net> ?scar Fuentes writes: > BTW, -fpcc-struct-return solves the case that motivated this thread. -fpcc-struct-return is an ABI change, hence it requires "compiling the world". Not acceptable. I'll be interested on hearing ideas about how to determine how a function returns a small struct, without knowing the internals of the struct. -- Oscar From sabre at nondot.org Wed Mar 26 13:02:16 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 26 Mar 2008 11:02:16 -0700 (PDT) Subject: [LLVMdev] Checked arithmetic In-Reply-To: <1206537564.26804.17.camel@vmx.home> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> Message-ID: On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > I want to background process this for a bit, but it would be helpful to > discuss some approaches first. > > There would appear to be three approaches: > > 1. Introduce a CC register class into the IR. This seems to be a > fairly major overhaul. > > 2. Introduce a set of scalar and fp computation quasi-instructions > that accept the same arguments as their computational counterparts, > but produce *only* the condition code. For example: Why not define an "add with overflow" intrinsic that returns its value and overflow bit as an i1? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From ofv at wanadoo.es Wed Mar 26 12:31:22 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Wed, 26 Mar 2008 18:31:22 +0100 Subject: [LLVMdev] Wrong calling convention? References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf@telefonica.net> Message-ID: ?scar Fuentes writes: > BTW, -fpcc-struct-return solves the case that motivated this thread. -fpcc-struct-return is an ABI change, hence it requires "compiling the world". Not acceptable. I'll be interested on hearing ideas about how to determine how a function returns a small struct, without knowing the internals of the struct. -- Oscar From daveed at vandevoorde.com Wed Mar 26 12:59:44 2008 From: daveed at vandevoorde.com (David Vandevoorde) Date: Wed, 26 Mar 2008 13:59:44 -0400 Subject: [LLVMdev] Wrong calling convention? In-Reply-To: References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf@telefonica.net> Message-ID: <056C4942-3D6B-4DE3-8207-2D2F4E8F5B62@vandevoorde.com> On Mar 26, 2008, at 1:31 PM, ?scar Fuentes wrote: > ?scar Fuentes writes: > >> BTW, -fpcc-struct-return solves the case that motivated this thread. > > -fpcc-struct-return is an ABI change, hence it requires "compiling the > world". Not acceptable. > > I'll be interested on hearing ideas about how to determine how a > function returns a small struct, without knowing the internals of the > struct. You need to know _something_ about the internals. GCC approximately implements the IA-64 C++ ABI; which is fairly conventional in this particular aspect of a C++ ABI. See http://www.codesourcery.com/cxx-abi/abi.html#calls In that ABI, if there is a "nontrivial" (that's a precise term) copy- constructor or destructor, the caller is responsible for allocation. Daveed From shap at eros-os.com Wed Mar 26 13:01:38 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 14:01:38 -0400 Subject: [LLVMdev] JIT and anonymous procs In-Reply-To: References: <1206536789.26804.3.camel@vmx.home> Message-ID: <1206554498.4523.1.camel@mikado64.cs.jhu.edu> On Wed, 2008-03-26 at 10:40 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > > The Kaleidoscope tutorial has us "interpreting" top-level expressions by > > generating a one-shot anonymous procedure and executing that. Once the > > expressions have been executed, these procedures will never be called > > again. > > > > How can the associated storage for this anonymous procedure be > > reclaimed? > > All functions in the tutorial are referenced by their Function*. The > Function* uniquely identifies a function and is independent of the name. I had understood that. So now I have compiled and run my top level expression's anonymous function. How do I go about properly freeing the Function object, *including* removing the anonymous procedure name from any global symbol table (if any) and also advising the runtime that the associated IR module can now be dropped along with everything else that was generated? From edwintorok at gmail.com Wed Mar 26 12:56:15 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Wed, 26 Mar 2008 19:56:15 +0200 Subject: [LLVMdev] Adding SQLite3 to llvm test-suite In-Reply-To: <615DC0B7-AC3A-4AA2-9F20-C2BCAE88EEE0@apple.com> References: <47E523BF.7040200@gmail.com> <3436D44D-3305-4886-96CE-92ACE46368D9@apple.com> <47E958E4.6040102@gmail.com> <4354d3270803260003m1e6b8f3exb33dd11477a04582@mail.gmail.com> <615DC0B7-AC3A-4AA2-9F20-C2BCAE88EEE0@apple.com> Message-ID: <47EA8E3F.7070203@gmail.com> Evan Cheng wrote: > On Mar 26, 2008, at 12:03 AM, T?r?k Edvin wrote: > >> Should I speak with Chris about commit access? >> > > I've committed it for you. Ping Chris about commit access next time. Thanks! --Edwin From shap at eros-os.com Wed Mar 26 13:02:47 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 14:02:47 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> Message-ID: <1206554567.4523.3.camel@mikado64.cs.jhu.edu> On Wed, 2008-03-26 at 11:02 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > > I want to background process this for a bit, but it would be helpful to > > discuss some approaches first. > > > > There would appear to be three approaches: > > > > 1. Introduce a CC register class into the IR. This seems to be a > > fairly major overhaul. > > > > 2. Introduce a set of scalar and fp computation quasi-instructions > > that accept the same arguments as their computational counterparts, > > but produce *only* the condition code. For example: > > Why not define an "add with overflow" intrinsic that returns its value and > overflow bit as an i1? Chris: I understand several simple ways to implement add with carry. Your suggestion is one of them. What I'm trying to understand is how to handle the conditional code issue generally. shap From nicolas.geoffray at lip6.fr Wed Mar 26 13:41:27 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Wed, 26 Mar 2008 19:41:27 +0100 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47E4E1E7.2070707@gmail.com> References: <47E42E20.60505@lip6.fr> <47E4E1E7.2070707@gmail.com> Message-ID: <47EA98D7.6020409@lip6.fr> Very nice Torok! I applied most of the patch. A few comments: 1) What is your jni.h file? I can't compile the Jni.cpp file with your changes. 2) ISO C++ does not support %jd. x86_64 does not know about %lld? Thanks! Nicolas T?r?k Edwin wrote: > Nicolas Geoffray wrote: > >> Hi everyone, >> >> I've just checked in a JVM and a CLI for LLVM (called JnJVM and N3). >> Both are placed in the vmkit svn directory. >> You can find the source code here: >> >> > > Very nice! > >> svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit >> >> Its licensed under the U of I Open Source License, so now that's in svn, >> you can change whatever you want, as long as HelloWorld.java and >> HelloWorld.cs work ;-) >> >> I haven't tested the build process on many machines, mostly on gentoo >> linux/x86 and linux/ppc. There are probably some dev libs that VMKit >> requires and the configure script does not check. A good thing would be >> to make the build process cleaner. >> > > The code is not 64-bit clean, attached is a patch to get it compile on > x86-64 Linux. > I also fixed some g++-4.2 warnings (const issues, symbol visibility). > > The libJnJVM directory builds, but it won't run, I get endless messages > like this: > ; ****************************************************** ; > ; SIGSEGV occured during a collection ; > ; I'm trying to let the allocator in a coherent stat ; > ; but the collector is DEAD and will never collect again ; > ; ****************************************************** ; > > Probably there are more 64-bit issues to solve. Unfortunately I don't > have time to look into this deeper now. > > Best regards, > --Edwin > ------------------------------------------------------------------------ > > This body part will be downloaded on demand. From evan.cheng at apple.com Wed Mar 26 13:42:07 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 26 Mar 2008 11:42:07 -0700 Subject: [LLVMdev] Wrong calling convention? In-Reply-To: References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf@telefonica.net> Message-ID: <94A682EF-5A78-405F-9EDE-7C3D681C312B@apple.com> Take a look at llvm-gcc. Look for HandleAggregateShadowArgument. Evan On Mar 26, 2008, at 10:31 AM, ?scar Fuentes wrote: > ?scar Fuentes writes: > >> BTW, -fpcc-struct-return solves the case that motivated this thread. > > -fpcc-struct-return is an ABI change, hence it requires "compiling the > world". Not acceptable. > > I'll be interested on hearing ideas about how to determine how a > function returns a small struct, without knowing the internals of the > struct. > > -- > Oscar > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From nicolas.geoffray at lip6.fr Wed Mar 26 13:44:07 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Wed, 26 Mar 2008 19:44:07 +0100 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47E96771.7090404@gmail.com> References: <47E42E20.60505@lip6.fr> <47E4E1E7.2070707.SS32976SS@gmail.com> <1206208253.16812.70.camel@asl.dorms.spbu.ru> <47E96771.7090404@gmail.com> Message-ID: <47EA9977.9020709@lip6.fr> T?r?k Edwin wrote: > > Good point. > > I think it would be best to review the code Class by Class to locate > 64-bit problems. > Indeed, the source code is very x86_64 unfriendly. Most of the errors should be in the GC and the Allocator though. > Having unit-tests for this code would make this a lot easier .... > > Maybe somebody participating at GSoC could take care of this ;) > Yeah, porting to all LLVM supported architectures, that would be great! As well as a test suite. As well as.... ;-) Nicolas > 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 evan.cheng at apple.com Wed Mar 26 13:45:39 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 26 Mar 2008 11:45:39 -0700 Subject: [LLVMdev] Wrong calling convention? In-Reply-To: <94A682EF-5A78-405F-9EDE-7C3D681C312B@apple.com> References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf@telefonica.net> <94A682EF-5A78-405F-9EDE-7C3D681C312B@apple.com> Message-ID: <953D0B9F-0B6E-44BA-AF22-BB73A937960B@apple.com> I should note this how we do it today but it may not be the solution long term. In an ideal world the llvm frontend will not need to know anything about the target since llvm is intended as a virtual instruction set. Evan On Mar 26, 2008, at 11:42 AM, Evan Cheng wrote: > Take a look at llvm-gcc. Look for HandleAggregateShadowArgument. > > Evan > > On Mar 26, 2008, at 10:31 AM, ?scar Fuentes wrote: > >> ?scar Fuentes writes: >> >>> BTW, -fpcc-struct-return solves the case that motivated this thread. >> >> -fpcc-struct-return is an ABI change, hence it requires "compiling >> the >> world". Not acceptable. >> >> I'll be interested on hearing ideas about how to determine how a >> function returns a small struct, without knowing the internals of the >> struct. >> >> -- >> Oscar >> >> _______________________________________________ >> 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 Wed Mar 26 11:56:04 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Wed, 26 Mar 2008 19:56:04 +0300 Subject: [LLVMdev] Wrong calling convention? In-Reply-To: <63v9ean5.fsf.SS1768SS@telefonica.net> References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf.SS1768SS@telefonica.net> Message-ID: <1206550564.16812.232.camel@asl.dorms.spbu.ru> Hello, Oscar > This is C++ land, so there is no "platform ABI", Well, here is g++ ABI :) > following the platform ABI, after all. > > BTW, -fpcc-struct-return solves the case that motivated this thread. Usually, special rules are applied for returning struct, if its size is small enough. So you can definitely find something small returned via registers. This is frontend job to select how to pass such object. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From edwintorok at gmail.com Wed Mar 26 14:23:47 2008 From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=) Date: Wed, 26 Mar 2008 21:23:47 +0200 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47EA98D7.6020409@lip6.fr> References: <47E42E20.60505@lip6.fr> <47E4E1E7.2070707@gmail.com> <47EA98D7.6020409@lip6.fr> Message-ID: <47EAA2C3.8050104@gmail.com> Nicolas Geoffray wrote: > Very nice Torok! I applied most of the patch. A few comments: > Thanks! > 1) What is your jni.h file? I can't compile the Jni.cpp file with your > changes. > Ouch, did they change 'const'-ness between gcj versions? I was using gcj-4.2.3, and jni.h is from libgcj8-dev. > 2) ISO C++ does not support %jd. x86_64 does not know about %lld? > It does, but gcc gives a warning, if I use %lld I get a warning on x86_64, if I %ld I get a warning on x86-32. int64_t is long int on x86-64. However sizeof(long int) == sizeof(long long int), so I don't know why gcc insists it is wrong. I only found %jd which doesn't give warnings on either: #include #include int main() { int64_t x=0; printf("%ld",x); printf("%lld",x); printf("%jd",x); return 0; } $ gcc -Wall -O2 p.c p.c: In function ?main?: p.c:7: warning: format ?%lld? expects type ?long long int?, but argument 2 has type ?int64_t? $ gcc -Wall -O2 p.c -m32 p.c: In function ?main?: p.c:6: warning: format ?%ld? expects type ?long int?, but argument 2 has type ?int64_t? Best regards, --Edwin From mrs at apple.com Wed Mar 26 14:47:15 2008 From: mrs at apple.com (Mike Stump) Date: Wed, 26 Mar 2008 12:47:15 -0700 Subject: [LLVMdev] compile programs with the LLVM compiler In-Reply-To: <347f9e8c0803261007x393c238xeb2a44b37cd24233@mail.gmail.com> References: <347f9e8c0803261007x393c238xeb2a44b37cd24233@mail.gmail.com> Message-ID: On Mar 26, 2008, at 10:07 AM, karthik parvathaneni wrote: > can anyone please help me out with a detailed description of the > project ??? What part of the web site wasn't detailed enough? > i mean is it just writing codes and compiling using the compiler or > something else ??? Pretty much. Some people write code, some people use the compiler... From shap at eros-os.com Wed Mar 26 14:48:17 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 15:48:17 -0400 Subject: [LLVMdev] Wrong calling convention? In-Reply-To: <1206550564.16812.232.camel@asl.dorms.spbu.ru> References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf.SS1768SS@telefonica.net> <1206550564.16812.232.camel@asl.dorms.spbu.ru> Message-ID: <1206560898.4523.5.camel@mikado64.cs.jhu.edu> On Wed, 2008-03-26 at 19:56 +0300, Anton Korobeynikov wrote: > Usually, special rules are applied for returning struct, if its size is > small enough. So you can definitely find something small returned via > registers. This is frontend job to select how to pass such object. It is true that many calling conventions optimize small structure return. It is the front end's job to *implement* this. It is the responsibility of the calling convention to *specify* this. The front end must comply with the calling convention, or separate compilation is compromised. shap From dpatel at apple.com Wed Mar 26 14:53:01 2008 From: dpatel at apple.com (Devang Patel) Date: Wed, 26 Mar 2008 12:53:01 -0700 Subject: [LLVMdev] compile programs with the LLVM compiler In-Reply-To: <347f9e8c0803261007x393c238xeb2a44b37cd24233@mail.gmail.com> References: <347f9e8c0803261007x393c238xeb2a44b37cd24233@mail.gmail.com> Message-ID: <9BCD172E-24FA-4549-BBA4-A3E9328AEEBD@apple.com> On Mar 26, 2008, at 10:07 AM, karthik parvathaneni wrote: > hello everyone ... my name is Karthik Parvathaneni ... and i am > interested in working on this project ... welcome! > can anyone please help me out with a detailed description of the > project ??? .... see www.llvm.org > i mean is it just writing codes and compiling using the compiler or > something else ??? .. This project develops the compiler that you can use to compile code written in supported programming languages. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080326/e79dcbdd/attachment.html From naasking at gmail.com Wed Mar 26 14:55:34 2008 From: naasking at gmail.com (Sandro Magi) Date: Wed, 26 Mar 2008 15:55:34 -0400 Subject: [LLVMdev] JIT and anonymous procs In-Reply-To: <1206554498.4523.1.camel@mikado64.cs.jhu.edu> References: <1206536789.26804.3.camel@vmx.home> <1206554498.4523.1.camel@mikado64.cs.jhu.edu> Message-ID: <7e2ad2d0803261255t11ab7470hc97b8c71bb89df94@mail.gmail.com> On Wed, Mar 26, 2008 at 2:01 PM, Jonathan S. Shapiro wrote: > > All functions in the tutorial are referenced by their Function*. The > > Function* uniquely identifies a function and is independent of the name. > > I had understood that. > > So now I have compiled and run my top level expression's anonymous > function. How do I go about properly freeing the Function object, > *including* removing the anonymous procedure name from any global symbol > table (if any) and also advising the runtime that the associated IR > module can now be dropped along with everything else that was generated? Freeing the machine code is straightforward: http://llvm.org/doxygen/classllvm_1_1JIT.html#a8 Not sure about the Function instance itself. The delete operator would be my first guess. Sandro From naasking at gmail.com Wed Mar 26 14:59:08 2008 From: naasking at gmail.com (Sandro Magi) Date: Wed, 26 Mar 2008 15:59:08 -0400 Subject: [LLVMdev] JIT and anonymous procs In-Reply-To: <7e2ad2d0803261255t11ab7470hc97b8c71bb89df94@mail.gmail.com> References: <1206536789.26804.3.camel@vmx.home> <1206554498.4523.1.camel@mikado64.cs.jhu.edu> <7e2ad2d0803261255t11ab7470hc97b8c71bb89df94@mail.gmail.com> Message-ID: <7e2ad2d0803261259k57634db4of6f5b6102f31bbe7@mail.gmail.com> On Wed, Mar 26, 2008 at 3:55 PM, Sandro Magi wrote: > Freeing the machine code is straightforward: > > http://llvm.org/doxygen/classllvm_1_1JIT.html#a8 > > Not sure about the Function instance itself. The delete operator would > be my first guess. I believe that may be correct actually, as the Function destructor invokes "dropAllReferences": http://llvm.org/doxygen/classllvm_1_1Function.html#a55 Sandro From baldrick at free.fr Wed Mar 26 15:04:07 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 26 Mar 2008 21:04:07 +0100 Subject: [LLVMdev] Checked arithmetic In-Reply-To: References: <1206501916.23853.13.camel@vmx.home> <1206537564.26804.17.camel@vmx.home> Message-ID: <200803262104.09201.baldrick@free.fr> Hi Chris, > Why not define an "add with overflow" intrinsic that returns its value and > overflow bit as an i1? what's the point? We have this today with apint codegen (if you turn on LegalizeTypes). For example, this function define i1 @cc(i32 %x, i32 %y) { %xx = zext i32 %x to i33 %yy = zext i32 %y to i33 %s = add i33 %xx, %yy %tmp = lshr i33 %s, 32 %b = trunc i33 %tmp to i1 ret i1 %b } codegens (on x86-32) to cc: xorl %eax, %eax movl 4(%esp), %ecx addl 8(%esp), %ecx adcl $0, %eax andl $1, %eax ret which uses the condition code as desired. Pity about the redundant andl $1, %eax! Ciao, Duncan. From sabre at nondot.org Wed Mar 26 15:37:53 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 26 Mar 2008 13:37:53 -0700 (PDT) Subject: [LLVMdev] Checked arithmetic In-Reply-To: <200803262104.09201.baldrick@free.fr> References: <1206501916.23853.13.camel@vmx.home> <1206537564.26804.17.camel@vmx.home> <200803262104.09201.baldrick@free.fr> Message-ID: On Wed, 26 Mar 2008, Duncan Sands wrote: > Hi Chris, > >> Why not define an "add with overflow" intrinsic that returns its value and >> overflow bit as an i1? > > what's the point? We have this today with apint codegen (if you turn on > LegalizeTypes). For example, this function The desired code is something like: foo: addl %eax, %ecx jo overflow_happened use(%ecx) etc. -Chris > define i1 @cc(i32 %x, i32 %y) { > %xx = zext i32 %x to i33 > %yy = zext i32 %y to i33 > %s = add i33 %xx, %yy > %tmp = lshr i33 %s, 32 > %b = trunc i33 %tmp to i1 > ret i1 %b > } > > codegens (on x86-32) to > > cc: > xorl %eax, %eax > movl 4(%esp), %ecx > addl 8(%esp), %ecx > adcl $0, %eax > andl $1, %eax > ret > > which uses the condition code as desired. Pity about the > redundant andl $1, %eax! > > Ciao, > > Duncan. > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Wed Mar 26 16:10:49 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 26 Mar 2008 14:10:49 -0700 (PDT) Subject: [LLVMdev] JIT and anonymous procs In-Reply-To: <1206554498.4523.1.camel@mikado64.cs.jhu.edu> References: <1206536789.26804.3.camel@vmx.home> <1206554498.4523.1.camel@mikado64.cs.jhu.edu> Message-ID: On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: >> All functions in the tutorial are referenced by their Function*. The >> Function* uniquely identifies a function and is independent of the name. > > I had understood that. > > So now I have compiled and run my top level expression's anonymous > function. How do I go about properly freeing the Function object, > *including* removing the anonymous procedure name from any global symbol > table (if any) and also advising the runtime that the associated IR > module can now be dropped along with everything else that was generated? // Free JIT'd machine code: EE->freeMachineCodeForFunction(F); // Delete functions and IR: F->eraseFromParent(); -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Wed Mar 26 16:11:52 2008 From: sabre at nondot.org (Chris Lattner) Date: Wed, 26 Mar 2008 14:11:52 -0700 (PDT) Subject: [LLVMdev] Checked arithmetic In-Reply-To: <1206554567.4523.3.camel@mikado64.cs.jhu.edu> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> Message-ID: On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: >> Why not define an "add with overflow" intrinsic that returns its value and >> overflow bit as an i1? > > Chris: > > I understand several simple ways to implement add with carry. Your > suggestion is one of them. What I'm trying to understand is how to > handle the conditional code issue generally. I'm suggesting basically: res,overflow = add_with_cary(a,b); if (overflow) goto somewhere use(res) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From baldrick at free.fr Wed Mar 26 15:55:50 2008 From: baldrick at free.fr (Duncan Sands) Date: Wed, 26 Mar 2008 21:55:50 +0100 Subject: [LLVMdev] Checked arithmetic In-Reply-To: References: <1206501916.23853.13.camel@vmx.home> <200803262104.09201.baldrick@free.fr> Message-ID: <200803262155.51600.baldrick@free.fr> Hi Chris, > > what's the point? We have this today with apint codegen (if you turn on > > LegalizeTypes). For example, this function > > The desired code is something like: > > foo: > addl %eax, %ecx > jo overflow_happened > use(%ecx) how's an intrinsic going to help with this? Also, is there any chance of codegen being capable one day of combining carry arithmetic coming from apint and the appropriate conditional branch into a "jo"? Ciao, Duncan. From shap at eros-os.com Wed Mar 26 15:56:01 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 16:56:01 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> Message-ID: <1206564961.28676.4.camel@vmx.home> On Wed, 2008-03-26 at 14:11 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > >> Why not define an "add with overflow" intrinsic that returns its value and > >> overflow bit as an i1? > > > > Chris: > > > > I understand several simple ways to implement add with carry. Your > > suggestion is one of them. What I'm trying to understand is how to > > handle the conditional code issue generally. > > I'm suggesting basically: > > res,overflow = add_with_cary(a,b); > if (overflow) goto somewhere > use(res) > > -Chris Yes. Sorry. I do see that that will work, and I had not intended to sound ungrateful for your response. It is my nature, when I look at a design problem, to try to consider the whole problem before implementing some part. It may turn out here that there isn't really a "whole problem" to consider. Even if there is, I agree that the shortest path to solving my immediate problem is to do exactly as you suggest. I guess my take is that when faced with an architectural question that you eventually may have to address in full, quick fixes tend to accrete that have to be undone when you get around to the general solution, and these make implementing the general thing harder -- unless you have thought it out in advance and the quick fixes are in line with the eventual solution. Now it may turn out that there isn't any "general thing" here at all. It's just that I'ld like to think that through before adopting what you suggest. shap From clattner at apple.com Wed Mar 26 16:05:25 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 26 Mar 2008 14:05:25 -0700 Subject: [LLVMdev] GSoC applications Message-ID: <398006A1-66B9-426B-8701-F5D0933966C8@apple.com> Hi All, This is a friendly reminder for GSoC applicants that are interested in LLVM. The deadline for applications is March 31: don't forget. :) The scope of acceptable projects includes improvements to llvm itself, clang, and now vmkit as well. -Chris From shap at eros-os.com Wed Mar 26 16:07:23 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 17:07:23 -0400 Subject: [LLVMdev] Hooking the global symbol resolver Message-ID: <1206565643.28676.16.camel@vmx.home> Okay, we're starting to dig in, and I've hit a question that will no doubt seem strange. Context: BitC is a polymorphic language. Since it has unboxed value types, our approach to compiling a polymorphic function is to polyinstantate it -- once for each signature. The name mangling scheme is both stable and reversible. At the site of the use occurrence, we can fully determine the mangled name of the desired instantiation. Given the mangled name of an instantiation that has not yet been synthesized, we can determine which procedure must be synthesized. At present, our front end implements a demand-driven instantiator that proceeds from main() until all calls are statically resolved. It seems to me, however, that this duplicates (nearly) functionality that is probably already present in the LLVM JIT layer. Here is what I am wondering: Is there some way we can "hook" the global symbol resolver so that we can run the polyinstantiator on demand? I *think* this could be done by running the resolver normally, noticing failure on a symbol that we know ought to exist, code generating the instance definition corresponding to the needed symbol, and then re-performing the lookup at global scope. What I'm not sure about here is several issues: 1. Does this make sense? 2. If so, where is the right place to hook the resolver? 3. Are we going to run into trouble arising from the fact that we are likely to end up using the module compiler in a recursive way? That is: the referencing module's compile will (in effect) be paused in its symbol resolution phase while we introduce a new module and compile that. I can imagine implementations where this would wreak serious havoc on the implementation of environments within the LLVM infrastructure. 4. Is there a better/cleaner approach? What other options should I consider? We can, thankfully, ensure that this recursive instantiation exercise terminates. :-) shap From shap at eros-os.com Wed Mar 26 16:14:02 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Wed, 26 Mar 2008 17:14:02 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <200803262155.51600.baldrick@free.fr> References: <1206501916.23853.13.camel@vmx.home> <200803262104.09201.baldrick@free.fr> <200803262155.51600.baldrick@free.fr> Message-ID: <1206566042.28676.23.camel@vmx.home> On Wed, 2008-03-26 at 21:55 +0100, Duncan Sands wrote: > Hi Chris, > > > > what's the point? We have this today with apint codegen (if you turn on > > > LegalizeTypes). For example, this function > > > > The desired code is something like: > > > > foo: > > addl %eax, %ecx > > jo overflow_happened > > use(%ecx) > > ...is there any chance > of codegen being capable one day of combining carry arithmetic coming > from apint and the appropriate conditional branch into a "jo"? This particular use case pattern (cond branch using CC value generated as a side effect of a useful operation) appears often enough to be worth getting right. So if it's beyond what codegen can do, then codegen wants to be fixed. It's clear enough that I can get working code emitted today -- that's not the issue. The concern is that languages supporting non-hardware arithmetic precisions rely on this particular pattern a whole lot. I definitely need to dig in harder and understand how LLVM works before I try to seriously advocate anything on this topic (or any other), but from a surface understanding of the IR, and experience building several prior compilers, I would say that the current IR is very well suited to C and not yet an ideal match to Ada, COBOL, or some other languages. That's not a criticism. Just a statement of first impressions. shap From ofv at wanadoo.es Wed Mar 26 17:09:51 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Wed, 26 Mar 2008 23:09:51 +0100 Subject: [LLVMdev] Wrong calling convention? References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf@telefonica.net> <94A682EF-5A78-405F-9EDE-7C3D681C312B@apple.com> Message-ID: Evan Cheng writes: >> I'll be interested on hearing ideas about how to determine how a >> function returns a small struct, without knowing the internals of the >> struct. > Take a look at llvm-gcc. Look for HandleAggregateShadowArgument. This does not qualify as "without knowing the internals of the struct" :-) DefaultABI::HandleReturnType made an interesting reading, although it uses information which is unaccessible to my compiler. -- Oscar From gohman at apple.com Wed Mar 26 17:16:26 2008 From: gohman at apple.com (Dan Gohman) Date: Wed, 26 Mar 2008 15:16:26 -0700 Subject: [LLVMdev] use-diet design? Message-ID: <89FD8A11-B4BA-4A32-96AD-B6ED1187201A@apple.com> Hi Gabor, Could you give a little more detailed description of the plan with the user-diet changes? I read the README but still don't have a good picture of what will happen. Specifically, which operators new/delete will be overridden? What work will they do? How will the surrogate getters/setters work? Thanks, Dan From dalej at apple.com Wed Mar 26 17:20:29 2008 From: dalej at apple.com (Dale Johannesen) Date: Wed, 26 Mar 2008 15:20:29 -0700 Subject: [LLVMdev] Wrong calling convention? In-Reply-To: References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf@telefonica.net> <94A682EF-5A78-405F-9EDE-7C3D681C312B@apple.com> Message-ID: On Mar 26, 2008, at 3:09 PM, ?scar Fuentes wrote: > Evan Cheng writes: > >>> I'll be interested on hearing ideas about how to determine how a >>> function returns a small struct, without knowing the internals of >>> the >>> struct. > >> Take a look at llvm-gcc. Look for HandleAggregateShadowArgument. > > This does not qualify as "without knowing the internals of the struct" > :-) > > DefaultABI::HandleReturnType made an interesting reading, although it > uses information which is unaccessible to my compiler. Which calling convention to use depends on the contents of the struct. You cannot make all cases work without that information. From ofv at wanadoo.es Wed Mar 26 17:33:18 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Wed, 26 Mar 2008 23:33:18 +0100 Subject: [LLVMdev] Wrong calling convention? References: <200803260906.18508.baldrick@free.fr> <200803261630.06793.baldrick@free.fr> <63v9ean5.fsf@telefonica.net> <056C4942-3D6B-4DE3-8207-2D2F4E8F5B62@vandevoorde.com> Message-ID: David Vandevoorde writes: >> I'll be interested on hearing ideas about how to determine how a >> function returns a small struct, without knowing the internals of the >> struct. > > You need to know _something_ about the internals. [snip] Well, as AFAIK there is no way of gathering that information, putting some checks to ensure that the manually provided type info is correct would be nice, but I'm afraid that there is no way to achieve that either (except for the most simple checks, like the struct size not being large than `double', etc). Boost type_traits does not mention g++ on the list of compilers that has the necessary intrinsics for supporting has_trivial_copier et al. I guess this is off-topic, so thank you all guys for your suggestions. -- Oscar From ofv at wanadoo.es Wed Mar 26 17:48:40 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Wed, 26 Mar 2008 23:48:40 +0100 Subject: [LLVMdev] Hooking the global symbol resolver References: <1206565643.28676.16.camel@vmx.home> Message-ID: "Jonathan S. Shapiro" writes: [snip] > 4. Is there a better/cleaner approach? What other options should I > consider? My front-end is very similar to yours in the feature of the multiple instantiations on demand, etc. One thing I learnt about LLVM is that it's philosophy is to be a friendly backend for frontends, but whatever your frontend does internally is not LLMV's business. Answuring your question, I'm not aware of any LLVM facility for what you describe. And if you find one, I would advise against using it. -- Oscar From gabor at mac.com Wed Mar 26 17:49:34 2008 From: gabor at mac.com (Gabor Greif) Date: Wed, 26 Mar 2008 23:49:34 +0100 Subject: [LLVMdev] use-diet design? Message-ID: <7133CCB0-5308-4DAB-8492-4E9BE49C8B23@mac.com> > Hi Gabor, > > Could you give a little more detailed description of the plan > with the user-diet changes? I read the README but still don't > have a good picture of what will happen. > > Specifically, which operators new/delete will be overridden? > What work will they do? How will the surrogate getters/setters > work? > > Thanks, > > Dan Hi Dan, I am going to summarize rapidly my previous correspondence with Chris. (It is late here, so expect errors.) We have 2 different layouts in the User (sub)classes: Layout a) The Use object(s) are inside of the User object and there are a fixed number of them. Layout b) The Use object(s) are referenced by a pointer to an array from the User object and there may be a variable number of them. Layout a) will be modelled by prepending the User object by the Use[] array. ...---.---.---.---.-------... | 0 | 0 | 2 | 1 | User ```---`---`---`---`-------``` 12 12 12 12 a bit-encoding in the 2 LSBits of the Use::Val will allow to find the start of the User object: 00 --> binary digit 0 01 --> binary digit 1 10 --> stop and calc (s) 11 --> full stop (S) Given a Use*, all we have to do is walk till we get a stop and we either have a User immediately behind or we have to walk to the next stop picking up digits and calculate the offset: .---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.------- --------- | s | 1 | 0 | 1 | 1 | s | 0 | 1 | 1 | 0 | s | 0 | 0 | 0 | 1 | S | User (or User*) '---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'------- --------- +16 +11 +6 +1 |___> |_______________________> |___________________________________________> |_______________________________________________________________> For layout b) instead of the User we will find a pointer (with LSBit set). Following this pointer brings us to the User. For both layouts the location of the User can be calculated rapidly, so there is no need to store Use::U in the Use object. This allows us to shrink its size to 12 (from 16). There are more middle-term savings, like eliminating the User::NumOperands member etc. There will be placement 'operator new' and 'Create' static factories, that will ensure that the layout invariants are met. I hope this gives a bit of a background for discussion. Cheers, Gabor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080326/aee5c2e1/attachment-0001.html From gabor at mac.com Wed Mar 26 17:16:03 2008 From: gabor at mac.com (Gabor Greif) Date: Wed, 26 Mar 2008 23:16:03 +0100 Subject: [LLVMdev] PATCH: Use size reduction -- wave1 Message-ID: <14DB8E59-9B9A-4935-92FF-BD21B15C2225@mac.com> Hi all, here comes the patch for the first wave of Use class size reduction. I have split it into 3 files, corresponding to - header changes - implementation changes - applications This at the moment does not contain the description how the size of the Use class will be reduced from 16 to 12 bytes, I am going to send that in a separate patch. This wave primarily consists of changes that are needed to allocate objects with a variable number of embedded s. Where the number of s is constant in the lifetime of an object, I preferred to keep the 'new Instr(...)' syntax. Otherwise I have introduced static 'Create(...)' methods, which are used instead of the 'new Instr(...)' construct. These replace the constructors and the constructors become private/protected. The arguments of the 'Create' methods are identical to the corresponding constructors. Essentially at the moment all introduced 'operator new's end up calling '::operator new(size_t)', so there should be no functionality change at all. This will change in subsequent waves. At the moment of writing this my trunk working copy is at r48837, I have used this command to do the merge: svn merge http://llvm.org/svn/llvm-project/llvm/branches/ggreif/use- diet at 48564 http://llvm.org/svn/llvm-project/llvm/branches/ggreif/use- diet . This is what it printed on the console: U include/llvm/BasicBlock.h U include/llvm/GlobalVariable.h U include/llvm/Support/LLVMBuilder.h U include/llvm/Instructions.h U include/llvm/GlobalAlias.h U include/llvm/Constants.h U include/llvm/User.h U include/llvm/InstrTypes.h U include/llvm/Function.h U tools/bugpoint/CrashDebugger.cpp U tools/bugpoint/Miscompilation.cpp U lib/Analysis/ScalarEvolutionExpander.cpp U lib/CodeGen/ShadowStackCollector.cpp U lib/CodeGen/IntrinsicLowering.cpp U lib/Linker/LinkModules.cpp U lib/Target/X86/X86TargetAsmInfo.cpp U lib/Bitcode/Reader/BitcodeReader.cpp U lib/ExecutionEngine/JIT/JIT.cpp U lib/VMCore/Instructions.cpp U lib/VMCore/Constants.cpp U lib/VMCore/AutoUpgrade.cpp U lib/VMCore/Function.cpp U lib/VMCore/Module.cpp U lib/VMCore/Core.cpp U lib/VMCore/BasicBlock.cpp U lib/AsmParser/llvmAsmParser.y U lib/AsmParser/llvmAsmParser.cpp.cvs U lib/AsmParser/llvmAsmParser.h.cvs U lib/AsmParser/llvmAsmParser.y.cvs U lib/Transforms/Utils/LowerInvoke.cpp U lib/Transforms/Utils/LCSSA.cpp U lib/Transforms/Utils/CodeExtractor.cpp U lib/Transforms/Utils/CloneModule.cpp U lib/Transforms/Utils/CloneFunction.cpp U lib/Transforms/Utils/BreakCriticalEdges.cpp U lib/Transforms/Utils/LowerSwitch.cpp U lib/Transforms/Utils/SimplifyCFG.cpp U lib/Transforms/Utils/BasicBlockUtils.cpp U lib/Transforms/Utils/LowerAllocations.cpp U lib/Transforms/Utils/UnifyFunctionExitNodes.cpp U lib/Transforms/Utils/InlineFunction.cpp U lib/Transforms/Utils/LoopSimplify.cpp U lib/Transforms/Utils/PromoteMemoryToRegister.cpp U lib/Transforms/Utils/Local.cpp U lib/Transforms/Instrumentation/RSProfiling.cpp U lib/Transforms/Instrumentation/ProfilingUtils.cpp U lib/Transforms/Scalar/LoopUnswitch.cpp U lib/Transforms/Scalar/IndVarSimplify.cpp U lib/Transforms/Scalar/GVNPRE.cpp U lib/Transforms/Scalar/InstructionCombining.cpp U lib/Transforms/Scalar/SimplifyCFG.cpp U lib/Transforms/Scalar/TailRecursionElimination.cpp U lib/Transforms/Scalar/LoopIndexSplit.cpp U lib/Transforms/Scalar/LoopStrengthReduce.cpp U lib/Transforms/Scalar/GCSE.cpp U lib/Transforms/Scalar/ScalarReplAggregates.cpp U lib/Transforms/Scalar/SCCP.cpp U lib/Transforms/Scalar/LoopRotation.cpp U lib/Transforms/Scalar/GVN.cpp U lib/Transforms/Scalar/ADCE.cpp U lib/Transforms/IPO/IndMemRemoval.cpp U lib/Transforms/IPO/SimplifyLibCalls.cpp U lib/Transforms/IPO/PruneEH.cpp U lib/Transforms/IPO/StructRetPromotion.cpp U lib/Transforms/IPO/ExtractGV.cpp U lib/Transforms/IPO/LowerSetJmp.cpp Skipped missing target: 'lib/Transforms/IPO/ExtractFunction.cpp' U lib/Transforms/IPO/GlobalOpt.cpp U lib/Transforms/IPO/DeadArgumentElimination.cpp U lib/Transforms/IPO/ArgumentPromotion.cpp U lib/Transforms/IPO/RaiseAllocations.cpp U examples/BrainF/BrainF.cpp U examples/BrainF/BrainFDriver.cpp U examples/ParallelJIT/ParallelJIT.cpp U examples/HowToUseJIT/HowToUseJIT.cpp U examples/ModuleMaker/ModuleMaker.cpp U examples/Fibonacci/fibonacci.cpp Notes: - I shall take the *.cvs files out of the patch. - lib/Transforms/IPO/ExtractFunction.cpp seems to have been deleted from trunk - GVN.cpp had a compile error due to changes --> I had to manually change the file emacs +1224 lib/Transforms/Scalar/GVN.cpp emacs +1231 lib/Transforms/Scalar/GVN.cpp - the patch is pretty dull, mostly mechanical changes - r48837 + this patch builds and the tests run without errors - I have omitted Create-ifying llvm-upgrade, as it is not on trunk any more - Some statistics: ggreif$ svn diff include > wave1-include.diff ggreif$ svn diff lib > wave1-lib.diff ggreif$ svn diff examples tools > wave1-rest.diff ggreif$ wc *.diff 798 3883 33028 wave1-include.diff 3894 16494 179719 wave1-lib.diff 441 1769 18291 wave1-rest.diff 5133 22146 231038 total - I cared about o Tab-freeness o correct re-indentation - I did not (yet) care about the 80-column regime - the explanation of my wave nomenclature is here: svn cat http(s)://llvm.org/svn/llvm-project/llvm/branches/ggreif/ README Cheers, Gabor -------------- next part -------------- A non-text attachment was scrubbed... Name: wave1-include.diff Type: application/octet-stream Size: 33028 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080326/4170df6b/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: wave1-lib.diff Type: application/octet-stream Size: 179719 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080326/4170df6b/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: wave1-rest.diff Type: application/octet-stream Size: 18291 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080326/4170df6b/attachment-0005.obj -------------- next part -------------- From arnold.schwaighofer at gmail.com Thu Mar 27 01:29:24 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Thu, 27 Mar 2008 07:29:24 +0100 Subject: [LLVMdev] RFC: tailcall ppc32 patch Message-ID: Hi there, it's me again. attached is preliminary support for tail calls on ppc 32. (once i get access to a 64bit machine that part will follow). It has passed the llvm-test with the -tailcallopt flag enabled. (after half a day on an old g4/800 :) okay to submit? probably not. :) suggestions. regards arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: tc-ppc.patch Type: text/x-patch Size: 57249 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080327/e0b978f0/attachment-0001.bin From chandlerc at gmail.com Thu Mar 27 01:47:23 2008 From: chandlerc at gmail.com (Chandler Carruth) Date: Wed, 26 Mar 2008 23:47:23 -0700 Subject: [LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64 In-Reply-To: <8E416D69-4749-4231-8279-F733E2645265@gmail.com> References: <18edb2ad0803242349h19382b18o710cd06d80945b04@mail.gmail.com> <8E416D69-4749-4231-8279-F733E2645265@gmail.com> Message-ID: <18edb2ad0803262347t52f88417o3218fdc9ceca270f@mail.gmail.com> Bam. This is about as reduced as it gets. I think I can spot the problem point: chandlerc at osiris ~/code/compilers/build/llvm-gcc $ cat testcase.i void foo () { float x __attribute__ ((mode (XF))); } chandlerc at osiris ~/code/compilers/build/llvm-gcc $ ./gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): Assertion `(!(__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size) || !Ty->isSized() || !isInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) == getTargetData().getABITypeSizeInBits(Ty)) && "LLVM type size doesn't match GCC type size!"' failed. testcase.i: In function 'foo': testcase.i:2: internal compiler error: Aborted Hope that helps. =] -Chandler PS: delta hates me, and this test case, a lot. reduced it by hand. On Tue, Mar 25, 2008 at 12:51 AM, Bill Wendling wrote: > Hi Chandler, > > This looks like a FE error, so you probably won't be able to get an > LLVM bitcode file for us. You could help by whittling the test case > down to something managable. First get a preprocessed file. Then I > would suggest following the instructions on this page to reduce the > testcase: > > http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction > > That will help us a lot with the bug report. > > -bw > > > > On Mar 24, 2008, at 11:49 PM, Chandler Carruth wrote: > > Hello, > > > > Trying to get my machine building up-to-date, and a nightly going, i > > ran into an assertion during the build of llvm-gcc 4.2: > > > > $ make -j2 > > > > /home/chandlerc/code/compilers/build/llvm-gcc/./gcc/xgcc > > -B/home/chandlerc/code/compilers/build/llvm-gcc/./gcc/ > > -B/home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux- > > gnu/bin/ > > -B/home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux- > > gnu/lib/ > > -isystem /home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc- > > linux-gnu/include > > -isystem /home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc- > > linux-gnu/sys-include > > -O2 -O2 -march=k8 -mfpmath=sse -pipe -DIN_GCC -W -Wall > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > > -Wold-style-definition -isystem ./include -fPIC -g > > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. > > -I/home/chandlerc/code/compilers/llvm-gcc/gcc > > -I/home/chandlerc/code/compilers/llvm-gcc/gcc/. > > -I/home/chandlerc/code/compilers/llvm-gcc/gcc/../include > > -I/home/chandlerc/code/compilers/llvm-gcc/gcc/../libcpp/include > > -I/home/chandlerc/code/compilers/llvm-gcc/gcc/../libdecnumber > > -I../libdecnumber -I/home/chandlerc/code/compilers/llvm/include > > -I/home/chandlerc/code/compilers/build/llvm/include -DL_powitf2 -c > > /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c -o > > libgcc/./_powitf2.o > > cc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: > > const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): > > Assertion `(!(__extension__ ({ const tree __t = (Tr); if > > (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != > > (tcc_type)) tree_class_check_failed (__t, (tcc_type), > > "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, > > __FUNCTION__); __t; })->type.size) || !Ty->isSized() || > > !isInt64((__extension__ ({ const tree __t = (Tr); if > > (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != > > (tcc_type)) tree_class_check_failed (__t, (tcc_type), > > "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, > > __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ > > ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) > > (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, > > (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm- > > types.cpp", > > 81, __FUNCTION__); __t; })->type.size), true) == > > getTargetData().getABITypeSizeInBits(Ty)) && "LLVM type size doesn't > > match GCC type size!"' failed. > > /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c: In function > > '__powixf2': > > /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c:1765: internal > > compiler error: Aborted > > > > My configure: > > .../configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu > > --target=x86_64-pc-linux-gnu > > --prefix=/home/chandlerc/code/compilers/install/llvm-gcc > > --disable-multilib --disable-shared > > --enable-llvm=/home/chandlerc/code/compilers/build/llvm > > --program-prefix=llvm- --enable-languages=c,c++ > > > > If more information would help, just let me know. > > > > -Chandler > > _______________________________________________ > > 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 idadesub at users.sourceforge.net Thu Mar 27 03:30:31 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Thu, 27 Mar 2008 01:30:31 -0700 Subject: [LLVMdev] first two chapters for the ocaml bindings in svn Message-ID: <1ef034530803270130h3dfb407fv721a7128e817709c@mail.gmail.com> I've just committed the first two chapters of my ocaml llvm bindings tutorial by porting the Kaleidoscope tutorial to ocaml. These chapters are the lexer and parser. If anyone is interest in trying it out, I'd love any feedback. If you've got the svn trunk checked out, you'll find the docs here: docs/tutorial/OCamlLangImpl1.html docs/tutorial/OCamlLangImpl2.html If not, you can view the css-less version here for those without llvm checked out: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/OCamlLangImpl1.html?revision=48871 http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/OCamlLangImpl2.html?revision=48871 In order to get it to run the examples, you'll need the svn trunk version of llvm, ocaml 3.10 installed, and llvm configured with ocaml support. I'll try to finish up the rest of the tutorial over the next couple days. From baldrick at free.fr Thu Mar 27 03:18:53 2008 From: baldrick at free.fr (Duncan Sands) Date: Thu, 27 Mar 2008 09:18:53 +0100 Subject: [LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64 In-Reply-To: <18edb2ad0803262347t52f88417o3218fdc9ceca270f@mail.gmail.com> References: <18edb2ad0803242349h19382b18o710cd06d80945b04@mail.gmail.com> <8E416D69-4749-4231-8279-F733E2645265@gmail.com> <18edb2ad0803262347t52f88417o3218fdc9ceca270f@mail.gmail.com> Message-ID: <200803270918.55448.baldrick@free.fr> Hi Chandler, > void > foo () { > float x __attribute__ ((mode (XF))); > } nice reduction. I don't see any problem on x86-32, and I don't have access to an x86-64 box right now. Can you please open a PR for this, and also run in the debugger. When you hit the abort, use "up" to go up a stack frame or two or three, and print out the gcc types [use: call debug_tree(type) ] and the LLVM type [use: call Ty->dump() ]. Thanks, Duncan. From nicolas.geoffray at lip6.fr Thu Mar 27 05:17:26 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Thu, 27 Mar 2008 11:17:26 +0100 Subject: [LLVMdev] GSoC applications for vmkit Message-ID: <47EB7436.6030508@lip6.fr> Following Chris reminder, here is a list of projects that VMKit (hence JnJVM and N3) would profit off. Projects I can mentor: (no preferences) 1) Generating shared libraries in LLVM bitcode or in the ELF/MachO format. This will enable many features such as not recompiling Java or CLI bytecode, optimize memory footprint. We could also generate executables and do a whole program analysis and transformation. 2) Hotspot like llvm: being able to switch between interpreter and compiler, choosing which optimizations to perform on the code, doing on-stack replacement 3) Virtual-machine optimizations: removal of null checks, implement optimizations for the Isolate API (many apps executing on the same JVM), removal of array bounds checks, implement thin locks 4) Port VMKit to different platforms: currently, it compiles and runs on gentoo linux/x86 and linux/ppc . At least, it would be nice to have a port of vmkit to darwin/ppc, darwin/x86, linux/x86_64, darwin/arm and linux/arm. 5) Do a test-suite for VMKit. 6) Make VMKit more robust: a better build system, code review and cleanup, integrate LLVM patch in LLVM svn. 7) Implement generics in N3 8) Interface VMKit with LLVM's GC facilities 9) Interface VMKit with another classpath library: currently only gnu-classpath is supported. One could add the open-sourced Sun library. Projects I could mentor, but an other mentor would be best: 10) Implement a type-based alias analysis in LLVM 11) Implement non-call exception handling in LLVM 12) Implement a generational and accurate garbage collector with LLVM GC intrinsics Projects I can not mentor: 13) Implement arithmetic overflow detection in LLVM Nicolas From gordonhenriksen at mac.com Thu Mar 27 06:44:22 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Thu, 27 Mar 2008 07:44:22 -0400 Subject: [LLVMdev] Hooking the global symbol resolver In-Reply-To: <1206565643.28676.16.camel@vmx.home> References: <1206565643.28676.16.camel@vmx.home> Message-ID: Hi Jonathan, In the context of a static compiler, I would recommend that you implement your own ?on the side? symbol table in order to track this state and perform on-demand instantiation as required. It is worthwhile to consider the LLVM module to be a passive output sink, not an active object. The JIT compiler, by contrast, is an active object, cooperating with its environment via the ModuleProvider interface. Overriding materializeFunction should be useful for on-demand instantiation. ? Gordon On Mar 26, 2008, at 17:07, Jonathan S. Shapiro wrote: > Okay, we're starting to dig in, and I've hit a question that will no > doubt seem strange. > > Context: BitC is a polymorphic language. Since it has unboxed value > types, our approach to compiling a polymorphic function is to > polyinstantate it -- once for each signature. > > The name mangling scheme is both stable and reversible. At the site > of the use occurrence, we can fully determine the mangled name of > the desired instantiation. Given the mangled name of an > instantiation that has not yet been synthesized, we can determine > which procedure must be synthesized. > > At present, our front end implements a demand-driven instantiator > that proceeds from main() until all calls are statically resolved. > > It seems to me, however, that this duplicates (nearly) functionality > that is probably already present in the LLVM JIT layer. > > Here is what I am wondering: > > Is there some way we can "hook" the global symbol resolver so that > we can run the polyinstantiator on demand? I *think* this could be > done by running the resolver normally, noticing failure on a symbol > that we know ought to exist, code generating the instance definition > corresponding to the needed symbol, and then re-performing the > lookup at global scope. > > What I'm not sure about here is several issues: > > 1. Does this make sense? > > 2. If so, where is the right place to hook the resolver? > > 3. Are we going to run into trouble arising from the fact that we > are likely to end up using the module compiler in a recursive > way? That is: the referencing module's compile will (in effect) be > paused in its symbol resolution phase while we introduce a new > module and compile that. I can imagine implementations where this > would wreak serious havoc on the implementation of environments > within the LLVM infrastructure. > > 4. Is there a better/cleaner approach? What other options should I > consider? > > We can, thankfully, ensure that this recursive instantiation > exercise terminates. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080327/6cd566a2/attachment-0001.html From tromey at redhat.com Thu Mar 27 08:22:51 2008 From: tromey at redhat.com (Tom Tromey) Date: Thu, 27 Mar 2008 07:22:51 -0600 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47EAA2C3.8050104@gmail.com> (=?utf-8?B?IlTDtnLDtms=?= Edwin"'s message of "Wed\, 26 Mar 2008 21\:23\:47 +0200") References: <47E42E20.60505@lip6.fr> <47E4E1E7.2070707@gmail.com> <47EA98D7.6020409@lip6.fr> <47EAA2C3.8050104@gmail.com> Message-ID: >>>>> "T?r?k" == T?r?k Edwin writes: >> 1) What is your jni.h file? I can't compile the Jni.cpp file with your >> changes. T?r?k> Ouch, did they change 'const'-ness between gcj versions? T?r?k> I was using gcj-4.2.3, and jni.h is from libgcj8-dev. It looks like we did change it, in Classpath, in 2007. I assume it was for compatibility with the JNI spec; JNI is supposed to be both source- and binary-compatible across VMs, and we try very hard to preserve this. Tom From regehr at cs.utah.edu Thu Mar 27 10:51:13 2008 From: regehr at cs.utah.edu (John Regehr) Date: Thu, 27 Mar 2008 09:51:13 -0600 (MDT) Subject: [LLVMdev] Checked arithmetic In-Reply-To: <1206564961.28676.4.camel@vmx.home> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> Message-ID: On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > I guess my take is that when faced with an architectural question that > you eventually may have to address in full, quick fixes tend to accrete > that have to be undone when you get around to the general solution, and > these make implementing the general thing harder -- unless you have > thought it out in advance and the quick fixes are in line with the > eventual solution. Hey, you need to be careful with this reasoning or else you'll end up implementing a whole new language, compiler, and OS. Oh wait nevermind :). John From chandlerc at gmail.com Thu Mar 27 10:52:57 2008 From: chandlerc at gmail.com (Chandler Carruth) Date: Thu, 27 Mar 2008 08:52:57 -0700 Subject: [LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64 In-Reply-To: <200803270918.55448.baldrick@free.fr> References: <18edb2ad0803242349h19382b18o710cd06d80945b04@mail.gmail.com> <8E416D69-4749-4231-8279-F733E2645265@gmail.com> <18edb2ad0803262347t52f88417o3218fdc9ceca270f@mail.gmail.com> <200803270918.55448.baldrick@free.fr> Message-ID: <18edb2ad0803270852y5515d974s1540a0685ac5d29a@mail.gmail.com> Here you go: Starting program: /home/chandlerc/code/compilers/build/llvm-gcc/gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): Assertion `(!(__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm- types.cpp", 81, __FUNCTION__); __t; })->type.size) || !Ty->isSized() || !isInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)-> common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) == getTargetData().getABITypeSizeInBits(Ty)) && "LLVM type size doesn't match GCC type size!"' failed. [New Thread 0x2b709e7b8440 (LWP 15687)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x2b709e7b8440 (LWP 15687)] 0x00002b709e48afa5 in raise () from /lib/libc.so.6 (gdb) up #1 0x00002b709e48ca00 in abort () from /lib/libc.so.6 (gdb) up #2 0x00002b709e4843df in __assert_fail () from /lib/libc.so.6 (gdb) up #3 0x0000000000a84d3b in llvm_set_type (Tr=0x2b709d6f8790, Ty=0x166c210) at /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:78 78 assert((!TYPE_SIZE(Tr) || !Ty->isSized() || !isInt64(TYPE_SIZE(Tr), true) || (gdb) Ty->dump() Undefined command: "Ty->dump". Try "help". (gdb) call Ty->dump() x86_fp80 (gdb) call debug_tree(type) No symbol "type" in current context. (gdb) up #4 0x0000000000a86501 in TypeConverter::ConvertType (this=0x16941a0, orig_type=0x2b709d6f8790) at /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:756 756 case 80: return SET_TYPE_LLVM(type, Type::X86_FP80Ty); (gdb) call debug_tree(type) constant invariant 96> unit size constant invariant 12> align 32 symtab 0 alias set -1 precision 80 pointer_to_this > (gdb) On Thu, Mar 27, 2008 at 1:18 AM, Duncan Sands wrote: > Hi Chandler, > > > > void > > foo () { > > float x __attribute__ ((mode (XF))); > > } > > nice reduction. I don't see any problem on x86-32, > and I don't have access to an x86-64 box right now. > Can you please open a PR for this, and also run in > the debugger. When you hit the abort, use "up" to > go up a stack frame or two or three, and print out > the gcc types [use: call debug_tree(type) ] and the > LLVM type [use: call Ty->dump() ]. > > Thanks, > > Duncan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080327/075975c5/attachment.html From baldrick at free.fr Thu Mar 27 11:04:43 2008 From: baldrick at free.fr (Duncan Sands) Date: Thu, 27 Mar 2008 17:04:43 +0100 Subject: [LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64 In-Reply-To: <18edb2ad0803270852y5515d974s1540a0685ac5d29a@mail.gmail.com> References: <18edb2ad0803242349h19382b18o710cd06d80945b04@mail.gmail.com> <200803270918.55448.baldrick@free.fr> <18edb2ad0803270852y5515d974s1540a0685ac5d29a@mail.gmail.com> Message-ID: <200803271704.44120.baldrick@free.fr> Does this fix it? Index: lib/Target/X86/X86Subtarget.h =================================================================== --- lib/Target/X86/X86Subtarget.h (revision 48879) +++ lib/Target/X86/X86Subtarget.h (working copy) @@ -144,9 +144,12 @@ std::string getDataLayout() const { const char *p; - if (is64Bit()) - p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; - else { + if (is64Bit()) { + if (isTargetDarwin()) + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; + else + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:32:32"; + } else { if (isTargetDarwin()) p = "e-p:32:32-f64:32:64-i64:32:64-f80:128:128"; else From shap at eros-os.com Thu Mar 27 11:21:17 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Thu, 27 Mar 2008 12:21:17 -0400 Subject: [LLVMdev] Hooking the global symbol resolver In-Reply-To: References: <1206565643.28676.16.camel@vmx.home> Message-ID: <1206634877.18767.29.camel@shaptop.om-md.eros-os.com> On Thu, 2008-03-27 at 07:44 -0400, Gordon Henriksen wrote: > In the context of a static compiler, I would recommend that you > implement your own ?on the side? symbol table in order to track this > state and perform on-demand instantiation as required. It is > worthwhile to consider the LLVM module to be a passive output sink, > not an active object. I think I understand what you are saying, but let me delve into this a little further. My main point is that the technique we are after is generally useful for languages having well-integrated template mechanisms. The approach you advocate may still be the best approach, but I'ld like to make sure that we are having the same conversation. Let me illustrate the problem concretely. Consider the BitC primitive definition of lists: (defunion (list 'a) (cons 'a (list 'a)) nil) Modulo surface syntax, this looks on first inspection to be exactly like the corresponding definitions in ML or Haskell. But in ML or Haskell there is only one run-time "expansion" of this type, because all of the possible element types occupy exactly one fundamental unit of storage. This is not true for BitC types. On a 32-bit machine having suitable alignment, the above definition guarantees that variables and bindings of type (list int64) are pointers to boxes whose first element is 64 bits (the int64) and whose second element is 32 bits (the next pointer). That is: the type must be instantiated with different concrete representations for different uses. Since we had to do this anyway, we use the same technique to resolve type classes, thereby eliminating the need for dictionary pointers. The BitC procedure: (define (add-one x) (+ x 1)) has the type: (forall (Arith 'a) (fn ('a) 'a)) which (given our instantiation approach) is best imagined to be a template-like construct -- albeit one that is fully checked for consistency and whose expansion is known not to fail (barring memory exhaustion within the compiler). When a client program uses a dynamic library providing these sorts of constructs, we have two choices: 1. Generate them statically at static link time. This works, but it is not robust across dynamic library version changes (which is an endemic problem in languages that support both templates and dynamic linking). 2. Generate them dynamically at load time (or on first call). This is what we want to do. That is: we want to use a continuous compilation strategy, which is precisely what LLVM is supposedly attempting to achieve. If we adopt the approach that you suggest, we will end up implementing our own "generate on demand" infrastructure that has to operate in collusion with the dynamic loader. We know how to do that, but it is a moderately dicey business. Basically we have to run a pre-resolver before we emit code to an LLVM module, after which LLVM will run a second resolver. I certainly agree that this will work. But I didn't have in mind originally to view Modules as active things. It was not my intention to "extend" a module in mid compile. Rather, it was my thought that we could provide the unresolved symbol by emitting and compiling a second module. Where the LLVM infrastructure currently has something like this: if (!(sym = llvm_resolve_global(GlobalScope, symName))) some_failure_action(); it would now look something like: sym = llvm_resolve_global(GlobalScope, symName); if (!sym && frontend_has_symbol_generator && frontend_generate_symbol(symname)) // Note: if frontend_generate_symbol() has succeeded, it will have // constructed some LLVM Module and called the LLVM compiler to // admit it, with the consequence that GlobalScope will have been // updated to contain a binding for the desired symbol. sym = llvm_resolve_global(GlobalScope, symName); if (!sym) some_failure_action(); I don't think that it's any more complicated than that. This is basically the test that our static polyinstantiator runs right now. Note: I'm still not claiming that this is a good approach in the context of LLVM. I don't have my head wrapped around LLVM enough to have an opinion about that. I simply wanted to make sure that the question was clearly framed. I do, provisionally, think that this particular hook is consistent with the notion of continuous compilation. It seems (to me) necessary (and perhaps even sufficient) to let the front end participate in the continuousness of continuous compilation. shap From shap at eros-os.com Thu Mar 27 11:23:11 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Thu, 27 Mar 2008 12:23:11 -0400 Subject: [LLVMdev] Hooking the global symbol resolver In-Reply-To: References: <1206565643.28676.16.camel@vmx.home> Message-ID: <1206634991.18767.32.camel@shaptop.om-md.eros-os.com> On Wed, 2008-03-26 at 23:48 +0100, ?scar Fuentes wrote: > "Jonathan S. Shapiro" writes: > My front-end is very similar to yours in the feature of the multiple > instantiations on demand, etc. Oscar: after you have a chance to read my recent reply to Gordon, would you be kind enough to let me know whether you still believe the situations are similar. Also whether you think that what I am looking for is likely to be generally useful? > Answuring your question, I'm not aware of any LLVM facility for what you > describe. And if you find one, I would advise against using it. I understand the argument for separation of concerns, but your last sentence concerns me. Why would you recommend against using this kind of mechanism if it exists? Jonathan From shap at eros-os.com Thu Mar 27 11:29:50 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Thu, 27 Mar 2008 12:29:50 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> Message-ID: <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> On Thu, 2008-03-27 at 09:51 -0600, John Regehr wrote: > Hey, you need to be careful with this reasoning or else you'll end up > implementing a whole new language, compiler, and OS. > > Oh wait nevermind :). Don't forget prover. :-) shap From ofv at wanadoo.es Thu Mar 27 12:22:24 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Thu, 27 Mar 2008 18:22:24 +0100 Subject: [LLVMdev] Hooking the global symbol resolver References: <1206565643.28676.16.camel@vmx.home> <1206634991.18767.32.camel@shaptop.om-md.eros-os.com> Message-ID: <3aqccca7.fsf@telefonica.net> "Jonathan S. Shapiro" writes: > On Wed, 2008-03-26 at 23:48 +0100, ?scar Fuentes wrote: >> "Jonathan S. Shapiro" writes: >> My front-end is very similar to yours in the feature of the multiple >> instantiations on demand, etc. > > Oscar: after you have a chance to read my recent reply to Gordon, would > you be kind enough to let me know whether you still believe the > situations are similar. Also whether you think that what I am looking > for is likely to be generally useful? I had no time to read in detail your reply to Gordon (I'll go back to it later), but the similarities are astonishing. I suspect that it is not just a coincidence that we use a lispy syntax (defmacro anyone?). I'll like to learn about your project, so if this is possible, would you like to provide a pointer to some description? (by private e-mail) >> Answuring your question, I'm not aware of any LLVM facility for what you >> describe. And if you find one, I would advise against using it. > > I understand the argument for separation of concerns, but your last > sentence concerns me. Why would you recommend against using this kind of > mechanism if it exists? Whatever LLVM has, it is there either for the convenience of frontend -> backend information flux (note that I exclude the reverse direction) or for the convenience of LLVM itself. Chris et al. are no shy about improving the interfaces when they perceive a clear gain, so there are some chances that whatever you find convenient for your internal stuff today will be not there tomorrow. -- Oscar From callmeno2 at gmail.com Thu Mar 27 12:46:48 2008 From: callmeno2 at gmail.com (karthik parvathaneni) Date: Thu, 27 Mar 2008 23:16:48 +0530 Subject: [LLVMdev] Project help !! LLVM compiler ...testing codes Message-ID: <347f9e8c0803271046g34d78095i5e13aafae14c3f12@mail.gmail.com> hello everyone ... my name is Karthik Parvathaneni ... and i am interested in working on this project ... can anyone please help me out with a detailed description of the project ??? .... i mean is it just writing codes and compiling using the compiler or something else ??? .. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080327/2c8f48c5/attachment.html From criswell at cs.uiuc.edu Thu Mar 27 12:56:59 2008 From: criswell at cs.uiuc.edu (John Criswell) Date: Thu, 27 Mar 2008 12:56:59 -0500 Subject: [LLVMdev] Project help !! LLVM compiler ...testing codes In-Reply-To: <347f9e8c0803271046g34d78095i5e13aafae14c3f12@mail.gmail.com> References: <347f9e8c0803271046g34d78095i5e13aafae14c3f12@mail.gmail.com> Message-ID: <47EBDFEB.5000005@cs.uiuc.edu> karthik parvathaneni wrote: > hello everyone ... my name is Karthik Parvathaneni ... and i am interested in working on this project ... can anyone please help me out with a detailed description of the project ??? .... i mean is it just writing codes and compiling using the compiler or something else ??? .. > If you are referring to the project on the Open Projects page (http://llvm.cs.uiuc.edu/OpenProjects.html), then there are actually two similar projects. The first project is to just use LLVM to compile whatever programs you'd like to compile. These could be programs you've written, programs you're working on (for work or school), or open-source programs. The key is that the programs haven't been compiled using LLVM before; therefore, they may expose bugs in LLVM or show situations in which LLVM does not optimize a program well. The second project is to add programs to the LLVM test suite (http://llvm.cs.uiuc.edu/docs/TestingGuide.html). Naturally, contributions to the llvm-test suite must be open source (as we're redistributing the program's code as part of the test suite). Does this answer your question? -- John T. From regehr at cs.utah.edu Thu Mar 27 13:10:33 2008 From: regehr at cs.utah.edu (John Regehr) Date: Thu, 27 Mar 2008 12:10:33 -0600 (MDT) Subject: [LLVMdev] Checked arithmetic In-Reply-To: <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> Message-ID: > Don't forget prover. :-) Say on that note here's something that I want to see: a formal semantics for LLVM in for example higher order logic. This would probably not be that difficult. The problem that this solves is that current verified compiler efforts appear to be highly specific to both the language and the target. Once the semantics exists, you can either prove once and for all the that each LLVM->LLVM optimization pass preserves the semantics of the code, or else just do translation validation. Verifying the LLVM->native backends should not be incredibly difficult. Verifying a real LLVM front end would be a big projet but substantial headway is being made on that kind of thing for example by Xavier Leroy's group. I've tried to sell some of the HOL folks on this idea (they have a formal semantics for an ARM ISA, for example) but so far no dice. John Regehr From gabor at mac.com Thu Mar 27 13:29:34 2008 From: gabor at mac.com (Gabor Greif) Date: Thu, 27 Mar 2008 19:29:34 +0100 Subject: [LLVMdev] Checked arithmetic Message-ID: <238BD81B-10DB-45E3-BAB8-3634E3CCF321@mac.com> > > Don't forget prover. :-) > > Say on that note here's something that I want to see: a formal > semantics > for LLVM in for example higher order logic. This would probably > not be > that difficult. > > The problem that this solves is that current verified compiler efforts > appear to be highly specific to both the language and the target. > > Once the semantics exists, you can either prove once and for all > the that > each LLVM->LLVM optimization pass preserves the semantics of the > code, or > else just do translation validation. > > Verifying the LLVM->native backends should not be incredibly > difficult. > > Verifying a real LLVM front end would be a big projet but substantial > headway is being made on that kind of thing for example by Xavier > Leroy's > group. > > I've tried to sell some of the HOL folks on this idea (they have a > formal > semantics for an ARM ISA, for example) but so far no dice. > > John Regehr Hi John, some time ago I tried to encode some crucial properties of LLVM IR in Omega (Tim Sheard's system). It looked pretty good, but even encoding basic SSA properties as types (i.e. may only reference an already defined variable) cause your brain to overheat :-) Stefan Monnier [1] has also some papers about provably correct program transformations using an expressive type system. Cheers, Gabor [1] http://www.iro.umontreal.ca/~monnier/tcm.pdf From shap at eros-os.com Thu Mar 27 13:42:19 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Thu, 27 Mar 2008 14:42:19 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> Message-ID: <1206643339.3393.17.camel@shaptop.om-md.eros-os.com> On Thu, 2008-03-27 at 12:10 -0600, John Regehr wrote: > > Don't forget prover. :-) > > Say on that note here's something that I want to see: a formal semantics > for LLVM in for example higher order logic. This would probably not be > that difficult. > > The problem that this solves is that current verified compiler efforts > appear to be highly specific to both the language and the target. Hmm. Maintaining this would impose a significant burden of long-term stability on LLVM. From the rate of change that I see, I suspect that Chris may not be ready to firm things up quite that much just yet. Also, I think that a verified compiler is not the right goal. I think that what we want is a verifying compiler. We are not interested in whether the compiler is correct in any general sense. We are interested in whether the transformations performed by the compiler during some particular compilation are correct. That may be much easier to achieve, but I am not convinced that the LLVM team should adopt it as a goal. Their objectives are already complex enough. shap From pertti.kellomaki at tut.fi Thu Mar 27 14:39:37 2008 From: pertti.kellomaki at tut.fi (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=) Date: Thu, 27 Mar 2008 21:39:37 +0200 Subject: [LLVMdev] Checked arithmetic In-Reply-To: References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> Message-ID: <47EBF7F9.2010504@tut.fi> John Regehr wrote: > Say on that note here's something that I want to see: a formal semantics > for LLVM in for example higher order logic. This would probably not be > that difficult. Except that some aspects of the host platform leak through to .bc files. This may or may not be a problem. > Once the semantics exists, you can either prove once and for all the that > each LLVM->LLVM optimization pass preserves the semantics of the code, or > else just do translation validation. That would be quite nice indeed. > I've tried to sell some of the HOL folks on this idea (they have a formal > semantics for an ARM ISA, for example) but so far no dice. You could sell it to me. How much money do you have? ;-) But seriously, that is something I would very much like to see. One of the reasons why you have not had success may be that with current prover technology, formalizing LLVM semantics and carrying out proofs would be a fairly straightforward exercise, but not a trivial amount of work. Not a good combination in academic sense. On the other hand, formalizing LLVM and proving some properties would make for a very nice open source proof project, which would be an interesting beast. -- Pertti From shap at eros-os.com Thu Mar 27 15:03:41 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Thu, 27 Mar 2008 16:03:41 -0400 Subject: [LLVMdev] Host leak-through In-Reply-To: <47EBF7F9.2010504@tut.fi> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> <47EBF7F9.2010504@tut.fi> Message-ID: <1206648221.3393.64.camel@shaptop.om-md.eros-os.com> On Thu, 2008-03-27 at 21:39 +0200, Pertti Kellom?ki wrote: > Except that some aspects of the host platform leak through > to .bc files. This may or may not be a problem. A question about this occurred to me last night. BitC has only one machine-dependent type: word. The current runtime.h file typedef's this in a machine-dependent way, but all of the C code emitted by our current back end uses the typedef. Originally we intended to have a self-hosting compiler, and this provided us with a way to do bootstrap. LLVM has a back end that emits C code. How machine dependent is the emitted C code? shap From gordonhenriksen at mac.com Thu Mar 27 15:15:08 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Thu, 27 Mar 2008 16:15:08 -0400 Subject: [LLVMdev] first two chapters for the ocaml bindings in svn In-Reply-To: <1ef034530803270130h3dfb407fv721a7128e817709c@mail.gmail.com> References: <1ef034530803270130h3dfb407fv721a7128e817709c@mail.gmail.com> Message-ID: <25F90438-E1B0-4083-A33A-D900B28569FE@mac.com> On Mar 27, 2008, at 04:30, Erick Tryzelaar wrote: > I've just committed the first two chapters of my ocaml llvm bindings > tutorial by porting the Kaleidoscope tutorial to ocaml. These chapters > are the lexer and parser. If anyone is interest in trying it out, I'd > love any feedback. If you've got the svn trunk checked out, you'll > find the docs here: > > docs/tutorial/OCamlLangImpl1.html > docs/tutorial/OCamlLangImpl2.html > > If not, you can view the css-less version here for those without llvm > checked out: > > http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/OCamlLangImpl1.html?revision=48871 > http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/OCamlLangImpl2.html?revision=48871 > > In order to get it to run the examples, you'll need the svn trunk > version of llvm, ocaml 3.10 installed, and llvm configured with ocaml > support. I'll try to finish up the rest of the tutorial over the next > couple days. Looks fantastic so far. I'll take a deeper look this weekend. ? Gordon From regehr at cs.utah.edu Thu Mar 27 15:20:24 2008 From: regehr at cs.utah.edu (John Regehr) Date: Thu, 27 Mar 2008 14:20:24 -0600 (MDT) Subject: [LLVMdev] Checked arithmetic In-Reply-To: <1206643339.3393.17.camel@shaptop.om-md.eros-os.com> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> <1206643339.3393.17.camel@shaptop.om-md.eros-os.com> Message-ID: > Also, I think that a verified compiler is not the right goal. I think > that what we want is a verifying compiler. We are not interested in > whether the compiler is correct in any general sense. We are interested > in whether the transformations performed by the compiler during some > particular compilation are correct. My intuition is the same: translation validation sounds far easier than compiler verification. On the other hand general-purpose translation validation does not exist (that I know of) whereas the compiler verification people are making genuine steps forward: http://pauillac.inria.fr/~xleroy/publi-by-topic.html#compcert > That may be much easier to achieve, but I am not convinced that the LLVM > team should adopt it as a goal. Their objectives are already complex > enough. I agree, I was thinking of this as a separate project based on a fork of LLVM. If it happened to be wildly successful, some aspects could be folded back in. John From ofv at wanadoo.es Thu Mar 27 15:22:16 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Thu, 27 Mar 2008 21:22:16 +0100 Subject: [LLVMdev] Hooking the global symbol resolver References: <1206565643.28676.16.camel@vmx.home> <1206634877.18767.29.camel@shaptop.om-md.eros-os.com> Message-ID: "Jonathan S. Shapiro" writes: [snip] > if (!(sym = llvm_resolve_global(GlobalScope, symName))) > some_failure_action(); > > it would now look something like: > > sym = llvm_resolve_global(GlobalScope, symName); > if (!sym && frontend_has_symbol_generator > && frontend_generate_symbol(symname)) > // Note: if frontend_generate_symbol() has succeeded, it will have > // constructed some LLVM Module and called the LLVM compiler to > // admit it, with the consequence that GlobalScope will have been > // updated to contain a binding for the desired symbol. > sym = llvm_resolve_global(GlobalScope, symName); > if (!sym) > some_failure_action(); > > I don't think that it's any more complicated than that. This is > basically the test that our static polyinstantiator runs right now. > > Note: I'm still not claiming that this is a good approach in the context > of LLVM. I don't have my head wrapped around LLVM enough to have an > opinion about that. I simply wanted to make sure that the question was > clearly framed. > > I do, provisionally, think that this particular hook is consistent with > the notion of continuous compilation. It seems (to me) necessary (and > perhaps even sufficient) to let the front end participate in the > continuousness of continuous compilation. I'm all for hooks and delegation, but the problem here is that your proposal is not general enough and is hard to generalize it. It does not work for my project, for instance, although I face almost the same requirements than you wrt dynamic generation. The symbol name is enough for you, but not for me, and there is no way to teach LLVM about what info I need. This doesn't mean that the LLVM developers shouldn't consider your proposal on the context of the typical LLVM user. Maybe your case is common enough. -- Oscar From shap at eros-os.com Thu Mar 27 15:30:54 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Thu, 27 Mar 2008 16:30:54 -0400 Subject: [LLVMdev] Hooking the global symbol resolver In-Reply-To: References: <1206565643.28676.16.camel@vmx.home> <1206634877.18767.29.camel@shaptop.om-md.eros-os.com> Message-ID: <1206649854.3393.93.camel@shaptop.om-md.eros-os.com> On Thu, 2008-03-27 at 21:22 +0100, ?scar Fuentes wrote: > I'm all for hooks and delegation, but the problem here is that your > proposal is not general enough and is hard to generalize it. It does not > work for my project, for instance, although I face almost the same > requirements than you wrt dynamic generation. The symbol name is enough > for you, but not for me, and there is no way to teach LLVM about what > info I need. Is this because you have a more complicated scenario, or is it because your name mangling scheme is not sufficiently well designed? The evolution of mangling schemes in C++ initially ignored reversibility. This was a *huge* mistake, and it took years to correct it. The original problem was linkers that could not handle very long identifiers. Over time that issue was fixed, and eventually the world converged on an invertible scheme. Modern compilers almost universally use an invertible scheme today. I know nothing at all about your language (though I would like to correct that deficiency), but I am very confident that if an invertible mangling scheme is possible for you in principle, the time spent to develop one early will be repaid many times over later. shap From regehr at cs.utah.edu Thu Mar 27 15:32:53 2008 From: regehr at cs.utah.edu (John Regehr) Date: Thu, 27 Mar 2008 14:32:53 -0600 (MDT) Subject: [LLVMdev] Checked arithmetic In-Reply-To: <47EBF7F9.2010504@tut.fi> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> <47EBF7F9.2010504@tut.fi> Message-ID: > Except that some aspects of the host platform leak through > to .bc files. This may or may not be a problem. I know a bit about how Michael Norrish dealt with this sort of thing in his formal semantics for C. For example, integer width is modeled as a constant, but one with an unspecified value. Other C level choices such as order of evaluation of function arguments are modeled using nondeterministic choice. My understanding is that these are not too difficult at the level of the language specification, but that they make proofs about portable C code very difficult. I don't have a sense if the platform leaks in LLVM are bad ones or not. > One of the reasons why you have not had success may be that with current > prover technology, formalizing LLVM semantics and carrying out proofs > would be a fairly straightforward exercise, but not a trivial amount > of work. Not a good combination in academic sense. But the same is true about LLVM itself, yes? Sometimes researchers take on large infrastructure-type projects because these are great enablers of new research. This is what tenure is for. Or did Vikram start this project as an assistant professor? If so, my hat is off :). John Regehr From shap at eros-os.com Thu Mar 27 15:33:35 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Thu, 27 Mar 2008 16:33:35 -0400 Subject: [LLVMdev] Checked arithmetic In-Reply-To: References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> <1206643339.3393.17.camel@shaptop.om-md.eros-os.com> Message-ID: <1206650015.3393.96.camel@shaptop.om-md.eros-os.com> On Thu, 2008-03-27 at 14:20 -0600, John Regehr wrote: > My intuition is the same: translation validation sounds far easier than > compiler verification. On the other hand general-purpose translation > validation does not exist (that I know of) whereas the compiler > verification people are making genuine steps forward. Very interesting. Thanks for that pointer. It is surprising that one problem is not a subset of the other. One issue I did not mention: even if one decides only to emit a proof for the transformation of the code that is emitted, one must still verify the correctness of the IR reader (if applicable) and the code emitter. A verified transformation of a low-confidence input would still be a step forward, but the break in the confidence chain at the parser is significant. shap From baldrick at free.fr Thu Mar 27 16:07:45 2008 From: baldrick at free.fr (Duncan Sands) Date: Thu, 27 Mar 2008 22:07:45 +0100 Subject: [LLVMdev] GSoC applications for vmkit Message-ID: <200803272207.47041.baldrick@free.fr> > Projects I could mentor, but an other mentor would be best: > 10) Implement a type-based alias analysis in LLVM > 11) Implement non-call exception handling in LLVM I could mentor exception handling work. As well as non-call exceptions there's a bunch of stuff to be done to optimize exception handling. (1) Move the personality function out of eh.selector and make it per function. Have it be specified as a function attribute like the garbage collector gc annotation. (2) Move the catch-all definition out of eh.selector and stick it in the LLVM meta-data (there needs to be some kind of personality -> catch-all map in the meta-data). With (1) and (2) done, it is possible to eliminate eh.selector calls if they have no uses, and also not to generate them in the first place if they were only there to provide the personality and the catch-all. (3) Instead of outputting explicit calls to the unwinder rewind function in llvm-gcc, use a rewind intrinsic or the unwind instruction instead. Teach codegen to lower this to the appropriate unwinder call (this depends on the target). (4) If the only thing in a landing pad is a rewind, change the invoke into a normal call. The point of (1)-(3) above is to be able to do this. You get pointless invokes all the time due to constructors/destructors which don't actually do anything (but you only discover this after having created the invoke + landing pad etc). This would allow them to be turned into normal calls for a nice code size reduction and code simplification. (5) Lots of other stuff, see PR1508, PR2157 and PR2154 for starters. Ciao, Duncan. From eric.gouriou at pobox.com Thu Mar 27 16:18:28 2008 From: eric.gouriou at pobox.com (Eric Gouriou) Date: Thu, 27 Mar 2008 14:18:28 -0700 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47EAA2C3.8050104@gmail.com> References: <47E42E20.60505@lip6.fr> <47E4E1E7.2070707@gmail.com> <47EA98D7.6020409@lip6.fr> <47EAA2C3.8050104@gmail.com> Message-ID: <2295E809-7812-471B-9C25-08C6A77FF4F3@pobox.com> On Mar 26, 2008, at 12:23 PM, T?r?k Edwin wrote: [...] >> 2) ISO C++ does not support %jd. x86_64 does not know about %lld? >> > > It does, but gcc gives a warning, if I use %lld I get a warning on > x86_64, if I %ld I get a warning on x86-32. > int64_t is long int on x86-64. However sizeof(long int) == sizeof(long > long int), so I don't know why gcc insists it is wrong. > I only found %jd which doesn't give warnings on either: > > #include > #include > int main() > { > int64_t x=0; > printf("%ld",x); > printf("%lld",x); > printf("%jd",x); > return 0; > } > > $ gcc -Wall -O2 p.c > p.c: In function ?main?: > p.c:7: warning: format ?%lld? expects type ?long long int?, but > argument > 2 has type ?int64_t? > $ gcc -Wall -O2 p.c -m32 > p.c: In function ?main?: > p.c:6: warning: format ?%ld? expects type ?long int?, but argument 2 > has > type ?int64_t? To print a int64_t value, use PRId64 from inttypes.h if you can. #include int64_t x = ...; printf("x=%"PRId64"\n", x); It's ugly at first, but portable (provided inttypes.h ...). Eric From evan.cheng at apple.com Thu Mar 27 16:32:58 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 27 Mar 2008 14:32:58 -0700 Subject: [LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64 In-Reply-To: <200803271704.44120.baldrick@free.fr> References: <18edb2ad0803242349h19382b18o710cd06d80945b04@mail.gmail.com> <200803270918.55448.baldrick@free.fr> <18edb2ad0803270852y5515d974s1540a0685ac5d29a@mail.gmail.com> <200803271704.44120.baldrick@free.fr> Message-ID: <9CEAC68A-100D-441C-9FE3-A96D374A2EA4@apple.com> Probably better to move the discussion to a bug? Evan On Mar 27, 2008, at 9:04 AM, Duncan Sands wrote: > Does this fix it? > > Index: lib/Target/X86/X86Subtarget.h > =================================================================== > --- lib/Target/X86/X86Subtarget.h (revision 48879) > +++ lib/Target/X86/X86Subtarget.h (working copy) > @@ -144,9 +144,12 @@ > > std::string getDataLayout() const { > const char *p; > - if (is64Bit()) > - p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; > - else { > + if (is64Bit()) { > + if (isTargetDarwin()) > + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; > + else > + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:32:32"; > + } else { > if (isTargetDarwin()) > p = "e-p:32:32-f64:32:64-i64:32:64-f80:128:128"; > else > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From isanbard at gmail.com Thu Mar 27 16:44:57 2008 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 27 Mar 2008 14:44:57 -0700 Subject: [LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64 In-Reply-To: <9CEAC68A-100D-441C-9FE3-A96D374A2EA4@apple.com> References: <18edb2ad0803242349h19382b18o710cd06d80945b04@mail.gmail.com> <200803270918.55448.baldrick@free.fr> <18edb2ad0803270852y5515d974s1540a0685ac5d29a@mail.gmail.com> <200803271704.44120.baldrick@free.fr> <9CEAC68A-100D-441C-9FE3-A96D374A2EA4@apple.com> Message-ID: <16e5fdf90803271444y24564095y7ae1e970fdd65107@mail.gmail.com> Sure. Chandler, could you file a PR for this? -bw On Thu, Mar 27, 2008 at 2:32 PM, Evan Cheng wrote: > Probably better to move the discussion to a bug? > > Evan > > > > On Mar 27, 2008, at 9:04 AM, Duncan Sands wrote: > > > Does this fix it? > > > > Index: lib/Target/X86/X86Subtarget.h > > =================================================================== > > --- lib/Target/X86/X86Subtarget.h (revision 48879) > > +++ lib/Target/X86/X86Subtarget.h (working copy) > > @@ -144,9 +144,12 @@ > > > > std::string getDataLayout() const { > > const char *p; > > - if (is64Bit()) > > - p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; > > - else { > > + if (is64Bit()) { > > + if (isTargetDarwin()) > > + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; > > + else > > + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:32:32"; > > + } else { > > if (isTargetDarwin()) > > p = "e-p:32:32-f64:32:64-i64:32:64-f80:128:128"; > > else > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From evan.cheng at apple.com Thu Mar 27 17:01:30 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 27 Mar 2008 15:01:30 -0700 Subject: [LLVMdev] RFC: tailcall ppc32 patch In-Reply-To: References: Message-ID: <03ED3DF7-3978-4211-833C-26751C255E3C@apple.com> On Mar 26, 2008, at 11:29 PM, Arnold Schwaighofer wrote: > Hi there, > > it's me again. attached is preliminary support for tail calls on ppc > 32. (once i get access to a 64bit machine that part will follow). It > has passed the llvm-test with the -tailcallopt flag enabled. (after > half a day on an old g4/800 :) > > okay to submit? probably not. :) suggestions. I can see some stylistic issues. e.g. getFramePointerFrameIndex() etc. should be declared const, also please make sure there is a space between 'if' and '('. But I don't enough about PPC to really pick on it. :-) Dale, can you look through the patch? Thanks, Evan > > > regards > arnold > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ofv at wanadoo.es Thu Mar 27 17:05:41 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Thu, 27 Mar 2008 23:05:41 +0100 Subject: [LLVMdev] Hooking the global symbol resolver References: <1206565643.28676.16.camel@vmx.home> <1206634877.18767.29.camel@shaptop.om-md.eros-os.com> <1206649854.3393.93.camel@shaptop.om-md.eros-os.com> Message-ID: "Jonathan S. Shapiro" writes: > On Thu, 2008-03-27 at 21:22 +0100, ?scar Fuentes wrote: >> I'm all for hooks and delegation, but the problem here is that your >> proposal is not general enough and is hard to generalize it. It does not >> work for my project, for instance, although I face almost the same >> requirements than you wrt dynamic generation. The symbol name is enough >> for you, but not for me, and there is no way to teach LLVM about what >> info I need. > > Is this because you have a more complicated scenario, or is it because > your name mangling scheme is not sufficiently well designed? Both :-) I guess that I could invent a name mangling schema, but it certainly would be very complex and generate names of several kilobytes for *each* function invocation. The issue is that the actual function that is generated depends on the invocation point. For instance: (foo) (bar) ;; The code generated for this call to `foo' ;; may differ from the first call: (foo) [snip] > but I am very confident that if an invertible > mangling scheme is possible for you in principle, the time spent to > develop one early will be repaid many times over later. I agree that your idea about the hook can be useful for most typical front-ends, as my project can be considered "weird". -- Oscar From vadve at cs.uiuc.edu Thu Mar 27 23:11:03 2008 From: vadve at cs.uiuc.edu (Vikram S. Adve) Date: Thu, 27 Mar 2008 23:11:03 -0500 Subject: [LLVMdev] Checked arithmetic In-Reply-To: References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> <47EBF7F9.2010504@tut.fi> Message-ID: <02D8E890-1FA3-4B72-AFB1-DEBCABE1778C@cs.uiuc.edu> On Mar 27, 2008, at 3:32 PM, John Regehr wrote: > This is what tenure is for. Or did Vikram start this > project as an assistant professor? If so, my hat is off :). > > John Regehr Well, Chris and I did start this when I was a very junior assistant professor, 2nd year in fact! But the hat-tipping should go to Chris: he took our initial ideas, ran with it, made it his MS thesis, and eventually took it to a level well beyond your typical research infrastructure. --Vikram From sabre at nondot.org Thu Mar 27 23:16:53 2008 From: sabre at nondot.org (Chris Lattner) Date: Thu, 27 Mar 2008 21:16:53 -0700 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <2295E809-7812-471B-9C25-08C6A77FF4F3@pobox.com> References: <47E42E20.60505@lip6.fr> <47E4E1E7.2070707@gmail.com> <47EA98D7.6020409@lip6.fr> <47EAA2C3.8050104@gmail.com> <2295E809-7812-471B-9C25-08C6A77FF4F3@pobox.com> Message-ID: On Mar 27, 2008, at 2:18 PM, Eric Gouriou wrote: > > On Mar 26, 2008, at 12:23 PM, T?r?k Edwin wrote: > [...] >>> 2) ISO C++ does not support %jd. x86_64 does not know about %lld? >>> >> >> It does, but gcc gives a warning, if I use %lld I get a warning on >> x86_64, if I %ld I get a warning on x86-32. >> int64_t is long int on x86-64. However sizeof(long int) == >> sizeof(long >> long int), so I don't know why gcc insists it is wrong. >> I only found %jd which doesn't give warnings on either: > > To print a int64_t value, use PRId64 from inttypes.h if you can. > > #include > > int64_t x = ...; > printf("x=%"PRId64"\n", x); > > It's ugly at first, but portable (provided inttypes.h ...). Unfortunately, inttypes.h isn't portable either :(. I'd suggest: printf("%lld", (long long)x); which is guaranteed to work and is fine on any system where sizeof(int64_t) == sizeof(long long). LLVM already makes lots of assumptions that this is true already, so one more won't hurt. -Chris From regehr at cs.utah.edu Fri Mar 28 01:06:22 2008 From: regehr at cs.utah.edu (John Regehr) Date: Fri, 28 Mar 2008 00:06:22 -0600 (MDT) Subject: [LLVMdev] Checked arithmetic In-Reply-To: <02D8E890-1FA3-4B72-AFB1-DEBCABE1778C@cs.uiuc.edu> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> <47EBF7F9.2010504@tut.fi> <02D8E890-1FA3-4B72-AFB1-DEBCABE1778C@cs.uiuc.edu> Message-ID: > professor, 2nd year in fact! But the hat-tipping should go to Chris: > he took our initial ideas, ran with it, made it his MS thesis, and > eventually took it to a level well beyond your typical research > infrastructure. Nice! We need more Chrises! John From nicholas at mxc.ca Fri Mar 28 01:15:41 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Thu, 27 Mar 2008 23:15:41 -0700 Subject: [LLVMdev] unwinds to in the CFG Message-ID: <47EC8D0D.5090503@mxc.ca> I have a new plan for handling 'unwinds to' in the control flow graph and dominance. Just as a quick recap the problem I encountered is how to deal instructions in a block being used as operands in the unwind dest. Such as this: bb1: unwinds to %cleanup call void @foo() ; might throw, might not %x = add i32 %y, %z call void @foo() ; might throw, might not ret void cleanup: call void @use(i32 %x) The problem is that %x might not have been executed before we enter %cleanup. I won't reiterate what my previous plan was. The problem with it was that a lot of optimizations use the dominance tree to decide where it's safe to insert new instructions and it always assumes that if A dom B then an instruction in A is always accessible in B. Here's the new plan. Please poke holes in it. A. redefine the CFG a bit. i. pred_iterator stays the same. ii. succ_iterator only iterates over successors iii. outedge_iterator iterates over successors and the unwind dest There's still some code which refers to outedges by TerminatorInst + unsigned. I can't think of any reason not to replace all of them with outedge_iterator. B. redefine the dominator tree by modifying the GraphTraits i. A dom B means that all instructions in A are guaranteed to execute before any instructions in B. ii. the domtree may have multiple roots. Multiple roots occurs when the entry block 'unwinds to' another block. Domtree getRoot() should just return the root represented by the Function entry block, and if anyone needs it would could provide getAllRoots(). We would also need to add an "isReachable" method to domtree and replace all users who currently test for reachability by checking whether the block is dominated by the root. Before I start investing time implementing these changes, does anyone foresee any problems that I missed? Nick From nicholas at mxc.ca Fri Mar 28 01:20:59 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Thu, 27 Mar 2008 23:20:59 -0700 Subject: [LLVMdev] unwinds to in the CFG In-Reply-To: <47EC8D0D.5090503@mxc.ca> References: <47EC8D0D.5090503@mxc.ca> Message-ID: <47EC8E4B.3060907@mxc.ca> Sorry -- Small change. Nick Lewycky wrote: > A. redefine the CFG a bit. > i. pred_iterator stays the same. pred_iterator becomes an inverse of outedge_iterator. That is, edges that lead to the execution of this block, regardless of whether it's an unwind-edge or not. Nick From mdevan.foobar at gmail.com Fri Mar 28 02:00:58 2008 From: mdevan.foobar at gmail.com (Mahadevan R) Date: Fri, 28 Mar 2008 12:30:58 +0530 Subject: [LLVMdev] Python bindings? In-Reply-To: <92C2DA77-A681-4023-AF56-B627BF64E16C@mac.com> References: <92C2DA77-A681-4023-AF56-B627BF64E16C@mac.com> Message-ID: > Note that C bindings have been introduced since 2005, so there may be > a different route available than was taken then. Look in include/llvm- > c. The intent of the C bindings is to enable high-level language > bindings. The current focus is on enabling front-end compilers. Ocaml > and Haskell bindings have been developed atop them, the former being > in the LLVM source tree. 1) Are the C bindings complete? That is, is there some part of the C++ API that is not exposed by the C API? 2) Do the Ocaml/Haskell bindings follow that language's naming conventions? Or LLVM's? For e.g., in Python method names are usually like_this. So which of these are preferred: Builder.set_insert_point() or Builder.SetInsertPoint() ? Regards, -MD. From resistor at mac.com Fri Mar 28 02:04:10 2008 From: resistor at mac.com (Owen Anderson) Date: Fri, 28 Mar 2008 02:04:10 -0500 Subject: [LLVMdev] unwinds to in the CFG In-Reply-To: <47EC8E4B.3060907@mxc.ca> References: <47EC8D0D.5090503@mxc.ca> <47EC8E4B.3060907@mxc.ca> Message-ID: Note that changing the definition of pred_iterator may have consequences for post-dom tree construction. You may need to split pred_iterator as you are splitting succ_iterator. --Owen On Mar 28, 2008, at 1:20 AM, Nick Lewycky wrote: > Sorry -- Small change. > > Nick Lewycky wrote: >> A. redefine the CFG a bit. >> i. pred_iterator stays the same. > > pred_iterator becomes an inverse of outedge_iterator. That is, edges > that lead to the execution of this block, regardless of whether it's > an > unwind-edge or not. > > Nick > > _______________________________________________ > 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/20080328/b58515d5/attachment.bin From pertti.kellomaki at tut.fi Fri Mar 28 02:48:39 2008 From: pertti.kellomaki at tut.fi (=?UTF-8?B?UGVydHRpIEtlbGxvbcOka2k=?=) Date: Fri, 28 Mar 2008 09:48:39 +0200 Subject: [LLVMdev] Host leak-through In-Reply-To: <1206648221.3393.64.camel@shaptop.om-md.eros-os.com> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> <47EBF7F9.2010504@tut.fi> <1206648221.3393.64.camel@shaptop.om-md.eros-os.com> Message-ID: <47ECA2D7.4000608@tut.fi> Jonathan S. Shapiro wrote: > LLVM has a back end that emits C code. How machine dependent is the > emitted C code? The dependence I was referring to are things like sizeof(int). I doubt the emitted C code has many dependences. -- Pertti From idadesub at users.sourceforge.net Fri Mar 28 02:57:54 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Fri, 28 Mar 2008 00:57:54 -0700 Subject: [LLVMdev] Python bindings? In-Reply-To: References: <92C2DA77-A681-4023-AF56-B627BF64E16C@mac.com> Message-ID: <1ef034530803280057r4482b25enf194df6c0020e196@mail.gmail.com> On Fri, Mar 28, 2008 at 12:00 AM, Mahadevan R wrote: > 1) > Are the C bindings complete? That is, is there some part of the C++ API > that is not exposed by the C API? Nope, there's still a lot that's not done. Patches are always welcome :) We've got enough in subversion to implement the Kaleidoscope tutorial though. > 2) > Do the Ocaml/Haskell bindings follow that language's naming conventions? > Or LLVM's? For e.g., in Python method names are usually like_this. So > which of these are preferred: > > Builder.set_insert_point() > > or > > Builder.SetInsertPoint() I can't speak for the haskell bindings, but the ocaml bindings do not. We use the lowercase/underscore format traditionally used in ocaml projects. We don't need to bind all of the helper functions and methods so the api can be kept a little smaller. They also might be named differently and the semantics can be changed. For instance, the function "createPromoteMemoryToRegisterPass" creates a Pass object that we can add to a PassManager, but in ocaml we have "add_memory_to_register_promotion" which takes a PassManager as an argument and adds it inside the binding. This makes memory management a bit simpler. From baldrick at free.fr Fri Mar 28 04:10:04 2008 From: baldrick at free.fr (Duncan Sands) Date: Fri, 28 Mar 2008 10:10:04 +0100 Subject: [LLVMdev] unwinds to in the CFG In-Reply-To: <47EC8D0D.5090503@mxc.ca> References: <47EC8D0D.5090503@mxc.ca> Message-ID: <200803281010.06001.baldrick@free.fr> Hi Nick, > Just as a quick recap the problem I encountered is how to deal > instructions in a block being used as operands in the unwind dest. Such > as this: > > bb1: unwinds to %cleanup > call void @foo() ; might throw, might not > %x = add i32 %y, %z > call void @foo() ; might throw, might not > ret void > cleanup: > call void @use(i32 %x) > > The problem is that %x might not have been executed before we enter > %cleanup. how about just declaring this illegal? i.e. require the first call to be in a different basic block to the second, making it possible to use a phi node in %cleanup. Ciao, Duncan. From shap at eros-os.com Fri Mar 28 06:44:50 2008 From: shap at eros-os.com (Jonathan S. Shapiro) Date: Fri, 28 Mar 2008 07:44:50 -0400 Subject: [LLVMdev] Host leak-through In-Reply-To: <47ECA2D7.4000608@tut.fi> References: <1206501916.23853.13.camel@vmx.home> <3198EDCF-38FE-4B02-A364-CFD96C113BAE@nondot.org> <1206537564.26804.17.camel@vmx.home> <1206554567.4523.3.camel@mikado64.cs.jhu.edu> <1206564961.28676.4.camel@vmx.home> <1206635391.18767.40.camel@shaptop.om-md.eros-os.com> <47EBF7F9.2010504@tut.fi> <1206648221.3393.64.camel@shaptop.om-md.eros-os.com> <47ECA2D7.4000608@tut.fi> Message-ID: <1206704691.1949.6.camel@vmx.home> On Fri, 2008-03-28 at 09:48 +0200, Pertti Kellom?ki wrote: > Jonathan S. Shapiro wrote: > > LLVM has a back end that emits C code. How machine dependent is the > > emitted C code? > > The dependence I was referring to are things like sizeof(int). > I doubt the emitted C code has many dependences. I'll have to look at the emitted code. If an IR i32 gets emitted as an int32_t, that's good. But if the target int happens to be 32 bits, and the emitter therefore generates int, that's bad. In any case that would only solve half of my problem, because LLVM doesn't have anything analogous to a word type in the IR. C emission is really the only use case for that, so I'm not convinced that it is worthwhile to add it. shap From dag at cray.com Fri Mar 28 10:59:05 2008 From: dag at cray.com (David Greene) Date: Fri, 28 Mar 2008 09:59:05 -0600 Subject: [LLVMdev] RFC: GLIBCXX_DEBUG ScheduleDAG Patch In-Reply-To: <47DAF754.5070503@gmail.com> References: <200712171217.52176.dag@cray.com> <200802041131.28740.dag@cray.com> <47DAF754.5070503@gmail.com> Message-ID: <200803281059.05820.dag@cray.com> On Friday 14 March 2008 17:08, T?r?k Edwin wrote: > David Greene wrote: > > 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. > > Please see bug #2155, I am seeing an additional testsuite failure with > ScheduleDAG patch. > I am not saying there is any problem with ScheduleDAG patch itself, it > may be just exposing a previously hidden bug. > > [I tried to add you to the Cc: of the bugreport, but bugzilla didn't > find your email address] This patch has been superseded by a patch from Roman Levenstein. The backtrace in the bug doesn't give much help. I have seen a few more GLIBCXX_DEBUG failures as I've updated my owrking copy. I've had trouble running "make install" lately, though, so I haven't tested in a while. -Dave From gordonhenriksen at mac.com Fri Mar 28 11:26:16 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Fri, 28 Mar 2008 12:26:16 -0400 Subject: [LLVMdev] unwinds to in the CFG In-Reply-To: <47EC8D0D.5090503@mxc.ca> References: <47EC8D0D.5090503@mxc.ca> Message-ID: <39B1AD0F-4804-4442-A775-C64671954FF9@mac.com> Hi Nick, On Mar 28, 2008, at 02:15, Nick Lewycky wrote: > Before I start investing time implementing these changes, does > anyone foresee any problems that I missed? Stepping back from the nuts and bolts for a moment, could you precisely define what constitutes a predecessor in this model? What blocks would a phi node in %catch require for a case like this? define i8 @f(i1 %b) { entry: b label %try try: unwinds to %catch b i1 %b, label %then, label %else then: unwinds to %catch ret void else: unwinds to %catch ret void catch: ; What are my predecessors? ret void } > B. redefine the dominator tree by modifying the GraphTraits > i. A dom B means that all instructions in A are guaranteed to > execute before any instructions in B. > ii. the domtree may have multiple roots. > > Multiple roots occurs when the entry block 'unwinds to' another block. It seems highly problematical that static allocas might not dominate their uses. The entry block is already special in that it cannot be used as a branch target. Why not also forbid 'unwinds to' on the entry block? ? Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080328/d701b75a/attachment-0001.html From dpatel at apple.com Fri Mar 28 11:37:18 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 28 Mar 2008 09:37:18 -0700 Subject: [LLVMdev] unwinds to in the CFG In-Reply-To: <47EC8D0D.5090503@mxc.ca> References: <47EC8D0D.5090503@mxc.ca> Message-ID: On Mar 27, 2008, at 11:15 PM, Nick Lewycky wrote: > I have a new plan for handling 'unwinds to' in the control flow graph > and dominance. > > Just as a quick recap the problem I encountered is how to deal > instructions in a block being used as operands in the unwind dest. > Such > as this: > > bb1: unwinds to %cleanup > call void @foo() ; might throw, might not > %x = add i32 %y, %z > call void @foo() ; might throw, might not > ret void > cleanup: > call void @use(i32 %x) > > The problem is that %x might not have been executed before we enter > %cleanup. This means bb1 has multiple exit points, which defeats the "single entry, single exit" idea. Did I miss anything here ? - Devang From jon at ffconsultancy.com Fri Mar 28 11:44:57 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Fri, 28 Mar 2008 16:44:57 +0000 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <47E42E20.60505@lip6.fr> References: <47E42E20.60505@lip6.fr> Message-ID: <200803281644.58057.jon@ffconsultancy.com> On Friday 21 March 2008 21:52:32 Nicolas Geoffray wrote: > Hi everyone, > > I've just checked in a JVM and a CLI for LLVM (called JnJVM and N3). > Both are placed in the vmkit svn directory. > You can find the source code here: > > svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit This looks really exciting but I'm having trouble finding information about this project. Is there documentation? I am particularly interested in the GC... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From gordonhenriksen at mac.com Fri Mar 28 14:14:45 2008 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Fri, 28 Mar 2008 15:14:45 -0400 Subject: [LLVMdev] Python bindings? In-Reply-To: <1ef034530803280057r4482b25enf194df6c0020e196@mail.gmail.com> References: <92C2DA77-A681-4023-AF56-B627BF64E16C@mac.com> <1ef034530803280057r4482b25enf194df6c0020e196@mail.gmail.com> Message-ID: <693BFFD4-C85D-4E18-968A-2F7880CE4231@mac.com> On Mar 28, 2008, at 03:57, Erick Tryzelaar wrote: > On Fri, Mar 28, 2008 at 12:00 AM, Mahadevan R > wrote: >> 1) >> Are the C bindings complete? That is, is there some part of the C++ >> API that is not exposed by the C API? > > Nope, there's still a lot that's not done. Patches are always > welcome :) We've got enough in subversion to implement the > Kaleidoscope tutorial though. I like to think we're binding with a goal. :) So when a need is satisfied, it's ?done? for that need. As Erick well knows, I'm happy to accept patches to extend the bindings into any areas of interest. Very much of LLVM's functionality is either truly or essentially private, so varying definitions of ?everything? are either pointless or unsatisfiable. >> 2) >> Do the Ocaml/Haskell bindings follow that language's naming >> conventions? >> Or LLVM's? For e.g., in Python method names are usually like_this. So >> which of these are preferred: >> >> Builder.set_insert_point() >> >> or >> >> Builder.SetInsertPoint() > > I can't speak for the haskell bindings, but the ocaml bindings do > not. We use the lowercase/underscore format traditionally used in > ocaml projects. Tradition, schmadition; capitalization is part of the Objective Caml syntax. :P > We don't need to bind all of the helper functions and methods so the > api can be kept a little smaller. They also might be named > differently and the semantics can be changed. For instance, the > function "createPromoteMemoryToRegisterPass" creates a Pass object > that we can add to a PassManager, but in ocaml we have > "add_memory_to_register_promotion" which takes a PassManager as an > argument and adds it inside the binding. This makes memory > management a bit simpler. Something that the C bindings provide that I think is actually valuable is a considerably simplified memory ownership model, particularly for the IR. The C++ side doesn't participate in GC, and it is therefore not knowable whether an object needs to be disposed of or not when the managed handle to it become garbage. Since the C bindings don't expose the features that allow for the creation of detached IR objects, 'delete Module' is guaranteed to to clean up any IR objects properly. Such detached objects are not especially useful to compiler front-ends. The bulk of memory management simply disappears from both bindings and client code using this model. In particular, bindings don't need to implement finalizers. ? Gordon From nicolas.geoffray at lip6.fr Fri Mar 28 14:57:58 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Fri, 28 Mar 2008 20:57:58 +0100 Subject: [LLVMdev] Say hi to VMKit: JVM/LLVM, CLI/LLVM In-Reply-To: <200803281644.58057.jon@ffconsultancy.com> References: <47E42E20.60505@lip6.fr> <200803281644.58057.jon@ffconsultancy.com> Message-ID: <47ED4DC6.6010009@lip6.fr> Hi Jon, Jon Harrop wrote: > On Friday 21 March 2008 21:52:32 Nicolas Geoffray wrote: > >> Hi everyone, >> >> I've just checked in a JVM and a CLI for LLVM (called JnJVM and N3). >> Both are placed in the vmkit svn directory. >> You can find the source code here: >> >> svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit >> > > This looks really exciting but I'm having trouble finding information about > this project. Is there documentation? I am particularly interested in the > GC... > > You can find an overview of the project here: http://pagesperso-systeme.lip6.fr/Gael.Thomas/papers/spe-thomas-java-flexibility.pdf And if you speak french, a detailed description of the GC http://pagesperso-systeme.lip6.fr/Gael.Thomas/papers/these-gael.thomas.pdf Note that things have changed since, and the vms are developped in C++ using LLVM (instead of Lisp using VPU) Nicolas From gabor at mac.com Fri Mar 28 15:28:28 2008 From: gabor at mac.com (Gabor Greif) Date: Fri, 28 Mar 2008 21:28:28 +0100 Subject: [LLVMdev] unwinds to in the CFG Message-ID: <1B4B4944-3F4F-41C8-8389-456292441A77@mac.com> > Hi Nick, > > > Just as a quick recap the problem I encountered is how to deal > > instructions in a block being used as operands in the unwind > dest. Such > > as this: > > > > bb1: unwinds to %cleanup > > call void @foo() ; might throw, might not > > %x = add i32 %y, %z > > call void @foo() ; might throw, might not > > ret void > > cleanup: > > call void @use(i32 %x) > > > > The problem is that %x might not have been executed before we enter > > %cleanup. > > how about just declaring this illegal? i.e. require the first call > to be in a different basic block to the second, making it possible > to use a phi node in %cleanup. > > Ciao, > > Duncan. I pretty much support your opinion Duncan. Unwind BBs should not mess with values defined by their worker BB. We should not introduce undefined behaviour intentionally. Gabor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080328/bcd60098/attachment.html From sbg at froztek.com Fri Mar 28 17:55:04 2008 From: sbg at froztek.com (=?UTF-8?B?U8O4cmVuIELDuGc=?=) Date: Fri, 28 Mar 2008 23:55:04 +0100 Subject: [LLVMdev] GSoC Proposal: Language bindings via. SWIG Message-ID: <47ED7748.5090804@froztek.com> Hi, I've been lurking around the LLVM project for a couple of months now. The two recent threads about python bindings for LLVM ([1] and [2]), combined with the fact that I am looking for at GSoC project at the moment. Lead to the idea of making the "public" parts of LLVM SWIG[3]-friendly and basing a set of python bindings on this. My reasoning for doing it this way, is that it allows reuse of the SWIG annotation for bindings to other languages such as Perl and Java among others. What I would like to do for the GSoC is: 1) Annotate the necessary parts of LLVM for processing by SWIG. 2) Use SWIG to generate a python wrapper around LLVM 3) Add a (hopefully) thin layer of python code to complete the bindings. Before submitting an application for this project. I would like to know if there is an interest in this, within the LLVM project, and possibly if this is already being worked on. Regards, S?ren B?g [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013318.html [2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013171.html [3] http://www.swig.org/ From cfr at adobe.com Fri Mar 28 19:17:19 2008 From: cfr at adobe.com (Chuck Rose III) Date: Fri, 28 Mar 2008 17:17:19 -0700 Subject: [LLVMdev] stack alignment (again) Message-ID: <680422C0AA225644931C2F6DD07200DD01B60D48@namail5.corp.adobe.com> Hola LLVMers, I was curious about the state of stack alignment on x86. I noticed there are a few bugs outstanding on the issue. I recently added some code which had the effect of throwing an extra function parameter on our stack at runtime, a 4 byte pointer. Esp is now not 16-byte aligned, so instructions like unpcklps xmm1, dword ptr [eps] cause grief. My AllocaInstr instructions are told to be 16 byte aligned, so the addition of a 4-byte parameter shouldn't have changed alignment on the objects. The unpcklps instruction is coming from an ExtractElementInst or InsertElementInst. I can always hard code these by cyling my vectors to memory and doing things one scalar at a time, though perf will suffer. I'll try it Monday to see if it gets rid of the alignment sensitive instructions. I'm noticing this under windows via JIT. I'm going to check to see if my mac has similar issues. Thanks, Chuck. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080328/3cbec898/attachment.html From dalej at apple.com Fri Mar 28 19:23:41 2008 From: dalej at apple.com (Dale Johannesen) Date: Fri, 28 Mar 2008 17:23:41 -0700 Subject: [LLVMdev] stack alignment (again) In-Reply-To: <680422C0AA225644931C2F6DD07200DD01B60D48@namail5.corp.adobe.com> References: <680422C0AA225644931C2F6DD07200DD01B60D48@namail5.corp.adobe.com> Message-ID: On Mar 28, 2008, at 5:17 PM, Chuck Rose III wrote: > Hola LLVMers, > > I was curious about the state of stack alignment on x86. I noticed > there are a few bugs outstanding on the issue. I recently added > some code which had the effect of throwing an extra function > parameter on our stack at runtime, a 4 byte pointer. > > Esp is now not 16-byte aligned, so instructions like unpcklps xmm1, > dword ptr [eps] cause grief. My AllocaInstr instructions are told > to be 16 byte aligned, so the addition of a 4-byte parameter > shouldn?t have changed alignment on the objects. > > The unpcklps instruction is coming from an ExtractElementInst or > InsertElementInst. I can always hard code these by cyling my > vectors to memory and doing things one scalar at a time, though perf > will suffer. I?ll try it Monday to see if it gets rid of the > alignment sensitive instructions. > > I?m noticing this under windows via JIT. I?m going to check to see > if my mac has similar issues. The stack on MacOS is supposed to be kept 16-byte aligned. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080328/6864a92b/attachment-0001.html From viridia at gmail.com Fri Mar 28 20:07:46 2008 From: viridia at gmail.com (Talin) Date: Fri, 28 Mar 2008 18:07:46 -0700 Subject: [LLVMdev] Advice on debugging? Message-ID: <47ED9662.8070006@gmail.com> I've been using lli to do most of my unit tests for the compiler that I'm writing. However, when I get a test that crashes, its difficult to find which instruction it was that caused the crash. I tried running bugpoint, but it didn't seem to work for me, and upon reading the documentation, it seems to be intended for a different purpose than finding bugs in my source program; It seems to be related more to finding errors in the various optimizer passes. So for example, when I run lli on my program: ---------------------------------------------------------- Assertion failed: (V == V2 && "Didn't find key?"), function RemoveKey, file StringMap.cpp, line 177. 0 lli 0x0049edcd _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3815PrintStackTraceEv + 45 1 lli 0x0049efc9 _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3813SignalHandlerEi + 323 2 libSystem.B.dylib 0x9534297b _sigtramp + 43 3 ??? 0xffffffff 0x0 + 4294967295 4 libSystem.B.dylib 0x953bb782 raise + 26 5 libSystem.B.dylib 0x953cad3f abort + 73 6 libSystem.B.dylib 0x953bc923 __assert_rtn + 101 7 lli 0x00491ca7 _ZN4llvm13StringMapImpl9RemoveKeyEPNS_18StringMapEntryBaseE + 127 8 lli 0x00461946 _ZN4llvm9StringMapIPNS_5ValueENS_15MallocAllocatorEE6removeEPNS_14StringMapEntryIS2_EE + 24 9 lli 0x00461094 _ZN4llvm16ValueSymbolTable15removeValueNameEPNS_14StringMapEntryIPNS_5ValueEEE + 24 10 lli 0x0040aabe _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE18removeNodeFromListEPS1_ + 94 11 lli 0x003cbd66 _ZN4llvm6iplistINS_10BasicBlockENS_12ilist_traitsIS1_EEE6removeERNS_14ilist_iteratorIS1_EE + 254 ...etc... ---------------------------------------------------------- But when I run bugpoint, I get: ---------------------------------------------------------- Read input file : 'out/Debug/test/stdlib/test08.bcc' *** All input ok Found gcc: /usr/bin/gcc Initializing execution environment: Running the code generator to test for a crash: Generating reference output from raw program: Reference output is: bugpoint.reference.out *** Checking the code generator... *** Debugging miscompilation! Checking to see if '' compile correctly: yup. *** Optimized program matches reference output! No problem detected... bugpoint can't help you with your problem! ---------------------------------------------------------- To be honest, I am not sure what this all means. In any case, what I'd like is a way to find out more about the source of the crash. I don't suppose anyone is working on a version of lli that supports single-step debugging from the command line? Or do I need to compile to assembly and use gdb? What's the best strategy for solving this type of problem? -- Talin From chandlerc at gmail.com Fri Mar 28 20:52:58 2008 From: chandlerc at gmail.com (Chandler Carruth) Date: Fri, 28 Mar 2008 18:52:58 -0700 Subject: [LLVMdev] GSoC Proposal: Language bindings via. SWIG In-Reply-To: <47ED7748.5090804@froztek.com> References: <47ED7748.5090804@froztek.com> Message-ID: <18edb2ad0803281852n21ebb74p218a07a5181d2d32@mail.gmail.com> If SWIG can be made to do a good job with Python/Ruby/Perl etc bindings around LLVM, I would be very interested in this. I'm personally interested in seeing both Python and Ruby bindings, and in having them be as easily maintained as possible. I think it would be interesting to see what the SWIG-style solution can do in this direction as opposed to the C-binding approach. If it results in better and/or lower maintenance/development cost bindings for specific target languages, I'm all for it. -Chandler On Fri, Mar 28, 2008 at 3:55 PM, S?ren B?g wrote: > Hi, > > I've been lurking around the LLVM project for a couple of months now. > The two recent threads about python bindings for LLVM ([1] and [2]), > combined with the fact that I am looking for at GSoC project at the > moment. Lead to the idea of making the "public" parts of LLVM > SWIG[3]-friendly and basing a set of python bindings on this. > > My reasoning for doing it this way, is that it allows reuse of the SWIG > annotation for bindings to other languages such as Perl and Java among > others. > > What I would like to do for the GSoC is: > 1) Annotate the necessary parts of LLVM for processing by SWIG. > 2) Use SWIG to generate a python wrapper around LLVM > 3) Add a (hopefully) thin layer of python code to complete the bindings. > > Before submitting an application for this project. I would like to know > if there is an interest in this, within the LLVM project, and possibly > if this is already being worked on. > > Regards, > S?ren B?g > > [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013318.html > [2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013171.html > [3] http://www.swig.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080328/0e0e39e9/attachment.html From jonas at MIT.EDU Fri Mar 28 21:03:52 2008 From: jonas at MIT.EDU (Eric Jonas) Date: Fri, 28 Mar 2008 22:03:52 -0400 Subject: [LLVMdev] GSoC Proposal: Language bindings via. SWIG In-Reply-To: <18edb2ad0803281852n21ebb74p218a07a5181d2d32@mail.gmail.com> References: <47ED7748.5090804@froztek.com> <18edb2ad0803281852n21ebb74p218a07a5181d2d32@mail.gmail.com> Message-ID: <1206756232.5676.10.camel@convolution> To anyone on #llvm I'm sure I'm starting to sound like a broken record, but I'd just like to point out that for python bindings at least, you can quite easily manipulate the LLVM infrastructure via ctypes as a shared object / dll -- no C required! Those of us interested in talking to LLVM from Lisps, either Common Lisp (via CFFI) or a scheme like PLT/Mzscheme, can also use the shared library interface. In fact, for the Common Lisp case, this is the _only portable_ (cross-implementation) way of talking to LLVM. If anyone's interested in Here is a one-off example of python using the shared library approach and Gordon's excellent C interface (llvm-c): http://pastebin.com/m5197c5e7 (the verbosity at the beginning is because of some linkage issues with the llvm SOs) ...Eric On Fri, 2008-03-28 at 18:52 -0700, Chandler Carruth wrote: > If SWIG can be made to do a good job with Python/Ruby/Perl etc > bindings around LLVM, I would be very interested in this. I'm > personally interested in seeing both Python and Ruby bindings, and in > having them be as easily maintained as possible. I think it would be > interesting to see what the SWIG-style solution can do in this > direction as opposed to the C-binding approach. If it results in > better and/or lower maintenance/development cost bindings for specific > target languages, I'm all for it. > > -Chandler > > On Fri, Mar 28, 2008 at 3:55 PM, S?ren B?g wrote: > Hi, > > I've been lurking around the LLVM project for a couple of > months now. > The two recent threads about python bindings for LLVM ([1] and > [2]), > combined with the fact that I am looking for at GSoC project > at the > moment. Lead to the idea of making the "public" parts of LLVM > SWIG[3]-friendly and basing a set of python bindings on this. > > My reasoning for doing it this way, is that it allows reuse of > the SWIG > annotation for bindings to other languages such as Perl and > Java among > others. > > What I would like to do for the GSoC is: > 1) Annotate the necessary parts of LLVM for processing by > SWIG. > 2) Use SWIG to generate a python wrapper around LLVM > 3) Add a (hopefully) thin layer of python code to complete the > bindings. > > Before submitting an application for this project. I would > like to know > if there is an interest in this, within the LLVM project, and > possibly > if this is already being worked on. > > Regards, > S?ren B?g > > [1] > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013318.html > [2] > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013171.html > [3] http://www.swig.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 chandlerc at gmail.com Fri Mar 28 21:19:18 2008 From: chandlerc at gmail.com (Chandler Carruth) Date: Fri, 28 Mar 2008 19:19:18 -0700 Subject: [LLVMdev] GSoC Proposal: Language bindings via. SWIG In-Reply-To: <1206756232.5676.10.camel@convolution> References: <47ED7748.5090804@froztek.com> <18edb2ad0803281852n21ebb74p218a07a5181d2d32@mail.gmail.com> <1206756232.5676.10.camel@convolution> Message-ID: <18edb2ad0803281919y7645f33dtb9339265cb43b4aa@mail.gmail.com> On Fri, Mar 28, 2008 at 7:03 PM, Eric Jonas wrote: > To anyone on #llvm I'm sure I'm starting to sound like a broken record, > but I'd just like to point out that for python bindings at least, you > can quite easily manipulate the LLVM infrastructure via ctypes as a > shared object / dll -- no C required! I think it is quite worth while to have a "native" binding in the language. That is, one which meshes to a greater extent with the languages native object model (or provides a functional model as appropriate), naming, and style conventions. That is why I'm particularly curious about a SWIG approach, and the possibility of lowering the effort of this. Basically, it's often not worth building bindings by hand. If SWIG can do it automatically and for multiple languages? That might be worthwhile. Just my 2 cents. This is in no way to say I don't really really like the C-binding for FFI based interfaces. =] -Chandler > Those of us interested in talking > to LLVM from Lisps, either Common Lisp (via CFFI) or a scheme like > PLT/Mzscheme, can also use the shared library interface. In fact, for > the Common Lisp case, this is the _only portable_ (cross-implementation) > way of talking to LLVM. > > If anyone's interested in > > Here is a one-off example of python using the shared library approach > and Gordon's excellent C interface (llvm-c): > > http://pastebin.com/m5197c5e7 > > (the verbosity at the beginning is because of some linkage issues with > the llvm SOs) > ...Eric > > > > On Fri, 2008-03-28 at 18:52 -0700, Chandler Carruth wrote: > > If SWIG can be made to do a good job with Python/Ruby/Perl etc > > bindings around LLVM, I would be very interested in this. I'm > > personally interested in seeing both Python and Ruby bindings, and in > > having them be as easily maintained as possible. I think it would be > > interesting to see what the SWIG-style solution can do in this > > direction as opposed to the C-binding approach. If it results in > > better and/or lower maintenance/development cost bindings for specific > > target languages, I'm all for it. > > > > -Chandler > > > > On Fri, Mar 28, 2008 at 3:55 PM, S?ren B?g wrote: > > Hi, > > > > I've been lurking around the LLVM project for a couple of > > months now. > > The two recent threads about python bindings for LLVM ([1] and > > [2]), > > combined with the fact that I am looking for at GSoC project > > at the > > moment. Lead to the idea of making the "public" parts of LLVM > > SWIG[3]-friendly and basing a set of python bindings on this. > > > > My reasoning for doing it this way, is that it allows reuse of > > the SWIG > > annotation for bindings to other languages such as Perl and > > Java among > > others. > > > > What I would like to do for the GSoC is: > > 1) Annotate the necessary parts of LLVM for processing by > > SWIG. > > 2) Use SWIG to generate a python wrapper around LLVM > > 3) Add a (hopefully) thin layer of python code to complete the > > bindings. > > > > Before submitting an application for this project. I would > > like to know > > if there is an interest in this, within the LLVM project, and > > possibly > > if this is already being worked on. > > > > Regards, > > S?ren B?g > > > > [1] > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013318.html > > [2] > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013171.html > > [3] http://www.swig.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 > > _______________________________________________ > 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/20080328/50efd7bd/attachment-0001.html From mdevan.foobar at gmail.com Fri Mar 28 21:45:33 2008 From: mdevan.foobar at gmail.com (Mahadevan R) Date: Sat, 29 Mar 2008 08:15:33 +0530 Subject: [LLVMdev] GSoC Proposal: Language bindings via. SWIG In-Reply-To: <1206756232.5676.10.camel@convolution> References: <47ED7748.5090804@froztek.com> <18edb2ad0803281852n21ebb74p218a07a5181d2d32@mail.gmail.com> <1206756232.5676.10.camel@convolution> Message-ID: > but I'd just like to point out that for python bindings at least, you > can quite easily manipulate the LLVM infrastructure via ctypes as a > shared object / dll -- no C required! Those of us interested in talking ctypes brings with it it's own troubles. To use it in any non-trivial way, one must write enough non-trivial wrapper code in Python. Performance is also affected (though I haven't measured it myself). Boost.Python[1] is another option. All said, it is not so difficult to write Python extensions in C (which probably is one reason so many glue tools exist?). Regards, -MD. [1] http://www.boost.org/libs/python/doc/index.html From jonas at MIT.EDU Fri Mar 28 22:27:01 2008 From: jonas at MIT.EDU (Eric Jonas) Date: Fri, 28 Mar 2008 23:27:01 -0400 Subject: [LLVMdev] GSoC Proposal: Language bindings via. SWIG In-Reply-To: References: <47ED7748.5090804@froztek.com> <18edb2ad0803281852n21ebb74p218a07a5181d2d32@mail.gmail.com> <1206756232.5676.10.camel@convolution> Message-ID: <1206761221.5676.25.camel@convolution> On Sat, 2008-03-29 at 08:15 +0530, Mahadevan R wrote: > > but I'd just like to point out that for python bindings at least, you > > can quite easily manipulate the LLVM infrastructure via ctypes as a > > shared object / dll -- no C required! Those of us interested in talking > > ctypes brings with it it's own troubles. To use it in any non-trivial way, > one must write enough non-trivial wrapper code in Python. Performance > is also affected (though I haven't measured it myself). > In my experience, even when combining two languages with fairly similar object-orientation semantics like python and C++ , you always have to write a decent chunk of glue code. When the semantics are wildly different, the amount of glue code becomes non-trivial. The question becomes, do you want to write your bindings in a language like C or in your native language (which you ostensibly love more than C anyway, or you probably wouldn't be creating the bindings in the first place). Even SWIG isn't a panacea, and still forces you to write a layer on top of the resulting swig objects if you want an interface that looks appropriate for your native language. > Boost.Python[1] is another option. Boost.Python is an awesome tool for wrapping simple projects, and I've used it in the past for four or five somewhat-complex object hierarchies. We had many object lifecycle issues that ended up rendering it unusable with our existing high-performance code (some numeric, some network). Also, it does all manner of C++ template magic, and when it breaks / fails to do what you want it too / changes in a subtle way between boost revisions, god help you. > All said, it is not so difficult to write Python extensions in C (which > probably is one reason so many glue tools exist?). I'd argue that python's dog-slow performance in some areas ("Help me, PyPy project, you're my only hope!") coupled with python coders reluctance to touch C with a ten-foot pole also contributes to the proliferation of these tools :) And of course, all I'm really arguing for here is for the LLVM build process (Which, after an hour, I still don't understand) to build the shared libraries correctly so that I can use it from lisp :) ...Eric From nicholas at mxc.ca Fri Mar 28 23:49:28 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Fri, 28 Mar 2008 21:49:28 -0700 Subject: [LLVMdev] unwinds to in the CFG In-Reply-To: <200803281010.06001.baldrick@free.fr> References: <47EC8D0D.5090503@mxc.ca> <200803281010.06001.baldrick@free.fr> Message-ID: <47EDCA58.8010808@mxc.ca> Duncan Sands wrote: > Hi Nick, > >> Just as a quick recap the problem I encountered is how to deal >> instructions in a block being used as operands in the unwind dest. Such >> as this: >> >> bb1: unwinds to %cleanup >> call void @foo() ; might throw, might not >> %x = add i32 %y, %z >> call void @foo() ; might throw, might not >> ret void >> cleanup: >> call void @use(i32 %x) >> >> The problem is that %x might not have been executed before we enter >> %cleanup. > > how about just declaring this illegal? i.e. require the first call > to be in a different basic block to the second, making it possible > to use a phi node in %cleanup. Because it's extremely difficult for an optimization pass to maintain that guarantee, it's expensive to scan through the instruction list sequentially, and it leads to additional basic blocks. I agree that the snippet should be illegal, but I don't think this is the way to do it. Nick From nicholas at mxc.ca Fri Mar 28 23:57:49 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Fri, 28 Mar 2008 21:57:49 -0700 Subject: [LLVMdev] unwinds to in the CFG In-Reply-To: <39B1AD0F-4804-4442-A775-C64671954FF9@mac.com> References: <47EC8D0D.5090503@mxc.ca> <39B1AD0F-4804-4442-A775-C64671954FF9@mac.com> Message-ID: <47EDCC4D.7000609@mxc.ca> Gordon Henriksen wrote: > What blocks would a phi node in %catch require for a case like this? > > define i8 @f(i1 %b) { > > entry: > > b label %try > > try: unwinds to %catch > > b i1 %b, label %then, label %else > > then: unwinds to %catch > > ret void > > else: unwinds to %catch > > ret void > > catch: ; What are my predecessors? > > ret void > > } 'catch' has 3 preds, %try, %then and %else. > >> B. redefine the dominator tree by modifying the GraphTraits >> i. A dom B means that all instructions in A are guaranteed to >> execute before any instructions in B. >> ii. the domtree may have multiple roots. >> >> Multiple roots occurs when the entry block 'unwinds to' another block. > > It seems highly problematical that static allocas might not dominate > their uses. I'm not sure what you mean by that. It would be invalid to "alloca" in a BB then use the pointer in the unwind dest. You can't escape that. The entry block is already special in that it cannot be used > as a branch target. Why not also forbid 'unwinds to' on the entry block? Yes, we could also do that. I'm all for hearing arguments for and opposed. Nick From edwintorok at gmail.com Sat Mar 29 08:02:35 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sat, 29 Mar 2008 15:02:35 +0200 Subject: [LLVMdev] Introducing a branch optimization and prediction pass Message-ID: <47EE3DEB.3020408@gmail.com> Hi, I would like to transform unpredictable conditional branches with a small body into cmov instructions to reduce branch miss penalty. LLVM generates cmov/setcc instructions when SelectInst is used. The idea is to transform regular branches into selects, when that is possible and profitable. However this needs branch prediction info, and it seems LLVM doesn't provide that AFAICT. Could gcc's branch predictor be used here, or are there plans for an llvm-specific branch predictor? This has performance benefits if the branch is otherwise unpredictable, for example: for(i=0;i References: <47EC8D0D.5090503@mxc.ca> <39B1AD0F-4804-4442-A775-C64671954FF9@mac.com> <47EDCC4D.7000609@mxc.ca> Message-ID: On 2008-03-29, at 00:57, Nick Lewycky wrote: > Gordon Henriksen wrote: > >> What blocks would a phi node in %catch require for a case like this? >> >> define i8 @f(i1 %b) { >> entry: >> b label %try >> try: unwinds to %catch >> b i1 %b, label %then, label %else >> then: unwinds to %catch >> ret void >> else: unwinds to %catch >> ret void >> catch: ; What are my predecessors? >> ret void >> } > > 'catch' has 3 preds, %try, %then and %else. Would it be more natural to claim %entry and %try as the predecessors? This is similar to how a high level language disallows variable declarations from a try block to be visible from the catch. object x; try { x = null; } catch { use(x); } // error, x is uninitialized Also, consider a phi node: phi i32 [%x, %bb1] ; %x defined in %bb1. Depending on what type of predecessor %bb1 is, some of the models you've mentioned declare this phi node illegal. >>> B. redefine the dominator tree by modifying the GraphTraits >>> i. A dom B means that all instructions in A are guaranteed to >>> execute before any instructions in B. >>> ii. the domtree may have multiple roots. >>> >>> Multiple roots occurs when the entry block 'unwinds to' another >>> block. >> >> It seems highly problematical that static allocas might not >> dominate their uses. > > I'm not sure what you mean by that. It would be invalid to "alloca" > in a BB then use the pointer in the unwind dest. You can't escape > that. I'm just giving an example of something that breaks if the entry-block- dominates-all-blocks property is violated. Front-ends and transformations rely upon this property by unconditionally placing their 'local variable declaration' allocas in the entry block. ? Gordon From sean.soria at gmail.com Sat Mar 29 13:50:02 2008 From: sean.soria at gmail.com (Sean Soria) Date: Sat, 29 Mar 2008 11:50:02 -0700 Subject: [LLVMdev] Using Povray with the test suite Message-ID: I'm using LLVM 2.2 and trying to run the external povray test. The LLVM Test Suite Guide (http://llvm.org/releases/2.2/docs/TestingGuide.html) Indicates that configuring with "--enable-povray=directory" will do the trick. Unfortunately that doesn't seem to work. Poking around the config files I saw that "--with-externals=directory" seems to work, but then the script only looks for a povray directory named povray31 within the specified external directory. After getting it to correctly find Povray 3.1 I tried to run the test suite again but it seems to expect Povray to be compiled already. Could somebody point me in the right direction? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080329/6376317c/attachment.html From nicholas at mxc.ca Sat Mar 29 14:07:46 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Sat, 29 Mar 2008 12:07:46 -0700 Subject: [LLVMdev] unwinds to in the CFG In-Reply-To: References: <47EC8D0D.5090503@mxc.ca> <39B1AD0F-4804-4442-A775-C64671954FF9@mac.com> <47EDCC4D.7000609@mxc.ca> Message-ID: <47EE9382.4020602@mxc.ca> Gordon Henriksen wrote: > On 2008-03-29, at 00:57, Nick Lewycky wrote: > >> Gordon Henriksen wrote: >> >>> What blocks would a phi node in %catch require for a case like this? >>> >>> define i8 @f(i1 %b) { >>> entry: >>> b label %try >>> try: unwinds to %catch >>> b i1 %b, label %then, label %else >>> then: unwinds to %catch >>> ret void >>> else: unwinds to %catch >>> ret void >>> catch: ; What are my predecessors? >>> ret void >>> } >> 'catch' has 3 preds, %try, %then and %else. > > Would it be more natural to claim %entry and %try as the predecessors? > This is similar to how a high level language disallows variable > declarations from a try block to be visible from the catch. In LLVM the rule is that an instruction must be dominated by its operands. Predecessors and successors don't enter into it, except to define the dominance tree. > object x; > try { x = null; } > catch { use(x); } // error, x is uninitialized > Yes, I know. I'm planning to accomplish this by defining pred/succ sensibly such that we get a domtree where the equivalent LLVM code would be invalid. > Also, consider a phi node: > > phi i32 [%x, %bb1] ; %x defined in %bb1. > > Depending on what type of predecessor %bb1 is, some of the models > you've mentioned declare this phi node illegal. Oh. Now that's a very good point. bb1: unwinds to %cleanup %x = add i32 @foo, @bar ret i32 %x cleanup: %y = phi i32 [%x, bb1] If %cleanup has %bb1 as a predecessor then the above is legal. (PHI nodes being the only Instruction that works on pred/succ and not dominators.) And you're right, the fix for that it to make the predecessor be bb1's preds (if it has any). This is nastier than I was expecting... Nick From scooter.phd at gmail.com Sat Mar 29 15:00:45 2008 From: scooter.phd at gmail.com (Scott Michel) Date: Sat, 29 Mar 2008 13:00:45 -0700 Subject: [LLVMdev] Tracking down the "pred_iterator out of range" assert Message-ID: <258cd3200803291300g75284472lddf84bd2bfb21069@mail.gmail.com> I've finally been able to get back to a little hacking, and I've tracked down the before/after SVN revision numbers where this assert gets triggered: 47988: No assert 47989: Assert gets triggered during 'make check' This bug pops up when building Release from bootstrap on x86 Darwin (Mac OS X 10.4.11) using XCode 2.5's gcc 4.0.1. I've looked at the diffs between the two revision numbers, but didn't get very far. I'll continue to investigate, but I'm sure there are other llvm developers who can find the problem somewhat faster. -scooter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080329/81162efd/attachment.html From nicholas at mxc.ca Sat Mar 29 15:09:27 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Sat, 29 Mar 2008 13:09:27 -0700 Subject: [LLVMdev] Tracking down the "pred_iterator out of range" assert In-Reply-To: <258cd3200803291300g75284472lddf84bd2bfb21069@mail.gmail.com> References: <258cd3200803291300g75284472lddf84bd2bfb21069@mail.gmail.com> Message-ID: <47EEA1F7.70001@mxc.ca> That's my patch. Do you have steps to reproduce? Nick Scott Michel wrote: > I've finally been able to get back to a little hacking, and I've tracked > down the before/after SVN revision numbers where this assert gets triggered: > > 47988: No assert > 47989: Assert gets triggered during 'make check' > > This bug pops up when building Release from bootstrap on x86 Darwin (Mac > OS X 10.4.11) using XCode 2.5's gcc 4.0.1. I've looked at the diffs > between the two revision numbers, but didn't get very far. I'll continue > to investigate, but I'm sure there are other llvm developers who can > find the problem somewhat faster. > > > -scooter > > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From belayda at gmail.com Sat Mar 29 18:46:10 2008 From: belayda at gmail.com (Bernardo Elayda) Date: Sat, 29 Mar 2008 16:46:10 -0700 Subject: [LLVMdev] Noob questoin on ExecutionEngine::create Message-ID: <3e5ed32f0803291646n4d85183al9aad9865dc31dc2a@mail.gmail.com> Hello! I'm using llvm v2.1 on FC8. I'm having some trouble with the tutorial on adding JIT. I'm just trying to compile the following code: using namespace llvm; static ExecutionEngine *TheExecutionEngine; static Module *TheModule; int main(){ TheModule = new Module("my cool jit"); TheExecutionEngine = ExecutionEngine::create(TheModule); } I'm using the following command-line for compiling: -- g++ -g test.cpp `llvm-config --cppflags --ldflags --libs core jit native I get an error that says: The headers I'm using are the ones listed in the full code listing of the LLVM Kaleidoscope adding JIT tutorial. Is the tutorial wrong and the header correct or vice-versa? Was the tutorial not written for llvm 2.1 and above? thx in advance! -Bernardo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080329/d45adc38/attachment.html From belayda at gmail.com Sat Mar 29 18:51:52 2008 From: belayda at gmail.com (Bernardo Elayda) Date: Sat, 29 Mar 2008 16:51:52 -0700 Subject: [LLVMdev] no matching function call to llvm::ExecutionEngine::create(llvm::Module*&) Message-ID: <3e5ed32f0803291651p58875520m129c5c8d45816d5c@mail.gmail.com> Hi! I'm a noob to llvm and I'm running through the tutorial for adding JIT. I"m using llvm 2.1 on FC8. I'm just trying to compile this very simple piece of code based upon the full code listing in the tutorial: using namespace std; static ExecutionEngine *TheExecutionEngine; static Module *TheModule; int main() { TheModule = new Module("my cool jit"); TheExecutionEngine = ExecutionEngine::create(TheModule); } I'm using all the headers mentioned in the full code listing of the 'adding JIT' tutorial. When I compile the above code, I get the following error: error: no matching function for call to 'llvm::ExecutionEngine::create(llvm::Module*&) Was the tutorial wrong? Was the tutorial not written for llvm 2.1? Or is it operator error on my part. thx in advance! -Bernardo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080329/9d147869/attachment.html From sabre at nondot.org Sat Mar 29 19:10:58 2008 From: sabre at nondot.org (Chris Lattner) Date: Sat, 29 Mar 2008 17:10:58 -0700 Subject: [LLVMdev] Noob questoin on ExecutionEngine::create In-Reply-To: <3e5ed32f0803291646n4d85183al9aad9865dc31dc2a@mail.gmail.com> References: <3e5ed32f0803291646n4d85183al9aad9865dc31dc2a@mail.gmail.com> Message-ID: <1D04119E-1E3F-4B6B-8778-B5951143DC87@nondot.org> On Mar 29, 2008, at 4:46 PM, Bernardo Elayda wrote: > The headers I'm using are the ones listed in the full code listing > of the LLVM Kaleidoscope adding JIT tutorial. > Is the tutorial wrong and the header correct or vice-versa? Was the > tutorial not written for llvm 2.1 and above? > The tutorial was designed for llvm 2.2+. -Chris From paba50 at gmail.com Sun Mar 30 01:53:13 2008 From: paba50 at gmail.com (Kumaripaba Miyurusara Atukorala) Date: Sun, 30 Mar 2008 12:23:13 +0530 Subject: [LLVMdev] Compile programs with the LLVM Compiler as a gsoc project Message-ID: hi, This e-mail is written to involve some of the project ideas in LLVM in GSOC this year. I was looking in to the ideas mentioned under improving current system and found the idea of "Compile programs with the LLVM Compiler" to be interesting. I would like to compile one of the large code bases that have not yet been compiled with LLVM and convert the build system to be compatible with the LLVM Programs testsuite. But I have several doubts to be clarified. They are listed below. - I would like to know whether this is a suitable project for GSOC? - What software has already been compiled with LLVM and what are not; so that I can identify the possible candidates for the project? Thank you Me: My name is Kumaripaba Atukorala and I am a computer science and engineering undergraduate [1]. I'm interested in compiler technology and have experience in C/C++ and java programming [2]. [1] - http://www.cse.mrt.ac.lk [2] - http://paba50.googlepages.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080330/f989e59c/attachment-0001.html From chandlerc at gmail.com Sun Mar 30 03:08:17 2008 From: chandlerc at gmail.com (Chandler Carruth) Date: Sun, 30 Mar 2008 01:08:17 -0700 Subject: [LLVMdev] Tracking down the "pred_iterator out of range" assert In-Reply-To: <47EEA1F7.70001@mxc.ca> References: <258cd3200803291300g75284472lddf84bd2bfb21069@mail.gmail.com> <47EEA1F7.70001@mxc.ca> Message-ID: <18edb2ad0803300108v711bea85pb72c432fd3b81470@mail.gmail.com> On Sat, Mar 29, 2008 at 1:09 PM, Nick Lewycky wrote: > That's my patch. > > Do you have steps to reproduce? I just reproduced. I took a clean OS X 10.4 / Xcode (stable release i think) laptop, built llvm w/ the following commands: $ ./configure --enable-optimized --enable-jit $ make -j2 $ ./Release/bin/llvm-as < test/CodeGen/X86/loop-hoist.ll -o testcase.bc $ ./Release/bin/llc testcase.bc /Users/chandlerc/code/oss/llvm/include/llvm/Support/CFG.h:61: failed assertion `!It.atEnd() && "pred_iterator out of range!"' fish: Process 19237, "Release/bin/llc" from job 1, "Release/bin/llvm-as < test/CodeGen/X86/loop-hoist.ll | Release/bin/llc > /dev/null" terminated by signal SIGABRT (Abort) Here is a GDB backtrace. Feel free to ask me for any further information. (gdb) bt #0 0x9003d66c in kill () #1 0x9010e8cf in raise () #2 0x9010d422 in abort () #3 0x0054e4aa in __eprintf () #4 0x0044ae8e in llvm::isCriticalEdge () #5 0x0043d092 in (anonymous namespace)::CodeGenPrepare::OptimizeBlock () #6 0x0043dd24 in (anonymous namespace)::CodeGenPrepare::runOnFunction () #7 0x004f8163 in llvm::FPPassManager::runOnFunction () #8 0x004f874a in llvm::FunctionPassManagerImpl::run () #9 0x004f88a5 in llvm::FunctionPassManager::run () #10 0x000034da in main () -Chandler > > Nick > > Scott Michel wrote: > > I've finally been able to get back to a little hacking, and I've tracked > > down the before/after SVN revision numbers where this assert gets > triggered: > > > > 47988: No assert > > 47989: Assert gets triggered during 'make check' > > > > This bug pops up when building Release from bootstrap on x86 Darwin (Mac > > OS X 10.4.11) using XCode 2.5's gcc 4.0.1. I've looked at the diffs > > between the two revision numbers, but didn't get very far. I'll continue > > to investigate, but I'm sure there are other llvm developers who can > > find the problem somewhat faster. > > > > > > -scooter > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080330/9600f79c/attachment.html From ramon.garcia.f at gmail.com Sun Mar 30 03:44:54 2008 From: ramon.garcia.f at gmail.com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=) Date: Sun, 30 Mar 2008 10:44:54 +0200 Subject: [LLVMdev] I am not going to apply for this Google Summer of code Message-ID: As I have a new job, and it is incompatible with the Google Summer of code, I cannot apply for the project as it was my intention. Best regards, Ramon From gabor at mac.com Sun Mar 30 03:55:29 2008 From: gabor at mac.com (Gabor Greif) Date: Sun, 30 Mar 2008 10:55:29 +0200 Subject: [LLVMdev] PING: PATCH: Use size reduction -- wave1 Message-ID: <5F2F6F97-B64A-41A9-8884-4473689D4775@mac.com> Not really urgent, but I keep getting conflicts the day or another. Cheers, Gabor From idadesub at users.sourceforge.net Sun Mar 30 05:04:39 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sun, 30 Mar 2008 03:04:39 -0700 Subject: [LLVMdev] first two chapters for the ocaml bindings in svn In-Reply-To: <25F90438-E1B0-4083-A33A-D900B28569FE@mac.com> References: <1ef034530803270130h3dfb407fv721a7128e817709c@mail.gmail.com> <25F90438-E1B0-4083-A33A-D900B28569FE@mac.com> Message-ID: <1ef034530803300304g303635fej32d3d05a41f087fd@mail.gmail.com> Chapters 3 and 4 are now in subversion: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/OCamlLangImpl3.html?view=co http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/OCamlLangImpl4.html?view=co These modules add support for codegen and jitting. Control structures are next :) From rajikacc at gmail.com Sun Mar 30 09:39:31 2008 From: rajikacc at gmail.com (Rajika Kumarasiri) Date: Sun, 30 Mar 2008 20:09:31 +0530 Subject: [LLVMdev] [Proposal] GSoC 2008 project proposal for improving the llvm-test testsuite Message-ID: <696bc1d50803300739m27c3e398nd80831cd053838c0@mail.gmail.com> Hello every body, With the ideas and suggestions that I got from you all I came up with the proposal for the project of improving the llvm-test testsuite. I am posting my proposal here, if you have any feedback(anything to be added or anything to be removed ) please let me know, so that I can improve the proposal before I upload it in Google web app. Thanks in advance.! Regarda, Rjika *Proposal for summer of code 2008, Rajika Kumarasiri* *1. Project title:* Extend the llvm-test testsuite to include new programs and benchmaraks[1], and give a web service interface to run a test build remotely. *2. Abstract:* LLVM[2] is a collection of libraries and header files of a virtual machine and has a GCC-front end in which C/C++ programs can be compiled into LLVM bitcode. The aim of this project is to improve the testsuite[3] of LLVM, which is an extremely useful task. So the tesuite of the llvm is extended by including this new programs and benchmarks[1]. The test programs would be a part of the already existing testsuite with ability to check new features and correctness and also benchmarks. The test cases would reproduce any failures when LLVM fails to build the third party codes[1]. Test programs would be either small, independent ones(located in llvm/test) which check correctness and features or large whole programs(located in llvm/project/llvm-test) which check the benchmarks. In both cases test cases will be programs which are more CPU intensive (to get the most effect out of machine time) and will have a few library dependencies(to avoid the version mismatch problem and to run on wide range of platforms). At the other end project include a web service interface in which user can submit a test build for a particular target and get the result out put. *3. Deliverables:* 1.Individual test programs in source code format. 2.A small HOWTO associate with each and every test program(which includes how to use, which input parameters should be supplied and the detailed outputs). This is the documentation associated with the each of the test case. 3.A web service interface in which a user can submit a test and receive the result. 4.A small HOWTO which describe the inputs, outputs and how to use the web service interface. 5.Documentation to support the continuation of the project (if required) *4. Benefits to the llvm community* After successful completion of the project following will be available to the LLVM community. 1.An improved test suite with new benchmarks programs. 2.A web service interface, in which a user can submit a test build and get the result. *5. Overview:* My work in this project will cover two parts. First part is the improvement which is going to be added to the LLVM test suite. The LLVM test suite comes in two forms in which one is a set of independent code fragment (under llvm/test) and whole programs (under llvm/project/llvm-test). Having a good test suite for the LLVM is an extremely important task, since it gives a lot of coverage of programs and enables to spot and improve any problem in the compiler. The implementation details are as follows (in abstract form). 1.Compile the benchmarks programs[1] with LLVM compiler. 2.If this successful update the relevant make files in llvm/project/llvm-test to include the new benchmark to the llvm test suite. 3.If this fails, derive(rewrite or modify the existing one) a small test case program(this entirely depend on the benchmark program use[1]) and add it to the test suite. Extend the build system(modify the makefiles in llvm/test and llvm/project/llvm-test) to include the new test cases to the LLVM testsuite. For example consider the BioPerf[1]. I should take the existing benchmarks and appropriately update its makefiles so that it builds on the whole program testsuite (in llvm/project/llvm-test), if BioPerf fails to build with LLVM I need to derive(modify an existing one or write a new test case) small test case to reproduce the failures. These independent tests are then added to llvm/test together with the relevant updates in makefiles of the build system. When developing benchmarks input data set must be adjusted appropriately so that it doesn't take hours to run the this benchmark and it takes enough time to notice the performance changes. My second work on the project involves developing a web service interface so that a user can submit test build and get the result remotely. Once a user submits a test build with a specific target the build result (any possible deviation from that target) will be given. Having this kind of a web service interface can be very useful, since it avoids the need of maintaining two trees of code base for testing purposes. And also if this web service can be exposed to the llvm-user community they will also get the benefit to run a test build remotely for a particular target. Implementation of the web service is straight forward, the user of the web service will be given a client(which takes the payload to the service) developed using client API and it will communicate with the service(which actually runs the test suite) developed with the service API of the Apache Axis2/C web services frame work[4]. Axis2/C written in C(giving us the ability to embed it to LLVM easily) and come under Apache license[5] (giving us the ability to ship with LLVM due to the Apache license). * 6. Project Plan:* I have broken down the project under 4 steps as follows. Weekly status updates will be given in the llvm-dev list. Step1: Initial Planning and Designing I would look into the build system of LLVM testsuite, how a simple test can be written for the testsuite under this step. And also I'll look into how a C/C++ program can be compiled using LLVM compiler in this time. And also I will design the web service interface(together with inputs, out puts etc..,) Deliverable: Prototype test case. Estimated Completion: 21st May 2008 Step2: Implementation of initial test suite programs I would focus on implementing the testsuite programs in this step. The selection of the benchmarks program priority[1] will depend on factors such as pointer intensive programs, memory intensive program etc.,I hope to add programs to the test suite as far as I can within this time from the list[1]. Deliverable(s): Completed test cases from the list[1] and the documentation for mid evaluation. Estimated Completion: 2nd July 2008 Step3: Improvements and Implementing web service interface and the rest of the benchmarks programs Modifications or improvements suggested at the mid evaluation would be completed in this step. And also the web service will be developed. And also the rest of the benchmarks will be completed from the list. Deliverable(s): Web service and the test programs for the rest of the list. Estimated Completion: 3th August 2008 Step4: Final Product and Documents This step would complete the project in which. Necessary documents would also be present with the final product. Deliverable(s): Final product and documentation Estimated Completion: 11th August 2008 * 7. Biography:* I am a final year computer science and engineering undergraduate of the Department of Computer Science and Engineering of University of Moratuwa, Sri Lanka[6]. I have involved in Open source development regarding web services. I developed a firefox extension which introduced a new Javascript object, WSRequest which can be used for consume web services. It is free and open source in which the code is available here[7]. And also I participated in GSoC 2007 program and developed a part of the mail transport for Apache Axis2/C[8]. I have a great interest in compiler technology and have experience in C/C++ programming. I took the one semester course on compiler theory at the university and developed a lexical analyzer in C for a subset of Javascript language [9] and a pretty printer for a subset of Javascript in python[10]. I was a looking for a compiler project to work on and I found LLVM, and I'll continuously work on it to make any contribution to the llvm community. Other information about me including my projects work can be found in my resume[11]. *Reference:* [1] - http://nondot.org/sabre/LLVMNotes/#benchmarks [2] - http://llvm.org/ [3] - http://llvm.org/docs/TestingGuide.html [4] - http://ws.apache.org/axis2/c/ [5] - http://www.apache.org/licenses/LICENSE-2.0 [6] - http://www.cse.mrt.ac.lk/ [7] - https://wso2.org/repos/wso2/trunk/wsf/javascript/xpi/ [8] - http://rajikacc.googlepages.com/mail_trasnport.tar.gz [9] - http://rajikacc.googlepages.com/scanner.tar.gz [10] - http://rajikacc.googlepages.com/pretty_printer.tar.gz [11] - http://rajikacc.googlepages.com/resume_rajika.pdf -- comp.lang.c - http://groups.google.com/group/comp.lang.c/topics -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080330/81b2abaa/attachment-0001.html From jo at durchholz.org Sun Mar 30 09:40:30 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 30 Mar 2008 16:40:30 +0200 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps Message-ID: <1206888030.7785.19.camel@kurier> Hi all, I managed to navigate around all those issues with environment variables and such. llvm itself now builds and checks just fine, but I can't get llvm-gcc to compile. Trying to 'make' from .../gcc gives me: ./xgcc -B./ -B/home/jo/i686-pc-linux-gnu/bin/ -isystem /home/jo/i686-pc-linux-gnu/include -isystem /home/jo/i686-pc-linux-gnu/sys-include -L/home/jo/llvm-gcc-wrk/gcc/../ld -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/. -I/home/jo/llvm-gcc-src/gcc/../include -I/home/jo/llvm-gcc-src/gcc/../libcpp/include -I/home/jo/llvm-gcc-src/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o /tmp/ccuWW3r0.s: Assembler messages: /tmp/ccuWW3r0.s:27: Error: suffix or operands invalid for `push' /tmp/ccuWW3r0.s:37: Error: suffix or operands invalid for `call' /tmp/ccuWW3r0.s:55: Error: suffix or operands invalid for `push' /tmp/ccuWW3r0.s:65: Error: suffix or operands invalid for `call' make: *** [crtbegin.o] Error 1 ./xgcc -dumpmachine gives i686-pc-linux-gnu so this is OK. The reported lines are: 27 pushl %ebp 37 call *%edx 55 pushl %ebp 65 call *%eax What's wrong? Regards, Jo P.S.: I'm running with a freshly compiled and PATH-installed llvm package with a clean 'make check', and use export LLVM_GCC_SRC=$HOME/llvm-gcc-src export LLVM_GCC_WRK=$HOME/llvm-gcc-wrk export LLVM_CONFIGURE= export LLVM_CONFIGURE="$LLVM_CONFIGURE --prefix=$HOME" export LLVM_CONFIGURE="$LLVM_CONFIGURE --enable-optimized" export LLVM_CONFIGURE="$LLVM_CONFIGURE --build=i686-pc-linux-gnu" export LLVM_CONFIGURE="$LLVM_CONFIGURE --host=i686-pc-linux-gnu" export LLVM_CONFIGURE="$LLVM_CONFIGURE --target=i686-pc-linux-gnu" export CC=gcc-4.2 export CXX=g++-4.2 cd $LLVM_GCC_WRK $LLVM_GCC_SRC/configure $LLVM_CONFIGURE make -j3 From asl at math.spbu.ru Sun Mar 30 10:16:14 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 30 Mar 2008 19:16:14 +0400 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <1206888030.7785.19.camel.SS2328SS@kurier> References: <1206888030.7785.19.camel.SS2328SS@kurier> Message-ID: <1206890174.16812.366.camel@asl.dorms.spbu.ru> Hello, Joachim. > What's wrong? Looks like, it uses 64-bit assembler. Could you please check installed binutils? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From baldrick at free.fr Sun Mar 30 11:18:12 2008 From: baldrick at free.fr (Duncan Sands) Date: Sun, 30 Mar 2008 18:18:12 +0200 Subject: [LLVMdev] [Proposal] GSoC 2008 project proposal for improving the llvm-test testsuite In-Reply-To: <696bc1d50803300739m27c3e398nd80831cd053838c0@mail.gmail.com> References: <696bc1d50803300739m27c3e398nd80831cd053838c0@mail.gmail.com> Message-ID: <200803301818.15680.baldrick@free.fr> Hi, sounds like a nice project. Some comments below. > *1. Project title:* > Extend the llvm-test testsuite to include new programs and benchmaraks[1], benchmaraks -> benchmarks > and give a web service interface to run a test build remotely. Also, this is not a title, it is a summary. How about calling it: "Improve the llvm testsuite" > *2. Abstract:* > LLVM[2] is a collection of libraries and header files of a virtual machine > and has a GCC-front end in which C/C++ programs can be compiled into LLVM > bitcode. How about: LLVM[2] is a set of libraries and tools for code optimization, including a a virtual machine and a GCC-front end capable of compiling C, C++, ObjectiveC, Ada and Fortran programs. > The aim of this project is to improve the testsuite[3] of LLVM, which is an improve the testsuite[3] of LLVM -> improve the LLVM testsuite[3] > extremely useful task. In general it is a bad idea to make this kind of unsupported claim: saying that something is "extremely useful" without explaining *why* it is extremely useful. You would do better to say: This would be extremely useful because X, Y and Z. > So the tesuite of the llvm is extended by including > this new programs and benchmarks[1]. -> Firstly, by expanding the coverage of the testsuite by adding new programs and benchmarks[1]. At this point I had to go and do something else - I may be able to comment more later. Best wishes, Duncan. From dberlin at dberlin.org Sun Mar 30 11:22:34 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Sun, 30 Mar 2008 12:22:34 -0400 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <1206888030.7785.19.camel@kurier> References: <1206888030.7785.19.camel@kurier> Message-ID: <4aca3dc20803300922q225c7c72g2a57a94e75558d0f@mail.gmail.com> It shoudl work fine if you set CC right and use --build --target --host == i686-pc-linux-gnu On Sun, Mar 30, 2008 at 10:40 AM, Joachim Durchholz wrote: > Hi all, > > I managed to navigate around all those issues with environment variables > and such. llvm itself now builds and checks just fine, but I can't get > llvm-gcc to compile. > > Trying to 'make' from .../gcc gives me: > > ./xgcc -B./ -B/home/jo/i686-pc-linux-gnu/bin/ > -isystem /home/jo/i686-pc-linux-gnu/include > -isystem /home/jo/i686-pc-linux-gnu/sys-include > -L/home/jo/llvm-gcc-wrk/gcc/../ld -O2 -DIN_GCC -W -Wall > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -I. -I. > -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/. > -I/home/jo/llvm-gcc-src/gcc/../include > -I/home/jo/llvm-gcc-src/gcc/../libcpp/include > -I/home/jo/llvm-gcc-src/gcc/../libdecnumber -I../libdecnumber -g0 > -finhibit-size-directive -fno-inline-functions -fno-exceptions > -fno-zero-initialized-in-bss -fno-toplevel-reorder > -fno-omit-frame-pointer \ > -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN \ > -o crtbegin.o > /tmp/ccuWW3r0.s: Assembler messages: > /tmp/ccuWW3r0.s:27: Error: suffix or operands invalid for `push' > /tmp/ccuWW3r0.s:37: Error: suffix or operands invalid for `call' > /tmp/ccuWW3r0.s:55: Error: suffix or operands invalid for `push' > /tmp/ccuWW3r0.s:65: Error: suffix or operands invalid for `call' > make: *** [crtbegin.o] Error 1 > > > ./xgcc -dumpmachine gives > i686-pc-linux-gnu > so this is OK. > > The reported lines are: > 27 pushl %ebp > 37 call *%edx > 55 pushl %ebp > 65 call *%eax > > What's wrong? > > Regards, > Jo > > P.S.: I'm running with a freshly compiled and PATH-installed llvm > package with a clean 'make check', and use > export LLVM_GCC_SRC=$HOME/llvm-gcc-src > export LLVM_GCC_WRK=$HOME/llvm-gcc-wrk > export LLVM_CONFIGURE= > export LLVM_CONFIGURE="$LLVM_CONFIGURE --prefix=$HOME" > export LLVM_CONFIGURE="$LLVM_CONFIGURE --enable-optimized" > export LLVM_CONFIGURE="$LLVM_CONFIGURE --build=i686-pc-linux-gnu" > export LLVM_CONFIGURE="$LLVM_CONFIGURE --host=i686-pc-linux-gnu" > export LLVM_CONFIGURE="$LLVM_CONFIGURE --target=i686-pc-linux-gnu" > export CC=gcc-4.2 > export CXX=g++-4.2 > cd $LLVM_GCC_WRK > $LLVM_GCC_SRC/configure $LLVM_CONFIGURE > make -j3 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From dberlin at dberlin.org Sun Mar 30 11:23:16 2008 From: dberlin at dberlin.org (Daniel Berlin) Date: Sun, 30 Mar 2008 12:23:16 -0400 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <4aca3dc20803300922q225c7c72g2a57a94e75558d0f@mail.gmail.com> References: <1206888030.7785.19.camel@kurier> <4aca3dc20803300922q225c7c72g2a57a94e75558d0f@mail.gmail.com> Message-ID: <4aca3dc20803300923w76549329ofcc05139af71c2cb@mail.gmail.com> To clarify, configure --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --target=i686-pc-linux-gnu I do this all the time on my 4 core amd64 box and it works fine. On Sun, Mar 30, 2008 at 12:22 PM, Daniel Berlin wrote: > It shoudl work fine if you set CC right and use --build --target > > --host == i686-pc-linux-gnu > > > > On Sun, Mar 30, 2008 at 10:40 AM, Joachim Durchholz wrote: > > Hi all, > > > > I managed to navigate around all those issues with environment variables > > and such. llvm itself now builds and checks just fine, but I can't get > > llvm-gcc to compile. > > > > Trying to 'make' from .../gcc gives me: > > > > ./xgcc -B./ -B/home/jo/i686-pc-linux-gnu/bin/ > > -isystem /home/jo/i686-pc-linux-gnu/include > > -isystem /home/jo/i686-pc-linux-gnu/sys-include > > -L/home/jo/llvm-gcc-wrk/gcc/../ld -O2 -DIN_GCC -W -Wall > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > > -Wold-style-definition -isystem ./include -I. -I. > > -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/. > > -I/home/jo/llvm-gcc-src/gcc/../include > > -I/home/jo/llvm-gcc-src/gcc/../libcpp/include > > -I/home/jo/llvm-gcc-src/gcc/../libdecnumber -I../libdecnumber -g0 > > -finhibit-size-directive -fno-inline-functions -fno-exceptions > > -fno-zero-initialized-in-bss -fno-toplevel-reorder > > -fno-omit-frame-pointer \ > > -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN \ > > -o crtbegin.o > > /tmp/ccuWW3r0.s: Assembler messages: > > /tmp/ccuWW3r0.s:27: Error: suffix or operands invalid for `push' > > /tmp/ccuWW3r0.s:37: Error: suffix or operands invalid for `call' > > /tmp/ccuWW3r0.s:55: Error: suffix or operands invalid for `push' > > /tmp/ccuWW3r0.s:65: Error: suffix or operands invalid for `call' > > make: *** [crtbegin.o] Error 1 > > > > > > ./xgcc -dumpmachine gives > > i686-pc-linux-gnu > > so this is OK. > > > > The reported lines are: > > 27 pushl %ebp > > 37 call *%edx > > 55 pushl %ebp > > 65 call *%eax > > > > What's wrong? > > > > Regards, > > Jo > > > > P.S.: I'm running with a freshly compiled and PATH-installed llvm > > package with a clean 'make check', and use > > export LLVM_GCC_SRC=$HOME/llvm-gcc-src > > export LLVM_GCC_WRK=$HOME/llvm-gcc-wrk > > export LLVM_CONFIGURE= > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --prefix=$HOME" > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --enable-optimized" > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --build=i686-pc-linux-gnu" > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --host=i686-pc-linux-gnu" > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --target=i686-pc-linux-gnu" > > export CC=gcc-4.2 > > export CXX=g++-4.2 > > cd $LLVM_GCC_WRK > > $LLVM_GCC_SRC/configure $LLVM_CONFIGURE > > make -j3 > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > From rajikacc at gmail.com Sun Mar 30 11:31:15 2008 From: rajikacc at gmail.com (Rajika Kumarasiri) Date: Sun, 30 Mar 2008 22:01:15 +0530 Subject: [LLVMdev] [Proposal] GSoC 2008 project proposal for improving the llvm-test testsuite In-Reply-To: <200803301818.15680.baldrick@free.fr> References: <696bc1d50803300739m27c3e398nd80831cd053838c0@mail.gmail.com> <200803301818.15680.baldrick@free.fr> Message-ID: <696bc1d50803300931w48850f32m13c0a76be7b03fca@mail.gmail.com> hi, Thanks for the input, I'll do the necessary arrangements. Regards, Rajika On Sun, Mar 30, 2008 at 9:48 PM, Duncan Sands wrote: > Hi, sounds like a nice project. Some comments below. > > > *1. Project title:* > > Extend the llvm-test testsuite to include new programs and > benchmaraks[1], > > benchmaraks -> benchmarks > > > and give a web service interface to run a test build remotely. > > Also, this is not a title, it is a summary. How about calling it: > "Improve the llvm testsuite" > > > *2. Abstract:* > > LLVM[2] is a collection of libraries and header files of a virtual > machine > > and has a GCC-front end in which C/C++ programs can be compiled into > LLVM > > bitcode. > > How about: LLVM[2] is a set of libraries and tools for code optimization, > including a a virtual machine and a GCC-front end capable of compiling > C, C++, ObjectiveC, Ada and Fortran programs. > > > The aim of this project is to improve the testsuite[3] of LLVM, which is > an > > improve the testsuite[3] of LLVM -> improve the LLVM testsuite[3] > > > extremely useful task. > > In general it is a bad idea to make this kind of unsupported claim: saying > that something is "extremely useful" without explaining *why* it is > extremely > useful. You would do better to say: This would be extremely useful > because > X, Y and Z. > > > So the tesuite of the llvm is extended by including > > this new programs and benchmarks[1]. > > -> Firstly, by expanding the coverage of the testsuite by adding new > programs > and benchmarks[1]. > > At this point I had to go and do something else - I may be able to comment > more > later. > > Best wishes, > > Duncan. > -- comp.lang.c - http://groups.google.com/group/comp.lang.c/topics -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080330/25e13dc4/attachment.html From sabre at nondot.org Sun Mar 30 11:57:52 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 30 Mar 2008 09:57:52 -0700 Subject: [LLVMdev] Compile programs with the LLVM Compiler as a gsoc project In-Reply-To: References: Message-ID: <60853269-D412-4453-95BB-3847382D5267@nondot.org> On Mar 29, 2008, at 11:53 PM, Kumaripaba Miyurusara Atukorala wrote: > hi, > This e-mail is written to involve some of the project ideas in LLVM > in GSOC this year. > I was looking in to the ideas mentioned under improving current > system and found the idea of "Compile programs with the LLVM > Compiler" to be interesting. I would like to compile one of the > large code bases that have not yet been compiled with LLVM and > convert the build system to be compatible with the LLVM Programs > testsuite. > > But I have several doubts to be clarified. They are listed below. > I would like to know whether this is a suitable project for GSOC? > What software has already been compiled with LLVM and what are not; > so that I can identify the possible candidates for the project? I think this would be a great project. However, I would rephrase it to be more concrete. How about taking a linux distro like redhat or gentoo or whatever you are familiar of comfortable with, and try compiling the whole thing with llvm-gcc? As part of the GSoC project, you could file bug reports for any issues you hit and help track down problems. -Chris > > Thank you > > Me: > My name is Kumaripaba Atukorala and I am a computer science and > engineering undergraduate [1]. I'm interested in compiler technology > and have experience in C/C++ and java programming [2]. > > [1] - http://www.cse.mrt.ac.lk > [2] - http://paba50.googlepages.com > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080330/25de2b2c/attachment-0001.html From jo at durchholz.org Sun Mar 30 12:07:50 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 30 Mar 2008 19:07:50 +0200 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <4aca3dc20803300923w76549329ofcc05139af71c2cb@mail.gmail.com> References: <1206888030.7785.19.camel@kurier> <4aca3dc20803300922q225c7c72g2a57a94e75558d0f@mail.gmail.com> <4aca3dc20803300923w76549329ofcc05139af71c2cb@mail.gmail.com> Message-ID: <1206896870.7785.24.camel@kurier> Am Sonntag, den 30.03.2008, 12:23 -0400 schrieb Daniel Berlin: > To clarify, > > configure --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu > --target=i686-pc-linux-gnu > > I do this all the time on my 4 core amd64 box and it works fine. There must be some other difference, as I'm doing exactly that: > > > export LLVM_GCC_SRC=$HOME/llvm-gcc-src > > > export LLVM_GCC_WRK=$HOME/llvm-gcc-wrk > > > export LLVM_CONFIGURE= > > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --prefix=$HOME" > > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --enable-optimized" > > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --build=i686-pc-linux-gnu" > > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --host=i686-pc-linux-gnu" > > > export LLVM_CONFIGURE="$LLVM_CONFIGURE --target=i686-pc-linux-gnu" > > > export CC=gcc-4.2 > > > export CXX=g++-4.2 > > > cd $LLVM_GCC_WRK > > > $LLVM_GCC_SRC/configure $LLVM_CONFIGURE > > > make -j3 Look at how $LLVM_CONFIGURE is built, the final value is --prefix=/home/jo --enable-optimized --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu" Regards, Jo From sabre at nondot.org Sun Mar 30 12:21:43 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 30 Mar 2008 10:21:43 -0700 Subject: [LLVMdev] stack alignment (again) In-Reply-To: <680422C0AA225644931C2F6DD07200DD01B60D48@namail5.corp.adobe.com> References: <680422C0AA225644931C2F6DD07200DD01B60D48@namail5.corp.adobe.com> Message-ID: <9CBA7929-8D57-48C9-AFD3-E4C34BC204D7@nondot.org> On Mar 28, 2008, at 5:17 PM, Chuck Rose III wrote: > I was curious about the state of stack alignment on x86. I noticed > there are a few bugs outstanding on the issue. I recently added > some code which had the effect of throwing an extra function > parameter on our stack at runtime, a 4 byte pointer. > > Esp is now not 16-byte aligned, so instructions like unpcklps xmm1, > dword ptr [eps] cause grief. My AllocaInstr instructions are told > to be 16 byte aligned, so the addition of a 4-byte parameter > shouldn?t have changed alignment on the objects. Hi Chuck, I think the basic problem is that the stack pointer on windows/linux is not guaranteed to be 16 byte aligned. This means that any use of an instruction which requires 16-byte alignment (e.g. sse stuff) and accesses a frameindex can cause a problem. The issue is that the frameindex will be marked as needing 16+ byte alignment, but the code generator just won't respect this. The fix for this is somewhat simple: in Prolog/Epilog Insertion, the PEI pass should notice when frame indices have alignment greater than the guaranteed stack alignment. When this happens, it should emit code into the prolog to dynamically align the stack (e.g. by emitting 'and esp, -16'). This doesn't occur on the mac, because the stack is always guaranteed to be 16-byte aligned. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080330/892d4fed/attachment.html From edwintorok at gmail.com Sun Mar 30 12:26:28 2008 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sun, 30 Mar 2008 20:26:28 +0300 Subject: [LLVMdev] Compile programs with the LLVM Compiler as a gsoc project In-Reply-To: <60853269-D412-4453-95BB-3847382D5267@nondot.org> References: <60853269-D412-4453-95BB-3847382D5267@nondot.org> Message-ID: <47EFCD44.2060102@gmail.com> Chris Lattner wrote: > > On Mar 29, 2008, at 11:53 PM, Kumaripaba Miyurusara Atukorala wrote: > >> hi, >> This e-mail is written to involve some of the project ideas in LLVM >> in GSOC this year. >> I was looking in to the ideas mentioned under improving current >> system and found the idea of "Compile programs with the LLVM >> Compiler" to be interesting. I would like to compile one of the large >> code bases that have not yet been compiled with LLVM and convert the >> build system to be compatible with the LLVM Programs testsuite. >> >> >> >> But I have several doubts to be clarified. They are listed below. >> >> * I would like to know whether this is a suitable project for GSOC? >> * What software has already been compiled with LLVM and what are >> not; so that I can identify the possible candidates for the >> project? >> > I think this would be a great project. However, I would rephrase it > to be more concrete. > > How about taking a linux distro like redhat or gentoo or whatever you > are familiar of comfortable with, and try compiling the whole thing > with llvm-gcc? As part of the GSoC project, you could file bug > reports for any issues you hit and help track down problems. > Excellent idea! When testing large code bases built with llvm, and trying to track down where the problem is it would be very useful to have an automated tool to help. Something similar to 'git bisect', or bugpoint but for many source files. For example: built entire code with gcc, get some "expected output" (run make check, ....), same for llvm-gcc. If they differ, start tracking down (automatically!) in which source files the problem is. Then you build half code with llvm, half with gcc. If it breaks, you build 1/4 llvm, 3/4 gcc; if it doesn't break you build 3/4 llvm, 1/4 gcc, and so on. The situation should be logged by a tool, because for example I would certainly forget which build worked, and which one didn't. It would make sense to cache files previously built, an easy way to do that would be to build everything with one compiler, then backup&remove one half, and built it with the other compiler (just run make with the correct compiler, it will rebuild the missing files). Then restore the half, remove a quarter, repeat. If this tool could be a drop-in wrapper for CC/CXX, it would be excellent, since nearly every autotooled package could be tested this way. P.S.: to avoid duplicate bug reports, I think filing a "meta" bug that holds as depedencies all bugs that affect package X would be useful. Best regards, --Edwin From tonic at nondot.org Sun Mar 30 12:28:24 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sun, 30 Mar 2008 10:28:24 -0700 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <1206896870.7785.24.camel@kurier> References: <1206888030.7785.19.camel@kurier> <4aca3dc20803300922q225c7c72g2a57a94e75558d0f@mail.gmail.com> <4aca3dc20803300923w76549329ofcc05139af71c2cb@mail.gmail.com> <1206896870.7785.24.camel@kurier> Message-ID: <4012747D-8216-4F23-8DCD-A3271852C056@nondot.org> On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: > > Am Sonntag, den 30.03.2008, 12:23 -0400 schrieb Daniel Berlin: >> To clarify, >> >> configure --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu >> --target=i686-pc-linux-gnu >> >> I do this all the time on my 4 core amd64 box and it works fine. > > There must be some other difference, as I'm doing exactly that: > >>>> export LLVM_GCC_SRC=$HOME/llvm-gcc-src >>>> export LLVM_GCC_WRK=$HOME/llvm-gcc-wrk >>>> export LLVM_CONFIGURE= >>>> export LLVM_CONFIGURE="$LLVM_CONFIGURE --prefix=$HOME" >>>> export LLVM_CONFIGURE="$LLVM_CONFIGURE --enable-optimized" >>>> export LLVM_CONFIGURE="$LLVM_CONFIGURE --build=i686-pc-linux-gnu" >>>> export LLVM_CONFIGURE="$LLVM_CONFIGURE --host=i686-pc-linux-gnu" >>>> export LLVM_CONFIGURE="$LLVM_CONFIGURE --target=i686-pc-linux-gnu" >>>> export CC=gcc-4.2 >>>> export CXX=g++-4.2 >>>> cd $LLVM_GCC_WRK >>>> $LLVM_GCC_SRC/configure $LLVM_CONFIGURE >>>> make -j3 > > Look at how $LLVM_CONFIGURE is built, the final value is > > --prefix=/home/jo --enable-optimized --build=i686-pc-linux-gnu > --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu" > This looks likes its missing some stuff. Make sure the configure line is exactly as what is in README.LLVM. -Tanya > Regards, > Jo > > _______________________________________________ > 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 Sun Mar 30 12:40:00 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 30 Mar 2008 10:40:00 -0700 Subject: [LLVMdev] PATCH: Use size reduction -- wave1 In-Reply-To: <14DB8E59-9B9A-4935-92FF-BD21B15C2225@mac.com> References: <14DB8E59-9B9A-4935-92FF-BD21B15C2225@mac.com> Message-ID: <94D307F4-2668-491C-8E04-7FCD46B63892@nondot.org> On Mar 26, 2008, at 3:16 PM, Gabor Greif wrote: > here comes the patch for the first wave of Use class size reduction. > > I have split it into 3 files, corresponding to > - header changes > - implementation changes > - applications nice! > This at the moment does not contain the description how the > size of the Use class will be reduced from 16 to 12 bytes, > I am going to send that in a separate patch. Right, sounds great. > This wave primarily consists of changes that are needed > to allocate objects with a variable number of embedded s. Ok. > Where the number of s is constant in the lifetime of an object, > I preferred to keep the 'new Instr(...)' syntax. Otherwise I have > introduced static 'Create(...)' methods, which are used instead of the > 'new Instr(...)' construct. The bad thing about this is that it is inconsistent. I'd prefer to have consistent use of ::Create for all IR classes to make it easier to learn the API. That said, a temporary moment of inconsistency is ok: you could commit this part, then switch the remaining classes over. > These replace the constructors and the > constructors become private/protected. The arguments of the 'Create' > methods are identical to the corresponding constructors. > Essentially at the moment all introduced 'operator new's end up > calling > '::operator new(size_t)', so there should be no functionality change > at all. > This will change in subsequent waves. This basically looks good, some thoughts for the future: 1) Please (eventually) don't make the 'operator new' override be public. I'd actually prefer all memory alloc/dealloc stuff to be done privately to the (vmcore) .cpp files, not exposed through the header. 2) Eventually we'll need to make the dtor private as well. 3) Make sure that make check and some reasonable subset of llvm-test passes with this patch :) Finally, please update llvm-gcc 4.2 as well when you commit this. I'll update clang after you commit. When you commit, please email llvmdev/commits with an email that says "API CHANGE" in the subject line with info on how to upgrade out-of- tree projects (e.g. vmkit). Thanks Gabor! -Chris From jo at durchholz.org Sun Mar 30 12:41:44 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 30 Mar 2008 19:41:44 +0200 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <1206890174.16812.366.camel@asl.dorms.spbu.ru> References: <1206888030.7785.19.camel.SS2328SS@kurier> <1206890174.16812.366.camel@asl.dorms.spbu.ru> Message-ID: <1206898904.7785.35.camel@kurier> Am Sonntag, den 30.03.2008, 19:16 +0400 schrieb Anton Korobeynikov: > Hello, Joachim. > > > What's wrong? > Looks like, it uses 64-bit assembler. That was my assumption as well. > Could you please check installed binutils? $ llvm-as -version Low Level Virtual Machine (http://llvm.org/): llvm version 2.3svn Optimized build with assertions. $ as --version GNU assembler (GNU Binutils for Ubuntu) 2.18 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. I'm using --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu as configure options though, so it *should* assemble in 32-bit mode. (Unless configure or the makefiles got something wrong and aren't determining the right options from --build/host/target.) Regards, Jo From sabre at nondot.org Sun Mar 30 12:44:31 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 30 Mar 2008 10:44:31 -0700 Subject: [LLVMdev] Checked arithmetic In-Reply-To: <200803262155.51600.baldrick@free.fr> References: <1206501916.23853.13.camel@vmx.home> <200803262104.09201.baldrick@free.fr> <200803262155.51600.baldrick@free.fr> Message-ID: <7374998C-935F-4C27-92EE-351EF1E13876@nondot.org> On Mar 26, 2008, at 1:55 PM, Duncan Sands wrote: > Hi Chris, > >>> what's the point? We have this today with apint codegen (if you >>> turn on >>> LegalizeTypes). For example, this function >> >> The desired code is something like: >> >> foo: >> addl %eax, %ecx >> jo overflow_happened >> use(%ecx) > > how's an intrinsic going to help with this? Also, is there any chance > of codegen being capable one day of combining carry arithmetic coming > from apint and the appropriate conditional branch into a "jo"? The flow would be: 1) f.e. (or optimizer potentially) produces an intrinsic. 2) intrinsic is propagated by optimizer. If optimizer can prove the thing doesn't overflow, it can replace with unchecked add, providing "false" to the overflow flag. 3) SDISel gets the intrinsic, turns into an SDNode 4) Legalize does its thing, allowing a target to custom lower the node (like x86 would above) or using generic support for it. -Chris From asl at math.spbu.ru Sun Mar 30 12:51:31 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 30 Mar 2008 21:51:31 +0400 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <1206898904.7785.35.camel.SS986SS@kurier> References: <1206888030.7785.19.camel.SS2328SS@kurier> <1206890174.16812.366.camel@asl.dorms.spbu.ru> <1206898904.7785.35.camel.SS986SS@kurier> Message-ID: <1206899491.16812.373.camel@asl.dorms.spbu.ru> Hello, Joachim > This assembler was configured for a target of `x86_64-linux-gnu'. Hrm, try to check, how 'as' is invoked by llvm-gcc, you need jut to run the mentioned cmdline 'by hands': ./xgcc -B./ -B/home/jo/i686-pc-linux-gnu/bin/ -isystem /home/jo/i686-pc-linux-gnu/include -isystem /home/jo/i686-pc-linux-gnu/sys-include -L/home/jo/llvm-gcc-wrk/gcc/../ld -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/. -I/home/jo/llvm-gcc-src/gcc/../include -I/home/jo/llvm-gcc-src/gcc/../libcpp/include -I/home/jo/llvm-gcc-src/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o plus, add '-v' option to see, what is really executed. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From jo at durchholz.org Sun Mar 30 12:52:13 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 30 Mar 2008 19:52:13 +0200 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <4012747D-8216-4F23-8DCD-A3271852C056@nondot.org> References: <1206888030.7785.19.camel@kurier> <4aca3dc20803300922q225c7c72g2a57a94e75558d0f@mail.gmail.com> <4aca3dc20803300923w76549329ofcc05139af71c2cb@mail.gmail.com> <1206896870.7785.24.camel@kurier> <4012747D-8216-4F23-8DCD-A3271852C056@nondot.org> Message-ID: <1206899533.7785.46.camel@kurier> Am Sonntag, den 30.03.2008, 10:28 -0700 schrieb Tanya Lattner: > On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: > > Look at how $LLVM_CONFIGURE is built, the final value is > > > > --prefix=/home/jo --enable-optimized --build=i686-pc-linux-gnu > > --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu" > > > > This looks likes its missing some stuff. Make sure the configure line > is exactly as what is in README.LLVM. Ah, I see. I seem to be missing --enable-llvm and --enable-languages. I'll give it another try. Regards, Jo From dalej at apple.com Sun Mar 30 13:07:02 2008 From: dalej at apple.com (Dale Johannesen) Date: Sun, 30 Mar 2008 11:07:02 -0700 Subject: [LLVMdev] stack alignment (again) In-Reply-To: <9CBA7929-8D57-48C9-AFD3-E4C34BC204D7@nondot.org> References: <680422C0AA225644931C2F6DD07200DD01B60D48@namail5.corp.adobe.com> <9CBA7929-8D57-48C9-AFD3-E4C34BC204D7@nondot.org> Message-ID: On Mar 30, 2008, at 10:21 AM, Chris Lattner wrote: > On Mar 28, 2008, at 5:17 PM, Chuck Rose III wrote: >> I was curious about the state of stack alignment on x86. I noticed >> there are a few bugs outstanding on the issue. I recently added >> some code which had the effect of throwing an extra function >> parameter on our stack at runtime, a 4 byte pointer. >> >> Esp is now not 16-byte aligned, so instructions like unpcklps xmm1, >> dword ptr [eps] cause grief. My AllocaInstr instructions are told >> to be 16 byte aligned, so the addition of a 4-byte parameter >> shouldn?t have changed alignment on the objects. > > Hi Chuck, > > I think the basic problem is that the stack pointer on windows/linux > is not guaranteed to be 16 byte aligned. This means that any use of > an instruction which requires 16-byte alignment (e.g. sse stuff) and > accesses a frameindex can cause a problem. The issue is that the > frameindex will be marked as needing 16+ byte alignment, but the > code generator just won't respect this. > > The fix for this is somewhat simple: in Prolog/Epilog Insertion, the > PEI pass should notice when frame indices have alignment greater > than the guaranteed stack alignment. When this happens, it should > emit code into the prolog to dynamically align the stack (e.g. by > emitting 'and esp, -16'). > > This doesn't occur on the mac, because the stack is always > guaranteed to be 16-byte aligned. Another possibility, which only works if you have control of all the code being compiled, is to 16-byte align the stack in main and keep it 16-byte aligned thereafter. Different versions of gcc have used this method and the method Chris suggests. Still another is to disable generation of SSE instructions. -mattr=- sse2 should work. The gcc switch, -mno-sse2, did not work in llvm-gcc last time I tried; this is on my list of things to make work, but fairly far down. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080330/30934279/attachment.html From dag at cray.com Sun Mar 30 13:17:53 2008 From: dag at cray.com (David Greene) Date: Sun, 30 Mar 2008 12:17:53 -0600 Subject: [LLVMdev] reg_iterator Caveats Message-ID: <200803301317.53885.dag@cray.com> I'm forwarding this to llvmdev so it doesn't get lost in the sea of commits... -Dave ---------- Forwarded Message ---------- Subject: Re: [llvm-commits] [llvm] r48521 - in /llvm/trunk: include/llvm/CodeGen/LiveVariables.h lib/CodeGen/LiveVariables.cpp test/CodeGen/PowerPC/2008-03-18-RegScavengerAssert.ll test/CodeGen/X86/x86-64-ret0.ll Date: Friday 28 March 2008 16:34 From: David Greene To: llvm-commits at cs.uiuc.edu Cc: Chris Lattner On Tuesday 18 March 2008 23:59, Chris Lattner wrote: > How about using reg_iterators to do this? I assume this only applies > to vregs. If you walk the use_iterator list for the register, you can > very efficiently discard uses in other blocks (check User->getparent() > == MBB). Any uses within the same block are either a) in phi nodes, > in which case they are above the instruction or b) users later in the > block. > > If the representation is not in SSA form, you have to do some more > checks, but this should be a lot faster than scanning the whole > machine block. MBB's can be very large after all :) Ack. I just started looking at using reg_iterators elsewhere but wasn't aware of this non-SSA caveat. Can you elaborate? -Dave ------------------------------------------------------- From paba50 at gmail.com Sun Mar 30 13:19:18 2008 From: paba50 at gmail.com (Kumaripaba Miyurusara Atukorala) Date: Sun, 30 Mar 2008 23:49:18 +0530 Subject: [LLVMdev] Compile programs with the LLVM Compiler as a gsoc project In-Reply-To: <47EFCD44.2060102@gmail.com> References: <60853269-D412-4453-95BB-3847382D5267@nondot.org> <47EFCD44.2060102@gmail.com> Message-ID: Thank you. I'll take all these valuable facts in to consideration and come up with my proposal for this project . Kumaripaba On 3/30/08, T?r?k Edwin wrote: > > Chris Lattner wrote: > > > > On Mar 29, 2008, at 11:53 PM, Kumaripaba Miyurusara Atukorala wrote: > > > >> hi, > >> This e-mail is written to involve some of the project ideas in LLVM > >> in GSOC this year. > >> I was looking in to the ideas mentioned under improving current > >> system and found the idea of "Compile programs with the LLVM > >> Compiler" to be interesting. I would like to compile one of the large > >> code bases that have not yet been compiled with LLVM and convert the > >> build system to be compatible with the LLVM Programs testsuite. > >> > >> > >> > >> But I have several doubts to be clarified. They are listed below. > >> > >> * I would like to know whether this is a suitable project for GSOC? > >> * What software has already been compiled with LLVM and what are > >> not; so that I can identify the possible candidates for the > >> project? > >> > > I think this would be a great project. However, I would rephrase it > > to be more concrete. > > > > How about taking a linux distro like redhat or gentoo or whatever you > > are familiar of comfortable with, and try compiling the whole thing > > with llvm-gcc? As part of the GSoC project, you could file bug > > reports for any issues you hit and help track down problems. > > > > Excellent idea! > > When testing large code bases built with llvm, and trying to track down > where the problem is it would be very useful to have an automated tool > to help. Something similar to 'git bisect', or bugpoint but for many > source files. > > For example: built entire code with gcc, get some "expected output" (run > make check, ....), same for llvm-gcc. If they differ, start tracking > down (automatically!) in which source files the problem is. Then you > build half code with llvm, half with gcc. If it breaks, you build 1/4 > llvm, 3/4 gcc; if it doesn't break you build 3/4 llvm, 1/4 gcc, and so > on. The situation should be logged by a tool, because for example I > would certainly forget which build worked, and which one didn't. > It would make sense to cache files previously built, an easy way to do > that would be to build everything with one compiler, then backup&remove > one half, and built it with the other compiler (just run make with the > correct compiler, it will rebuild the missing files). Then restore the > half, remove a quarter, repeat. > > If this tool could be a drop-in wrapper for CC/CXX, it would be > excellent, since nearly every autotooled package could be tested this way. > > P.S.: to avoid duplicate bug reports, I think filing a "meta" bug that > holds as depedencies all bugs that affect package X would be useful. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080330/e01d60c8/attachment-0001.html From sabre at nondot.org Sun Mar 30 13:30:40 2008 From: sabre at nondot.org (Chris Lattner) Date: Sun, 30 Mar 2008 11:30:40 -0700 Subject: [LLVMdev] reg_iterator Caveats In-Reply-To: <200803301317.53885.dag@cray.com> References: <200803301317.53885.dag@cray.com> Message-ID: <3991571F-1D80-4F8A-BADF-4019E9504A0C@nondot.org> On Mar 30, 2008, at 11:17 AM, David Greene wrote: > I'm forwarding this to llvmdev so it doesn't get lost in the sea of > commits... reg_iterators are independent of SSA or not. The basic issue is that if you loop over uses or defs of a register, it will return *all* the uses/defs of that register in the current function. If the value is SSA form, it is reasonable to say "give me the first def" and expect it to be the only def. For multiply defined values like physregs, this is not true, because the reg can have multiple defs. That said, ref_iterator and variants will always do what they are documented to, they just don't magically provide ssa-like properties for physregs. -Chris From asl at math.spbu.ru Sun Mar 30 13:33:49 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 30 Mar 2008 22:33:49 +0400 Subject: [LLVMdev] stack alignment (again) In-Reply-To: References: <680422C0AA225644931C2F6DD07200DD01B60D48@namail5.corp.adobe.com> <9CBA7929-8D57-48C9-AFD3-E4C34BC204D7@nondot.org> Message-ID: <1206902029.16812.382.camel@asl.dorms.spbu.ru> Hello, Dale > Another possibility, which only works if you have control of all the > code being compiled, is to 16-byte align the stack in main and keep it > 16-byte aligned thereafter. Yep, this is already done for cygwin/mingw inside llvm codegen. So, only different callbacks can be broken there. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From jo at durchholz.org Sun Mar 30 13:53:18 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 30 Mar 2008 20:53:18 +0200 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <1206899491.16812.373.camel@asl.dorms.spbu.ru> References: <1206888030.7785.19.camel.SS2328SS@kurier> <1206890174.16812.366.camel@asl.dorms.spbu.ru> <1206898904.7785.35.camel.SS986SS@kurier> <1206899491.16812.373.camel@asl.dorms.spbu.ru> Message-ID: <1206903198.7785.57.camel@kurier> Am Sonntag, den 30.03.2008, 21:51 +0400 schrieb Anton Korobeynikov: > Hello, Joachim > > > This assembler was configured for a target of `x86_64-linux-gnu'. > Hrm, try to check, how 'as' is invoked by llvm-gcc, you need jut to run > the mentioned cmdline 'by hands': > [...] > plus, add '-v' option to see, what is really executed. This *is* interesting. Turns out it's calling /home/jo/llvm-gcc-wrk/./gcc/as --traditional-format -V -Qy -o crtbegin.o /tmp/ccFNX5fN.s ... but the assembler is reporting GNU assembler version 2.18 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.18 anyway, strange... ... ah, turns out /home/jo/llvm-gcc-wrk/./gcc/as is just a shell script that execs /usr/bin/as, which of course is just the preinstalled 64-bit as. I still don't understand why it isn't getting a --32 or -m32 option, somewhere in the configure-makefile-gcc chain there *should* be something that's responsible for translating --build/host/target to one of these options. Now off to trying Tanya's approach :-) Regards Jo From nicolas.geoffray at lip6.fr Sun Mar 30 14:05:34 2008 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Sun, 30 Mar 2008 21:05:34 +0200 Subject: [LLVMdev] Being able to know the jitted code-size before emitting Message-ID: <47EFE47E.4090905@lip6.fr> Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-size.patch Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20080330/d88390fe/attachment.pl From evan.cheng at apple.com Sun Mar 30 14:16:47 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 30 Mar 2008 12:16:47 -0700 Subject: [LLVMdev] stack alignment (again) In-Reply-To: <9CBA7929-8D57-48C9-AFD3-E4C34BC204D7@nondot.org> References: <680422C0AA225644931C2F6DD07200DD01B60D48@namail5.corp.adobe.com> <9CBA7929-8D57-48C9-AFD3-E4C34BC204D7@nondot.org> Message-ID: <5E58D343-7BD4-4DBB-B9D2-62DE0F615C8F@apple.com> On Mar 30, 2008, at 10:21 AM, Chris Lattner wrote: > On Mar 28, 2008, at 5:17 PM, Chuck Rose III wrote: >> I was curious about the state of stack alignment on x86. I noticed >> there are a few bugs outstanding on the issue. I recently added >> some code which had the effect of throwing an extra function >> parameter on our stack at runtime, a 4 byte pointer. >> >> Esp is now not 16-byte aligned, so instructions like unpcklps xmm1, >> dword ptr [eps] cause grief. My AllocaInstr instructions are told >> to be 16 byte aligned, so the addition of a 4-byte parameter >> shouldn?t have changed alignment on the objects. > > Hi Chuck, > > I think the basic problem is that the stack pointer on windows/linux > is not guaranteed to be 16 byte aligned. This means that any use of > an instruction which requires 16-byte alignment (e.g. sse stuff) and > accesses a frameindex can cause a problem. The issue is that the > frameindex will be marked as needing 16+ byte alignment, but the > code generator just won't respect this. > > The fix for this is somewhat simple: in Prolog/Epilog Insertion, the > PEI pass should notice when frame indices have alignment greater > than the guaranteed stack alignment. When this happens, it should > emit code into the prolog to dynamically align the stack (e.g. by > emitting 'and esp, -16'). This only works if frame pointer is not being omitted. Otherwise, you can't restore to the old stack pointer in the epilogue. So X86RegisterInfo::hasFP() must return true for Windows when any of the frame slots have alignment greater than the default alignment. Evan > > This doesn't occur on the mac, because the stack is always > guaranteed to be 16-byte aligned. > > -Chris > _______________________________________________ > 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/20080330/977bfc9d/attachment-0001.html From jo at durchholz.org Sun Mar 30 14:39:05 2008 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 30 Mar 2008 21:39:05 +0200 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <4012747D-8216-4F23-8DCD-A3271852C056@nondot.org> References: <1206888030.7785.19.camel@kurier> <4aca3dc20803300922q225c7c72g2a57a94e75558d0f@mail.gmail.com> <4aca3dc20803300923w76549329ofcc05139af71c2cb@mail.gmail.com> <1206896870.7785.24.camel@kurier> <4012747D-8216-4F23-8DCD-A3271852C056@nondot.org> Message-ID: <1206905945.7785.69.camel@kurier> Am Sonntag, den 30.03.2008, 10:28 -0700 schrieb Tanya Lattner: > On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: > > Look at how $LLVM_CONFIGURE is built, the final value is > > > > --prefix=/home/jo --enable-optimized --build=i686-pc-linux-gnu > > --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu" > > > > This looks likes its missing some stuff. Make sure the configure line > is exactly as what is in README.LLVM. OK, I now have LLVM_VERSION_INFO=kurier-bootstrap /home/jo/llvm-gcc-src/configure --prefix=/home/jo --enable-optimized --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --enable-llvm=/home/jo --enable-languages=c,c++ The --enable-llvm directory is the same as --prefix, I hope that's right (the actual binaries are in the 'bin' subdirectory). I don't think --enable-checking should be necessary, I had llvm ./configure'd with --enable-optimized (I hope that's the same as specifying ENABLE_OPTIMIZED=1 during the 'make' run for LLVM proper). Trying with OPTIMIZE_OPTION=-O2 didn't help. Anything else I may have overlooked? Regards, Jo P.S.: Rerunning the failing command with -v gave me GNU C version 4.2.1 (Based on Apple Inc. build 5555) (LLVM build) (i686-pc-linux-gnu) compiled by GNU C version 4.2.1 (Ubuntu 4.2.1-5ubuntu4). so it seems to call the right compiler, but I still get /home/jo/llvm-gcc-wrk/./gcc/as --traditional-format -V -Qy -o crtbegin.o crtstuff.s GNU assembler version 2.18 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.18 crtstuff.s: Assembler messages: crtstuff.s:15: Error: suffix or operands invalid for `push' crtstuff.s:29: Error: suffix or operands invalid for `call' crtstuff.s:36: Error: suffix or operands invalid for `pop' crtstuff.s:39: Error: suffix or operands invalid for `pop' crtstuff.s:47: Error: suffix or operands invalid for `push' crtstuff.s:60: Error: suffix or operands invalid for `call' crtstuff.s:63: Error: suffix or operands invalid for `pop' (As noted in one of my previous mails, .../gcc/as is just a shellscript calling the installed as, which happens to be GNU as.) From nicholas at mxc.ca Sun Mar 30 15:03:28 2008 From: nicholas at mxc.ca (Nick Lewycky) Date: Sun, 30 Mar 2008 13:03:28 -0700 Subject: [LLVMdev] unwinds to in the CFG In-Reply-To: <47EE9382.4020602@mxc.ca> References: <47EC8D0D.5090503@mxc.ca> <39B1AD0F-4804-4442-A775-C64671954FF9@mac.com> <47EDCC4D.7000609@mxc.ca> <47EE9382.4020602@mxc.ca> Message-ID: <47EFF210.9080501@mxc.ca> Hi Gordon, I've been thinking about this problem a bit. Nick Lewycky wrote: > Gordon Henriksen wrote: >> Also, consider a phi node: >> >> phi i32 [%x, %bb1] ; %x defined in %bb1. >> >> Depending on what type of predecessor %bb1 is, some of the models >> you've mentioned declare this phi node illegal. > > Oh. Now that's a very good point. > > bb1: unwinds to %cleanup > %x = add i32 @foo, @bar > ret i32 %x > cleanup: > %y = phi i32 [%x, bb1] > > If %cleanup has %bb1 as a predecessor then the above is legal. (PHI > nodes being the only Instruction that works on pred/succ and not > dominators.) We already have this issue with invoke. Consider: bb1: %x = invoke i32 @f() to label %normal unwind label %unwind normal: phi i32 [%x, %bb1] ret i32 %x unwind: phi i32 [%x, %bb1] ; illegal ret i32 %x The PHI in %unwind must mention %bb1, but may not refer to %x. In the code sample I pasted before (bb1: unwinds to %cleanup) it would mean that the PHI node in %cleanup must reference %bb1 but may not contain any instructions inside of %bb1. Yes this rule will require fixing up some optimizations, but I'm prepared to do that. This only applies to PHI nodes so it'll be fast to check for. The usual dominance test will take care of the case where %unwind branches out to other blocks that try to use %x. Any other issues I should keep in mind? Nick From delta17 at cox.net Sun Mar 30 15:53:33 2008 From: delta17 at cox.net (Jon Sargeant) Date: Sun, 30 Mar 2008 13:53:33 -0700 Subject: [LLVMdev] Function Parameter Requirements? Message-ID: <47EFFDCD.2070902@cox.net> I'm trying to find the requirements for function parameters in the documentation. The assembler rejects 'i32({i32,i32})' with the error 'Function arguments must be value types!' so I'm guessing that each parameter type must be a first-class type. The assembler also rejects '{i32,i32}(i32)' with the error 'LLVM Functions cannot return aggregates'. This error seems to contradict the documentation which states 'The return type of a function type is a scalar type or a void type or a struct type'. Finally, I suggest defining these additional terms in the type-classification section: - value type - scalar type - aggregate type Best Regards, Jon From ofv at wanadoo.es Sun Mar 30 16:25:30 2008 From: ofv at wanadoo.es (=?iso-8859-1?Q?=D3scar_Fuentes?=) Date: Sun, 30 Mar 2008 23:25:30 +0200 Subject: [LLVMdev] Function Parameter Requirements? References: <47EFFDCD.2070902@cox.net> Message-ID: Jon Sargeant writes: > I'm trying to find the requirements for function parameters in the > documentation. The assembler rejects 'i32({i32,i32})' with the error > 'Function arguments must be value types!' so I'm guessing that each > parameter type must be a first-class type. Right. You must pass either {i32,i32}* (a pointer to the structure) or {i64} (a first-class value that contains your structure). This depends on the calling convention and platform you are working on. > The assembler also rejects > '{i32,i32}(i32)' with the error 'LLVM Functions cannot return > aggregates'. This is a similar case. Your function's signaure should be: void ({i32,i32}* sret, {i32}) (you pass an address for putting there the structure) or i64 ({i32}) (you use a i64 for packing the structure). Again, this depends on your platform and calling convention. If you are working with C++, the existence of copiers or destructors for the struct may affect how you pass it. A good idea is to check wath llvm-gcc does, compilent C code that is equivalent to your case and reading the generated LLVM assembly code. (Use -emit-llvm switch on llvm-gcc and then use the llvm-dis tool). Another useful tool is llvm2cpp. > This error seems to contradict the documentation which > states 'The return type of a function type is a scalar type or a void > type or a struct type'. The docs are right, but perhaps not clear enough for a LLVM novice: the attribute `sret' on the first argument of a function indicates that that argument is in fact the "return type" of the function. [snip] -- Oscar From baldrick at free.fr Sun Mar 30 17:09:08 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 31 Mar 2008 00:09:08 +0200 Subject: [LLVMdev] Function Parameter Requirements? In-Reply-To: <47EFFDCD.2070902@cox.net> References: <47EFFDCD.2070902@cox.net> Message-ID: <200803310009.08743.baldrick@free.fr> Hi, > I'm trying to find the requirements for function parameters in the > documentation. The assembler rejects 'i32({i32,i32})' with the error > 'Function arguments must be value types!' so I'm guessing that each > parameter type must be a first-class type. they must be first-class types or opaque types. > The assembler also rejects > '{i32,i32}(i32)' with the error 'LLVM Functions cannot return > aggregates'. This error seems to contradict the documentation which > states 'The return type of a function type is a scalar type or a void > type or a struct type'. The documentation is based on svn head, which is currently getting support for functions returning multiple values. This is done by having the function return a struct type (the struct type cannot contain other structs: first-class types only). > Finally, I suggest defining these additional terms in the > type-classification section: > - value type > - scalar type > - aggregate type Good idea. Want to prepare a patch? Best wishes, Duncan. From tonic at nondot.org Sun Mar 30 17:35:52 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sun, 30 Mar 2008 15:35:52 -0700 Subject: [LLVMdev] Being able to know the jitted code-size before emitting In-Reply-To: <47EFE47E.4090905@lip6.fr> References: <47EFE47E.4090905@lip6.fr> Message-ID: <57475716-E4E2-4C73-BD97-374702DC7788@nondot.org> On Mar 30, 2008, at 12:05 PM, Nicolas Geoffray wrote: > Hi everyone, > > vmkit requires to know the size of a jitted method before emitting > the method. This allows to allocate the correct size for the method. > The attached patch creates this functionality when the flag > SizedMemoryCode is on. > > In order to implement this functionality, i had to virtualize some > MachineCodeEmitter functions. > > Is it OK to commit the patch? > A couple style comments: - The header for SizeEmitter.h is the old style. Please remove the part about "was developed by". You can see other files for the correct format. I think SizeEmitter.cpp is missing the header totally. - SizeEmitter.h/SizeEmitter.cpp is lacking comments. Please add doxygen style comments for all functions and member variables. Thanks, Tanya > Thanks, > Nicolas > Index: include/llvm/Target/TargetOptions.h > =================================================================== > --- include/llvm/Target/TargetOptions.h (revision 48944) > +++ include/llvm/Target/TargetOptions.h (working copy) > @@ -74,6 +74,10 @@ > /// be emitted. > extern bool ExceptionHandling; > > + /// SizedMemoryCode - This flags indicates that memory for code > is allocated by > + /// an external allocator which requires the size to allocate > + extern bool SizedMemoryCode; > + > /// PerformTailCallOpt - This flag is enabled when -tailcallopt is > specified > /// on the commandline. When the flag is on, the target will > perform tail call > /// optimization (pop the caller's stack) providing it supports it. > Index: include/llvm/CodeGen/SizeEmitter.h > =================================================================== > --- include/llvm/CodeGen/SizeEmitter.h (revision 0) > +++ include/llvm/CodeGen/SizeEmitter.h (revision 0) > @@ -0,0 +1,116 @@ > +//===-- llvm/CodeGen/MachineCodeEmitter.h - Code emission -------*- > C++ -*-===// > +// > +// The LLVM Compiler Infrastructure > +// > +// This file was developed by the LLVM research group and is > distributed under > +// the University of Illinois Open Source License. See LICENSE.TXT > for details. > +// > +// > = > = > = > ----------------------------------------------------------------------= > ==// > +// > +// This file defines an abstract interface that is used by the > machine code > +// emission framework to output the code. This allows machine code > emission to > +// be separated from concerns such as resolution of call targets, > and where the > +// machine code will be written (memory or disk, f.e.). > +// > +// > = > = > = > ----------------------------------------------------------------------= > ==// > + > +#ifndef LLVM_CODEGEN_SIZEEMITTER_H > +#define LLVM_CODEGEN_SIZEEMITTER_H > + > +#include "llvm/CodeGen/MachineCodeEmitter.h" > +#include "llvm/CodeGen/MachineFunction.h" > + > +namespace llvm { > + /// SizeEmitter - The JIT implementation of the > MachineCodeEmitter, which is > + /// used to output functions to memory for execution. > +class SizeEmitter : public MachineCodeEmitter { > + MachineFunction * Fn; > + void* ConstantPoolBase; > + void* JumpTableBase; > + MachineConstantPool *ConstantPool; > + MachineJumpTableInfo *JumpTable; > + std::vector LabelLocations; > + MachineCodeEmitter* MCE; > + > +public: > + SizeEmitter(MachineCodeEmitter* mce) { > + CurBufferPtr = 0; > + BufferBegin = 0; > + BufferEnd = (unsigned char*)-1; > + MCE = mce; > + } > + > + SizeEmitter(std::vector locations) { > + LabelLocations = locations; > + CurBufferPtr = 0; > + BufferBegin = 0; > + BufferEnd = (unsigned char*)-1; > + } > + > + void initConstantPool(MachineConstantPool *MCP); > + > + void initJumpTableInfo(MachineJumpTableInfo *MJTI); > + > + > + virtual void startFunction(MachineFunction &F) { > + CurBufferPtr = 0; > + Fn = &F; > + > + // Ensure the constant pool/jump table info is at least 4-byte > aligned. > + emitAlignment(16); > + > + initConstantPool(F.getConstantPool()); > + initJumpTableInfo(F.getJumpTableInfo()); > + > + ConstantPoolBase = (void*)(((uintptr_t) ConstantPoolBase) + > CurBufferPtr); > + JumpTableBase = (void*)(((uintptr_t) JumpTableBase) + > CurBufferPtr); > + } > + > + virtual bool finishFunction(MachineFunction &F) { > + MCE->setCurrentPtr(CurBufferPtr); > + return false; > + } > + virtual void startFunctionStub(unsigned StubSize, unsigned > Alignment) {} > + virtual void *finishFunctionStub(const Function *F) { return 0; } > + virtual void addRelocation(const llvm::MachineRelocation&) { } > + virtual void emitByte(unsigned char B) { > + CurBufferPtr++; > + } > + virtual void emitWordLE(unsigned W) { > + CurBufferPtr+=4; > + } > + virtual void emitWordBE(unsigned W) { > + CurBufferPtr+=4; > + } > + virtual void emitInt32(int Value) { > + CurBufferPtr += 4; > + } > + virtual void emitInt64(uint64_t Value) { > + CurBufferPtr += 8; > + } > + virtual void emitAt(uintptr_t *Addr, uintptr_t Value) { > + } > + > + > + > + virtual void StartMachineBasicBlock(MachineBasicBlock *MBB) {} > + virtual intptr_t getConstantPoolEntryAddress(unsigned > ConstantNum) const; > + > + virtual intptr_t getJumpTableEntryAddress(unsigned Index) const; > + > + virtual intptr_t getMachineBasicBlockAddress(MachineBasicBlock > *MBB) const { > + assert(0 && "Should not be in getMachineBasicBlockAddress of > SizeEmitter"); > + } > + > + virtual void emitLabel(uint64_t) {} > + virtual intptr_t getLabelAddress(uint64_t LabelID) const { > + assert(LabelLocations.size() > (unsigned)LabelID && > + LabelLocations[LabelID] && "Label not emitted!"); > + return LabelLocations[LabelID]; > + } > + virtual void setModuleInfo(llvm::MachineModuleInfo*) {} > +}; > + > +} // end llvm namespace > + > +#endif > Index: include/llvm/CodeGen/MachineCodeEmitter.h > =================================================================== > --- include/llvm/CodeGen/MachineCodeEmitter.h (revision 48143) > +++ include/llvm/CodeGen/MachineCodeEmitter.h (working copy) > @@ -18,6 +18,7 @@ > #define LLVM_CODEGEN_MACHINECODEEMITTER_H > > #include "llvm/Support/DataTypes.h" > +#include > #include > > namespace llvm { > @@ -92,7 +93,7 @@ > /// emitByte - This callback is invoked when a byte needs to be > written to the > /// output stream. > /// > - void emitByte(unsigned char B) { > + virtual void emitByte(unsigned char B) { > if (CurBufferPtr != BufferEnd) > *CurBufferPtr++ = B; > } > @@ -100,7 +101,7 @@ > /// emitWordLE - This callback is invoked when a 32-bit word needs > to be > /// written to the output stream in little-endian format. > /// > - void emitWordLE(unsigned W) { > + virtual void emitWordLE(unsigned W) { > if (CurBufferPtr+4 <= BufferEnd) { > *CurBufferPtr++ = (unsigned char)(W >> 0); > *CurBufferPtr++ = (unsigned char)(W >> 8); > @@ -114,7 +115,7 @@ > /// emitWordBE - This callback is invoked when a 32-bit word needs > to be > /// written to the output stream in big-endian format. > /// > - void emitWordBE(unsigned W) { > + virtual void emitWordBE(unsigned W) { > if (CurBufferPtr+4 <= BufferEnd) { > *CurBufferPtr++ = (unsigned char)(W >> 24); > *CurBufferPtr++ = (unsigned char)(W >> 16); > @@ -175,7 +176,7 @@ > } > > /// emitInt32 - Emit a int32 directive. > - void emitInt32(int Value) { > + virtual void emitInt32(int Value) { > if (CurBufferPtr+4 <= BufferEnd) { > *((uint32_t*)CurBufferPtr) = Value; > CurBufferPtr += 4; > @@ -185,7 +186,7 @@ > } > > /// emitInt64 - Emit a int64 directive. > - void emitInt64(uint64_t Value) { > + virtual void emitInt64(uint64_t Value) { > if (CurBufferPtr+8 <= BufferEnd) { > *((uint64_t*)CurBufferPtr) = Value; > CurBufferPtr += 8; > @@ -195,7 +196,7 @@ > } > > /// emitAt - Emit Value in Addr > - void emitAt(uintptr_t *Addr, uintptr_t Value) { > + virtual void emitAt(uintptr_t *Addr, uintptr_t Value) { > if (Addr >= (uintptr_t*)BufferBegin && Addr < > (uintptr_t*)BufferEnd) > (*Addr) = Value; > } > @@ -270,6 +271,11 @@ > /// Specifies the MachineModuleInfo object. This is used for > exception handling > /// purposes. > virtual void setModuleInfo(MachineModuleInfo* Info) = 0; > + > + void setCurrentPtr(unsigned char* Ptr) { > + CurBufferPtr = Ptr; > + } > + > }; > > } // End llvm namespace > Index: lib/CodeGen/LLVMTargetMachine.cpp > =================================================================== > --- lib/CodeGen/LLVMTargetMachine.cpp (revision 48143) > +++ lib/CodeGen/LLVMTargetMachine.cpp (working copy) > @@ -17,6 +17,7 @@ > #include "llvm/Assembly/PrintModulePass.h" > #include "llvm/Analysis/LoopPass.h" > #include "llvm/CodeGen/Passes.h" > +#include "llvm/CodeGen/SizeEmitter.h" > #include "llvm/CodeGen/Collector.h" > #include "llvm/Target/TargetOptions.h" > #include "llvm/Transforms/Scalar.h" > @@ -257,7 +258,13 @@ > > if (addPreEmitPass(PM, Fast) && PrintMachineCode) > PM.add(createMachineFunctionPrinterPass(cerr)); > + > + if (SizedMemoryCode) { > + SizeEmitter * SE = new SizeEmitter(&MCE); > + addSimpleCodeEmitter(PM, Fast, false, *SE); > + } > > + > addCodeEmitter(PM, Fast, PrintEmittedAsm, MCE); > > PM.add(createCollectorMetadataDeleter()); > Index: lib/CodeGen/SizeEmitter.cpp > =================================================================== > --- lib/CodeGen/SizeEmitter.cpp (revision 0) > +++ lib/CodeGen/SizeEmitter.cpp (revision 0) > @@ -0,0 +1,77 @@ > +#include "llvm/CodeGen/SizeEmitter.h" > +#include "llvm/Constant.h" > +#include "llvm/Constants.h" > +#include "llvm/DerivedTypes.h" > +#include "llvm/Module.h" > +#include "llvm/Type.h" > +#include "llvm/CodeGen/MachineCodeEmitter.h" > +#include "llvm/CodeGen/MachineFunction.h" > +#include "llvm/CodeGen/MachineConstantPool.h" > +#include "llvm/CodeGen/MachineJumpTableInfo.h" > +#include "llvm/CodeGen/MachineRelocation.h" > +#include "llvm/ExecutionEngine/GenericValue.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" > +#include "llvm/ADT/Statistic.h" > +#include "llvm/System/Memory.h" > +#include > +using namespace llvm; > + > + > +void SizeEmitter::initConstantPool(MachineConstantPool *MCP) { > + const std::vector &Constants = MCP- > >getConstants(); > + if (Constants.empty()) return; > + > + MachineConstantPoolEntry CPE = Constants.back(); > + unsigned Size = CPE.Offset; > + const Type *Ty = CPE.isMachineConstantPoolEntry() > + ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal->getType(); > + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); > + ConstantPoolBase = allocateSpace(Size, 1 << MCP- > >getConstantPoolAlignment()); > + ConstantPool = MCP; > +} > + > +void SizeEmitter::initJumpTableInfo(MachineJumpTableInfo *MJTI) { > + const std::vector &JT = MJTI- > >getJumpTables(); > + if (JT.empty()) return; > + > + unsigned NumEntries = 0; > + for (unsigned i = 0, e = JT.size(); i != e; ++i) > + NumEntries += JT[i].MBBs.size(); > + > + unsigned EntrySize = MJTI->getEntrySize(); > + > + // Just allocate space for all the jump tables now. We will fix > up the actual > + // MBB entries in the tables after we emit the code for each > block, since then > + // we will know the final locations of the MBBs in memory. > + JumpTable = MJTI; > + JumpTableBase = allocateSpace(NumEntries * EntrySize, MJTI- > >getAlignment()); > +} > + > +intptr_t SizeEmitter::getConstantPoolEntryAddress(unsigned > ConstantNum) const { > + assert(ConstantNum < ConstantPool->getConstants().size() && > + "Invalid ConstantPoolIndex!"); > + return (intptr_t)ConstantPoolBase + > + ConstantPool->getConstants()[ConstantNum].Offset; > +} > + > +intptr_t SizeEmitter::getJumpTableEntryAddress(unsigned Index) > const { > + const std::vector &JT = JumpTable- > >getJumpTables(); > + assert(Index < JT.size() && "Invalid jump table index!"); > + > + unsigned Offset = 0; > + unsigned EntrySize = JumpTable->getEntrySize(); > + > + for (unsigned i = 0; i < Index; ++i) > + Offset += JT[i].MBBs.size(); > + > + Offset *= EntrySize; > + > + return (intptr_t)((char *)JumpTableBase + Offset); > +} > + > Index: lib/Target/TargetMachine.cpp > =================================================================== > --- lib/Target/TargetMachine.cpp (revision 48143) > +++ lib/Target/TargetMachine.cpp (working copy) > @@ -31,6 +31,7 @@ > bool UseSoftFloat; > bool NoZerosInBSS; > bool ExceptionHandling; > + bool SizedMemoryCode; > Reloc::Model RelocationModel; > CodeModel::Model CMModel; > bool PerformTailCallOpt; > Index: lib/ExecutionEngine/JIT/JITEmitter.cpp > =================================================================== > --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 48143) > +++ lib/ExecutionEngine/JIT/JITEmitter.cpp (working copy) > @@ -18,12 +18,14 @@ > #include "llvm/Constant.h" > #include "llvm/Module.h" > #include "llvm/Type.h" > +#include "llvm/ADT/DenseMap.h" > #include "llvm/CodeGen/MachineCodeEmitter.h" > #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/CodeGen/SizeEmitter.h" > #include "llvm/ExecutionEngine/JITMemoryManager.h" > #include "llvm/Target/TargetData.h" > #include "llvm/Target/TargetJITInfo.h" > @@ -370,6 +376,7 @@ > virtual void startFunction(MachineFunction &F); > virtual bool finishFunction(MachineFunction &F); > > + void initConstantPool(MachineConstantPool *MCP); > void emitConstantPool(MachineConstantPool *MCP); > void initJumpTableInfo(MachineJumpTableInfo *MJTI); > void emitJumpTableInfo(MachineJumpTableInfo *MJTI); > @@ -469,19 +476,47 @@ > > > void JITEmitter::startFunction(MachineFunction &F) { > - uintptr_t ActualSize; > - BufferBegin = CurBufferPtr = MemMgr- > >startFunctionBody(F.getFunction(), > - ActualSize); > - BufferEnd = BufferBegin+ActualSize; > + MMI->BeginFunction(&F); > > - // Ensure the constant pool/jump table info is at least 4-byte > aligned. > - emitAlignment(16); > + if (SizedMemoryCode) { > + BufferBegin = CurBufferPtr; > + BufferEnd = (unsigned char*) 0xffffffff; > + > + // Ensure the constant pool/jump table info is at least 4-byte > aligned. > + emitAlignment(16); > > - emitConstantPool(F.getConstantPool()); > - initJumpTableInfo(F.getJumpTableInfo()); > + initConstantPool(F.getConstantPool()); > + initJumpTableInfo(F.getJumpTableInfo()); > + > + > + uintptr_t ActualSize = (uintptr_t)CurBufferPtr; > + CurBufferPtr = MemMgr->startFunctionBody(F.getFunction(), > + ActualSize); > + > + ConstantPoolBase = (void*)(((unsigned) ConstantPoolBase) + > CurBufferPtr); > + JumpTableBase = (void*)(((unsigned) JumpTableBase) + > CurBufferPtr); > > - // About to start emitting the machine code for the function. > - emitAlignment(std::max(F.getFunction()->getAlignment(), 8U)); > + emitConstantPool(F.getConstantPool()); > + > + } else { > + uintptr_t ActualSize; > + BufferBegin = CurBufferPtr = MemMgr- > >startFunctionBody(F.getFunction(), > + > ActualSize); > + BufferEnd = BufferBegin+ActualSize; > + > + // Ensure the constant pool/jump table info is at least 4-byte > aligned. > + emitAlignment(16); > + > + initConstantPool(F.getConstantPool()); > + emitConstantPool(F.getConstantPool()); > + initJumpTableInfo(F.getJumpTableInfo()); > + > + // About to start emitting the machine code for the function. > + emitAlignment(std::max(F.getFunction()->getAlignment(), 8U)); > + > + } > + > + > TheJIT->updateGlobalMapping(F.getFunction(), CurBufferPtr); > > MBBLocations.clear(); > @@ -579,12 +614,18 @@ > DOUT << "Disassembled code:\n" > << sys::disassembleBuffer(FnStart, FnEnd-FnStart, > (uintptr_t)FnStart); > #endif > + > if (ExceptionHandling) { > uintptr_t ActualSize; > + if (SizedMemoryCode) { > + SizeEmitter sz(LabelLocations); > + DE->EmitDwarfTable(F, sz, FnStart, FnEnd); > + ActualSize = sz.getCurrentPCValue(); > + } > SavedBufferBegin = BufferBegin; > SavedBufferEnd = BufferEnd; > SavedCurBufferPtr = CurBufferPtr; > - > + > BufferBegin = CurBufferPtr = MemMgr- > >startExceptionTable(F.getFunction(), > > ActualSize); > BufferEnd = BufferBegin+ActualSize; > @@ -598,11 +639,10 @@ > TheJIT->RegisterTable(FrameRegister); > } > MMI->EndFunction(); > - > return false; > } > > -void JITEmitter::emitConstantPool(MachineConstantPool *MCP) { > +void JITEmitter::initConstantPool(MachineConstantPool *MCP) { > const std::vector &Constants = MCP- > >getConstants(); > if (Constants.empty()) return; > > @@ -611,12 +651,15 @@ > const Type *Ty = CPE.isMachineConstantPoolEntry() > ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal->getType(); > Size += TheJIT->getTargetData()->getABITypeSize(Ty); > - > + > ConstantPoolBase = allocateSpace(Size, 1 << MCP- > >getConstantPoolAlignment()); > ConstantPool = MCP; > +} > > +void JITEmitter::emitConstantPool(MachineConstantPool *MCP) { > if (ConstantPoolBase == 0) return; // Buffer overflow. > > + const std::vector &Constants = MCP- > >getConstants(); > // Initialize the memory for all of the constant pool entries. > for (unsigned i = 0, e = Constants.size(); i != e; ++i) { > void *CAddr = (char*)ConstantPoolBase+Constants[i].Offset; > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ralph at inputplus.co.uk Sun Mar 30 17:41:32 2008 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 30 Mar 2008 23:41:32 +0100 Subject: [LLVMdev] Compile programs with the LLVM Compiler as a gsoc project In-Reply-To: <60853269-D412-4453-95BB-3847382D5267@nondot.org> References: <60853269-D412-4453-95BB-3847382D5267@nondot.org> Message-ID: <20080330224133.017815F88@blake.inputplus.co.uk> Hi Chris, > How about taking a linux distro like redhat or gentoo or whatever you > are familiar of comfortable with, and try compiling the whole thing > with llvm-gcc? As part of the GSoC project, you could file bug > reports for any issues you hit and help track down problems. They may seem a bit large and daunting. How about Linux from Scratch? If it's completed, more could be added on. http://www.linuxfromscratch.org/ Cheers, Ralph. From tonic at nondot.org Sun Mar 30 17:45:05 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sun, 30 Mar 2008 15:45:05 -0700 Subject: [LLVMdev] Compiling llvm-gcc on amd64 with 32 bits: assembler still carps In-Reply-To: <1206905945.7785.69.camel@kurier> References: <1206888030.7785.19.camel@kurier> <4aca3dc20803300922q225c7c72g2a57a94e75558d0f@mail.gmail.com> <4aca3dc20803300923w76549329ofcc05139af71c2cb@mail.gmail.com> <1206896870.7785.24.camel@kurier> <4012747D-8216-4F23-8DCD-A3271852C056@nondot.org> <1206905945.7785.69.camel@kurier> Message-ID: <4FCB7F4E-4325-47D9-9DA0-A0330F35A2E8@nondot.org> On Mar 30, 2008, at 12:39 PM, Joachim Durchholz wrote: > > Am Sonntag, den 30.03.2008, 10:28 -0700 schrieb Tanya Lattner: >> On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: >>> Look at how $LLVM_CONFIGURE is built, the final value is >>> >>> --prefix=/home/jo --enable-optimized --build=i686-pc-linux-gnu >>> --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu" >>> >> >> This looks likes its missing some stuff. Make sure the configure line >> is exactly as what is in README.LLVM. > > OK, I now have > > LLVM_VERSION_INFO=kurier-bootstrap /home/jo/llvm-gcc-src/configure > --prefix=/home/jo --enable-optimized --build=i686-pc-linux-gnu > --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu > --enable-llvm=/home/jo --enable-languages=c,c++ > Where have you built llvm? The enable-llvm dir should point to where you built llvm. > The --enable-llvm directory is the same as --prefix, I hope that's > right > (the actual binaries are in the 'bin' subdirectory). > > I don't think --enable-checking should be necessary, I had > llvm ./configure'd with --enable-optimized (I hope that's the same as > specifying ENABLE_OPTIMIZED=1 during the 'make' run for LLVM proper). > You have to build both a release build of LLVM and llvm-gcc or both debug. You can't mix. So if you did --enable-checking that Debug. SVN by default is debug. A release of LLVM is release by default. I think --enable-optimized and ENABLE_OPTIMIZED=1 are the same, so you should be ok. > Trying with OPTIMIZE_OPTION=-O2 didn't help. > > Anything else I may have overlooked? > I'm guessing its your --enable-llvm setting. Hope that helps.. -Tanya > Regards, > Jo > > > P.S.: Rerunning the failing command with -v gave me > > GNU C version 4.2.1 (Based on Apple Inc. build 5555) (LLVM build) > (i686-pc-linux-gnu) > compiled by GNU C version 4.2.1 (Ubuntu 4.2.1-5ubuntu4). > > so it seems to call the right compiler, but I still get > > /home/jo/llvm-gcc-wrk/./gcc/as --traditional-format -V -Qy -o > crtbegin.o crtstuff.s > GNU assembler version 2.18 (x86_64-linux-gnu) using BFD version (GNU > Binutils for Ubuntu) 2.18 > crtstuff.s: Assembler messages: > crtstuff.s:15: Error: suffix or operands invalid for `push' > crtstuff.s:29: Error: suffix or operands invalid for `call' > crtstuff.s:36: Error: suffix or operands invalid for `pop' > crtstuff.s:39: Error: suffix or operands invalid for `pop' > crtstuff.s:47: Error: suffix or operands invalid for `push' > crtstuff.s:60: Error: suffix or operands invalid for `call' > crtstuff.s:63: Error: suffix or operands invalid for `pop' > > (As noted in one of my previous mails, .../gcc/as is just a > shellscript > calling the installed as, which happens to be GNU as.) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From delta17 at cox.net Sun Mar 30 17:51:48 2008 From: delta17 at cox.net (Jon Sargeant) Date: Sun, 30 Mar 2008 15:51:48 -0700 Subject: [LLVMdev] Function Parameter Requirements? In-Reply-To: <200803310009.08743.baldrick@free.fr> References: <47EFFDCD.2070902@cox.net> <200803310009.08743.baldrick@free.fr> Message-ID: <47F01984.2090409@cox.net> Duncan Sands wrote: [snip] >> Finally, I suggest defining these additional terms in the >> type-classification section: >> - value type >> - scalar type >> - aggregate type > > Good idea. Want to prepare a patch? Sorry, I wasn't clear. What is a value type? A scalar type? An aggregate type? Best Regards, Jon From tonic at nondot.org Sun Mar 30 17:57:22 2008 From: tonic at nondot.org (Tanya Lattner) Date: Sun, 30 Mar 2008 15:57:22 -0700 Subject: [LLVMdev] Removing llvm-upgrade Message-ID: <94560399-CDAC-4EBB-95E8-CE3A248D7524@nondot.org> At the end of this week, I plan to remove llvm-upgrade from SVN. All tests in llvm/test have been upgraded to no longer use llvm-upgrade. If anyone has any objections to this, please speak now! Thanks, Tanya From evan.cheng at apple.com Sun Mar 30 22:28:09 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 30 Mar 2008 20:28:09 -0700 Subject: [LLVMdev] Introducing a branch optimization and prediction pass In-Reply-To: <47EE3DEB.3020408@gmail.com> References: <47EE3DEB.3020408@gmail.com> Message-ID: <32A310B0-76CD-4C9E-8D70-6C7B02E0C088@apple.com> On Mar 29, 2008, at 6:02 AM, T?r?k Edwin wrote: > Hi, > > I would like to transform unpredictable conditional branches with a > small body into cmov instructions to reduce branch miss penalty. > LLVM generates cmov/setcc instructions when SelectInst is used. The > idea > is to transform regular branches into selects, when that is possible > and > profitable. LLVM is already aggressively turning branches into selects as far as I can see. > > However this needs branch prediction info, and it seems LLVM doesn't > provide that AFAICT. > Could gcc's branch predictor be used here, or are there plans for an > llvm-specific branch predictor? Sure, either the FE or some earlier profiling pass should provide some branch predication info. > > > This has performance benefits if the branch is otherwise > unpredictable, > for example: > > for(i=0;i if(isalnum(buf[i])) > *p++ = buf[i]; > } > > Assume the input data is binary data, you can't know in advance if the > branch is taken or not. Either prediction will lead to a miss > penalty X% > of the time. > The conditional write can be transformed using a dummy variable [2]. Ok. You want to speculatively execute the code and only writes back the result if the predicate is true, right? > > > But, if the branch's body is big, or if is statically/dynamically > predictable this optimization must not be applied. > This optimization needs the following: > * determine if the transformation can be applied: > * if the body has call/return/asm it cannot be applied > > * if volatile data is accesed within the loop > * any other situations? If there are any instructions with side effects then this cannot be done. > > * determine if branch is statically/dynamically predictable: > * statically: if compiler can predict branch, don't apply this > optimization > * dynamically: can branch be predicted based on execution history > (i.e. can CPU predict it?) Based on profiling data from previous runs? Or dynamic profiling in JIT situation? > > * how to determine if a branch's body is small? > if execution_cost_of(body) + > execution_cost_of(cmov)/branch_miss_probability < branch_miss_penalty, > or simply: execution_cost_of(body) < branch_miss_penalty > If it is bigger, then it is faster if we take the miss penalty (and > don't execute the body) > But miss-penalties, and execution_costs are target specific, so use > TargetData here (and teach it about penalties), or > use some heuristic based on number of instruction in basic block? Sounds reasonable. But it's potentially more complicated than this for a target like x86 that have very few registers. The speculatively executed code will clobber registers so it has significant cost if the result of computation is not written back. > > * if we cannot transform all instructions from the basic block into > instr+cmov, then it is not worth applying this optimization (since > we'll > have a branch anyway). Sure. It might be worthwhile to extend the if-converter to do this. The first step is to turn it on for x86 to convert blocks which are entirely move's. > > Does Codegen guarantee to always transform Select into CMOV/SETCC (or > equivalent), on targets that support it? Right. > > * if target doesn't support conditional moves, we must not apply this > transformation Correct. > > * memory ordering/multi-thread safety: > if(pthread_mutex_trylock(...)) { *p++ = 4;} > Transforming this into a cmov should be safe, because we are using a > dummy variable on the stack as destination [2] if condition is false. > What if we have memory reads, those might not be always be safe to > move > out of the branch's body (because the condition could be required to > ensure the access is valid), > or it could actually decrease performance in case the guarding > condition > is to prevent L2 cache misses, example: > if(fast_filter_table[value] == match && slow_filter_table[value] == > match) { ... do something ... } That's something to worry about later. :-) > > > If we unconditionally read from slow_filter_table it could actually > reduce the performance (assume slow_filter_table is huge), and might > not > be legal because we violate > the short-circuit evaluation. Right, speculative loads would require much more analysis to ensure safety. This might be something you don't want to do in step 1. > > > (BTW, the branch predictor should say it is predictable, and we > wouldn't > apply the transformation at all, but we cannot rely on the branch > predictor to make > short-circuit eva