Hit send accidentally on my last mail. Sorry
On 9 Dec 2010, at 15:19, "Julian Brown" julian@codesourcery.com wrote:
On Thu, 09 Dec 2010 14:42:49 +0000 Andrew Stubbs ams@codesourcery.com wrote:
On 26/11/10 11:11, Andrew Stubbs wrote:
As we discussed on Monday, I think it might be helpful to get a number of knowledgeable people together on a call to discuss GCC optimization opportunities.
So, I'd like to get some idea of who would like to attend, and we'll try to find a slot we can all make. I'm on vacation next week, so I expect it'll be in two or three week's time.
I've now collected together all the ideas people sent to me here: https://wiki.linaro.org/AndrewStubbs/Sandbox/GCCoptimizations
It might be worth talking about even the oldest differences between the ARM instruction sets and "traditional RISC", e.g.:
- Load/store multiple instructions: GCC only generates these from load_multiple/store_multiple (from a couple of places where hard registers are already known, e.g. function prologues & epilogues), or using peepholes. All ARM chips support much more generality for the latter: e.g. sparse sets of registers, and transfers of more than four registers. Maybe a pass can be added to somehow take better advantage of those.
Also keep in mind the constraint of increasing register numbers getting increasing addresses this pass has to run after reg-allocation or we need to teach GCC to assign registers according to these constraints.
It might also have some effects with generated schedules where we now might change the order in which values are produced .
Ramana
Conditional execution: we already know improvements can probably be made here.
Shifted operands in ALU ops: I think GCC generally does quite well at using these: maybe there are places where they can be used more effectively though. There are certainly several "special tricks" you can do with these, though GCC probably knows most of them by now.
Conditional flag-setting: I'm not sure if there's much more to be gained from this, but it might be worth looking at also.
Hand-written assembler code is, of course, likely to use all of the above extensively...
Julian
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain