[llvm] r177599 - Model prefetches and barriers as loads.

Andrew Trick atrick at apple.com
Thu Mar 21 11:25:28 PDT 2013


On Mar 21, 2013, at 10:44 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> 
> On Mar 20, 2013, at 4:20 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
>> ----- Original Message -----
>>> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk>
>>> To: llvm-commits at cs.uiuc.edu
>>> Sent: Wednesday, March 20, 2013 6:09:53 PM
>>> Subject: [llvm] r177599 - Model prefetches and barriers as loads.
>>> 
>>> Author: stoklund
>>> Date: Wed Mar 20 18:09:53 2013
>>> New Revision: 177599
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=177599&view=rev
>>> Log:
>>> Model prefetches and barriers as loads.
>>> 
>>> It's not yet clear if these instructions need a more careful model.
>> 
>> In my experience, modeling prefetches as reading and writing to their argument's address works pretty well (in that it keeps the prefetches ahead of the loads they're supposed to be prefetching, and keeps them after the last real write). One issue that we currently have is that the MMO attached to the prefetch thinks that the relevant address range only has size 1 (because the prefetch intrinsic takes an i8*), but it should really have the size of the (L1) cache line.
> 
> That sounds like a reasonable approach for the scheduler when determining memory dependencies.
> 
> In the SchedModel annotations, I'm more concerned with the execution engine resources consumed by the prefetch instructions. The 'WriteLoad' annotation simply represents a micro-op issued to the load-store unit.

Right. The processor's machine model won't affect aliasing at all. Whether it actually reads or writes memory is a property of the instruction. It could work for the DAG builder to consider prefetches writes for the purpose of memory dependence. I'm not sure if it already does that, but it definitely won't consult the machine model to find out.

-Andy



More information about the llvm-commits mailing list