If the incoming block to a phi node is an EH pad, then we will materialize into an EH pad, which is not supposed to happen. To fix this, I added a check to see if incoming block of a phi node is an EH pad before using it as the insertion point.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This bug is causing Edge builds to fail when using new builds of Clang, so I would appreciate if someone could please take a look.
Also, CI failures look unrelated to this change and I was not able to repro them if I rebase change onto latest main.
This needs a test case. See llvm/test/Transforms/ConstantHoisting for existing tests for this pass.
Out of curiosity, have you bisected this to a particular change?
llvm/lib/Transforms/Scalar/ConstantHoisting.cpp | ||
---|---|---|
190 | Are you sure you meant to shadow the outer variable here? InsertionBlock will be null in the case you are trying to handle, a phi, preceded by a catchswitch, and I'm not sure what DT->getNode(nullptr) returns. |
I haven't. It was crashing LTO build so repro was time consuming. I was trying to find recent changes that might have allowed more hoisting to happen, but there wasn't anything obvious to me. We took a compiler drop around 11/25 and then the next one we took on 1/3 was failing.
llvm/lib/Transforms/Scalar/ConstantHoisting.cpp | ||
---|---|---|
190 | Good catch, thanks! I originally just copy/pasted the EH loop when I was testing and must have introduced that bug when I refactored. |
I'm working on a test case, but my repro was massive, and hand writing the IR for this is a bit tricky.
Looks like my new test is passing in CI, but Debian CI is failing for some unrelated reason.
Are you sure you meant to shadow the outer variable here? InsertionBlock will be null in the case you are trying to handle, a phi, preceded by a catchswitch, and I'm not sure what DT->getNode(nullptr) returns.