Insert constants and globals in order by maintaining the position
of the constant and global inserted last. Update the tests
to reflect the updated insertion order. Also make sure functions
are always inserted at the end of the module instead of at
the second last position and delete a spurious function in
the intrinsic.ll that seems to exist to avoid the first
function under test ends up at the end of the module.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp | ||
---|---|---|
433 | Naming nit: this returns a block rather than the insertion point, which is a combination a of a block and an iteration in it. Conceptual nit: by doing this, we will always insert constants in the inverse order of their encounter. This makes the IR surprising to read, but isn't really a functional change. Some ideas for handling it in the future: can't we maintain the Operation * of the last inserted constant and use that to set the insertion point after it? | |
443–446 | Similar as above: can't we just maintain the Operation * of the first function and set the insertion point before it for globals to avoid iterating over the module? |
mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp | ||
---|---|---|
433 | I agree the inverse order is problematic and will try to implement a variant with Operation *. Alternatively, we may also have multiple builders? |
mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp | ||
---|---|---|
433 | We may have multiple builders as long as we carefully propagate their extra state such as listeners, although it may not be a concern right now. IMO just setting the insertion point is simple and more future-proof. |
mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp | ||
---|---|---|
433 | Sounds good! |
Naming nit: this returns a block rather than the insertion point, which is a combination a of a block and an iteration in it.
Conceptual nit: by doing this, we will always insert constants in the inverse order of their encounter. This makes the IR surprising to read, but isn't really a functional change. Some ideas for handling it in the future: can't we maintain the Operation * of the last inserted constant and use that to set the insertion point after it?