The default lowering of assert calls abort in case the assertion is
violated. The failure message is ignored but should be used by custom lowerings
that can assume more about their environment.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Conversion/StandardToLLVM/StandardToLLVM.cpp | ||
---|---|---|
1406 | nit: remove the newline here. | |
1429 | nit: Can you use Block instead of auto here and below? | |
1440 | Why not use LLVM::CondBranchOp directly here? | |
1440 | This seems incorrect. I would expect the continuation block to be destination if the condition is true. (The true block is first is cond_br) |
mlir/test/Conversion/StandardToLLVM/standard-to-llvm.mlir | ||
---|---|---|
98 | The targets are switched. |
mlir/lib/Conversion/StandardToLLVM/StandardToLLVM.cpp | ||
---|---|---|
1420 | Mutating the module like this is not allowed. This conversion pattern could be applied inside a function pass which will be running in parallel, and this mutation of the module body will trigger a race condition very easily. It's likely that if you craft a test case that simply has two std.assert ops, each in a different function, you will cause a ThreadSanitizer failure. What is currently being done for creating the malloc/free declarations? |
mlir/lib/Conversion/StandardToLLVM/StandardToLLVM.cpp | ||
---|---|---|
1420 | Or do we have some sort of guarantee that this is running single-threaded on the whole module? |
Thanks for adding this!
mlir/lib/Conversion/StandardToLLVM/StandardToLLVM.cpp | ||
---|---|---|
1420 | I see that we are already doing this kind of "insert into the mdoule from deep inside a conversion pattern" in a number of places. Sigh. I guess we are assuming that these patterns are being applied serially for now :/ Sorry for the noise. |
mlir/lib/Conversion/StandardToLLVM/StandardToLLVM.cpp | ||
---|---|---|
1420 | Conversion to LLVM is a module pass. It replaces standard functions with llvm functions, so it cannot be a function pass anyway. If it becomes a performance issue, we can potentially split it into two parts: rewrite functions serially, then rewrite function bodies in parallel. This will need some infrastructural support to work around type mismatches (many patterns rely on knowing the original type) and to avoid splitting this into two passes. |
nit: remove the newline here.