tree 0c6e8dab3e73d0a9f14154eb4f44984fd2c64b35
parent fa072bd29a109be424e6f4521823529750a55efe
author Krzysztof Drewniak <Krzysztof.Drewniak@amd.com> 1741130346 -0600
committer GitHub <noreply@github.com> 1741130346 -0600
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJnx4pqCRC1aQ7uu5UhlAAAaSIQAFee2IJb7zcgU+NscrmeinJ0
 Sh4Wz2jPH+EKJld/pognX+x8ggMusbv9BEJN8a1DULCxZBpSbzNeFZkJ273RXMGG
 blaVrSpVauQUKtBnZezfGyiRIUeKZd9wWOPRxsg+1+dFcH5/mw8qiOcO7wAiz7v3
 o2yslp9wjBFInU1RrnaPJiXTzJYObZJM7bgYWheWDPyJgdl1P3uCM5Xyhv2P7W+y
 W5H/7mC3Jh0pD+qe9eAR/ppm6bEDgZUi1GQU+T5QAGnW9su7jk/d87MJCPQAjR5m
 /yWvh64MNMiG+ot3YuE8hwgCWCYxJZcwSzrBmBLwYiWZ10ZST2cVEhgPl7D+uqZo
 24hMbALMFE1Pf7RpSbPP3kffgxK3wLBGZXzEx50SS32DAcxPKo5jUfOFcuy5ZQbz
 +glBmKlnOjmVuh8O06OxhekEl6C7uujYPyrqkapfrQpTfCHw0t/OnJHiSbqu3u0+
 Q/c/+3DqkcrgAhri86IB+c3eKUkqP9Qc9p3omZPvivIH+FU5MPkZ5xyO26YVRito
 uDAFl/Htj+jz731QbBOfGd6LoHxDMABvsJGB+qz99ErcZoAW5yPPqQkjBSE5kgK+
 PQmiT3Z2+jqMqOiKx9STgX3VHVsMbbHdyf6am9Y2uD2aZYXOs6uxuTF484jKD68Y
 RgC2pw5pcXxKmUgRNObI
 =DYPW
 -----END PGP SIGNATURE-----
 

[AMDGPU] Add custom MachineValueType entries for buffer fat poiners (#127692)

The old hack of returning v5/v6i32 for the fat and strided buffer
pointers was causing issuse during vectorization queries that expected
to be able to construct a VectorType from the return value of `MVT
getPointerType()`. On example is in the test attached to this PR, which
used to crash.

Now, we define the custom MVT entries, the 160-bit
amdgpuBufferFatPointer and 192-bit amdgpuBufferStridedPointer, which are
used to represent ptr addrspace(7) and ptr addrspace(9) respectively.

Neither of these types will be present at the time of lowering to a
SelectionDAG or other MIR - MVT::amdgpuBufferFatPointer is eliminated by
the LowerBufferFatPointers pass and amdgpu::bufferStridedPointer is not
currently used outside of the SPIR-V translator (which does its own
lowering).

An alternative solution would be to add MVT::i160 and MVT::i192. We
elect not to do this now as it would require changes to unrelated code
and runs the risk of breaking any SelectionDAG code that assumes that
the MVT series are all powers of two (and so can be split apart and
merged back together) in ways that wouldn't be obvious if someone tried
to use MVT::i160 in codegen. If i160 is added at some future point,
these custom types can be retired.