This is an archive of the discontinued LLVM Phabricator instance.

[mlir][llvm] Type consistency transformations
ClosedPublic

Authored by Moxinilian on Jun 28 2023, 6:59 AM.

Details

Summary

This revision introduces new rewrites to improve the type consistency of
a program expressed in the LLVM dialect.

Type consistency means that a given opaque pointer is consistently used
assuming the same pointee type, in a best effort basis. The introduced
rewrites modify the program to improve type consistency while preserving
the same semantics. This is useful for two main reasons:

  • Transformation passes in the LLVM dialect like SROA or Mem2Reg can analyse code better if type information and structure is used in a consistent manner. Opaque pointers make this difficult to enforce, but type consistency improvements increase the amount of occurences where reasonable analysis can pick up on transformable patterns.
  • While LLVM IR is not particularly picky about inconsistent type uses, it may be of interest to lift LLVM IR into higher level dialects. Having more instances of consistent type information would help lifting into dialects that do care about consistent types.

In order to detect cases of inconsistent uses, operations returning an
LLVMPointer can implement the GetResultPtrElementType interface, which
allows getting a hint of which type the provided pointer should see its
pointee as, if such hint is available. The provided rewrites will then
use this hint to attempt to modify operations using the pointers so they
use the hinted type when dealing with the pointer.

Two transformations have been implemented in this revision:

  • When a load/store uses a struct ptr directly to write to the first element of the struct, introduce a GEP to the first element so the type structure is preserved.
  • When a GEP statically indexes in a pointer with a base type inconsistent with the hint, try to find indices using the hint as a base type that would result in the same offset, and replace the GEP with this indexing.

More transformations are possible and I hope this is only a beginning
for this simplification effort.

Diff Detail

Event Timeline

Moxinilian created this revision.Jun 28 2023, 6:59 AM
Herald added a reviewer: dcaballe. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
Moxinilian requested review of this revision.Jun 28 2023, 6:59 AM
Moxinilian edited the summary of this revision. (Show Details)

Fix formatting.

gysit added inline comments.Jun 28 2023, 9:49 AM
mlir/include/mlir/Dialect/LLVMIR/LLVMInterfaces.td
173–174

Soon there will hopefully only be opaque pointers!

189

As this is an LLVM interface we may not need the result number. An LLVM operation can only have zero or one result. If it has multiple results they need to be packed into a struct which we don't want to support I guess.

mlir/include/mlir/Dialect/LLVMIR/Transforms/TypeConsistency.h
33–34
mlir/lib/Dialect/LLVMIR/Transforms/TypeConsistency.cpp
22

nit: Can you do a pass over the includes some like sys/types.h definitely seem unnecessary.

67

nit: since there is an indexType in mlir maybe rename to subelementType?

72–75

Is this second attempt needed? It seems both structs and arrays expect a i32 index?

98

I suspect this should get the element type in the typed pointer case.

Can we bail out earlier and not handle the typed pointer case?

102

I think you should be able to do:

getAddrMutable().assign(properPtr)
117

Should't there be a check here that the first subelement type matches the inconsistent element type? Only in that case the rewrite seems beneficial?

140–142

maybe factor out a static helper method that is called areCastCompatible?

149–152
159

nit: As above getValueMutable().assign() may work.

175

nit: let's use uint64_t or size_t consistently.

242

I probably need an online explanation of this tomorrow. I would have expected that the alignment needs to relative the base address?

294

nit: I hope typed pointers will be gone :). Also I think it is fine to simplify and only support the opaque pointer case!

Moxinilian marked 15 inline comments as done.
Moxinilian edited the summary of this revision. (Show Details)

Address comments + fix bugs + add bitcast in direct struct load.

Moxinilian edited the summary of this revision. (Show Details)

Improve revision message.

Mark comments as done.

gysit accepted this revision.Jun 29 2023, 6:51 AM

Nice Thanks!

LGTM!

mlir/lib/Dialect/LLVMIR/Transforms/TypeConsistency.cpp
291

ultra nit: here we end up if a scalar element in a struct or array is read at an offset? If yes it may make sense to put a short comment that says that can happen if the access to a leaf type is not perfectly aligned. Also maybe add a TODO that we may want to support vector types?

This revision is now accepted and ready to land.Jun 29 2023, 6:51 AM

Address comment.

This revision was automatically updated to reflect the committed changes.