| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Patch by Jai Menon.
llvm-svn: 126165
|
|
|
|
|
|
|
|
|
|
|
| |
LiveIns."
In other words, do not keep track of argument's location. The debugger (gdb) is not prepared to see line table entries for arguments. For the debugger, "second" line table entry marks beginning of function body.
This requires some coordination with debugger to get this working.
- The debugger needs to be aware of prolog_end attribute attached with line table entries.
- The compiler needs to accurately mark prolog_end in line table entries (at -O0 and at -O1+)
llvm-svn: 126155
|
|
|
|
|
|
|
|
| |
X86 instruction decode structure was being interpreted as
being in units of bits, although it is actually stored in
units of bytes.
llvm-svn: 126147
|
|
|
|
| |
llvm-svn: 126130
|
|
|
|
|
|
| |
but which is responsible for us doing really bad things to 256.bzip2.
llvm-svn: 126126
|
|
|
|
|
|
|
| |
"dllimport" function must not be GlobalVariable, but Function. It is enough to check with GlobalValue.
test/CodeGen/X86/dll-linkage.ll is updated to check llc -O0.
llvm-svn: 126110
|
|
|
|
|
|
| |
on Core 2 and Nehalem, so the code we generate is better than GCC's here.
llvm-svn: 126100
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
approximation
of a constant had a minor typo introduced when copying it from the book, which
caused it to favor negative approximations over positive approximations in many
cases. Positive approximations require fewer operations beyond the multiplication.
In the case of division by 3, we still generate code that is a single instruction
larger than GCC's code.
llvm-svn: 126097
|
|
|
|
|
|
|
|
|
| |
since one needs to be a register operand. Just use movss instead of forcing
an operand into a register.
Fixes PR9239
llvm-svn: 126072
|
|
|
|
|
|
|
|
|
| |
of testing for its presence at cmake time.
This way the build automatically regenerates the makefiles when a svn
update brings in a new sublibrary.
llvm-svn: 126068
|
|
|
|
| |
llvm-svn: 126054
|
|
|
|
|
|
|
| |
This is reasonable to do since all bt-mem forms do the
same thing.
llvm-svn: 126047
|
|
|
|
| |
llvm-svn: 126018
|
|
|
|
| |
llvm-svn: 125832
|
|
|
|
| |
llvm-svn: 125805
|
|
|
|
|
|
| |
Validate encoding of leave in 64bit mode.
llvm-svn: 125795
|
|
|
|
|
|
|
|
|
|
|
|
| |
(LLVMX86Utils.a) to break cyclic library dependencies between
LLVMX86CodeGen.a and LLVMX86AsmParser.a. Previously this code was in
a header file and marked static but AVX requires some additional
functionality here that won't be used by all clients. Since including
unused static functions causes a gcc compiler warning, keeping it as a
header would break builds that use -Werror. Putting this in its own
library solves both problems at once.
llvm-svn: 125765
|
|
|
|
|
|
| |
these patterns.
llvm-svn: 125759
|
|
|
|
|
|
| |
No one uses *-mingw64. mingw-w64 is represented as {i686|x86_64}-w64-mingw32. In llvm side, i686 and x64 can be treated as similar way.
llvm-svn: 125747
|
|
|
|
| |
llvm-svn: 125746
|
|
|
|
|
|
| |
other getNode() methods. Radar 9002173.
llvm-svn: 125665
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
have their low bits set to zero. This allows us to optimize
out explicit stack alignment code like in stack-align.ll:test4 when
it is redundant.
Doing this causes the code generator to start turning FI+cst into
FI|cst all over the place, which is general goodness (that is the
canonical form) except that various pieces of the code generator
don't handle OR aggressively. Fix this by introducing a new
SelectionDAG::isBaseWithConstantOffset predicate, and using it
in places that are looking for ADD(X,CST). The ARM backend in
particular was missing a lot of addressing mode folding opportunities
around OR.
llvm-svn: 125470
|
|
|
|
|
|
|
|
| |
These are just FXSAVE and FXRSTOR with REX.W prefixes. These versions use
64-bit pointer values instead of 32-bit pointer values in the memory map they
dump and restore.
llvm-svn: 125446
|
|
|
|
| |
llvm-svn: 125438
|
|
|
|
|
|
|
| |
largely completes support for 128-bit fallback lowering for code that
is not 256-bit ready.
llvm-svn: 125315
|
|
|
|
| |
llvm-svn: 125284
|
|
|
|
| |
llvm-svn: 125187
|
|
|
|
|
|
|
| |
anything but the simplest of cases, lower a 256-bit BUILD_VECTOR by
splitting it into 128-bit parts and recombining.
llvm-svn: 125105
|
|
|
|
|
|
|
| |
couple of utility functions that will be used in other places for more
AVX lowering.
llvm-svn: 125029
|
|
|
|
|
|
| |
enough for caller to allocate one.
llvm-svn: 124949
|
|
|
|
|
|
| |
functional changes.
llvm-svn: 124948
|
|
|
|
| |
llvm-svn: 124947
|
|
|
|
| |
llvm-svn: 124946
|
|
|
|
| |
llvm-svn: 124912
|
|
|
|
|
|
|
|
| |
This allows us to easily support 256-bit operations that don't have
native 256-bit support. This applies to integer operations, certain
types of shuffles and various othher things.
llvm-svn: 124910
|
|
|
|
|
|
| |
custom conversion functions).
llvm-svn: 124872
|
|
|
|
|
|
|
| |
infrastructure. This makes lowering 256-bit vectors to 128-bit
vectors simple when 256-bit vector support is not available.
llvm-svn: 124868
|
|
|
|
|
|
|
|
|
|
| |
matching EXTRACT_SUBVECTOR to VEXTRACTF128 along with support routines
to examine and translate index values. VINSERTF128 comes next. With
these two in place we can begin supporting more AVX operations as
INSERT/EXTRACT can be used as a fallback when 256-bit support is not
available.
llvm-svn: 124797
|
|
|
|
|
|
|
|
| |
Reversing the operands allows us to fold, but doesn't force us to. Also, at
this point the DAG is still being optimized, so the check for hasOneUse is not
very precise.
llvm-svn: 124773
|
|
|
|
|
|
|
|
| |
prefix would be misinterpreted in some cases on 32-bit
x86 platforms. Thanks to Olivier Meurant for identifying
the bug.
llvm-svn: 124709
|
|
|
|
| |
llvm-svn: 124652
|
|
|
|
| |
llvm-svn: 124639
|
|
|
|
| |
llvm-svn: 124611
|
|
|
|
|
|
|
| |
how to lower more/new operations. This is a prerequisite for adding
additional AVX lowering.
llvm-svn: 124447
|
|
|
|
|
|
| |
Create override of this method in X86/ARM/MBlaze.
llvm-svn: 124378
|
|
|
|
|
|
| |
CALL64 marks %xmm* as dead.
llvm-svn: 124354
|
|
|
|
|
|
|
|
| |
default implementation for x86, going through the stack in a similr
fashion to how the codegen implements BUILD_VECTOR. Eventually this
will get matched to VINSERTF128 if AVX is available.
llvm-svn: 124307
|
|
|
|
|
|
|
|
| |
implementation of EXTRACT_SUBVECTOR for x86, going through the stack
in a similr fashion to how the codegen implements BUILD_VECTOR.
Eventually this will get matched to VEXTRACTF128 if AVX is available.
llvm-svn: 124292
|
|
|
|
| |
llvm-svn: 124272
|
|
|
|
| |
llvm-svn: 124270
|