Wow thanks for the pointer! That seems unfortunate, I wonder if there is a way to evaluate whether the extra jump is actually worth it, and whether this optimization could be allowed.
If I remove the check for `OptForSize` and `PredTBB == MBB`, we can optimize OP's report, but seem to regress basic tests like llvm/test/CodeGen/X86/conditional-tailcall.ll, literally flipping the branches incorrectly IIUC.
Why is that a problem? I'd figure that a short jump is basically free since the target is likely to be in the instruction cache? Is it an issue of readahead/speculation through multiple jumps?
Wow thanks for the pointer! That seems unfortunate, I wonder if there is a way to evaluate whether the extra jump is actually worth it, and whether this optimization could be allowed.
At the very least, can check when the target isn't a basic block and thus it's a clear win. Will fix your case.
I'm dubious about the whole thing though. Seems like it may day from when branching "down" vs. "up" mattered to branch prediction.
It seems that that code handles just the case when target is function.
https://github.com/llvm/llvm-project/blob/535df472b04208d6ae...
commit a468601e0ead ("[X86] Re-enable conditional tail calls and fix PR31257.")
https://reviews.llvm.org/D29856
added the comment.
If I remove the check for `OptForSize` and `PredTBB == MBB`, we can optimize OP's report, but seem to regress basic tests like llvm/test/CodeGen/X86/conditional-tailcall.ll, literally flipping the branches incorrectly IIUC.
Filed: https://bugs.llvm.org/show_bug.cgi?id=50130
Nice find! I wonder what they mean by changing branch direction?
Why is that a problem? I'd figure that a short jump is basically free since the target is likely to be in the instruction cache? Is it an issue of readahead/speculation through multiple jumps?