https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52082
Drea Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Keywords|ra |
--- Comment #4 from Drea Pinski <pinskia at gcc dot gnu.org> ---
```
if (z_37(D) != 0)
goto <bb 8>; [50.00%]
else
goto <bb 9>; [50.00%]
<bb 8> [local count: 5427362]:
v4.2_12 = v4;
goto <bb 13>; [100.00%]
<bb 9> [local count: 5427362]:
v3.3_16 = v3;
goto <bb 13>; [100.00%]
<bb 13> [local count: 10854725]:
# _109 = PHI <v3.3_16(9), v4.2_12(8)>
```
factor_out_conditional_load can handle this case.
Currently we have:
/* We can't factor out a non-ssa named based load
as it might cause a variable not taken an
address to become needing the address taken.
An example is in go.
Were we produce:
_24 = PHI <&crypto/tls.cipherSuitesPreferenceOrder(36),
&crypto/tls.cipherSuitesPreferenceOrderNoAES(37)>
And &crypto/tls.cipherSuitesPreferenceOrder address bit was not set.
FIXME: Refine to check ADDRESSABLE bit. */
if (TREE_CODE (p0) != SSA_NAME || TREE_CODE (p1) != SSA_NAME)
return false;
>From https://gcc.gnu.org/pipermail/gcc-patches/2026-June/720278.html :
```
We should definitely avoid making auto_var_in_fn_p variables
address-taken when they were not already. There might be an
argument that we should not for not address-taken local
binding vars either (those which can have !may_be_aliased).
Testing !may_be_aliased could be one way to check, but consider
that phiprop (the reverse transformation) is also done to get
all address-takens go away, so a greedy local check might fight
against this, esp. when done too early in the optimization pipeline.
```
