Fwd: Re: ARM ldm/stm peepholes

[Bernd Schmidt <bernds at codesourcery dot com>]

And again, since the mailing list apparently thought I was a spammer:

-------- Original Message --------
Subject: Re: ARM ldm/stm peepholes
Date: Tue, 27 Apr 2010 23:49:42 +0200
From: Bernd Schmidt <bernds@codesourcery.com>
To: Richard Earnshaw <rearnsha@arm.com>
CC: ramana.radhakrishnan@arm.com, GCC Patches <gcc-patches@gcc.gnu.org>

On 04/23/2010 03:02 PM, Richard Earnshaw wrote:
> 
> On Fri, 2010-04-23 at 09:13 +0100, Ramana Radhakrishnan wrote:
>> It would be useful to be able to control ldm /stm generation on a
>> per-core basis i.e. on some cores it might be useful to have ldm's and
>> stm's as a size optimization rather than as a performance optimization.
>> For instance the A8 and A9 have a good ldm and stm setup but there might
>> be circumstances where this might not be the right thing to do.
>>
> 
> This shouldn't be done on an explicit 'per-core' basis, but on a cost of
> alternatives basis.  That is, there should be a cost function that
> returns the cost of an ldm with N registers; this can then be compared
> with the cost of (N+1)/2 ldrd instructions (if valid) or N ldr
> instructions and the cheapest alternative selected.  The new costing
> framework that I committed last week should easily support adding such
> functions.  It may be necessary to separate out the costs of LDM and STM
> as they could, in theory be different.

As a step in that direction, I've created a function
multiple_operation_profitable_p which can do these cost calculations.
For now I've retained the existing (minimal) heuristic; I feel
uncomfortable adding anything else since I don't believe I have access
to the necessary information.

If you can point me to any ARM optimization guides which I can use to
determine the correct costs, I could add this.  Alternatively, if you
could add ldm/ldrd/stm costs to your new infrastructure, I can make use
of it.  However, I'd still claim that this patch is by itself an
improvement, and can easily be extended later if someone has the correct
numbers.  The patch is already extremely big and it would be somewhat
easier to commit it now as a logically separate step before adding ldrd
support - it would also help locate problems if there are regressions.

New version below, now also includes the peep2 changes.  Those help
avoid the need for some redundant peepholes that would otherwise be
required to handle peep2 deficiencies.  Minimally tested since not much
changed since I previously posted these patches, will of course retest
whenever something is ready to be committed.


Bernd

Attachment: ldmstmv6g.diff
Description: Text document