| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147367 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
of having the W bit set for XOP instructons. Removes ORing W-bits in the encoder and will similarly simplify the disassembler implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147365 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147364 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
force alignment on these instructions. Add a couple testcases for memory forms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147361 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
size, but with the special handling to be compatible with the intrinsic expecting a vector. Similar handling is already used elsewhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147360 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
1. The ST*UX instructions that store and update the stack pointer did not set define/kill on R1. This became a problem when I activated post-RA scheduling (and had incorrectly adjusted the Frames-large test).
2. eliminateFrameIndex did not kill its scavenged temporary register, and this could cause the scavenger to exhaust all available registers (and its emergency spill slot) when there were a lot of CR values to spill. The 2010-02-12-saveCR test has been adjusted to check for this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147359 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147353 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147351 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
aren't valid unless AVX is enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147349 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147348 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
in r147339.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147347 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
along with CLMUL. That's required for the XMM registers to be valid for integer data. Doesn't change any behavior since the CLMUL instructions don't have patterns yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147345 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
with AES. Since that's required for the XMM registers to be valid for integer data. Doesn't change any behavior though since you can't use an intrinsic with an illegal type anyway. Just makes it consistent with the VEX forms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147344 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
to the patterns specified by the instructions. Also remove unnecessary bitconverts from the AES patterns.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147342 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
on its own without disabling SSE4.2 or SSE4A.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147339 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
for v16i16 and v32i8.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147337 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147336 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Add same assert on similar code path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147335 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
floating-point types. PR11674.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
Matching MOVLP mask for AVX (265-bit vectors) was wrong.
The failure was detected by conformance tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147308 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147289 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
consistency. Add comments and an assert for BMI instructions to PerformXorCombine since the enabling of the combine is conditional on it, but the function itself isn't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147287 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147269 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
x86 specific reloc_coff_secrel32 with a generic FK_SecRel_4.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147252 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LZCNT instructions are available. Force promotion to i32 to get
a smaller encoding since the fix-ups necessary are just as complex for
either promoted type
We can't do standard promotion for CTLZ when lowering through BSR
because it results in poor code surrounding the 'xor' at the end of this
instruction. Essentially, if we promote the entire CTLZ node to i32, we
end up doing the xor on a 32-bit CTLZ implementation, and then
subtracting appropriately to get back to an i8 value. Instead, our
custom logic just uses the knowledge of the incoming size to compute
a perfect xor. I'd love to know of a way to fix this, but so far I'm
drawing a blank. I suspect the legalizer could be more clever and/or it
could collude with the DAG combiner, but how... ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147251 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
inspection earlier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147250 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147247 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
'bsf' instructions here.
This one is actually debatable to my eyes. It's not clear that any chip
implementing 'tzcnt' would have a slow 'bsf' for any reason, and unless
EFLAGS or a zero input matters, 'tzcnt' is just a longer encoding.
Still, this restores the old behavior with 'tzcnt' enabled for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147246 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
X86ISelLowering C++ code. Because this is lowered via an xor wrapped
around a bsr, we want the dagcombine which runs after isel lowering to
have a chance to clean things up. In particular, it is very common to
see code which looks like:
(sizeof(x)*8 - 1) ^ __builtin_clz(x)
Which is trying to compute the most significant bit of 'x'. That's
actually the value computed directly by the 'bsr' instruction, but if we
match it too late, we'll get completely redundant xor instructions.
The more naive code for the above (subtracting rather than using an xor)
still isn't handled correctly due to the dagcombine getting confused.
Also, while here fix an issue spotted by inspection: we should have been
expanding the zero-undef variants to the normal variants when there is
an 'lzcnt' instruction. Do so, and test for this. We don't want to
generate unnecessary 'bsr' instructions.
These two changes fix some regressions in encoding and decoding
benchmarks. However, there is still a *lot* to be improve on in this
type of code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147244 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147238 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
loadRegFromStackSlot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147235 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147234 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147232 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147231 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM targets with NEON units have access to aligned vector loads and
stores that are potentially faster than unaligned operations.
Add support for spilling the callee-saved NEON registers to an aligned
stack area using 16-byte aligned NEON loads and store.
This feature is off by default, controlled by an -align-neon-spills
command line option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147211 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
My change r146949 added register clobbers to the eh_sjlj_dispatchsetup pseudo
instruction, but on Thumb1 some of those registers cannot be used. This
caused massive failures on the testsuite when compiling for Thumb1. While
fixing that, I noticed that the eh_sjlj_setjmp instruction has a "nofp"
variant, and I realized that dispatchsetup needs the same thing, so I have
added that as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147204 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147192 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
rdar://10558523
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147189 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Noticed by inspection; I don't have a testcase for this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147188 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147184 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Fixes PR11214.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147180 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
The value from the operands isn't right yet, but we weren't encoding it at
all previously. The parser needs to twiddle the values when building the
instruction.
Partial for: rdar://10558523
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147170 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147169 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147158 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
reporting
it. It does need some some tests...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147154 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
Just treat it as-if the shift wasn't there at all. 'as' compatibility.
rdar://10604767
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147153 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147152 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147151 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147150 91177308-0d34-0410-b5e6-96231b3b80d8
|