https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94006
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
>
> Reduced testcase:
> struct f
> {
> int t;
> };
>
> static const struct f g0 = {0};
> static const struct f g1 = {-1};
>
> struct f f1(int a, int b)
> {
> return a == b ? g0 : g1;
> }
>
> ---- CUT -----
>
> NOTE the C front-end has it done correctly.
Guess it fully-folds this. We're going through phiprop and then indeed
SRA doesn't scalarize things, obviously because it cannot scalarize globals.
Rejected (2365): not aggregate: a
Rejected (2366): not aggregate: b
Candidate (2370): D.2370
! Disqualifying D.2370 - No scalar replacements to be created.
f1 (int a, int b)
{
struct f D.2370;
<bb 2> [local count: 1073741824]:
if (a_2(D) == b_3(D))
goto <bb 3>; [34.00%]
else
goto <bb 4>; [66.00%]
<bb 3> [local count: 365072224]:
D.2370 = g0;
goto <bb 5>; [100.00%]
<bb 4> [local count: 708669601]:
D.2370 = g1;
<bb 5> [local count: 1073741824]:
return D.2370;
}
There's nothing that would replace the "aggregate copy" with load/store
pairs here. I guess we could have update-address-taken do "scalar replacement"
of "aggregates" that have an integer mode, but then here we have the return
stmt which wouldn't be happy with a SSA register argument... (maybe we
need to allow VIEW_CONVERT <aggregate-type> (SSA reg) there?).
For GIMPLE this is a representational issue for aggregates we'll expand
as registers (based on TYPE/DECL_MODE) and again not exposing ABI details
at return/arguments which should really drive as to whether to represent
arguments/return values as registers or memory.
