History log of /llvm-project/llvm/lib/CodeGen/BranchFolding.cpp (Results 126 – 150 of 442)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# e3256477 25-Oct-2016 Robert Lougher <rob.lougher@gmail.com>

Remove debug location from common tail when tail-merging

The branch folding pass tail merges blocks into a common-tail. However, the
tail retains the debug information from one of the original inpu

Remove debug location from common tail when tail-merging

The branch folding pass tail merges blocks into a common-tail. However, the
tail retains the debug information from one of the original inputs to the
merge (chosen randomly). This is a problem for sampled-based PGO, as hits
on the common-tail will be attributed to whichever block was chosen,
irrespective of which path was actually taken to the common-tail.

This patch fixes the issue by nulling the debug location for the common-tail.

Differential Revision: https://reviews.llvm.org/D25742

llvm-svn: 285093

show more ...


# 8271be9a 12-Oct-2016 Krzysztof Parzyszek <kparzysz@codeaurora.org>

Do not remove implicit defs in BranchFolder

Branch folder removes implicit defs if they are the only non-branching
instructions in a block, and the branches do not use the defined registers.
The pro

Do not remove implicit defs in BranchFolder

Branch folder removes implicit defs if they are the only non-branching
instructions in a block, and the branches do not use the defined registers.
The problem is that in some cases these implicit defs are required for
the liveness information to be correct.

Differential Revision: https://reviews.llvm.org/D25478

llvm-svn: 284036

show more ...


# 4040c0f4 20-Sep-2016 Matthias Braun <matze@braunis.de>

BranchFolder: Fix invalid undef flags after merge.

It is legal to merge instructions with different undef flags; However we
must drop the undef flag from the merged instruction if it isn't present
e

BranchFolder: Fix invalid undef flags after merge.

It is legal to merge instructions with different undef flags; However we
must drop the undef flag from the merged instruction if it isn't present
everywhere.

This fixes http://llvm.org/PR30199

llvm-svn: 281957

show more ...


# 1b9fc8ed 14-Sep-2016 Matt Arsenault <Matthew.Arsenault@amd.com>

Finish renaming remaining analyzeBranch functions

llvm-svn: 281535


# e8e0f5ca 14-Sep-2016 Matt Arsenault <Matthew.Arsenault@amd.com>

Make analyzeBranch family of instruction names consistent

analyzeBranch was renamed to use lowercase first, rename
the related set to match.

llvm-svn: 281506


# b678219a 12-Sep-2016 Ahmed Bougacha <ahmed.bougacha@gmail.com>

[BranchFolding] Unique added live-ins after hoisting code.

We're not supposed to have duplicate live-ins.

llvm-svn: 281224


# 75e25f68 07-Sep-2016 Hans Wennborg <hans@hanshq.net>

X86: Fold tail calls into conditional branches where possible (PR26302)

When branching to a block that immediately tail calls, it is possible to fold
the call directly into the branch if the call is

X86: Fold tail calls into conditional branches where possible (PR26302)

When branching to a block that immediately tail calls, it is possible to fold
the call directly into the branch if the call is direct and there is no stack
adjustment, saving one byte.

Example:

define void @f(i32 %x, i32 %y) {
entry:
%p = icmp eq i32 %x, %y
br i1 %p, label %bb1, label %bb2
bb1:
tail call void @foo()
ret void
bb2:
tail call void @bar()
ret void
}

before:

f:
movl 4(%esp), %eax
cmpl 8(%esp), %eax
jne .LBB0_2
jmp foo
.LBB0_2:
jmp bar

after:

f:
movl 4(%esp), %eax
cmpl 8(%esp), %eax
jne bar
.LBB0_1:
jmp foo

I don't expect any significant size savings from this (on a Clang bootstrap I
saw 288 bytes), but it does make the code a little tighter.

This patch only does 32-bit, but 64-bit would work similarly.

Differential Revision: https://reviews.llvm.org/D24108

llvm-svn: 280832

show more ...


Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2
# 64e42814 18-Aug-2016 Kyle Butt <kyle+llvm@iteratee.net>

Branch Folding: Accept explicit threshold for tail merge size.

This is prep work for allowing the threshold to be different during layout,
and to enforce a single threshold between merging and dupli

Branch Folding: Accept explicit threshold for tail merge size.

This is prep work for allowing the threshold to be different during layout,
and to enforce a single threshold between merging and duplicating during
layout. No observable change intended.

