WIP patch, RFC: ARM ldm/stm peephole rewrite

[Bernd Schmidt]

On 03/25/2010 12:42 PM, Richard Earnshaw wrote:

> 1) Please no more ML in the ARM backend.  It's bad enough that the neon
> patterns are generated that way, but that's a massively bigger chunk of
> code.  This bit seems more like doing it for its own sake.

Well, I didn't want to write them by hand, and the other generators were
in ML so I was going for consistency.  What do you suggest - just delete
the generator after I'm done with it, or write another one in C?

Do you think we should have a full set, or only up to four registers?

> 2) Why are you generating the .md file fragment with the GPL exception
> clause?  This file is part of core GCC not a library.

Copied from the wrong neon generator.

> 3) IIRC LDMIB with write-back trips a bug on some StrongARM chips (sadly
> not yet obsolete).  So anything up to ARMv4 needs to avoid this.

Ok.  Is it only ldmib?

> 4) LDM is not always the best thing.  On more recent chips for a small
> number of regs they can be slower than individual loads, and only once
> you go above 4 regs might it break even.  On some cores it may never be
> faster than using LDRD (especially if the address is 64-bit aligned).
> Don't forget than in Thumb-2 LDRD can take any two independent registers
> with no ordering constraint.

The current peephole code doesn't handle this, does it?  Where can I
find more information about the cases in which it is profitable?  I
think as a code-size optimization, it should always be a win; and
there's a Thumb PR requesting this type of transformation.

> Finally, I'm presuming that as a WIP this isn't aimed at 4.5. 

It isn't.


Bernd