diff options
author | Aleksandr Popov <42888396+aleks-tmb@users.noreply.github.com> | 2025-08-28 11:03:41 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-08-28 11:03:41 +0200 |
commit | abfe556c46f7c055cacc79f3aa322bb2c05d92f5 (patch) | |
tree | 3e49c594ccd08ca090eec5252a2b46d1aa1f269e /llvm/tools/llvm-lto2/llvm-lto2.cpp | |
parent | 4fc8bffbaafec55a43e50ff5888163aa2cd5c744 (diff) | |
download | llvm-abfe556c46f7c055cacc79f3aa322bb2c05d92f5.zip llvm-abfe556c46f7c055cacc79f3aa322bb2c05d92f5.tar.gz llvm-abfe556c46f7c055cacc79f3aa322bb2c05d92f5.tar.bz2 |
MC: Fix NOP insertion between fused instructions that breaks macro fusion (#155784)
In the
https://github.com/llvm/llvm-project/commit/39c8cfb70d203439e3296dfdfe3d41f1cb2ec551
patch, getOrCreateDataFragment was optimized by eagerly allocating an
empty fragment when adding a fragment with a variable-size tail. This
means that in this case the current MC fragment is no longer the one
where the instruction was inserted, and the check
`PendingBA && PendingBA->getNext() == OS.getCurrentFragment()` fails,
since CurrentFragment is now the empty fragment instead of the fragment
containing the instruction.
`PendingBA -> Fragment with a variable-size tail (contains previous
instruction) -> CurrentFragment (newly allocated empty fragment)`
This breaks the macro-fusion logic because it incorrectly assumes
another fragment has been inserted between the fused instructions.
Fixes https://github.com/llvm/llvm-project/issues/155045
#155316 Reland
Diffstat (limited to 'llvm/tools/llvm-lto2/llvm-lto2.cpp')
0 files changed, 0 insertions, 0 deletions