to LLVM IR changes with addr label weirdness. In the testcase, we
generate references to the two bb's when codegen'ing the first
function:
_test1: ## @test1
leaq Ltmp0(%rip), %rax
..
leaq Ltmp1(%rip), %rax
Then continue to codegen the second function where the blocks
get merged. We're now smart enough to emit both labels, producing
this code:
_test_fun: ## @test_fun
## BB#0: ## %entry
Ltmp1: ## Block address taken
Ltmp0:
## BB#1: ## %ret
movl $-1, %eax
ret
Rejoice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98595 91177308-0d34-0410-b5e6-96231b3b80d8
- Although it would be nice to allow this decoupling, the assembler needs to be able to reason about MCSymbolRefExprs in too many places to make this viable. We can use a target specific encoding of the variant if this becomes an issue.
- This patch also extends llvm-mc to support parsing of the modifiers, as opposed to lumping them in with the symbol.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98592 91177308-0d34-0410-b5e6-96231b3b80d8
label is generated, but then the block is deleted. Since the
value is undefined, we just emit the label right after the entry
label of the function. It might matter that the label is in the
same section as the function was afterall.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98579 91177308-0d34-0410-b5e6-96231b3b80d8
function, then the BB is RAUW'd before the definition is emitted. There
are still two cases not being handled, but this should improve us back to
the situation before I touched anything.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98566 91177308-0d34-0410-b5e6-96231b3b80d8
allocated and thus not freed. This is cool except that it contains
and std::string so the string data didn't get freed. In any case
there is no reason to redundantly store the string data in the
MCSymbol anyway, just make the MCSymbol ref the string data in the
MCContext StringMap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98536 91177308-0d34-0410-b5e6-96231b3b80d8
label instead of trying to form one based on the BB name (which
causes collisions if the name is empty). This fixes PR6608
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98495 91177308-0d34-0410-b5e6-96231b3b80d8
an MCSymbol. Make the EH_LABEL MachineInstr hold its label
with an MCSymbol instead of ID. Fix a bug in MMI.cpp which
would return labels named "Label4" instead of "label4".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98463 91177308-0d34-0410-b5e6-96231b3b80d8
instead of label ID's. This cleans up and regularizes a bunch
of code and makes way for future progress.
Unfortunately, this pointed out to me that JITDwarfEmitter.cpp
is largely copy and paste from DwarfException/MachineModuleInfo
and other places. This is very sad and disturbing. :(
One major change here is that TidyLandingPads moved from being
called in DwarfException::BeginFunction to being called in
DwarfException::EndFunction. There should not be any
functionality change from doing this, but I'm not an EH expert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98459 91177308-0d34-0410-b5e6-96231b3b80d8
and passing off ownership to AsmPrinter. Now MachineModuleInfo
creates it and owns it by value. This allows us to use MCSymbols
more consistently throughout the rest of the code generator, and
simplifies a bit of code. This also allows MachineFunction to
keep an MCContext reference handy, and cleans up the TargetRegistry
interfaces for AsmPrinters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98450 91177308-0d34-0410-b5e6-96231b3b80d8
Tested: clang debug bootstrap, llvm-gcc bootstrap, `make check-lit`
after configuring with --with-llvmgccdir (and this did run the
FrontendC* tests this time)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98410 91177308-0d34-0410-b5e6-96231b3b80d8
- The implementation is currently very brain dead and inefficient, but I have a
clear plan on how to fix it.
- The good news is, it works and correctly assembles 403.gcc (when built with
Clang, at '-Os', '-Os -g', and '-O3'). Even better, at '-Os' and '-Os -g',
the resulting binary is exactly equivalent to that when built with the system
assembler. So it probably works! :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98396 91177308-0d34-0410-b5e6-96231b3b80d8
