similar to: [LLVMdev] Benchmarks for small embedded platforms

On Jul 31, 2012, at 4:43 AM, James Pallister <james.pallister at embecosm.com> wrote: > Hi Everyone, > > As you may recall (I posted a while back) I'm currently doing a project > measuring the energy consumption for different compiler flags. I've now > gathered a set of benchmarks which I think are appropriate, for these > (very) low end embedded platforms. >

Hi, I didn't do any serious benchmarking but so far I never found a case where LLVM does better than IAR on CortexM0, but I saw a lot of cases where IAR output is better than LLVM... That said I did not use -Os or -Oz, I just used -O3. A recurrent situation is that LLVM push/pop one or two extra registers compared to IAR, I guess it does so in order to comply with a standard ABI or

What about benchmarks on other Arm devices? On 02/26/2013 02:52 PM, Jim Grosbach wrote: > Cortex-M0 is a Thumb1 only device. There hasn't been any concerted > effort to tune LLVM's Thumb1 output in quite a long time. Even back then > (2008 or so), the effort was mainly to get it to work acceptably, with > the real performance tuning work being done for Thumb2. I'm not >

Cortex-M0 is a Thumb1 only device. There hasn't been any concerted effort to tune LLVM's Thumb1 output in quite a long time. Even back then (2008 or so), the effort was mainly to get it to work acceptably, with the real performance tuning work being done for Thumb2. I'm not surprised that an embedded market focussed compiler like IAR is better tuned for a chip like that. -Jim On Feb

I've not run any on non-iOS devices, and haven't looked at GCC since v4.2.1 due to licensing issues, so I don't have a good feel for comparative benchmarking. -Jim On Feb 26, 2013, at 4:20 PM, Reed Kotler <rkotler at mips.com> wrote: > What about benchmarks on other Arm devices? > > On 02/26/2013 02:52 PM, Jim Grosbach wrote: >> Cortex-M0 is a Thumb1 only

Hello, as a newbee, I'd appreciate some support on regression test setup. Specifically, I am interrested in the feature of tail call optimizations for the ARM v6m targets. This feature currently seems to be completely deactivated at the moment (v6m being based on thumb1 ?!). According to my code-reading, this feature will involve some modifications in epilogue generation. My work on a gcc

On 18 December 2014 at 04:02, Tim Northover <t.p.northover at gmail.com> wrote: >> You have some special version of qemu? My default distribution's qemu >> package did not have a cortex-M0 nor has qemu head freshly taken from git: > > The trouble with Cortex-M0 (from a virtualised testing perspective) is > that it doesn't have an MMU, so any "real"

On 12/16/14 3:53 AM, Kristof Beyls wrote: > I've been wondering too about how to get better ARM v6m compile-and-execute > testing going. > > As you say Jon, the non-execution-based regression tests are surprisingly > good at catching issues; but they're no full substitute for executing the > code produced by the backend for a reasonably-sized test suite. > > If

Hi Everyone, I'd like to announce a project joint between the University of Bristol and Embecosm. In this project we hope to identify what effect a broad range of compiler options has on the energy consumption of different embedded platforms. To do this we are finding a set of relevant benchmarks, compiling them with different options and measuring their energy consumption on these platforms.

Thanks for the example, that is very useful in working out the overall scope of the problem, which is now wider than I thought it was. I've put some comments inline. On 15 March 2018 at 19:12, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: >> >> Hello everyone, this is most likely Arm specific, but could affect

Hi Tim, I wonder if you could help me with the following, even if just giving some pointers about where to look. I previously posted a similar question in the mailing list, but unfortunately I have not received a reply. This is the subject: I want to reduce the number of register spills to the stack that are created around storeRegToStackSlot and loadRegFromStackSlot In order to do so, I can

Hello everyone, this is most likely Arm specific, but could affect other targets where there is a somewhat complex relationship between the triple and mcpu option. At present when clang is used as a linker driver for the gold-plugin and when using and an explicit -mcpu is not given to clang, then clang will always generate a -Wl,-plugin-opt=mcpu=<default CPU> where the default CPU is based

On 16 March 2018 at 10:38, Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 15 March 2018 at 19:12, Friedman, Eli <efriedma at codeaurora.org> wrote: >> Having ARMv7a instructions in an ARMv4t file shouldn't be a problem: a >> function should be allowed to override the CPU attributes to generate code >> for a newer target. This is generally

On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: > Hello everyone, this is most likely Arm specific, but could affect > other targets where there is a somewhat complex relationship between > the triple and mcpu option. > > At present when clang is used as a linker driver for the gold-plugin > and when using and an explicit -mcpu is not given to clang, then clang > will

I haven't tried using -Os/z on any ARM device for the last 3 years, and back then, -Os would break many things. People normally care about code size on Cortex-R/M and ARM9 or older, and in there, not many LLVM users. --renato On 27 February 2013 00:38, Jim Grosbach <grosbach at apple.com> wrote: > I've not run any on non-iOS devices, and haven't looked at GCC since >

On 27 February 2013 08:54, David Chisnall <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

> > $ qemu-arm -cpu ? > > Available CPUs: > > arm926 arm946 arm1026 arm1136 arm1136-r2 arm1176 arm11mpcore > > cortex-m3 > > cortex-a8 > > cortex-a8-r2 cortex-a9 cortex-a15 ti925t pxa250 sa1100 sa1110 > pxa255 pxa260 > > pxa261 pxa262 pxa270 pxa270-a0 pxa270-a1 pxa270-b0 pxa270-b1 xa270- > c0 > > pxa270-c5 any > > >

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

Hello, find enclosed a first patch for adding tail call optimizations for thumb1 targets. I assume that this list is the right place for publishing patches for review? Since this is my first proposal for LLVM, I'd very much appreciate your feedback. What the patch is meant to do: For Tail calls identified during DAG generation, the target address will be loaded into a register by use

Dear R community, I've been writing simple functions for the past year and half and have come across a similar problem several times. The execution of a function within my own function produces NaN's or fails to execute as intended. My conundrum is that I can execute the function outside of my function without error, so it's difficult for me, as a novice functioneer, to figure out