- Nov 29, 2013
-
-
Zoran Jovanovic authored
llvm-svn: 195967
-
Petar Jovanovic authored
XFAIL llvm-cov.test for MIPS until big-endian issues are fixed for llvm-cov. The test does pass on MIPS little-endian. llvm-svn: 195966
-
Zoran Jovanovic authored
llvm-svn: 195965
-
Aaron Ballman authored
llvm-svn: 195964
-
Aaron Ballman authored
Using a custom subject to reenable the Subjects line for the ns_bridged attribute. No functional change intended. llvm-svn: 195963
-
Aaron Ballman authored
llvm-svn: 195962
-
Alexander Kornienko authored
Summary: Use LS_JavaScript for files ending with ".js". Added support for ">>>=" operator. Reviewers: djasper, klimek Reviewed By: djasper CC: cfe-commits, klimek Differential Revision: http://llvm-reviews.chandlerc.com/D2242 llvm-svn: 195961
-
Aaron Ballman authored
Enables support for custom subject lists for attributes. As a testbed, uses the custom subject for the ibaction attribute. llvm-svn: 195960
-
Kostya Serebryany authored
llvm-svn: 195959
-
Kostya Serebryany authored
llvm-svn: 195958
-
Timur Iskhodzhanov authored
llvm-svn: 195957
-
Timur Iskhodzhanov authored
llvm-svn: 195956
-
Timur Iskhodzhanov authored
llvm-svn: 195955
-
Daniel Jasper authored
Before: int aaaa; // This line is formatted. // The comment continues .. // .. here. Before: int aaaa; // This line is formatted. // The comment continues .. // .. here. This fixes llvm.org/PR17914. llvm-svn: 195954
-
Daniel Jasper authored
This should fix llvm.org/PR17241. Maybe it sticks this time :-). llvm-svn: 195953
-
Daniel Jasper authored
Before: DEBUG( // { f(); }); After: DEBUG( // { f(); }); Also add additional test to selected formatting of individual statements in nested blocks. llvm-svn: 195952
-
Hal Finkel authored
On the PPC A2, instructions are only issued after their input operands are ready. Model this by specifying that input operands are read at dispatch (0 cycles after issue). This changes all input operand latencies from 1 to 0. Significant test-suite performance changes (these are 99.5% confidence intervals on 6 runs for both before and after): speedups: MultiSource/Benchmarks/sim/sim -1.21915% +/- 0.175063% MultiSource/Benchmarks/TSVC/LinearDependence-flt/LinearDependence-flt -1.23946% +/- 1.05133% SingleSource/Benchmarks/Misc/flops-2 -1.24237% +/- 0.681362% MultiSource/Applications/JM/lencod/lencod -1.33992% +/- 0.757498% MultiSource/Benchmarks/TSVC/InductionVariable-flt/InductionVariable-flt -1.51802% +/- 1.21468% MultiSource/Benchmarks/TSVC/GlobalDataFlow-flt/GlobalDataFlow-flt -2.18818% +/- 1.28605% MultiSource/Benchmarks/TSVC/Packing-flt/Packing-flt -2.21977% +/- 1.19499% SingleSource/Benchmarks/BenchmarkGame/spectral-norm -2.29822% +/- 0.671871% MultiSource/Benchmarks/TSVC/Packing-dbl/Packing-dbl -2.40975% +/- 0.355931% SingleSource/Benchmarks/Misc/fp-convert -2.41899% +/- 1.04751% MultiSource/Benchmarks/TSVC/Searching-dbl/Searching-dbl -2.50349% +/- 0.126765% SingleSource/Benchmarks/Misc/flops-3 -3.00214% +/- 0.700795% MultiSource/Benchmarks/TSVC/LoopRestructuring-flt/LoopRestructuring-flt -3.56995% +/- 3.2929% MultiSource/Applications/sgefa/sgefa -4.24908% +/- 2.00413% MultiSource/Benchmarks/ASC_Sequoia/IRSmk/IRSmk -18.1294% +/- 3.96489% regressions: MultiSource/Benchmarks/TSVC/Reductions-dbl/Reductions-dbl 1.03249% +/- 0.178547% MultiSource/Applications/hexxagon/hexxagon 1.16597% +/- 0.285235% MultiSource/Benchmarks/TSVC/IndirectAddressing-flt/IndirectAddressing-flt 1.39576% +/- 1.07855% SingleSource/Benchmarks/Misc-C++/stepanov_v1p2 1.71539% +/- 0.173182% MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1 1.90013% +/- 0.866472% MultiSource/Benchmarks/TSVC/Recurrences-dbl/Recurrences-dbl 2.39854% +/- 1.05914% MultiSource/Benchmarks/TSVC/ControlFlow-dbl/ControlFlow-dbl 2.4402% +/- 0.817904% MultiSource/Benchmarks/TSVC/LoopRestructuring-dbl/LoopRestructuring-dbl 5.87997% +/- 3.3172% MultiSource/Benchmarks/Trimaran/netbench-crc/netbench-crc 9.02643% +/- 5.79591% MultiSource/Benchmarks/VersaBench/bmm/bmm 10.3517% +/- 1.227% Obviously, there are data points on both sides of this; but I think, overall, this supports making the change. llvm-svn: 195951
-
Lang Hames authored
constraints on their frame offsets. llvm-svn: 195950
-
Hal Finkel authored
Some of the older PPC processor definitions don't have associated SchedMachineModels; correct this for the PPC440. llvm-svn: 195949
-
Hal Finkel authored
The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
-
Hal Finkel authored
The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
-
Hal Finkel authored
Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
-
Lang Hames authored
llvm-svn: 195945
-
Lang Hames authored
target independent. Most of the x86 specific stackmap/patchpoint handling was necessitated by the use of the native address-mode format for frame index operands. PEI has now been modified to treat stackmap/patchpoint similarly to DEBUG_INFO, allowing us to use a simple, platform independent register/offset pair for frame indexes on stackmap/patchpoints. Notes: - Folding is now platform independent and automatically supported. - Emiting patchpoints with direct memory references now just involves calling the TargetLoweringBase::emitPatchPoint utility method from the target's XXXTargetLowering::EmitInstrWithCustomInserter method. (See X86TargetLowering for an example). - No more ugly platform-specific operand parsers. This patch shouldn't change the generated output for X86. llvm-svn: 195944
-
Hao Liu authored
llvm-svn: 195943
-
Hao Liu authored
E.g. the immediate value of vshrns_n_s16 is [1,16], which should be [1,8]. llvm-svn: 195942
-
Hao Liu authored
Or we can generate some illegal instructions. E.g. shrn2 v0.4s, v1.2d, #35. The legal range should be in [1, 16]. llvm-svn: 195941
-
Jiangning Liu authored
llvm-svn: 195940
-
Jiangning Liu authored
llvm-svn: 195939
-
Jiangning Liu authored
argument double floating point. llvm-svn: 195938
-
Jiangning Liu authored
llvm-svn: 195937
-
Kevin Qin authored
llvm-svn: 195936
-
Tobias Grosser authored
llvm-svn: 195935
-
- Nov 28, 2013
-
-
Stephen Canon authored
llvm-svn: 195934
-
Rafael Espindola authored
llvm-svn: 195933
-
Benjamin Kramer authored
No functionality change. llvm-svn: 195932
-
Rafael Espindola authored
llvm-svn: 195931
-
Sylvestre Ledru authored
llvm-svn: 195930
-
NAKAMURA Takumi authored
I think, in principle, intrinsics_gen may be added explicitly. That said, it can be added incidentally, since each target already has dependencies to llvm-tblgen. Almost all source files depend on both CommonTaleGen and intrinsics_gen. Explicit add_dependencies() have been pruned under lib/Target. llvm-svn: 195929
-
NAKAMURA Takumi authored
llvm-svn: 195928
-