| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
each corresponding CodeGen.
Without explicit dependencies, both per-file action and in-CommonTableGen action could run in parallel.
It races to emit *.inc files simultaneously.
llvm-svn: 187780
|
|
|
|
| |
llvm-svn: 187779
|
|
|
|
| |
llvm-svn: 187778
|
|
|
|
|
|
| |
dependencies.
llvm-svn: 187777
|
|
|
|
| |
llvm-svn: 187771
|
|
|
|
|
|
| |
Patch by: Mei Ye
llvm-svn: 187764
|
|
|
|
| |
llvm-svn: 187763
|
|
|
|
| |
llvm-svn: 187758
|
|
|
|
| |
llvm-svn: 187752
|
|
|
|
|
|
|
| |
We use MVT::i32 for the vector index type, because we use 32-bit
operations to caculate offsets when dynamically indexing vectors.
llvm-svn: 187749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This virtual function can be implemented by targets to specify the type
to use for the index operand of INSERT_VECTOR_ELT, EXTRACT_VECTOR_ELT,
INSERT_SUBVECTOR, EXTRACT_SUBVECTOR. The default implementation returns
the result from TargetLowering::getPointerTy()
The previous code was using TargetLowering::getPointerTy() for vector
indices, because this is guaranteed to be legal on all targets. However,
using TargetLowering::getPointerTy() can be a problem for targets with
pointer sizes that differ across address spaces. On such targets,
when vectors need to be loaded or stored to an address space other than the
default 'zero' address space (which is the address space assumed by
TargetLowering::getPointerTy()), having an index that
is a different size than the pointer can lead to inefficient
pointer calculations, (e.g. 64-bit adds for a 32-bit address space).
There is no intended functionality change with this patch.
llvm-svn: 187748
|
|
|
|
|
|
| |
This reverts commit r187745.
llvm-svn: 187747
|
|
|
|
|
|
| |
simple.
llvm-svn: 187745
|
|
|
|
|
|
| |
greatly on many comments in the code.
llvm-svn: 187742
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
literal entries.
Our internal regex implementation does not cope with large numbers
of anchors very efficiently. Given a ~3600-entry special case list,
regex compilation can take on the order of seconds. This patch solves
the problem for the special case of patterns matching literal global
names (i.e. patterns with no regex metacharacters). Rather than
forming regexes from literal global name patterns, add them to
a StringSet which is checked before matching against the regex.
This reduces regex compilation time by an order of roughly thousands
when reading the aforementioned special case list, according to a
completely unscientific study.
No test cases. I figure that any new tests for this code should
check that regex metacharacters are properly recognised. However,
I could not find any documentation which documents the fact that the
syntax of global names in special case lists is based on regexes.
The extent to which regex syntax is supported in special case lists
should probably be decided on/documented before writing tests.
Differential Revision: http://llvm-reviews.chandlerc.com/D1150
llvm-svn: 187732
|
|
|
|
|
|
|
|
|
| |
This will be used to implement an optimisation for literal entries
in special case lists.
Differential Revision: http://llvm-reviews.chandlerc.com/D1278
llvm-svn: 187731
|
|
|
|
| |
llvm-svn: 187727
|
|
|
|
| |
llvm-svn: 187725
|
|
|
|
|
|
|
|
|
|
| |
(zext, sext, uitofp, sitofp, trunc, fpext, fptosi, fptrunc, bitcast) and shift operations (shl, ashr, lshr) for integer and floating point data types.
Added tests.
Done by Yuri Veselov (mailto:Yuri.Veselov@intel.com).
llvm-svn: 187724
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch just uses a peephole test for "add; compare; branch" sequences
within a single block. The IR optimizers already convert loops to
decrement-and-branch-on-nonzero form in some cases, so even this
simplistic test triggers many times during a clang bootstrap and
projects/test-suite run. It looks like there are still cases where we
need to more strongly prefer branches on nonzero though. E.g. I saw a
case where a loop that started out with a check for 0 ended up with a
check for -1. I'll try to look at that sometime.
I ended up adding the Reference class because MachineInstr::readsRegister()
doesn't check for subregisters (by design, as far as I could tell).
llvm-svn: 187723
|
|
|
|
|
|
| |
flags.
llvm-svn: 187722
|
|
|
|
| |
llvm-svn: 187721
|
|
|
|
| |
llvm-svn: 187720
|
|
|
|
|
|
| |
Just the definitions and MC support. The next patch uses them for codegen.
llvm-svn: 187719
|
|
|
|
|
|
|
|
|
|
|
| |
Perhaps predictably, doing comparison elimination on the fly during
SystemZLongBranch turned out to be a bad idea. The next patches make
use of LOAD AND TEST and BRANCH ON COUNT, both of which require
changes to earlier instructions.
No functionality change intended.
llvm-svn: 187718
|
|
|
|
|
|
| |
Added intrinsics and tests.
llvm-svn: 187717
|
|
|
|
|
|
|
|
|
| |
helper functions. This can be optimized out later when the remaining
parts of the helper function work is moved into the Mips16HardFloat pass.
For now it forces us to use the 32 bit save/restore instructions instead
of the 16 bit ones.
llvm-svn: 187712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
double test(double a, double b, double c, double d) { return a<b ? c : d; }
before:
_test:
ucomisd %xmm0, %xmm1
ja LBB0_2
movaps %xmm3, %xmm2
LBB0_2:
movaps %xmm2, %xmm0
after:
_test:
cmpltsd %xmm1, %xmm0
andpd %xmm0, %xmm2
andnpd %xmm3, %xmm0
orpd %xmm2, %xmm0
Small speedup on Benchmarks/SmallPT
llvm-svn: 187706
|
|
|
|
| |
llvm-svn: 187705
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the weird and wondeful usual arithmetic conversions, some
calculations involving negative values were getting performed in
uint32_t and then promoted to int64_t, which is really not a good
idea.
Patch by Katsuhiro Ueno.
llvm-svn: 187703
|
|
|
|
| |
llvm-svn: 187702
|
|
|
|
| |
llvm-svn: 187701
|
|
|
|
|
|
| |
Store them in a place that gets cleaned up properly.
llvm-svn: 187700
|
|
|
|
| |
llvm-svn: 187698
|
|
|
|
|
|
| |
Using an object to do the cleanup may look like overkill, but it's safer and nicer than putting deletes everywhere.
llvm-svn: 187696
|
|
|
|
| |
llvm-svn: 187695
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Internally, the PowerPC backend names the 32-bit GPRs R[0-9]+, and names the
64-bit parent GPRs X[0-9]+. When matching inline assembly constraints with
explicit register names, on PPC64 when an i64 MVT has been requested, we need
to follow gcc's convention of using r[0-9]+ to refer to the 64-bit (parent)
registers.
At some point, we'll probably want to arrange things so that the generic code
in TargetLowering uses the AsmName fields declared in *RegisterInfo.td in order
to match these inline asm register constraints. If we do that, this change can
be reverted.
llvm-svn: 187693
|
|
|
|
|
|
| |
Remove assertion that the verifier should catch.
llvm-svn: 187692
|
|
|
|
|
|
|
| |
This is for the benefit of those of us with inferior debuggers which
do not permit member function calls on value types.
llvm-svn: 187685
|
|
|
|
|
|
|
|
| |
attribute list is ordered by index.
Differential Revision: http://llvm-reviews.chandlerc.com/D1265
llvm-svn: 187682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Everything that comes after -- should be treated as a filename. This
enables passing in filenames that would otherwise be conflated with
command-line options.
This is especially important for clang-cl which supports options
starting with /, which are easily conflatable with Unix-style
path names.
Differential Revision: http://llvm-reviews.chandlerc.com/D1274
llvm-svn: 187675
|
|
|
|
| |
llvm-svn: 187671
|
|
|
|
| |
llvm-svn: 187667
|
|
|
|
| |
llvm-svn: 187666
|
|
|
|
|
|
|
|
| |
come from different blocks.
Thanks Alexey Samsonov.
llvm-svn: 187663
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the multiple breakages on ARM test-suite after the SLP
vectorizer was introduced by default on O3. The problem was an illegal
vector type on ARMTTI::getCmpSelInstrCost() <3 x i1> which is not simple.
The guard protects this code from breaking (cause of the problems) but
doesn't fix the issue that is generating the odd vector in the first
place, which also needs to be investigated.
llvm-svn: 187658
|
|
|
|
|
|
| |
secrel32 instead of long opcodes (only for coff). This makes them debuggable with GDB (with fix for 64bits msvc)
llvm-svn: 187656
|
|
|
|
| |
llvm-svn: 187649
|
|
|
|
| |
llvm-svn: 187646
|
|
|
|
|
|
|
|
| |
code emitted as secrel32 instead of long opcodes (only for coff). This makes them debuggable with GDB."
It broke x86_64-win32 builder in llvm/test/DebugInfo.
llvm-svn: 187642
|