[llvm-dev] RFC: Generic IR reductions
Amara Emerson via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 9 09:31:45 PST 2017
Ping. Does anyone else have thoughts on this?
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.
> 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?
More information about the llvm-dev