[ColdFire 36/63] Use RTL for prologues and epilogues

[Richard Sandiford]

Roman Zippel <zippel@linux-m68k.org> writes:
> On Tue, 23 Jan 2007, Richard Sandiford wrote:
>> >> My hope was that movem could be used for other things too
>> >> (inline memcpy()s, maybe), which would mean that even the
>> >> pre-reload optimisers would get to see these insns.
>> >
>> > This is a rather complex pattern, so I doubt it will be very useful, 
>> > before reload it's better to have simple patterns and I have no idea how 
>> > you want to get this through register allocation.
>> > Patterns like this are used in {load,store}_multiple and AFAICT it's only 
>> > used for function parameters, where the hard registers are known.
>> > What kind of pre-reload optimisations are you thinking of?
>> 
>> In answer to the last point, I was saying that instructions created by
>> things like movstr expanders would be seen by pre-reload optimisers.
>> It was just a general statement; I wasn't thinking of any optimisation
>> in particular.
>> 
>> And yes, these patterns are designed to only accept hard registers.
>> The difference is that the patterns in the patch enforce consistency
>> whereas (from what I gather of movem_operation), the pattern above
>> doesn't.
>
> Considering the possibility we generate a movem pattern before reload, the 
> pattern would be readonly anyway and would only have informational value 
> and could be optional. The predicate check would then simply verify that 
> this extra information matches the information in the unspec.
>
> OTOH considering that there is currently no use for this detailed 
> information, I'd rather keep it simple (and the unspec doesn't preclude 
> adding this information later).

I simply don't understand this argument.  The patch I posted
describes what the pattern does in ordinary RTL, and verifies
that the pattern is a valid h/w instruction.  That seems exactly
the right thing to do.  Why go out of your way to introduce an
unspec when a patch that doesn't need it already exists?

I'm not sure this argument is getting us anywhere though.
It's not our call, so let's see what the maintainers think.

Richard