http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56885
Andrey Belevantsev <abel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |abel at gcc dot gnu.org
--- Comment #9 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
Trunk does not ICE for me anymore, though the two insns Yuri mentioned are
still reordered. I will explain what happens in more detail.
The selective scheduler supports register renaming. So on seeing an
anti-dependence in this case for di=r69 it assumes that the RHS of this insn
can be moved up with the new register, e.g. r?? = r69 and later di = r??. When
the new register is being chosen, there is nothing in the function that
prevents using the original register, di -- no liveness or hardware imposed
restrictions are reported by the backend so we allow to move the insn with the
original register. The reason for this is that the dependence comes from the
implicit_set on the another insn (insn 30 in Yuri's dump), and implicit sets do
not get reflected in the dataflow information (which we get from DF_LIVE_IN
sets and df_simulate_one_insn_backwards interfaces).
Now, if the extra dependencies really come from the evaluation_hook interface
of the x86 backend, I'd note that the hook, originally implemented for ia64
only, was not intended for adding any new dependencies, but rather for
reflecting the dependencies added in the backend for its own purposes. E.g.
for ia64 the interface allows to get the complete dependence picture before
making decisions on bundling. So I'd claim that any dependencies created for
the scheduler should also be calculated via the general deps_analyze_insn
mechanism of sched-deps.c, with the correctly prepared deps context. E.g. any
changes done with implicit_sets/clobbers/uses and IRA/LRA interfaces are also
visible within the selective scheduling. The selective scheduling analyzes
dependencies between separate insns, not blocks, so the evaluation_hook
interface does not make sense for it.
To summarize, if the backend wants to stop reordering insns in question and
also forbid renaming, then this should be exposed from within a hook called
from sched-deps.c when calculating dependencies through deps_analyze_insn, not
later, and then we can judge whether the new dependence comes from
LHS/RHS/whole insn and make appropriate changes for renaming. The current
interface does not tell us that renaming is prohibited and we cannot derive it
from the IR. The best way would be to properly reflect all restrictions in the
IR and not end up lying to the dataflow machinery and the scheduler.
