This is an archive of the discontinued LLVM Phabricator instance.

[mlir][llvm] Import pointer data layout specification.
ClosedPublic

Authored by gysit on Mar 29 2023, 9:41 AM.

Details

Summary

The revision moves the data layout parsing into a separate file
and extends it to support pointer data layout specifications.
Additionally, it also produces more precise warnings and error
messages.

Diff Detail

Event Timeline

gysit created this revision.Mar 29 2023, 9:41 AM
Herald added a reviewer: dcaballe. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
gysit requested review of this revision.Mar 29 2023, 9:41 AM
definelicht added inline comments.Mar 30 2023, 12:28 AM
mlir/lib/Target/LLVMIR/DataLayoutImporter.cpp
44

Wouldn't it be useful to have error messages on what failed parsing?

83–88

It would be useful to show examples of alignment strings in a comment to understand why this code looks the way it does

99–107

Again, it would be great with some examples of what this string can look like and why 🙂

140–141
192–193

This should be a constexpr defined somewhere very visible, perhaps even in the header file? Is there a test that would flag if this ever changed?

200
mlir/lib/Target/LLVMIR/DataLayoutImporter.h
42

I dropped some comments. As elaborated in one of the comments, I'm uncertain if it makes sense to add an instance of the DataLayoutImporter to the ModuleImport class and keep it around.

mlir/lib/Target/LLVMIR/DataLayoutImporter.cpp
37

Ultra nit: I would prefer {} here.

44

I guess it's unclear where this error message should be attached to. But I agree, error messages would be nice to have.

46

NIT: Can you not just pass the isalpha function to the take_while or is there some type inference issue?

55

I'm not sure about the coding conventions, but this initialisation is not necessary.

255

Is there a good reason why this function expects a Type instead of just a LLVMPointerType?

267

NIT: Are you sure that key will not be treated like an unused variable by all compilers. I recall some issues related to this, but that might be a false alarm.

269

As above

271

NIT: No need to store this in a local variable.

mlir/lib/Target/LLVMIR/DataLayoutImporter.h
58

Should that really return a copy of the SmallVector? The only usage would work with an ArrayRef<StringRef>

mlir/lib/Target/LLVMIR/ModuleImport.cpp
703

Given that this is the only usage of the dataLayoutImporter outside of the ModuleImport::convertDataLayout, it seems a bit excessive to keep it around over the full lifetime of a ModuleImporter.
This function could still take the context as an argument and be decoupled from the DataLayoutImporter class. In that case, the imported could be allocated on the stack of the ModuleImport::convertDataLayout function.

gysit updated this revision to Diff 509657.Mar 30 2023, 6:54 AM
gysit marked 15 inline comments as done.

Rebase and address comments.

mlir/lib/Target/LLVMIR/DataLayoutImporter.cpp
44

Producing precise error messages is hard since there are many places where parsing may fail. There is also no real error handling infrastructure here. The good thing is the user we get the token that failed parsing (e.g. something like i32:32:32). That should be precise enough especially since this data layout strings are mostly not user facing and we do not expect any parsing errors (produced by LLVM and consumed by MLIR).

192–193

It would be nice to get the string directly from LLVM but I did not find a good way to achieve this since LLVM returns an empty string for the default layout. I added a test that verifies all elements of the default.

Dinistro accepted this revision.Mar 30 2023, 9:24 AM

LGTM module the UB comment.

mlir/lib/Target/LLVMIR/DataLayoutImporter.cpp
112

Careful here ;)

This revision is now accepted and ready to land.Mar 30 2023, 9:24 AM
gysit updated this revision to Diff 509736.Mar 30 2023, 11:10 AM

Improve test.

Dinistro added inline comments.Mar 31 2023, 12:07 AM
mlir/lib/Target/LLVMIR/DataLayoutImporter.cpp
112

NVM, I mixed something up here.

definelicht accepted this revision.Mar 31 2023, 1:06 AM

LGTM modulo nits! It's very nice to have the comments describing possible layouts, it's a big service to anyone who ever needs to look at this again 😉

mlir/lib/Target/LLVMIR/DataLayoutImporter.cpp
103
mlir/lib/Target/LLVMIR/DataLayoutImporter.h
68–71

I would also still be in favor of exposing this publicly, either by making it public or moving it out of the class. God forbid anyone will need it, but it's better than it can be retrieved like this instead of copy-pasting it 😉

gysit updated this revision to Diff 509941.Mar 31 2023, 1:37 AM
gysit marked an inline comment as done.

Address comments.

gysit updated this revision to Diff 509943.Mar 31 2023, 1:46 AM

Address last comment.

gysit added inline comments.Mar 31 2023, 1:50 AM
mlir/lib/Target/LLVMIR/DataLayoutImporter.h
68–71

I prefer keeping it private for now since I do not want others to use it. Instead users should query the imported data layout. We may still change this in the future if there happens to be a use case.

gysit updated this revision to Diff 509947.Mar 31 2023, 2:28 AM

Move the string constant to the cpp.

This revision was automatically updated to reflect the committed changes.