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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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. |
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. |
LGTM module the UB comment.
mlir/lib/Target/LLVMIR/DataLayoutImporter.cpp | ||
---|---|---|
112 | Careful here ;) |
mlir/lib/Target/LLVMIR/DataLayoutImporter.cpp | ||
---|---|---|
112 | NVM, I mixed something up here. |
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 😉 |
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. |