If we know that zero constant operand is already in the right place we do not need
to re-order anything.
Details
Diff Detail
Event Timeline
llvm/test/CodeGen/X86/fminimum-fmaximum.ll | ||
---|---|---|
1141 | 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). |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
30300 | nit: can you use a different variable name than PreferredZero as the value in the lambda doesn't always match whats in the outerscope. |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
30300 | Agreed. Thanks, Will use just Zero. | |
llvm/test/CodeGen/X86/fminimum-fmaximum.ll | ||
1141 | I will modify test to use constant 0.f and -0.f to cover both not a preferred zero and not an opposite zero. |
llvm/test/CodeGen/X86/fminimum-fmaximum.ll | ||
---|---|---|
1141 | 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>. |
llvm/test/CodeGen/X86/fminimum-fmaximum.ll | ||
---|---|---|
1141 | Got it. So you actually want another improvement. For vector we actually need preferred/opposite zero or not zero actually. So I need one more test case and improvement in the code. |
Great! Thanks. LGTM.
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
30300 | It seems a little bit confusing for me that we generally do different things for vectors and scalars. Consider inputs 5. and <5., 5.>: for the first we return false, for the second -- true. But I can't think of better naming explaining this behavior difference, or splitting into different lambdas. In fact, there is no much difference whether we return true or false because non zero cases are covered by isKnownNeverZeroFloat calls. |
nit: can you use a different variable name than PreferredZero as the value in the lambda doesn't always match whats in the outerscope.