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
Humphreys, Jonathan
2014-Sep-29 20:16 UTC
[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"
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