17:39 fdobridge: <g​fxstrand> Right now, NAK should be lowering away 64-bit shifts already. The only 64-bit op we implement right now is iadd
18:34 benjaminl: the instr in the IR is OpShf, which has low and high srcs, but nak_from_nir always sets one of them to zero
18:34 benjaminl: would it be a good idea for me to replace this with OpShl, and then emit SHF on sm75 only?
18:35 benjaminl: right now I'm doing the reverse of this, where the IR still has the full SHF, and then the sm50 encoding asserts that one of the two srcs is zero and emits SHL/SHR
18:39 karolherbst: apparently on sm50 we use SHF only for 64 bit shifts
18:40 karolherbst: the two sources put together make up a 64 bit value
18:40 benjaminl: yeah, SHL/SHR doesn't exist on sm75, right?
18:40 benjaminl: I haven't checked this
18:40 karolherbst: correct
18:41 karolherbst: on sm75+ SHL/SHR are just assembly alias to SHF
18:41 karolherbst: but on sm50 it _should_ work the same
18:41 benjaminl: nak has a similar situation with IMad64, where we're generating this instruction for imul/imul_high and then discarding one of the outputs
18:42 benjaminl: while IMAD64 doesn't exist on sm50, so I currently have the legalization pass replacing it with IMAD.LO.CC and IMAD.HI.X
18:42 karolherbst: imad64 doesn't exist anywhere
18:42 benjaminl: wait what's encode_sm75 doing then
18:43 karolherbst: there is no 64 bit alu on nvidia
18:43 karolherbst: only shifts and selects exist in 64 bit
18:43 karolherbst: well.. and some fp64 stuff
18:43 karolherbst: also
18:44 karolherbst: on sm50 you don't want to use IMAD
18:44 karolherbst: you want to use XMAD
18:45 karolherbst: XMAD is constant latency 16 bit IMAD and usually always faster than using IMAD
18:46 benjaminl: ah, that's good to know
18:46 karolherbst: you can also always compile some ptx to SASS and use nvdisasm to see what Nvidia generates
18:46 fdobridge: <g​fxstrand> Oh, fun. More 16-bit multiply shenanigans. We had that on Intel, too.
18:47 fdobridge: <g​fxstrand> 🙄
18:47 fdobridge: <k​arolherbst🐧🦀> yeah.. the tldr is that IMAD has variable runtime
18:47 fdobridge: <k​arolherbst🐧🦀> and even using 3 XMAD to make a full 32 bit IMAD is fater
18:47 fdobridge: <k​arolherbst🐧🦀> *faster
18:48 fdobridge: <k​arolherbst🐧🦀> luckily, all the subops were already REed: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/codegen/nv50_ir.h?ref_type=heads#L284-305
18:48 benjaminl: ... weird, are there any situations where you would want IMAD?
18:48 karolherbst: I honestly don't know
18:48 karolherbst: nvidia never seems to use it
18:49 karolherbst: but maybe there are some rough corner cases
18:50 fdobridge: <k​arolherbst🐧🦀> maybe there weren't sure if the hardware is correct?
18:50 fdobridge: <g​fxstrand> Those really aren't 64-bit, though. Just two sources which combine to a 64-bit thing. The only real 64-bit integer thing is conversations.
18:51 fdobridge: <k​arolherbst🐧🦀> yeah...
18:51 fdobridge: <k​arolherbst🐧🦀> I guess conversions does count as a proper 64 bit alu
18:52 fdobridge: <g​fxstrand> Could be. Could also be that they needed it for imul_high and just made it do imul too, because why not?
18:52 fdobridge: <k​arolherbst🐧🦀> ohhh.... I just found a cool instruction: I2IP
18:52 fdobridge: <k​arolherbst🐧🦀> heh..
18:52 fdobridge: <k​arolherbst🐧🦀> Turing also got an actual `I2I`
18:53 fdobridge: <k​arolherbst🐧🦀> always saturating though
18:53 fdobridge: <k​arolherbst🐧🦀> and always S32 source
18:53 fdobridge: <k​arolherbst🐧🦀> dest only 8/16
18:53 fdobridge: <g​fxstrand> Saturating is what you want
18:53 fdobridge: <k​arolherbst🐧🦀> yeah
18:53 fdobridge: <k​arolherbst🐧🦀> just curious why Volta doesn't have it
18:53 fdobridge: <g​fxstrand> 🤷🏻‍♀️
18:54 fdobridge: <k​arolherbst🐧🦀> I2IP is like F2FP
18:54 fdobridge: <k​arolherbst🐧🦀> though F2FP is ampere only
18:54 fdobridge: <g​fxstrand> For most integer down-casts, you just want &
18:54 fdobridge: <k​arolherbst🐧🦀> yeah
18:54 fdobridge: <k​arolherbst🐧🦀> anyway.. no 64 bit alu on nvidia 😄
18:55 fdobridge: <g​fxstrand> There's no actual conversation. The only interesting integer down-conversion is a saturating one.
18:55 fdobridge: <g​fxstrand> Are there 64-bit ISetP?
18:56 fdobridge: <k​arolherbst🐧🦀> mhhh.. I thought there is/was
18:57 benjaminl: I'm still kinda confused about sm75 here. does it have a real IMAD64?
18:57 fdobridge: <g​fxstrand> No, it doesn't.
18:57 fdobridge: <k​arolherbst🐧🦀> mhh.. there is also `SGXT`
18:58 benjaminl: is the encode_imad64 function in encode_sm75 emitting something else?
18:58 fdobridge: <k​arolherbst🐧🦀> ohh we even have `OP_SGXT` in codegen 🙃 do we even use it
18:58 fdobridge: <g​fxstrand> It has IMAD.HI which returns the top 32 bits of the result. You have to use those to build a full 64-bit imad
18:58 fdobridge: <k​arolherbst🐧🦀> for EXTBF lowering.. figures
18:59 fdobridge: <g​fxstrand> Hrm... Oh, right. The IMad64 is the version that takes 32-bit sources and produces a 64-bit result.
18:59 benjaminl: yeah
19:00 benjaminl: ah, and this isn't "really 64-bit" because it doesn't take 64-bit sources?
19:00 fdobridge: <k​arolherbst🐧🦀> ohh right.. the only 64 bit SET was a fp64 one
19:00 fdobridge: <g​fxstrand> We really need to make the NIR lowering pass produce those... Need to think about that.
19:00 fdobridge: <k​arolherbst🐧🦀> `DSETP`
19:02 fdobridge: <g​fxstrand> ISETP does have two destination predicates. We need to figure out what the second one does. I suspect it's a free equality check so you can chain two ISETP to get a 64-bit one.
19:02 fdobridge: <k​arolherbst🐧🦀> `IMNMX` is Turing+ only 🙃
19:02 fdobridge: <k​arolherbst🐧🦀> and they ditched `DMNMX` with Volta+
19:04 fdobridge: <k​arolherbst🐧🦀> @gfxstrand the other predicate is the negation of the first one
19:04 fdobridge: <g​fxstrand> Unsurprising, given that there's no NaN behavior to worry about with imin/max. We can just ask NIR to lower, I think.
19:04 fdobridge: <k​arolherbst🐧🦀> uhm.. for 32 bit ops
19:04 fdobridge: <k​arolherbst🐧🦀> the second predicate is always true with `.EX`
19:05 fdobridge: <g​fxstrand> Really? That's dumb. Why would I want a predicate and it's negative? I can just negate the first predicate.
19:05 fdobridge: <k​arolherbst🐧🦀> 🤷
19:05 benjaminl: hmm, why is it useful to have a negated predicate output when most places that take a predicate already allow negation?
19:05 fdobridge: <g​fxstrand> That feels off to me.
19:05 fdobridge: <k​arolherbst🐧🦀> ohhh wait
19:05 fdobridge: <k​arolherbst🐧🦀> it's a _bit_ smarter than that
19:05 fdobridge: <k​arolherbst🐧🦀> the negation happens before the chaining
19:05 benjaminl: ahhh
19:06 fdobridge: <k​arolherbst🐧🦀> so you do the chaining with the actual and the negated result of the operands
19:06 fdobridge: <k​arolherbst🐧🦀> I guess it's only useful for `.XOR` and `.OR` then
19:08 fdobridge: <g​fxstrand> We should get my unit test framework in an upstreamable state and have tests for this stuff. It was really handy when figuring out the exact behavior of IADD3.
19:08 fdobridge: <k​arolherbst🐧🦀> and I guess it does the same with `.EX` 🙃 I just got confused by the doc
19:08 fdobridge: <k​arolherbst🐧🦀> without chaining the second output pred is always true
19:08 fdobridge: <g​fxstrand> What do you mean by "without chaining"?
19:08 fdobridge: <k​arolherbst🐧🦀> a plain `ISETP`
19:08 fdobridge: <k​arolherbst🐧🦀> not `ISETP.AND` or whatever
19:08 fdobridge: <g​fxstrand> Without .EX?
19:09 fdobridge: <k​arolherbst🐧🦀> .EX can also chain
19:09 fdobridge: <k​arolherbst🐧🦀> then you can even input two preds
19:11 fdobridge: <k​arolherbst🐧🦀> no idea how `.EX` workds
19:11 fdobridge: <k​arolherbst🐧🦀> *works
19:12 fdobridge: <k​arolherbst🐧🦀> anyway..
19:12 fdobridge: <k​arolherbst🐧🦀> oP0 = (src0 cmp src1) .op inP0
19:12 fdobridge: <k​arolherbst🐧🦀> oP1 = (!(src0 cmp src1)) .op inP0
19:13 fdobridge: <k​arolherbst🐧🦀> maybe with `.EX` you chain both inputs?
19:14 fdobridge: <k​arolherbst🐧🦀> unchained `.EX` has still the second input predicate...
19:14 fdobridge: <k​arolherbst🐧🦀> unchained I think is basically `.AND` with the first input pred set to `PT`
19:20 fdobridge: <g​fxstrand> Okay. That's something potentially useful. IDK how to use it yet but might be able to. 😅
19:21 fdobridge: <k​arolherbst🐧🦀> you can do it to optimize `OR`s and such away
19:21 fdobridge: <k​arolherbst🐧🦀> uhm.. not sure about the oP1 stuff tho
19:21 fdobridge: <k​arolherbst🐧🦀> maybe if the code does both
19:21 fdobridge: <k​arolherbst🐧🦀> ohh
19:21 fdobridge: <k​arolherbst🐧🦀> I know
19:22 fdobridge: <k​arolherbst🐧🦀> if you have an `or(not(or(a, b)), c)` thing going
19:22 fdobridge: <k​arolherbst🐧🦀> ehh.. a cmp instead of the inner or
19:23 fdobridge: <k​arolherbst🐧🦀> `or(not(ieq(a, b)), c)`
19:23 fdobridge: <k​arolherbst🐧🦀> or something silly like that
19:23 fdobridge: <k​arolherbst🐧🦀> mhhhh
19:23 fdobridge: <g​fxstrand> Yeah, it's so you can more easily fold stuff in.
19:23 fdobridge: <k​arolherbst🐧🦀> yeah....
19:23 fdobridge: <k​arolherbst🐧🦀> I guess it makes sense if you need both values
19:23 fdobridge: <k​arolherbst🐧🦀> otherwise you could fold the `not` with the compare
19:23 fdobridge: <g​fxstrand> You can still do it most of the time if you know demorgan's laws but that makes it easier, I guess.
20:40 benjaminl: got 'compute.basic.*' down to two CTS failures on nak sm50
20:40 benjaminl: both of the failures are image atomics