This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] Fixed non-uniform addr64 MUBUF in shader
AbandonedPublic

Authored by tpr on May 22 2018, 5:21 AM.

Details

Reviewers
nhaehnle
arsenm
Summary

SIInstrInfo::legalizeOperands was assuming that it never sees an addr64
MUBUF in a shader. But it is generated from a global load, which LLPC
uses for a load from a read-only global variable.

Fixed to detect the addr64 case, and then legalize in the same way as in
compute.

Change-Id: I8aee2a0dc37d2061de445c30c7510e40b3e52f3c

Diff Detail

Event Timeline

tpr created this revision.May 22 2018, 5:21 AM
tpr added inline comments.May 22 2018, 5:54 AM
lib/Target/AMDGPU/SIInstrInfo.cpp
3666

OK, so that check doesn't actually work. I'll push a revised fix in a bit.

tpr updated this revision to Diff 148009.May 22 2018, 8:20 AM

V2: Fixed check for whether MUBUF/MTBUF is addr64

tpr updated this revision to Diff 148012.May 22 2018, 8:22 AM

V3: Fixed the comment as well.

Harbormaster completed remote builds in B18455: Diff 148012.
tpr marked an inline comment as done.May 22 2018, 8:23 AM

Pushed revised fix.

arsenm added inline comments.May 22 2018, 8:48 AM
lib/Target/AMDGPU/SIInstrInfo.cpp
3667

I don't like that this was checking the calling convention at all. Can we just eliminate that check altogether?

3669

You should be able to avoid adding isAddr64 by just moving the getNamedOperand call for vaddr below up here

tpr added inline comments.May 22 2018, 9:49 AM
lib/Target/AMDGPU/SIInstrInfo.cpp
3667

So (from a compute point of view) you think it is ok for all non-addr64 cases of MUBUF/MTBUF to go in here? I think that is probably ok, but then I'm not sure why Nicolai added the calling convention check in the first place.

3669

I tried that, and I got false positives on offen/idxen/bothen variants.

arsenm added inline comments.May 23 2018, 3:17 AM
lib/Target/AMDGPU/SIInstrInfo.cpp
3667

The main concerning case I'm aware of with anything touching these is for anything using the add-tid bit (and maybe strided access). In any case, the calling convention isn't actually the property that matters

3669

Oh right, the operand name is still the same for either

tpr added inline comments.May 23 2018, 5:39 AM
lib/Target/AMDGPU/SIInstrInfo.cpp
3667

So you want to replace the calling convention check with something else, but I don't think it is entirely clear yet what the check should be. Can we leave that to a subsequent change? My change here did not add it in the first place.

tpr abandoned this revision.May 25 2018, 11:36 AM

I'm abandoning this. I have a much better fix for my problem, now I have discovered that I can get at divergence information in instruction selection:
https://reviews.llvm.org/D47383