Ah, right, I see about the need for the exclusive and inclusive scan results.

But I still don't understand it:

1. Why do you want an exclusive scan? Surely what you're trying to do is just "sum" up all lanes into lane 63, which is an inclusive scan.
2. Can't you do an exclusive scan with powers of 2 shifts like an inclusive scan, but just with the wf_sr1 on the front? (Although I think that gives the wrong answer due to (1)).
3. Isn't the only thing wrong with this code before this fix that you forgot to put the bank masks on steps 2, 3 and 4? (Although you're correct to remove the unnecessary intermediate wwm intrinsic calls.)

Oh, it's because you've switched to an exclusive scan.

I don't understand this fix. Surely a reduction is done with just power of two shifts. Why do we need the shift by 3 as well? What is the extra wf_sr1 dpp at the start for?

V2: Addressed review comment.

In D57027#1381468, @scott.linder wrote:

The code looks good to me, but I'm wondering why the move from doing this in AsmPrinter::EmitEndOfAsmFile to TargetStreamer::finish? It seems like it is fine to emit directives in either, but I don't understand why the change here.

I was thinking it is a bit odd that we're having to handle WQM and WWM in this way even though they are target instructions. However I think it is ok because they act like the non-target COPY instruction in that they do not specify a register class for operands.

V2: Addressed review comments.

V2: Addressed review comments.

Yes, sorry, I pushed this fix to phab without even checking that it applies to trunk. I had completely forgotten that you have already fixed this in trunk (D48431) and I reverted your fix in our local branch.

For a quick fix for my specific problem, I have gone for the frontend hack, so I am abandoning this review.

Oh, I've found it already in use in a different case in LLPC:

EarlyCSE does seem to common up in this situation. And, if I disable that, I get GVN commoning it up.

It's EarlyCSE, which seems to completely ignore Convergent. That's bad, right?

It would be good to have comments from other reviewers re the whole idea of having a TargetRegistry interface to allow readobj-style dumping of a target-specific note type to be inside the target.

-strip actually does more, but will be fine for the application I need it for.

Hi Michał and Chandler. I wasn't sure who to add as reviewers for this. If you can think of anyone more appropriate, please add them. Thanks.

V2: Addressed review comments.

This particular family of notes is target specific because it contains information on how the driver should program the hardware in order to be able to run the shaders in this graphics pipeline. So I think that justifies treating the notes as target specific.

Ping.

For the old intrinsics, there used to be code called from dag pattern matching to convert a single offset into some combination of voffset, soffset and instoffset. Is that what you're referring to?

Requires D52823. Currently no in-tree user of this code.

See D52824 for the start of AMDGPU implementing this.

See D52822 for AMDGPU implementing ELFNoteDumper.

Requires D52821.

LGTM

Hi Quentin

1. That test only fails without this fix if you have the fix in D51257.

V2: mir test

Hmm, me too for trunk. It only fails on our fork that is 340950 plus local changes, so the code generated by instruction selection is probably different.

This is now superseded by D52061. If that one is approved, I will abandon this one.