| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
different number of elements.
Bitcasts were passing with vectors of pointers with different number of
elements since the number of elements was checking
SrcTy->getVectorNumElements() == SrcTy->getVectorNumElements() which
isn't helpful. The addrspacecast was also wrong, but that case at least
is caught by the verifier. Refactor bitcast and addrspacecast handling
in castIsValid to be more readable and fix this problem.
llvm-svn: 199821
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch restores the ARM mode if the user's inline assembly
does not. In the object streamer, it ensures that instructions
following the inline assembly are encoded correctly and that
correct mapping symbols are emitted. For the asm streamer, it
emits a .arm or .thumb directive.
This patch does not ensure that the inline assembly contains
the ADR instruction to switch modes at runtime.
The problem we need to solve is code like this:
int foo(int a, int b) {
int r = a + b;
asm volatile(
".align 2 \n"
".arm \n"
"add r0,r0,r0 \n"
: : "r"(r));
return r+1;
}
If we compile this function in thumb mode then the inline assembly
will switch to arm mode. We need to make sure that we switch back to
thumb mode after emitting the inline assembly or we will incorrectly
encode the instructions that follow (i.e. the assembly instructions
for return r+1).
Based on patch by David Peixotto
Change-Id: Ib57f6d2d78a22afad5de8693fba6230ff56ba48b
llvm-svn: 199818
|
|
|
|
|
|
| |
Found by -Wdocumentation.
llvm-svn: 199814
|
|
|
|
|
|
|
| |
identify_magic is not free, so we should avoid calling it twice. The argument
also makes it cheap for createBinary to just forward to createObjectFile.
llvm-svn: 199813
|
|
|
|
| |
llvm-svn: 199812
|
|
|
|
| |
llvm-svn: 199811
|
|
|
|
| |
llvm-svn: 199810
|
|
|
|
| |
llvm-svn: 199809
|
|
|
|
| |
llvm-svn: 199808
|
|
|
|
| |
llvm-svn: 199807
|
|
|
|
| |
llvm-svn: 199806
|
|
|
|
| |
llvm-svn: 199805
|
|
|
|
| |
llvm-svn: 199804
|
|
|
|
| |
llvm-svn: 199803
|
|
|
|
| |
llvm-svn: 199801
|
|
|
|
|
|
| |
because vector compare instruction puts result in mask register.
llvm-svn: 199798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
will remove plain COPYs using eraseFromParent(), but if the COPY has imp-defs/imp-uses it will convert it to a KILL, to keep the imp-def around.
This actually totally breaks and causes the machine verifier to cry in several cases, one of which being:
%RAX<def> = COPY %RCX<kill>
%ECX<def> = COPY %EAX<kill>, %RAX<imp-use,kill>
These subregister copies are together identified as noops, so are both removed. However, the second one as it has an imp-use gets converted into a kill:
%ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill>
As the original COPY has been removed, the verifier goes into tears at the use of undefined EAX and RAX.
There are several hacky solutions to this hacky problem (which is all to do with imp-use/def weirdnesses), but the least hacky I've come up with is to *always* remove COPYs by converting to KILLs. KILLs are no-ops to the code generator so the generated code doesn't change (which is why they were partially used in the first place), but using them also keeps the def/use and imp-def/imp-use chains alive:
%RAX<def> = KILL %RCX<kill>
%ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill>
The patch passes all test cases including the ones that check the removal of MOVs in this circumstance, along with an extra test I added to check subregister behaviour (which made the machine verifier fall over before my patch).
The patch also adds some DEBUG() statements because the file hadn't got any.
llvm-svn: 199797
|
|
|
|
|
|
| |
SHUFFLE_VECTOR.
llvm-svn: 199791
|
|
|
|
| |
llvm-svn: 199788
|
|
|
|
|
|
| |
by their aliases.
llvm-svn: 199786
|
|
|
|
| |
llvm-svn: 199784
|
|
|
|
| |
llvm-svn: 199781
|
|
|
|
| |
llvm-svn: 199776
|
|
|
|
|
|
|
|
| |
absolute code.
Fixes PR#18521
llvm-svn: 199775
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inconsistent results for different orderings of alloca slices. The
fundamental issue is that it is just always a mistake to return early
from this function. There is no effective early exit to leverage. This
patch stops trynig to do so and simplifies the code a bit as
a consequence.
Original diagnosis and patch by James Molloy with some name tweaks by me
in part reflecting feedback from Duncan Smith on the mailing list.
llvm-svn: 199771
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The constructors of classes deriving from Binary normally take an error_code
as an argument to the constructor. My original intent was to change them
to have a trivial constructor and move the initial parsing logic to a static
method returning an ErrorOr. I changed my mind because:
* A constructor with an error_code out parameter is extremely convenient from
the implementation side. We can incrementally construct the object and give
up when we find an error.
* It is very efficient when constructing on the stack or when there is no
error. The only inefficient case is where heap allocating and an error is
found (we have to free the memory).
The result is that this is a much smaller patch. It just standardizes the
create* helpers to return an ErrorOr.
Almost no functionality change: The only difference is that this found that
we were trying to read past the end of COFF import library but ignoring the
error.
llvm-svn: 199770
|
|
|
|
|
|
|
|
|
| |
Fix a crash in SjLjEHPrepare::lowerIncomingArguments caused by treating
VectorType like an aggregate. It's first-class!
<rdar://problem/15854596>
llvm-svn: 199768
|
|
|
|
|
|
|
| |
Generalized the heuristic that looks at the (very rough) size of the
register file before enabling regpressure tracking.
llvm-svn: 199766
|
|
|
|
|
|
|
|
|
|
|
| |
For PPC64 SVR (and Darwin), the stores that take byval aggregate parameters
from registers into the stack frame had MachinePointerInfo objects with
incorrect offsets. These offsets are relative to the object itself, not to the
stack frame base.
This fixes self hosting on PPC64 when compiling with -enable-aa-sched-mi.
llvm-svn: 199763
|
|
|
|
|
|
|
|
| |
dependent libraries from a bitcode module.
Differential Revision: http://llvm-reviews.chandlerc.com/D2343
llvm-svn: 199759
|
|
|
|
| |
llvm-svn: 199751
|
|
|
|
|
|
|
|
| |
II_RESTORE
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199749
|
|
|
|
|
|
| |
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199748
|
|
|
|
|
|
| |
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199747
|
|
|
|
| |
llvm-svn: 199746
|
|
|
|
|
|
| |
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199743
|
|
|
|
| |
llvm-svn: 199742
|
|
|
|
|
|
|
|
| |
II_SQRT_D respectively
No functional change
llvm-svn: 199741
|
|
|
|
|
|
|
|
| |
II_DIV_D respectively
No functional change
llvm-svn: 199738
|
|
|
|
|
|
|
|
| |
II_NMADD_D, and II_NMSUB_S
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199737
|
|
|
|
|
|
|
|
| |
II_NMADD_S, and II_NMSUB_S
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199734
|
|
|
|
|
|
| |
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199732
|
|
|
|
|
|
| |
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199728
|
|
|
|
|
|
| |
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199727
|
|
|
|
|
|
| |
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199722
|
|
|
|
|
|
| |
No functional change since the InstrItinData's have been duplicated.
llvm-svn: 199719
|
|
|
|
| |
llvm-svn: 199716
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the unwind_raw directive for the ARM IAS. The unwind_raw
directive takes the form of a stack offset value followed by one or more bytes
representing the opcodes to be emitted. The opcode emitted will interpreted as
if it were assembled by the opcode assembler via the standard unwinding
directives.
Thanks to Logan Chien for an extra test!
llvm-svn: 199707
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The .personalityindex directive is equivalent to the .personality directive with
the ARM EABI personality with the specific index (0, 1, 2). Both of these
directives indicate personality routines, so enhance the personality directive
handling to take into account personalityindex.
Bonus fix: flush the UnwindContext at the beginning of a new function.
Thanks to Logan Chien for additional tests!
llvm-svn: 199706
|
|
|
|
|
|
|
|
| |
It was commited as r199628 but reverted in r199628 as causing
regression test failed. It's because of old vervsion of patch
I used to commit. Sorry for mistake.
llvm-svn: 199704
|