https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at gcc dot gnu.org
--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sorry, just trying to read the code for the first time.
inherit_in_ebb walks from the end to the start of the ebb, so that makes me
wonder whether latest_call_insn isn't misnamed, because it is actually the
first call in the bb after the insn being currently processed.
But there is another thing, split_reg is called both from within inherit_in_ebb
where
perhaps the first call insn in the ebb after the currently handled instruction
is meaningful, but also it can be called from spill_hard_reg_in_range which is
called
from lra_split_hard_reg_for called from lra. The last one is a function which
can also call lra_inheritance which calls inherit_in_ebb.
Now, latest_call_insn is cleared at the start of inherit_in_ebb, but isn't
cleared at the end, so I'd be afraid it could have just used some random call
somewhere during lra_split_hard_reg_for.
One possibility would be to clear that variable also at the end of
inherit_in_ebb, signalizing we are no longer in that function and so split_reg
should keep doing what it used to do before, or I think the calls from outside
inherit_in_ebb have non-NULL to argument, while the calls from within
inherit_in_ebb have NULL to.
Though, I think clearing the var at the end of inherit_in_ebb might be better,
so that we don't keep random garbage in that variable.
