Skip to content

[RISCV][GISel] Don't custom legalize load/store of vector of pointers if ELEN < XLEN. #101565

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 13, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions llvm/lib/Target/RISCV/GISel/RISCVLegalizerInfo.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -330,9 +330,11 @@ RISCVLegalizerInfo::RISCVLegalizerInfo(const RISCVSubtarget &ST)

// we will take the custom lowering logic if we have scalable vector types
// with non-standard alignments
LoadStoreActions.customIf(
LegalityPredicates::any(typeIsLegalIntOrFPVec(0, IntOrFPVecTys, ST),
typeIsLegalPtrVec(0, PtrVecTys, ST)));
LoadStoreActions.customIf(typeIsLegalIntOrFPVec(0, IntOrFPVecTys, ST));

// Pointers require that XLen sized elements are legal.
if (XLen <= ST.getELen())
LoadStoreActions.customIf(typeIsLegalPtrVec(0, PtrVecTys, ST));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// Pointers require that XLen sized elements are legal.

Do we need to mark as legal in the ELEN < XLEN case? with a call to legalIf?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't seem to have marked any pointer vectors with legalIf. I think they just go to the custom handler and get treated as legal if they pass the alignment check.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be marking pointer types legal with legalIf? The only case they need to go through custom is when they have special alignment.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. It would make the custom handler simpler, we wouldn't need to call allowsMemoryAccessForAlignment since we wouldn't get to the custom handler if we had already check the alignment with legalIf.

On the other hand calling allowsMemoryAccessForAlignment allows us to handle FeatureUnalignedVectorMem correctly. So maybe that's a vote for removing the legalIf and just letting the custom handle always handle it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand calling allowsMemoryAccessForAlignment allows us to handle FeatureUnalignedVectorMem correctly. So maybe that's a vote for removing the legalIf and just letting the custom handle always handle it?

Do we care about FeatureUnalignedVectorMem in the aligned cases? If we were to move the legalIf, it could probably be done in another patch because it doesn't have to do with pointers.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we care about FeatureUnalignedVectorMem in the aligned cases? If we were to move the legalIf, it could probably be done in another patch because it doesn't have to do with pointers.

No. But by listing the aligned cases explicitly with legalIf we're effectively hardcoding what allowsMemoryAccessForAlignment is already capable of checking. Is there an advantage to having both a legalIf and a customIf when the customIf can already handle the legal case?

}

LoadStoreActions.widenScalarToNextPow2(0, /* MinSize = */ 8)
Expand Down
Loading