I think it looks very good, thank you!

LGTM.

In general adding "custom" code to SelectionDAGBuilder::setValue looks odd. Instead I would add a target-customizable postprocessing loop on pairs of Value <-> SDNode into SelectionDAGISel::SelectBasicBlock right after the DAG is created. The target hook should be able to get whatever it requires LLVM IR analisys and annotate SDNodes.

Added test. It turns out getOccupancyWithLocalMemSize function doesn't account for amdgpu-waves-per-eu attribute so I added call to getWavesPerEU (which does).

fixed per review issues.

LGTM.

SIInstrInfo::doMemOpsHaveSameBasePtr looks generic enough to be default indeed but should we commit this first and then make doMemOpsHaveSameBasePtr default so we could rollback to this one in case of severe regressions? LGTM by the way.

Wow! I wish I had this before! LGTM.

LGTM. However it looks like we should fix TD to follow single naming convention.

Ok, unmangled part looks different indeed. If the issue with pre-link checking is solved this patch is ok with me.

Splitting AMDGPULibFunc in two classes looks a huge overkill. How about modifying AMDGPULibFunc::parse so it could accept unmangled names and just return an enum id for the function (using some fast lookup approach)? Type info for such functions can be left unpopulated and supposed to be handled by the client (as in fold_read_write_pipe).

LGTM.

LGTM.

The implementation of this approach looks good to me. The only question is which way to go to implement v3 vector.

LGTM.

LGTM.

LGTM, Thanks!

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM, with nit.

LGTM.

LGTM.

LGTM.

fixed as per comments

In D33289#758647, @rampitec wrote:

In D33289#758351, @vpykhtin wrote:

I inserted MachineInstrRegs between reset and recede, all functions are in old places. I should move MachineInstrRegs higher

I see it now, thanks. Can you move it higher please?

I agree if this is a bugfix.

I inserted MachineInstrRegs between reset and recede, all functions are in old places. I should move MachineInstrRegs higher

LGTM.

LGTM.

I'm a bit confused with all of these advance... but lets submit and improve this later.

You can do the reset with move - this would not require copy.

I really don't understand it all. Why not just have reset(MachineInstr *, LiveRegSet ) and do a reset on the next BB with liveset from previous BB? It looks like your code does it. Another question: your reset does skip debugs, but the caller doesn't know about it and can supply unskipped iterator to the next advance.

In D33105#755186, @rampitec wrote:

In D33105#755182, @vpykhtin wrote:

This looks a bit as using carkeys to open a bottle. Should we have single instruction RP diff returning function without changing any state?

We probably should, but it probably does not belong to this change.

This looks a bit as using carkeys to open a bottle. Should we have single instruction RP diff returning function without changing any state?

In D33105#755142, @rampitec wrote:

In D33105#754976, @vpykhtin wrote:

If I don't mistake downward tracker cannot work on arbitrary instruction order, so let's change it's interface so that it tracks current instruction and move it, likewise like llvm standard tracker, that is reset(MI), advance()

In general it cannot work on an arbitrary order, but it can be used as a probe to schedule next arbitrary instruction and then reset to the previous state.
Then in D33117 I'm using advanceBefore to cross basic block boundary and I do not really want to slow down advance method by checking for the iterator end condition which is needed relatively seldom.

If I don't mistake downward tracker cannot work on arbitrary instruction order, so let's change it's interface so that it tracks current instruction and move it, likewise like llvm standard tracker, that is reset(MI), advance()

LGTM.

LGTM, Thanks!

LGTM.

Looks good.

LGTM.

LGTM.

Looks very good now! Thanks!

Thank you for doing this! I really need it.

Looks good.

LGTM.

For the second assert it may be the case for iterator invalidation, though I haven't checked.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

Thanks Axel!

The following tests assert with this (and predecessors) patches with SISched turned on by default:

LGTM.

First part of comments related only to C++ issues

If SU(i) uses register produced by SI(j):

I may miss something, but it looks that you can build data edges when building a superdag consisting of blocks. Incoming data edges would be liveins, outcoming - liveouts.

In general, I think moving instructions just to use standard RP tracker to discover liveins/liveouts isn't a good idea. It isn't only slow but doesn't look reliable too. Why not discover these sets using DAG directly?

Stack trace:

I didn't debugged it and I don't know why you decided so.

I ran lit tests with sished with ShouldTrackLaneMasks=true enabled by default with this patch, the following tests asserted:

LGTM.

LGTM.