[LLVMdev] arm compiler benchmarks

[reed kotler]

I will surely share some results when I have them.

I'm working on mips 16 which is like thumb 1.

For mips 16 people only care about size usually.

I need to implement a simple version of constant islands which I hope to 
finish this week and then I should have the tools to start to be 
competitive.

Reed

On 02/27/2013 06:23 AM, Renato Golin wrote:
> On 27 February 2013 08:54, David Chisnall <David.Chisnall at cl.cam.ac.uk 
> <mailto:David.Chisnall at cl.cam.ac.uk>> wrote:
>
>     > People normally care about code size on Cortex-R/M and ARM9 or
>     older, and in there, not many LLVM users.
>
>     There are a lot of A8 devices around with 256KB (or less) of L2
>     cache (32KB of L1 i-cache), and so code density, if not code size,
>     matters a lot for these.  Cache sizes in mobile chips tend to be
>     as small as possible, as it's very hard to turn off those
>     transistors (there are several projects at ARM and elsewhere that
>     I'm aware of in this direction, but I don't know of any in
>     shipping products yet).
>
>
> I didn't mean to say that code size is not important, especially for 
> ARM, just that the average LLVM user (even ARM users) will not care 
> yet that much.
>
> Most benchmarks I've seen around are all platform software, comparing 
> performance with Atom and not a single mention on code size. When I 
> did some benchmarks a few years back, I noticed that LLVM's code was 
> at least twice as big as GCC with the same specs, some times more than 
> 4x bigger, would be good to know how it compares now to see how much 
> people really care about code size.
>
> Reed,
>
> Will you be able to share your results? I think you'll find that LLVM 
> has indeed progressed in that area, as I've seen some commits going 
> through during the last few years on that area. I'd like to know if 
> we're getting close to GCC.
>
> cheers,
> --renato
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130227/e3edabe2/attachment.html>