|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This pass performs if-conversion on SSA form machine code by
speculatively executing both sides of the branch and using a cmov
instruction to select the result. This can help lower the number of
branch mispredictions on architectures like x86 that don't have
predicable instructions.
The current implementation is very aggressive, and causes regressions on
mosts tests. It needs good heuristics that have yet to be implemented.
llvm-svn: 159694 | 
| | 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | It appears to have caught a use-after-free introduced as by r159567
and/or friends which call 'addPass' from many more places. The bug in
'addPass' doesn't appear to be new, and was spotted by inspection when
ASan shown a bright light of a stacktrace at these functions.
Hopefully this will fix the ASan failure -- I have no test case other
than running an ASan-built clang over the test suite.
llvm-svn: 159614 | 
| | 
| 
| 
| 
| 
| | instead.
llvm-svn: 159611 | 
| | 
| 
| 
| | llvm-svn: 159599 | 
| | 
| 
| 
| 
| 
| | Part of rdar://6880388 and rdar://11766377
llvm-svn: 159590 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This is still a work in progress but I believe it is currently good enough
to fix PR13122 "Need unit test driver for codegen IR passes".  For example,
you can run llc with -stop-after=loop-reduce to have it dump out the IR after
running LSR.  Serializing machine-level IR is not yet supported but we have
some patches in progress for that.
The plan is to serialize the IR to a YAML file, containing separate sections
for the LLVM IR, machine-level IR, and whatever other info is needed.  Chad
suggested that we stash the stop-after pass in the YAML file and use that
instead of the start-after option to figure out where to restart the
compilation.  I think that's a great idea, but since it's not implemented yet
I put the -start-after option into this patch for testing purposes.
llvm-svn: 159570 | 
| | 
| 
| 
| | llvm-svn: 159569 | 
| | 
| 
| 
| 
| 
| 
| | This makes it possible to just use a zero value to represent "no pass", so
the phony NoPassID global variable is no longer needed.
llvm-svn: 159568 | 
| | 
| 
| 
| 
| 
| 
| 
| | This is a preliminary step toward having TargetPassConfig be able to
start and stop the compilation at specified passes for unit testing
and debugging.  No functionality change.
llvm-svn: 159567 | 
| | 
| 
| 
| 
| 
| 
| | register does not have multiple definitions. Modified TwoAddressInstructionPass
to use getUniqueVRegDef instead of getVRegDef.
llvm-svn: 159545 | 
| | 
| 
| 
| 
| 
| | Reapplies r159406 with minor cleanup. The regressions appear to have been spurious.
llvm-svn: 159541 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | - 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 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | implicit_def, the other instruction can be anything, including instructions
that define multiple values. Be careful about that and don't assume what operand
0 is.
Fixes pr13249.
llvm-svn: 159509 | 
| | 
| 
| 
| 
| 
| | a reduced testcase, but this fixes pr13209.
llvm-svn: 159479 | 
| | 
| 
| 
| 
| 
| | instructions with two register operands.
llvm-svn: 159465 | 
| | 
| 
| 
| 
| 
| 
| | When a local virtual register is made global, make sure to clear any
existing kill flags.
llvm-svn: 159461 | 
| | 
| 
| 
| 
| 
| 
| | This would previously get reported as the misleading "Virtual register
def doesn't dominate all uses."
llvm-svn: 159460 | 
| | 
| 
| 
| 
| 
| | This comes in handy during peephole optimization.
llvm-svn: 159453 | 
| | 
| 
| 
| | llvm-svn: 159433 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This was always part of the VMCore library out of necessity -- it deals
entirely in the IR. The .cpp file in fact was already part of the VMCore
library. This is just a mechanical move.
I've tried to go through and re-apply the coding standard's preferred
header sort, but at 40-ish files, I may have gotten some wrong. Please
let me know if so.
I'll be committing the corresponding updates to Clang and Polly, and
Duncan has DragonEgg.
Thanks to Bill and Eric for giving the green light for this bit of cleanup.
llvm-svn: 159421 | 
| | 
| 
| 
| 
| 
| 
| | (a.k.a. MDNodes). The module doesn't belong in Analysis. Move it to the VMCore
instead.
llvm-svn: 159414 | 
| | 
| 
| 
| 
| 
| | This reverts commit r159406. I noticed a performance regression so I'll back out for now.
llvm-svn: 159411 | 
| | 
| 
| 
| | llvm-svn: 159408 | 
| | 
| 
| 
| | llvm-svn: 159407 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The TargetInstrInfo::getNumMicroOps API does not change, but soon it
will be used by MachineScheduler. Now each subtarget can specify the
number of micro-ops per itinerary class. For ARM, this is currently
always dynamic (-1), because it is used for load/store multiple which
depends on the number of register operands.
Zero is now a valid number of micro-ops. This can be used for
nop pseudo-instructions or instructions that the hardware can squash
during dispatch.
llvm-svn: 159406 | 
| | 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| 
| 
| | Such passes can be used to tweak the register assignments in a
target-dependent way, for example to avoid write-after-write
dependencies.
llvm-svn: 159209 | 
| | 
| 
| 
| 
| 
| 
| | very first (and worst) placement algorithm. These should now more
accurately reflect the reality of the pass.
llvm-svn: 159185 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The primary advantage is that loop optimizations will be applied in a
stable order. This helps debugging and unit test creation. It is also
a better overall implementation without pathologically bad performance
on deep functions.
On large functions (llvm-stress --size=200000 | opt -loops)
Before: 0.1263s
After:  0.0225s
On deep functions (after tweaking llvm-stress, thanks Nadav):
Before: 0.2281s
After:  0.0227s
See r158790 for more comments.
The loop tree is now consistently generated in forward order, but loop
passes are applied in reverse order over the program. If we have a
loop optimization that prefers forward order, that can easily be
achieved by adding a different type of LoopPassManager.
llvm-svn: 159183 | 
| | 
| 
| 
| 
| 
| | type. No test case. Found by inspection.
llvm-svn: 159179 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Verify that all paths from the entry block to a virtual register read
pass through a def. Enable this check even when MRI->isSSA() is false.
Verify that the live range of a virtual register is live out of all
predecessor blocks, even for PHI-values.
This requires that PHIElimination sometimes inserts IMPLICIT_DEF
instruction in predecessor blocks.
llvm-svn: 159150 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Implicitly defined virtual registers can simply have the <undef> bit set
on all uses, and copies can be turned into implicit defs recursively.
Physical registers are a bit trickier. We handle the common case where a
physreg def is used by a nearby instruction in the same basic block. For
more complicated cases, just leave the IMPLICIT_DEF instruction in.
llvm-svn: 159149 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | When a PHI use is <undef>, don't emit a copy in the predecessor block,
but insert an IMPLICIT_DEF instruction instead. This ensures that
virtual register uses are always jointly dominated by defs, even if some
of them are IMPLICIT_DEF.
llvm-svn: 159121 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | When the source register to a 2-addr instruction is undefined, there is
no need to attempt any transformations - simply replace the source
register with the destination register.
This also comes up when lowering IMPLICIT_DEF instructions - make sure
the <undef> flag is moved to the new partial register def operand:
  %vreg8<def> = INSERT_SUBREG %vreg9<undef>, %vreg0<kill>, sub_16bit
