[Layout] Add a new option (NFC)

Currently cost based loop rotation algo can only be turned on with
two conditions: the function has real profile data, and -precise-rotation-cost
flag is turned on. T

[Layout] Add a new option (NFC)

Currently cost based loop rotation algo can only be turned on with
two conditions: the function has real profile data, and -precise-rotation-cost
flag is turned on. This is not convenient for developers to experiment
when profile is not available. Add a new option to force the new
rotation algorithm -force-precise-rotation-cost

llvm-svn: 269266

show more ...

Add opt-bisect support to additional passes that can be skipped

Differential Revision: http://reviews.llvm.org/D19882

llvm-svn: 268457

[MachineBlockPlacement] Let the target optimize the branches at the end.

After the layout of the basic blocks is set, the target may be able to get rid
of unconditional branches to fallthrough block

[MachineBlockPlacement] Let the target optimize the branches at the end.

After the layout of the basic blocks is set, the target may be able to get rid
of unconditional branches to fallthrough blocks that the generic code does not
catch. This happens any time TargetInstrInfo::AnalyzeBranch is not able to
analyze all the branches involved in the terminators sequence, while still
understanding a few of them.

In such situation, AnalyzeBranch can directly modify the branches if it has been
instructed to do so.

This patch takes advantage of that.

llvm-svn: 268328

show more ...

[MBP] Use Function::optForSize() instead of checking OptimizeForSize directly.

Fix a FIXME. Disable loop alignment if compiled with -Oz now.

llvm-svn: 268121

[MBP] Split placement and alignment into two functions. NFC.

Cut and Paste.

llvm-svn: 268067

Re-commit optimization bisect support (r267022) without new pass manager support.

The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the

Re-commit optimization bisect support (r267022) without new pass manager support.

The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling).

Differential Revision: http://reviews.llvm.org/D19172

llvm-svn: 267231

show more ...

Revert "Initial implementation of optimization bisect support."

This reverts commit r267022, due to an ASan failure:

http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549

llvm-s

Revert "Initial implementation of optimization bisect support."

This reverts commit r267022, due to an ASan failure:

http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549

llvm-svn: 267115

show more ...

Initial implementation of optimization bisect support.

This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to trac

Initial implementation of optimization bisect support.

This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations.

The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used.

The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way.

Differential Revision: http://reviews.llvm.org/D19172

llvm-svn: 267022

show more ...

Do not select EhPad BB in MachineBlockPlacement when there is regular BB to schedule

Summary:
EHPad BB are not entered the classic way and therefor do not need to be placed after their predecessors.

Do not select EhPad BB in MachineBlockPlacement when there is regular BB to schedule

Summary:
EHPad BB are not entered the classic way and therefor do not need to be placed after their predecessors. This patch make sure EHPad BB are not chosen amongst successors to form chains, and are selected as last resort when selecting the best candidate.

EHPad are scheduled in reverse probability order in order to have them flow into each others naturally.

Reviewers: chandlerc, majnemer, rafael, MatzeB, escha, silvas

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D17625

llvm-svn: 265726

show more ...

[BlockPlacement] Remove an unnecessary continue

NFC.

llvm-svn: 265643

[MBP] Remove an unused function parameter

NFC.

llvm-svn: 265642

Revert "[BlockPlacement] Remove an unnecessary continue" and "[MBP] Remove an unused function parameter"

llvm-svn: 265638

[MBP] Remove an unused function parameter

NFC.

llvm-svn: 265596

[BlockPlacement] Remove an unnecessary continue

NFC.

llvm-svn: 265407

Factor out MachineBlockPlacement::fillWorkLists. NFC

Summary: There are places in MachineBlockPlacement where a worklist is filled in pretty much identical way. The code is duplicated. This refactor

Factor out MachineBlockPlacement::fillWorkLists. NFC

Summary: There are places in MachineBlockPlacement where a worklist is filled in pretty much identical way. The code is duplicated. This refactor it so that the same code is used in both scenarii.

Reviewers: chandlerc, majnemer, rafael, MatzeB, escha, silvas

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D18077

llvm-svn: 263495

show more ...

