[Mlir-commits] [clang] [lld] [llvm] [mlir] [IR] Introduce `T<address space>` to `DataLayout` to represent flat address space if a target supports it (PR #108786)

Artem Belevich llvmlistbot at llvm.org
Mon Sep 16 11:10:00 PDT 2024


Artem-B wrote:

The description of the flat address space in the `TargetTransformInfo.h` is somewhat vague and both, soo specific and not precise enough, IMO:
```
The flat address space is a
  /// generic address space that can be used access multiple segments of memory
  /// with different address spaces. Access of a memory location through a
  /// pointer with this address space is expected to be legal but slower
  /// compared to the same memory location accessed through a pointer with a
  /// different address space.
  ///
  /// This is for targets with different pointer representations which can
  /// be converted with the addrspacecast instruction. If a pointer is converted
  /// to this address space, optimizations should attempt to replace the access
  /// with the source address space.
```

- "can be used access multiple segments of memory with different AS" -- does it mean all of them? If it covers only some of the segments, which ones?
- "access expected to be slower" -- that's also not necessarily a universal property. It's conceivable that on some architectures, it's conversion between address spaces that may be non-free, but once you have the pointer, actual accesses work equally fast.

> * Can there be more than one flat address space?
> - No

Why not? E.g. if we have a processor with Harvard architecture, there may conceivably be multiple 'flat', non-overlapping address spaces, each covering a set of specific ASes.

I think conceptually we should describe AS hierarchy explicitly, and avoid the assumptions on their number or layout.
E.g. `T0:1,2,3,4,5`  may mean `AS 0` is a flat superset of `AS 1,2,3,4,5`.

... and then change the API to `getParentAS(AS)` which would return AS itself if it's not contained in any other AS, or the higher level AS.

https://github.com/llvm/llvm-project/pull/108786


More information about the Mlir-commits mailing list