[GVNHoist] Rename variables.

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

llvm-svn: 288142

[GVNHoist] Enable aggressive hoisting when optimizing for code-size

Enable scalar hoisting at -Oz as it is safe to hoist scalars to a place
where they are partially needed.

Differential Revision: h

[GVNHoist] Enable aggressive hoisting when optimizing for code-size

Enable scalar hoisting at -Oz as it is safe to hoist scalars to a place
where they are partially needed.

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

llvm-svn: 288141

show more ...

[MemorySSA] Tighten up types to make our API prettier. NFC.

Patch by bryant.

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

llvm-svn: 285750

commit back "GVN-hoist: fix store past load dependence analysis (PR30216, PR30499)"

This is with an extra change to avoid calling MemoryLocation::get() on a call instruction.

Differential Revision:

commit back "GVN-hoist: fix store past load dependence analysis (PR30216, PR30499)"

This is with an extra change to avoid calling MemoryLocation::get() on a call instruction.

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

llvm-svn: 284098

show more ...

Revert "GVN-hoist: fix store past load dependence analysis (PR30216, PR30499)"

This CL didn't actually address the test case in PR30499, and clang
still crashes.

Also revert dependent change "Memor

Revert "GVN-hoist: fix store past load dependence analysis (PR30216, PR30499)"

This CL didn't actually address the test case in PR30499, and clang
still crashes.

Also revert dependent change "Memory-SSA cleanup of clobbers interface, NFC"

Reverts r283965 and r283967.

llvm-svn: 284093

show more ...

Memory-SSA cleanup of clobbers interface, NFC

This implements the cleanup that Danny asked to commit separately from the
previous fix to GVN-hoist in https://reviews.llvm.org/D25476#inline-219818

T

Memory-SSA cleanup of clobbers interface, NFC

This implements the cleanup that Danny asked to commit separately from the
previous fix to GVN-hoist in https://reviews.llvm.org/D25476#inline-219818

Tested with ninja check on x86_64-linux.

llvm-svn: 283967

show more ...

GVN-hoist: fix store past load dependence analysis (PR30216, PR30499)

This is a refreshed version of a patch that was reverted: it fixes
the problems reported in both PR30216 and PR30499, and
contai

GVN-hoist: fix store past load dependence analysis (PR30216, PR30499)

This is a refreshed version of a patch that was reverted: it fixes
the problems reported in both PR30216 and PR30499, and
contains all the test-cases from both bugs.

To hoist stores past loads, we used to search for potential
conflicting loads on the hoisting path by following a MemorySSA
def-def link from the store to be hoisted to the previous
defining memory access, and from there we followed the def-use
chains to all the uses that occur on the hoisting path. The
problem is that the def-def link may point to a store that does
not alias with the store to be hoisted, and so the loads that are
walked may not alias with the store to be hoisted, and even as in
the testcase of PR30216, the loads that may alias with the store
to be hoisted are not visited.

The current patch visits all loads on the path from the store to
be hoisted to the hoisting position and uses the alias analysis
to ask whether the store may alias the load. I was not able to
use the MemorySSA functionality to ask for whether load and
store are clobbered: I'm not sure which function to call, so I
used a call to AA->isNoAlias().

Store past store is still working as before using a MemorySSA
query: I added an extra test to pr30216.ll to make sure store
past store does not regress.

Tested on x86_64-linux with check and a test-suite run.

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

llvm-svn: 283965

show more ...

Revert r282168 "GVN-hoist: fix store past load dependence analysis (PR30216)"

and also the dependent r282175 "GVN-hoist: do not dereference null pointers"

It's causing compiler crashes building Har

Revert r282168 "GVN-hoist: fix store past load dependence analysis (PR30216)"

and also the dependent r282175 "GVN-hoist: do not dereference null pointers"

It's causing compiler crashes building Harfbuzz (PR30499).

llvm-svn: 282199

show more ...

GVN-hoist: do not dereference null pointers

there may be basic blocks without memory accesses, in which case the
list of accesses is a null pointer.

llvm-svn: 282175

GVN-hoist: fix store past load dependence analysis (PR30216)

To hoist stores past loads, we used to search for potential
conflicting loads on the hoisting path by following a MemorySSA
def-def link

GVN-hoist: fix store past load dependence analysis (PR30216)

To hoist stores past loads, we used to search for potential
conflicting loads on the hoisting path by following a MemorySSA
def-def link from the store to be hoisted to the previous
defining memory access, and from there we followed the def-use
chains to all the uses that occur on the hoisting path. The
problem is that the def-def link may point to a store that does
not alias with the store to be hoisted, and so the loads that are
walked may not alias with the store to be hoisted, and even as in
the testcase of PR30216, the loads that may alias with the store
to be hoisted are not visited.

The current patch visits all loads on the path from the store to
be hoisted to the hoisting position and uses the alias analysis
to ask whether the store may alias the load. I was not able to
use the MemorySSA functionality to ask for whether load and
store are clobbered: I'm not sure which function to call, so I
used a call to AA->isNoAlias().

Store past store is still working as before using a MemorySSA
query: I added an extra test to pr30216.ll to make sure store
past store does not regress.

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

llvm-svn: 282168

