- Aug 06, 2013
-
-
Alexey Samsonov authored
Store compile unit corresponding to each chain of inlined debug info entries. No functionality change. llvm-svn: 187792
-
Alexey Samsonov authored
llvm-svn: 187790
-
Tim Northover authored
This change came about primarily because of two issues in the existing code. Niether of: define i64 @test1(i64 %val) { %in = trunc i64 %val to i32 tail call i32 @ret32(i32 returned %in) ret i64 %val } define i64 @test2(i64 %val) { tail call i32 @ret32(i32 returned undef) ret i32 42 } should be tail calls, and the function sameNoopInput is responsible. The main problem is that it is completely symmetric in the "tail call" and "ret" value, but in reality different things are allowed on each side. For these cases: 1. Any truncation should lead to a larger value being generated by "tail call" than needed by "ret". 2. Undef should only be allowed as a source for ret, not as a result of the call. Along the way I noticed that a mismatch between what this function treats as a valid truncation and what the backends see can lead to invalid calls as well (see x86-32 test case). This patch refactors the code so that instead of being based primarily on values which it recurses into when necessary, it starts by inspecting the type and considers each fundamental slot that the backend will see in turn. For example, given a pathological function that returned {{}, {{}, i32, {}}, i32} we would consider each "real" i32 in turn, and ask if it passes through unchanged. This is much closer to what the backend sees as a result of ComputeValueVTs. Aside from the bug fixes, this eliminates the recursion that's going on and, I believe, makes the bulk of the code significantly easier to understand. The trade-off is the nasty iterators needed to find the real types inside a returned value. llvm-svn: 187787
-
Serge Pavlov authored
llvm-svn: 187786
-
Craig Topper authored
llvm-svn: 187783
-
Craig Topper authored
llvm-svn: 187781
-
NAKAMURA Takumi authored
Target/*/CMakeLists.txt: Add the dependency to CommonTableGen explicitly for 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
-
Craig Topper authored
llvm-svn: 187779
-
NAKAMURA Takumi authored
llvm-svn: 187778
-
NAKAMURA Takumi authored
llvm-svn: 187777
-
Craig Topper authored
llvm-svn: 187771
-
Tom Stellard authored
Patch by: Mei Ye llvm-svn: 187764
-
Eric Christopher authored
llvm-svn: 187763
-
Matt Arsenault authored
llvm-svn: 187758
-
Eric Christopher authored
llvm-svn: 187752
-
Tom Stellard authored
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
-
Tom Stellard authored
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
-
Eric Christopher authored
This reverts commit r187745. llvm-svn: 187747
-
Eric Christopher authored
simple. llvm-svn: 187745
-
- Aug 05, 2013
-
-
Eric Christopher authored
greatly on many comments in the code. llvm-svn: 187742
-
Peter Collingbourne authored
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
-
Peter Collingbourne authored
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
-
Aaron Ballman authored
llvm-svn: 187727
-
Alexey Samsonov authored
llvm-svn: 187725
-
Elena Demikhovsky authored
LLVM Interpreter: This patch implements vector support for cast operations (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
-
Richard Sandiford authored
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
-
Benjamin Kramer authored
llvm-svn: 187722
-
Richard Sandiford authored
llvm-svn: 187721
-
Richard Sandiford authored
llvm-svn: 187720
-
Richard Sandiford authored
Just the definitions and MC support. The next patch uses them for codegen. llvm-svn: 187719
-
Richard Sandiford authored
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
-
Elena Demikhovsky authored
Added intrinsics and tests. llvm-svn: 187717
-
Reed Kotler authored
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
-
- Aug 04, 2013
-
-
Benjamin Kramer authored
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
-
Elena Demikhovsky authored
llvm-svn: 187705
-
Tim Northover authored
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
-
Benjamin Kramer authored
llvm-svn: 187702
-
Reed Kotler authored
llvm-svn: 187701
-
Benjamin Kramer authored
Store them in a place that gets cleaned up properly. llvm-svn: 187700
-
Benjamin Kramer authored
llvm-svn: 187698
-