similar to: [LLVMdev] arm compiler benchmarks

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

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 >

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 >

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

Reed, On May 14, 2012, at 3:45 PM, reed kotler <rkotler at mips.com> wrote: > On 05/14/2012 02:42 PM, Jakob Stoklund Olesen wrote: >> On May 14, 2012, at 2:28 PM, reed kotler wrote: >> >>> I'm not using getMinimalPhysRegClass. Some target independent code is using it. >> Probably PEI. >> >>> It makes trouble for us and I would like to

My understanding was that micro mips was similar to Thumb2, in that the smaller encodings have constraints on which registers can be read/written, because of the narrowing of the register fields in the encoding. If that's the case, then it definitely makes sense to model the micro mips instruction set as distinct from the mips32 instruction set, in basically the same way that Thumb2 is done.

Micro mips is really 100% .s compatible with mips32. There are no register field size constraints and such. It's a strict superset of mips32. For the gcc port, the assembler is basically the only thing we changed. The gcc port was just adding the ".micromips" directive to the .s file and maybe some tiny driver work. That is the quandary. The entire .td file would have to be

At one of the BOFS during the llvm conference a few years back, one of the Apple managers stated in effect that their view of -Os was to get some modest savings but only if performance has near 0 impact. On 02/23/2013 09:45 AM, Reed Kotler wrote: > On 02/23/2013 04:28 AM, David Chisnall wrote: >> Hi Reed, >> >> -Os could do with some love. It is more or less the same set

On 02/23/2013 04:28 AM, David Chisnall wrote: > Hi Reed, > > -Os could do with some love. It is more or less the same set of passes as -O2, but with a few things that are most likely to increase code size removed. We have had problems with it in the past for FreeBSD's bootloader. By tweaking the set of default passes added for -Os, I got the size down by about 20%, but I didn't

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

The problem is that everything about the mips32 and micro mips 16 instruction is the same, aside from the encoding in to binary. Seems like maybe we need to extend the notion of an instruction so that it can have alternate encodings depending on subtarget. On 09/05/2012 08:28 PM, Jim Grosbach wrote: > The instructions are defined by their encodings, not the assembly syntax. You want

I think that Bill Wendlings new attribute implementation would allow me to do this but it is not ready yet. Maybe it's okay to just add them to the list of function attributes as I suggested. But in the end, someone has to approve the checkin. On 01/11/2013 07:35 AM, Reed Kotler wrote: > Yes, you could have mips16 and fastcc. > > Mips16 just means that processor mode to execute

The instructions are defined by their encodings, not the assembly syntax. You want separate instruction definitions for the different encodings and select. Between them in the assembler via sub target features. See ARM handling of thumb vs thumb2 vs arm for examples of how to do this. On Sep 5, 2012, at 6:59 PM, reed kotler <rkotler at mips.com> wrote: > The micro mips processor

Hi Reed, -Os could do with some love. It is more or less the same set of passes as -O2, but with a few things that are most likely to increase code size removed. We have had problems with it in the past for FreeBSD's bootloader. By tweaking the set of default passes added for -Os, I got the size down by about 20%, but I didn't have time to evaluate whether this was a general saving or

On 11/18/2013 06:34 PM, Jim Grosbach wrote: > On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > >> I don't know ARM hardly at all but... >> >> This comment does not seem to match the code. >> Or maybe tBfar is a BL? > What does the definition of tBfar say? Okay.. but // Far jump // Just a pseudo for a tBL instruction. Needed

On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > I don't know ARM hardly at all but... > > This comment does not seem to match the code. > Or maybe tBfar is a BL? What does the definition of tBfar say? > > Also, how does this work if the destination is greater than 2**21? > It doesn’t. IIRC, that’s under the category of “if people start

Yes, you could have mips16 and fastcc. Mips16 just means that processor mode to execute that function is "mips16". So in a mips16 designated function, I will just emit mips16 instructions and in a "nomips16" function, just emit normal mips32 instructions. I tend to call this "mips32" normal mode, "standard encoding" because in reality the processor is

In this case, you can specialize a few pass manager objects, each for a specific sub target type. E.g. PassManager pm0 = .. ; // for mips32; PassManager pm1 = .. ; // for mips16; ... if(function needs to run on mips32) pm0.run(); else if(function needs to run on mips16) pm1.run(); ... Of course, you have to figure out the suitable sets of functions for each sub target. Hope it helps.

not in this case. the architecture is changing on a per function pass. mips32->mips16->mips16.... same issue would be for arm->thumb1->arm On 03/29/2013 04:26 PM, Chuck Zhao wrote: > Can you do this instead: > > PassManager pm = ...; > pm.add(other needed passes); > ... > if(arch you are interested) > pm.add(your pass); > ... > pm.run(); > > >

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