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]

Re: Reload patch to improve 386 code


>   In message <Pine.GSO.4.02A.9809041107001.19368-100000@matlock.informatik.rwth-aachen.de>you write:
>   > Inheritance doesn't seem to cause problems with my patch; I've never touched
>   > it and did not run into bugs.
> Well, when dealing with reload "it seems to work for me" isn't enough :-)
> 
> The primary issue is that when a reload is inherited its lifetime is
> extended, possibly beyond the original insn where it was used as a
> reload reg.
> 
> So, when we inherit reloads, we have to make sure to note that the
> reloadreg is marked as live for the longer range.
> 
> Then again inheritance happens just before we start emitting the
> reload insns themselves, so maybe it doesn't conflict with your code.

It really shouldn't. Inheritance only looks at the insns that reload is
already done with, and the one currently being processed.  For those
which reload has completed, the register life information calculated by
my patch is never referenced again, so the inheritance code can do
whatever it wants to them.

> We actually have most of the stuff to implement this now.  We just need
> to set the alias set for such MEMs so that they have a different set
> than all the MEMs created before reload.

We'd need to be a bit careful about this, since some of these MEMs might be
replaced (for example) in instruction splitting later on, and the special
"this MEM made by reload" alias set must be preserved during such operations.

Bernd



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