In D71192#1886101, @piotr wrote:

Hi @cwabbott,
This commit causes a GPU hang on amdvlk in one test, due to the missing "done" bit on the normal export. I think in the attached case the patch incorrectly classifies the export as being in an infinite loop.

before_AMDGPUUnifyDivergentExitNodes.ll2 KBDownload

In D71192#1848832, @nhaehnle wrote:

LGTM. Did you manage to sort out your commit access issues?

It seems I forgot to test this against the entire testsuite, which made a bunch
of buildbots unhappy. This version fixes the issues:

Can someone else please commit this? @nhaehnle? It's been almost a month, excluding Christmas, and my commit access situation still hasn't been resolved. This fix is necessary for radv to pass VK 1.2 conformance, and we'd like it to cherry-pick it to LLVM 10 before it's released.

I just asked earlier this week to get my commit rights back, but I haven't heard back right away, so you can commit it if I don't get it first.

Suppress unused variable warnings in release builds.

Add diff for new test.

Add a test for multiple phis as suggested by @nikic.

• Update precommitted test in this commit.
• Make the test match the original bug better. It turns out that in my attempt to make it harder for other transforms to happen beforehand and break the test, I accidentally made another transform kick in which broke it anyways. Use this form with a loop which should hopefully defeat other optimizations better.

In D70781#1774320, @nhaehnle wrote:

If two exports with done bit are executed, I suspect we could enter race conditions where the export allocation is freed after the first export with done, and then another wave gets the same export memory spot and its data could be overwritten by the second, newly introduced, export with done bit. Or enter some hang condition in the hardware. Who knows.

• Fix wrong indentation and missing "immarg" on intrinsic declaration
• Make sure that we remove the done bit from existing exports, and test it

Update comment to explain why this works even when only some threads are killed.

In D70781#1766515, @critson wrote:

In D70781#1765291, @cwabbott wrote:

I think this isn't an issue because the exec mask at the end of the program is going to be the same as the mask when the last "real" export happens. The way kill is implemented means that control flow never reconverges for a killed thread, so it stays dead until the very end. I've done some manual tests with the aforementioned CTS test, and it does seem to be properly discarding the right pixels too. But that's a good question :)

I agree in the general case that should hold; however, if there was a discard after the true export done then it wouldn't. I don't have a good use case for why such a thing would happen -- exports should in the main be the last thing a (PS) shader does. So if we consider kill after export done semantically invalid then this is fine.

In D70781#1765237, @arsenm wrote:

This seems fine to me, although I know nothing about exports, and I would prefer if we could eventually fix the kill intrinsic design

In D70781#1764809, @critson wrote:

The extra export is for not great for performance as it introduces an unnecessary stall at the end of the shader.

Fix leftover extraneous change from an earlier version.

FWIW, this LGTM. Maybe it would be a good idea to add more lines to global-constant.ll to test radeonsi (amdgcn-- at the moment) and radv (amdgcn-mesa-mesa3d) under the NOPAL label.

I just noticed that this already came up in D65813 and it does the right thing, it's just waiting review.

In D67003#1652687, @arsenm wrote:

In D67003#1652686, @cwabbott wrote:

In D67003#1652676, @arsenm wrote:

Is mesa actually using mesa3d now? I thought we were still in the unpleasant situation where "unknown" OS was treated like mesa3d, but not quite. I thought clover and radv were using mesa3d, but OpenGL was not. If it has, can we finally drop the second scratch implementation?

Ugh, you're right, radeonsi still has target triple = "amdgcn--". Why exactly is that? Would anything break if we just changed it to amdgcn-mesa-mesa3d like what radv does? I don't want that to block this, though, so is there any other user that needs to return true here? AMDVLK maybe?

Mesa is the only oddball relying on the unknown OS behavior. IIRC this required work in mesa to switch the scratch ABI from using relocations to what radv does, but besides that I think everything would work

In D67003#1652676, @arsenm wrote:

Is mesa actually using mesa3d now? I thought we were still in the unpleasant situation where "unknown" OS was treated like mesa3d, but not quite. I thought clover and radv were using mesa3d, but OpenGL was not. If it has, can we finally drop the second scratch implementation?

FYI, I think I don't have commit access anymore because of the whole licensing thing, so I'll need someone else to commit for me.

Actually, now that I think about it, I believe we realized that SIFixWWMLiveness has a giant hole in that if any of the extra live ranges we insert are split, it'll fall over. I don't think anyone has come up with a way to express the constraints only with extra defs and uses in a way that always works, and I'm not sure it's possible. The issue is that we're lying to LLVM RA by pretending that vector instructions always fully clobber their destinations, and while before we were careful to never write to any inactive channels in order to keep up the charade, but WWM instructions force us to deal with it somehow. Fully informing LLVM of what's going on would involve marking every vector instruction as partially clobbering its destination, even the move instructions and load/store instructions LLVM emits during RA, which of course would tank performance unless LLVM is taught about predicated liveness -- but of course that's a whole lot of work that opens another can of worms (register pressure is suddenly not that meaningful anymore...).

In D59295#1427864, @arsenm wrote:

