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 ...

RegisterScavenger: Take a reference as enterBasicBlock() argument.

Make it obvious that the argument cannot be nullptr.
Remove an unnecessary nullptr check in initRegState.

llvm-svn: 265511

Don't use potentially invalidated iterator

If the lhs is evaluated before the rhs, FuncletI's operator-> can trigger the

assert(isHandleInSync() && "invalid iterator access!");

at include/llvm/A

Don't use potentially invalidated iterator

If the lhs is evaluated before the rhs, FuncletI's operator-> can trigger the

assert(isHandleInSync() && "invalid iterator access!");

at include/llvm/ADT/DenseMap.h:1061. (Happens e.g. when compiled with GCC 6.)

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

llvm-svn: 265024

show more ...

Test commit access

llvm-svn: 263165

[BranchFolding] Change function name related with merging MMOs. NFC

Summary:
Removing MMOs is not our prefer behavior any more.

Reviewers: mcrosier, reames

Differential Revision: http://reviews

[BranchFolding] Change function name related with merging MMOs. NFC

Summary:
Removing MMOs is not our prefer behavior any more.

Reviewers: mcrosier, reames

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

llvm-svn: 262580

show more ...

CodeGen: Remove an iterator => pointer conversion, NFC

Part of PR26753.

llvm-svn: 262154

CodeGen: Change MachineInstr to use MachineInstr&, NFC

Change MachineInstr API to prefer MachineInstr& over MachineInstr*
whenever the parameter is expected to be non-null. Slowly inching
toward be

CodeGen: Change MachineInstr to use MachineInstr&, NFC

Change MachineInstr API to prefer MachineInstr& over MachineInstr*
whenever the parameter is expected to be non-null. Slowly inching
toward being able to fix PR26753.

llvm-svn: 262149

show more ...

CodeGen: Use MachineInstr& in HashMachineInstr, NFC

Also update HashEndOfMBB to take MachineBasicBlock&.

llvm-svn: 262146

CodeGen: TII: Take MachineInstr& in predicate API, NFC

Change TargetInstrInfo API to take `MachineInstr&` instead of
`MachineInstr*` in the functions related to predicated instructions
(I'll try to

CodeGen: TII: Take MachineInstr& in predicate API, NFC

Change TargetInstrInfo API to take `MachineInstr&` instead of
`MachineInstr*` in the functions related to predicated instructions
(I'll try to come back later and get some of the rest). All of these
functions require non-null parameters already, so references are more
clear. As a bonus, this happens to factor away a host of implicit
iterator => pointer conversions.

No functionality change intended.

llvm-svn: 261605

show more ...

[BranchFolding] Set correct mem refs (2nd try)

This is a recommit of r257253 which was reverted in r257270.
Previous testcase can make failure on some targets due to using opt with O3 option.

Origi

[BranchFolding] Set correct mem refs (2nd try)

This is a recommit of r257253 which was reverted in r257270.
Previous testcase can make failure on some targets due to using opt with O3 option.

Original Summary:
Merge MBBICommon and MBBI's MMOs.

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

llvm-svn: 257317

show more ...

Revert "[BranchFolding] Set correct mem refs"

This reverts commit 1ff11017d2669b933b29fcbb6451cfcda34ad693.

llvm-svn: 257270

[BranchFolding] Set correct mem refs

Merge MBBICommon and MBBI's MMOs.

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

llvm-svn: 257253

Consolidate MemRefs handling from BranchFolding and correct latent bug

Move the logic from BranchFolding to use the shared infrastructure for merging MMOs introduced in 256909. This has the effect o

Consolidate MemRefs handling from BranchFolding and correct latent bug

Move the logic from BranchFolding to use the shared infrastructure for merging MMOs introduced in 256909. This has the effect of making BranchFolding more capable.

In the process, fix a latent bug. The existing handling for merging didn't handle the case where one of the instructions being merged had overflowed and dropped MemRefs. This was a latent bug in the places the code was commoned from, but potentially reachable in BranchFolding.

Once this is in, we're left with a single place to consider implementing MMO unique-ing as proposed in http://reviews.llvm.org/D15230.

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

llvm-svn: 256966

show more ...

[MemOperands] Clarify code around dropping memory operands [NFC]

Clarify a comment about what it means to drop memory operands from an instruction. While I'm adding change the name of the method sl

[MemOperands] Clarify code around dropping memory operands [NFC]

Clarify a comment about what it means to drop memory operands from an instruction. While I'm adding change the name of the method slightly to make it a bit more clear what's going on when reading calling code.

llvm-svn: 256346

show more ...

Revert "[BranchFolding] Merge MMOs during tail merge"

This reverts commit r254694.

It broke bootstrap.

llvm-svn: 254700

[BranchFolding] Merge MMOs during tail merge

Summary:
If we remove the MMOs from Load/Store instructions,
they are treated as volatile. This makes other optimization passes unhappy.
eg. Load/Store O

[BranchFolding] Merge MMOs during tail merge

Summary:
If we remove the MMOs from Load/Store instructions,
they are treated as volatile. This makes other optimization passes unhappy.
eg. Load/Store Optimization

So, it looks better to merge, not remove.

Reviewers: gberry, mcrosier

Subscribers: gberry, llvm-commits

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

llvm-svn: 254694

show more ...

(no commit message)

llvm-svn: 254686

[WinEH] Avoid infinite loop in BranchFolding for multiple single block funclets

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

llvm-svn: 254629

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 ...

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

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

1. New in

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

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: 254348

show more ...

[WinEH] Don't forward branches across empty EH pad BBs

For really simple SEH catchpads, we tried to forward the invoke unwind
edge across the empty block.

llvm-svn: 252822

Refactor: Simplify boolean conditional return statements in lib/CodeGen.

Patch by Richard.

llvm-svn: 251213

CodeGen: Remove implicit conversions from Analysis and BranchFolding

Remove a few more implicit ilist iterator conversions, this time from
Analysis.cpp and BranchFolding.cpp.

I added a few overload

CodeGen: Remove implicit conversions from Analysis and BranchFolding

Remove a few more implicit ilist iterator conversions, this time from
Analysis.cpp and BranchFolding.cpp.

I added a few overloads for `remove()` and `erase()`, which quite
naturally take pointers as well as iterators as parameters. This will
reduce the churn at least in the short term, but I don't really have a
problem with these existing for longer.

llvm-svn: 249867

show more ...

[WinEH] Permit branch folding in the face of funclets

Track which basic blocks belong to which funclets. Permit branch
folding to fire but only if it can prove that doing so will not cause
code in

[WinEH] Permit branch folding in the face of funclets

Track which basic blocks belong to which funclets. Permit branch
folding to fire but only if it can prove that doing so will not cause
code in one funclet to be reused in another.

llvm-svn: 249257

show more ...