Revert r237539: "Reapply r237520 with another fix for infinite looping"

This caused PR23583.

llvm-svn: 237739

Reapply r237520 with another fix for infinite looping

SimplifyDemandedBits was "simplifying" a constant by removing just sign bits.
This caused a canonicalization race between different parts of ins

Reapply r237520 with another fix for infinite looping

SimplifyDemandedBits was "simplifying" a constant by removing just sign bits.
This caused a canonicalization race between different parts of instcombine.

Fix and regression test added - third time lucky?

llvm-svn: 237539

show more ...

Revert commits r237521 and r237520.

The AArch64 LNT bot is unhappy - I've found that the problem is in
SimpliftDemandedBits, but that's going to require another code review
so reverting in the meant

Revert commits r237521 and r237520.

The AArch64 LNT bot is unhappy - I've found that the problem is in
SimpliftDemandedBits, but that's going to require another code review
so reverting in the meantime.

llvm-svn: 237528

show more ...

Reapply r237453 with a fix for the test timeouts.

The test timeouts were due to instcombine fighting itself. Regression test added.
Original log message:

Canonicalize min/max expressions correctly.

Reapply r237453 with a fix for the test timeouts.

The test timeouts were due to instcombine fighting itself. Regression test added.
Original log message:

Canonicalize min/max expressions correctly.

This patch introduces a canonical form for min/max idioms where one operand
is extended or truncated. This often happens when the other operand is a
constant. For example:

%1 = icmp slt i32 %a, i32 0
%2 = sext i32 %a to i64
%3 = select i1 %1, i64 %2, i64 0

Would now be canonicalized into:

%1 = icmp slt i32 %a, i32 0
%2 = select i1 %1, i32 %a, i32 0
%3 = sext i32 %2 to i64

