llvm dev - Sep 2014 - [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

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

Yes, I think the 2 outcomes are:
 - the current spec is unclear and will be clarified
 - in order to support safelen() and even the simd construct itself, LLVM will
require infrastructure work to know when a lexically backwards dependence may
have been introduced.

Jon

-----Original Message-----
From: Tian, Xinmin [mailto:xinmin.tian at intel.com] 
Sent: Monday, September 29, 2014 10:43 AM
To: Renato Golin; Hal Finkel
Cc: Humphreys, Jonathan; 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

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