Minor code cleanup. NFC.

llvm-svn: 263196

[MBP] Renaming a confusing variable and add clarifying comments

Was discussed as part of http://reviews.llvm.org/D17830

llvm-svn: 262571

[MBP] Avoid placing random blocks between loop preheader and header

If we have a loop with a rarely taken path, we will prune that from the blocks which get added as part of the loop chain. The prob

[MBP] Avoid placing random blocks between loop preheader and header

If we have a loop with a rarely taken path, we will prune that from the blocks which get added as part of the loop chain. The problem is that we weren't then recognizing the loop chain as schedulable when considering the preheader when forming the function chain. We'd then fall to various non-predecessors before finally scheduling the loop chain (as if the CFG was unnatural.) The net result was that there could be lots of garbage between a loop preheader and the loop, even though we could have directly fallen into the loop. It also meant we separated hot code with regions of colder code.

The particular reason for the rejection of the loop chain was that we were scanning predecessor of the header, seeing the backedge, believing that was a globally more important predecessor (true), but forgetting to account for the fact the backedge precessor was already part of the existing loop chain (oops!.

Differential Revision: http://reviews.llvm.org/D17830

llvm-svn: 262547

show more ...

[MBP] Remove overly verbose debug output

llvm-svn: 262531

[MBP] Adjust debug output to be more focused and approachable

llvm-svn: 262522

Partially revert "Add command line options to force function/loop alignments."

This partially reverts r256571 in favor of the solution in r258409.

llvm-svn: 258421

[BlockPlacement] Add option to align all non-fall-through blocks.

Summary: This option is being added for testing purposes.

Reviewers: mcrosier

Subscribers: mcrosier, llvm-commits

Differential Re

[BlockPlacement] Add option to align all non-fall-through blocks.

Summary: This option is being added for testing purposes.

Reviewers: mcrosier

Subscribers: mcrosier, llvm-commits

Differential Revision: http://reviews.llvm.org/D16410

llvm-svn: 258409

show more ...

Add command line options to force function/loop alignments.

These are being added for testing purposes.
http://reviews.llvm.org/D15648

llvm-svn: 256571

Replace all weight-based interfaces in MBB with probability-based interfaces, and update all uses of old interfaces.

(This is the second attempt to submit this patch. The first caused two assertion

Replace all weight-based interfaces in MBB with probability-based interfaces, and update all uses of old interfaces.

(This is the second attempt to submit this patch. The first caused two assertion
failures and was reverted. See https://llvm.org/bugs/show_bug.cgi?id=25687)

The patch in http://reviews.llvm.org/D13745 is broken into four parts:

1. New interfaces without functional changes (http://reviews.llvm.org/D13908).
2. Use new interfaces in SelectionDAG, while in other passes treat probabilities
as weights (http://reviews.llvm.org/D14361).
3. Use new interfaces in all other passes.
4. Remove old interfaces.

This patch is 3+4 above. In this patch, MBB won't provide weight-based
interfaces any more, which are totally replaced by probability-based ones.
The interface addSuccessor() is redesigned so that the default probability is
unknown. We allow unknown probabilities but don't allow using it together
with known probabilities in successor list. That is to say, we either have a
list of successors with all known probabilities, or all unknown
probabilities. In the latter case, we assume each successor has 1/N
probability where N is the number of successors. An assertion checks if the
user is attempting to add a successor with the disallowed mixed use as stated
above. This can help us catch many misuses.

All uses of weight-based interfaces are now updated to use probability-based
ones.


Differential revision: http://reviews.llvm.org/D14973

llvm-svn: 254377

show more ...

Revert r254348: "Replace all weight-based interfaces in MBB with probability-based interfaces, and update all uses of old interfaces."

and the follow-up r254356: "Fix a bug in MachineBlockPlacement

Revert r254348: "Replace all weight-based interfaces in MBB with probability-based interfaces, and update all uses of old interfaces."

and the follow-up r254356: "Fix a bug in MachineBlockPlacement that may cause assertion failure during BranchProbability construction."

Asserts were firing in Chromium builds. See PR25687.

llvm-svn: 254366

show more ...