This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Handle different pointer sizes in unranked memref descriptors
ClosedPublic

Authored by krzysz00 on Jan 9 2023, 8:36 AM.

Details

Summary

The code for unranked memref descriptors assumed that
sizeof(!llvm.ptr) == lizeof(!llvm.ptr<N>) for all address spaces N.
This is not always true (ex. the AMDGPU compiler backend has
sizeof(!llvm.ptr) = 64 bits but sizeof(!llvm.ptr<5>) = 32 bits, where
address space 5 is used for stack allocations). While this is merely
an overallocation in the case where a non-0 address space has pointers
smaller than the default, the existing code could cause OOB memory
accesses when sizeof(!llvm.ptr<N>) > sizeof(!llvm.ptr).

So, add an address spaces parameter to computeSizes in order to
partially resolve this class of bugs. Note that the LLVM data layout
in the conversion passes is currently set to "" and not constructed
from the MLIR data layout or some other source, but this could change
in the future.

Depends on D142159

Diff Detail

Event Timeline

krzysz00 created this revision.Jan 9 2023, 8:36 AM
Herald added a project: Restricted Project. · View Herald Transcript
krzysz00 requested review of this revision.Jan 9 2023, 8:36 AM
ftynse requested changes to this revision.Jan 10 2023, 1:22 AM

I'm not sure this will in fact work for the GPU case that is used as a motivation. Could you add a test for that?

mlir/lib/Conversion/LLVMCommon/MemRefBuilder.cpp
361

Nit: we can use c++17 structured bindings now.

mlir/lib/Conversion/LLVMCommon/Pattern.cpp
235–238

Nit: let's drop the no-longer necessary number of stack elements since we are here.

240

This wouldn't work with non-integer memory spaces such as the ones we now use for GPU, which seems to be the motivation for this patch.

This revision now requires changes to proceed.Jan 10 2023, 1:22 AM

I'll note that the non-integer GPU address spaces are handled not in the type converter but by running a pass before the *ToLLVM calls get their hands no the types, so the assumpiton that getMemorySpaceAsInt() works is currently valid ... but it's probably not a bad idea to account for the more general case now just in case.

krzysz00 updated this revision to Diff 488385.Jan 11 2023, 2:27 PM

Address style comments, add a few consts on getters

krzysz00 marked 2 inline comments as done.Jan 11 2023, 2:29 PM
krzysz00 added inline comments.
mlir/lib/Conversion/LLVMCommon/Pattern.cpp
240

To rephrase, the type converter for MemRefType already assumes that getMemorySpaceAsInt() works. Getting that cleaned up would probably require a broader refactoring of the [LLVM] type converter to keep or allow creating an address space -> int mapping.

ftynse added inline comments.Jan 16 2023, 5:18 AM
mlir/lib/Conversion/LLVMCommon/Pattern.cpp
240

I understand that the converter already assumes the int address space (it shouldn't, we should handle that more gracefully than asserting there, but it's irrelevant for this patch). Here, we should have access to the converted pointer type though, so we could rather extract the integer address space from the LLVM pointer type and avoid propagating the assumption about it being an integer in all memrefs here.

krzysz00 updated this revision to Diff 490899.Jan 20 2023, 9:52 AM
krzysz00 edited the summary of this revision. (Show Details)

Swap getMemorySpaceAsInt() for the more general mechanism from the previous patch.

ftynse accepted this revision.Jan 31 2023, 2:57 AM
This revision is now accepted and ready to land.Jan 31 2023, 2:57 AM
krzysz00 updated this revision to Diff 496178.Feb 9 2023, 10:37 AM

Update new test, fix -Wunused-variable from previous patch