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