The following routines implement the SSA copy renaming phase.
This optimization looks for copies between 2 SSA_NAMES, either through a
direct copy, or an implicit one via a PHI node result and its arguments.
Each copy is examined to determine if it is possible to rename the base
variable of one of the operands to the same variable as the other operand.
i.e.
T.3_5 = <blah>
a_1 = T.3_5
If this copy couldn't be copy propagated, it could possibly remain in the
program throughout the optimization phases. After SSA->normal, it would
become:
T.3 = <blah>
a = T.3
Since T.3_5 is distinct from all other SSA versions of T.3, there is no
fundamental reason why the base variable needs to be T.3, subject to
certain restrictions. This optimization attempts to determine if we can
change the base variable on copies like this, and result in code such as:
a_5 = <blah>
a_1 = a_5
This gives the SSA->normal pass a shot at coalescing a_1 and a_5. If it is
possible, the copy goes away completely. If it isn't possible, a new temp
will be created for a_5, and you will end up with the exact same code:
a.8 = <blah>
a = a.8
The other benefit of performing this optimization relates to what variables
are chosen in copies. Gimplification of the program uses temporaries for
a lot of things. expressions like
a_1 = <blah>
<blah2> = a_1
get turned into
T.3_5 = <blah>
a_1 = T.3_5
<blah2> = a_1
Copy propagation is done in a forward direction, and if we can propagate
through the copy, we end up with:
T.3_5 = <blah>
<blah2> = T.3_5
The copy is gone, but so is all reference to the user variable 'a'. By
performing this optimization, we would see the sequence:
a_5 = <blah>
a_1 = a_5
<blah2> = a_1
which copy propagation would then turn into:
a_5 = <blah>
<blah2> = a_5
and so we still retain the user variable whenever possible.
Coalesce the partitions in MAP representing VAR1 and VAR2 if it is valid.
Choose a representative for the partition, and send debug info to DEBUG.
Don't coalesce if one of the variables occurs in an abnormal PHI.
Partitions already have the same root, simply merge them.
Never attempt to coalesce 2 different parameters.
Refrain from coalescing user variables, if requested.
If both values have default defs, we can't coalesce. If only one has a
tag, make sure that variable is the new root partition.
Do not coalesce if we cannot assign a symbol to the partition.
Don't coalesce if the new chosen root variable would be read-only.
If both ign1 && ign2, then the root var of the larger partition
wins, so reject in that case if any of the root vars is TREE_READONLY.
Otherwise reject only if the root var, on which replace_ssa_name_symbol
will be called below, is readonly.
Don't coalesce if the two variables aren't type compatible .
There is a disconnect between the middle-end type-system and
VRP, avoid coalescing enum types with different bounds.
Merge the two partitions.
Set the root variable of the partition to the better choice, if there is
one.