[llvm-dev] RFC: Generic IR reductions

[Amara Emerson via llvm-dev]

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.