https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #11 from pietro <pietro.gcc at sociotechnical dot xyz> --- (In reply to Oleg Endo from comment #9) > (In reply to Andrew Pinski from comment #8) > > See > > https://gcc.gnu.org/legacy-ml/gcc-patches/2009-05/msg01233.html > > and > > https://gcc.gnu.org/legacy-ml/gcc-patches/2009-09/msg00130.html > > Nice find! Thanks Andrew. > Yeah, same problem, but different solution. I think the patch in > attachment 59210 [details] is better, as in more robust, though. It places > the barrier much earlier. sched2 runs quite late and there are many places > where a prefetch hypothetically might get reordered before sched2. IMO. Using "PREFETCH_SCHEDULE_BARRIER_P (prefetch) = true;" works for your test case on sh4-elf. The only difference from the code produced by the patch in attachment 59210 is that PREFETCH_SCHEDULE_BARRIER_P keeps the "mov #0,r0" for the return value after the "pref @r1". For reference this is how I used PREFETCH_SCHEDULE_BARRIER_P: diff --git a/gcc/builtins.cc b/gcc/builtins.cc index 37c7c98e5c..132ebc6ef3 100644 --- a/gcc/builtins.cc +++ b/gcc/builtins.cc @@ -1328,8 +1328,14 @@ expand_builtin_prefetch (tree exp) create_address_operand (&ops[0], op0); create_integer_operand (&ops[1], INTVAL (op1)); create_integer_operand (&ops[2], INTVAL (op2)); - if (maybe_expand_insn (targetm.code_for_prefetch, 3, ops)) - return; + rtx_insn *prefetch = maybe_gen_insn (targetm.code_for_prefetch, 3, ops); + if (prefetch) + { + /* Prevent the prefetch from being reordered by scheduling. */ + PREFETCH_SCHEDULE_BARRIER_P (prefetch) = true; + emit_insn (prefetch); + return; + } } /* Don't do anything with direct references to volatile memory, but
