similar to: [LLVMdev] PR 1660

433.milc, 447.deall, and 450.soplex are run as part of the nightly tests on Darwin (=MacOSX) in a way that closely approximates -O4. They are working there. I am inclined to suspect gold given that they work at -O3. Can a Linux person comment? On Jul 23, 2010, at 10:19 AMPDT, Reza Yazdani wrote: > Following is the list of fp benchmarks that fail. They all pass with > -O3, but

Hi Dale, Thanks for getting back. I may not be able to switch to llvm 4.2 at this time. I did try: llvm-gcc --emit-llvm -c sumarray.c -o sumarray.bc llc -march=ppc32 sumarray.bc gcc -arch ppc sumarray.s And this produced a ppc binary that worked (at least in this case). Do you know if this approach is worthwhile? Thx, Jose -----Original Message----- From: Dale Johannesen [mailto:dalej at

Thanks again, Dale. Hopefully, someone has the answer. Jose -----Original Message----- From: Dale Johannesen [mailto:dalej at apple.com] Sent: Friday, January 29, 2010 3:52 PM To: Jose Rangel Cc: Dale Johannesen Subject: Re: [LLVMdev] llvm-gcc 4.0 question On Jan 29, 2010, at 3:13 PMPST, Jose Rangel wrote: > Hi Dale, > > Is there a way to get llvm 4.2 and os x 10.4 to work

Hi, I think Dale meant to post this to ask the whole group, instead of just me. Basically, I'd like to build llvm-gcc 4.2 on host i686-apple-darwin9 for target powerpc-apple-darwin8. So far my efforts have failed. If you know the answer or can point me in the right direction, I'd be much obliged. Thx, Jose > Hi Dale, > > Is there a way to get llvm 4.2 and os x 10.4 to work

On Jan 29, 2010, at 2:55 PMPST, Jose Rangel wrote: > Hi Dale, > > Thanks for getting back. I may not be able to switch to llvm 4.2 at > this > time. I did try: > > llvm-gcc --emit-llvm -c sumarray.c -o sumarray.bc > llc -march=ppc32 sumarray.bc > gcc -arch ppc sumarray.s > > And this produced a ppc binary that worked (at least in this case). > > Do you

Following is the list of fp benchmarks that fail. They all pass with -O3, but some fail with -O4. I did the test run. Thanks, Reza Estimated Estimated Base Base Base Peak Peak Peak Benchmarks Ref. Run Time Ratio Ref. Run Time Ratio -------------- ------ --------- ---------

Hi Dale, Thanks for replying. Concerning Darwin, I compiled this test on snow leopard and ran it using rosetta (that is, using -arch ppc -m32). I will try this later on leopard. Thanks, Jose ________________________________ From: Dale Johannesen [mailto:dalej at apple.com] Sent: Friday, January 22, 2010 3:10 PM To: Jose Rangel Cc: Dale Johannesen; llvmdev at cs.uiuc.edu

Le 27 mai 2010 à 09:15, Kevin Wooten a écrit : > Implementing the backend (or editing the current PPC backend as needed) is a definite option. This seems to be the real question... which is easier... maintaining the PPC backend or maintaining the rewriter. Currently (in admittedly trivial tests) I have gotten the rewriter to work and output C code. There are some outstanding issues to do

PS3 is not "a Linux derivative." The compilers supplied by SCE for PS3 game development are highly customized and support a customized ABI that will take some time to adjust LLVM and Clang to support. You'd likely also run afoul of a TRC or two, similar to the problems you'll face with Microsoft TCRs mentioned earlier. Alex On May 27, 2010, at 12:15 AM, Kevin Wooten

Please create a thread on DevNet to discuss this further. Alex On May 27, 2010, at 9:26 AM, Kevin Wooten wrote: > By linux derivative I meant that it borrows the linux GCC ABI... and > it does. You can compile with an off the shelf GCC cross compiler > and link the resultant object files ones compiled with the PS3 > provided version. We have done it. > > Also, as both

Implementing the backend (or editing the current PPC backend as needed) is a definite option. This seems to be the real question... which is easier... maintaining the PPC backend or maintaining the rewriter. Currently (in admittedly trivial tests) I have gotten the rewriter to work and output C code. There are some outstanding issues to do with linking and accessing the reflection information

Why? I think the discussion belongs here, and the topic doesn't seem to include proprietary information - a lot of 360 info has been made public through MS material. Other info can be discussed without much disclosure (we can refer to TCRs by three-letter category and number, etc). - Sherief On May 27, 2010, at 1:15 PM, Alex Rosenberg wrote: > Please create a thread on DevNet to discuss

llvm can output C code, but that target has bitrotted severely over the last few months and nobody seems to be interested in fixing it. You may need to do some work there. Alternatively you could implement the PPC ABI that you need. There are several examples of supporting multiple ABIs on the same hardware, x86 being the most obvious. A lot of simple stuff will probably Just Work with the

llvm-gcc-4.0 is no longer maintained. Use llvm-gcc-4.2. On Jan 29, 2010, at 2:01 PMPST, Jose Rangel wrote: > Hi, > > I am using the llvm-gcc 4.0 front end binaries from llvm.org on an > intel > mac running 10.5.8. A couple of questions: > > 1) these binaries have "darwin8" as part of the file name. Are these > compatible with OS X 10.5.8 aka darwin9? >

Hi, I am using the llvm-gcc 4.0 front end binaries from llvm.org on an intel mac running 10.5.8. A couple of questions: 1) these binaries have "darwin8" as part of the file name. Are these compatible with OS X 10.5.8 aka darwin9? 2) assuming (1) is ok, if I compile a hello world program using: gcc -arch ppc hello.c, I get a ppc binary, but if I use llvm-gcc -arch ppc hello.c, I get an

Kevin, there're some unwritten rules on the 360 that seem to interfere with code generation - pointer load-stores seem to require zeroing the most significant 32 bits, for example - that was one issue that I ran into a while ago while fooling around with code generation on the 360 (and don't blame me if I'm slightly off the mark, it was quite a while ago). I didn't seem to find it

By linux derivative I meant that it borrows the linux GCC ABI... and it does. You can compile with an off the shelf GCC cross compiler and link the resultant object files ones compiled with the PS3 provided version. We have done it. Also, as both an XBox 360 and PS3 developer, there seems to me to be nothing in the TCRs/TRCs that preclude us from using a different compiler. There are rules

On Jan 22, 2010, at 3:01 PMPST, Jose Rangel wrote: > 2) The following test is commented out on purpose: > MultiSource/Benchmarks/Misc-C++-EH/spirit > > Should this test still be commented out? It’s actually has the most > lines of code of all your tests and seems quite useful. In addition, > it seems to work for us. Is there something wrong with this test > (e.g. buggy

Yep... I have been a 360 developer since the days when it was a actual Macintosh G5. I went to all the early tech. seminars and learned way more about that wacky processor and MS's seemingly crazy ABI choices than I care to (I know, I know, they had their reasons for them). Knowing this is why I quickly turned toward rewriting objc instead of attempting to implement a backend. I have also

Assign the bug to me and I'll fix it in TOT next week! Thanks for narrowing it down! On Wednesday, September 22, 2010, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi all, > > I think I figured it out: > 112804 causes 64-bit UNPCKLBW to no longer be selected for certain cases. > 112805 is benign. > 112806 causes 64-bit UNPCKHBW to no longer be selected for