| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 221798
|
| |
|
|
| |
llvm-svn: 221797
|
| |
|
|
|
|
| |
in -funknown-anytype mode (in lldb use).
llvm-svn: 221796
|
| |
|
|
|
|
|
| |
Returning more information will allow BitstreamReader to be simplified a bit
and changed to read 64 bits at a time.
llvm-svn: 221794
|
| |
|
|
|
|
|
| |
This change actually wasn't warranted for -O0, and the new changes prove it and
break the build.
llvm-svn: 221793
|
| |
|
|
|
|
|
| |
I seem to have missed the update I made for changing 'flag_pic' to "PIC Level".
Mea culpa.
llvm-svn: 221792
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Large-model was added first. With the addition of support for multiple PIC
models in LLVM, now add small-model PIC for 32-bit PowerPC, SysV4 ABI. This
generates more optimal code, for shared libraries with less than about 16380
data objects.
Test Plan: Test cases added or updated
Reviewers: joerg, hfinkel
Reviewed By: hfinkel
Subscribers: jholewinski, mcrosier, emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D5399
llvm-svn: 221791
|
| |
|
|
|
|
|
|
|
|
|
| |
The addition of RegisterNumber introduced a bug where if the PC is stored in a
return address register, such as on ARM and PowerPC, this register number is
retrieved and used, but never checked in the row if it's saved. Correct this by
setting the variable that's used to the new register number.
Patch by Jason Molenda.
llvm-svn: 221790
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Taking advantage of the new 'CFAIsRegisterDereferenced' CFA register type, add
full stack unwind support to the PowerPC/PowerPC64 ABI. Also, add a new
register set for powerpc32-on-64, so the register sizes are correct. This also
requires modifying the ProcessMonitor to add support for non-uintptr_t-sized
register values.
Reviewers: jasonmolenda, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6183
llvm-svn: 221789
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
PowerPC handles the stack chain with the current stack pointer being a pointer
to the backchain (CFA). LLDB currently has no way of handling this, so this
adds a "CFA is dereferenced from a register" type.
Discussed with Jason Molenda, who also provided the initial patch for this.
Reviewers: jasonmolenda
Reviewed By: jasonmolenda
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6182
llvm-svn: 221788
|
| |
|
|
|
|
| |
Reviewed by Ed Maste at MeetBSD.
llvm-svn: 221787
|
| |
|
|
| |
llvm-svn: 221786
|
| |
|
|
| |
llvm-svn: 221785
|
| |
|
|
| |
llvm-svn: 221784
|
| |
|
|
|
|
| |
It was broken since r221708.
llvm-svn: 221783
|
| |
|
|
| |
llvm-svn: 221782
|
| |
|
|
| |
llvm-svn: 221781
|
| |
|
|
|
|
|
|
| |
microMIPS instructions
Differential Revision: http://reviews.llvm.org/D6198
llvm-svn: 221780
|
| |
|
|
|
|
|
|
| |
cases from Halide folks. This initial step was extracted from
a prototype change by Clay Wood to try and address regressions found
with Halide and the new vector shuffle lowering.
llvm-svn: 221779
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This test case is blatantly x86-specific, so skip it on other targets.
Reviewers: kcc, eugenis, earthdok, samsonov
Reviewed By: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6216
llvm-svn: 221778
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Address sanitization of ptrace(2) is only implemented for x86, so skip
the test on other targets.
Reviewers: kcc, eugenis, earthdok, samsonov
Reviewed By: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6215
llvm-svn: 221777
|
| |
|
|
|
|
|
| |
removes windows line endings and other noise. This is in prelude to
making substantive changes to these tests.
llvm-svn: 221776
|
| |
|
|
|
|
| |
removed in r221751. [-Wdocumentation]
llvm-svn: 221775
|
| |
|
|
|
|
|
|
|
| |
3 instructions: vrcp28, vrsqrt28, vexp2, only vector forms.
Intrinsics include SAE (Suppres All Exceptions) parameter.
http://reviews.llvm.org/D6214
llvm-svn: 221774
|
| |
|
|
| |
llvm-svn: 221773
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
IndVarSimplify should not widen an indvar if arithmetics on the wider
indvar are more expensive than those on the narrower indvar. For
instance, although NVPTX64 treats i64 as a legal type, an ADD on i64 is
twice as expensive as that on i32, because the hardware needs to
simulate a 64-bit integer using two 32-bit integers.
Split from D6188, and based on D6195 which adds NVPTXTargetTransformInfo.
Fixes PR21148.
Test Plan:
Added @indvar_32_bit that verifies we do not widen an indvar if the arithmetics
on the wider type are more expensive.
Reviewers: jholewinski, eliben, meheff, atrick
Reviewed By: atrick
Subscribers: jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D6196
llvm-svn: 221772
|
| |
|
|
|
|
| |
Fixes PR21221. Patch by Axel Naumann, test by me.
llvm-svn: 221771
|
| |
|
|
| |
llvm-svn: 221770
|
| |
|
|
| |
llvm-svn: 221769
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enables the vec_vsx_ld and vec_vsx_st intrinsics for
PowerPC, which provide programmer access to the lxvd2x, lxvw4x,
stxvd2x, and stxvw4x instructions.
New code in altivec.h defines these in terms of new builtins, which
are themselves defined in BuiltinsPPC.def. The builtins are converted
to LLVM intrinsics in CGBuiltin.cpp. Additional code is added to
builtins-ppc-vsx.c to verify the correct generation of the intrinsics.
Note that I moved the other VSX builtins so all VSX builtins will be
alphabetical in their own section in BuiltinsPPC.def.
There is a companion patch for LLVM.
llvm-svn: 221768
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enables the vec_vsx_ld and vec_vsx_st intrinsics for
PowerPC, which provide programmer access to the lxvd2x, lxvw4x,
stxvd2x, and stxvw4x instructions.
New LLVM intrinsics are provided to represent these four instructions
in IntrinsicsPowerPC.td. These are patterned after the similar
intrinsics for lvx and stvx (Altivec). In PPCInstrVSX.td, these
intrinsics are tied to the code gen patterns, with additional patterns
to allow plain vanilla loads and stores to still generate these
instructions.
At -O1 and higher the intrinsics are immediately converted to loads
and stores in InstCombineCalls.cpp. This will open up more
optimization opportunities while still allowing the correct
instructions to be generated. (Similar code exists for aligned
Altivec loads and stores.)
The new intrinsics are added to the code that checks for consecutive
loads and stores in PPCISelLowering.cpp, as well as to
PPCTargetLowering::getTgtMemIntrinsic().
There's a new test to verify the correct instructions are generated.
The loads and stores tend to be reordered, so the test just counts
their number. It runs at -O2, as it's not very effective to test this
at -O0, when many unnecessary loads and stores are generated.
I ended up having to modify vsx-fma-m.ll. It turns out this test case
is slightly unreliable, but I don't know a good way to prevent
problems with it. The xvmaddmdp instructions read and write the same
register, which is one of the multiplicands. Commutativity allows
either to be chosen. If the FMAs are reordered differently than
expected by the test, the register assignment can be different as a
result. Hopefully this doesn't change often.
There is a companion patch for Clang.
llvm-svn: 221767
|
| |
|
|
|
|
|
|
|
| |
Every MemoryObject is a StreamableMemoryObject since the removal of
StringRefMemoryObject, so just merge the two.
I will clean up the MemoryObject interface in the upcoming commits.
llvm-svn: 221766
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this, -Wunused-local-typedef would incorrectly warn on the two typedefs
in this program:
void foo() {
struct A {};
struct B : public A {
typedef A INHERITED;
B() : INHERITED() {}
typedef B SELF;
B(int) : SELF() {}
};
}
llvm-svn: 221765
|
| |
|
|
| |
llvm-svn: 221764
|
| |
|
|
| |
llvm-svn: 221763
|
| |
|
|
| |
llvm-svn: 221762
|
| |
|
|
|
|
|
|
| |
This reverts commit r221756.
David Blaikie pointed out it was unsafe.
llvm-svn: 221761
|
| |
|
|
|
|
|
| |
The problems with the dyld all image infos struct
seems to be specific to arm64.
llvm-svn: 221760
|
| |
|
|
| |
llvm-svn: 221759
|
| |
|
|
| |
llvm-svn: 221758
|
| |
|
|
| |
llvm-svn: 221757
|
| |
|
|
| |
llvm-svn: 221756
|
| |
|
|
| |
llvm-svn: 221755
|
| |
|
|
|
|
| |
workaround took us from wrong-code to ICE.
llvm-svn: 221754
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A subtle bug was found where attempting to copy a non-const function_ref
lvalue would actually invoke the generic forwarding constructor (as it
was a closer match - being T& rather than the const T& of the implicit
copy constructor). In the particular case this lead to a dangling
function_ref member (since it had referenced the function_ref passed by
value to its ctor, rather than the outer function_ref that was still
alive)
SFINAE the converting constructor to not be considered if the copy
constructor is available and demonstrate that this causes the copy to
refer to the original functor, not to the function_ref it was copied
from. (without the code change, the test would fail as Y would be
referencing X and Y() would see the result of the mutation to X, ie: 2)
llvm-svn: 221753
|
| |
|
|
| |
llvm-svn: 221752
|
| |
|
|
|
|
|
|
|
|
|
|
| |
With this patch MCDisassembler::getInstruction takes an ArrayRef<uint8_t>
instead of a MemoryObject.
Even on X86 there is a maximum size an instruction can have. Given
that, it seems way simpler and more efficient to just pass an ArrayRef
to the disassembler instead of a MemoryObject and have it do a virtual
call every time it wants some extra bytes.
llvm-svn: 221751
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
This is a re-commit of r219977:
r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2.
(That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of
'this' within a template.)
r219977 was a re-commit of r217995, r218011, and r218053:
r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC.
(Incorrect overload resolution in the presence of using-declarations.)
It was re-committed in r219977 with a workaround for the MSVC rejects-valid.
r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of
unbraced range-based for loop).
llvm-svn: 221750
|
| |
|
|
|
|
| |
This reverts commit r221073 to match upstream revert in r221711.
llvm-svn: 221749
|
| |
|
|
|
|
|
| |
penultimate parameter of a template parameter list, where the last parameter is
itself a pack, and build a bogus empty final pack argument.
llvm-svn: 221748
|