Quoting omalleys@xxxxxxx: > Quoting Michael Hope <michael.hope@xxxxxxxxxx>: > >> On Sat, Apr 2, 2011 at 12:04 PM, Xerxes Ranby <xerxes@xxxxxxxxx> wrote: >>> On 2011-04-02 00:20, Michael Hope wrote: >>>> >>>> On Sat, Apr 2, 2011 at 1:50 AM,<omalleys@xxxxxxx> wrote: >>>>> >>>>> Did anyone ever get llvm/clang working? >>>>> >>>>> It -says- it is fast, good optimization, faster binaries, aimed at >>>>> generating better errors, and has good tools for debugging. :) the >>>>> darwin-arm (and x86 ports are production quality. >>>>> There isn't support for EABI or< armv6 in the ARM-backend yet. >>>> >>>> I'm having a bit of a look at this for Linaro at the moment. LLVM is >>>> quite respectable, and generates code that is slower than GCC but >>>> generally in the same ballpark. Of the three benchmarks I've tried, >>>> two took 8 % longer to run on an A9 and pybench took more like 40 % >>>> longer to run. pybench is sensitive to having a good inner loop >>>> though. >>> >>> For what I know, LLVM defaults to ARMv4t code generation unless it >>> gets told >>> that it are allowed to use newer code generation. >>> >>> This llvm bug tracked how llvm and clang implemented X86 cpu feature >>> autodetection code to make clang generate the best code available for any >>> given host when using -march=native. >>> http://www.llvm.org/bugs/show_bug.cgi?id=5389 >>> >>> I have added an initial cpu features auto-detection code for ARM to that >>> bug-report for the LLVM part. >>> >>> Do you get better performance on your A9 tests when running clang with >>> clang -mcpu=generic -mattr=+neon,-thumb2,+v6,+vfp2 >> >> I've only done a first pass, but I'm fairly sure I used clang >> -mcpu=cortex-a9 -mfpu=neon. I don't think clang supports ARMv4T at >> all. I'm working on automating the benchmarks at the moment and I'll >> add llvm into that. Better than some throw-away, unreproducable >> results :) >> > > According to what I understood from their web docs (which may or may > not be accurate..) and was listed under "known issues" I think for > the "backend" for the 2.8 release: > -armv4 doesn't have thumb support yet. > -EABI is unsupported for all processors. > > I was unclear whether that was just the llvm/clang toolchain or it > also included the llvm-gccX toolchain. > > LLVM 2.9 is scheduled to be released today (April 4th). 2.8 is still > listed as the current version on their website, so there might be a > delay or it may not be updated yet. > I will correct myself, it is the armv6 that has issues with thumb support. I don't know if that means that everything < armv6 has the same issue or not. - performance- phoronix did a benchmark testing between gcc 4.6, gcc 4.5, llvm/clang, llvm/dragonegg on x86/x86_64 http://www.phoronix.com/scan.php?page=article&item=gcc_46_llvm29&num=1 It doesn't appear as though llvm is necessarily faster. I'm actually kind of interested in how much more colourful the warnings are. :) (BTW I wasn't actually suggesting -changing- compilers at this point without EABI support.) However more colourful error messages maybe useful. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
