[llvm] [CodeGen] Make LoadExtActions address-space aware (PR #162407)
Matt Arsenault via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 25 09:40:31 PST 2025
================
@@ -1472,27 +1472,40 @@ class LLVM_ABI TargetLoweringBase {
/// Return how this load with extension should be treated: either it is legal,
/// needs to be promoted to a larger size, needs to be expanded to some other
/// code sequence, or the target has a custom expander for it.
- LegalizeAction getLoadExtAction(unsigned ExtType, EVT ValVT,
- EVT MemVT) const {
- if (ValVT.isExtended() || MemVT.isExtended()) return Expand;
- unsigned ValI = (unsigned) ValVT.getSimpleVT().SimpleTy;
- unsigned MemI = (unsigned) MemVT.getSimpleVT().SimpleTy;
+ LegalizeAction getLoadExtAction(unsigned ExtType, EVT ValVT, EVT MemVT,
+ unsigned AddrSpace) const {
----------------
arsenm wrote:
This is too narrowly targeted at ext loads - really we need to know the address space for the legality of all loads (and stores). This has been a big DAG pain point since always (e.g., https://github.com/llvm/llvm-project/issues/90714). Every memory instruction legality query should be a function of the types, address space, and alignment.
std::map probably isn't the right way to encode this information either. In GlobalISel you have a chain of arbitrary legalization predicates that can check the address space.
It is a full 24-bit value, it just happens the common cases targets care about are small numbers. You can construct a system that wants to handle an arbitrary value range. The system today mostly treats non-0, but not explicitly handled address spaces as 0, which is kind of a nice property.
https://github.com/llvm/llvm-project/pull/162407
More information about the llvm-commits
mailing list