Reverts commit 1b104388752f66191c867380efde7bbf1f13ca80.
After D130316, this is no longer necessary.
Paths
| Differential D130323
revert "[MC] Don't recreate a label if it's already used" Changes PlannedPublic Authored by nickdesaulniers on Jul 21 2022, 6:17 PM.
Details
Diff Detail
Event TimelineThis revision is now accepted and ready to land.Jul 21 2022, 6:23 PM nickdesaulniers added a child revision: D130391: revert "[CodeGen] Require a name for a block addr target".Jul 22 2022, 12:33 PM Comment Actions
"Inline asm feels wrong." Fixed that for you. :-P Comment Actions Turning on more build targets, either this or https://reviews.llvm.org/D130391 regresses (llvm/test/CodeGen/RISCV/inline-asm-S-constraint.ll). Comment Actions
It's the child patch. This revision is now accepted and ready to land.Aug 17 2022, 11:38 AM Comment Actions
i.e. this one regresses llvm/test/CodeGen/RISCV/inline-asm-S-constraint.ll. I'm going to rebase D130391 to go in first, since that shouldn't be controversial. Let's see. nickdesaulniers removed a child revision: D130391: revert "[CodeGen] Require a name for a block addr target".Aug 17 2022, 11:55 AM Comment Actions I think I've found the issue: AddrLabelMap::getAddrLabelSymbolToEmit uses createNamedTempSymbol() when a BasicBlock has its address taken (i.e. blockaddress), but it doesn't update the symbol table (MCContext's Symbols member), so AsmParser can't find the existing symbol. It looks like in the failing test case llvm/test/CodeGen/RISCV/inline-asm-S-constraint.ll that createSymbol is called with .Ltmp to create the initial BB label, but then later getOrCreateSymbol calls createSymbol for .Ltmp0. It seems like AddrLabelMap::getAddrLabelSymbolToEmit should have just added .Ltmp0 to MCContext's Symbols then and there.
Revision Contents
Diff 446677 llvm/include/llvm/MC/MCContext.h
llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
llvm/lib/MC/MCContext.cpp
llvm/lib/MC/MCParser/AsmParser.cpp
llvm/lib/MC/MCParser/MasmParser.cpp
|