<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 15, 2018 at 8:54 AM, Connor Abbott <span dir="ltr"><<a href="mailto:cwabbott0@gmail.com" target="_blank">cwabbott0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Feb 14, 2018 at 11:53 PM, Timothy Arceri <<a href="mailto:tarceri@itsqueeze.com">tarceri@itsqueeze.com</a>> wrote:<br>
><br>
><br>
> On 15/02/18 04:39, Marek Olšák wrote:<br>
>><br>
>> Reviewed-by: Marek Olšák <<a href="mailto:marek.olsak@amd.com">marek.olsak@amd.com</a>><br>
>><br>
>> Marek<br>
>><br>
>> On Wed, Feb 14, 2018 at 7:29 AM, Timothy Arceri <<a href="mailto:tarceri@itsqueeze.com">tarceri@itsqueeze.com</a>><br>
>> wrote:<br>
>>><br>
>>> Fixes glsl-1.30/execution/isinf-and-<wbr>isnan* piglit tests for<br>
>>> radeonsi and should fix SPIRV errors when LLVM optimises away<br>
>>> the workarounds in vtn_handle_alu() for handling ordered<br>
>>> comparisons.<br>
>>><br>
>>> Bugzilla: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=104905" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/<wbr>show_bug.cgi?id=104905</a><br>
>>> ---<br>
>>>   src/amd/common/ac_nir_to_llvm.<wbr>c | 8 ++++----<br>
>>>   1 file changed, 4 insertions(+), 4 deletions(-)<br>
>>><br>
>>> diff --git a/src/amd/common/ac_nir_to_<wbr>llvm.c<br>
>>> b/src/amd/common/ac_nir_to_<wbr>llvm.c<br>
>>> index a0c5680205..e81f86bb08 100644<br>
>>> --- a/src/amd/common/ac_nir_to_<wbr>llvm.c<br>
>>> +++ b/src/amd/common/ac_nir_to_<wbr>llvm.c<br>
>>> @@ -1792,16 +1792,16 @@ static void visit_alu(struct ac_nir_context *ctx,<br>
>>> const nir_alu_instr *instr)<br>
>>>                  result = emit_int_cmp(&ctx->ac, LLVMIntUGE, src[0],<br>
>>> src[1]);<br>
>>>                  break;<br>
>>>          case nir_op_feq:<br>
>>> -               result = emit_float_cmp(&ctx->ac, LLVMRealUEQ, src[0],<br>
>>> src[1]);<br>
>>> +               result = emit_float_cmp(&ctx->ac, LLVMRealOEQ, src[0],<br>
>>> src[1]);<br>
>>>                  break;<br>
>>>          case nir_op_fne:<br>
>>> -               result = emit_float_cmp(&ctx->ac, LLVMRealUNE, src[0],<br>
>>> src[1]);<br>
>>> +               result = emit_float_cmp(&ctx->ac, LLVMRealONE, src[0],<br>
>>> src[1]);<br>
><br>
><br>
> It seems we need to leave this one as is to avoid regressions. This is also<br>
> what radeonsi does.<br>
<br>
</div></div>So, the thing you have to understand is that in LLVM unordered<br>
comparisons are precisely the inverse of the ordered comparisons. That<br>
is, (a <=(ordered) b) == !(a >(unordered b), (a ==(ordered) b) == !(a<br>
!=(unordered) b), and  so on. C defines that all comparsions are<br>
ordered except !=, so that (a == b) == !(a != b) always holds true.<br>
Most hardware follows this convention -- offhand, x86 SSE is the only<br>
ISA I know of with separate ordered and unordered comparisons, and<br>
LLVM appears to have copied the distinction from them, but no one else<br>
has both. I'm not even sure if it's in the IEEE spec. GLSL follows the<br>
C convention, so glsl_to_nir just uses nir_op_fne to mean unordered<br>
not-equal. spirv_to_nir generates some extra instructions, which then<br>
get stripped away later... sigh.<br>
<br>
I think the right way to untangle this mess is to define that the NIR<br>
opcodes should always match the C convention. The separate ordered and<br>
unordered opcodes are unnecesary, since one is just the logical<br>
negation of the other, and LLVM was a little overzealous -- I'm sure<br>
they would get rid of the distinction if they had the chance -- and<br>
then they were blindly copied to SPIR-V. spirv_to_nir should just<br>
negate the result if necessary rather than emitting the extra code to<br>
handle NaN, and ac should use ordered except for not-equals.<br></blockquote><div><br></div><div>I think we should also use ordered for not-equal. Otherwise we have no way to contruct an unordered equal  or ordered not-equal using the not-trick. I think that would be more important than trying to keep it in sync with C? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
>>>                  break;<br>
>>>          case nir_op_flt:<br>
>>> -               result = emit_float_cmp(&ctx->ac, LLVMRealULT, src[0],<br>
>>> src[1]);<br>
>>> +               result = emit_float_cmp(&ctx->ac, LLVMRealOLT, src[0],<br>
>>> src[1]);<br>
>>>                  break;<br>
>>>          case nir_op_fge:<br>
>>> -               result = emit_float_cmp(&ctx->ac, LLVMRealUGE, src[0],<br>
>>> src[1]);<br>
>>> +               result = emit_float_cmp(&ctx->ac, LLVMRealOGE, src[0],<br>
>>> src[1]);<br>
>>>                  break;<br>
>>>          case nir_op_ufeq:<br>
>>>                  result = emit_float_cmp(&ctx->ac, LLVMRealUEQ, src[0],<br>
>>> src[1]);<br>
>>> --<br>
>>> 2.14.3<br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> mesa-dev mailing list<br>
>>> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
>>> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
><br>
> ______________________________<wbr>_________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
______________________________<wbr>_________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div></div>