This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Don't schedule prefetch INSNs


Richard Guenther wrote:
On Tue, May 19, 2009 at 5:21 PM, Andreas Krebbel
<krebbel@linux.vnet.ibm.com> wrote:
Hi,

I'm experimenting with prefetching instructions in the S/390 back-end
and found it rather annoying that the instruction scheduler shuffles
them around.  Is that intended behaviour?  When emitting a prefetch
instruction I usually want it to reside exactly where I emitted it and
especially don't want memory accesses to be moved over it.  The
attached patch fixes it for me.  Does that make sense?

Isn't that a big hammer as it will also prevent unrelated accesses from
being scheduled?

Restricting scheduling of prefetches relative to memory accesses may be a good idea, however making them a scheduling barrier, especially a TRUE_BARRIER, is a very big hummer.


As far as I understand, you don't really need to restrict scheduling for non-memory instructions in presence of a prefetch, as long as there is something to occupy CPU between the prefetch and memory access, everything should be fine for your testcase.

How about the following? Let me know if the below doesn't make much sense, there may be better alternatives.

Dependencies between instructions that access memory are created, in general, upon calling {true, anti, output, read}_dependence. These functions are passed two memory locations and they return 'true' if the locations are aliased and, hence, a dependence between corresponding instructions should be created.

You can make local wrappers for these functions that would additionally return 'true' (i.e., a dependence should be created) for prefetch instructions. As I understand, you only need to create wrappers for output_dependence (when memory write follows a write prefetch) and read_dependence (when memory read follows a read prefetch) -- this assumes, of cause, that prefetches are categorized into write and read kinds and that sched-deps.c honors that distinction (i.e., places corresponding MEMs into pending_read_mems and pending_write_mems.

Further, to ensure automaton collaboration, you want to create REG_DEP_TRUE dependencies instead of REG_DEP_ANTI dependencies for read prefetches and REG_DEP_OUTPUT dependencies for write prefetches -- this is due to
1. instruction latencies are only used for true dependencies and
2. <prefetch, memory access> pair does have a logical true dependence.


If using the wrappers for {output, read}_dependence(), then you can simply make the wrapper return the appropriate dependence type.

--
Maxim
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]