llvm-svn: 279117

show more ...


# 7c4535d1 12-Aug-2016 Haicheng Wu <haicheng@codeaurora.org>

Reapply [BranchFolding] Restrict tail merging loop blocks after MBP

Fixed a bug in the test case.

To fix PR28104, this patch restricts tail merging to blocks that belong to the
same loop after MBP.

Reapply [BranchFolding] Restrict tail merging loop blocks after MBP

Fixed a bug in the test case.

To fix PR28104, this patch restricts tail merging to blocks that belong to the
same loop after MBP.

llvm-svn: 278575

show more ...


# d9cbb160 12-Aug-2016 Haicheng Wu <haicheng@codeaurora.org>

Revert "[BranchFolding] Restrict tail merging loop blocks after MBP"

This reverts commit r278463 because it hits the bot.

llvm-svn: 278484


# ea023720 12-Aug-2016 Haicheng Wu <haicheng@codeaurora.org>

[BranchFolding] Restrict tail merging loop blocks after MBP

To fix PR28014, this patch restricts tail merging to blocks that belong to the
same loop after MBP.

Differential Revision: https://review

[BranchFolding] Restrict tail merging loop blocks after MBP

To fix PR28014, this patch restricts tail merging to blocks that belong to the
same loop after MBP.

Differential Revision: https://reviews.llvm.org/D23191

llvm-svn: 278463

show more ...


# 71b1ca1b 10-Aug-2016 Kyle Butt <kyle+llvm@iteratee.net>

Codegen: Tail Merge: Be less aggressive with special cases.

This change makes it possible for tail-duplication and tail-merging to
be disjoint. By being less aggressive when merging during layout, t

Codegen: Tail Merge: Be less aggressive with special cases.

This change makes it possible for tail-duplication and tail-merging to
be disjoint. By being less aggressive when merging during layout, there are no
overlapping cases between tail-duplication and tail-merging, provided the
thresholds are disjoint.

There is a remaining TODO to benchmark the succ_size() test for non-layout tail
merging.

llvm-svn: 278265

show more ...


Revision tags: llvmorg-3.9.0-rc1
# 9155354f 27-Jul-2016 Andrew Kaylor <andrew.kaylor@intel.com>

Revert EH-specific checks in BranchFolding that were causing blow ups in compile time.

Differential Revision: https://reviews.llvm.org/D22839

llvm-svn: 276898


# 71c30a14 15-Jul-2016 Jacques Pienaar <jpienaar@google.com>

Rename AnalyzeBranch* to analyzeBranch*.

Summary: NFC. Rename AnalyzeBranch/AnalyzeBranchPredicate to analyzeBranch/analyzeBranchPredicate to follow LLVM coding style and be consistent with TargetIn

Rename AnalyzeBranch* to analyzeBranch*.

Summary: NFC. Rename AnalyzeBranch/AnalyzeBranchPredicate to analyzeBranch/analyzeBranchPredicate to follow LLVM coding style and be consistent with TargetInstrInfo's analyzeCompare and analyzeSelect.

Reviewers: tstellarAMD, mcrosier

Subscribers: mcrosier, jholewinski, jfb, arsenm, dschuff, jyknight, dsanders, nemanjai

Differential Revision: https://reviews.llvm.org/D22409

llvm-svn: 275564

show more ...


# aeab09fb 12-Jul-2016 Matthias Braun <matze@braunis.de>

BranchFolding: Use LivePhysReg to update live in lists.

Use LivePhysRegs with a backwards walking algorithm to update live in
lists, this way the results do not depend on the presence of kill flags

BranchFolding: Use LivePhysReg to update live in lists.

Use LivePhysRegs with a backwards walking algorithm to update live in
lists, this way the results do not depend on the presence of kill flags
anymore.

This patch also reduces the number of registers added as live-in.
Previously all pristine registers as well as all sub registers of a
super register were added resulting in unnecessarily large live in
lists. This fixed https://llvm.org/PR25263.

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

llvm-svn: 275201

show more ...


# 83a25792 11-Jul-2016 Kyle Butt <kyle+llvm@iteratee.net>

Codegen: Fix comment in BranchFolding.cpp

Blocks to be tail-merged may share more than one successor. Correct the
comment to state that they share a specific successor, SuccBB, rather
than a single

Codegen: Fix comment in BranchFolding.cpp

