- Sep 05, 2013
-
-
Eric Christopher authored
llvm-svn: 190064
-
Joey Gouly authored
This removes the custom ISD Node: MEMBARRIER and replaces it with an intrinsic. llvm-svn: 190055
-
Richard Barton authored
These were pretty straightforward instructions, with some assembly support required for HLT. The ARM assembler is keen to split the instruction mnemonic into a (non-existent) 'H' instruction with the LT condition code. An exception for HLT is needed. HLT follows the same rules as BKPT when in IT blocks, so the special BKPT hadling code has been adapted to handle HLT also. Regression tests added including diagnostic tests for out of range immediates and illegal condition codes, as well as negative tests for pre-ARMv8. llvm-svn: 190053
-
Tilmann Scheller authored
Solution is not sufficient to prevent 'mov pc, lr' being emitted for jump table code. Test case doesn't trigger the added functionality. llvm-svn: 190047
-
Tilmann Scheller authored
This improves code generation for jump tables by avoiding the emission of "mov pc, lr" which could fool the processor into believing this is a return from a function causing mispredicts. The code generation logic for jump tables uses ADR to materialize the address of the jump target. Patch by Daniel Stewart! llvm-svn: 190043
-
Richard Sandiford authored
For now these are just used to handle scalar ANDs, ORs and XORs in which all operands are memory. llvm-svn: 190041
-
Nick Lewycky authored
llvm-svn: 190035
-
Venkatraman Govindaraju authored
In sparc, setjmp stores only the registers %fp, %sp, %i7 and %o7. longjmp restores the stack, and the callee-saved registers (all local/in registers: %i0-%i7, %l0-%l7) using the stored %fp and register windows. However, this does not guarantee that the longjmp will restore the registers, as they were when the setjmp was called. This is because these registers may be clobbered after returning from setjmp, but before calling longjmp. This patch prevents the registers %i0-%i5, %l0-l7 to live across the setjmp call using the register mask. llvm-svn: 190033
-
Bill Wendling authored
llvm-svn: 190021
-
Eric Christopher authored
llvm-svn: 190019
-
Andrew Trick authored
Fast register pressure tracking currently only takes effect during bottom up scheduling. Forcing this is a bit faster and simpler for targets that don't have many scheduling constraints and don't need top-down scheduling. llvm-svn: 190014
-
Nick Kledzik authored
llvm-svn: 190013
-
Bill Wendling authored
llvm-svn: 190004
-
Bill Wendling authored
llvm-svn: 190003
-
Eric Christopher authored
without a limiting factor. Update all testcases accordingly. llvm-svn: 190002
-
- Sep 04, 2013
-
-
Eric Christopher authored
Needs testcase updates. llvm-svn: 190000
-
Eric Christopher authored
llvm-svn: 189999
-
Andrew Trick authored
llvm-svn: 189997
-
Andrew Trick authored
llvm-svn: 189995
-
Andrew Trick authored
llvm-svn: 189994
-
Andrew Trick authored
llvm-svn: 189993
-
Andrew Trick authored
llvm-svn: 189992
-
Andrew Trick authored
If the instruction window is < NumRegs/2, pressure tracking is not likely to be effective. The scheduler has to process a very large number of tiny blocks. We want this to be fast. llvm-svn: 189991
-
Andrew Trick authored
llvm-svn: 189990
-
Andrew Trick authored
llvm-svn: 189989
-
Andrew Trick authored
llvm-svn: 189988
-
Andrew Trick authored
Register pressure tracking is half the complexity of the scheduler. It's useful to be able to turn it off for compile time and performance comparisons. llvm-svn: 189987
-
Rafael Espindola authored
I am about to patch this code, and this makes the diff far more readable. llvm-svn: 189982
-
Vincent Lejeune authored
llvm-svn: 189981
-
Vincent Lejeune authored
llvm-svn: 189980
-
Vincent Lejeune authored
llvm-svn: 189979
-
Eric Christopher authored
llvm-svn: 189977
-
Jim Grosbach authored
These instructions, such as vmul.f32, require the second source operand to be in D0-D15 rather than the full D0-D31. When optimizing, make sure to account for that by constraining the register class of a replacement virtual register to be compatible with the virtual register(s) it's replacing. I've been unsuccessful in creating a non-fragile regression test. This issue was detected by the LLVM nightly test suite running on an A15 (Bullet). PR17093: http://llvm.org/bugs/show_bug.cgi?id=17093 llvm-svn: 189972
-
Rafael Espindola authored
llvm-svn: 189971
-
Rafael Espindola authored
No functionality change. llvm-svn: 189969
-
Rafael Espindola authored
llvm-svn: 189967
-
Arnold Schwaighofer authored
Unaligned vldm/vstm need more uops and therefore are slower in general on swift. radar://14522102 llvm-svn: 189961
-
Silviu Baranga authored
Fix scheduling for vldm/vstm instructions that load/store more than 32 bytes on Cortex-A9. This also makes the existing code more compact. llvm-svn: 189958
-
Rafael Espindola authored
This reverts commit r189886. I found a corner case where this optimization is not valid: Say we have a "linkonce_odr unnamed_addr" in two translation units: * In TU 1 this optimization kicks in and makes it hidden. * In TU 2 it gets const merged with a constant that is *not* unnamed_addr, resulting in a non unnamed_addr constant with default visibility. * The static linker rules for combining visibility them produce a hidden symbol, which is incorrect from the point of view of the non unnamed_addr constant. The one place we can do this is when we know that the symbol is not used from another TU in the same shared object, i.e., during LTO. I will move it there. llvm-svn: 189954
-
Alexander Kornienko authored
Move generic isPrint and columnWidth implementations to a separate header/source to allow using both generic and system-dependent versions on win32. Summary: This is needed so we can use generic columnWidthUTF8 in clang-format on win32 simultaneously with a separate system-dependent implementations of isPrint/columnWidth in TextDiagnostic.cpp to avoid attempts to print Unicode characters using narrow-character interfaces (which is not supported on Windows, and we'll have to figure out how to handle this). Reviewers: jordan_rose Reviewed By: jordan_rose CC: llvm-commits, klimek Differential Revision: http://llvm-reviews.chandlerc.com/D1559 llvm-svn: 189952
-