On 20/04/15 19:02, Jeff Law wrote:
On 04/20/2015 02:25 AM, Kyrill Tkachov wrote:
Hi Jeff,
Hmmm, so what happens if the difference is < 0? I'd be a bit worried
about that case for the PA (for example).
So how about asserting that the INTVAL is >= 0 prior to returning so
that we catch that case if it ever occurs?
INTVAL being >= 0 is the case that I want to catch with this function.
INTVAL <0 is the usual case on leaf call optimisation. On arm, at least,
it means that x and y use the same base register (i.e. same stack frame)
but the offsets are such that reading SIZE bytes from X will not overlap
with Y, thus not requiring the workaround in this patch.
Thus, asserting that the result is positive is not right here.
What characteristic on pa makes this problematic? Is it the
STACK_GROWS_UPWARD?
Yea or more correctly that {STACK,FRAME}_GROWS_UPWARD and
ARGS_GROW_DOWNWARD. I think the stormy16 may have downward growing args
too.
Should I then extend this function to do something like:
HOST_WIDE_INT res = INTVAL (sub);
#ifndef STACK_GROWS_DOWNWARD
res = -res;
#endif
return res?
It certainly feels like something is needed for targets where growth is
in the opposite direction -- but my guess is that without a concrete
case that triggers on those targets (just the PA in 64 bit mode and
stormy?) we'll probably get it wrong in one way or another. Hence my
suggestion that we assert rather than try to handle it and silently
generate incorrect code in the process.
However, this function is expected to return negative numbers
when there is no overlap i.e. in the vast majority of cases when this
bug doesn't manifest. So asserting that it's positive is just
going to ICE at -O2 in almost any code.
From reading config/stormy16/stormy-abi it seems to me that we don't
pass arguments partially in stormy16, so this code would never be called
there. That leaves pa as the potential problematic target.
I don't suppose there's an easy way to test on pa? My checkout of binutils
doesn't seem to include a sim target for it.
Kyrill
Jeff
