Update alignment for int32 type lds_size argument

In D158150#4594958, @arsenm wrote:

Why do we need this? I thought this was already available in the dispatch packet, you just need to subtract the statically known size

Make lds size argument 32 bit int type.

Update test.

In D148142#4378978, @arsenm wrote:

If we’re going to do this, no changes should be needed in SIFrameLowering. The wavesize set in the subtarget constructor would be adjusted to consistently apply this everywhere. The prolog code is a very minor piece of this

Rebase.

Updated patch as per feedback from @Pierre-vh

expandImpliedFeatures gets all the features implied by current GPU. But wavefrontsize32 and 64 are not part of the feature list for gfx10 and above targets in AMDGPU.td. AFAIU, It is assumed those subtarget supports both the features if they are not part of the list. So GPUFeatureBits cannot be relied on to query FeatureWavefrontSize32/64.

Remove wavefrontsize64 function if compiling in wave32 mode.

Updated patch to delete the function if FeatureWavefrontSize32 is not supported by current GPU.

Rebase.

Port MBUF related tests from global-isel containing all the test combinations.

@foad As per your feedback, changes to sub.ll test have been made and merged upstream : LINK

Rebase. Update test.

Changes done as per review by @arsenm

Hi @nikic. I have made the changes that were suggested previously. Could you please review?

Rebase. Update test control-flow-fastregalloc.ll

Rebase.

Changes done as per @arsenm review.

Rebase

Fix mul.ll test failure.

Use ReversePostOrderTraversal list to compare machine instructions from different basic blocks.

Rebase. Ping

Introduce SIInstrWorklist. It has a std::set with comparison operator to store instructions as per order in machine function. This tries to solve the previous issue with sorting the vector in every iteration.

In D141030#4059355, @arsenm wrote:

I think this will mishandle the case where both the SRD and the soffset are VGPRs. You need to handle both at the same time in one waterfall loop (this should show up if your tests used a meaningful SRD). You can also just look into the globalisel tests for these intrinsics, they test all the permutations already

Make changes to legalize soffset and rsrc together.

Rebase

Rebase

Rebase

Use loadMBUFScalarOperandFromVGPR to build waterfall loop for soffset and srsrc.

Remove check for src array type.
Drop last zero from resulting NewIndices after matching the types.
Drop triple from test. Updated test checks with update_test_checks.py.
Added new tests for struct of array type and to check new zero index in resulting gep.

In D138637#3970359, @nikic wrote:

I think in terms of general approach, the better way to handle this would be to relax the Src->getResultElementType() != GEP.getSourceElementType() check to allow the transform if the types can be made to match by adding additional zero indices.

(As a meta note, I think we'd probably be better off considering GEPs with multiple dynamic indices to be non-canonical, and try to split them up instead, e.g. because this allows LICM of an invariant part. But I guess that's not our current stance. It would be interesting to hear where you have found this merging to be beneficial.)

Rebase. Use poison for srsrc operands.

Rebase. Ping

Removed inreg to params of tests. Made srsrc operand undef.

Rebase. Use -passes=instcombine in test.

Made changes to only identify copy and its result used by soffset of MUBUF/MTBUF. needToBeConvertedToVALU returns false if such pattern is found.
This also fixes vgpr-descriptor-waterfall-loop-idom-update.ll test, where the previous revision of the patch doesn't generate waterfall loop.

Rebase.

Thanks @nikic for feedback. Made changes to match Src ResultElementType with GEP SrcElementType by adding additional zero indices to Src gep.

Update code as per @jmmartinez comments.

Added comments to tests.

Rebase.

In D134423#3919858, @alex-t wrote:

In D134423#3914502, @foad wrote:

In D134423#3912577, @alex-t wrote:

BTW, if %5 is divergent we have a bug in ISel. We now should not have any V2S copy with the divergent source.

Look at the MIR that @skc7 quoted. %5 is divergent - it's copied from a vgpr function argument.

The BUFFER_LOAD_DWORDX4_OFFEN is one of (as I remember correctly 5) the exceptional opcodes for which V2S copy is created even in case the copy source is divergent.
There is no bug in ISel. We have the value in VGPR because it is divergent and this is correct. The V2S copy is created in InstrEmitter just because the opcode requires SGPR.
We have yet several other such opcodes.

V_WRITELANE_B32, S_BUFFER_LOAD_DWORD_IMM, BUFFER_LOAD_FORMAT_X_OFFSET, BUFFER_LOAD_FORMAT_X_IDXEN, BUFFER_LOAD_FORMAT_X_OFFEN, BUFFER_LOAD_FORMAT_X_BOTHEN, IMAGE_SAMPLE_V1_V2
And this is really a TODO. For each of them, we should make a design and change legalizeOperand correspondingly.

Rebase.

Rebase. D137567, D137569 commits are merged upstream.

In D134423#3912577, @alex-t wrote:

In D134423#3911947, @foad wrote:

In D134423#3911726, @skc7 wrote:

%8:sreg_32 = COPY %5:vgpr_32
%7:vgpr_32 = BUFFER_LOAD_DWORD_OFFEN %4:vgpr_32, killed %6:sgpr_128, %8:sreg_32, 0, 0, 0, 0, implicit $exec ::

I need more context. Is %5 uniform?

I think that I've got an idea behind this patch. Let's say %5 is uniform. Then we've got to try to promote all the %8 descendants to SALU if possible.
In some cases, it appears that such a copy has few or even no SALU descendants, and according to the common algorithm should be converted to VALU.
When the conversion is done, legalizeOperands creates the waterfall loop which is obviously much worse than inserting the v_readfirstlane_b32.
As far as I understand, @skc7 addresses this scenario and aims to avoid an unnecessary waterfall loop.
BTW, if %5 is divergent we have a bug in ISel. We now should not have any V2S copy with the divergent source.

Rebase. Moved fixes for scalable vectors to reviews: D137567, D137569

changes as per review suggestion.