Blocks to be tail-merged may share more than one successor. Correct the
comment to state that they share a specific successor, SuccBB, rather
than a single successor, which is not true.

llvm-svn: 275104

show more ...


# 267164df 24-Jun-2016 Kyle Butt <kyle+llvm@iteratee.net>

Codegen: Fix broken assumption in Tail Merge.

Tail merge was making the assumption that a layout successor or
predecessor was always a cfg successor/predecessor. Remove that
assumption. Changes to t

Codegen: Fix broken assumption in Tail Merge.

Tail merge was making the assumption that a layout successor or
predecessor was always a cfg successor/predecessor. Remove that
assumption. Changes to tests are necessary because the errant cfg edges
were preventing optimizations.

llvm-svn: 273700

show more ...


# 5b458cc1 09-Jun-2016 Haicheng Wu <haicheng@codeaurora.org>

Reapply "[MBP] Reduce code size by running tail merging in MBP.""

This reapplies commit r271930, r271915, r271923. They hit a bug in
Thumb which is fixed in r272258 now.

The original message:

The

Reapply "[MBP] Reduce code size by running tail merging in MBP.""

This reapplies commit r271930, r271915, r271923. They hit a bug in
Thumb which is fixed in r272258 now.

The original message:

The code layout that TailMerging (inside BranchFolding) works on is not the
final layout optimized based on the branch probability. Generally, after
BlockPlacement, many new merging opportunities emerge.

This patch calls Tail Merging after MBP and calls MBP again if Tail Merging
merges anything.

llvm-svn: 272267

show more ...


# 4fa9f3ae 07-Jun-2016 Haicheng Wu <haicheng@codeaurora.org>

Revert "[MBP] Reduce code size by running tail merging in MBP."

This reverts commit r271930, r271915, r271923. They break a thumb selfhosting
bot.

llvm-svn: 272017


# 77ea3447 06-Jun-2016 Haicheng Wu <haicheng@codeaurora.org>

[MBP] Reduce code size by running tail merging in MBP.

The code layout that TailMerging (inside BranchFolding) works on is not the
final layout optimized based on the branch probability. Generally,

[MBP] Reduce code size by running tail merging in MBP.

The code layout that TailMerging (inside BranchFolding) works on is not the
final layout optimized based on the branch probability. Generally, after
BlockPlacement, many new merging opportunities emerge.

This patch calls Tail Merging after MBP and calls MBP again if Tail Merging
merges anything.

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

llvm-svn: 271925

show more ...


# 664b561f 06-Jun-2016 Haicheng Wu <haicheng@codeaurora.org>

[BranchFolding] Replace MachineBlockFrequencyInfo with MBFIWrapper. NFC.

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

llvm-svn: 271923


Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1
# 0cfb5f85 10-May-2016 Dan Gohman <dan433584@gmail.com>

[WebAssembly] Move register stackification and coloring to a late phase.

Move the register stackification and coloring passes to run very late, after
PEI, tail duplication, and most other passes. Th

[WebAssembly] Move register stackification and coloring to a late phase.

Move the register stackification and coloring passes to run very late, after
PEI, tail duplication, and most other passes. This means that all code emitted
and expanded by those passes is now exposed to these passes. This also
eliminates the need for prologue/epilogue code to be manually stackified,
which significantly simplifies the code.

This does require running LiveIntervals a second time. It's useful to think
of these late passes not as late optimization passes, but as a domain-specific
compression algorithm based on knowledge of liveness information. It's used to
compress the code after all conventional optimizations are complete, which is
why it uses LiveIntervals at a phase when actual optimization passes don't
typically need it.

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

llvm-svn: 269012

show more ...


# 31d19d43 10-May-2016 Matthias Braun <matze@braunis.de>

CodeGen: Move TargetPassConfig from Passes.h to an own header; NFC

Many files include Passes.h but only a fraction needs to know about the
TargetPassConfig class. Move it into an own header. Also re

CodeGen: Move TargetPassConfig from Passes.h to an own header; NFC

Many files include Passes.h but only a fraction needs to know about the
TargetPassConfig class. Move it into an own header. Also rename
Passes.cpp to TargetPassConfig.cpp while we are at it.

llvm-svn: 269011

show more ...


# aa641a51 22-Apr-2016 Andrew Kaylor <andrew.kaylor@intel.com>

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


# 6013f45f 22-Apr-2016 Vedant Kumar <vsk@apple.com>

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


12345678910>>...18