https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122947
Bug ID: 122947
Summary: variant of pr117239.c still fails
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
Created attachment 62964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62964&action=edit
variant of pr117239.c that triggers the problem (with a cselib improvement?)
ISTM that the fix in bug 117239 is only papering over the problem.
It puzzled me that, after the initial call, we seemingly invalidate the
arguments passed to the callee on the stack, but that any of them remain live
in the cselib table.
Here's what I've found out so far:
- each store to the stack argument invalidates other stores to it, because our
bounds checking fails when (reg SP) relates to (value), so we can only tell
they're part of the same object.
https://gcc.gnu.org/pipermail/gcc-patches/2025-November/702233.html addresses
this, enabling the entire argument to remain live before the initial call.
Without this, we depend on scheduling to reverse the order of the stores in
either call to expose the problem.
- the const/pure callee-arg invalidation depends on CALL_INSN_FUNCTION_USAGE's
having stack slots for the args, but with -mno-accumulate-outgoing-args, it
doesn't, so the stored values survive
- after the bug 117239 fix, we invalidate the outgoing args from a previous
call at subsequent calls, but only if the subsequent calls use less stack space
for arguments, and only those arguments that were stored in the no-longer-used
range
Therefore, if we immediately call another function that takes the same stack
arguments, in a -mno-accumulate-outgoing-args scenario, and a store for the
second call happens to find in the cselib the same value stored for the first
call still live (as made easier by the patch above), then we *still* hit the
optimization error with the attached testcase, compiled with -fno-inline -O2
-fschedule-insns -mno-accumulate-outgoing-args like the original pr117239.c
testcase.
Now, it might be the case that, without the patch, we just don't hit the
problem for other reasons. But it seems risky to rely on those unknown reasons
to avoid deleting argument stores like that.
