https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
Bill Schmidt <wschmidt at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
Component|target |tree-optimization
--- Comment #5 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
It is difficult to track down exactly what happened here because there appears
to be some inlining occurring without any dumps showing up with
-fdump-tree-all. After .046t.inline_param2, we see
<bb 56>:
_71 = llvm::MachineInstrBuilder::addFrameIndex (_69, FI_16(D));
...
<bb 60>:
_73 = _71->MI;
_209 = _71->MF;
D.381968.OpKind = 1;
D.381968.SubReg_TargetFlags = 0;
D.381968.ParentMI = 0B;
D.381968.Contents.ImmVal = 0;
llvm::MachineInstr::addOperand (_73, _209, &D.381968);
By the time we get to the next dump (.068t.fixup_cfg4) there has been some
inline expansion performed. The relevant computations are:
<bb 113>:
D.383141 ={v} {CLOBBER};
_428 = &D.324881;
_69 = _428;
_354 = _69->MI;
_355 = _69->MF;
D.383161.OpKind = 5;
D.383161.SubReg_TargetFlags = 0;
D.383161.ParentMI = 0B;
_70 = D.383161.OpKind;
if (_70 != 5)
goto <bb 114>;
else
goto <bb 118>;
...
<bb 119>:
D.383161 ={v} {CLOBBER};
_436 = _69;
_71 = _436;
D.324881 ={v} {CLOBBER};
_208 = MEM[(struct TrackingMDRef *)&D.324880].MD;
if (_208 != 0B)
goto <bb 120>;
else
goto <bb 121>;
...
<bb 122>:
_73 = _71->MI;
_209 = _71->MF;
D.381968.OpKind = 1;
D.381968.SubReg_TargetFlags = 0;
D.381968.ParentMI = 0B;
D.381968.Contents.ImmVal = 0;
llvm::MachineInstr::addOperand (_73, _209, &D.381968);
Note that D.324881 gets clobbered when _71 has just been assigned to point to
D.324881. _73 and _209 then read values from this clobbered object. That
doesn't look good.
By the time we get to .092t.cplxlower1, this appears more explicit:
<bb 84>:
D.383161 ={v} {CLOBBER};
D.324881 ={v} {CLOBBER};
_208 = MEM[(struct TrackingMDRef *)&D.324880].MD;
if (_208 != 0B)
goto <bb 85>;
else
goto <bb 86>;
...
<bb 87>:
_73 = D.324881.MI;
_209 = D.324881.MF;
D.381968.OpKind = 1;
D.381968.SubReg_TargetFlags = 0;
D.381968.ParentMI = 0B;
D.381968.Contents.ImmVal = 0;
llvm::MachineInstr::addOperand (_73, _209, &D.381968);
This leads .093t.sra to create a use-without-def situation:
struct MachineInstr * const SR.1271;
...
<bb 87>:
_73 = SR.1271_292(D);
_209 = SR.1270_58(D);
D.381968.OpKind = 1;
D.381968.SubReg_TargetFlags = 0;
D.381968.ParentMI = 0B;
D.381968.Contents.ImmVal = 0;
llvm::MachineInstr::addOperand (_73, _209, &D.381968);
...and eventually we just initialize this thing to zero since it is
upward-exposed to the prologue, leading to the bad code gen we see.
So I assume that something bad has happened during inlining (or some other
phase where the dumps are not available). I don't know how to investigate
further. CCing Honza for his input...
