This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [4/7] Use correct promoted mode sign for result of GIMPLE_CALL
- From: Jim Wilson <jim dot wilson at linaro dot org>
- To: Jeff Law <law at redhat dot com>, Kugan <kugan dot vivekanandarajah at linaro dot org>, Michael Matz <matz at suse dot de>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Tue, 8 Sep 2015 14:50:47 -0700
- Subject: Re: [4/7] Use correct promoted mode sign for result of GIMPLE_CALL
- Authentication-results: sourceware.org; auth=none
- References: <55ECFC2A dot 7050908 at linaro dot org> <55ECFDB6 dot 8010100 at linaro dot org> <alpine dot LSU dot 2 dot 20 dot 1509071506440 dot 30229 at wotan dot suse dot de> <55EE012C dot 2040107 at linaro dot org> <55EF0148 dot 2040805 at redhat dot com>
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.
Jim