This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/60043] -fschedule-insns2 breaks anti-dependency
- From: "abel at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 04 Feb 2014 06:59:06 +0000
- Subject: [Bug rtl-optimization/60043] -fschedule-insns2 breaks anti-dependency
- Auto-submitted: auto-generated
- References: <bug-60043-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60043
Andrey Belevantsev <abel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |abel at gcc dot gnu.org
--- Comment #1 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
I don't follow the reasoning of this example and the original ML thread. The
load of *b follows the store to *a, thus the scheduler is checking for the
presence of the _true_ dependence between them:
gcc/sched-deps.c:
2660 if (true_dependence (XEXP (pending_mem, 0), VOIDmode, t)
2661 && ! sched_insns_conditions_mutex_p (insn,
2662 XEXP (pending,
0)))
2663 note_mem_dep (t, XEXP (pending_mem, 0), XEXP (pending,
0),
2664 sched_deps_info->generate_spec_deps
2665 ? BEGIN_DATA | DEP_TRUE : DEP_TRUE);
which does not exist because the mems have different alias sets. But you have
agreed that TBAA can be used for true dependences in the ML thread, no? What
is then required from the scheduler?