Summary:
.bss, .text, and .data are at least 16-byte aligned.
.reginfo is 4-byte aligned and has a 24-byte EntrySize.
.MIPS.abiflags has an 24-byte EntrySize.
.MIPS.options is 8-byte aligned and has 1-byte EntrySize.
Using a 1-byte EntrySize for .MIPS.options seems strange because the
records are neither 1-byte long nor fixed-length but this matches the value
that GAS emits.
Differential Revision: http://reviews.llvm.org/D4487
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212939 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is because the FP64A the hardware will redirect 32-bit reads/writes
from/to odd-numbered registers to the upper 32-bits of the corresponding
even register. In effect, simulating FR=0 mode when FR=0 mode is not
available.
Unfortunately, we have to make the decision to avoid mfc1/mtc1 before
register allocation so we currently do this for even registers too.
FPXX has a similar requirement on 32-bit architectures that lack
mfhc1/mthc1 so this patch also handles the affected moves from the FPU for
FPXX too. Moves to the FPU were supported by an earlier commit.
Differential Revision: http://reviews.llvm.org/D4484
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212938 91177308-0d34-0410-b5e6-96231b3b80d8
Sufficiently twisted use of TableGen lets us write patterns directly for f16
(as an i16 promoted to i32) -> f32 conversion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212933 91177308-0d34-0410-b5e6-96231b3b80d8
enabled and mthc1 and dmtc1 are not available (e.g. on MIPS32r1)
This prevents the upper 32-bits of a double precision value from being moved to
the FPU with mtc1 to an odd-numbered FPU register. This is necessary to ensure
that the code generated executes correctly regardless of the current FPU mode.
MIPS32r2 and above continues to use mtc1/mthc1, while MIPS-IV and above continue
to use dmtc1.
Differential Revision: http://reviews.llvm.org/D4465
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212930 91177308-0d34-0410-b5e6-96231b3b80d8
This crash was pretty common while compiling Rust for iOS (armv7). Reason -
SjLj preparation step was lowering aggregate arguments as ExtractValue +
InsertValue. ExtractValue has assertion which checks that there is some data in
value, which is not true in case of empty (no fields) structures. Rust uses
them quite extensively so this patch uses a 'select true, %val, undef'
instruction to lower the argument.
Patch by Valerii Hiora.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212922 91177308-0d34-0410-b5e6-96231b3b80d8
Verify that DAGCombiner does not crash when trying to fold a pair of shuffles
according to rule (added at r212539):
(shuffle (shuffle A, Undef, M0), Undef, M1) -> (shuffle A, Undef, M2)
The DAGCombiner avoids folding shuffles if the resulting shuffle dag node
is not legal for the target. That means, the resulting shuffle must have
legal type and legal mask.
Before, the DAGCombiner only called method
'TargetLowering::isShuffleMaskLegal' to check if it was "safe" to fold according
to the above-mentioned rule. However, this caused a crash in the x86 backend
since method 'isShuffleMaskLegal' always expects to be called on a
legal vector type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212915 91177308-0d34-0410-b5e6-96231b3b80d8
This is the first of a number of changes designed to generalise
MCWin64EHInstruction to support different target architectures. An ordered set
(vector) of these instructions is saved per frame to permit the emission of
information for Windows NT style unwinding. The only bit of information which
is actually target specific here is the Opcode for the unwinding bytecode. The
remainder of the information is simply generic information that is relevant to
the Windows NT unwinding model.
Remove the accessors for the fields, making them const and public instead. Sink
the knowledge of the alias'ed name into the single source and sink a single-use
check method into the use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212914 91177308-0d34-0410-b5e6-96231b3b80d8
Rename member variables and functions for the MCStreamer for DWARF-like
unwinding management. Rename the Windows ones as well and make the naming and
handling similar across the two. No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212912 91177308-0d34-0410-b5e6-96231b3b80d8
Our verifier check for checking if a global has local linkage was too
strict. Forbid private linkage but permit local linkage.
Object file formats permit this and forbidding it prevents elimination
of unused, internal, vftables under the MSVC ABI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212900 91177308-0d34-0410-b5e6-96231b3b80d8
MC was aping a binutils bug where aliases would default their linkage to
private instead of internal.
I've sent a patch to the binutils maintainers and they've recently
applied it to the GNU assembler sources.
This fixes PR20152.
Differential Revision: http://reviews.llvm.org/D4395
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212899 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a llvm.aarch64.hint intrinsic to mirror the llvm.arm.hint in order to
support the various hint intrinsic functions in the ACLE.
Add an optional pattern field that permits the subclass to specify the pattern
that matches the selection. The intrinsic pattern is set as mayLoad, mayStore,
so overload the value for the definition of the hint instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212883 91177308-0d34-0410-b5e6-96231b3b80d8
Due to the fact that the windows unwinding has the concept of chained frames, we
maintain a current frame info pointer that is adjusted on any push and pop of a
unwinding context. This just removes an unnecessary variable that was used to
mirror the DWARF unwinding code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212882 91177308-0d34-0410-b5e6-96231b3b80d8
This structure contains information related to the call frame used to generate
unwinding information. Rename this to reflect the future use to represent the
shared state between various architectures for WinCFI information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212881 91177308-0d34-0410-b5e6-96231b3b80d8
not properly handle the case where the predecessor block was the entry block to
the function. The only in-tree client of this is JumpThreading, which worked
around the issue in its own code. This patch moves the solution into the helper
so that JumpThreading (and other clients) do not have to replicate the same fix
everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212875 91177308-0d34-0410-b5e6-96231b3b80d8
Currently ASan instrumentation pass creates a string with global name
for each instrumented global (to include global names in the error report). Global
name is already mangled at this point, and we may not be able to demangle it
at runtime (e.g. there is no __cxa_demangle on Android).
Instead, create a string with fully qualified global name in Clang, and pass it
to ASan instrumentation pass in llvm.asan.globals metadata. If there is no metadata
for some global, ASan will use the original algorithm.
This fixes https://code.google.com/p/address-sanitizer/issues/detail?id=264.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212872 91177308-0d34-0410-b5e6-96231b3b80d8
Implementation is small now -- the interesting logic was moved to
`BranchProbability` a while ago. Move it into `bfi_detail` and get rid
of the related TODOs.
I was originally planning to define it within `BlockFrequencyInfoImpl`
(or `BFIIBase`), but it seems cleaner in a namespace. Besides,
`isPodLike` needs to be specialized before `BlockMass` can be used in
some of the other data structures, and there isn't a clear way to do
that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212866 91177308-0d34-0410-b5e6-96231b3b80d8
Test cases to follow once RuntimeDyldChecker supports introspection of stubs.
Fixes <rdar://problem/17648000>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212859 91177308-0d34-0410-b5e6-96231b3b80d8
This implements the target-independent lowering for the patchpoint
intrinsic. Targets have to implement the FastLowerCall
hook to support this intrinsic.
Related to <rdar://problem/17427052>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212849 91177308-0d34-0410-b5e6-96231b3b80d8
The infrastructure mimics the call lowering we have already in place for
SelectionDAG, but with limitations. For example structure return demotion and
non-simple types are not supported (yet).
Currently every backend has its own implementation and duplicated code for call
lowering. There is also no specified interface that could be called from
target-independent code. The target-hook is opt-in and doesn't affect current
implementations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212848 91177308-0d34-0410-b5e6-96231b3b80d8
Break out the arguemnts required from SelectionDAG, so that this function can
also be used by FastISel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212844 91177308-0d34-0410-b5e6-96231b3b80d8
Create a separate helper function for target-independent intrinsic lowering. Also
add an target-hook that allows to directly call into a target-sepcific intrinsic
lowering method. Currently the implementation is opt-in and doesn't affect
existing target implementations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212843 91177308-0d34-0410-b5e6-96231b3b80d8
The memcpy() and overlap helps didn't help much with timings, so clean up the change.
The difference at this point is that we now leave growth of the storage buffer
up to SmallVector's implementation:
- OS.reserve(OS.capacity() * 2);
+ OS.reserve(OS.size() + 64);
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212837 91177308-0d34-0410-b5e6-96231b3b80d8
These two routines didn't take a "const MCSymbolData &SD"
like the other MCELF::Get routines for some reason ...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212834 91177308-0d34-0410-b5e6-96231b3b80d8
This commit fixes a bug in PPCRegisterInfo::isFrameOffsetLegal that
could result in the LocalStackAlloc pass creating an MI instruction
out-of-range displacement:
%vreg17<def> = LD 33184, %vreg31; mem:LD8[%g](align=32)
%G8RC:%vreg17 G8RC_and_G8RC_NOX0:%vreg31
(In final assembler output the top bits are stripped off, resulting
in a negative offset loading from below the stack pointer.)
Common code expects the isFrameOffsetLegal routine to verify whether
adding a given offset to the offset already present in the instruction
results in a valid displacement. However, on PowerPC the routine
did not take the already present instruction offset into account.
This commit fixes isFrameOffsetLegal to add the instruction offset,
and updates a local caller (needsFrameBaseReg) to no longer add the
instruction offset itself before calling isFrameOffsetLegal.
Reviewed by Hal Finkel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212832 91177308-0d34-0410-b5e6-96231b3b80d8
