[PATCH] D150249: [X86] Improve handling on zero constant for fminimum/fmaximum lowering

Serguei Katkov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 11 20:11:22 PDT 2023


skatkov added inline comments.


================
Comment at: llvm/test/CodeGen/X86/fminimum-fmaximum.ll:1140
 ; X86-NEXT:    retl
   %r = call <2 x double> @llvm.minimum.v2f64(<2 x double> %x, <2 x double> <double 0., double 5.>)
   ret <2 x double> %r
----------------
e-kud wrote:
> skatkov wrote:
> > e-kud wrote:
> > > I think this test shows that a predicate //is not preferred zero// should be more generic than // is opposite zero// (in context of constant vectors).
> > I will modify test to use constant 0.f and -0.f to cover both not a preferred zero and not an opposite zero.
> > The intention of the test is to check that even if any of operands is zero we need all of them zero of the same sign.
> Sorry, my intentions were unclear. I mean in case of `min(%x, <0, 5>)` we need to generate a single instruction `min(<0, 5>, %x)`. But we generate all kinds of checks instead. This happens because we special case only `<0, 0, ...>` for `min`. Instead we can check something like "a constant vector consisted of not preferred zero" this will cover `<0, 0, ...>` as well as `<0, 5>`.
Got it. So you actually want another improvement. For vector we actually need preferred/opposite zero or not zero actually.
In this sense case with -0.0, 0.0 actually also makes sense.

So I need one more test case and improvement in the code.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150249/new/

https://reviews.llvm.org/D150249



More information about the llvm-commits mailing list