| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 184783
|
| |
|
|
|
|
| |
never modified. No functional change.
llvm-svn: 184781
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds support for the following extended mnemonics:
xnop
mr.
not
not.
la
llvm-svn: 184767
|
| |
|
|
|
|
|
|
| |
Representing enumerators by int64 instead of uint64 for now. At some
point we need to address the underlying issue of representation
depending on the specific enumeration.
llvm-svn: 184761
|
| |
|
|
| |
llvm-svn: 184758
|
| |
|
|
|
|
| |
our -> or
llvm-svn: 184756
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the predicted forms of branches (+/-).
There are three cases to consider:
- Branches using a PPC::Predicate code
For these, I've added new PPC::Predicate codes corresponding
to the BO values for predicted branch forms, and updated insn
printing to print them correctly. I've also added new aliases
for the asm parser matching the new forms.
- bt/bf
I've added new aliases matching to gBC etc.
- bd(n)z variants
I've added new instruction patterns for the predicted forms.
In all cases, the new patterns are used for the asm parser only.
(The new infrastructure ought to be sufficient to allow use by
the compiler too at some point.)
llvm-svn: 184754
|
| |
|
|
| |
llvm-svn: 184749
|
| |
|
|
|
|
|
|
| |
of NVPTXTargetObjectFile. ~NVPTXTargetObjectFile() tries to delete them.
It caused crash on some hosts since r184595.
llvm-svn: 184728
|
| |
|
|
|
|
|
| |
This adds the bt/bf/bd(n)zt/bd(n)zf mnemonics as aliases for the
asm parser, resolving to the generic conditional patterns.
llvm-svn: 184725
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should hopefully have fixed the stage2/stage3 miscompare on the dragonegg
testers.
"LoopVectorize: Use the dependence test utility class
We now no longer need alias analysis - the cases that alias analysis would
handle are now handled as accesses with a large dependence distance.
We can now vectorize loops with simple constant dependence distances.
for (i = 8; i < 256; ++i) {
a[i] = a[i+4] * a[i+8];
}
for (i = 8; i < 256; ++i) {
a[i] = a[i-4] * a[i-8];
}
We would be able to vectorize about 200 more loops (in many cases the cost model
instructs us no to) in the test suite now. Results on x86-64 are a wash.
I have seen one degradation in ammp. Interestingly, the function in which we
now vectorize a loop is never executed so we probably see some instruction
cache effects. There is a 2% improvement in h264ref. There is one or the other
TSCV loop kernel that speeds up.
radar://13681598"
llvm-svn: 184724
|
| |
|
|
|
|
|
| |
We are creating the runtime checks using this set so we need a deterministic
iteration order.
llvm-svn: 184723
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds instruction patterns to cover the generic forms of
the conditional branch instructions. This allows the assembler
to support the generic mnemonics.
The compiler will still generate the various specific forms
of the instruction that were already supported.
llvm-svn: 184722
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is currently only limited support for the "absolute" variants
of branch instructions. This patch adds support for the absolute
variants of all branches that are currently otherwise supported.
This requires adding new fixup types so that the correct variant
of relocation type can be selected by the object writer.
While the compiler will continue to usually choose the relative
branch variants, this will allow the asm parser to fully support
the absolute branches, with either immediate (numerical) or
symbolic target addresses.
No change in code generation intended.
llvm-svn: 184721
|
| |
|
|
|
|
|
| |
This adds support for the bd(n)zl and bd(n)zlrl instructions.
The patterns are currently used for the asm parser only.
llvm-svn: 184720
|
| |
|
|
|
|
|
| |
This patch adds support for the conditional variants of bl.
The pattern is currently used by the asm parser only.
llvm-svn: 184719
|
| |
|
|
|
|
|
| |
This patch adds support for blrl and its conditional variants.
The patterns are (currently) used for the asm parser only.
llvm-svn: 184718
|
| |
|
|
|
|
| |
definitions and adds dedicated parser methods to MipsAsmParser. It is the first in a series of patches that should fix the problems with parsing Mips FPU instructions and optimize the code in MipsAsmParser.
llvm-svn: 184716
|
| |
|
|
|
|
| |
{inf,-inf,NaN,-NaN}.
llvm-svn: 184713
|
| |
|
|
|
|
| |
of them.
llvm-svn: 184712
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
only access the significand of FiniteNonZero/NaN floats.
The method significandParts() is a helper method meant to ease access to
APFloat's significand by allowing the user to not need to be aware of whether or
not the APFloat is using memory allocated in the instance itself or in an
external array.
This assert says that one can only access the significand of FiniteNonZero/NaN
floats. This makes it cumbersome and more importantly dangerous when one wishes
to zero out the significand of a zero/infinity value since one will have to deal
with the aforementioned quandary related to how the memory in APFloat is
allocated.
llvm-svn: 184711
|
| |
|
|
|
|
|
|
|
|
|
|
| |
what APFloat is actually using said macro for.
In the context of APFloat, seeing a macro called convolve suggests that APFloat
is using said value in some sort of convolution somewhere in the source code.
This is misleading.
I also added a documentation comment to the macro.
llvm-svn: 184710
|
| |
|
|
|
|
|
| |
When encoded to thumb, VFP instruction and VMOV/VDUP between scalar and
core registers, must have their predicate bit to 0b1110.
llvm-svn: 184707
|
| |
|
|
| |
llvm-svn: 184706
|
| |
|
|
|
|
|
| |
Sorry for the unit test churn. I'll try to make the change permanently
next time.
llvm-svn: 184705
|
| |
|
|
|
|
|
| |
In thumb1, NOP is a pseudo-instruction equivalent to mov r8, r8.
However the disassembler should not use this alias.
llvm-svn: 184703
|
| |
|
|
|
|
| |
mask == 0 -> UNPRED
llvm-svn: 184702
|
| |
|
|
| |
llvm-svn: 184701
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
CGSCC pass manager. This should insulate the inlining decisions from the
vectorization decisions, however it may have both compile time and code
size problems so it is just an experimental option right now.
Adding this based on a discussion with Arnold and it seems at least
worth having this flag for us to both run some experiments to see if
this strategy is workable. It may solve some of the regressions seen
with the loop vectorizer.
llvm-svn: 184698
|
| |
|
|
|
|
|
|
| |
This reverts commit cbfa1ca993363ca5c4dbf6c913abc957c584cbac.
We are seeing a stage2 and stage3 miscompare on some dragonegg bots.
llvm-svn: 184690
|
| |
|
|
|
|
|
|
|
| |
exponent_t is only used internally in APFloat and no exponent_t values are
exposed via the APFloat API. In light of such conditions it does not make any
sense to gum up the llvm namespace with said type. Plus it makes it clearer that
exponent_t is associated with APFloat.
llvm-svn: 184686
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now no longer need alias analysis - the cases that alias analysis would
handle are now handled as accesses with a large dependence distance.
We can now vectorize loops with simple constant dependence distances.
for (i = 8; i < 256; ++i) {
a[i] = a[i+4] * a[i+8];
}
for (i = 8; i < 256; ++i) {
a[i] = a[i-4] * a[i-8];
}
We would be able to vectorize about 200 more loops (in many cases the cost model
instructs us no to) in the test suite now. Results on x86-64 are a wash.
I have seen one degradation in ammp. Interestingly, the function in which we
now vectorize a loop is never executed so we probably see some instruction
cache effects. There is a 2% improvement in h264ref. There is one or the other
TSCV loop kernel that speeds up.
radar://13681598
llvm-svn: 184685
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This class checks dependences by subtracting two Scalar Evolution access
functions allowing us to catch very simple linear dependences.
The checker assumes source order in determining whether vectorization is safe.
We currently don't reorder accesses.
Positive true dependencies need to be a multiple of VF otherwise we impede
store-load forwarding.
llvm-svn: 184684
|
| |
|
|
|
|
|
| |
Sets of dependent accesses are built by unioning sets based on underlying
objects. This class will be used by the upcoming dependence checker.
llvm-svn: 184683
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Untill now we detected the vectorizable tree and evaluated the cost of the
entire tree. With this patch we can decide to trim-out branches of the tree
that are not profitable to vectorizer.
Also, increase the max depth from 6 to 12. In the worse possible case where all
of the code is made of diamond-shaped graph this can bring the cost to 2**10,
but diamonds are not very common.
llvm-svn: 184681
|
| |
|
|
|
|
|
|
|
|
|
| |
This makes it possible to write unit tests that are less susceptible
to minor code motion, particularly copy placement. block-placement.ll
covers this case with -pre-RA-sched=source which will soon be
default. One incorrectly named block is already fixed, but without
this fix, enabling new coalescing and scheduling would cause more
failures.
llvm-svn: 184680
|
| |
|
|
|
|
|
|
| |
sequences.
Make sure that we don't replace and RAUW two sequences if one does not dominate the other.
llvm-svn: 184674
|
| |
|
|
|
|
| |
The RAII builder location guard is saving a reference to instructions, so we can't erase instructions during vectorization.
llvm-svn: 184671
|
| |
|
|
|
|
| |
ULEB128/SLEB128 generation
llvm-svn: 184669
|
| |
|
|
|
|
|
|
| |
This is an awful implementation of the target hook. But we don't have
abstractions yet for common machine ops, and I don't see any quick way
to make it table-driven.
llvm-svn: 184664
|
| |
|
|
| |
llvm-svn: 184660
|
| |
|
|
|
|
|
|
|
| |
Rewrote the SLP-vectorization as a whole-function vectorization pass. It is now able to vectorize chains across multiple basic blocks.
It still does not vectorize PHIs, but this should be easy to do now that we scan the entire function.
I removed the support for extracting values from trees.
We are now able to vectorize more programs, but there are some serious regressions in many workloads (such as flops-6 and mandel-2).
llvm-svn: 184647
|
| |
|
|
|
|
| |
and parameter packs
llvm-svn: 184643
|
| |
|
|
| |
llvm-svn: 184642
|
| |
|
|
|
|
|
|
| |
argument."
It doesn't work as I intended it to. This reverts commit r184638.
llvm-svn: 184641
|
| |
|
|
|
|
| |
It has become an expensive operation. No functionality change.
llvm-svn: 184638
|
| |
|
|
|
|
|
|
|
| |
Although in reality the symbol table in ELF resides in a section, the
standard requires that there be no more than one SHT_SYMTAB. To enforce
this constraint, it is cleaner to group all the symbols under a
top-level `Symbols` key on the object file.
llvm-svn: 184627
|
| |
|
|
|
|
|
|
|
| |
We have no targets on trunk that bundle before regalloc. However, we
have been advertising regalloc as bundle safe for use with out-of-tree
targets. We need to at least contain the parts of the code that are
still unsafe.
llvm-svn: 184620
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A FastISel optimization was causing us to emit no information for such
parameters & when they go missing we end up emitting a different
function type. By avoiding that shortcut we not only get types correct
(very important) but also location information (handy) - even if it's
only live at the start of a function & may be clobbered later.
Reviewed/discussion by Evan Cheng & Dan Gohman.
llvm-svn: 184604
|
| |
|
|
|
|
| |
Thanks to Bill Wendling for pointing this out!
llvm-svn: 184593
|