Page MenuHomePhabricator

nastafev (Nikita Astafev)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 7 2018, 10:54 AM (23 w, 4 d)

Recent Activity

Nov 8 2018

nastafev added a comment to D45616: [X86] Lower _mm[256|512]_cmp[.]_mask intrinsics to native llvm IR.

Thanks, I agree with @andrew.w.kaylor and his interpretation.
I was trying to convey the message that the programmer operating with intrinsics relies on the semantics they carry because there's no other way to express that semantics. Re-optimizing what's already optimized (hand-written code with intrinsics) may be nice, but not critical in his (my) view, whereas violating semantics defeats the purpose - I could have written that same loop around generic compare myself if that was enough for my purposes. I would not insist on the way you resolve this, this is not urgent, but I do believe this is a regression and it deserves a fix.

Nov 8 2018, 4:39 PM

Nov 7 2018

nastafev added a comment to D45616: [X86] Lower _mm[256|512]_cmp[.]_mask intrinsics to native llvm IR.
can trigger arbitrary floating-point exceptions anywhere in your code
Nov 7 2018, 3:10 PM
nastafev added a comment to D45616: [X86] Lower _mm[256|512]_cmp[.]_mask intrinsics to native llvm IR.

Hello. It seems you were well aware that you are changing the semantics of FP operation here by ignoring the signaling/quiet portion of the immediate. But what shall the user do now? There was no way to force quiet FP comparison behavior in C language, so intrinsics and reliance on quiet compare (and SAE bit in AVX512) were natural way of forcing it. And now you are taking them out. Is there a switch that could prevent this optimization? I think it could be more tolerable if you only did this under fast-math.

Nov 7 2018, 11:14 AM