- Jun 24, 2013
-
-
Eric Christopher authored
llvm-svn: 184788
-
Adrian Prantl authored
llvm-svn: 184783
-
Eric Christopher authored
never modified. No functional change. llvm-svn: 184781
-
Ulrich Weigand authored
[PowerPC] Support some miscellaneous mnemonics in the asm parser This adds support for the following extended mnemonics: xnop mr. not not. la llvm-svn: 184767
-
David Blaikie authored
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
-
Benjamin Kramer authored
llvm-svn: 184758
-
Aaron Watry authored
our -> or llvm-svn: 184756
-
Ulrich Weigand authored
[PowerPC] Add predicted forms of branches 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
-
Nadav Rotem authored
llvm-svn: 184749
-
NAKAMURA Takumi authored
NVPTXTargetObjectFile.h: Initialize some pointers as NULL in the constructor of NVPTXTargetObjectFile. ~NVPTXTargetObjectFile() tries to delete them. It caused crash on some hosts since r184595. llvm-svn: 184728
-
Ulrich Weigand authored
[PowerPC] Add t/f branch mnemonics to asm parser 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
-
Arnold Schwaighofer authored
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
-
Arnold Schwaighofer authored
We are creating the runtime checks using this set so we need a deterministic iteration order. llvm-svn: 184723
-
Ulrich Weigand authored
[PowerPC] Support generic conditional branches in asm parser 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
-
Ulrich Weigand authored
[PowerPC] Support absolute branches 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
-
Ulrich Weigand authored
[PowerPC] Support bd(n)zl and bd(n)zlrl 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
-
Ulrich Weigand authored
[PowerPC] Support b(cond)l in the asm parser This patch adds support for the conditional variants of bl. The pattern is currently used by the asm parser only. llvm-svn: 184719
-
Ulrich Weigand authored
[PowerPC] Support blrl and variants in the asm parser This patch adds support for blrl and its conditional variants. The patterns are (currently) used for the asm parser only. llvm-svn: 184718
-
Vladimir Medic authored
This patch introduces RegisterOperand class into Mips FPU instruction 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
-
Michael Gottesman authored
llvm-svn: 184713
-
Michael Gottesman authored
llvm-svn: 184712
-
Michael Gottesman authored
[APFloat] Removed a assert from significandParts() which says that one can 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
-
Michael Gottesman authored
[APFloat] Rename macro convolve => PackCategoriesIntoKey so that it is clear 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
-
Amaury de la Vieuville authored
When encoded to thumb, VFP instruction and VMOV/VDUP between scalar and core registers, must have their predicate bit to 0b1110. llvm-svn: 184707
-
Amaury de la Vieuville authored
llvm-svn: 184706
-
Andrew Trick authored
Sorry for the unit test churn. I'll try to make the change permanently next time. llvm-svn: 184705
-
Amaury de la Vieuville authored
In thumb1, NOP is a pseudo-instruction equivalent to mov r8, r8. However the disassembler should not use this alias. llvm-svn: 184703
-
Amaury de la Vieuville authored
mask == 0 -> UNPRED llvm-svn: 184702
-
Amaury de la Vieuville authored
llvm-svn: 184701
-
Chandler Carruth authored
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
-
Arnold Schwaighofer authored
This reverts commit cbfa1ca993363ca5c4dbf6c913abc957c584cbac. We are seeing a stage2 and stage3 miscompare on some dragonegg bots. llvm-svn: 184690
-
Michael Gottesman authored
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
-
Arnold Schwaighofer authored
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
-
Arnold Schwaighofer authored
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
-
Arnold Schwaighofer authored
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
-
Nadav Rotem authored
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
-
Andrew Trick authored
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
-
- Jun 23, 2013
-
-
Nadav Rotem authored
Make sure that we don't replace and RAUW two sequences if one does not dominate the other. llvm-svn: 184674
-
Nadav Rotem authored
The RAII builder location guard is saving a reference to instructions, so we can't erase instructions during vectorization. llvm-svn: 184671
-
David Blaikie authored
llvm-svn: 184669
-