trying to create RMW opportunities in the x86 backend. This can cause a
cycle to appear in the graph, since the other uses may eventually feed into
the TokenFactor we are sinking the load below.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81996 91177308-0d34-0410-b5e6-96231b3b80d8
the Intel instruction tables.
The patterns will stay blank because ADD reg, reg
is faster, but having the encoding available is
useful for the disassembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81994 91177308-0d34-0410-b5e6-96231b3b80d8
more than one phi, since that leads to higher register pressure on
entry to the phi. This is especially problematic when the phi is in
a loop header, as it increases register pressure throughout the loop.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81993 91177308-0d34-0410-b5e6-96231b3b80d8
Eliminate the PersonalityPrefix/Suffix & NeedsIndirectEncoding
fields from MAI: they aren't part of the asm syntax, they are
related to the structure of the object file.
To replace their functionality, add a new
TLOF::getSymbolForDwarfGlobalReference method which asks targets
to decide how to reference a global from EH in a pc-relative way.
The default implementation just returns the symbol. The default
darwin implementation references the symbol through an indirect
$non_lazy_ptr stub. The bizarro x86-64 darwin specialization
handles the weird "foo@GOTPCREL+4" hack.
DwarfException.cpp now uses this to emit the reference to the
symbol in the right way, and this also eliminates another
horrible hack from DwarfException.cpp:
- if (strcmp(MAI->getPersonalitySuffix(), "+4@GOTPCREL"))
- O << "-" << MAI->getPCSymbol();
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81991 91177308-0d34-0410-b5e6-96231b3b80d8
All of these do not have patterns (they're for the
disassembler).
Many of the floating-point instructions will probably
be rolled into definitions that have patterns, and may
eventually be superseded by mdefs. So I put them
together and left a comment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81979 91177308-0d34-0410-b5e6-96231b3b80d8
one implementation into its one caller. This eliminates a totally
awesome and gratuitous hack where we casted a Function* to
GlobalVariable*.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81967 91177308-0d34-0410-b5e6-96231b3b80d8
and use PersonalityPrefix/Suffix to achieve the same effect (like
the x86 backend).
This changes the code generated for ppc static mode, but guess what,
we were generating this before:
.byte 0x9B ; Personality (indirect pcrel sdata4)
.long ___gxx_personality_v0-. ; Personality
which is not correct! (it is not an 'indirect' reference).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81965 91177308-0d34-0410-b5e6-96231b3b80d8
Intel tables, where the source operand is
specified by the R/M field and the destination
operand by the Reg field.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81914 91177308-0d34-0410-b5e6-96231b3b80d8
to the Intel register table.
Added 16- and 64-bit MOVs to and from the segment
registers to the Intel instruction tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81895 91177308-0d34-0410-b5e6-96231b3b80d8
interrupt instruction, which shouldn't arise any other way). 0xcd is
also used by JITMemoryManager to initialize the buffer to garbage,
which means it could appear following a noreturn call even when
that is not a stub, confusing X86CompilationCallback2. PR 4929.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81888 91177308-0d34-0410-b5e6-96231b3b80d8
VLDM/VSTM instructions, and without this check, the code assumes that an
offset is allowed, as it would be with VLDR/VSTR. The asm printer,
however, silently drops the offset, producing incorrect code. Since the
address register in this case is either the stack or frame pointer, the
spill location ends up conflicting with some other stack slot or with
outgoing arguments on the stack.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81879 91177308-0d34-0410-b5e6-96231b3b80d8
not folded in the constant folder because the constant folder doesn't
simplify ConstantExpr operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81864 91177308-0d34-0410-b5e6-96231b3b80d8
instead of cloning and RAUWing it.
- Make AbstractTypeUser a friend of Value so that it can offer
its subclasses a way to update a Value's type in place. This
is better than a universally visible setType method on Value,
and it's sufficient for the immediate need.
- Eliminate the constant "convert" functions. This eliminates a
lot of logic duplication, and fixes a complicated bug where a
constant can't actually be cloned during the type refinement
process because some of the types that its folder needs are
half-destroyed, being in the middle of refinement themselves.
- Move the getValType functions from being static overloaded
functions in Constants.cpp to be members of class template
specializations in ConstantsContext.h. This means that the
code ends up getting instantiated twice, however it also
makes it possible to eliminate all "convert" functions, so
it's not a big net code size increase. And if desired, the
duplicate instantiations could be eliminated with some
reorganization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81861 91177308-0d34-0410-b5e6-96231b3b80d8
