[PATCH] D75306: [ms] [llvm-ml] Add initial MASM STRUCT/UNION support

Eric Astor via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 22 08:06:14 PDT 2020


epastor marked an inline comment as done.
epastor added inline comments.


================
Comment at: llvm/lib/MC/MCParser/MasmParser.cpp:167
+  FieldType FT;
+  union {
+    IntFieldInfo IntInfo;
----------------
rnk wrote:
> I think this union is creating a fair amount of code complexity. The more clang-y code pattern would be to do something like:
> - Use a BumpPtrAllocator for memory allocation to make these all owned by the asm parser, there should be one already somewhere
> - Use raw pointers to point between these classes, avoids need for unique_ptr or other ownership management
> - Set up the usual class hierarchy:
>     class FieldInitializer { FieldType FT; ... };
>     class IntFieldInit : public FieldInitializer { ... };
>     class RealFieldInit : public FieldInitializer { ... };
>     class StructFieldInit : public FieldInitializer { ... };
> 
> Then the parseFieldInitializer variants could return a nullable pointer to indicate parsing success or failure. WDYT?
> 
> The drawback of this approach is that objects in BumpPtrAllocators are not destroyed, so they cannot own external resources. Most vectors can just become ArrayRefs pointing to arrays in the same allocator. The main thing I see that this would affect is the StringMap for fields and APInt for int fields. So, I guess I'm not sure it's worth a big rewrite, but it's something to consider.
I agree it would might be worth the change - but the rewrite looks to be pretty big, and complicated due to several of the members in these objects. Let's move forward in a full review for now, and discuss the right answer as we go.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75306/new/

https://reviews.llvm.org/D75306





More information about the llvm-commits mailing list