[llvm-dev] Vectorizing minimum without function attributes
Sanjay Patel via llvm-dev
llvm-dev at lists.llvm.org
Mon May 6 06:31:19 PDT 2019
We have several problems with FP min/max optimization, so it would help to
see an IR example. But I agree that we should not require a function
attribute to enable the optimization.
This might be the closest match based on the description:
On Sat, May 4, 2019 at 3:51 PM Nicolau Werneck via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Thanks for the reply. I should say I'm actually working on 6.0, but I
> don't think this part of the code changed much since. These are traces I
> made with GDB optimizing a loop with floats and then integers, showing
> where they diverge:
> This is the point I believe we need to set the function attribute for the
> vectorization to work with floats:
> Could this be a bug? It seems to me it just wasn't changed yet to depend
> only on instruction flags.
> I would gladly work on refactoring this if there's an opportunity, but I'm
> a complete newbie in this project. It would be great to hear from someone
> more knowledgeable what can be done about this issue, especially if turns
> out to be a very small patch!
> On Sat, May 4, 2019 at 3:41 PM Finkel, Hal J. <hfinkel at anl.gov> wrote:
>> On 5/4/19 6:36 AM, llvm-dev wrote:
>> The LLVM loop vectorizer does a great job handling reductions with the
>> `min(a, b)` function over an array of integers or floats. This finds the
>> smallest value of a list exploiting SIMD instructions, and works just as
>> well as a summation.
>> Specifically with floats, though, using the `fcmp` instruction, the
>> vectorization seems to require the function attribute "no-nans-fp-math" to
>> be set. Just setting instruction flags is not enough.
>> fcmp takes fast-math flags now, but that wasn't always true (my
>> recollection is that was a capability added after the arithmetic
>> operations). In any case, I wonder if this is just a hold-over from before
>> fcmp took fast-math flags, or if this is an && condition that should be an
>> || condition.
>> This forces us to give up on fine-grained control of fast-math in the
>> code in order to benefit from this vectorization.
>> How to overcome this? LLVM has intrinsic functions such as `minnum` and
>> `minimum` (`minnan`) that accurately represent the operation. This could
>> permit fine-grained control of fast-math flags, although the vectorizer
>> seems to ignore these intrinsics.
>> Beyond this specific case, it would be nice to be sure when is it ever
>> necessary to set these function attributes, e.g.
>> What would be a way to control the vectorization for `min` without having
>> to rely on that function attribute? And furthermore, could LLVM
>> optimizations conceivably depend only on instruction flags, and not ever on
>> function attributes? What would be necessary to achieve this?
>> The goal has been to eliminate the dependence on the function attributes
>> once all of the necessary local flags are in place. Obviously I could be
>> missing something, but this just seems like a bug.
>> Nicolau Werneck <nwerneck at gmail.com>
>> http://n <http://nwerneck.sdf.org>ic.hpavc.net
>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> Nicolau Werneck <nwerneck at gmail.com>
> http://n <http://nwerneck.sdf.org>ic.hpavc.net
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev