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.
Jeff