This builds upon a patch posted by David Majenemer
(https://www.marc.info/?l=llvm-commits&m=143008038714141&w=2). That pass
passively stopped instcombine from ruining canonical patterns. This
patch additionally actively makes instcombine canonicalize too.

Canonicalization of expressions involving a change in type from int->fp
or fp->int are not yet implemented.

llvm-svn: 237520

show more ...

Convert PHI getIncomingValue() to foreach over incoming_values(). NFC.

We already had a method to iterate over all the incoming values of a PHI. This just changes all eligible code to use it.

Ine

Convert PHI getIncomingValue() to foreach over incoming_values(). NFC.

We already had a method to iterate over all the incoming values of a PHI. This just changes all eligible code to use it.

Ineligible code included anything which cared about the index, or was also trying to get the i'th incoming BB.

llvm-svn: 237169

show more ...

[InstCombine] Create zero constants on demand.

No functional change intended.

llvm-svn: 235257

Recommit r233116 better: Remove a redundant instcombine involving bitcasts of geps of bitcasts

This just didn't need to be here at all, but the assertion I tried to
add wasn't appropriate either - t

Recommit r233116 better: Remove a redundant instcombine involving bitcasts of geps of bitcasts

This just didn't need to be here at all, but the assertion I tried to
add wasn't appropriate either - the circumstance isn't impossible, it's
just not important to deal with it here - the gep-rooted version of this
instcombine will handle this case, we don't need to duplicate it for the
case where the gep happens to be used in a bitcast.

llvm-svn: 233404

show more ...

Opaque Pointer Types: GEP API migrations to specify the gep type explicitly

The changes to InstCombine (& SCEV) do seem a bit silly - it doesn't make
anything obviously better to have the caller acc

Opaque Pointer Types: GEP API migrations to specify the gep type explicitly

The changes to InstCombine (& SCEV) do seem a bit silly - it doesn't make
anything obviously better to have the caller access the pointers element
type (the thing I'm trying to remove) than the GEP itself, but it's a
helpful migration step. This will allow me to more obviously lock down
GEP (& Load, etc) API usage, then fix all the code that accesses pointer
element types except the places that need to be removed (most of the
InstCombines) anyway - at which point I'll need to just remove all that
code because it won't be meaningful anymore (there will be no pointer
types, so no bitcasts to combine)

SCEV looks like it'll need some restructuring - we'll have to do a bit
more work for GEP canonicalization, since it'll depend on how it's used
if we can even manage to canonicalize it to a non-ugly GEP. I guess we
can do some fun stuff like voting (do 2 out of 3 load from the GEP with
a certain type that gives a pretty GEP? Does every typed use of the GEP
use either a specific type or a generic type (i8*, etc)?)

llvm-svn: 233131

show more ...

Revert "Remove an InstCombine that seems to have become redundant."

Assertion fires in compiler-rt. Guess it does fire..

This reverts commit r233116.

llvm-svn: 233121

Remove an InstCombine that seems to have become redundant.

Assert that this doesn't fire - I'll remove all of this later, but just
leaving it in for a while in case this is firing & we just don't ha

Remove an InstCombine that seems to have become redundant.

Assert that this doesn't fire - I'll remove all of this later, but just
leaving it in for a while in case this is firing & we just don't have
test coverage.

llvm-svn: 233116

show more ...

[opaque pointer type] IRBuilder gep migration progress

llvm-svn: 232294

DataLayout is mandatory, update the API to reflect it with references.

Summary:
Now that the DataLayout is a mandatory part of the module, let's start
cleaning the codebase. This patch is a first at

DataLayout is mandatory, update the API to reflect it with references.

Summary:
Now that the DataLayout is a mandatory part of the module, let's start
cleaning the codebase. This patch is a first attempt at doing that.

This patch is not exactly NFC as for instance some places were passing
a nullptr instead of the DataLayout, possibly just because there was a
default value on the DataLayout argument to many functions in the API.
Even though it is not purely NFC, there is no change in the
validation.

I turned as many pointer to DataLayout to references, this helped
figuring out all the places where a nullptr could come up.

I had initially a local version of this patch broken into over 30
independant, commits but some later commit were cleaning the API and
touching part of the code modified in the previous commits, so it
seemed cleaner without the intermediate state.

Test Plan:

Reviewers: echristo

Subscribers: llvm-commits

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231740

show more ...

InstCombine: fold more cases of (fp_to_u/sint (u/sint_to_fp val))

Fixes radar 15486701.

From: Fiona Glaser <fglaser@apple.com>
llvm-svn: 229437

[InstCombine] When canonicalizing gep indices, prefer zext when possible

If we know that the sign bit of a value being sign extended is zero, we can use a zero extension instead. This is motivated

[InstCombine] When canonicalizing gep indices, prefer zext when possible

If we know that the sign bit of a value being sign extended is zero, we can use a zero extension instead. This is motivated by the fact that zero extensions are generally cheaper on x86 (and most other architectures?). We already apply a similar transform in DAGCombine, this just extends that to the IR level.

This comes up when we eagerly canonicalize gep indices to the width of a machine register (i64 on x86_64). To do so, we insert sign extensions (sext) to promote smaller types.

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

llvm-svn: 229189

show more ...

[PM] Rename InstCombine.h to InstCombineInternal.h in preparation for
creating a non-internal header file for the InstCombine pass.

I thought about calling this InstCombiner.h or in some way more cl

[PM] Rename InstCombine.h to InstCombineInternal.h in preparation for
creating a non-internal header file for the InstCombine pass.

I thought about calling this InstCombiner.h or in some way more clearly
associating it with the InstCombiner clas that it is primarily defining,
but there are several other utility interfaces defined within this for
InstCombine. If, in the course of refactoring, those end up moving
elsewhere or going away, it might make more sense to make this the
combiner's header alone.

Naturally, this is a bikeshed to a certain degree, so feel free to lobby
for a different shade of paint if this name just doesn't suit you.

llvm-svn: 226783

show more ...

[PM] Move TargetLibraryInfo into the Analysis library.

While the term "Target" is in the name, it doesn't really have to do
with the LLVM Target library -- this isn't an abstraction which LLVM
targe

[PM] Move TargetLibraryInfo into the Analysis library.

While the term "Target" is in the name, it doesn't really have to do
with the LLVM Target library -- this isn't an abstraction which LLVM
targets generally need to implement or extend. It has much more to do
with modeling the various runtime libraries on different OSes and with
different runtime environments. The "target" in this sense is the more
general sense of a target of cross compilation.

This is in preparation for porting this analysis to the new pass
manager.

No functionality changed, and updates inbound for Clang and Polly.

llvm-svn: 226078

show more ...

More code format fix from r224133, NFC

llvm-svn: 224140

Restructure code from r224097. NFC

llvm-svn: 224133

Fix another infinite loop in InstCombine

Summary:
InstCombine infinite-loops for the testcase added
It is because InstCombine is generating instructions that can be
optimized by itself. Fix by not o

Fix another infinite loop in InstCombine

Summary:
InstCombine infinite-loops for the testcase added
It is because InstCombine is generating instructions that can be
optimized by itself. Fix by not optimizing frem if the optimized
type is the same as original type.
rdar://problem/19150820

Reviewers: majnemer

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

llvm-svn: 224097

show more ...

InstCombine: Fix another infinite loop caused by visitFPTrunc

We would attempt to replace an frem's operand with the same operand.
This would cause InstCombine to think real work was done, causing
I

InstCombine: Fix another infinite loop caused by visitFPTrunc

We would attempt to replace an frem's operand with the same operand.
This would cause InstCombine to think real work was done, causing
InstCombine to enter an infinite loop.

This fixes the second part of PR21576.

llvm-svn: 222265

show more ...

Revert "Revert r222040 because of bot failure."

This reverts commit r222203, reverting r222040 didn't end up turning the
bot green.

llvm-svn: 222261

Revert r222040 because of bot failure.

http://lab.llvm.org:8080/green/job/clang-Rlto_master/298/
Hopefully, bot will be green.

llvm-svn: 222203

InstCombine: Fix infinite loop caused by visitFPTrunc

We would attempt to replace a fptrunc of an frem with an identical
fptrunc. This would cause the new fptrunc to be added to the worklist.
Of co

InstCombine: Fix infinite loop caused by visitFPTrunc

We would attempt to replace a fptrunc of an frem with an identical
fptrunc. This would cause the new fptrunc to be added to the worklist.
Of course, this results in an infinite loop because we will keep
visiting the newly created fptruncs.

This fixes PR21576.

llvm-svn: 222040

show more ...

InstCombine: Fix a combine assuming that icmp operands were integers

An icmp may have pointer arguments, it isn't limited to integers or
vectors of integers.

This fixes PR21388.

llvm-svn: 220664

Handle sqrt() shrinking in SimplifyLibCalls like any other call

This patch removes a chunk of special case logic for folding
(float)sqrt((double)x) -> sqrtf(x)
in InstCombineCasts and handles it in

Handle sqrt() shrinking in SimplifyLibCalls like any other call

This patch removes a chunk of special case logic for folding
(float)sqrt((double)x) -> sqrtf(x)
in InstCombineCasts and handles it in the mainstream path of SimplifyLibCalls.

No functional change intended, but I loosened the restriction on the existing
sqrt testcases to allow for this optimization even without unsafe-fp-math because
that's the existing behavior.

I also added a missing test case for not shrinking the llvm.sqrt.f64 intrinsic
in case the result is used as a double.

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

llvm-svn: 220514

show more ...