This is an archive of the discontinued LLVM Phabricator instance.

CodeGen: Fix pointer info in SplitVecOp_EXTRACT_VECTOR_ELT
ClosedPublic

Authored by yaxunl on Nov 7 2017, 1:51 PM.

Details

Summary

SplitVecOp_EXTRACT_VECTOR_ELT uses dummy pointer info to generate SDLoad, which
causes isel failure on amdgcn target with amdgiz environment since amdgcn backend
needs correct address space to lower SDLoad.

This patch fixes that.

Diff Detail

Repository
rL LLVM

Event Timeline

yaxunl created this revision.Nov 7 2017, 1:51 PM
rampitec accepted this revision.Nov 7 2017, 2:01 PM

LGTM

This revision is now accepted and ready to land.Nov 7 2017, 2:01 PM
efriedma requested changes to this revision.Nov 7 2017, 2:30 PM
efriedma added a subscriber: efriedma.
efriedma added inline comments.
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

You can't use "UndefValue" here; a non-null "Value*" has to be something alias analysis will understand properly.

If you want to actually get this right, you need to use MachinePointerInfo::getFixedStack(). (CreateStackTemporary doesn't explicitly return the FrameIndex, but you can extract it from the returned FrameIndexSDNode.) Or I guess we could add some way to represent an unknown pointer in a specific address-space, but that's probably not any simpler.

This revision now requires changes to proceed.Nov 7 2017, 2:30 PM
yaxunl added inline comments.Nov 7 2017, 3:04 PM
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

getFixedStack can only be used with frame index with a constant offset, but here the offset is not constant. Here we only need to carry the information about address space. Therefore undef with a specific address space. The backend won't perform any optimization based on that and only uses the address space information.

efriedma added inline comments.Nov 7 2017, 3:28 PM
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

getFixedStack can only be used with frame index with a constant offset, but here the offset is not constant.

Okay. You might need some other PseudoSourceValue, then.

Therefore undef with a specific address space.

undef means "this access doesn't alias anything". See BasicAAResult::aliasCheck.

The backend won't perform any optimization based on that

Among other things, we use MachinePointerInfo for scheduling... so if you get the info wrong, we could move the load before the store.

yaxunl added inline comments.Nov 7 2017, 4:41 PM
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

There is no existing PseudoSourceValue suitable for this.

On the other hand, undef seems to be just the right representation. This is a temporary value on stack and it is used only here and not aliased to anything else.

efriedma added inline comments.Nov 7 2017, 5:25 PM
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

On the other hand, undef seems to be just the right representation. This is a temporary value on stack and it is used only here and not aliased to anything else.

No, undef is clearly wrong. There is one very important aliasing relationship here: the scalar load aliases the vector store. "undef" aliases nothing. (I'm not sure the current MachineInstr::mayAlias will actually come to that conclusion in this case, but that could easily change in the future if we do more aggressive alias analysis with stack temporaries.)

rampitec added inline comments.Nov 7 2017, 5:48 PM
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

Scalar load from scratch is not possible as far as I understand.

yaxunl added inline comments.Nov 7 2017, 5:56 PM
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

How about introduce a new PseudoSourceValue kind "AddressSpace". The only known information about this pointer is its address space.

rampitec added inline comments.Nov 7 2017, 6:01 PM
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

To me it is an Undef in an obscure package. I think undef is just fine here. If we would use it for anything the a PseudoSourceValue holding a FI is a right choice.

rampitec added inline comments.Nov 7 2017, 6:07 PM
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

Also, I would say it does not make situation worse than before the change. Before it was just dummy MachinePointerInfo(). I do not really think all problems shall be solved in a single patch.

yaxunl updated this revision to Diff 124126.Nov 23 2017, 8:13 PM
yaxunl edited edge metadata.

Revised by Eli's comments.

yaxunl added inline comments.Nov 23 2017, 8:16 PM
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
1787 ↗(On Diff #121974)

I found a way to represent a stack memory with unknown offset and have updated the patch. Please take a look. Thanks.

yaxunl updated this revision to Diff 124761.Nov 29 2017, 9:07 AM

synch to ToT.

efriedma added inline comments.Nov 30 2017, 2:43 PM
lib/CodeGen/MachineInstr.cpp
1016 ↗(On Diff #124761)

The new patch is mostly the right idea, but I'm not sure I like the way hasUnknownOffset modifies the meaning of MachineMemOperand... we have code which accesses the offset scattered all over.

yaxunl added inline comments.Dec 1 2017, 10:15 AM
lib/CodeGen/MachineInstr.cpp
1016 ↗(On Diff #124761)

I think what I need is a PointerInfo which is the same as PointerInfo() but has a proper address space. i.e., it returns nulptr for getValue() and getPseudoValue() but returns correct address space. This way, most of the existing codes do not need change, and the backend can still get the correct addr space.

I will see if I can implement that.

yaxunl updated this revision to Diff 125212.Dec 1 2017, 1:24 PM

Removed member hasUnknownOffset from MachinePointerInfo and added member AddrSpace.

efriedma accepted this revision.Dec 1 2017, 1:46 PM

LGTM

This revision is now accepted and ready to land.Dec 1 2017, 1:46 PM
This revision was automatically updated to reflect the committed changes.
foad added a subscriber: foad.Apr 27 2022, 2:19 AM
foad added inline comments.
llvm/trunk/include/llvm/CodeGen/MachineMemOperand.h
41–42

Am I right in thinking that this part of the comment should have been removed, since we're now allowing a null pointer here but with a specified (non-default) address space?

Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 27 2022, 2:19 AM
arsenm added inline comments.Apr 27 2022, 6:37 AM
llvm/trunk/include/llvm/CodeGen/MachineMemOperand.h
41–42

Yes

foad added inline comments.Apr 28 2022, 1:08 AM
llvm/trunk/include/llvm/CodeGen/MachineMemOperand.h
41–42