On 07/07/2015 10:29 AM, Jim Wilson wrote:
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.
It'd be real interesting to see if that call ever does any real
conversions -- ie, is it ever called with types that are not useless
type conversions (useless_type_conversion_p has essentially become the
definition of the gimple type system, for better or worse).
This is critically important as various parts of the compiler will take
a degenerate PHI node and propagate the RHS of the PHI into the uses of
the LHS of the PHI -- without doing any conversions.
So if you had something like
X = PHI (Y);
Where X is a sub-word local and Y is a sub-word parameter, the
propagators will blindly replace uses of X with Y, which may be wrong if
I understand your next paragraph correctly.
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.
And this would seem to imply that those objects can't be set/referenced
in the same PHI because of the zero vs sign extension issue.
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.
It's less about connecting parameters to locals and more about ensuring
that objects connected are close enough in their types that one could be
substituted for the other.
jeff
