Re: [PATCH][expr.c] PR 65358 Avoid clobbering partial argument during sibcall

[Kyrill Tkachov <kyrylo.tkachov@arm.com>]

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
>