This is the mail archive of the gcc-patches@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: [RFA][PATCH][middle-end/53623] Improve extension elimination


On 12/20/13 09:45, Jakub Jelinek wrote:
On Fri, Dec 20, 2013 at 09:26:10AM -0700, Jeff Law wrote:
Thanks for working on this, the only thing I'd worry about are
HARD_REGNO_NREGS > 1 registers if the two hard regs might overlap.
The reg_set_between_p and reg_used_between_p calls when you dig down
into them eventually use reg_overlap_mentioned_p which should do the
right thing in this regard.

I'll audit ree for problems of this nature.

The two reg_*_between_p functions check only insns in between the two, but
not the insns themselves.  What I meant is if it e.g. couldn't be possible
to have HARD_REGNO_NREGS == 2 registers say 1 and 2, where the first insn
would load into the low half of 1, then one insn that say sign extends
1 into {2,3}, then perhaps {2,3} is used and finally 1 is zero extended
into {1,2} and that is used later on.  For little endian this would work,
while after the transformation which sign extends the memory into {2,3}
and then copies that into {1,2} (thus overwriting content of low half of
{2,3} with the high half of it).  Perhaps the RA will never allow this.
ISTM if we're presented with something like that (and I don't think there's anything in RA which explicitly disallows such code), then what we have to evaluate is whether or not the transformation preserves the semantics.

So, incoming would look like this (assuming a 32 bit target):


r1:SI = mem:SI
r2:DI = sext:DI (r1:SI)
[ Use r2/r3 ]
r1:DI = zext:DI (r1:SI)

And that would be transformed into:

r2:DI = sext:DI (mem:SI)
r1:DI = r2:DI
[ Use r2/r3 ]
r1:DI = zext:DI (r1:SI)

Where r2 will have the wrong value in the use statements. ISTM we can check for an overlap between the destination of the memory load and the destination of the first extension. Right?

Is that the case you're worrying about?

jeff


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