show more ...

GVN-hoist: fix typo

llvm-svn: 282165

GVN-hoist: only hoist relevant scalar instructions

Without this patch, GVN-hoist would think that a branch instruction is a scalar instruction
and would try to value number it. The patch filters out

GVN-hoist: only hoist relevant scalar instructions

Without this patch, GVN-hoist would think that a branch instruction is a scalar instruction
and would try to value number it. The patch filters out all such kind of irrelevant instructions.

A bit frustrating is that there is no easy way to discard all those very infrequent instructions,
a bit like isa<TerminatorInst> that stands for a large family of instructions. I'm thinking that
checking for those very infrequent other instructions would cost us more in compilation time
than just letting those instructions getting numbered, so I'm still thinking that a simpler check:

if (isa<TerminatorInst>(I))
return false;

is better than listing all the other less frequent instructions.

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

llvm-svn: 282160

show more ...

IR: Remove Value::intersectOptionalDataWith, replace all calls with calls to Instruction::andIRFlags.

The two functions are functionally equivalent.

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

IR: Remove Value::intersectOptionalDataWith, replace all calls with calls to Instruction::andIRFlags.

The two functions are functionally equivalent.

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

llvm-svn: 280884

show more ...

GVN-hoist: invalidate MD cache (PR29144)

Without invalidating the entries in the MD cache we would try to access instructions
that were removed in previous iterations of hoisting.

Differential Revi

GVN-hoist: invalidate MD cache (PR29144)

Without invalidating the entries in the MD cache we would try to access instructions
that were removed in previous iterations of hoisting.

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

llvm-svn: 279907

show more ...

GVN-hoist: fix hoistingFromAllPaths for loops (PR29034)

It is invalid to hoist stores or loads if they are not executed on all paths
from the hoisting point to the exit of the function. In the testc

GVN-hoist: fix hoistingFromAllPaths for loops (PR29034)

It is invalid to hoist stores or loads if they are not executed on all paths
from the hoisting point to the exit of the function. In the testcase, there are
paths in the loop that do not execute the stores or the loads, and so hoisting
them within the loop is unsafe.

The problem is that the current implementation of hoistingFromAllPaths is
incomplete: it walks all blocks dominated by the hoisting point, and does not
return false when the loop contains a path on which the hoisted ld/st is
not executed.

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

llvm-svn: 279732

show more ...

GVNHoist: Use the pass version of MemorySSA and preserve it.

Summary: GVNHoist: Use the pass version of MemorySSA and preserve it.

Reviewers: sebpop, george.burgess.iv

Subscribers: llvm-commits

D

GVNHoist: Use the pass version of MemorySSA and preserve it.

Summary: GVNHoist: Use the pass version of MemorySSA and preserve it.

Reviewers: sebpop, george.burgess.iv

Subscribers: llvm-commits

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

llvm-svn: 279504

show more ...

Test commit

llvm-svn: 278598

Use range algorithms instead of unpacking begin/end

No functionality change is intended.

llvm-svn: 278417

Fix PR 28933

Summary:
This fixes PR 28933 by making sure GVNHoist does not try to recreate memory
accesses when it has not actually moved them.

Reviewers: sebpop

Subscribers: llvm-commits, george.

Fix PR 28933

Summary:
This fixes PR 28933 by making sure GVNHoist does not try to recreate memory
accesses when it has not actually moved them.

Reviewers: sebpop

Subscribers: llvm-commits, george.burgess.iv

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

llvm-svn: 278401

show more ...

Consistently use FunctionAnalysisManager

Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching e

Consistently use FunctionAnalysisManager

Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.

Thanks to David for the suggestion.

llvm-svn: 278077

show more ...

GVN-hoist: fix early exit logic

The patch splits a complex && if condition into easier to read and understand
logic. That wrong early exit condition was letting some instructions with not
all opera

GVN-hoist: fix early exit logic

The patch splits a complex && if condition into easier to read and understand
logic. That wrong early exit condition was letting some instructions with not
all operands available pass through when HoistingGeps was true.

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

llvm-svn: 277785

show more ...

GVNHoist: Don't hoist convergent calls

llvm-svn: 277767

GVN-hoist: limit the length of dependent instructions

Limit the number of times the while(1) loop is executed. With this restriction
the number of hoisted instructions does not change in a significa

GVN-hoist: limit the length of dependent instructions

Limit the number of times the while(1) loop is executed. With this restriction
the number of hoisted instructions does not change in a significant way on the
test-suite.

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

llvm-svn: 277651

show more ...

GVN-hoist: compute DFS numbers once

With this patch we compute the DFS numbers of instructions only once and update
them during the code generation when an instruction gets hoisted.

Differential Re

GVN-hoist: compute DFS numbers once

With this patch we compute the DFS numbers of instructions only once and update
them during the code generation when an instruction gets hoisted.

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

llvm-svn: 277650

show more ...

GVN-hoist: compute MSSA once per function (PR28670)

With this patch we compute the MemorySSA once and update it in the code generator.

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

llvm-s

GVN-hoist: compute MSSA once per function (PR28670)

With this patch we compute the MemorySSA once and update it in the code generator.

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

llvm-svn: 277649

show more ...