If you can express the constraints with some series of uses and defs, that would be preferable.

In D59295#1427734, @arsenm wrote:

I really don't like introducing new, dynamically reserved registers for this. It's going to introduce hell for dealing with any kind of ABI, and reserved registers are generally a bad idea. There's also nothing guaranteeing there are any free registers available to reserve, since you are just grabbing totally unused ones. This is going to just hit some variant of the problem I've been working on solving for handling SGPR->VGPR spills. Can WWM code be moved into a bundle or something?

Fixed a regression in the llvm.amdgcn.kill tests.

I'm not going to read everything in detail, but the combining rules look correct to me and everything passes with this pass enabled. Feel free to re-enable it.

Adding a pattern for this wouldn't work for what I wanted to do, which was a ballot/inverseballot pair to operate directly on the bitmask representation of a boolean, since there's a bug where SelectionDAG forgets that ballot removes divergence, and it needs to be non-divergent for the pattern to fire. That being said, inserting two readlanes isn't that much better, so maybe I should just fix that instead...

• Remove spurious whitespace change.
• Lower S_INV_BALLOT with EmitInstrWithCustomInserter.

• Added a pseudoinstruction lowered in SILowerI1Copies, and legalized it more

similarly to how other instructions are legalized.

• Added tests where the source is a uniform and non-uniform phi node. I had to

to use the amdgpu_ps calling convention here to get the arguments into SGPR's.

In D57748#1385046, @arsenm wrote:

The user can't actually guarantee the argument is uniform, since transforms are allowed to touch the argument. We're accumulating quite a few places that assume this though

I figured it would be a little easier if I looked at these cases by myself. It turns out there are more problems with isIdentityValue, including some correctness issues. After fixing these, everything works correctly now.

Sorry, I just got back from break this week. I've run CTS with the pass enabled, and it now passes, although it seems most of the patterns we use don't get folded. Firstly AND, XOR, unsigned max, and unsigned min are most troubling, since the code that gets generated looks like it should be optimized:

In D55314#1321326, @vpykhtin wrote:

Ok, I'll disable it. I'm not sure about 3rd point: are you sayng the pass doesn't actually perform the optimization or it's fundamentally wrong? Because it implemented to handle "identity" cases for add, mul and min/max.

In D55314#1321222, @vpykhtin wrote:

In D55314#1321167, @hakzsam wrote:

Hi,

This change breaks most of the subgroups tests with RADV (ie. dEQP-VK.subgroups.arithmetic.*).

Any reasons why you enabled it by default? Looks like it now triggers a new bug in the AMDGPU backend.

Thanks!

Hi,

this is awaited feature and other reason is to detect a situation such yours. I think it's better to turn it off and reproduce the failures: how can I do this?

In D54516#1300997, @nhaehnle wrote:

In D54516#1298178, @cwabbott wrote:

I believe the combination of Convergent + not Speculatable should mean that the compiler shouldn't hoist it to a non-control-equivalent block and shouldn't CSE it. In particular, IIRC it's not guaranteed that that a readnone function always return the same value when it's called with the same arguments, so it's not safe to CSE -- it just means that LLVM can move other things across it, since it doesn't modify *caller-visible* state. What pass is causing a problem? Maybe it's a bug in the pass?

readnone is literally readnone. Maybe you're mixing this up with inaccessiblememonly?

I believe the combination of Convergent + not Speculatable should mean that the compiler shouldn't hoist it to a non-control-equivalent block and shouldn't CSE it. In particular, IIRC it's not guaranteed that that a readnone function always return the same value when it's called with the same arguments, so it's not safe to CSE -- it just means that LLVM can move other things across it, since it doesn't modify *caller-visible* state. What pass is causing a problem? Maybe it's a bug in the pass?

In D46470#1088984, @tpr wrote:

You made a comment in this code that "this is a workaround anyways until LLVM gains the notion of predicated uses and definitions of variables". How do you see that working? Are you aware of anyone else thinking along those lines in the LLVM community? Something to think about for the future.

For the liveness issue, maybe a better way to solve it would be to add a new ENTER_WWM pseudoinstruction similar to EXIT_WWM, and add a matching implicit def to the matching ENTER_WWM whenever we insert an implicit use on EXIT_WWM, and mark both of them as kills. After all, any affected registers only need to interfere with the instructions run in WWM, so that should help with code quality too. I'm not sure why I didn't do that in the first place.

Ping on this one. This is the last outstanding patch for implementing AMD_shader_ballot in Mesa.

It looks like Sam has worked a lot on the assembler, including adding support for DPP instructions, so I'm adding him for the assembler bits. I'd like to get this in before I leave next week, though.

Remove spurious change to AMDGPUAsmParser.cpp

Fix assembling DPP instructions. Also, adopt a more conservative version of
D34715. In particular, we ignore Constraints/DisableEncoding from the original
instruction for the DPP version. The only instruction with any special
constraints is MAC, because of its fake third source, and there it doesn't make
sense to keep the fake third source since it has to be the same as the normal
"old" source anyways. We can revisit this if something else comes up, but I
think this is a good plan for now.