This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ColdFire 36/63] Use RTL for prologues and epilogues
Hi,
On Tue, 23 Jan 2007, Richard Sandiford wrote:
> > These operands are inside an unspec, why should they do that?
>
> Only operands 1 and 2 are inside an unspec. The actual SET operands
> are not. My point is that the SET operands could in principle be
> changed without updating operands 1 or 2. The rtl optimisers are
> not obliged to consider the possibility that the number of a hard
> register operand is encoded in some other constant operand.
That's why I said I'm considering to move the set part into a frame
related note.
> >> 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).
bye, Roman