Only if the value is negative or positive is what matters,
so use a constant that doesn't require an instruction to
materialize.
Details
- Reviewers
• tstellarAMD nhaehnle arsenm
Diff Detail
Event Timeline
I don't understand why changing the type to i32 is necessary. Isn't -1.0 also a legal inline immediate practically everywhere?
I agree, but the D3D designers in their infinite wisdom designed a KILL opcode with a floating point parameter, which we inherited via TGSI in Mesa, which in turn motivated this (indeed somewhat questionable) intrinsic.
Hmm. My concern is that (non-constant) KILL gets lowered to a floating point comparison, which treats NaNs specially. (i32)-1 is a NaN. I admit that it doesn't really matter since this patch uses a constant, but it still leaves me with an uncomfortable feeling.
The intrinsic itself's type doesn't change, this is just an internal implementation detail
I forgot about this patch. I investigated our kill code generation some more, and it turns out that changing the "default" kill intrinsic to take an i1 instead of a float leads to better code anyway.
So if this change here is urgent to you for some reason, just go ahead and commit as-is and I'll rebase my changes on top of it, otherwise I'll soon post a change that should end up having the same effect.
Yes, I'm working on a combination of patches for LLVM and Mesa that replaces both llvm.AMDGPU.kill and llvm.amdgpu.kilp with an llvm.amdgcn.kill(i1) intrinsic, where the argument is true if the thread should be killed.