| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 109450
|
| |
|
|
| |
llvm-svn: 109448
|
| |
|
|
|
|
|
|
|
| |
we are using AVX and no AVX version of the desired intruction is present,
this is better for incremental dev (without fallbacks it's easier to spot
what's missing). Not sure this is the best hack thought (we can also disable
all HasSSE* predicates by dinamically marking them 'false' if AVX is present)
llvm-svn: 109434
|
| |
|
|
|
|
|
|
| |
This assumption is not satisfied due to global mergeing.
Workaround the issue by temporary disablinge mergeing of const globals.
Also, ignore LLVM "special" globals. This fixes PR7716
llvm-svn: 109423
|
| |
|
|
| |
llvm-svn: 109421
|
| |
|
|
| |
llvm-svn: 109373
|
| |
|
|
| |
llvm-svn: 109372
|
| |
|
|
| |
llvm-svn: 109359
|
| |
|
|
|
|
|
|
|
|
|
|
| |
appropriate for targets without detailed instruction iterineries.
The scheduler schedules for increased instruction level parallelism in
low register pressure situation; it schedules to reduce register pressure
when the register pressure becomes high.
On x86_64, this is a win for all tests in CFP2000. It also sped up 256.bzip2
by 16%.
llvm-svn: 109300
|
| |
|
|
| |
llvm-svn: 109295
|
| |
|
|
|
|
|
| |
function live in set. This will give us tGPR for Thumb1 and GPR otherwise,
so the copy will be spillable. rdar://8224931
llvm-svn: 109293
|
| |
|
|
|
|
|
|
|
|
| |
comments explaining why it was wrong. 8225024.
Fix the real problem in 8213383: the code that splits very large
blocks when no other place to put constants can be found was not
considering the case that the block contained a Thumb tablejump.
llvm-svn: 109282
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
it's too late to start backing off aggressive latency scheduling when most
of the registers are in use so the threshold should be a bit tighter.
- Correctly handle live out's and extract_subreg etc.
- Enable register pressure aware scheduling by default for hybrid scheduler.
For ARM, this is almost always a win on # of instructions. It's runtime
neutral for most of the tests. But for some kernels with high register
pressure it can be a huge win. e.g. 464.h264ref reduced number of spills by
54 and sped up by 20%.
llvm-svn: 109279
|
| |
|
|
| |
llvm-svn: 109276
|
| |
|
|
| |
llvm-svn: 109248
|
| |
|
|
| |
llvm-svn: 109224
|
| |
|
|
| |
llvm-svn: 109222
|
| |
|
|
| |
llvm-svn: 109207
|
| |
|
|
| |
llvm-svn: 109206
|
| |
|
|
|
|
| |
encodings taken from the AVX manual
llvm-svn: 109204
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SSE, so we can't return floating point values if this
is disabled. Detect this error for clang.
With SSE1 only, f64 is a problem; it can be done, but
neither llvm-gcc nor clang has ever generated correct
code for it. Since nobody noticed this I think it's
OK to treat it as an error for now.
This also handles SSE-sized vectors of floating point.
8207686, 8204109.
llvm-svn: 109201
|
| |
|
|
|
|
| |
with PINSRW, which was totally wrong because of a typo I introduced previously
llvm-svn: 109198
|
| |
|
|
|
|
|
|
| |
ARM/PPC/MSP430-specific code (which are the only targets that
implement the hook) can directly reference their target-specific
instrinfo classes.
llvm-svn: 109171
|
| |
|
|
|
|
| |
This complete the assembler support for the general AVX ISA. But we still miss instructions from FMA3 and CLMUL specific feature flags, which are now the next step
llvm-svn: 109168
|
| |
|
|
| |
llvm-svn: 109167
|
| |
|
|
|
|
|
|
|
| |
This is probably not the best way to implement "Force LR to
be spilled if the Thumb function size is > 2048." do this,
it should use the branch shortening infrastructure, but I'm
just preserving functionality here.
llvm-svn: 109165
|
| |
|
|
| |
llvm-svn: 109154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
rip out the implementation of X86InstrInfo::GetInstSizeInBytes.
The code being ripped out just implemented a copy and hacked up
version of the (old) instruction encoder, and is buggy and
terrible in other ways. Since "GetInstSizeInBytes" is really
only there to support the JIT's "NeedsExactSize" hook (which
noone is using), just rip out the code. I will rip out the
NeedsExactSize hook next.
This resolves rdar://7617809 - switch X86InstrInfo::GetInstSizeInBytes to use X86MCCodeEmitter
llvm-svn: 109149
|
| |
|
|
|
|
| |
call. Fixes PR7608
llvm-svn: 109125
|
| |
|
|
| |
llvm-svn: 109092
|
| |
|
|
| |
llvm-svn: 109091
|
| |
|
|
| |
llvm-svn: 109090
|
| |
|
|
|
|
| |
especially on other platforms. Is there a better way to fix this.
llvm-svn: 109084
|
| |
|
|
| |
llvm-svn: 109081
|
| |
|
|
|
|
|
|
| |
for lowering without sse2. Add a couple of new testcases.
Fixes a few libgomp tests and latent bugs. Remove a few todos.
llvm-svn: 109078
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
instruction does not have to be 4-byte aligned. Rather, it's the offset + 2 that must be aligned since the instruction expands into:
mov pc, r1
.align 2
LJTI0_0_0:
.long LBB0_14
This fixes rdar://8213383. No test case since it's not possible to come up with a suitable small one.
llvm-svn: 109076
|
| |
|
|
| |
llvm-svn: 109070
|
| |
|
|
| |
llvm-svn: 109069
|
| |
|
|
| |
llvm-svn: 109064
|
| |
|
|
|
|
|
| |
Add 64-bit (GR64) versions of some instructions (which are not
described in their SSE forms, but are described in AVX)
llvm-svn: 109063
|
| |
|
|
|
|
| |
and then forced every register to be a vr128 on win64.
llvm-svn: 109060
|
| |
|
|
|
|
| |
rdar://8202967
llvm-svn: 109057
|
| |
|
|
|
|
|
|
| |
asmprinter or mangler around. This is option #B for killing off
X86InstrInfo::GetInstSizeInBytes. Option #A (killing
"needsexactsize") was sent for consideration to llvmdev.
llvm-svn: 109056
|
| |
|
|
| |
llvm-svn: 109047
|
| |
|
|
| |
llvm-svn: 109045
|
| |
|
|
|
|
| |
in their SSE forms (although they exist), but add the AVX forms anyway, so the assembler can benefit from it
llvm-svn: 109039
|
| |
|
|
|
|
|
|
|
|
|
| |
1) all registers were spilled as xmm, regardless of actual size
2) win64 abi doesn't do the varargs-size-in-%al thing
Still to look into:
xmm6-15 are marked as clobbered by call instructions on win64 even though they aren't.
llvm-svn: 109035
|
| |
|
|
| |
llvm-svn: 109032
|
| |
|
|
| |
llvm-svn: 109009
|
| |
|
|
|
|
| |
the wrong directory.
llvm-svn: 109005
|