This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reload Issue -- I can't believe we haven't hit this before


On Wed, 2005-04-20 at 18:51 +0200, Eric Botcazou wrote:
> > Yes, I meant SET_DEST.  Do you see how if a SET_DEST is a pseudo
> > which did not get a hard register and is equivalent to a readonly
> > memory location that the insn is useless?
> 
> Yes, I think so: being equivalenced implies that there was a REG_EQUIV note, 
> so the insn cannot do anything else than setting the pseudo to the value it 
> is already equivalenced to.
Right.  So, in theory all we have to do is delete these insns.

The problem is detection and elimination of these insns.

It's relatively easy to scan the register state to find pseudos which
were not assigned a hard reg and which are equivalenced to a readonly
memory location.  If you find any, then you scan the IL and kill the
offending insns.

Seems trivial.  Unfortunately, it's not that simple.

The relatively unstructured nature of RTL means the offending assignment
to the pseudo could appear in a multitude of contexts, including simple
assignments or part of an arbitrarily complex parallel.  It's probably
not safe to simply remove the assignment if it appears in a PARALLEL as
doing so may create an unrecognizable insn.  Ugh.  If we find such cases
we could fall back to not recording the equivalence.

But what worries me even more is spilling.  Say a pseudo has a hard reg
assigned and is also equivalent to a readonly memory location.  Reload
then decides to spill the pseudo out of the hard reg because the hard
reg was needed for something else.  When that occurs we'd have to scan
affected live range of the pseudo for assignments into the pseudo and
remove them like I've suggested above.  But that brings another set of
bookkeeping problems -- we're twiddling reg_equiv_XXX significantly
later in the reload process, and I'm not sure how safe that's going to
be.

Given how rare this situation occurs, I'm leaning towards simply 
ignoring the problematical equivalences.

jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]