This patch brings support for setting runtime preemption specifiers of
LLVM's GlobalValues. In LLVM semantics, if the dso_local attribute
is not explicitly requested, then it is inferred based on linkage and
visibility. We model this same behavior with a UnitAttribute: if it is
present, then we explicitly request the GlobalValue to marked as
dso_local, otherwise we rely on the GlobalValue itself to make this
decision.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
It was recently pointed out on discord that the LLVM dialect lacks the ability to add dso_local specifiers for LLVM::GlobalValues.
However, I'm not sure if I added the attribute in the right position of the constructors; to minimize diff, I added it as the last parameter. Is this ok?
mlir/include/mlir/Dialect/LLVMIR/LLVMOps.td | ||
---|---|---|
1023 | Nit: I'd put this before the list of named attributes, it's an implicit convention we have. Also, I'd rather make the argument type bool. | |
mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp | ||
1278 | If dsoLocal is a unit attribute already, there's no need to call builder.getUnitAttr (which may lock in theory). Here, I suppose dsoLocal should be a bool instead. |
mlir/include/mlir/Dialect/LLVMIR/LLVMOps.td | ||
---|---|---|
1023 | Agreed! I assume I should do the same for LLVMFuncOp, which does increase the diff of this patch a bit. Please have a look again to make sure this is ok | |
mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp | ||
1278 | Oops, that's a mistake on my part. But yeah, given how we're making this a bool, then we'll keep the getUnitAttr call. |
C:\ws\w3\llvm-project\premerge-checks\mlir\lib\ExecutionEngine\CRunnerUtils.cpp(21): fatal error C1083: Cannot open include file: 'alloca.h': No such file or directory
I suspect this is not a related error?
Build was broken today, if you rebase it'll be fixed, but you can ignore it right now.
Nit: I'd put this before the list of named attributes, it's an implicit convention we have.
Also, I'd rather make the argument type bool.