[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