| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Fix PR15239.
llvm-svn: 175985
|
|
|
|
|
|
| |
Fixes PR15115.
llvm-svn: 175962
|
|
|
|
|
|
| |
under coldcc
llvm-svn: 175911
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to TargetFrameLowering, where it belongs. Incidentally, this allows us
to delete some duplicated (and slightly different!) code in TRI.
There are potentially other layering problems that can be cleaned up
as a result, or in a similar manner.
The refactoring was OK'd by Anton Korobeynikov on llvmdev.
Note: this touches the target interfaces, so out-of-tree targets may
be affected.
llvm-svn: 175788
|
|
|
|
|
|
|
|
|
|
| |
exists solely to enable it to call itself for i8 with some registers.
The proposed patch simplifies the function somewhat to make the High
bit only meaningful for the i8 mode, which makes sense. No functional
difference (getX86SubSuperRegister is not getting called from anywhere
outside with i64 and High=true).
llvm-svn: 175762
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
s/AddDirectiveHandler/addDirectiveHandler/
s/ParseMSInlineAsm/parseMSInlineAsm/
s/ParseIdentifier/parseIdentifier/
s/ParseStringToEndOfStatement/parseStringToEndOfStatement/
s/ParseEscapedString/parseEscapedString/
s/EatToEndOfStatement/eatToEndOfStatement/
s/ParseExpression/parseExpression/
s/ParseParenExpression/parseParenExpression/
s/ParseAbsoluteExpression/parseAbsoluteExpression/
s/CheckForValidSection/checkForValidSection/
http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
No functional change intended.
llvm-svn: 175675
|
|
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
ivars should be camel-case and start with an upper-case letter. A few in
TargetLowering were starting with a lower-case letter.
No functional change intended.
llvm-svn: 175667
|
|
|
|
| |
llvm-svn: 175641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sext <4 x i1> to <4 x i64>
sext <4 x i8> to <4 x i64>
sext <4 x i16> to <4 x i64>
I'm running Combine on SIGN_EXTEND_IN_REG and revert SEXT patterns:
(sext_in_reg (v4i64 anyext (v4i32 x )), ExtraVT) -> (v4i64 sext (v4i32 sext_in_reg (v4i32 x , ExtraVT)))
The sext_in_reg (v4i32 x) may be lowered to shl+sar operations.
The "sar" does not exist on 64-bit operation, so lowering sext_in_reg (v4i64 x) has no vector solution.
I also added a cost of this operations to the AVX costs table.
llvm-svn: 175619
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MS-style inline assembly.
This is a follow-on to r175334. Forcing a FP to be emitted doesn't ensure it
will be used. Therefore, force the base pointer as well. We now treat MS
inline assembly in the same way we treat functions with dynamic stack
realignment and VLAs. This guarantees the BP will be used to reference
parameters and locals.
rdar://13218191
llvm-svn: 175576
|
|
|
|
| |
llvm-svn: 175560
|
|
|
|
|
|
| |
No intended functionality change.
llvm-svn: 175536
|
|
|
|
|
|
| |
PPCJITInfo.cpp in r175394.
llvm-svn: 175531
|
|
|
|
| |
llvm-svn: 175525
|
|
|
|
| |
llvm-svn: 175497
|
|
|
|
| |
llvm-svn: 175472
|
|
|
|
| |
llvm-svn: 175467
|
|
|
|
| |
llvm-svn: 175464
|
|
|
|
| |
llvm-svn: 175463
|
|
|
|
| |
llvm-svn: 175458
|
|
|
|
| |
llvm-svn: 175457
|
|
|
|
| |
llvm-svn: 175408
|
|
|
|
| |
llvm-svn: 175402
|
|
|
|
| |
llvm-svn: 175363
|
|
|
|
| |
llvm-svn: 175359
|
|
|
|
|
|
| |
new features.
llvm-svn: 175336
|
|
|
|
|
|
|
|
|
|
|
| |
If the frame pointer is omitted, and any stack changes occur in the inline
assembly, e.g.: "pusha", then any C local variable or C argument references
will be incorrect.
I pass no judgement on anyone who would do such a thing. ;)
rdar://13218191
llvm-svn: 175334
|
|
|
|
| |
llvm-svn: 175322
|
|
|
|
|
|
|
| |
When we're recalculating the feature set of the subtarget, we need to have the
ivars in their initial state.
llvm-svn: 175320
|
|
|
|
|
|
|
|
|
|
| |
features.
If two functions require different features (e.g., `-mno-sse' vs. `-msse') then
we want to honor that, especially during LTO. We can do that by resetting the
subtarget's features depending upon the 'target-feature' attribute.
llvm-svn: 175314
|
|
|
|
| |
llvm-svn: 175312
|
|
|
|
|
|
|
| |
than we need to and some ELF linkers complain about directly accessing symbols
with default visibility.
llvm-svn: 175268
|
|
|
|
|
|
|
|
| |
blocks. We still don't have consensus if we should try to change clang or
the standard, but llvm should work with compilers that implement the current
standard and mangle those functions.
llvm-svn: 175267
|
|
|
|
|
|
| |
linkage.
llvm-svn: 175264
|
|
|
|
| |
llvm-svn: 175220
|
|
|
|
| |
llvm-svn: 175212
|
|
|
|
|
|
| |
-feature flag, instructions definitions, test cases
llvm-svn: 175196
|
|
|
|
| |
llvm-svn: 175189
|
|
|
|
|
|
| |
Added a test.
llvm-svn: 175144
|
|
|
|
| |
llvm-svn: 175133
|
|
|
|
| |
llvm-svn: 175121
|
|
|
|
|
|
| |
Fixes PR15250!
llvm-svn: 175092
|
|
|
|
|
|
|
| |
displacements.
rdar://12974533
llvm-svn: 175083
|
|
|
|
|
|
|
|
|
|
|
| |
This happens when there is both stack realignment and a dynamic alloca in the
function. If we overwrite %esi (rep;movsl uses fixed registers) we'll lose the
base pointer and the next register spill will write into oblivion.
Fixes PR15249 and unbreaks firefox on i386/freebsd. Mozilla uses dynamic allocas
and freebsd a 4 byte stack alignment.
llvm-svn: 175057
|
|
|
|
|
|
| |
since a caller uses preserved registers across the call.
llvm-svn: 175043
|
|
|
|
|
|
| |
assembly.
llvm-svn: 175036
|
|
|
|
|
|
|
| |
Fixed decode of existing 3dNow prefetchw instruction
Intel is scheduled to add a compatible prefetchw (same encoding) to future CPUs
llvm-svn: 174920
|
|
|
|
|
|
| |
*added file for test cases for i386 intel syntax
llvm-svn: 174900
|
|
|
|
|
|
|
|
|
|
|
|
| |
account. Atoms use LEA for updating SP in prologs/epilogs, and the
exact LEA opcode depends on the data model.
Also reapplying the test case which was added and then reverted
(because of Atom failures), this time specifying explicitly the CPU in
addition to the triple. The test case now checks all variations (data
mode, cpu Atom vs. Core).
llvm-svn: 174542
|
|
|
|
|
|
|
| |
pointer in function prologs/epilogs. The opcodes should depend on the
data model (LP64 vs. ILP32) rather than the architecture bit-ness.
llvm-svn: 174446
|