Yes, SVE can vectorize early exit loops by using speculative (first-faulting) loads, which essentially give a predicate of the lanes loaded successfully. For uncounted loops with these special loads, the loop predicate tests can be done using a 'ptest' instruction, checking if the last element is active. Amara On 3 February 2017 at 10:15, Simon Pilgrim <llvm-dev at redking.me.uk> wrote:> >> On 2 Feb 2017, at 01:06, Amara Emerson <amara.emerson at gmail.com> wrote: >>> >>> What stops us from doing so with intrinsics is just the knowledge, so >>> we trade complexity in the back-end to match long patterns for >>> complexity in optimisation passes to know about the new intrinsics. >>> >>> The arguments were: >>> >>> Pro intrinsic: >>> * Simpler and shorter IR >>> * Easier to read, easier for the vectorisers to generate >>> * Easier for the back-end to match >>> * Easier transition towards scalable vectors in the future >> Also want to re-iterate that reductions are useful for testing bits of >> predicate vectors, which can be applicable to other targets than SVE >> for things like early-exit vectorization. Simon mentioned this to me >> off-list. Simon, could you comment here if this proposal would work >> for your needs? > > Yes - I’m hoping that we can both vectorise early-out ‘any_of’ predicate tests code and perform early-out breaks from already vectorised cases - nothing I’ve seen suggests this will get in the way. It’s mainly going to be a case of correct recognition in the LV, handling dereference’d arrays etc. and I don’t think these intrinsics will obfuscate these cases/attributes etc. > > Does SVE have an early-out ability or is it an all or nothing mechanism? > > Simon.
Ping. Does anyone else have thoughts on this? Amara On 3 February 2017 at 11:25, Amara Emerson <amara.emerson at gmail.com> wrote:> Yes, SVE can vectorize early exit loops by using speculative > (first-faulting) loads, which essentially give a predicate of the > lanes loaded successfully. For uncounted loops with these special > loads, the loop predicate tests can be done using a 'ptest' > instruction, checking if the last element is active. > > Amara > > On 3 February 2017 at 10:15, Simon Pilgrim <llvm-dev at redking.me.uk> wrote: >> >>> On 2 Feb 2017, at 01:06, Amara Emerson <amara.emerson at gmail.com> wrote: >>>> >>>> What stops us from doing so with intrinsics is just the knowledge, so >>>> we trade complexity in the back-end to match long patterns for >>>> complexity in optimisation passes to know about the new intrinsics. >>>> >>>> The arguments were: >>>> >>>> Pro intrinsic: >>>> * Simpler and shorter IR >>>> * Easier to read, easier for the vectorisers to generate >>>> * Easier for the back-end to match >>>> * Easier transition towards scalable vectors in the future >>> Also want to re-iterate that reductions are useful for testing bits of >>> predicate vectors, which can be applicable to other targets than SVE >>> for things like early-exit vectorization. Simon mentioned this to me >>> off-list. Simon, could you comment here if this proposal would work >>> for your needs? >> >> Yes - I’m hoping that we can both vectorise early-out ‘any_of’ predicate tests code and perform early-out breaks from already vectorised cases - nothing I’ve seen suggests this will get in the way. It’s mainly going to be a case of correct recognition in the LV, handling dereference’d arrays etc. and I don’t think these intrinsics will obfuscate these cases/attributes etc. >> >> Does SVE have an early-out ability or is it an all or nothing mechanism? >> >> Simon.
On 9 February 2017 at 17:31, Amara Emerson <amara.emerson at gmail.com> wrote:> Ping. Does anyone else have thoughts on this?Hi Amara, It seems the people who replied in this thread are mostly in sync with the proposal, why don't you push a review in phab, and let's take this to the next level? cheers, --renato