[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

[Tian, Xinmin]

Arch, I would vote for #2, I think it is a better for long term solution. Teach opts to honor the fence is reasonable.

Thanks,
Xinmin   

-----Original Message-----
From: Robison, Arch 
Sent: Monday, September 29, 2014 1:57 PM
To: Tian, Xinmin; Renato Golin; Hal Finkel
Cc: Jonathan Humphreys; LLVM Dev
Subject: RE: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

Here's my take on representing the ordering information in LLVM.  There are at least two basic approaches:

1. Add metadata to each load and store that has some kind of sequence number.  Consecutive
   operations with no associated "sequenced before" relationship can have the same number.
   If a transform breaks the order, the vectorizer has to either undo the reordering or punt.

2. Add another flavor of the "fence" instruction that represents a vectorization fence.
   The front-end would insert the fence at sequence points (to use the old term).
   Transforms would not be allowed to move loads/stores/calls over these fences unless
   they can prove the movement does not convert a forward lexical dependence to backwards one.

Approach 2 avoids renumbering issues for inliners and partial unrollers.  The downside is that passes that reorder loads/stores would need to recognize the fence and the restrictions that it imposes.  The fence is somewhat similar to "fence singlethread acq_rel", but lighter in principle since loads/stores *not* participating in loop-carried dependences can be moved over it.

For Julia @simd, I had in mind making the fence instruction a user-visible feature and ditching implicit lexical sequencing altogether.

- Arch


-----Original Message-----
From: Tian, Xinmin
Sent: Monday, September 29, 2014 10:43 AM
To: Renato Golin; Hal Finkel
Cc: Jonathan Humphreys; Robison, Arch; LLVM Dev
Subject: RE: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

Renato, I think Hal meant to ensure partial ordering, e.g. not to convert lexical forward data dep to lexical backward data dep due to statement ordering if any. 
'
Xinmin 

-----Original Message-----
From: Renato Golin [mailto:renato.golin at linaro.org]
Sent: Monday, September 29, 2014 1:06 AM
To: Hal Finkel
Cc: Tian, Xinmin; Jonathan Humphreys; Robison, Arch; LLVM Dev
Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

On 28 September 2014 22:09, Hal Finkel <hfinkel at anl.gov> wrote:
> Thanks Xinmin!
>
> So we'll need a method to ensure the correct (partial) ordering.

I thought that the idea was to avoid computing loop dependencies when safelen is specified, at least at that level. We might do it to a greater length, but we should assume it to be safe for distances < VL.

We still need the method, I agree, for everything else, though.

cheers,
--renato