rewrite undef:
  %vreg8<def> = INSERT_SUBREG %vreg8<undef>, %vreg0<kill>, sub_16bit
convert to:
  %vreg8:sub_16bit<def,read-undef> = COPY %vreg0<kill>
llvm-svn: 159120 | 
| | 
| 
| 
| | llvm-svn: 159112 | 
| | 
| 
| 
| | llvm-svn: 159092 | 
| | 
| 
| 
| 
| 
| 
| 
| | It's simple: Don't treat <undef> operands as uses, and don't assume a
virtual register has a defining instruction unless a real use has been
seen.
llvm-svn: 159061 | 
| | 
| 
| 
| 
| 
| | The ProcessImplicitDefs class can be local to its implementation file.
llvm-svn: 159041 | 
| | 
| 
| 
| | llvm-svn: 159039 | 
| | 
| 
| 
| | llvm-svn: 159030 | 
| | 
| 
| 
| 
| 
| | It is both smaller and faster than DenseMap.
llvm-svn: 159029 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Original commit message:
    Allow up to 64 functional units per processor itinerary.
    This patch changes the type used to hold the FU bitset from unsigned to uint64_t.
    This will be needed for some upcoming PowerPC itineraries.
llvm-svn: 159027 | 
| | 
| 
| 
| 
| 
| | Don't try to print out the live range of a physreg.
llvm-svn: 159021 | 
| | 
| 
| 
| 
| 
| 
| | DBG_VALUE instructions could be referring to non-existing virtual
registers.
llvm-svn: 159020 | 
| | 
| 
| 
| 
| 
| 
| | There is no need to check for physreg live ranges. They don't exist any
more.
llvm-svn: 159019 | 
| | 
| 
| 
| 
| 
| | Everyone is using on-demand regunit ranges now.
llvm-svn: 159018 |