On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson <jim.wil...@linaro.org> wrote: >On Tue, Jul 7, 2015 at 8:07 AM, Jeff Law <l...@redhat.com> wrote: >> On 06/29/2015 07:15 PM, Jim Wilson wrote: >> So if these "copies" require a conversion, then isn't it >fundamentally >> wrong to have a PHI node which copies between them? That would seem >to >> implicate the eipa_sra pass as needing to be aware of these >promotions and >> avoid having these objects with different representations appearing >on the >> lhs/rhs of a PHI node. > >My years at Cisco didn't give me a chance to work on the SSA passes, >so I don't know much about how they work. But looking at this, I see >that PHI nodes are eventually handed by emit_partition_copy in >tree-outof-ssa.c, which calls convert_to_mode, so it appears that >conversions between different (closely related?) types are OK in a PHI >node. The problem in this case is that we have the exact same type >for the src and dest. The only difference is that the ARM forces >sign-extension for signed sub-word parameters and zero-extension for >signed sub-word locals. Thus to detect the need for a conversion, you >have to have the decls, and we don't have them here. There is also >the problem that all of the SUBREG_PROMOTED_* stuff is in expand_expr >and friends, which aren't used by the cfglayout/tree-outof-ssa.c code >for PHI nodes. So we need to copy some of the SUBREG_PROMOTED_* >handling into cfglyout/tree-outof-ssa, or modify them to call >expand_expr for PHI nodes, and I haven't had any luck getting that to >work yet. I still need to learn more about the code to figure out if >this is possible.
It probably is. The decks for the parameter based SSA names are available, for the PHI destination there might be no decl. >I also think that the ARM handling of PROMOTE_MODE is wrong. Treating >a signed sub-word and unsigned can lead to inefficient code. This is >part of the problem is much easier for me to fix. It may be hard to >convince ARM maintainers that it should be changed though. I need >more time to work on this too. > >I haven't looked at trying to forbid the optimizer from creating PHI >nodes connecting parameters to locals. That just sounds like a >strange thing to forbid, and seems likely to result in worse code by >disabling too many optimizations. But maybe it is the right solution >if neither of the other two options work. This should only be done >when PROMOTE_MODE disagrees with TARGET_PROMOTE_FUNCTION_MODE, forcing >the copy to require a conversion. I don't think disallowing such PHI nodes is the right thing to do. I'd rather expose the TARGET_PROMOTE_FUNCTION_MODE effect earlier by modifying the parameter types during, say, gimplification. Richard. >Jim
