On 15/09/15 22:47, Richard Biener wrote:
On Tue, Sep 8, 2015 at 11:50 PM, Jim Wilson <jim.wil...@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
