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
I'm not clear on the connection between safelen and lexical dependences. Aren't these separable features? safelen is an upper bound on the safe vectorization width. Lexical dependences are about what load/store/call reorderings are safe. - Arch -----Original Message----- From: Humphreys, Jonathan [mailto:j-humphreys at ti.com] Sent: Monday, September 29, 2014 3:17 PM To: Tian, Xinmin; Renato Golin; Hal Finkel Cc: Robison, Arch; LLVM Dev Subject: RE: [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
Humphreys, Jonathan
2014-Sep-29 21:09 UTC
[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"
There is a connection. Safelen(k) is saying that lexically backward dependences are allowed, as long as they are greater than k in distance. -----Original Message----- From: Robison, Arch [mailto:arch.robison at intel.com] Sent: Monday, September 29, 2014 3:35 PM To: Humphreys, Jonathan; Tian, Xinmin; Renato Golin; Hal Finkel Cc: LLVM Dev Subject: RE: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" I'm not clear on the connection between safelen and lexical dependences. Aren't these separable features? safelen is an upper bound on the safe vectorization width. Lexical dependences are about what load/store/call reorderings are safe. - Arch -----Original Message----- From: Humphreys, Jonathan [mailto:j-humphreys at ti.com] Sent: Monday, September 29, 2014 3:17 PM To: Tian, Xinmin; Renato Golin; Hal Finkel Cc: Robison, Arch; LLVM Dev Subject: RE: [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