A block address may be used in inline assembly. In which case it
requires a name so that the asm parser has something to parse. Creating
a name for every block address is a large hammer, but is necessary
because at the point when a temp symbol is created we don't necessarily
know if it's used in inline asm. This ensures that it exists regardless.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 35705 Build 35704: arc lint + arc unit
Event Timeline
Creating a name for every block address is a large hammer, but is necessary because at the point when a temp symbol is created we don't necessarily know if it's used in inline asm.
Sure we do; in this case if llvm::any_of the Uses of the BasicBlocks isa<CallBrInst> then we need to name the label. Right?
It's not enough to just check that a BB's address is used by a callbr, since
the value doesn't have to be directly used by it. E.g., it could be stored into
memory and then loaded.
test/CodeGen/X86/callbr-asm-obj-file.ll | ||
---|---|---|
2 | When I run this test case locally, I get: $ llc < callbr-asm-obj-file.ll -filetype=obj -mtriple=x86_64-linux-gnu <unknown>:0: error: Undefined temporary symbol Am I holding it wrong? |
test/CodeGen/X86/callbr-asm-obj-file.ll | ||
---|---|---|
2 | Ah, I missed the parent revision relationship between the two patches. Does phabricator UI show this relation anywhere? |
test/CodeGen/X86/callbr-asm-obj-file.ll | ||
---|---|---|
2 | I see it right above my subscription to this revision. void added a parent revision: D65304: [MC] Don't recreate a label if it's already used. |
In the "Revision Contents" box, there's a "Stack" tab. It looks like that's what shows the relationship.
I think the comment in LLVMTargetMachine::addAsmPrinter about // Don't waste memory on names of temp labels. should be amended in this patch to say ... unless it's address is taken or something to that effect.
I'm not sure about that. It might be confusing to people, as we aren't technically wasting memory if the block address is taken. Also, the boolean being set here seems to have slightly different semantics from the change I made.
When I run this test case locally, I get:
Am I holding it wrong?