(yet) recognize the 'trap' mnemonic, so we use .short/.long to emit the
opcode directly. On Darwin, however, we do want the mnemonic for more
readable assembly code and better disassembly.
Adjust the .td file to use the 'trap' mnemonic and handle using the binutils
workaround in the assembly printer. Also tweak the formatting of the opcode
values to make them consistent between the MC printer and the old printer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114679 91177308-0d34-0410-b5e6-96231b3b80d8
they are in. Both ways should be equivalent, but gas produces relocations
against the section.
Roman wrote the patch, I added the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114667 91177308-0d34-0410-b5e6-96231b3b80d8
"external" even when doing lazy bitcode loading. This was broken because
a function that is not materialized fails the !isDeclaration() test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114666 91177308-0d34-0410-b5e6-96231b3b80d8
when the unconditional branch destination is the fallthrough block. The
canonicalization makes it easier to allow optimizations on DAGs to invert
conditional branches. The branch folding pass (and AnalyzeBranch) will clean up
the unnecessary unconditional branches later.
This is one of the patches leading up to disabling codegen prepare critical edge
splitting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114630 91177308-0d34-0410-b5e6-96231b3b80d8
Allocator instances can now be created by calling createPBQPRegisterAllocator.
Tidied up use of CoalescerPair as per Jakob's suggestions.
Made the new PBQPBuilder based construction process the default. The internal construction process
remains in-place and available via -pbqp-builder=false for now. It will be removed shortly if the new
process doesn't cause any regressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114626 91177308-0d34-0410-b5e6-96231b3b80d8
new VariantKind to the MCSymbolExpr seems like overkill, but I'm not sure
there's a more straightforward way to get the printing difference captured.
(i.e., x86 uses @PLT, ARM uses (PLT)).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114613 91177308-0d34-0410-b5e6-96231b3b80d8
CombineTo to avoid putting the result on the worklist. I don't think it makes
much difference for now, but it might help someday as we add more DAG
combine optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114595 91177308-0d34-0410-b5e6-96231b3b80d8
of those. Refactor to share code for handling BUILD_VECTOR(VMOVRRD).
I don't have a testcase that exercises this, but it seems like an obvious
good thing to do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114589 91177308-0d34-0410-b5e6-96231b3b80d8
truncates are free only in the case where the extended type is legal but the
load type is not. If both types are illegal, such as when they are too big,
the load may not be legalized into an extended load.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114568 91177308-0d34-0410-b5e6-96231b3b80d8
end up altering the thread on which crashes are done because of its use of
Darwin's broken raise() implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114558 91177308-0d34-0410-b5e6-96231b3b80d8
ARM cross-compiler on x86, because the MMO size did not match the type size.
This fixes the MMO size and also the size of the stack object to match the
type size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114554 91177308-0d34-0410-b5e6-96231b3b80d8
x86-32: 32-bit calls were named "call" not "calll". 64-bit calls were correctly
named "callq", so this only impacted x86-32.
This fixes rdar://8456370 - llvm-mc rejects 'calll'
This also exposes that mingw/64 is generating a 32-bit call instead of a 64-bit call,
I will file a bugzilla.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114534 91177308-0d34-0410-b5e6-96231b3b80d8
