| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
default implementation for x86, going through the stack in a similr
fashion to how the codegen implements BUILD_VECTOR. Eventually this
will get matched to VINSERTF128 if AVX is available.
llvm-svn: 124307
|
|
|
|
|
|
|
|
| |
implementation of EXTRACT_SUBVECTOR for x86, going through the stack
in a similr fashion to how the codegen implements BUILD_VECTOR.
Eventually this will get matched to VEXTRACTF128 if AVX is available.
llvm-svn: 124292
|
|
|
|
| |
llvm-svn: 124245
|
|
|
|
|
|
|
|
|
|
| |
clang's -Wuninitialized-experimental warning.
While these don't look like real bugs, clang's
-Wuninitialized-experimental analysis is stricter
than GCC's, and these fixes have the benefit
of being general nice cleanups.
llvm-svn: 124073
|
|
|
|
|
|
| |
and fixes here and there.
llvm-svn: 123170
|
|
|
|
|
|
|
|
|
|
| |
without a TRI instance.
Print virtual registers numbered from 0 instead of the arbitrary
FirstVirtualRegister. The first virtual register is printed as %vreg0.
TRI::NoRegister is printed as %noreg.
llvm-svn: 123107
|
|
|
|
|
|
|
| |
etc. takes an option OptSize. If OptSize is true, it would return
the inline limit for functions with attribute OptSize.
llvm-svn: 122952
|
|
|
|
| |
llvm-svn: 122949
|
|
|
|
|
|
|
|
| |
up freebsd bootloader. However, this doesn't make much sense for Darwin, whose
-Os is meant to optimize for size only if it doesn't hurt performance.
rdar://8821501
llvm-svn: 122936
|
|
|
|
|
|
|
|
|
|
| |
This allows us to compile:
void test(char *s, int a) {
__builtin_memset(s, a, 15);
}
into 1 mul + 3 stores instead of 3 muls + 3 stores.
llvm-svn: 122710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
series of shifts and ors.
We could implement a DAGCombine to turn x * 0x0101 back into logic operations
on targets that doesn't support the multiply or it is slow (p4) if someone cares
enough.
Example code:
void test(char *s, int a) {
__builtin_memset(s, a, 4);
}
before:
_test: ## @test
movzbl 8(%esp), %eax
movl %eax, %ecx
shll $8, %ecx
orl %eax, %ecx
movl %ecx, %eax
shll $16, %eax
orl %ecx, %eax
movl 4(%esp), %ecx
movl %eax, 4(%ecx)
movl %eax, (%ecx)
ret
after:
_test: ## @test
movzbl 8(%esp), %eax
imull $16843009, %eax, %eax ## imm = 0x1010101
movl 4(%esp), %ecx
movl %eax, 4(%ecx)
movl %eax, (%ecx)
ret
llvm-svn: 122707
|
|
|
|
|
|
|
| |
something that just glues two nodes together, even if it is
sometimes used for flags.
llvm-svn: 122310
|
|
|
|
|
|
|
| |
enough to teach it that ADDE(0,0) is known 0 except the
low bit, for example.
llvm-svn: 122191
|
|
|
|
|
|
|
| |
catch this here rather than later after accessing uninitialized memory
etc. Fires when compiling the testcase in PR8237.
llvm-svn: 121635
|
|
|
|
|
|
|
|
| |
zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.
llvm-svn: 121120
|
|
|
|
| |
llvm-svn: 120910
|
|
|
|
|
|
| |
setAllBits(), setBit(unsigned), etc.
llvm-svn: 120564
|
|
|
|
| |
llvm-svn: 120298
|
|
|
|
| |
llvm-svn: 119990
|
|
|
|
| |
llvm-svn: 119903
|
|
|
|
|
|
|
|
|
|
|
| |
so don't claim they are. They are allocated using DAG.getNode, so attempts
to access MemSDNode fields results in reading off the end of the allocated
memory. This fixes crashes with "llc -debug" due to debug code trying to
print MemSDNode fields for these barrier nodes (since the crashes are not
deterministic, use valgrind to see this). Add some nasty checking to try
to catch this kind of thing in the future.
llvm-svn: 119901
|
|
|
|
|
|
|
| |
DAGCombine from making an illegal transformation of bitcast of a scalar to a
vector into a scalar_to_vector.
llvm-svn: 119819
|
|
|
|
|
|
|
|
| |
memset; we may need it to decide between MOVAPS and MOVUPS
later. Adjust a test that was looking for wrong code.
PR 3866 / 8675131.
llvm-svn: 119605
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
be used
to perform the copy, which may be of lots of memory [*]. It would be good if the
fall-back code generated something reasonable, i.e. did the copy in a loop, rather
than vast numbers of loads and stores. Add a note about this. Currently target
specific code seems to always kick in so this is more of a theoretical issue rather
than a practical one now that X86 has been fixed.
[*] It's amazing how often people pass mega-byte long arrays by copy...
llvm-svn: 118275
|
|
|
|
|
|
|
| |
with a SimpleValueType, while an EVT supports equality and
inequality comparisons with SimpleValueType.
llvm-svn: 118169
|
|
|
|
|
|
|
|
| |
memory, so a MachineMemOperand is useful (not propagated
into the MachineInstr yet). No functional change except
for dump output.
llvm-svn: 117413
|
|
|
|
| |
llvm-svn: 116890
|
|
|
|
|
|
|
| |
setup they require. Use this for ARM/Darwin to rematerialize the base
pointer from the frame pointer when required. rdar://8564268
llvm-svn: 116879
|
|
|
|
|
|
|
| |
I think I've audited all uses, so it should be dependable for address spaces,
and the pointer+offset info should also be accurate when there.
llvm-svn: 114464
|
|
|
|
|
|
| |
MachinePointerInfo around more.
llvm-svn: 114452
|
|
|
|
| |
llvm-svn: 114450
|
|
|
|
|
|
| |
with an indexed load/store that has an offset in the index.
llvm-svn: 114449
|
|
|
|
|
|
| |
SelectionDAG::getExtLoad overload, and eliminate it.
llvm-svn: 114446
|
|
|
|
|
|
| |
getLoad overloads.
llvm-svn: 114443
|
|
|
|
|
|
|
| |
instead of srcvalue/offset pairs. This corrects SV info for mem
operations whose size is > 32-bits.
llvm-svn: 114401
|
|
|
|
|
|
|
| |
MachinePointerInfo. Among other virtues, this doesn't silently truncate the
svoffset to 32-bits.
llvm-svn: 114399
|
|
|
|
|
|
| |
MachinePointerInfo
llvm-svn: 114397
|
|
|
|
|
|
| |
eliminating some weird "infer a frame address" logic which was dead.
llvm-svn: 114396
|
|
|
|
|
|
|
| |
MachinePointerInfo, propagating the type out a level of API. Remove
the old MachineFunction::getMachineMemOperand impl.
llvm-svn: 114393
|
|
|
|
|
|
|
|
|
|
| |
is that there is
NO path to the destination containing side effects, not that SOME path contains no side effects.
In practice, this only manifests with CombinerAA enabled, because otherwise the chain has little
to no branching, so "any" is effectively equivalent to "all".
llvm-svn: 114268
|
|
|
|
| |
llvm-svn: 112571
|
|
|
|
|
|
|
|
| |
Fixes potential ambiguity problems on VS 2010.
Patch by nobled!
llvm-svn: 110029
|
|
|
|
| |
llvm-svn: 109234
|
|
|
|
| |
llvm-svn: 109122
|
|
|
|
|
|
| |
-enable-no-nans-fp-math and -enable-no-infs-fp-math. All of the current codegen fp math optimizations only care whether the fp arithmetics arguments and results can never be NaN.
llvm-svn: 108465
|
|
|
|
|
|
| |
for consistency sake.
llvm-svn: 107820
|
|
|
|
| |
llvm-svn: 107710
|
|
|
|
|
|
| |
ensures remat'ed loads from fixed slots have the right alignments.
llvm-svn: 107591
|
|
|
|
|
|
| |
This produces terrible but correct code.
llvm-svn: 106952
|
|
|
|
|
|
| |
is not used. Spotted by gcc-4.6.
llvm-svn: 106854
|