This patch fixes a case that not handled properly.
See bug report: https://llvm.org/bugs/show_bug.cgi?id=25824
Details
- Reviewers
qcolombet
Diff Detail
- Repository
- rL LLVM
Event Timeline
This patch is more of a workaround to fix a bug. It seems to me the conditions of the safe point is not strong enough.
Since it's not SSA, the dominance relationship can't guarantee that the save point is before the def.
Sure. I'm currently reducing the test case. It's exposed by a LTO compilation, so the original function is large. :D
Hi Quentin,
I updated bugzilla with a test reduced from a 150,000 lines of IR. :D
I'm still trying to write a even simpler one with inline asm so we can check into unit test.
Hi Weiming,
Could you try if the attached patch fixes the problem?
If it does, that should be a much safer workaround.
Thanks,
-Quentin
Hi Quentin,
Yes, but I need to change one line because otherwise, it will crash with other inputs.
else ==> else if (MLI->getLoopFor(Restore)) {
// If the loop does not exit, .... SmallVector<...> ExitBlocks;
MLI->getLoopFor(Restore)->getExitingBlocks(ExitBlocks); ==> need to check if Restore is in loop
}
Hi Weiming,
You can abandon this diff, the problem was fixed by r255613.
Thanks for reporting the problem!
Cheers,
-Quentin