https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125903
Bug ID: 125903
Summary: Failure to const/copy propagate after shrink-wrapping
or prologue/epilogue generation
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
Based on the very light debugging I've done, I suspect this is a target issue
or perhaps a minor issue in cleaning up after shrink-wrapping.
Consider this code:
void foo (unsigned *, unsigned *, unsigned);
unsigned *baz (unsigned) __attribute__ ((const));
struct COST
{
unsigned *cost;
unsigned maxWeakConstraintLevel;
};
unsigned * bar(struct COST *c)
{
unsigned *valp;
if(c->maxWeakConstraintLevel == 0)
valp =0;
else
{
valp = baz (4 * 33);
foo (valp, c->cost, c->maxWeakConstraintLevel * sizeof(unsigned));
}
return valp;
}
When compiled with -march=rv64gcbv_zicond -O2 we get this interesting fragment
at the end of the function:
li a5,0 # 4 [c=4 l=4] *movdi_64bit/1
mv a0,a5 # 69 [c=4 l=4] *movdi_64bit/0
ret # 75 [c=0 l=4] simple_return
We should have used a0 as the destination of insn 4. That would have made insn
69 a nop-move and it should be eliminated.
Prior to prologue/epilogue generation things look sensible. It's only after
prologue/epilogue generation that the constant is exposed.