| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
an MVT::i1, i.e. before type legalization.
This is a speculative fix for a problem on Mips reported by Akira Hatanaka.
llvm-svn: 160036
|
|
|
|
|
|
|
|
|
| |
multiple scalars and insert them into a vector. Next, we shuffle the elements
into the correct places, as before.
Also fix a small dagcombine bug in SimplifyBinOpWithSameOpcodeHands, when the
migration of bitcasts happened too late in the SelectionDAG process.
llvm-svn: 159991
|
|
|
|
|
|
|
|
| |
move, since there are only two possible values.
Previously, this would become an integer extension operation, followed by a real integer->float conversion.
llvm-svn: 159957
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
subtarget CPU descriptions and support new features of
MachineScheduler.
MachineModel has three categories of data:
1) Basic properties for coarse grained instruction cost model.
2) Scheduler Read/Write resources for simple per-opcode and operand cost model (TBD).
3) Instruction itineraties for detailed per-cycle reservation tables.
These will all live side-by-side. Any subtarget can use any
combination of them. Instruction itineraries will not change in the
near term. In the long run, I expect them to only be relevant for
in-order VLIW machines that have complex contraints and require a
precise scheduling/bundling model. Once itineraries are only actively
used by VLIW-ish targets, they could be replaced by something more
appropriate for those targets.
This tablegen backend rewrite sets things up for introducing
MachineModel type #2: per opcode/operand cost model.
llvm-svn: 159891
|
|
|
|
| |
llvm-svn: 159839
|
|
|
|
| |
llvm-svn: 159837
|
|
|
|
|
|
| |
corresponding clang warning.
llvm-svn: 159742
|
|
|
|
|
|
| |
booleans. Patch by James Benton.
llvm-svn: 159739
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also allow trailing register mask operands on non-variadic both
MachineSDNodes and MachineInstrs.
The extra physreg RegisterSDNode operands are added to the MI as
<imp-use> operands. This makes it possible to have non-variadic call
instructions.
Call and return instructions really are non-variadic, the argument
registers should only be used implicitly - they are not part of the
encoding.
llvm-svn: 159727
|
|
|
|
|
|
|
|
|
|
| |
be used here:
IntegersSubsetMapping
- Replaced type of Items field from std::list with std::map. In neares future I'll test it with DenseMap and do the correspond replacement
if possible.
llvm-svn: 159703
|
|
|
|
|
|
|
|
| |
IntegersSubsetMapping
- Replaced type of Items field from std::list with std::map. In neares future I'll test it with DenseMap and do the correspond replacement
if possible.
llvm-svn: 159659
|
|
|
|
|
|
| |
This reverts commit b2833d9dcba88c6f0520cad760619200adc0442c.
llvm-svn: 159618
|
|
|
|
|
|
| |
instead.
llvm-svn: 159611
|
|
|
|
|
|
| |
Part of rdar://6880388 and rdar://11766377
llvm-svn: 159590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Changed isSingleNumber method behaviour. Now this flag is calculated on demand.
IntegersSubsetMapping
- Optimized diff operation.
- Replaced type of Items field from std::list with std::map.
- Added new methods:
bool isOverlapped(self &RHS)
void add(self& RHS, SuccessorClass *S)
void detachCase(self& NewMapping, SuccessorClass *Succ)
void removeCase(SuccessorClass *Succ)
SuccessorClass *findSuccessor(const IntTy& Val)
const IntTy* getCaseSingleNumber(SuccessorClass *Succ)
IntegersSubsetTest
- DiffTest: Added checks for successors.
SimplifyCFG
Updated SwitchInst usage (now it is case-ragnes compatible) for
- SimplifyEqualityComparisonWithOnlyPredecessor
- FoldValueComparisonIntoPredecessors
llvm-svn: 159527
|
|
|
|
|
|
|
| |
When a local virtual register is made global, make sure to clear any
existing kill flags.
llvm-svn: 159461
|
|
|
|
|
|
| |
CodeGen to ignore calls to it
llvm-svn: 159383
|
|
|
|
|
|
|
|
|
|
|
| |
Teach vector legalization how to honor Promote for int to float
conversions. The code checking whether to promote the operation knew
to look at the operand, but the actual promotion code didn't. This
fixes that. The operand is promoted up via [zs]ext.
rdar://11762659
llvm-svn: 159378
|
|
|
|
|
|
|
|
|
| |
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.
The reasoning is because the DebugInfo module is simply an interface to the
debug info MDNodes and has nothing to do with analysis.
llvm-svn: 159312
|
|
|
|
|
|
| |
type. No test case. Found by inspection.
llvm-svn: 159179
|
|
|
|
| |
llvm-svn: 159112
|
|
|
|
| |
llvm-svn: 159092
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
boolean flag to an enum: { Fast, Standard, Strict } (default = Standard).
This option controls the creation by optimizations of fused FP ops that store
intermediate results in higher precision than IEEE allows (E.g. FMAs). The
behavior of this option is intended to match the behaviour specified by a
soon-to-be-introduced frontend flag: '-ffuse-fp-ops'.
Fast mode - allows formation of fused FP ops whenever they're profitable.
Standard mode - allow fusion only for 'blessed' FP ops. At present the only
blessed op is the fmuladd intrinsic. In the future more blessed ops may be
added.
Strict mode - allow fusion only if/when it can be proven that the excess
precision won't effect the result.
Note: This option only controls formation of fused ops by the optimizers. Fused
operations that are explicitly requested (e.g. FMA via the llvm.fma.* intrinsic)
will always be honored, regardless of the value of this option.
Internally TargetOptions::AllowExcessFPPrecision has been replaced by
TargetOptions::AllowFPOpFusion.
llvm-svn: 158956
|
|
|
|
| |
llvm-svn: 158927
|
|
|
|
|
|
|
|
| |
_umodsi3 libcalls if they have the same arguments. This optimization
was apparently broken if one of the node was replaced in place.
rdar://11714607
llvm-svn: 158900
|
|
|
|
|
|
| |
node is removed. Sorry, no test case. Foudn it by inspection of the code
llvm-svn: 158839
|
|
|
|
|
|
| |
The test case for this will come with the PPC indexed preinc loads commit.
llvm-svn: 158822
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds DAG combines to form FMAs from pairs of FADD + FMUL or
FSUB + FMUL. The combines are performed when:
(a) Either
AllowExcessFPPrecision option (-enable-excess-fp-precision for llc)
OR
UnsafeFPMath option (-enable-unsafe-fp-math)
are set, and
(b) TargetLoweringInfo::isFMAFasterThanMulAndAdd(VT) is true for the type of
the FADD/FSUB, and
(c) The FMUL only has one user (the FADD/FSUB).
If your target has fast FMA instructions you can make use of these combines by
overriding TargetLoweringInfo::isFMAFasterThanMulAndAdd(VT) to return true for
types supported by your FMA instruction, and adding patterns to match ISD::FMA
to your FMA instructions.
llvm-svn: 158757
|
|
|
|
| |
llvm-svn: 158467
|
|
|
|
|
|
|
| |
Minimum latency determines per-cycle scheduling groups.
Expected latency determines critical path and cost.
llvm-svn: 158021
|
|
|
|
|
|
|
|
|
|
|
|
| |
expression (a * b + c) that can be implemented as a fused multiply-add (fma)
if the target determines that this will be more efficient. This intrinsic
will be used to implement FP_CONTRACT support and an aggressive FMA formation
mode.
If your target has a fast FMA instruction you should override the
isFMAFasterThanMulAndAdd method in TargetLowering to return true.
llvm-svn: 158014
|
|
|
|
|
|
|
|
| |
This allows a subtarget to explicitly specify the issue width and
other properties without providing pipeline stage details for every
instruction.
llvm-svn: 157979
|
|
|
|
|
|
|
|
| |
itinerary.
Use ILP heuristics for long latency instrs if no scoreboard exists.
llvm-svn: 157978
|
|
|
|
| |
llvm-svn: 157925
|
|
|
|
| |
llvm-svn: 157885
|
|
|
|
|
|
| |
IntRange converted from struct to class. So main change everywhere is replacement of ".Low/High" with ".getLow/getHigh()"
llvm-svn: 157884
|
|
|
|
|
|
| |
IntegersSubsetGeneric, IntegersSubsetMapping: added IntTy template parameter, that allows use either APInt or IntItem. This change allows to write unittest for these classes.
llvm-svn: 157880
|
|
|
|
|
|
|
| |
Check that the SDValue TargetLowering::LowerOperation returns is not null
before replacing the original node with the returned node.
llvm-svn: 157873
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No functional change intended.
Sorry for the churn. The iterator classes are supposed to help avoid
giant commits like this one in the future. The TableGen-produced
register lists are getting quite large, and it may be necessary to
change the table representation.
This makes it possible to do so without changing all clients (again).
llvm-svn: 157854
|
|
|
|
|
|
| |
MCRegAliasIterator can include Reg itself in the list.
llvm-svn: 157848
|
|
|
|
|
|
|
|
|
| |
Factor out the expansion code into a function.
This change is to be enabled in clang.
rdar://9877866
llvm-svn: 157830
|
|
|
|
|
|
|
| |
IntegersSubset devided into IntegersSubsetGeneric and into IntegersSubset itself. The first has no references to ConstantInt and works with IntItem only.
IntegersSubsetMapping also made generic. Here added second template parameter "IntegersSubsetTy" that allows to use on of two IntegersSubset types described below.
llvm-svn: 157815
|
|
|
|
|
|
| |
wrote and the usual LLVM convention.
llvm-svn: 157708
|
|
|
|
|
|
| |
operands of an FMA node.
llvm-svn: 157707
|
|
|
|
|
|
| |
IntegersSubsetMapping.
llvm-svn: 157612
|
|
|
|
| |
llvm-svn: 157594
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implemented IntItem - the wrapper around APInt. Why not to use APInt item directly right now?
1. It will very difficult to implement case ranges as series of small patches. We got several large and heavy patches. Each patch will about 90-120 kb. If you replace ConstantInt with APInt in SwitchInst you will need to changes at the same time all Readers,Writers and absolutely all passes that uses SwitchInst.
2. We can implement APInt pool inside and save memory space. E.g. we use several switches that works with 256 bit items (switch on signatures, or strings). We can avoid value duplicates in this case.
3. IntItem can be easyly easily replaced with APInt.
4. Currenly we can interpret IntItem both as ConstantInt and as APInt. It allows to provide SwitchInst methods that works with ConstantInt for non-updated passes.
Why I need it right now? Currently I need to update SimplifyCFG pass (EqualityComparisons). I need to work with APInts directly a lot, so peaces of code
ConstantInt *V = ...;
if (V->getValue().ugt(AnotherV->getValue()) {
...
}
will look awful. Much more better this way:
IntItem V = ConstantIntVal->getValue();
if (AnotherV < V) {
}
Of course any reviews are welcome.
P.S.: I'm also going to rename ConstantRangesSet to IntegersSubset, and CRSBuilder to IntegersSubsetMapping (allows to map individual subsets of integers to the BasicBlocks).
Since in future these classes will founded on APInt, it will possible to use them in more generic ways.
llvm-svn: 157576
|
|
|
|
| |
llvm-svn: 157527
|
|
|
|
|
|
|
| |
This is obviosly right but I don't see how to do this with proper vector
iterators without building a horrible mess of workarounds.
llvm-svn: 157526
|
|
|
|
|
|
| |
vector.begin()-1 is invalid too.
llvm-svn: 157525
|