Re: [4/7] Use correct promoted mode sign for result of GIMPLE_CALL

[kugan <kugan.vivekanandarajah@linaro.org>]

On 15/09/15 22:47, Richard Biener wrote:
> On Tue, Sep 8, 2015 at 11:50 PM, Jim Wilson <jim.wilson@linaro.org> wrote:
>> On 09/08/2015 08:39 AM, Jeff Law wrote:
>>> Is this another instance of the PROMOTE_MODE issue that was raised by
>>> Jim Wilson a couple months ago?
>>
>> It looks like a closely related problem.  The one I am looking at has
>> confusion with a function arg and a local variable as they have
>> different sign extension promotion rules.  Kugan's is with a function
>> return value and a local variable as they have different sign extension
>> promotion rules.
>>
>> The bug report is
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
>>
>> The gcc-patches thread spans a month end boundary, so it has multiple heads
>> https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02132.html
>> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00112.html
>> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00524.html
>>
>> Function args and function return values get the same sign extension
>> treatment when promoted, this is handled by
>> TARGET_PROMOTE_FUNCTION_MODE. Local variables are treated differently,
>> via PROMOTE_MODE. I think the function arg/return treatment is wrong,
>> but changing that is an ABI change which is undesirable.  I suppose we
>> could change local variables to match function args and return values,
>> but I think that is moving in the wrong direction.  Though Kugan's new
>> optimization pass will remove some of the extra unnecessary sign/zero
>> extensions added by the arm TARGET_PROMOTE_FUNCTION_MODE definition, so
>> maybe it won't matter enough to worry about any more.
>>
>> If we can't fix this in the arm backend, then we may need different
>> middle fixes for these two cases.  I was looking at ways to fix this in
>> the tree-out-of-ssa pass.  I don't know if this will work for Kugan's
>> testcase, I'd need time to look at it.

As you said, I dont think the fix in tree-out-of-ssa pass will not fix 
this case. Kyrill also saw the same problem with the trunk as in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67714
>
> I think the function return value should have been "promoted" according to
> the ABI by the lowering pass.  Thus the call stmt return type be changed,
> exposing the "mismatch" and compensating the IL with a sign-conversion.
>

Function return value is promoted as per ABI.
In the example from PR67714
....
  _8 = fn1D.5055 ();
   e_9 = (charD.4) _8;
   f_13 = _8;
...

_8 is sign extended correctly. But in f_13 = _8, it is promoted to 
unsigned and zero extended due to the backend PROMOTE_MODE. We thus have:

The zero-extension during expand:
;; f_13 = _8;

(insn 15 14 0 (set (reg/v:SI 110 [ f ])
         (zero_extend:SI (subreg/u:QI (reg/v:SI 110 [ f ]) 0))) 
arm-zext.c:18 -1
      (nil))

This is wrong.

> As for your original issue with function arguments they should really
> get similar
> treatment, eventually in function arg gimplification already, by making
> the PARM_DECLs promoted and using a local variable for further uses
> with the "local" type.  Eventually one can use DECL_VALUE_EXPR to fixup
> the IL, not sure.  Or we can do this in the promotion pass as well.
>

I will try doing this see if I can do this.

Thanks,
Kugan

> Richard.
>
>> Jim
>>